CircleCIのOrbをCICDに活用すべく試行錯誤した箇所の個人的まとめ
はじめに
CircleCIの特定Orb利用時、実際の動作に至るまで時間が掛かった箇所や、仕様上実現するための使い方についてまとめました。
aws-ecr
以前のエントリーにてaws-cli Orbを使ってDocker Imageをアップしていた箇所をaws-ecr Orbに置き換えてみました。設定がシンプルでメンテナンスコストを減らせる点が大きな理由です。
CircleCI Orb Registry - circleci/aws-ecr
今回のハマりどころは以下の通りです。
IAMユーザを用意する必要がある
パラメータにrole arnを指定する箇所がなく、IAMロールではなくIAMユーザにて設定が必要です。管理コンソール上にて、該当ロールにSwitchした後でIAMユーザを発行します。
発行したIAMユーザにはECRへのアクセス権限の追加が必要となります。Workflowが権限不足だった場合はCircleCIの実行ログに必要なポリシーが出力されます。設定して再実行後、他にもポリシーが必要だった場合はその都度ポリシーを足していきます。
Dockerファイル名指定パラメータにpath指定を混ぜる
Dockerファイル名とDockerファイルのある相対パスの2つを指定するパラメータがあります。相対パス指定が上手く行かない場合、CircleCIでの実行ログを見る限りではDockerファイル名の指定部分に相対パスを含めてしまっても問題なさそうです。
jobs:
- aws-ecr/build-and-push-image:
dockerfile: 'dockerfile/Dockerfile'
aws-cli Orbと初期リージョン環境変数と異なる
aws-cliはAWS_DEFAULT_REGIONですが、aws-ecrはAWS_REGIONです。最初、この違いに気が付かず頭を傾げました。
名前違いで同じパラメータが複数存在することになりますが、aws-ecr Orbの呼び出し回数が限られると判っている場合はOrbのregion指定に直接埋め込んでしまっても良いかと思います。
slack
設定上のハマりはそれほど存在しないと思いますが、メッセージに適用できる変数で制約があります。
コミットメッセージを含める場合はjobsではなくstepで
workflow設定内ではユーザ変数設定が不可能な制約にて、メッセージに設定できる変数はCircleCIの環境変数に限られます。
ブランチ名とタグ名の指定は可能です。あと、タイミングによっては一致しない可能性もありますが、最新のコミットハッシュも指定できます。
自由にメッセージを設定したい場合は、ひと手間掛かりますがjob以下のstep内にての指定に切り替えることをおすすめします。
あとがき
CircleCIの各オーブは利用するにあたっての前提について説明等触れられていないケースもあり、場合によっては使うにあたって要件を満たしているかのソースコード検証も必要になります。
要件とOrbの仕様にズレが有る場合は、無理にOrbを適用せずにrun:による実行も検討することも一つの手段です。
