Dockermorishitaです。ランタイムを変更したら余計にハマったという話です。本題に入る前にアクトインディでのCodeBuildの利用状況を紹介します。主な用途は次のとおりです。本番サービス用DockerイメージのビルドはCodePipelineに組み込まれています。開発環境用DBイメージというのは、毎日本番DBのバックアップをリストアして作っているものです。各エンジニア、デザイナーがローカル開発環境で使うもので、プルすればほぼ最新の本番データをローカル環境で動かせます1。自動テストについては次のエントリで紹介しています。tech.actindi.nettech.actindi.netランタイムを最新にしたら動かなくなった!さて、本題です。Webpacker+Workboxの設定変更をしていてローカル環境での実行ではうまく設定どおりに動作するのですが、本番適用するためDockerイメージをビルドするとうまく動作しないという事象を調べていました。設定の仕方やコマンドの実行順序、実行タイミングなどいろいろ試してみましたがうまくいかず困っていました。Dockerイメージのビルド中の処理なのでCodeBuildのランタイムが原因であることは冷静に考えれば少ないはずです。うまくいかない原因を見つけられず焦ってしまい実行環境を疑ってしまいました。設定を確認すると利用しているイメージがaws/codebuild/docker:17.09.0となっていました。「まさかこれが原因?」と思って変更しようとしました。イメージの上書きをクリックして見ると...。仕様が変わっていたCodeBuildの環境設定あれ、しばらく触ってなかったら設定項目が変わっている。なにより、イメージのバージョニング体系が変わっている。些細な仕様変更だろう。最新を選択すればいいだろうと次の様に設定を変更してしまいました。aws/codebuild/standard:2.0-1.11.0で、再度CodeBuildを実行すると、エラーで止まってしまいました。ビルド失敗11秒で止まっているとは実質起動すらしてない様子。もとに戻すという退路も絶たれていました。うわー、余計にハマった!もともとサクッと終わる瞬殺タスクだと思っていたのに...。buildspec.ymlに変更が必要だったログを見てみると次のエラーメッセージが出ていました。version.ふむふむ、ランタイムバージョンを少なくとも1つしてする必要があるらしい。ドキュメントを確認してみると次の様に変わったようです。以前は、Ruby、Node.js、Dockerなど使いたい言語やツールごとにイメージが用意されていたと思います。指定するように変わったようです。ドキュメントには次の様に書かれています2。セクションでランタイムを指定できます。「指定できます」と書かれていますが、先のエラーメッセージを見ると1つは「指定しなければならない」ようです。選択できるランタイムのバージョンは次のとおりです。次のように設定を追加しました。Dockerイメージ作る場合にはCodeBuildの環境設定の特権付与にチェックを入れるのも重要です。これにチェックを入れないとDockerが動きません。これで元通り動くようになりました。まとめ新しいCodebuildのランタイムイメージのDockerファイルはGithubで公開されています。2.0を選択したほうがいいと思います。変更も必要なのでご注意を。CodeBuild最後にアクトインディではエンジニアを募集しています。actindi.net“ほぼ"というのは1日1回ビルドなので若干タイムラグがあるのと、メアドなどのセンシティブなデータはマスクされているという意味です。レイヤーキャッシュのハマったことこんにちは、キエンです。現在、いこレポにてCodeBuildを使用...2019-04-06Prontoでソースレビュー自動化はじめまして。