Infrastructure as Code

このページで学ぶこと

• Infrastructure as Code
• Machine-Readable Infrastructure Definition
• Version Control Practice
• Code / Change Review
• Repeatable Deployment
• Consistent Configuration
• Automation Engine Application
• Validation / Testing Workflow
• Declarative vs Imperative
• IaC vs Script Automation
• IaC with Device / Controller Management

Infrastructure as Code

Infrastructure as Code（IaC）は、InfrastructureのProvisioning・Configuration・ManagementをMachine-readableなCode / Definitionとして扱う方法である。Cloud専用でも特定Tool専用でもない。

Machine-Readable Definition

人がDeviceへ直接Commandを入力することを管理の中心にせず、Infrastructureを表すDefinitionをMachine-readableな形で管理し、Automation等から適用できる。

Version Control

Infrastructure DefinitionはVersion Controlで管理することが一般的で、変更履歴、差分確認、Rollbackの判断などに利用できる。ただしVersion Controlされていること自体をIaC成立の必須条件とはしない。

Code / Change Review

Infrastructure変更をDefinitionの差分として扱えるため、適用前にCode Review / Change Reviewを行うWorkflowと組み合わせやすい。

Repeatable / Consistent Deployment

同じDefinitionとAutomationを用いることで、同じInfrastructureをRepeatableに展開し、複数環境でのConfiguration Consistencyを保ちやすい。

Automation Engine

IaC DefinitionはAutomation Engine等によって実際のDeviceやControllerへ反映される。Definitionを書くだけでInfrastructureが自動的に変わるとは限らない。

Validation / Testing

DefinitionのSyntax、Policy、Expected Stateなどを適用前後にValidation / TestingするWorkflowを組み込める。IaCであること自体が設定の正しさを保証するわけではない。

Declarative / Imperative

Declarativeは「どういう状態であるべきか」というDesired State / Whatを記述し、Imperativeは「その状態へどう到達するか」というProcedure / Howを記述する。IaCはDeclarativeだけに限定されない。

IaCとScript Automation

AutomationはTask / Operationの自動実行だけでも成立する。IaCではInfrastructure Definition自体をCodeとして管理する点が中心になるため、すべてのAutomationがIaCではない。

Device / Controllerとの組み合わせ

IaC DefinitionをDeviceへ直接適用するAutomationにも、Controllerを介して反映する構成にもできる。Device-Based / Controller-Based / Automation-Based / IaCは相互排他的ではない。

重要な注意点

IaCはTerraform専用・Ansible専用・Cloud専用ではない。Version Controlは重要なPracticeだがIaC成立条件ではなく、DeclarativeだけがIaCというわけでもない。