CircleCIを愛用している私ですが、最近GitHub Actionsに入門してみました。また、CI/CDツールは様々なメリットやデメリットなどエンジニアとして把握すべきです。ちなみに私はCircleCIの経験がある前提でGitHub Actionsを実装していたので、「この機能ないんかい!どうやるんだ!?」とハマることがありました。(脳の切り替えが遅い)

さて、以前CircleCIで個人のリポジトリがマージされるとgit pullによるSSHデプロイするように作りましたが、手っ取り早く、同様なことをAWSのEC2に対して高速にrsyncデプロイを実装してみました。

[CircleCI]masterにマージされたらサーバーにSSHしてコードをデプロイする


構成図

※例としてGitHub Flowによる開発方法、各EC2はPublicサブネット配下にあり、SSHができる環境です。アプリケーションはPHP7.4/Laravelとします。

・Stg
 ・ GitHub Actions
  ・リモートブランチにpush
  ・workflow_dispatchによる手動でリモートブランチを指定してrsyncデプロイ
・本番
 ・GitHub Actions
  ・masterマージによるrsyncデプロイ


GitHub Actionsのデバッグってどうやるのよ?

[Github Actions]シンタックスチェック

GitHub ActionsにSSHしてデバッグする

CircleCI同様と思いきや、デバッグ時にコンテナにSSHする場合はわざわざ action-tmate を指定してpushしないといけません。結構手間なのでコメントアウトして書いておくといいですね。シンタックスチェックは actionlint コマンドを使えばOK。早速書いていきましょう。


Setting GitHub Actions

https://docs.github.com/ja/actions/using-workflows/workflow-syntax-for-github-actions

  • deploy/stg/deploy.sh

まず、Laravelをデプロイするためのレシピとしてシェルスクリプトを作りました。単純にcomposer install、rsyncしてマイグレーションするだけです。rsyncはchecksumで差分のみコピーと、デフォルトだと隠しファイルがコピーされないので–includeで明示的に指定しましょう。.gitディレクトリは増え続けるので–excludeで省きます。この流れをworkflows直に書こうとしていましたが、可読性が下がるので上記のように分けるのがベストだと思いました。

ちなみに–deleteオプションはによる転送元のディレクトリに存在せず、転送先のディレクトリに存在するファイルがあれば削除します。

※本番用のデプロイシェルはステージングと同様なので割愛します。

  • .github/workflows/deploy-stg.yml

上記コメントしていますが、 actions/checkout についてはCircleCIのcheckoutと挙動が違うので下記ドキュメントを見たほうが良さそうです。

https://github.com/actions/checkout

ステージング環境にテストするためには、push時やプルリクエスト時にステージング環境へリモートブランチのソースコードをデプロイできればOKということになります。そこで、CircleCI時では以下のようにCircleCIで定義されているブランチ名を変数として取ってきてAPI経由でデプロイするといったことをできないのかと路頭に迷っていたところ、 workflow_dispatch を利用して手動でWebからブランチ名を指定、ブランチをcheckoutしてデプロイできるというのを知りました。これならわざわざステージング用にシェル芸する必要はないですし、本番環境と同等になります。非常に便利ですね。

https://docs.github.com/ja/actions/managing-workflow-runs/manually-running-a-workflow

[CircleCI][ECS/Fargate]API v2を使って気楽にステージング環境をデプロイさせる

ちなみにCircleCIでも manual pipeline run button というのがあったのかい….!!(以下後でテストしてみます)

https://circleci.com/ja/changelog/#%E3%83%91%E3%82%A4%E3%83%97%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%AE%E6%89%8B%E5%8B%95%E5%AE%9F%E8%A1%8C%E3%83%9C%E3%82%BF%E3%83%B3

Trigger Pipelineでbooleanとstg用のworkflows名に対してtrueを指定すればリリースできました。

  • .github/workflows/deploy-prd.yml

本番もコードはほとんど同じで、onのworkflowでbranchesはmasterを指定すればOK。CircleCIと似てる。


デプロイ確認とSlack通知


まとめ

CircleCIは1ファイル管理しますが複数のworkflowを書けるのがGithub Actionsのメリットと感じました。(個人的にはCircleCI推しだけど)Github Actionsは導入も簡単だし、気楽にCI/CDを実装できるのは良いと感じました。コンテナのデプロイもサクッとできそう。


ちなみに

SSMでもrunningしているインスタンスIDをタグで取得して、SSHが動いていればrsync可能です。マイグレーションは実行シェル分けたほうが分かりやすいですね。

[AWS]SSMでEC2にログインする方法

  • deploy/stg/deploy.sh

  • deploy/stg/migration/run.sh

カテゴリー: AWSGitHub Actions

adachin

1989年生まれのFindy/SRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化、分析基盤の運用などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTA/TechBullで未経験者にインフラのコーチング/コミュニティマネージャーとして立ち上げと運営をしている。また、過去「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください