はてなインターン2019ももう終わりに近づいていていろんな成果が出てめでたいな〜と思っている。
社用PCと私用PCでChromeのprofileを別にした
今までは利便性のために社用PCと私用PC両方ともGoogleの個人アカウントと社内アカウント両方ログインしていたのだけれど,最近社用PCには個人アカウントをログインしないようにした.
最初はオンオフをしっかり切り分けたいという意図があったのだけれど,意外といろいろな気づきがあった.
例えば,
- ブックマークを分離できる
- 今まではTwitterやらGitHubやら仕事と趣味でアクセス頻度の高いものが両方ブックマークされていたけれど,仕事・趣味で分けられる
- 社用PCでデフォルトのGoogleアカウントを仕事用にできる
- 権限周りとかたまにハマることがあったのがなくなる
- 閲覧履歴が混ざらない
- 私用PCに会社関連の履歴が残らない
- 社用PCに趣味活動の履歴が残らない
などなど結構メリットがある.
あとブックマークの他に拡張もリセットされるので結構新鮮な気持ちでセットアップできるというのも面白かった.
社用PCのブクマからTwitterを消したのでますますTLを見る機会は減りそうという話もあったりする.
とここまで書いて世の中の人間は当たり前にprofile分けているんだろうかと思ったけどどうなんだろうか.
異動した
8/1付で異動があり,はてなブログのチームに配属になった. 職種としては引き続きSREになっている.
以前はシステムプラットフォーム部というチームにいて,名前の通り社内の基盤を見るなどを行っていた.
こういったように,今までは作ったシステムは社内の人に利用してもらうという感じだった.
これからは,はてなブログというプロダクトに関わることでよりユーザに近いものを作っていくことになる.
直近で言えばこの前に予告された「はてなブログ タグ」の開発に,異動のしばらく前から関わっている.
タグやはてなブログの今後にご期待ください.
それと,開発だけではなくドッグフーディングのためにもっとブログを書いていきたい.
余談
入社したのは2018/08/02なので社会人になってからちょうど1年が経ったことになる.
CDKを使ってECSを構築運用している話をした
7/18に AWS Loftで行われた「AWS Cloud Development Kit -CDK- Meetup」というイベントで登壇ししてきました.
awsclouddevelopmentkitcdkmeetu.splashthat.com
発表スライドはこちらです.
CDKをどうして採用したのかという話や,ECSライブラリを作った話,さらにはECS上でGitOpsを実現するための仕組みとしてCDKを利用した話をしました.
CloudFormationを置き換えるだけでなく,もっと強力な力を持っているということが伝わったら嬉しいです.
はてなでは去年の8月辺りから社内で触り始めている人が現れ,10月あたりで開催された社内勉強会でCDKの話題が出て興味を持ったのが最初でした.
そこからいくつかのライブラリを作成したり,本番導入を行ったりしました.
- GitHub - cohalz/cdk-fluentd-log-driver: experimental: AWS-CDK library for fluentd log driver on ECS
- GitHub - cohalz/cirrocumulus: Library to create an easy-to-use ECS cluster using AWS CDK
そして今月にめでたくGAとなり,今後は様々な利用事例が出てくるのを楽しみにしています.
7月の登壇予定
今月は登壇する機会をいくつか貰ったので,まとめた.
7/6(土) 沖縄学生×企業エンジニア 7月大LT大会!!!
監視の話を10分する予定. connpass.com
7/7(日) Hatena Engineer Meetup #1 in Okinawa
SREと自分のキャリアについての話を15分する予定. hatena.connpass.com
7/18(木) AWS Cloud Development Kit -CDK- Meetup
「CDKを用いたモダンなECSクラスタの構築と運用」というタイトルで話を20分する予定. awsclouddevelopmentkitcdkmeetu.splashthat.com
よろしくお願いします
会場でお待ちしています.
kanikoをAWS CodeBuildで使う その2
前回書いた記事では,CodeBuildのベースイメージとしてkanikoを利用した際のビルド及びECRにpushする方法を書いた.
今回はCodeBuildのイメージを変更せずデフォルトイメージ(aws/codebuild/standard:2.0
)のまま,docker runを使ってkanikoを利用する方法について書いていく.
この方法はCloudBuildでビルドする方法に近く,またgcr.io/kaniko-project/warmer
を使ったベースイメージのキャッシュも利用できるようになるため,実際にCodeBuildでkanikoを利用したい場合にはこちらを利用することが一般的になると思う.
以下では動かすための手順を書いていく.
CodeBuildのロール情報をkanikoのイメージに渡す
kanikoをdocker run経由で実行するということで,そのままではECRにpushする際に必要なIAMのロール情報をコンテナに渡すことができない.
ロール情報をコンテナに渡すための方法としてはCodeBuildからhttp://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}
というエンドポイントを叩き,その結果をコンテナの環境変数として渡すという方法をとれば良い.
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}
エンドポイントや環境変数の渡し方などは以下の記事が参考になる.
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テンプレートは以下から利用できる.
以上の形で,結構複雑ではあるけれど,キャッシュを利用できるような形でkanikoを使うことができるようになった.
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テンプレートを作ってみた.
リポジトリにあるexample/using-kaniko-image/template.yml
ファイルをデプロイすることで,このリポジトリにあるDockerfileをkanikoを使ってビルドしECRにpushするという動作を確認することができる.
実行するとこのようにCodeBuildのビルドログがkanikoの表示になっているのが確認できる.
終わりに
動かすまでが意外と大変だったけど,終わってみると結構簡単に使えるようにできたので良かった.
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を使っている