アジアクエスト クラウドインテグレーション部の田中雄也です。
この記事では、CI/CDを知るためのはじめの一歩として、インフラ環境をコード化するIaCについてご紹介していきます。
この記事を読むことで、インフラ環境をコード化するIaCという仕組みを知ることができます。この手法の具体的な活用例の紹介を通じて、より効率的な環境構築を知るきっかけとなれば幸いです。
「Continuous Integration」・「Continuous Delivery」の略称で、日本語に訳すと「継続的インテグレーション・継続的デリバリー」といった意味になります。
ソフトウェアのリリーススピードの向上を目的とした開発手法で、 ソフトウェアをリリースさせた段階で満足するのではなく、リリース後においても継続的なアップデートの提供をすることで、絶えず変化するビジネス環境に適応したソフトウェアの提供を目指すための手法です。
コードの変更が行われる都度のテストやデプロイを自動化することで、ソフトウェアのリリーススピードの向上を通して、市場が求めるアプリケーションを維持し、競争力を保ち続けることが目的となっています。現在ではソフトウェアだけでなく、クラウドインフラにもこの仕組みが応用されるなど幅広い開発現場で用いられる手法となっています。
さて、今回扱うIaCとはどのようなものなんでしょう。
ずばり、「Infrastructure as Code」の略称で、簡潔にいうと、インフラストラクチャ構築をコード化することです。
ネットワークの構成やサーバーの設定など、インフラを構成する要素をコード化し、その構築や管理を専用のソフトウェアによって自動化する手法です。
が挙げられます。
担当者が手動でインフラ環境をデプロイすることを考えると、どうしても手順書と設計書を見比べながら作業することになり、時間もかかりますし、ミスの可能性も考えられます。
そのため、インフラ構築をコード化することで、構築の自動化や標準化を通して、ミスや作業時間の削減をすることが求められているのです。
これらの関係性はCI/CDの説明の際に、クラウドインフラにも応用されていると記載をしている。まさに、その部分になります！
CI/CDとIaCは、自動化と効率化の部分で結びついています。IaCでコードとして記述したインフラ環境の設計図をCI/CDによる自動的なテストとデプロイによって、開発者による手動での介入なしに、リソースのプロビジョニングまでのステップを完了させることができます。
開発者はCI/CDとIaCを連携して運用することで、開発にかかるリスクを低減しながらも、環境構築に掛かるスピード向上を達成することが可能になるのです。
というわけで、ここからは実際にIaCがどのような形で提供されているのかを把握するために、各クラウドサービスにおける
IaCサービスについて見ていきます。
AWSのIaCサービスで、サービスの開始が2011年と歴の長いIaCの火付け役。
記述はJSON/YAML形式で比較的シンプルに扱える。最小単位は「スタック」であり、スタックの集まりであるスタックセットを利用することで、複数のアカウントや複数のリージョンに対して同様の構築を展開することが可能。
例として、CFnに用いられるYAMLでは、以下のような形式でコードを記述します。
(全体を記載すると長くなってしまうので、EC2の定義部分のみ。実際に構築するためには、この他にもパラメータの定義やテンプレートのバージョンの定義などが必要になってきます。)
…
Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref HogeImage
KeyName: hogehoge-key
InstanceType: !Ref InstanceType
SecurityGroups:
- !Ref HogeSG
BlockDeviceMappings:
- DeviceName: /dev/sda1
Ebs:
VolumeSize: 50
…
Azureのサービスで、リソースのデプロイに限らず、全般的な管理などを行う包括的な機能を備えている。
JSONをもとにしたARMや独自の形式であるBicepなどを活用して記述する。変数を扱いやすいという点でJSONより扱いやすいという意見もある。
最小単位は「リソースグループ」で、それぞれデプロイに用いられるARMは腕、Bicepは上腕二頭筋が由来だったりとユーモアが利いたネーミングセンスをしている。
例として、Bicepでは、以下のような形式で記述します。(VM定義部のみ抜粋)
…
resource vm 'Microsoft.Compute/virtualMachines@2021-03-01' = {
name: vmName
location: location
properties: {
hardwareProfile: {
vmSize: vmSize
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
}
dataDisks: [
{
diskSizeGB: 1023
}
…
GCPのサービス。GCP全体としてGUIよりもAPIが充実/推奨される傾向にあり、CDMも同様。
JSONとYAML、PythonとJinjaなどでコードを記述できる。それぞれの使い分けとしては、JSONとYAMLは静的でシンプルな構成に適しているため、規模の小さい環境向け。PythonとJinjaはより動的で複雑な環境に適しており、記述したコードの内容を変数化し、モジュールとして再利用することに向いている。
最小単位は「デプロイメント」で、GCPではTerraformの活用も推進されているため、CDMの開発優先度は低いようにも思える。
例として、CDMのPythonは、以下のような形式で記述します。(VM定義部のみ抜粋)
…
COMPUTE_URL_BASE = 'https://www.googleapis.com/compute/v1/'
def GenerateConfig(context):
datadisk = 'datadisk-'+ context.env['deployment']
resources = [{
'type': 'compute.v1.instance',
'name': 'vm-' + context.env['deployment'],
'properties': {
'zone': context.properties['zone'],
'machineType': ''.join([COMPUTE_URL_BASE, 'projects/', context.env['project'], '/zones/',
context.properties['zone'], '/machineTypes/f1-micro']),
'disks': [{
'deviceName': 'boot',
'type': 'PERSISTENT',
'boot': True,
'autoDelete': True,
'initializeParams': {
'sourceImage': ''.join([COMPUTE_URL_BASE, 'projects/debian-cloud/global/images/family/debian-11'])}
}
}
}]
return {'resources': resources}
…
各サービスを簡単に比較すると以下のようになります。
| AWS CFn | Azure RM | GCP CDM | |
|---|---|---|---|
| 料金 | 無料 | 無料 | 無料 |
| リソースのデプロイ先 | スタック展開先に依存 | テンプレート内に記述 | テンプレート内に記述 |
| 記述言語 | JSON/YAML | ARM(JSON)/Bicep | JSON/YAML/Python/Jinja |
| リソースの権限管理 | 〇 | 〇 | 〇 |
| 学習のしやすさ | 〇 | 〇 | △ |
料金面：各サービスが無料となっているのでその点を気にする必要はなさそうです。
リソースのデプロイ先：AWS以外はテンプレート内にどのリージョンに対してリソースを構築するかについて明示的に記述する必要があります。それに対しAWSでは、リソースのデプロイ先がCFn展開時に用いたリージョンに依存するため、コードを展開したリージョンにそのままリソースが構築される仕組みになっています。
記述言語：AWSのCFnは複雑な処理には直接対応をしていないため、ループや複雑な処理を用いたい場合には別の手段との連携をする必要があります。
リソースの権限管理：AWSのIAMのような形で、各IaCサービスがどこまでのサービスを作成可能かについて権限を定められるかどうかという観点です。全てのサービスにおいて、IaCを活用して作成できるリソースについて権限設定で制限をかけることが可能です。
学習のしやすさ：AWSは、広く使われているため学習に利用できるドキュメントが多いため〇としています。Azureは有志の情報こそAWSには及ばないものの、公式ドキュメントが充実しているため、学習のしやすさを〇としています。
GCPは他のサービスと比較して情報ソースがそろっておらず、比較的学習がしづらいと言えるため△としています。
ここまでは、各クラウドサービスに根付いているIaCサービスについてご紹介してきました。
しかし、IaCツールには、今まで紹介してきたクラウドサービスを横断して、IaCを実現できるツールも存在しています。その1つがTerraformです。
Terraformは、HashiCorp社によって開発されたオープンソースのツールであり、今までご紹介をしてきたAWS/GCP/Azure/Kubernetes等に対応した無料のIaCツールであることから、エンジニアにとても人気のあるツールです。
その特徴として、インフラの定義をコードとして記述することで、作成の過程を自動で行ってくれる宣言型といった仕組みや管理対象のインフラの現状を追跡するために用いられるstateファイルの存在が挙げられます。
ちなみに、stateファイルとは、Terraformの特徴的な機能であり、管理対象のインフラの現状を追跡するものです。
このファイルの存在によりTerraformはリソースの変更が必要・不必要の判断やリソース間の依存関係の追跡をすることでリソースが正しい順序で作成、更新、削除されることを保証しています。
逆に言うと、Terraformでの開発時にはstateファイルが必須となるため、共同開発時にはファイルの共有が必要となってきます。
また、先ほどまで紹介してきたサービスと違って、個々のクラウドサービスに根ざしたツールではないため、コード外での変更を取り込むために、変更をファイルに反映させる必要があるという点に欠点があります。いずれにせよ取り扱い注意なファイルだと言えます。
最後に、そのほかTerraformの惜しいポイントを挙げるとすると以下の点があります。
次にIaCの仕組みの1つであるCDKと関連するサービスについてご紹介をしていきます。
Cloud Development Kitの略で
JavaScript、Python、Java、C#、Goと言ったプログラミング言語でクラウドインフラやクラウドアプリケーションを定義・開発するプロセスのことで、インフラ環境をコードで構築する概念であるIaCの一種です。
AWS CDKは最新のプログラミング言語でAWSのインフラをコードとして定義し、それをAWS CloudFormationを通じてデプロイするための開発フレームワークです。
その特徴として
が挙げられます。
結論としてAWS CDKの働きは、使い慣れた言語で開発したコードを、CFNでデプロイをできる形に合成することにあります。
実際に、CDKを使用した場合の開発フローは以下の図のようになります。
AWSにはIaCのツールとして、CloudFormationが存在するにもかかわらず、なぜあえてAWS CDKが利用されるのでしょう。その理由は以下のようなものです。
上記のような理由から、AWS CDKを使うことで、開発者は新たな開発コストを気にすることなくより簡単にインフラ構築ができるようになるのです。
そして、それがAWS CDKが今日においても選ばれ続ける理由となっています。
例として、AWS CDKのテンプレートは以下のような形式になります。
…
class TestStack(core.Stack):
def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
super().__init__(scope, id, **kwargs)
aws_ec2.CfnInstance(
self,
id=‘ec2',
availability_zone="ap-northeast-1a",
image_id=image_id,
instance_type="t2.micro",
key_name=‘cdk-ssh-key',
security_group_ids=sg_ids,
subnet_id=subnet_id,
)
…
CDK for Terraform (CDKTF)とはTerraformと同じく、HashiCorp社によって提供されているCDKツールであり、JavaScript（Typescript）、Python、Java、C#、Goに対応しています。
記述した言語の最終的なアウトプットが最終的のアウトプットはHashiCorp Configuration Language (HCL)という独自の形式で出力されることや特定のクラウドサービスに依存するものではなく、AWSだけでなくAzure、GCPといったマルチクラウドに対応していることが特徴になります。
専用のCLIもあり、比較的に使いやすいツールだと言えます。
そんなCDKTFが選ばれる理由も以下に集約されます。
総じて、開発者はCDKツールを使うことによって、新たな学習コストを削減し、使い慣れた環境で効率的な開発ができるようになります。
その上で、CDKツールを用いることで基本的なIaCツールには備わっていないような機能やサポートといった恩恵を受けることもできるので、IaCツール検討の際には、ぜひCDKツールも候補に入れて頂くとよいかなと思います。
ちなみに例として、CDK for Terraformのテンプレートは以下のような形式になります。
…
class TestStack(TerraformStack):
def __init__(self, scope: Construct, ns: str):
super().__init__(scope, ns)
AwsProvider(self, "AWS", region="us-west-1")
instance = Instance(self, "compute",
ami=hoge-ami,
instance_type="t2.micro",
key_name=‘cdktf-ssh-key’,
security_group_ids=sg_id,
subnet_id=subnet_id
)
…
ここまで、多様なIaCツールをご紹介してきました。とはいえ、結局どのツールを選択するのがいいんでしょうか？
結論からいうと、リソースをデプロイする先のクラウドサービスが決まっているならそこから逆算して考える。それでも絞りこめなければ、最後は好みです。
参考までに、ツールを選定する際に考えるべき点としては以下のような項目が挙げられます。
これらの観点を通しても利用するツールを絞り込むことができない場合には、時間軸という点から考えてみてもいいかもしれません。
期限が迫っている開発に対して学習コストの高く、使い慣れていないツールを導入してしまうと、それだけ構築の工程は長引いてしまいますよね。要するに、ツールの選定はその場にあったツールを選定することが重要にはなってくるのです。
ただ、やはり最終的には好みであって、自分が興味を持って始められることが肝心です。
きっかけの1つとして、IaCツールに触ることのできるワークショップのURLをまとめていますので、興味があればご確認ください。
これらの観点を通しても利用するツールを絞り込むことができない場合には、時間軸という点から考えてみてもいいかもしれません。
期限が迫っている開発に対して学習コストの高く、使い慣れていないツールを導入してしまうと、それだけ構築の工程は長引いてしまいますよね。要するに、ツールの選定はその場にあったツールを選定することが重要にはなってくるのです。
ただ、やはり最終的には好みであって、自分が興味を持って始められることが肝心です。
きっかけの1つとして、IaCツールに触ることのできるワークショップのURLをまとめていますので、興味があればご確認ください。
URLはこちらAWS CloudFormation
Azure Resource Manager
Terraform
AWS CDK
というわけで、この記事では「CI/CDはじめの一歩 IaC編」として、CI/CDとIaC。そこに用いられるツールについて触れさせていただきました。
CI/CDとは、継続的インテグレーション・継続的デリバリーを指す言葉でソフトウェアのリリーススピードの向上を目的として、コードの変更が行われる都度のテストやデプロイを自動化するものとして現在では、ソフトウェアだけでなくクラウドインフラを含めた幅広い開発現場で用いられている開発手法であること。
IaCとは、インフラ構築をコード化することで、構築の自動化や標準化を通して、ミスや作業時間を削減できる仕組みであること。
そんなCI/CDとIaCは、自動化と効率化の部分で結びついていて、IaCでコードとして記述したインフラ環境の設計図をCI/CDによる自動的なテストとデプロイによって、開発者による手動での介入なしにプロビジョニングまでの工程を完了させる。それによって開発にかかるリスクを低減しながらも、環境構築に掛かるスピード向上を達成できること。
が、ご理解いただけたでしょうか？
この記事が皆様のCI/CDやIaCに踏み出す一歩として寄与することを願っています。
最後までお読みいただき、ありがとうございました。
また、この記事は
以前に投稿したCI/CDはじめの一歩シリーズの一部となっています。
以前の記事をご覧になりたい方は下記のリンクより参照できますので、よければご覧ください。
参考記事