OSSの運用自動化ソフト 注目の7製品まとめ(Ansible/Terraform編):コードでインフラ構築、管理を実現するOSSたち(1)
システム構築、運用の自動化を担う「IaC(Infrastructure as Code)」を実現するソフトウェアは多くの種類が存在します。本連載では注目のIaCソフトウェア製品を7つ列挙し、それぞれの特徴などを比較して紹介します。ぜひ選ぶ際の参考にしてみてください。
クラウドネイティブ実践に欠かせない要素として、システム構築、運用を自動化する「IaC(Infrastructure as Code)」があります。IaC自体は数年前から注目を集め、その意義やメリットに対する正しい理解もかなり浸透しましたが、ビジネス目的達成のためには「自社独自の狙いや事情」に即したツール選定が1つのカギとなります。
しかし、ご存じの通り、IaCを実現するソフトウェアは多くの種類が存在し、それぞれに担当する分野が異なったり、記述するコードの形式が異なったりします。またソフトウェア間で連携する機能もあるなど、それぞれ特徴を持っています。
本連載では、注目のIaCソフトウェア製品を7つ列挙し、それぞれの特徴などを比較して紹介します。
製品名 | ベンダー/コミュニティー | 特徴 | |
---|---|---|---|
1 | Ansible | レッドハット | サーバを立ち上げる際に、あらかじめ用意した設定ファイルに基づいて、ソフトウェアのインストールや設定を自動で実行できるソフトウェア。「Playbook」と呼ばれる設定ファイルはYAML形式で記述し比較的学習が容易であることと、管理対象サーバに管理用のソフトウェアをインストールしないエージェントレスな構成が特徴。 |
2 | Terraform | HashiCorp | 設定ファイルに基づいてサーバなどのインフラを管理できるソフトウェア。各種パブリッククラウドや仮想化環境に対応している。インフラの構成管理に特化しており、サーバ内部の設定などは別のIaCツールを用いることが一般的。 |
3 | Chef | Chef Software Inc. | Ansibleと同様に、サーバを立ち上げる際に、あらかじめ用意した設定ファイルに基づいて、ソフトウェアのインストールや設定を自動で実行できるソフトウェア。「レシピ」と呼ばれる設定ファイルはRubyをベースとしたDSL(ドメイン固有言語)で記述する。Chef Serverを用いた大規模管理にも対応している。 |
4 | Puppet | Puppet, Inc. | AnsibleやChefと同様に、サーバを立ち上げる際に、あらかじめ用意した設定ファイルに基づいて、ソフトウェアのインストールや設定を自動で実行できるソフトウェア。「マニフェスト」と呼ばれる設定ファイルはRubyライクの独自DSLで記述する。スタンドアロン型とクライアントサーバ型の2種類の形態が存在する。 |
5 | Pulumi | PulumiCorp | Terraformと同様に設定ファイルに基づいてサーバなどのインフラを管理できるソフトウェア。各種パブリッククラウドや仮想化環境に対応している。インフラの構成管理に特化しており、サーバ内部の設定などは別のIaCツールを用いることが一般的。設定ファイルはJavaScript、TypeScript、Python、Goなど、複数の言語から選択して利用できる。 |
6 | Jenkins | Jenkins CI | ソフトウェア開発のビルド、テストおよびデプロイに関連する部分の自動化を支援し、継続的インテグレーション(CI)と継続的デリバリー(CD)を促進するソフトウェア。他のソフトウェアと異なり、インフラの管理ではなくソフトウェア開発を支援するソフトウェア。 |
7 | Packer | HashiCorp | マシンイメージの作成を自動化するツール。Amazon Web Services(AWS)なら「AMI」、Microsoft Azureなら「arm」を作成する。設定ファイルはjsonで記述する。AnsibleやChefなどと連携できる。 |
それぞれのソフトウェアをカテゴリーに分けたものが以下の表となります。
プロビジョニング | Terraform/Pulumi |
---|---|
コンフィギュレーション | Ansible/Chef/Puppet |
イメージ作成 | Packer |
継続的インテグレーション | Jenkins |
第1回は、上記ソフトウェアのうち、AnsibleとTerraformを紹介していきます。
Ansible
Ansibleは2012年にAnsible社によってリリースされた構成管理ソフトウェアです。同様の特徴を持つソフトウェアとしては、2005年にPuppetが、2009年にChefがリリースされており、Ansibleはこれらのソフトウェアの中では後発に当たります。Ansible社は2015年、レッドハットに買収され、現在はレッドハットがAnsibleを開発しています。
Ansibleが優れている点
Ansibleが先発のソフトウェアに対して優れているとされている点は以下の項目が挙げられます。
1.設定ファイルの読みやすさ、書きやすさ
Ansibleでは、処理を記述する設定ファイルは「YAML」と呼ばれる形式で記述します。YAMLは可読性が高く、専門的なプログラミングの知識がなくても理解しやすいところが特徴として挙げられます。そのため、設定ファイルの書きやすさにもつながってきます。
AnsibleのPlaybookの例が以下となります。
- name: install nginx hosts: web vars: ansible_become: yes ansible_become_method: sudo tasks: - name: install nginx yum: name: nginx state: latest - name: start service nginx service: name: nginx state: started - name: http open firewalld: service: http permanent: yes immediate: yes state: enabled
2. エージェントレス
Ansibleは、対象のサーバにSSHで接続できればよく、サーバ内に専用のソフトウェア(エージェント)をインストールする必要がありません。管理する対象のサーバが1台ならともかく、対象が数十台、数百台と多くなると、エージェントをインストールする点が導入の障壁になるケースがあります。Ansibleの場合、Ansibleを実行するサーバにのみAnsibleを導入すればよく、SSH接続さえできれば、構成管理の対象にできます。
3.構成管理可能な対象機器が幅広い
先述したようにエージェントレスが特徴になるため、Ansibleではサーバに加え、ネットワーク機器やストレージなどソフトウェアをインストールできない機器でも構成管理の対象としてコントロールできます。
Ansibleの注意点
こうした優れた点がある一方で、導入に際しては注意すべきポイントもあります。
1. 複雑な処理の実行が苦手
Ansibleでは、YAMLで表現することが難しい、複雑な条件分岐などのプログラマブルな処理を実行するためには工夫が必要になります。ChefやPuppetの場合はRubyをベースとしたDSLで記述するため、プログラマブルな処理も比較的柔軟に記述できます。
またAnsibleはYAMLによる可読性を重視しているため、複雑な処理を定義できません。今までシェルスクリプトで自動化に取り組んできたITエンジニアにとっては不自由だと感じるかもしれません。
2. 実行の完全性を担保できない
Ansible自体にはテスト機能が含まれていません。コマンドの実行結果は表示できるため、実行処理が行われているかどうかの確認は可能ですが、実行結果が意図した内容になったかどうかは、実行者自身が確認して判断する必要があります。
3. SSHポートが必ず開いている必要がある
Ansibleはエージェントレスで対象サーバに対してSSH接続経由で構成管理を実現しているため、構成管理の対象サーバはSSHの接続ポートを開けておく必要があります。ポート開放はセキュリティ上のリスクとなるため、接続元サーバのIPアドレスで接続を制限するなどの対策が別途必要になります。
有償サポートは、レッドハットが提供する有償版Ansibleの「Ansible Engine」で提供されています。
Terraform
Terraformは2014年にHashiCorpによってリリースされた構成管理ソフトウェアです。同様のソフトウェアにはPulumiがあります。
今回紹介するソフトウェアの中では、Ansibleがサーバの中身の構成を管理するのに対して、Terraformはサーバインフラの構成を管理する位置付けになっています。どちらもIaCソフトウェアに分類されますが、カバーする範囲が異なるため、併用されることもあります。
Terraformが優れている点
Terraformを導入するメリットとして、以下の点が挙げられます。
1.クラウドとの親和性が高い
コードによってインフラを管理するというメリットを最も享受できるのはクラウドを利用する場合になります。クラウドでは、仮想サーバだけではなく、多くのマネージドサービスを組み合わせてシステムを構成しているケースが多いためです。またTerraformは複数のクラウドに対応しています。各クラウドベンダーが用意している構成管理サービスはそれぞれのクラウドサービスに特化しているのに対して、Terraformなら複数のクラウドインフラを同一のツールで管理できます。
ツール名 | 開発元 | 対応するクラウド |
---|---|---|
Terraform | HashiCorp | AWS、Azure、Google Cloud Platform(GCP)など |
Pulumi | PulumiCorp | AWS、Azure、GCPなど |
AWS CloudFormation | Amazon | AWS |
Azure Resource Manager | Microsoft | Azure |
Google Cloud Deployment Manager | GCP | |
構成管理ツールのクラウド対応状況の比較 |
2.扱いやすさ(コードの読みやすさ、書きやすさ)
IaCソフトウェアはインフラの構成をコードとして表現します。そのためコードの読みやすさ、書きやすさという点が重要になることはAnsibleの紹介でも述べた通りです。
Terraformでインフラを構成するコードを記述した例が以下となります。
# アクセス情報の指定 variable "aws_access_key" {} variable "aws_secret_key" {} provider "aws" { access_key = "${var.aws_access_key}" secret_key = "${var.aws_secret_key}" region = "ap-northeast-1" } # AMIの指定 variable "images" { default = { ap-northeast-1 = "ami-078296f82eb463377" } } # VPCの設定 resource "aws_vpc" "testVPC" { cidr_block = "10.0.0.0/16" instance_tenancy = "default" enable_dns_support = "true" enable_dns_hostnames = "false" } # インターネットゲートウェイの設定 resource "aws_internet_gateway" "testGW" { vpc_id = "${aws_vpc.testVPC.id}" } # サブネットの設定 resource "aws_subnet" "public-a" { vpc_id = "${aws_vpc.testVPC.id}" cidr_block = "10.0.0.0/24" availability_zone = "ap-northeast-1a" } # ルートテーブルの設定 resource "aws_route_table" "public-route" { vpc_id = "${aws_vpc.testVPC.id}" route { cidr_block = "0.0.0.0/0" gateway_id = "${aws_internet_gateway.testGW.id}" } } resource "aws_route_table_association" "puclic-a" { subnet_id = "${aws_subnet.public-a.id}" route_table_id = "${aws_route_table.public-route.id}" } # セキュリティグループの設定 resource "aws_security_group" "admin" { name = "admin" description = "Allow SSH inbound traffic" vpc_id = "${aws_vpc.testVPC.id}" ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } # EC2インスタンスの設定 resource "aws_instance" "test" { ami = "${var.images.ap-northeast-1}" instance_type = "t2.micro" key_name = "awskey" vpc_security_group_ids = [ "${aws_security_group.admin.id}" ] subnet_id = "${aws_subnet.public-a.id}" associate_public_ip_address = "true" root_block_device { volume_type = "gp2" volume_size = 8 } }
aws_access_key = "<アクセスキー>" aws_secret_key = "<シークレットキー>"
【注】クレデンシャル情報を設定ファイルに書き込むことは非推奨です。「terraform.tfvars」という名前のファイルを作成して、変数で指定します。またterraform.tfvarsはGitなどのバージョン管理ソフトの対象外として管理することが推奨されています。
コード自体が書きやすさ、読みやすさを備えているだけではなく、コメントも挿入できるため、これまでの手順書に基づいたインフラ構築を置き換えることが可能になっています。
Terraformがインフラを構成するライフサイクルは、以下の4つに分けられます。
- 準備(terraform init)
- 計画(terraform plan)
- 実行(terraform apply)
- 削除(terraform destroy)
かっこ書きで記載した通り、それぞれのサイクルにコマンドが用意されており、この4つのコマンドを覚えることでTerraformを扱えるようになっています。
Terraformは、以下の3種類が提供されています。
- Terraform OSS(オープンソースで提供されているTerraform)
- Terraform Cloud(Free Tier, Paid Tier, and Business Tier)(Terraformのマネージドサービスで、無償1プランと有償2プランが存在する)
- Terraform Enterprise(有償提供されるTerraform)
有償サポートはTerraform CloudのBusiness TierとTerraform Enterpriseに付帯しています。
第1回はIaCソフトウェアとして7製品を概観した上で、AnsibleとTerraformを紹介しました。次回はChef、Puppet、Pulumiの特徴を紹介していきます。
筆者紹介
大喜多利哉(おおきた としや)
1978年生まれ、神奈川県横須賀市出身。メーカー系システムインテグレーター、ISP、商社系ネットワークインテグレーターで、インフラエンジニアとしてプリセールスからITインフラ設計/構築/運用と、上流工程より一貫して携わる。現在はWebシステム開発運用会社でオンプレミス環境からパブリッククラウドへの移行案件を担当している。
Copyright © ITmedia, Inc. All Rights Reserved.