概要
みろりHPのデプロイが毎回面倒だったので、自動化してやったぜ!
これまで、みろりHPの機能追加、機能修正を行うときは、まず自分のぱそこで作業を行い、保存のために GitHub へ push して、変更ファイルをサーバ(VPS)へ FTP 接続でアップロードして、同サーバへ SSH 接続でデプロイコマンドを流す、という作業が必要だったのだ。面倒だ↓。
面倒だったので、 GitHub へ push するだけであとは全部勝手にデプロイしてくれるようにした↓ぜ!
- master branch への push を trigger にして GitHub Actions を実行する
- VPS へ SSH 接続する
- 認証にはパスワードではなく公開鍵方式を使う
- GitHub からソースを取得する
- デプロイコマンドを流す
今回作った yaml
こちらが GitHub Actions 用の yaml だ。これが上の画像の「push を trigger にこれやって」のスクリプトとなる。リポジトリの .github/workflows/
下に配置する。これは完全にみろりHP用なので、別のアプリケーションにそのまま使うことはできないだろう(とくに name: Deployment 部分)。だけど、 Actions を使って SSH 接続 -> デプロイサーバ内でソース取得、という流れの参考にはなるはずだ。
name: Python application
on:
push:
branches: [ master ]
env:
SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Deployment
run: |
echo "$SECRET_KEY" > secret_key
chmod 600 secret_key
ssh -oStrictHostKeyChecking=no ${SERVER_USER}@${SERVER_HOST} -i secret_key "
cd /vagrant/ &&
git fetch origin &&
git reset --hard origin/master &&
sudo /env3.6/bin/python3.6 /vagrant/manage.py migrate --settings=config.settings.production &&
sudo /env3.6/bin/python3.6 /vagrant/manage.py collectstatic -c --noinput --settings=config.settings.production &&
sudo apachectl restart
"
env:
SECRET_KEY: ${{ secrets.SECRET_KEY }}
SERVER_USER: ${{ secrets.SERVER_USER }}
SERVER_HOST: ${{ secrets.SERVER_HOST }}
# 成功時はこちらのステップが実行されます。
- name: Slack Notification on Success
if: success()
uses: rtCamp/action-slack-notify@v2.0.2
env:
SLACK_TITLE: Mrrhp deployment succeeded
SLACK_COLOR: good
# 失敗時はこちらのステップが実行されます。
- name: Slack Notification on Failure
uses: rtCamp/action-slack-notify@v2.0.2
if: failure()
env:
SLACK_TITLE: Mrrhp deployment failed
SLACK_COLOR: danger
今回のポイント
rtCamp/action-slack-notify
が、デプロイの実行を(ひいては成功と失敗も)Slack に通知してくれる。- ソースの取得に
git pull
ではなくgit fetch origin && git reset --hard origin/master
を使っている点。- このコマンドは、「ローカルのソースはいくらぶち壊してもいいから兎も角 origin と完全に同じ状態にしてくれ!」というコマンドだ。
pull
だとorigin/master
がreset
やpush --force-with-lease
で変更されているときに対応できない。これはどういうことかというと、「今回デプロイしたソースにちょっと問題があったわ、元の状態に戻そう」に対応できないということだ。- だけど origin と完全に合わせるようにしておけば、 origin を
reset
やらpush --force-with-lease
で元のバージョンに戻せば、デプロイサーバのソースも元に戻るという寸法だ。
- ssh 接続に公開鍵方式を使っている点。
- もともとパスワード認証と IP 制限で SSH 接続していたのだけれど、それだと GitHub Actions から接続ができない。これを機会に、公開鍵方式に切り替えた。
- IP 制限も解除しちゃったので、そこはちょっとセキュリティ下がっちゃったかな。
公開鍵方式の導入方法
上で触れた、公開鍵方式ログインの方法を書く。まず自分のローカルで鍵ファイルを作って、公開鍵を VPS へアップロード。
ssh-keygen
# ↓生成される。
# /Users/user/.ssh/id_rsa -> GitHub secret へ登録
# /Users/user/.ssh/id_rsa.pub -> VPS のホームディレクトリに置く
VPS 側で公開鍵認証の設定をする。
cd
mkdir .ssh
chmod 700 .ssh/
mv id_rsa.pub .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
秘密鍵指定で VPS へアクセスできることを確認する。
ssh -i /Users/user/.ssh/id_rsa root@host
VPS 側でパスワードログインを禁じる。 /etc/ssh/sshd_config を編集。
PasswordAuthentication no
おしまい
今回の件は、明らかに効率化につながっており、開発のハードルを下げることになっている。やりきった感があるぜ。