metadata=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI})

export AWS_ACCESS_KEY_ID=$(echo "${metadata}" | jq -r .AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo "${metadata}" | jq -r .SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo "${metadata}" | jq -r .Token)

mkdir .docker && echo "{\"credsStore\":\"ecr-login\"}" > .docker/config.json

docker run \
  -v $(pwd):/workspace \
  -v $(pwd)/.docker:/kaniko/.docker \
  -e AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
  -e AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
  -e AWS_SESSION_TOKEN=${AWS_SESSION_TOKEN} \
  gcr.io/kaniko-project/executor \
  -d ${ECR_REPO}

エンドポイントや環境変数の渡し方などは以下の記事が参考になる．

qiita.com

dev.classmethod.jp

docs.aws.amazon.com

gcr.io/kaniko-project/warmerを使えるようにする

これだけでもkanikoを使ったビルドができるようになるが，これに加えてkaniko-project/warmerを使うことで，ビルドする際のベースイメージのキャッシュが効くようになり，ビルド時間の短縮を狙うことができる．

以下のように書くことで，環境変数BASE_IMAGESにキャッシュを効かせたいイメージを書くことで，ホストの/cacheディレクトリにベースメージのキャッシュを保存することができる．

images=$(echo ${BASE_IMAGES} | perl -anal -e 'print join(" ", map {"--image=" . $_ } split ",")')

docker run -v /cache:/cache gcr.io/kaniko-project/warmer --cache-dir=/cache ${images}

そしてこのディレクトリをCodeBuildがキャッシュするようにbuildspec.ymlを書き換えれば良い．

BASE_IMAGESには複数のイメージを書くことができ，例えばgolang:1.10,alpine:latestを渡すと，$imagesの内容は--image=golang:1.10 --image=alpine:latestとなる

その他の注意点

気をつけないといけないのはまず，CodeBuildのビルド環境に特権付与が必要ということ．

特権を付与しないとdocker run自体を実行することができずに，

docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.

と言われてしまう．

また，docker runする際に，gcr.io/kaniko-project/executorやgcr.io/kaniko-project/warmerのイメージが必要になってくるため，これらのイメージ自体をキャッシュするためにはCodeBuildのレイヤキャッシュも有効にする必要がある．

つまりは基本的にCodeBuildのローカルキャッシュは全部有効にしておけば良い．

buildspecとCloudFormationテンプレート

以上を踏まえて，完成したbuildspec.ymlはこのようになった．

version: 0.2

phases:
  install:
    runtime-versions:
      docker: 18
  build:
    commands:
      - metadata=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI})
      - export AWS_ACCESS_KEY_ID=$(echo "${metadata}" | jq -r .AccessKeyId)
      - export AWS_SECRET_ACCESS_KEY=$(echo "${metadata}" | jq -r .SecretAccessKey)
      - export AWS_SESSION_TOKEN=$(echo "${metadata}" | jq -r .Token)
      - images=$(echo ${BASE_IMAGES} | perl -anal -e 'print join(" ", map {"--image=" . $_ } split ",")')
      - mkdir .docker && echo "{\"credsStore\":\"ecr-login\"}" > .docker/config.json
      - |
        docker run \
          -v /cache:/cache \
          gcr.io/kaniko-project/warmer \
          --cache-dir=/cache \
          ${images}
      - | 
        docker run \
          -v $(pwd):/workspace \
          -v $(pwd)/.docker:/kaniko/.docker \
          -v /cache:/cache \
          -e AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
          -e AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
          -e AWS_SESSION_TOKEN=${AWS_SESSION_TOKEN} \
          gcr.io/kaniko-project/executor \
          --cache=true \
          --cache-dir=/cache \
          --cache-repo ${ECR_REPO} \
          -d ${ECR_REPO}:${ECR_TAG}
cache:
  paths:
    - /cache/**/*

CodeBuildのキャッシュでカスタムキャッシュを有効にしていれば，/cache以下の内容を保持し，次回以降のビルドが高速化される．

以上の構成を動かすCloudFormationテンプレートは以下から利用できる．

github.com

以上の形で，結構複雑ではあるけれど，キャッシュを利用できるような形でkanikoを使うことができるようになった．

2019-06-10

kanikoをAWS CodeBuildで使う

最近kanikoの話題を見るようになってきて，どういう動作をするのかなと気になり触ることにした．

普段はGCPではなくAWSの方を使っているのもあり，CodeBuildの方でもkanikoを使えないかと試してみたメモ．

動かすまでに試した記録と動作するサンプルリポジトリを以下に書いていく．

gcr.io/kaniko-project/executorはCodeBuildでは利用できない

まずハマったこととして，公式で提供されているイメージはCodeBuild上で動かすには様々な問題があり，利用することができない．

そのハマった点とその対処を順に書いていく．

CodeBuildではscratchイメージを動かすことができない

CodeBuildのベースイメージとしてgcr.io/kaniko-project/executorを指定すると．以下のようなエラーが出てしまい実行することができない．

SINGLE_BUILD_CONTAINER_DEAD: Build container found dead before completing the build. Build container died because it was out of memory, or the Docker image is not supported*1

いくつか実験してみると，これはexecutorのイメージがscratchベースであるためだということがわかり，おそらくCodeBuildの実行に必要なものが何か揃っていないと考えることができる．*2

kanikoにはgcr.io/kaniko-project/executor:debugというshellとbusyboxが追加で入ったイメージも用意されているが，こちらも同様にエラーになってしまい使うことができない．

alpineイメージは以前にCodeBuild上で動作することを確認していたため*3，今回も最終イメージをalpineに変更することで回避することができた．

CodeBuildで動かすためのPATHが不十分

利用するイメージをalpineに変更したところ，今度は以下のような別のエラーが発生した．

Internal Service Error: CodeBuild is experiencing issues

このエラーでGoogle検索しても1件しかヒットせず，しかもあまり参考にならないと思われる情報*4だったため，しばらくは解決方法がわからない状態だった．

そんな中，executorのDockerfileを見るとPATHに/usr/local/bin:/kanikoしか書いていない*5という事に気づき，もしやと思って/binと/usr/binを追加したところ動作するようになった．

以上の対応を踏まえて，CodeBuildで動かすことのできるkanikoのalpineベースのイメージを作成した．

https://hub.docker.com/r/cohalz/kaniko-alpine

公式イメージの中身をそのまま持ってきているのもあり，公式イメージの代わりとしてCodeBuild以外でも使うことができる．

また，公式のdebugイメージと同様にshellやbusyboxも使えるようになるのでデバッグ時に便利である．

docker run -v $(pwd):/workspace -it --entrypoint="" cohalz/kaniko-alpine sh

実行コマンドをCodeBuildの形式に合わせる

GCPのCloud Buildでは実行したいコンテナとその引数を書いていく形式*6なのに対し，AWSのCodeBuild(や他のCIサービス)は実行環境がコンテナの内部になるほか，その環境で実行したいシェルスクリプトを書くという形式*7になっている．

そのため，CodeBuildで実行する際には，Cloud Buildで指定した引数の前にコマンド名である/kaniko/executorと，コンテナ内で実行するということで--forceオプションの2つを追加する必要がある．

つまり，CodeBuild上でビルドできるか確認するための最低限のbuildspec.ymlはこうなる．

version: 0.2

phases:
  build:
    commands:
      - /kaniko/executor --force --no-push"

CodeBuildからECRにpushできるようにする

上のを踏まえ，buildspec.ymlをこのように書くことでECRにpushできるようになる．

version: 0.2

phases:
  build:
    commands:
      - echo "{\"credsStore\":\"ecr-login\"}" > /kaniko/.docker/config.json
      - /kaniko/executor --force -d "${ECR_REPO}"

コマンドの一行目はECRへプッシュする際に必要で，kanikoではECRへプッシュする際には/kaniko/.docker/config.jsonのcredsStoreもしくはcredHelpersにECRを使えるような変更が必要なための対応になる．*8

ECRの認証はCodeBuildのロールを使うため，そのロールにECRへpushする権限も必要．

CodeBuildの動作確認用のリポジトリ&CloudFormation

CodeBuildで動作するkanikoイメージを作ったので，動作確認がしやすいようにサンプルプロジェクトとCloudFormationテンプレートを作ってみた．

github.com

リポジトリにあるexample/using-kaniko-image/template.ymlファイルをデプロイすることで，このリポジトリにあるDockerfileをkanikoを使ってビルドしECRにpushするという動作を確認することができる．

実行するとこのようにCodeBuildのビルドログがkanikoの表示になっているのが確認できる．

f:id:cohalz:20190610003852p:plain — CodeBuildのコンソール画面

終わりに

動かすまでが意外と大変だったけど，終わってみると結構簡単に使えるようにできたので良かった．

CodeBuildはローカルやS3のキャッシュも使えるのでkanikoとの相性もいいと思う(権限もCodeBuildのロールで制御できる)．

CodeBuildは元からBuildKitも利用できるので，kanikoとBuildKitのどちらを使うか適材適所で選んでいけると良いと思う．

*1:公式のトラブルシューティング: https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html#windows-server-core-version

*2:AWSのドキュメントにそのような記述は見つからなかったが

*3:https://developer.hatenastaff.com/entry/2019/04/16/130000

*4:https://forums.aws.amazon.com/thread.jspa?messageID=884916&tstart=0

*5:https://github.com/GoogleContainerTools/kaniko/blob/9f65174cb8391e01b4fbeda178d0e9b63dcabd75/deploy/Dockerfile#L38

*6:https://cloud.google.com/cloud-build/docs/build-config?hl=ja#build_steps

*7:https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html#build-spec-ref-example

*8:内部では amazon-ecr-credential-helperを使っている

2019-06-02

s3 syncを定期実行するDockerイメージを作った

Docker AWS

リポジトリは以下．イメージはcohalz/cron-s3-syncで利用可能．

github.com

以下のように実行するとyour-bucketというS3バケットにあるファイル群を/tmp/dir/ 以下に同期することができる．

docker run --init \
  -e "AWS_ACCESS_KEY_ID=xxxxxxxxxx" \
  -e "AWS_SECRET_ACCESS_KEY=xxxxxxxxxx" \
  -e "S3_BUCKET=your-bucket" \
  -e "LOCAL_DIR=/tmp/dir/" \
  -e "SYNC_TYPE=PULL" \
  cohalz/cron-s3-sync

同期は毎分実行され，変更のあったファイルだけが更新される．

逆にS3へバックアップしたいときにはSYNC_TYPE=PUSHとすることで，毎分S3へ同期させることができる．

主な用途として，別のコンテナで使うファイルを更新させたい場合に使える．このコンテナをサイドカーとして動かしボリュームを共有することで，その別のコンテナには手を加えずS3経由でファイルを更新することができる．

例えばEnvoyのDynamic configurationではファイルの更新を検知して再読込ができる*1ので，設定変更がEnvoyコンテナの入れ替えやコントロールプレーンの実装なしに実現できるようになる．*2

*1:公式ドキュメント: https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol.html#filesystem-subscriptions

*2:Envoyのファイルベースによる設定更新についてのブログ記事: https://medium.com/grensesnittet/file-based-dynamic-configuration-of-routes-in-envoy-proxy-6234dae968d2

2019-04-01

株式会社はてなに入社しました

id:cohalzです．2018年8月付で株式会社はてなに入社しました．

職種はSRE (Site Reliability Engineer) で，勤務地は京都です．

株式会社はてなに入社しました - hitode909の日記

まえがき

はてなとの出会いは、2017年のはてなインターンに参加したことがきっかけでした。はてなインターンの特徴の一つに、ほとんどの参加者が参加したときの内容をブログ記事として書いていることがあります。インターン参加記事には、技術やWebに対する大きな熱量がこもっており、すっかり自分もWeb技術をやっていくのだと感化されました。ダメ元で選考に望んだところ、運良く選考通過のお知らせをいただいてとてもうれしかったことを今もよく覚えています。そこから毎年インターンの参加者をみてきていますが、とてもハイレベルで、よく自分が選考通過したものだと今でも思います。この出来事が自身の人生にとって大きな転機だったと言えるでしょう。

インターンの2ヶ月後にアルバイトスタッフとして入社し、配属されたのは、はてなのITインフラを担当するシステムプラットフォーム部という部署でした。今でこそ当たり前のようにSREのような基盤技術を専門としていますが、当時はサービス開発をするアプリケーションエンジニアを志望していました。しかし、システムプラットフォーム部での仕事を通して、サーバがたくさんあってそれらが相互に通信してひとつの系をなすというWebシステムに魅せられ、今でいうところのSREを志しました。インターン中に行われたid:masayoshi さんによるインフラ講義に感銘を受けたことも影響しています。はてなでインフラ研修を受けました - Re:cohalz の記事にて、アルバイト時代に、何を学んだかを書いています。そこから新卒で内定をいただいたにも関わらず、大学院を中途退学してしまいましたが、その後も快く受け入れてくださったはてなにはとても感謝しています。*1

正社員として入社してから既に半年以上，アルバイトを含めると1年以上はてなで働いていたので，この機会に振り返ってみようと思います．

アルバイト時代

アルバイトとして入社した2017年11月時点では，ミドルウェア，Linux，クラウドサービスのことは何もわからない状態でした．

そんな中，最初にアサインされたタスクはLet's Encrypt証明書を自動で取得・更新するという基盤作成のタスクでした．

このタスクをアサインされた当時の状態でわからないことで言うと，

Let's Encryptって怪しいものだと思っていた．
AWS CLIはおろかAWS自体何一つ触ったこと無い
- 何をしたらどういった変化が起こるのかわからず，とにかく操作が怖い
webサーバってどうやって立てるの？
- セキュリティグループってやつで80番開放したら立つのかと思ってた
- nginxはなんて読むのかは知ってるけど何なのか知らない

と言うレベルで，とにかく1から進めていきました．

そんな状態で本当にやっていけるのか，もちろん不安ではありました．

しかし，所属していたチームの座談会を見たところ，その不安はなくなりました．

hatenacorp.jp

この記事では，当時アルバイトメンターをしてくれていた id:dekokun さんや，まだ新卒入社して年数の経っていない id:taketo957 さんや，雲の上の存在だった id:y_uuki さんまでも昔からインフラに詳しいわけではなかったという事実が助けになりました．