はじめに
IaCはBicepなりTerraformなりなんでもいいですが、ソースコードを管理するレポジトリをアプリケーションと一緒にするか、インフラのみのレポジトリにするのか悩ましいと思っています。格納したとしても、デプロイするときのパイプラインを作るのもなかなかめんどくさいと思っていました。
そんなある日、GitHubのレポジトリあさっていたら、MicrosoftからSymphonyというツールがあることを知りました。宣伝を見かけたことはないですが、そこそこコミットもされているようです。
これで万事解決というものではないですが、デプロイ用のスクリプト作るのめんどくさいなーとか思っている人は使ってもいいと思います。
- GitHub/Azure DevOpsサポート
- チームプロジェクトもしくはレポジトリは存在しない状態で作らなくてはならない
- Terraformの場合Azure Storageアカウント必要（Bicepでもなぜかつくられるけど）
- GitHubの場合はPull Request検証してくれるが、Azure Pipelinesはやってくれない（自分で登録して工夫しないといけない）
- サポートはLinux(Ubuntu)のランナーのみ
- クライアントはWSL内での実行を推奨（bash/zsh）
- git remoteはちゃんと書き換えよう
- Service Principal作成権限が必要です
初期構築
実行してみます。azure cliでログインして、symphonyのレポジトリをクローンした後、git remoteを消してください（git remote remove orgin）。そのままではMicrosoftのレポジトリを指してしまいます。
symphony provisionで初期化を行い、Azureリソースを作成します。
Service Principalが作成されるまでしばらく待ちます。
作成されたらsymphony pipeline config azdo | github bicep | terraformでパイプラインを準備します。あとはIACフォルダー配下にiacファイルをコミットしていくだけになります。
最初にサンプルも追加すると、すぐビルドできるようになっています。
CIしてみる
サンプルをビルドしてみましょう。Gitleaks、Linterといった準備を実行して問題なければリリースになります。私の場合Defender for DevOpsでCSPMも有効にしているので、エージェントレススキャンも実行されます。
フォルダー構成はパラメータファイルとIaCファイルは完全に別のフォルダー配下に置くことになります。
bicepparamファイルの階層。
bicepの階層。サンプルの場合01_, 02_というフォルダーの順番に自動的にデプロイされます。パイプラインの中やbicepでの依存関係は最小限になると思います。
フォルダーパスの階層を作る側がちょっと意識しないといけないとか、フォルダーの数慎重に考えないといけないだろうかなとか考えるところは割とありますが、フォルダーやごちゃっとしたIaCのファイルが散らばっていて、どの順番でリリースすればいいのかわかりづらい点に悩んでいるとかという人はちょっと試してもらってもいいかなと思います。
問題点
問題点としては、Azure CLI 2.71のバグのようで、bicepのvalidationでエラーになります。az config set bicep.use_binary_from_path=Falseをbicep実行前につけないと失敗するはずです。
あと、もう一つ、本家のスクリプトが更新されたとき、知る方法がわからないことでしょうか😅。リリースされるわけでもないですしね。
よかったら試してみてください。私も自分の環境をこれで管理していこうかなと思っています。
