Pocket

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時では以下のようにCicleCIで定義されているブランチ名を変数として取ってきて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を実装できるのは良いと感じました。コンテナのデプロイもサクッとできそう。ちなみにPrivateサブネット配下の場合はSSMでデプロイできそうです。

CircleCI社がGithub Actionsからの移行という記事を出しているので、比較してみるのもいいかも。この記事はある意味面白いw

https://circleci.com/docs/ja/2.0/migrating-from-github/

Pocket

カテゴリー: AWSGitHub Actions

adachin

1989年生まれのSRE。 ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。好きなツールはAnsible,Terraform,CircleCIで、ECS/Fargateでのインフラ構築を得意とする。副業では数社サーバー保守とベンチャー企業のインフラ改善やMENTAで未経験者にインフラのコーチングを実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、緊急対応、インフラコード化、リファクタリング、セキュリティ強化、新技術の検証、Docker開発環境の提供、AWSでのインフラ構築、ECS/Fargateへ移行、CakePHP4での管理画面作成、メンター、分析基盤の運用を担当している。個人開発では「夫婦、パートナー向け家事管理サービス/famii」をCakePHP4で絶賛開発中。

0件のコメント

コメントを残す

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