GitHub Actionsを使ってコンテナ版AWS Lambdaにデプロイしてみた | DevelopersIO
GitHub Actionsを使い、コンテナイメージをAmazon ECRにプッシュし、AWS Lambdaにデプロイする方法を紹介します。 GitHubからAWSへの認証では、OpenID Connect(OIDC)を利用します。 本ブログでは、GitHub Actionsを使い、main ブランチへの push をトリガーにコンテナイメージをビルドしてコンテナレジストリのAmazon ECRにプッシュし、AWS Lambdaにコンテナイメージをデプロイする方法を紹介します。 実質的にやっていることは、GitHub の ECS 向けドキュメントをベースに、以下の変更を加えています。 GitHub から AWS への認証に、IAMアクセスキーの代わりに OpenID Connect(OIDC)を利用 デプロイ先をAmazon ECSからAWS Lambdaへ変更 大前提として、デプロイのゴ
ECS用のCDパイプラインに対する考察
それでは、1パターンずつ構成を確認していきます。 1. 全部GitHub Actionsでやる GitHub Actionsでパイプライン全体を構築する場合は、以下の図のような構成になります。 ちなみに、GitHubのDeploymentsを使用することで、Slackと組み合わせてのChatOpsや、任意のコミットのデプロイを実行などいろいろと便利になります。 ですが、Deployments APIをパイプラインで利用するには、Actionsのトリガーの条件を変えたり、ECSへのデプロイの成否に応じてAPIを使ってDeploymentのステータスを更新したりする処理が必要になり、少々パイプラインが複雑化してしまいます。 なので、今回の趣旨とちょっとずれているため、各パターンには記載していません。 では、以下で処理を順に説明していきます。 Image Build 図中の Build Imag
GitHub Actionsでデプロイを並列に実行させてCI/CDを高速化してみた | DevelopersIO
開発の規模が大きくなると、CI/CDに時間がかかるようになります。特にクラウド環境を用いた開発で、インフラ構成までコードで管理している場合、差分の確認やインフラサービスの更新で処理の待ち時間が発生します。 各機能やサービスに依存関係がないのであれば、処理を並列に実行することで、デプロイ等にかかる時間を短縮することが出来ます。デプロイ以外にもビルドやテストで時間がかかっているのであれば、機能単位などに分割して並列に実行させるのも良いと思います。 本記事ではAWS環境へのデプロイをGitHub Actionsで並列に実行させてみます。 ワークフローを実装 AWS環境にデプロイするワークフローを実装します。.github/workflowsにYAMLファイルを作成すると、プッシュ時にGitHub Actionsがワークフローを実行します。 以下のワークフローでは、指定したブランチにプッシュされた
Google CloudのCloudBuild + KMSで機密ファイルを暗号化して管理する
ZennではAPIサーバーを動かすためにGCPを使っています。具体的にはCI/CDサービスのCloudBuildからAppEngineデプロイするようにしています。 その中で少しややこしいのが機密データを含むファイルの管理です。 GCPのプロジェクトの場合にはCloud Key Management System（KMS）というものを合わせて使うとCloudBuildのステップの中で暗号化したファイルを復元できます。 例えば、秘匿情報を含む.envというファイルがあるとして、GitHub等にはプッシュしたくないが、AppEngineで動かすアプリの中で読み込みたいというケースを考えてみます。 GCPではCloudBuild + KMSを使うことで実現が可能です。 大まかな流れ .gitignoreに.envを指定 ローカルでKMSにより.envを暗号化（.env.encファイルが作成される
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
