Github Actions

暇だから調べる。寝る前に。

GithubActions Deploy, Continuous Integrationなどのもろもろの役割を引き受けることができるツール。 最終的にはCI以上の役割を目指していそうな印象。

とりあえず、yamlのdocumentがすぐ出てこないことが辛かった。 https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onevent_nametypes

GithubActionのECSのTemplateWorkflowを少しずつ読み解いていく。

on:
  push:
    branches:
      - 'feature/deploy'

On

何をいじったら発火するのかの箇所。

branch, push, pull_requestなどなど色々設定できる。ここを調べているうちにgithubのreleaseの機能について深く知ることになる。 scheduleを設定するとcronみたいに動かせるみたい。

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v2

Jobs

実際に何を動作として期待するのかなどなど。steps以下に実際に挙動を追加していくみたい。usesには予めDockerImageで定義されているTemplate のWorkflowが入るみたい。ここで別々の環境で動いているから環境変数などが引き継がれないんだろな。

Fargate

fargateでのサーバーの起動を想定する。必要なものは4つ。 repository, service, cluster

task-definition

Githubdでjson形式で管理するのが一般的みたい。Imageのlatestタグとかを使って管理するのはrollbackとかの処理に向いていないからしないほうが良いらしい。 まあ確かにentry commandとか変わるかもしれないし、理にはかなっているが... serverのrepoにinfrastructureのコマンドをできるだけ入れたくないというお気持ちもある。

ref: https://github.com/aws-actions/amazon-ecs-deploy-task-definition

AWSからダウンロードしてそれを使うこともできるみたい。普通にこっちのほうが良さそう。Infrastructureのコードを同じ場所に置くのはやっぱり気持ち悪い。 折角Containerに格納できるならするべき。

はまったポイント

executionRoleArn: null

uploadしたdefinition.jsonのexecutionRoleArnが永遠にnullになってハマった... 結局ecsTaskExecutionRoleみたいにarnでなくともその名前を入れておけばUploadするときに自動で入れてくれるみたい。

参考

https://aws.amazon.com/jp/blogs/opensource/github-actions-aws-fargate/ https://github.com/aws-actions/amazon-ecs-deploy-task-definition