冬も終わりですね
写真は谷川岳ロープウェイからの谷川岳です
f:id:swx-yamamoto:20220319122810p:plain

前提

AWS の Code系サービスを使ったソースコード管理・ビルド(コンパイル)・デプロイ(環境への展開) は
基本的に以下の図のようになります

f:id:swx-yamamoto:20220319110211p:plain 正式なサービス名：
AWS CodeCommit 、AWS CodeBuild 、AWS CodeDeploy、AWS CodePipeline

やろうとしたこと

一度ビルドした結果ファイルをCodeBuild にキャッシュしておきビルド時間を短縮する
- AWS CodeCommit のソースコードを毎回全てビルドする必要はない
  - 毎回のビルドが不要なバイナリを最初のビルド時にCodeBuild にキャッシュしておき全体のビルド時間を短縮する

f:id:swx-yamamoto:20220319111251p:plain

CodeBuild にキャッシュする方法

AWS公式ドキュメントに記載のあるキャッシュ方法としては以下の 2種類があります

Amazon S3 にキャッシュ
CodeBuilがビルドする際に使用するホスト上にキャッシュ(ローカルキャッシュ)

ドキュメント：AWS CodeBuild でのキャッシュのビルド - AWS CodeBuild

図に示すと以下のようになります
f:id:swx-yamamoto:20220319115721p:plain

「1. Amazon S3 にキャッシュ」を選択する際の注意点としまして
CodeBuild が S3 にキャッシュしたファイルを S3 からネットワーク経由でダウンロードします
そのためビルドする時間よりもダウンロードする時間のほうが短い場合に有効な手段です
キャッシュしたファイルをダウンロードする時間については
ネットワークパフォーマンスやファイルサイズ・数等も関係してくるため
実際に計測してみて判断するしかありません

ローカルキャッシュする際の注意点

「2. CodeBuilがビルドする際に使用するホスト上にキャッシュ(ローカルキャッシュ)」を選択する際の注意点に関して見ていきます
この記事の本題です

f:id:swx-yamamoto:20220319120122p:plain

CodeBuild のビルド処理に前回と同一のホストが割り当てられた場合のみしかキャッシュが効かない

実際に使用してみるとキャッシュが効かないという問題が出ました
そのため AWS サポートに問い合わせたところ以下のような回答を得ました

ローカルキャッシュ機能は使用されない場合がある
- ローカルキャッシュは、前回と同一のホストが割り当てられた場合のみ機能するため、異なるホストが割り当てられた場合は機能しない
  - 同一のホストが割り当てられる条件等は公開していない
  - 同一のホストが割り当てられるようにするオプション等もない
確実にキャッシュを使用できる必要がある場合は Amazon S3 のキャッシュを使用すること

というわけでローカルキャッシュをあてにしない方が良さそうです

検証に使った buildspec.yml

とてもシンプルに検証しました

/yamamoto-temp というディレクトリをローカルキャッシュ用のディレクトリにしました (cache セクション)
ホスト名を出力
/yamamoto-temp/test.txt を ls - l して存在確認 (キャッシュが効いている場合には存在する想定)
/yamamoto-temp/test.txt を作成 (既に存在する場合にはタイムスタンプを更新)
/yamamoto-temp/test.txt を ls - l して存在確認 (作成したファイルが有ることを確認)

version: 0.2
phases:
  pre_build:
    commands:
      - echo Start
  build:
    commands:
      - uname -n
      - ls -l /yamamoto-temp/test.txt || echo "not cached"
      - touch /yamamoto-temp/test.txt
      - ls -l /yamamoto-temp/test.txt || echo "not created"
  post_build:
    commands:
      - echo Finished
cache:
  paths:
   - '/yamamoto-temp/'