Open6
IaC on Azure
- パイロットライト方式・パイロットランプ方式って言うの知らんかった。Azure だと "Redeploy on disaster" で、リデプロイ方式って明示されてるほうがわかりやすくて好き
- 循環型 IaC
- ドリフト検出と調整の話
- Terraformer か
az bicep decompile
- 精度気になる → LLM と Unit Test 組み合わせてループ回すとか?
IaC の課題
- 論文: Simplifying Cloud Management with Cloudless Computing (HotNets23)
- PDF: https://conferences.sigcomm.org/hotnets/2023/papers/hotnets23_qiu.pdf
- 問題
- IaC は難しい: 学習曲線のカーブがキツイ
- 検証が不十分: シンタックスの検証 (lint) が通っても動く保証なし
- デプロイが非効率: リソース依存関係の解析が不十分なのでリソース状態の再チェックが全体に対して走る
- コラボレーションが難しい: conflict への対応とかロールバックが難しい
- デバッグが難しい: ドリフトの検出と調整
- ポリシーがアドホック: 非機能要件的なポリシー(スケーリング、予算、セキュリティ要件)の統一が難しい
テスト周り
- 「Unit テストを書く時間と得られる安全は見合っていない感覚がある」とてもよく分かる
- Online Stack Test を増やすのが良いらしい
-
Offline Stack Tests
- シンタックスチェック: bicep の linter
- 静的コード解析
- tflint、checkov、bicep
- ポリシー準拠なら bicep の avm 使うと W-AF 準拠ライクなものが作れる
-
Online Stack Tests:
- 作ったリソース同士を連携させてフィードバックを得る
- System Tests: インテグレーションテスト
Azure の Online Stack Tests
terratest
ssh で jump-box vm にログインして、別 vm に ping 打てるかっていうテスト
Chef InSpec
describe azure_virtual_machine(resource_group: 'RESOURCE_GROUP', name: 'NAME-WEB-01') do
it { should exist }
it { should have_monitoring_agent_installed }
it { should_not have_endpoint_protection_installed([]) }
it { should have_only_approved_extensions(['MicrosoftMonitoringAgent']) }
its('type') { should eq 'Microsoft.Compute/virtualMachines' }
its('installed_extensions_types') { should include('MicrosoftMonitoringAgent') }
its('installed_extensions_names') { should include('LogAnalytics') }
end