Text＝北野 龍二、豊田 穣 （日本アイ・ビー・エム システムズ・エンジニアリング）
IBM Cloud Schematics 環境構築の流れ
環境の構築、変更、破棄の流れ
IBM Cloud Schematicsを利用して、IBM Cloud上に環境を構築する際の流れを図表4に示す。
環境構築
IBM Cloud Schematicsで、専用のワークスペースを用意して管理するプラットフォームを準備する。
コードをGitHub上に配置し、GitHubからコードをPullすることでSchematicsワークスペースに配置する。Terraformを使ってインフラストラクチャを構築／管理する主なコマンドは、terraform init、 terraform plan、terraform show、terraform apply、terraform destoryの5つであり、該当する挙動がIBM Cloud Schematicsでも存在する。
❶ ワークスペースの作成
ローカルマシンのTerraformでは、定義ファイル（.tf）を準備して、terraform initコマンドで作業ディレクトリを初期化する。必要なPluginがダウンロードされ、Terraformを実行できる準備が整う。
Schematicsワークスペースの作成時に渡したリポジトリやワークスペースの設定に問題がなければ、Schematicsワークスペースを作成した時点で、Terraformを実行する環境が整う。
❷ プランの作成（terraform init, terraform plan）
次に、terraform planコマンドで実行計画を参照する。コードに不備がないか、作成されるリソースや作成済みのリソースとの差分を参照できる。
Schematicワークスペースではプランの作成が該当する。プランの作成によって生成されるLogを図表5に示す。
❸ プランの適用（terraform init, terraform apply）
terraform planに問題がなければ、terraform applyコマンドでコードに定義されたリソースの作成／変更／削除を実行する。Schematicsワークスペースでは、プランの適用が該当する。
terraform planでのリソースの作成後はterraform.stateというファイルが作成され、Terraformにて作成されたリソースが管理される。
Schematicsワークスペースでは、このterraform.stateというファイルを直接参照することはできないが、現在のリソースの状態を参照するコマンドであるterraform showに該当する操作は、Schematicsワークスペースでは管理下にある作成済みのリソースや実行ログから確認できる。
プランの適用によって生成されるLogを図表6に示す。
プランの作成もしくはプランの適用が完了すると、図表7のように追加／変更／破棄するリソースの数が確認できる。
❹ 環境変更
環境の変更には2パターンある。1つはInfrastructure Codeを変更する。もう1つは手動でリソースの状態を変更する方法である。
1つ目は、コードを通して環境にデプロイ済みのリソースを変更する方法である。コードに追記や削除の修正を加え、terraform planをすることで、再度リソースに対して変更が加えられる。
IBM Cloud Schematicでも同様に、GitHubに修正をPushし、Schematicsワークスペースから最新コードをPullする必要がある。
例としては、Object StorageのBucketを3つから4つに変更したい場合である。追加のResourceブロックをコードに加え、ワークスペースでプランの適用することで管理しているリソースに対して追加や削除等の変更がされる。
2つ目は、コードを通さずに変更する場合である。すでに作成されたリソースに対して、手動で設定を追加する際に用いる。
この場合、Schematicsワークスペースが保持しているIBM Cloud上のリソースの状態を記録したTerraform状態ファイルと差分が生じている状態となる。差分を解消するため、ドリフトの検出と呼ばれる作業が発生し、手動で変更を行った際にはTerraform状態ファイルを現在のリソースの状態に更新する必要がある。
たとえば、パブリックエンドポイントが無効なリソースをTerraformでデプロイしており、手作業でパブリックエンドポイントをオンにした場合である。急な修正が必要で手作業により実施した場合は、この方法を選択できる。
変更がソースコードと異なるため、コード側の修正はどこかのタイミングで行う。ただし新規にリソースを追加したい場合は、コードを修正してプランの作成を実施する。
❺ 環境破棄
TerraformやSchematicsワークスペースで作成したリソースは、一括でのリソース破棄が可能である。Terraform状態ファイルで管理されたリソースをterraform destroyコマンドを実行することで逐次削除される。Schematicsワークスペースでは、リソースの削除が該当する。
ただし、リソースごとに定められた破棄の前提条件があるのであれば、破棄前に実施する。例としては、Object StorageのBucket削除である。Bucket内部にObjectが残っていると削除できない。
続いてSchematicsワークスペースでの画面操作について図表8～図表10に主要な画面操作を示す。
また図表11に主要な設定ファイル一覧を示す。
設定タブでは、TerraformテンプレートをGitHubからPullすることで、ワークスペースのコンテナ内へインポートできる。インポートの際に、HCLのブロックと呼ばれる構文をチェックしているので、構文エラーを発見すると、ワークスペースの状態が「アクティブ」ではなくなる。
また定義ファイルで定義した変数の一覧を確認でき、デフォルト値を設定していた場合は値が表示される。定義ファイルは、インポート後に上書きすることができるため、コード側で修正の必要がない。
ジョブタブでは、Schematics ワークスペースの作成、プランの作成やプランの適用、Pull等のワークスペース上で実施される操作Logが表示される。各Logを展開することで、図表5 および図表6に示したような詳細なLogを表示できる。
リソースタブでは、デプロイされたResourceブロックやリソース名が一覧表示され、どのリソースがIBM Cloud Schematicsの管理対象となっているかを一目で確認できる。
Hint & Tips
次にInfrastructure as Codeで準備、管理する工程でのHint & Tipsを記載する。
Infrastructure Codeの準備
Terraformの設定ファイルは公式サイトが記述方法を掲載しているため、参照することで構成図に沿ったリソースの記述方法を学べる。
設定ファイルの基本構成は、variable.tf, main.tfの2つで、記述が正しければデプロイが実行される。variable.tfにはmain.tfが呼びだすリソースの接頭辞やバージョン、フレーバの変数名を記載する。設定ファイルは、量や要件に応じて分割して記述することも可能である。
コードの管理
GitHubにて複数の環境のコードを管理し、それぞれ修正を継続する場合、コードの管理方法の容易さは要件等で決まる。
筆者からは、2パターンの管理方法を提案する。
1つは、ブランチを1つに絞り、複数環境を管理する方法（図表12）、もう1つはBranchをフォーク/Branchを切って、それぞれのBranchで1つずつ、各環境を管理する方法（図表13）である。
前者は管理が容易になる反面、GitHub上でLogが煩雑になるので、Logを追いづらい。また複数人が別々の環境を管理していると、変更を同期させるのに労力を費やす場合がある。
後者では、環境ごとにBranchを切っているので、Logが独立した環境のものとなり、管理が容易である。また複数名が別々の環境を触ってもBranchが分かれているので、同期させる労力は前者よりも小さく抑えられる。
TerraformとIBM Cloud Schematicsについて
メリット
IBM Cloud SchematicsはJSONやYAMLといった言語で書かれる独自のテンプレートではなく、Terraformを用いて書かれている。
そのため、IBM Cloudにリソースを払い出す際はIBM Cloud Schematicsを利用することで、Terraform実行基盤や管理をローカルマシンやリモートサーバーに用意する必要がなく、整備されたUIを持つマネージドのTerraform実行基盤を利用できる。
専用のコンテナ上でTerraformが実行されるため、実行中にローカルマシンのリソース専有に気を使う必要はなく、時間経過でデプロイが完了する。
デメリット
簡単なものであれば、UIで操作できてしまうので、偶発的な操作ミスが起こる可能性がある。たとえば、リソースの破棄である。リソースの破棄ボタンはアクションボタンの中にあり、さらに破棄前に確認はされるが、注意が必要である。
Terraformに記述するリソースと手動で作成するリソースの判断材料
Terraformは冪等性が担保されていると述べた。つまり、何度環境を作成しても同じ結果が得られるため、同一環境を作成する際に事前記述するTerraformのメリットが生まれる。
例を挙げると、VPCやサブネット、IBM Cloud Kubernetes Service、IBM Cloud Object Storageなど別環境でも再利用する頻度が高い場合は、設定ファイルとして事前記述しておくことで、デプロイが容易になる。
対して、その時の要件に合わせて何度か書き換える必要がある場合、あるいは手動で構築／変更するほうが速い場合などは、Terraformには記述せずに、手動で構築する。
また、設定ファイルを作成する際は記述してもリソースの制約で作成できないことがある。例を挙げると、Secrets Managerは1アカウントごとに1インスタンス、Activity Trackerは1リージョンごとに1インスタンスなどである。
最後に
ここまで、クラウド構築自動化の際に検討が必要な内容および具体的な操作方法について記述した。自動化については、次に挙げるようなメリットが考えられる。
❶ インフラストラクチャ構築の効率化とスピードアップ
（1） 1つ1つ手作業で作成／設定／確認の作業を行うわけではなく、リソース作成サービスが自動的に作成／設定／確認を行うため、構築の時間短縮につながる
（2） 事前に作成した設定（プラン）を検証し、テストすることで、環境構築のスピードを向上させられる
（3） 変更があった場合も設定の一部を変更して実行することで、関連するコンポーネントが自動的に変更される
❷ コード化によるインフラストラクチャ状態の把握しやすさ／再利用のしやすさ
（1） コード化することにより、これまでのExcelなどで作っていたパラメータシートに比べて、よりインフラストラクチャ設定などが理解しやすくなる
（2） インフラストラクチャ（デプロイ）の状態を持っているので、設計時と異なる状態であっても容易に把握が可能である
❸ バージョン管理と人為的ミスの低減
（1） GitHubなどのバージョン管理（ブランチ）を利用することで、インフラストラクチャ状態のバージョン管理が容易になる
（2） バージョン管理システムによる変更のトラッキングにより、いつ／何を変更したのかが簡単に追跡可能となる
（3） 環境に問題が発生した場合のロールバックも容易になる
（4） 直接変更を実施しないため、作業ミスを未然に防ぐことが期待される
❹ セキュリティの向上
（1） クラウドの状態を一括して管理することにより、セキュリティーポリシーの統一／権限の一貫性を保つことが容易になる
（2） 人為的ミスによりクラウド環境の権限変更を行い、セキュリティ事故が発生するなどのエラーを防げる
（3） インフラストラクチャ変更に関する権限を特定の人などに絞ることが可能なため、セキュリティの向上につながる
❺ 拡張性
（1） ツールの使い方自体は共通であり、多数のクラウドプロバイダー／サービスに対応しておりスキルの有効活用が可能である
（2） クラウドサービスの機能追加／変更があった場合でも、対応するモジュールを入れ替えるだけで設定変更などせずに利用可能である
（3） リソースの新規追加もtfファイルを追加するだけなので、容易である
クラウド構築の自動化を適用することにより、既存の構築作業で発生していた種々の問題（技術的／プロセス／人為的なもの）の解決につながると考えられるため、クラウド環境構築を計画する場合、一度検討してみることを強く推奨する。
著者
北野 龍二氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
著者
豊田 穣氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
［i Magazine・IS magazine］
