社用PCと私用PCでChromeのprofileを別にした

今までは利便性のために社用PCと私用PC両方ともGoogleの個人アカウントと社内アカウント両方ログインしていたのだけれど,最近社用PCには個人アカウントをログインしないようにした.

最初はオンオフをしっかり切り分けたいという意図があったのだけれど,意外といろいろな気づきがあった.

例えば,

  • ブックマークを分離できる
    • 今まではTwitterやらGitHubやら仕事と趣味でアクセス頻度の高いものが両方ブックマークされていたけれど,仕事・趣味で分けられる
  • 社用PCでデフォルトのGoogleアカウントを仕事用にできる
    • 権限周りとかたまにハマることがあったのがなくなる
  • 閲覧履歴が混ざらない
    • 私用PCに会社関連の履歴が残らない
    • 社用PCに趣味活動の履歴が残らない

などなど結構メリットがある.

あとブックマークの他に拡張もリセットされるので結構新鮮な気持ちでセットアップできるというのも面白かった.

社用PCのブクマからTwitterを消したのでますますTLを見る機会は減りそうという話もあったりする.

とここまで書いて世の中の人間は当たり前にprofile分けているんだろうかと思ったけどどうなんだろうか.

異動した

8/1付で異動があり,はてなブログのチームに配属になった. 職種としては引き続きSREになっている.

以前はシステムプラットフォーム部というチームにいて,名前の通り社内の基盤を見るなどを行っていた.

developer.hatenastaff.com

developer.hatenastaff.com

developer.hatenastaff.com

こういったように,今までは作ったシステムは社内の人に利用してもらうという感じだった.

これからは,はてなブログというプロダクトに関わることでよりユーザに近いものを作っていくことになる.

直近で言えばこの前に予告された「はてなブログ タグ」の開発に,異動のしばらく前から関わっている.

staff.hatenablog.com

タグやはてなブログの今後にご期待ください.

それと,開発だけではなくドッグフーディングのためにもっとブログを書いていきたい.

余談

入社したのは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の話題が出て興味を持ったのが最初でした.

そこからいくつかのライブラリを作成したり,本番導入を行ったりしました.

そして今月にめでたく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する方法を書いた.

core.cohalz.co

今回は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}

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

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/executorgcr.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を使うことができるようになった.

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.jsoncredsStoreもしくは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のどちらを使うか適材適所で選んでいけると良いと思う.

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

リポジトリは以下.イメージは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