Self-hosted GitHub Actions runners in AWS CodeBuild を試す
CodeBuild プロジェクトを使用して Webhook を設定し、GitHub ACtions ワークフローの yaml を更新して CodeBuild マシン上でホストされているセルフホストランナーを使用できる GitHub への認証は PAT か OAuth App を使う まとめというかわかったこと ※間違ってることや、こうすればいいよなどがあったらコメントください。 良かった点 セットアップは楽 ephemeral である 起動時間は EC2、Lambda 共に 1 分程度だった 個人的には十分速い マネージドイメージに加えて Docker カスタムイメージを指定可能 jobs.<job_id>.runs-on に -<image>-<image-version>-<instance-size> を追記すると、設定不要で様々なアーキテクチャのイメージを使える jobs.<job
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo
AWS CodeBuild でGitHub Actionsを呼び出せるようになったよ - Qiita
概要 2023年7月7日に、awsからAWS CodeBuildの機能アップデートが発表されました。 みんな大好き CodeBuild からどうやらGithub Actionsを呼び出せるとのことで、今回はどんな形で呼び出せるのかを検証してみました。 新機能: CodeBuild から Github Actions の呼び出し CodeBild では、buildspec というファイル(ビルド仕様)を使用し、CodeBuild の実行時にどんな処理をするのかを記述していきます。 例: version: 0.2 run-as: Linux-user-name env: variables: key: "value" key: "value" phases: install: run-as: Linux-user-name runtime-versions: runtime: version
C#で作成したAWS Lambdaの関数をGitHub Actionsで自動デプロイする - Qiita
.NET用のAmazon.Lambda.Toolsで下のコマンドで.NETプロジェクトを作成すると、以下のようなディレクトリ構成となります。 （プロジェクトファイルがSampleFunction/src/SampleFunction/SampleFunction.csprojに存在する） % dotnet new lambda.EmptyFunction --name SampleFunction テンプレート "Lambda Empty Function" が正常に作成されました。 % cd SampleFunction % tree SampleFunction SampleFunction ├── src │ └── SampleFunction │ ├── Function.cs │ ├── Readme.md │ ├── SampleFunction.csproj │ └── a
Lambda Web Adapter + SAMで既存のGo Fiberアプリをサーバーレス化する
背景 既存のGoアプリをAWS Lambda上で実行するためには、 aws-lambda-go、aws-lambda-go-api-proxyなどのライブラリーを使用しなければならず、 それに伴い、アプリケーションコードの侵入性が高く、移行するためには不便な状況がありました。 そこで、AWS Labsが提供するAWS Lambda Web Adapterを使用することで、既存のGoアプリを簡単にサーバーレス化することができるということです。 AWS Lambda Web Adapterは、HTTPリクエストをAWS Lambdaのイベントとして処理することで、既存のGoアプリをAWS Lambda上で実行するために必要なコードの侵入性を最小限に抑え、移行するために必要な変更量を減らします。 これにより、既存のGoアプリをサーバーレスアーキテクチャに移行するために不便なことがなくなり、AWS
GitHub Actionsでもっとセキュアにコンテナイメージをプッシュする - Qiita
2021/10/27にGithub ActionsでOpenID Connect（以下OIDC）サポートが正式にアナウンスになりました。 元々IAM Userの機密情報（アクセスキー＆シークレットキー）を使ってGithub Actionsでコンテナイメージのビルド&プッシュを行っていましたが、IAM Userの機密情報を使っていることで、万が一誤って機密情報をGithubリポジトリにプッシュしてしまうこともありえ、AWSも推奨していないので、今回OICDの仕様に則り一時的な認証情報でAWSリソースへアクセス・操作できるようにしたいと思います。 AWSでの設定 まずはGithub ActionsからOIDCでAWSにアクセスできるよう、いくらかIAMでロールなどを作成します。 AWSコンソールからポチポチして作成することもできるのですが、作成したリソースの管理のためにTerraformでAW
【GitHub Actions】S3へのデプロイ後にCloudFrontのキャッシュを削除する
はじめに CloudFront + S3 でホスティングしている Web ページで、S3にデプロイした時に CloudFront のキャッシュが効いて変更が反映されない事象がありました。CloudFront のキャッシュは画面上からでも削除できますが、毎回手動で対応する方法だと削除するのを忘れそうな気がするので、デプロイのフローの中でキャッシュの削除までできるようにします。 修正前の GitHub Actions のワークフロー やっていることはかなりシンプルで、ビルドとS3へのデプロイをしているだけです。 name: Deploy on: push env: AWS_ROLE_ARN: arn:aws:iam::${{secrets.AWS_ACCOUNT_ID}}:role/XXX permissions: id-token: write contents: read jobs: bu
ユニットテストをGitHub ActionsからCodeBuildに移行し、実行時間を35%削減した - Uzabase for Engineers
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
GitHub Actions で OIDC を使用して AWS 認証を行う
毎回ググってるので備忘録。 Google Cloud はこっち。 概要 GitHub Actions では OpenID Connect (OIDC) がサポートされています。 OIDC を使用することにより長期間有効なアクセスキーなどを用意することなく AWS 認証を行うことができます。 詳細については下記ページをご参照ください。 この記事では GitHub Actions で OIDC を使用して AWS 認証を行うまでの手順をまとめます。 リポジトリ この記事内で使用しているサンプルコードは下記リポジトリで管理しています。 手順 1. ID プロバイダを作成する まず OIDC に使用する ID プロバイダを AWS で作成します。 Terraform で作成する場合のサンプルコード data "http" "github_actions_openid_configuration"
GitHub ActionsでECS自動デプロイ環境を構築する（DBのmigrate処理まで） - Qiita
Github ActionsでECSにデプロイする構成自体はかなり多くの記事が出回っているので苦労はしないと思うのですが、IAMのキーの運用についてや、migrateタスクを自動で更新してコンテナを立ち上げて動かすのに少し時間がかかったので、網羅的にまとめておこうと思い、記事を書きます。 この記事の内容 IAMの作成(Assume Role) GitHubActionsの設定ファイルの書き方 GitHub Actions参考ドキュメント https://github.com/aws-actions https://github.com/aws-actions/amazon-ecr-login https://github.com/aws-actions/configure-aws-credentials https://github.com/aws-actions/amazon-ecs-d
AWSを使ったクラウドUnityビルド環境の構築～GitHub Actions構築編～ - Activ8 Tech Blog
エンジニアの岡村です。この記事は以前掲載した『AWSを使ったクラウドUnityビルド環境の構築～ビルドサーバー構築編～』の続編であり、シリーズの3記事目です。 synamon.hatenablog.com synamon.hatenablog.com また、インフラメンバーの黒岩さんに書いていただいたビルドサーバー構築編の補足になる記事もどうぞ。 synamon.hatenablog.com これまでで作ったもの ライセンスサーバー構築編ではUnityのフローティングライセンスを管理するサーバーを建て、ビルドサーバー構築編ではUnityがインストールされたマシンのAMI及び、それを利用してビルドトリガーに応じてSelf-Hosted Runnerを起動するよう設定しました。 その結果、以下の画像のような環境が構築されています。 今回はこの環境を利用して、Unityプロジェクトをgitのリモ
AWSを使ったクラウドUnityビルド環境の構築～ライセンスサーバー構築編～ - Activ8 Tech Blog
エンジニアの岡村です。 最近まで、弊社でのUnityを使ったクライアント開発では、社内の物理サーバーに立てたgitとJenkinsを使ってバージョン管理及びCIを行っていました。GitHubは主にサーバー開発に使われており、Unityのコードは検証用のような小さなものを置いている位の状態でした。 しかし、UnityプロジェクトのGitHubでの管理が本格的に始まり、それに合わせてCI/CD環境もクラウド上に構築する機運が高まってきました。 この機会にCIの構成を見直し、より便利なUnityクライアントのCI環境の構築を目指して試行錯誤したので、何回かに分けてその内容をお届けしたいと思います。 Unityのフローティングライセンス Unityには通常のユーザーID, パスワード, シリアルナンバーで認証するライセンスのほかに、ライセンスサーバーを自分で建ててそこにライセンスを登録し、クライア
AWSを使ったクラウドUnityビルド環境の構築～ビルドサーバー構築編～ - Activ8 Tech Blog
エンジニアの岡村です。この記事は以前掲載した『AWSを使ったクラウドUnityビルド環境の構築～ライセンスサーバー構築編～』の続編であり、シリーズの2記事目です。 synamon.hatenablog.com 前回の記事ではEC2を使ってライセンスサーバーを作成したので、そこに接続してライセンス認証をしてビルドを行うWindowsマシン(self-hosted runner)をAWS上に作っていきます。 UnityのCI事情 Unityを使ってCIを行おうとしたときにまず当たるのが、世のCIサービスのUnity対応の渋さです。サービス側がホストしてくれているマシンにUnityがインストールされている事はまずなく、エディタの処理もサイズも軽いわけではないのでデフォルトで用意されている非力なマシンに毎回ダウンロード、インストールして動かすとかなりの無駄が発生してしまいます。公式が提供しているU
CircleCI-AWSをOIDC認証で連携する際のTips
2022年3月26日に待望のCircleCI OIDCサポートがリリースされました。 よーしブログ書くぞと思ったらクラメソさんが先に記事を投稿していたので、実際に自分が試したところをTipsとして記載します。 Terraformでの実装 OIDC Provider まずはOIDC Providerの定義から。 resource "aws_iam_openid_connect_provider" "circleci" { url = "https://oidc.circleci.com/org/${local.circleci_org_id}" client_id_list = [local.circleci_org_id] thumbprint_list = [ "9e99a48a9960b14926bb7f3b02e22da2b0ab7280", ] } locals { circlec
CircleCI が OIDC をサポート！ 永続的な AWS Access Key を廃止できる！
GitHub Actions は以前から OpenID Connect を用いた Cloud Provider への認証が可能でしたが、先日、ついに CircleCI も OIDC をサポートしました 🎉 これにより、AWS で発行する永続的な Access key を廃止することが可能になります！ 利用方法 1. CircleCI の Contextを作成する & Organization ID を確認する 1.1 Context の作成 今回のために AWS 用の Context を作成しましょう。 （環境変数の設定は後ほど行います。） 1.2 Organization ID の確認 CircleCI の Organization ID は https://app.circleci.com/ の Organization Settings > Contexts から取得できます。 （
GitHub ActionsでオープンデータをS3にアップロードしてLambdaで処理する
先日、GitHubで公開しているオープンデータを AWS内で処理する設定を行いました。 その過程を若干一般化して投稿したいと思います。 AWS側の処理はオープンデータをS3にアップロードして、Lambdaで実行する流れになります。 S3へのアップロードをトリガーにLambdaを動かすこともできますが、既にファイルパスを渡すとS3のファイルを取得して処理するものを作成していますので、S3へのアップロード後にGitHub側からLambdaを呼び出すことにしました。 概要 GitHub Actions で AWSのリソースを使えるようにするには、AWS側とGitHub側双方に設定が必要です。 具体的には以下の設定が必要になります。 Amazon Web Service 設定 1-1. IDプロバイダ追加 1-2. IAMロール作成 1-3. IAMポリシー作成 GitHub 設定 2-1. シー
Github ActionsでAWS CDKの自動Pull Request生成に挑戦した話
概要 趣味の開発でよくAWS CDKを利用してAWSの各種サービスを構築することが多い AWS CDKはインフラやCloud Formationの知識が少なくとも、好きな開発言語を使ってAWS環境を構築できるため、非常に優秀なソリューションであると感じる しかし、AWS自体の進化速度が非常に速く、これに劣らずAWS CDKも頻繁にアップデートされる(週１くらいでどんどんバージョンが上がる) https://github.com/aws/aws-cdk/releases 従来は、「気づいたときに」以下のように適宜手動でアップグレード対応をしていた AWS CDKは好きな言語で開発できるが、いくつか試してみてTypeScriptが書きやすいため好んで使っている TypeScriptの場合、package.jsonでCDKのバージョンを管理するが、これをアップグレードするために npm-chec
コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう ! ~コンテナ利用者に捧げる AWS Lambda の新しい開発方式 ! ~ 第 6 回 - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは、サーバーレス スペシャリストソリューションアーキテクトの下川 (@_kensh) です。 「第 1 回 コンテナ Lambda の ”いろは”、AWS CLI でのデプロイに挑戦 !」では、AWS CLI を使ってコンテナ Lambda 関数を実際に AWS Lambda サービスにデプロイして動作確認をしてみました。 「第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !」では、開発者のローカル環境でコンテナ Lambda 関数の動作確認をする方法を紹介しました。 「第 3 回 コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !」では、コンテナイメージサポート Lambda 関数のカスタムイメージ作成方法について紹介しました。 「第 4 回コンテナ Lambda を AWS SAM でデプロイしよう !」
コンテナ Lambda の CI/CD パイプラインの考え方 ~コンテナ利用者に捧げる AWS Lambda の新しい開発方式 ! ~ 第 5 回~ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは、サーバーレス スペシャリストソリューションアーキテクトの下川 (@_kensh) です。 「第 1 回 コンテナ Lambda の ”いろは”、AWS CLI でのデプロイに挑戦 !」では、AWS CLI を使ってコンテナ Lambda 関数を実際に AWS Lambda サービスにデプロイして動作確認をしてみました。 「第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !」では、開発者のローカル環境でコンテナ Lambda 関数の動作確認をする方法を紹介しました。 「第 3 回コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !」では、コンテナイメージサポート Lambda 関数のカスタムイメージ作成方法について紹介しました。 「第４回コンテナ Lambda を AWS SAM でデプロイしよう !」では、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS for GitHub Actions
