みろりHP、とうとう自動デプロイに対応する(v3.14.0)

概要

みろり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

おしまい

今回の件は、明らかに効率化につながっており、開発のハードルを下げることになっている。やりきった感があるぜ。