OSSの運用自動化ソフト 注目の7製品まとめ（Ansible/Terraform編）：コードでインフラ構築、管理を実現するOSSたち（1）

システム構築、運用の自動化を担う「IaC（Infrastructure as Code）」を実現するソフトウェアは多くの種類が存在します。本連載では注目のIaCソフトウェア製品を7つ列挙し、それぞれの特徴などを比較して紹介します。ぜひ選ぶ際の参考にしてみてください。

[大喜多利哉，＠IT]

印刷

通知 連載「％」の新着をメールで通知

隕九ｋPost

Shareシェア

はてなブックマーク

SharePocket Button

　クラウドネイティブ実践に欠かせない要素として、システム構築、運用を自動化する「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	Google	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
    }
}

main.tf

aws_access_key = "＜アクセスキー＞"
aws_secret_key = "＜シークレットキー＞"

terraform.tfvars

【注】クレデンシャル情報を設定ファイルに書き込むことは非推奨です。「terraform.tfvars」という名前のファイルを作成して、変数で指定します。またterraform.tfvarsはGitなどのバージョン管理ソフトの対象外として管理することが推奨されています。

　コード自体が書きやすさ、読みやすさを備えているだけではなく、コメントも挿入できるため、これまでの手順書に基づいたインフラ構築を置き換えることが可能になっています。

　Terraformがインフラを構成するライフサイクルは、以下の4つに分けられます。

1. 準備（terraform init）
2. 計画（terraform plan）
3. 実行（terraform apply）
4. 削除（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システム開発運用会社でオンプレミス環境からパブリッククラウドへの移行案件を担当している。

縺薙�騾｣霈峨ｒ縲碁€｣霈芽ｨ倅ｺ九い繝ｩ繝ｼ繝医€阪↓逋ｻ骭ｲ縺吶ｋ New