吉田の雑記

エンジニアとしてのアウトプット中心でその他のことも書きます

Fly.ioへのデプロイをGitHub Actionsで自動化する

この記事の立ち位置

  • 自身の構築時のメモで、Fly.ioが公開しているドキュメントから変更した部分や、他に参照したドキュメントを書く。
  • 2023年2月時点の情報で、内容・リンクが変更となる可能性があります。ご了承ください。

大元のドキュメント

fly.io

やること

今回はすでに作成済みのリポジトリを想定。

  1. コンソール上でflyctl auth token を実行し、トークンを取得。
  2. リポジトリのsecretsを設定する。キー名はFLY_API_TOKEN
    対象のリポジトリの"Settings"→"Secrets and variables"→"Actions"→"Secrets"の箇所。
  3. fly.toml というデプロイのための情報が書かれたファイルをgit追跡対象に設定(.gitignoreから外す) 。
  4. .github/workflows/fly.yml というGitHub Actions用のワークフローファイルを作成する。

fly.ymlファイルの中身

詳細はドキュメントのここからを参照。 今回は一部改変を以下のように設定。

name: Fly Deploy
on:
  pull_request:
    types:
      - closed
    branches:
      - main
env:
  FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
jobs:
  deploy:
    name: Deploy app
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: superfly/flyctl-actions/setup-flyctl@master
      - run: flyctl deploy --remote-only

変更箇所

GitHub Actionsが走るタイミングを「mainブランチにpushされたとき」→「mainブランチにプルリクエストがマージされたとき」に変更。

環境が2つある場合

例えばproduction/stagingの二環境が存在する場合、以下のページを参考にfly.tomlfly.xxxxx.tomlといった形で複数作っていると想定。

fly.io

この場合には以下を変更する。

  • .github/workflows/fly.ymlfly.xxxxx.ymlといった形で複数作成する。
  • 実行条件内のbranchesを分ける。
  • 最終行の- run: flyctl deploy --remote-only末尾に- run: flyctl deploy --remote-only --config fly.xxxxx.tomlというように利用するtomlファイルを明示的に指定する。(コンソールでのflyctlと同じような考え方。)

設定してどうなったか

Fly.ioはデフォルトだとローカルからファイルをアップロードしてデプロイする形式。
以下のようなデメリットがあったので、これらが解消され、カフェでも作業ができるようになってホクホク。

  • コミットすらしていないソースをデプロイできるので、GitHubのソースと一致していない可能性がある。
  • フリーwifiでは恐らくセキュリティの問題(アップロードが制限されている?)で弾かれる。

もちろんCI/CDらしくもっとテストを走らせるとかゴニョゴニョできるようになりたい。

最後に

GitHub Actionsを始めて触ったものの、あまり引っかからずに設定ができた。
Circle CIからGitHub Actionsに移行しつつあると聞いたので、もっと触ってみたい。