OSSの運用自動化ソフト 注目の7製品まとめ（Chef/Puppet/Pulmi編）：注目のIaC（Infrastructure as Code）ソフトウェア7製品徹底比較 2022年版（2）
「IaC（Infrastructure as Code）」を実現するソフトウェア製品を比較して紹介する本連載。今回はChef、Puppet、Pulumiを紹介します。ぜひ選ぶ際の参考にしてみてください。
クラウドネイティブ実践に欠かせない要素として、システム構築、運用を自動化する「IaC（Infrastructure as Code）」があります。IaC自体は数年前から注目を集め、その意義やメリットに対する正しい理解もかなり浸透しましたが、ビジネス目的達成のためには「自社独自の狙いや事情」に即したツール選定が1つのカギとなります。
しかし、ご存じの通り、IaCを実現するソフトウェアは多くの種類が存在し、それぞれに担当する分野が異なったり、記述するコードの形式が異なったりします。またソフトウェア間で連携する機能もあるなど、それぞれ特徴を持っています。
| 製品名 | ベンダー／コミュニティー | 特徴 | |
|---|---|---|---|
| 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 |
前回は、注目のIaCソフトウェア7製品の内、AnsibleとTerraformを紹介しました。
今回は上記ソフトウェアのうち、Chef、Puppet、Pulumiを紹介します。
Chef
Chefは2009年にOpscodeがリリースした構成管理ソフトウェアです。その後、OpscodeはChef Softwareに社名を変更して現在に至ります。同様の特徴を持つソフトウェアとして2005年にPuppetが、2012年にAnsibleがリリースされています。
Chefの特徴として以下の点が挙げられます。
RubyのDSL（ドメイン固有言語）で記述
Chefでは、構成管理に使用するコードを「レシピ」と呼ばれるファイルに記述し、レシピの集合体を「クックブック」として管理します。レシピはRubyのDSL（ドメイン固有言語）で記述し、プログラマブルな処理が可能であることと、Rubyの経験があれば比較的容易に記述できることが特徴として挙げられます。
Chefのレシピの例が以下となります。
package ['nginx'] do action :install end systemd_unit 'nginx' do action [:start, :enable] end
上記の例ではパッケージを1つインストールし、systemdでサービスの起動と起動時有効化を実施するだけですのでプログラマブルな要素はありません。Chefでは、複数のパッケージのインストールを以下のように記述して繰り返し処理をさせることができます。
package ['httpd', 'httpd-devel', 'mysql', 'mysql-server', 'mysql-devel', 'php', ‘php-mysql’] do action :install end
Attributeなどを利用すると、かなり複雑な構成管理ができるようになっているのが、Chefの特徴です。一般公開されているクックブックを組み合わせて、標準機能では操作ができないリソースの操作などもできます。
サーバによる管理
今日において、Chefによる構成管理はChef Infra Serverを用いて行われることが推奨されています。かつてはChef-Soloと呼ばれるスタンドアロン型のChefが存在しましたが、現在はなくなっています。代わりにChef-Zeroと呼ばれるスタンドアロン型のChefが登場しましたが、現在のChef-Zeroはテスト用に用いることが推奨されており、永続的な利用は推奨されていません。
Chefのスタンドアロンでの利用は、Chef-Zeroを使ったリモート管理（エージェントのセットアップはSSH経由で行い、構成管理はエージェントへの通信を介しておこないます）の他、Chef Infra ClientのLocal Modeで、エージェントをローカルで実行して自身を構成管理できます（Puppetのスタンドアロン型の実行形式に似ています）。
このように、Ansibleがスタンドアロンでも導入しやすく、かつサーバによる管理にも対応しているのと比較して、Chefはスタンドアロンで利用することからサーバによる管理にかじを切っている印象です。
エージェント型
Chefはエージェントによる構成管理を採用しています。Chefによる構成管理をつかさどるサーバをChef Infra Serverと呼び、管理対象のサーバで動作するエージェントをChef Infra Clientと呼びます。
Chef Softwareのプロダクトは全てオープンソースで開発されており、非営利目的、実験、個人利用で使用している場合は無償で利用できます。ビジネス利用の場合は商用ライセンスを契約する必要があり、Chef Softwareのサポートを受けることもできるようになります。これはソフトウェアを有料化して収益を得るというモデルではなく、ソフトウェア自体はオープンソースで提供し、サポートで収益を得るというレッドハットのビジネスモデルと似ています。
Puppet
Puppetは2005年にLuke Kanies氏によってリリースされ、現在ではPuppet Labsが開発している構成管理ソフトウェアです。
Puppetにはスタンドアロン型とクライアントサーバ型の2種類の形態が存在し、クライアントサーバ型で動作する場合はPuppet ServerとPuppet Agentの2つのソフトウェアによって動作します。Puppet Agentをインストールされた対象サーバには、スタンドアロン型のPuppetもインストールされます。
構成管理をするスクリプトは「マニフェスト（manifest）」と呼ばれ、Rubyライクな独自のDSLで記述します。
マニフェストには構成管理の対象サーバの「あるべき構成」を記述します。スタンドアロン型の場合、Puppetが動作しているサーバ自身に「あるべき構成」が適用されますが、クライアントサーバ型の場合、Puppet Serverがマニフェストを一元管理し、構成管理の対象サーバのPuppet Agentに対してマニフェストを配布し、各サーバにはそのマニフェストが適用されます。
Puppetでは、構成管理の各設定のことを「リソース」と呼びます。
Ansibleはスタンドアロン型であってもリモートのサーバの構成管理が可能であるのに対して、Puppetのスタンドアロン型はPuppetがインストールされたサーバに対して構成管理を行います。そのため、リモートから構成管理をする場合はクライアントサーバ型を採用する必要があります。
Ansible、Chef、Puppetの動作イメージを図に表すと以下のようになります。
Puppetのマニフェスト例が以下となります。
package { "nginx":
provider => "yum",
ensure => "installed",
}
service { "nginx":
name => "nginx",
ensure => running,
require => Package["nginx"],
}
firewalld_service { 'Allow HTTP from the Public zone':
ensure => 'present',
service => 'http',
zone => 'public',
}
Puppetには無償のオープンソース版と、有償のエンタープライズ版が用意されています。
前回のAnsibleと合わせて、3つのコンフィギュレーション層のIaCツールを紹介しましたので、簡単に比較をしてみましょう。
| 項目 | Ansible | Chef | Puppet |
|---|---|---|---|
| 言語 | YAML | DSL（Ruby） | DSL（PuppetDSL） |
| 実行形式 | スタンドアロン型（リモート管理可能）／クライアントサーバ型 | スタンドアロン型（リモート管理可能だが手順はやや難解）／クライアントサーバ型 | スタンドアロン型（管理対象サーバで実行）／クライアントサーバ型 |
| 導入のしやすさ | ◎ | ▲ | ○ |
| 複雑な処理 | ▲ | ◎ | ▲ |
| 情報の多さ | ◎ | △ | △ |
| 有償サポート | あり | あり | あり |
| ※各項目は◎○▲△で順位付けしています。 | |||
導入のしやすさに関しては、エージェントレスでスタンドアロン型でもリモート管理が可能で、YAMLで定義ファイルが書きやすいAnsibleを最も高い評価としました。その次にはPuppetが比較的実行しやすく、Chefは次点の印象でした。
複雑な処理に関しては、RubyのDSLを採用しているChefを最も高い評価としました。AnsibleとPuppetは記述言語が異なるものの同程度と見ました。
情報の多さに関しては、最後発のAnsibleが最も多い印象です。比較的新しい情報を入手しやすい環境にあるといえます。Chefは古い情報が多く、Chef自体がバージョンアップでコマンド体系などが大きく変わっていることから、情報の入手難度は高いといえるでしょう。Puppetに関しては情報そのものが少ない印象です。
有償サポートはいずれのツールにも用意されており、エンタープライズにおける導入に関してもいずれのツールも対応できると評価しました。
Pulumi
Pulumiは2017年にPulumiCorpがリリースした構成管理ソフトウェアです。今回紹介するソフトウェアの中では、Chef、PuppetがAnsibleと同様に、主にサーバ内部の構成管理をするために用いられるのに対して、PulumiはTerraformと同様に、主にインフラの構成管理をするために用いられます。
Pulumiの特徴として以下の点が挙げられます。
記述する言語が選択可能
Pulumiでは、PythonやTypeScript、Goといった言語を選択して記述できます。プログラミング言語で記述するためプログラマーにとっては理解が容易で、プログラマブルな処理を簡単に記述できるだけでなく、IDE（統合開発環境）によるコード補完などの恩恵を得ることができます。一方で、プログラミング言語に精通していないエンジニアにとっては学習コストを要する面もあります。
クラウドとの親和性が高い
PulumiもTerraformと同様に、AWS、Microsoft Azure、Google Cloud Platform（GCP）などの複数のパブリッククラウドに対応しています。マルチクラウド環境でも同一のツールでインフラの構成管理ができます。
Pulumiでインフラを構成するコードを記述した例が以下となります。言語はTypeScriptを選択した場合の例です。
Pulumiの公式チュートリアルにあるように、pulumi new aws-typescriptコマンドを実行してプロジェクトを作成すると、以下のファイルとディレクトリが作成されます。
[root@t pulumi-test]# ll
合計 168
-rw-r--r-- 1 root root 37 10月 23 12:16 Pulumi.dev.yaml
-rw-r--r-- 1 root root 87 10月 23 12:12 Pulumi.yaml
-rw-r--r-- 1 root root 420 10月 23 13:01 index.ts
drwxr-xr-x 145 root root 4096 10月 23 12:14 node_modules
-rw-r--r-- 1 root root 141742 10月 23 12:14 package-lock.json
-rw-r--r-- 1 root root 247 10月 23 12:12 package.json
-rw-r--r-- 1 root root 438 10月 23 12:12 tsconfig.json
index.ts
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";
// Create an AWS resource (S3 Bucket)
const bucket = new aws.s3.Bucket("my-bucket");
// Export the name of the bucket
export const bucketName = bucket.id;
Pulumiは無償版の他、PulumiCorpによる有償版も提供されています。1人で使う場合は無償版が利用可能ですが、チームで利用するなどの場合には有償版を利用する必要があります。
前回のTerraformと合わせて、2つのプロビジョニング層のIaCツールを紹介しましたので、簡単に比較をしてみましょう。
| Terraform | Pulumi | |
|---|---|---|
| 対応プラットフォーム | AWS、Azure、GCPなど | AWS、Azure、GCPなど |
| 言語 | HCL（HashiCorp Configuration Language） | JavaScript,TypeScript,Python,Goなど |
| 導入のしやすさ | ◎ | ▲ |
| 複雑な処理 | ▲ | ◎ |
| 情報の多さ | ◎ | △ |
| 有償サポート | あり | あり |
| ※各項目は◎○▲△で順位付けしています。 | ||
対応プラットフォームはプロバイダーと呼ばれる外部モジュールに依存しますが、どちらも主要なクラウドプラットフォームには対応しています。
言語に関しては、プログラミング言語の経験がある人はPulumiがよさそうですが、筆者としてはTerraformが書きやすく、またコマンドもシンプルで分かりやすい印象です。
プログラミング言語が使えるので、複雑な処理に関してはPulumiが向いているでしょう。情報量に関してはTerraformが多く、Pulumiは少ない印象です。有償サポートはどちらにも用意されているので、エンタープライズ環境での導入も問題ないでしょう。
前回と今回を通じて、IaCツールでもそれぞれ特徴があるとお分かりいただけたでしょうか。次回はこれまで紹介したツールとは若干毛色の異なる、JenkinsとPackerを紹介します。
筆者紹介
大喜多利哉（おおきた としや）
1978年生まれ、神奈川県横須賀市出身。メーカー系システムインテグレーター、ISP、商社系ネットワークインテグレーターで、インフラエンジニアとしてプリセールスからITインフラ設計／構築／運用と、上流工程より一貫して携わる。現在はWebシステム開発運用会社でオンプレミス環境からパブリッククラウドへの移行案件を担当している。
Copyright © ITmedia, Inc. All Rights Reserved.