Infrastructure-as-Codeアプローチと「Pulumi」の概要

Japanese IT global Comments Off on Infrastructure-as-Codeアプローチと「Pulumi」の概要

はじめに

みなさん、Infrastructure as Code(以下、IaC)は実践されているでしょうか。IaCとは、ネットワーク、サーバー、データベースなどのインフラ構成をプログラムでコード化し、その構築や管理を自動化する手法を指します。変化の激しいビジネス環境に対応するため、ソフトウェアのみならず、インフラの迅速な構築/提供の必要性も日々増してきています。

「Terraform」や「Ansible」など、すでにIaCの代表的なインフラ構成管理ツールを利用されている方も多いかもしれませんが、IaCを始めるにあたっての様々なコストが問題で、なかなかIaCに踏み切れない方もいらっしゃるかもしれません。本連載ではそのような方々の一助になればと思い、より開発者にとって使いやすいインフラ構成管理ツール「Pulumi」を概要から実践まで解説/紹介します。

本連載のレベル感としては、Pulumiを初めて触れる方でも理解できるようにしていきます。また、実践では、実際にPulumiを利用していくつか簡単なAWSのリソース作成や、現場で役立つPulumiの機能を紹介していきます。

初回となる今回は、IaCの基礎知識とPulumiの概要を解説します。

Infrastructure-as-Codeとは

改めて、IaCとはネットワークやサーバーをはじめとするITインフラの構成や設定をコード化して管理・構築の自動化を行うことを指します。例えば、サーバーの構築であれば、ミドルウェア/OSのインストール、アカウントの作成、ツールのインストールなど、サーバーを利用するまでの一連の構築手順を手動で行う必要がありましたが、これらの手順をコード化することにより、手作業で構築するよりも工数が削減できたり、同様のサーバーを複数構築する際も、コードを再利用することで大幅な工数削減が期待できます。

IaCを導入する際の主なメリット/デメリットとして、以下の点が考えられます。

Infrastructure-as-Codeメリット

  • 作業の効率化
    前述の通り、手作業で行っていた構築作業をコード化することで工数を削減したり、一度作成したコードから複数の同じ設定のインフラ構成をデプロイすることも可能になります。また、例えば設定が異なる複数のサーバーについて、一部共通の設定部分が存在する場合は、その部分のみをコードで共通化するなどの運用も可能です。
  • 自動化による人的ミスの削減
    手動による構築作業は高い確率でミスが発生します。似た作業を繰り返し行うようなケースでは特に注意が必要です。手動で行う作業をコード化して、自動的に構築作業を実行することで、これらの人的ミスを削減できます。
  • DevOpsとの親和性
    ソフトウェア同様、インフラの構成もコード化することで、Gitなどのバージョン管理やCI/CDにも活用できます。

Infrastructure-as-Codeデメリット

  • ツールごとの言語/書き方/ルールの学習コスト
    IaCを実現するためのツールごとに、コードの書き方、管理対象のリソース、言語などが異なります。例えば、TerraformはHCL(HashiCorp Configuration Language)という独自言語でリソースの状態を記述する宣言型の構成ツールであり、Ansibleはplaybookと呼ばれるファイルにデータ記述言語であるYAMLで構成手順を記述する手続き型の構成管理ツールになります。他にも様々なツールは存在しますが、そのツールごとの特性やポリシーを理解し、活用するまでの学習コストは、初学者にとって負担であると考えられます。
  • 既存インフラリソースの移行作業
    一般的に、すでに存在するインフラリソースをIaCの管理化に移行する作業は、新たにリソースをIaCで作成するケースよりも工数がかかります。コード化の手間に加え、既存のリソースが正しくコードに置き換えられたかどうか、テストをする必要があります。本番環境などのリソースをコード化する際は、なおさら細心の注意を払う必要があります。

このように、IaCはシステムの規模が大きくなるにつれ、あるいは冗長な構成であるほどそのメリットを発揮しますが、IaCに取り組むまでのハードルが少し高いと考えられます。

今回解説するインフラ構成管理ツールのPulumiは、開発エンジニアやインフラエンジニアが、普段からある程度GoやPythonなどの開発言語を利用しているのであれば、IaCに取り組む上での一部のデメリットを補うことが可能となります。

Pulumiとは

Pulumiの特徴

  • GoやPythonなど複数の汎用言語に対応
    Pulumiの最大の特徴は、GoやPython、JavaScript、TypeScript、C#などの既存の主要な開発言語や、YAMLによる記述に対応している点です。TerraformのHCLのような専用言語はありません。普段のソフトウェア開発同様、Pulumiではインフラを関数やライブラリ、クラスで定義したり、ループ処理やif文処理も容易に行えます。各々の開発言語が普段パッケージを扱うようにPulumiを利用できるため、IDEのサポートも受けやすいです。

    Visual Studio Codeで表示されるPulumi利用時のAWS S3 Bucketのパラメータヒント

  • 複数のクラウド/サービスやKubernetesに対応
    GCP、AWSやAzureなどの主要なパブリッククラウドから、Kubernetesのようなコンテナオーケストレーション、OpenStackなどに対応しており、70以上のクラウドやサービスに対応しています(2022年1月現在)。Pulumiはオープンソースプロジェクトであり現在もアクティブなコミュニティであるため、今後も対応可能なクラウドやサービスは増える予定です。公式で発表されている開発ロードマップはこちらで確認できます。

    AWS/Azure/GCP/Kubernetesなど主要サービスをはじめ様々なサービスに対応

  • インフラのリソースの状態をPulumiで管理
    インフラのリソース状態はPulumiで管理されており、インフラの最終的なあるべき状態だけを意識してプログラムを組むことができます。リソース状態を記録したファイル(state)はデフォルトで、Pulumiが提供するクラウドサービス(Pulumi Service)に保存されます。設定を変更してローカルや他のストレージサービス(AWS S3/GCP CloudStorageなど)にもリソース状態を記録したファイルを保存できます。

    Pulumi Serviceのコンソール画面。stateの管理やリソース変更履歴なども確認できる

その他、Pulumiが提供するクラウドサービスのGUIコンソール画面からソースコードのビルド、テスト、デプロイまでの一通りのパイプライン制御や、auditログの確認、RBAC制御やサポート(有償)などのサービスも利用できます。

Pulumiを導入した企業の一部として、Atlassian、SANS、Skai、Mercedes-Benzなどが紹介されており、GartnerよりPulumiが「Cool Vendor in the May 2020 Gartner Cool Vendors in Agile and DevOps」として認識されるなど、ここ数年で海外での注目度も上がっています。

詳細は後述しますが、Pulumiは無料版と、サポートサービスなどが含まれる有償のエンタープライズ版など、複数のプランが提供されています。個人利用や、チーム利用でも管理対象がある程度のリソース規模であれば無料で利用できるため、気軽にPulumiを試せます。

Pulumiの利用イメージ

Pulumi利用時の流れは、下図のようなイメージになります。この例はJavaScript(index.js)を用いてインフラリソースを定義しているケースですが、他の言語(Python/Go/TypeScript/C#など)を利用した場合もほぼ同様の流れとなります。

  1. Language host
    インフラリソースのあるべき姿を「Program」として、好きな開発言語で定義します(JavaScriptなら「index.js」、Goなら「main.go」、Pythonなら「__main__.py」など)。「Language host」はPulumi CLIインストール時に開発言語ごとに用意されるpluginで、Programの実行を担います。インフラリソース作成時に自動的にLanguage hostが実行されます。
  2. new Resource()
    インフラリソース作成(更新)時はCLIにてPulumiコマンド(pulumi up)を実行します。コマンド実行時に新たなリソースが検知されると(JavaScriptなら「new Resource()」、Goなら「NewResource()」、Pythonなら「Resource()」などのクラスを経由して)、Pulumi CLI内部のプログラム「Engine」が検知した情報を受け取り、リソースのあるべき姿「Program」と、あらかじめPulumi Service等で保存されている現在のリソース状態「State」を比較し、次のアクション(リソースを作成するか、更新するかなど)が決定されます。
  3. Create/Update/Delete
    リソースのアクションが決まったら、AWS/Azure/GCPなど、ぞれぞれのサービスに対応したプラグインを用いて、実際にリソースが作成/更新されます。
  4. Write new state
    インフラリソースの作成/更新が成功したら、現在のStateを更新します。基本的にはProgramを作成して、Pulumiコマンドを実行(実際のインフラリソースの作成/更新)するとリソースが作成/更新されます。その他の細かい処理(new Resource()による新しいリソースの検知、Engineの処理など)はPulumiで自動的に実行されるプロセスとなります。

上図の利用イメージではPulumiコマンドの手動実行によるリソースの作成について記載していますが、GitHub ActionsやJenkinsなどのCI/CDシステムと連携させて、例えばProgramをGitなどのソースコードレポジトリにPushすると、lintなどでコードチェック後にPulumiコマンド(インフラ作成)を自動実行させるなどのCI/CDも実現できます。

Pulumiは様々なCI/CDシステムに対応しています。詳細は、こちらを参照してください。

Original Post>