やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このテキーラはサービスだから、まず飲んで落ち着いて欲しい。
うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。
でも、このスレタイを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、このスレを立てたんだ。
じゃあ、注文を聞こうか。
めでたい
はてなインターン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を使うことができるようになった．
