API_URL=https://example.com
BRANCH_API_URL=https://hoge.com
host ${BRANCH_API_URL#https://} && API_URL=${BRANCH_API_URL} || :
${BRANCH_API_URL#https://} で、環境変数 BRANCH_API_URLの先頭の https:// を取り除いているhost は引数のドメインが無い場合、異常終了するコマンド: は何もしないコマンドhost が正常終了すれば、 API_URL には、BRANCH_API_URL が格納されるhost が異常終了すればなにもしない(結果として、API_URL はデフォルトの https://example.com のままbuildspec に以下を追加
phases:
install:
commands:
- yum -y install bind-utils
bind-utils でまとめてインストールされるinstall phase で実行するFARGATE SPOT のみにする
さっき止めるまで80時間ぐらい、10タスク中1つも落ちませんでした。FARGATE_SPOT、マジで今は東京リージョン使い放題です。 https://t.co/qDIX3vu2wo
— 濱田孝治（ハマコー） (@hamako9999) 2019年12月12日
ECS の Capacity Provider を FARGATE SPOT のみにする
ECSのクラスターの実行環境。Fargete ならば FARGATE と FARGATE SPOT がある
FARGATE を消してしまえば、 Capacity Provider は FARGATE SPOT のみなので、全ての task が Fargate Spot で実行されるもし、 FARGATE と FARGATE SPOT を併用したい場合、Capacity provider strategy という設定で、task実行時の Capacity Provider の配分を決めることができる
AWSとSaaSを統合するために、AWSで発生するイベントを他のAWSサービスやSaaSと紐付けるサービス
Amazon EventBridge は、独自のアプリケーション、統合 Software-as-a-Service (SaaS) アプリケーション、および AWS のサービスからのデータを使用して、アプリケーションを簡単に接続することを可能にするサーバーレスイベントバスです。
大規模に素早く pub/sub したい場合は SNS。いろいろなサービスと手軽に繋がりたい場合は、EventBridge という感じらしい
- name: Slack Notification when build failed
if: failure()
uses: rtCamp/action-slack-notify@master
env:
SLACK_CHANNEL: channel-name
SLACK_COLOR: '#ff0000'
SLACK_TITLE: ':fire::fire::fire: Build error! :fire::fire::fire:'
SLACK_MESSAGE: "Build error! Please check github!"
SLACK_USERNAME: GitHub Actions
SLACK_WEBHOOK: ${{secrets.SLACK_WEBHOOK}}
if: failure() で失敗した場合のみ起動するstepを設定できる
rtCamp/action-slack-notify@master は、slack通知のGitHub Action
GitHub Actionsでは、ブランチ名は環境変数 GITHUB_REF から取ることができるが、ブランチ削除時には GITHUB_REF が refs/heads/master になってしまう
${{ github.event.ref }} から取得する
webhook event のペイロードがすべて格納されているところ
ブランチ削除の場合のペイロードはこちらを参照
name: delete_branch
on: [delete]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Echo branch name
run: echo ${GITHUB_REF}
- name: Echo commit hash
run: echo ${GITHUB_SHA}
- name: Echo github.event.ref
run: echo "${{ github.event.ref }}"
こちらのつづき
aws-actions/configure-aws-credentials を GitHub Actions に組み込む"hello" を puts するだけのシンプルな lambda hello を us-east-1 に作成
require 'json'
def lambda_handler(event:, context:)
# TODO implement
puts 'hello'
{ statusCode: 200, body: JSON.generate('Hello from Lambda!') }
end
github-actions を作成$ aws iam create-user --user-name github-actions
{
"User": {
"Path": "/",
"UserName": "github-actions",
"UserId": "********",
"Arn": "arn:aws:iam::********:user/github-actions",
"CreateDate": "2020-03-03T05:02:59Z"
}
}
github-actions に lambda実行権限持つロールを付与$ aws iam attach-user-policy \ --user-name github-actions \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaRole
$ aws lambda invoke --function-name hello --region us-east-1 response.json
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
aws-actions/configure-aws-credentials を GitHub Actions に組み込むaws-actions/configure-aws-credentials は AWS 公式の github action
Configure AWS credential and region environment variables for use in other GitHub Actions.
こんなふうに、アクセスキーとシークレットキーとリージョンを設定してやれば、ユーザの権限に応じた、AWS CLI が使えるようになる
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Run a one-line script
run: echo Hello, world!
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
GitHub Actionsで使用したい秘匿情報は、secrets に設定して、そこから取得する
$aws iam create-access-key --user-name github-actions
{
"AccessKey": {
"UserName": "github-actions",
"AccessKeyId": "********",
"Status": "Active",
"SecretAccessKey": "********",
"CreateDate": "2020-03-03T05:03:23Z"
}
}
secrets に設定することで、GitHub Actions にて ${{ secrets.key_name }} で参照できるようになる
settings -> secrets で設定可能
ここに、AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を設定する
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Run a hello lambda
run: aws lambda invoke --function-name hello response.json
コードをPUSHして、GitHub Actions から lambda が実行されて、正常終了の結果が返ってきたことを確認 👏
GitHub の特定のアクションをトリガーにCI/CD的なことを実行できるサービス
Githubのリポジトリから「Actions」を選択
いろんなActionをサジェストしてくれるけど、今回は Simple workflow を選択
すると、 .github/workflows/blank.yml にファイルが生成される
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello, world!
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
公式ドキュメントを参照
ざっくりこんなかんじ
name : 名前on : 発火するイベントjobs : イベント発火時に実行する処理を格納するところjobs.<job_id> : イベント発火時に実行する処理。<job_id> は buildjobs.<job_id>.runs-on : 実行環境。windowsとかMacOSもあるjobs.<job_id>.steps : 実行する処理jobs.<job_id>.uses : ジョブのステップの一部として実行される外部のアクション。公開リポジトリなどを参照できる。今回の場合 https://github.com/actions/checkout が実行されるjobs.<job_id>.name githubに表示されるステップの名前jobs.<job_id>.run ステップで実行される処理。runs-on で指定したOSでコマンドラインが実行されるコードを commit すると早速アクションが実行される
step単位で処理が実行されているのが分かる
ざっくりそんなかんじ
