IBM Cloud Pak for Multicloud Managementシリーズ(第3弾)"Infrastructure Management"
投稿者：クラウド・テクニカルセールスエンジニア
今回のブログ内容でご紹介する内容をウェビナーデモでもご紹介中です。
https://wcc.on24.com/webcast/previewlobby?e=2763540&k=AE09C7F14F5FC8033C7A8FA677E9C578
公開期限：2021年9月まで
第3回：Infrastructure Managementについて
・始めに
こんにちは。NI+C小野です。
本ブログでは私が今年度より担当しているIBM Cloud Paksやコンテナ技術について、そこで得た知識や学びを紹介していきます。
第3回でも引き続きIBM Cloud Pak for Multicloud Management(以下MCM)に内包されている、ソフトウェアの一つInfrastructure Managementについて取りまとめていきます。
Infrastructure Managementの土台となる、IBM Cloud Paksや他の内包ソフトウェアについては第1回、第２回にて説明をしていますので、是非ご覧ください。
第1回(https://www.niandc.co.jp/sol/tech/date20201009_1892.php)
第2回(https://www.niandc.co.jp/sol/tech/date20201203_1940.php)
・Infrastructure Managementについて
ー製品説明
>Infrastructure Managementとは？
Infrastructure Managementの主な機能は、自動的なマルチクラウドやハイブリッドクラウドの構築や運用実現することです。
Infrastructure Managementからマルチクラウドを管理すると、各クラウドの専用ポータルを通さずにインフラを構築・管理できるため、全てのクラウドを一つのポータルから管理できます。また、構築・管理を自動化できることがInfrastructure Management独自の利点です。
現在、クラウドサービスは多くの企業で利用されています。しかしクラウドサービスの普及により複数のクラウド環境を利用することが増え、IT運用担当者の業務量の増加や複数クラウド環境に対するスキル習得が必要です。
＜発生する課題や悩み＞
・各パブリッククラウドごとの専用ポータル有識者の育成や調達が困難
・手作業によるヒューマンエラーの発生や品質のばらつき
・プロビジョニングや設定作業を自動化して運用コストや時間の削減をしたい
Infrastructure ManagementはInfrastructure as Codeという考え方を採用し、上記の課題や悩みを解決します。
※Infrastructure as Codeとは？
クラウド環境や仮想基盤環境でサーバを構築するためには、プロビジョニングやOS導入、設定を行い、非機能ソフトウェアも同様に導入や設定を行う必要がある。
これらを複数台同時に準備するには時間やコストが大幅にかかる。
→これらの問題を解決するために一連の手順をコードでテンプレート化し、自動的に処理を実施させ、時間やコスト、稼働を削減しようという考え方。
＜主なメリット＞
・インフラの構築・変更を自動化できるため、ヒューマンエラーの予防や時間の削減が可能
・作成したコードは繰り返し利用できるため、プロビジョニングや設定作業の時間を削減しつつ、品質を均一化
・コードをエビデンスとして利用でき、システム改修時も構成等の確認が簡単
ー3つのソフトウェア
Infrastructure Managementは3つのソフトウェアで構成されています。
それぞれを活用することで、クラウドのプロビジョニングやOS・ミドルウェアの導入、マルチクラウド・ハイブリッドクラウドの統合管理を実現します。
〇Terraform(IBM社の呼称はService Management)
Terraformは主にクラウドリソースのプロビジョニングを担当します。
Terraformはクラウド環境をコードで記述できます。
そして、コード通りの環境をプロビジョニング可能です。
作成したコードさえ保存しておけば、何度も同じ構成で環境を作成できます。
これによりプロビジョニングや設定作業を自動化し、ヒューマンエラーの予防や、時間の削減が可能です。
〇Ansible(IBM社の呼称はAnsible Automation )
Ansibleはそもそも構成管理やDay2運用を自動化するツールですが、Infrastructure Management内では、OS・ミドルウェアの導入構成や運用時における構成変更を担います。
Playbookと呼ばれるファイルに設定したいパラメータを記載するだけで、自動的にミドルウェアやOSの導入・設定が可能です。
Terraformのコードと同じようにPlaybookさえ保存しておけば、何度も同じ構成で導入や設定ができます。
また、繰り返し実施するDay2運用の処理も可能です。
これによりOS・ミドルウェアの導入や運用を自動化し、ヒューマンエラーの予防や、時間の削減が可能です。
〇CloudForms(IBM社の呼称はInfrastructure Management)
Cloud Formsはマルチクラウド・ハイブリッドクラウド全体の統合管理を担当します。
マルチクラウド・ハイブリッドクラウドのサーバの構成や稼働状況を収集し、ダッシュボードにて確認できます。
クラウドプロバイダーごとのポータルにアクセスせず、マルチクラウド・ハイブリッドクラウドの環境を管理できます。
また、レポート作成も可能です。これによりマルチクラウド環境をまとめて管理ができるため、各環境ごとに管理をする必要がなく稼働の削減や統合管理の実現が可能です。
今回は上記3つの機能の中からTerraformとAnsibleを利用して検証を行いました。
その際のまとめを記載します。
・Infrastructure Managementの検証
ー検証概要
今回の検証は、Infrastructure Managementの強みである自動化に観点を絞り、自動構築のメリットを確認する検証を行います。
内容は、TerraformとAnsibleを利用し、Webシステム(仮想サーバやロードバランサーで構成されている)を自動構築しました。
Terraformでクラウド環境の構築をし、Ansibleでサーバの設定(監視Agentやウイルス対策ソフトウェアの導入・設定)をしました。
実際に検証を行った環境は、以下の環境です。
Infrastructure Managementの環境は第1回、第2回の時に利用した環境とほぼ同じ環境を利用しました。違いとしては、MCM上にInfrastructure Managementが存在することです。
Webシステムの自動構築先はAWSを利用しました。
〈Infrastructure Management導入環境構成〉
・Infrastructure Management
・IBM Cloud Pak for Multicloud Management
・OpenShift
・VMware vSphere
・ベアメタルサーバ(IBM Cloud)
〈自動構築先環境〉
AWS 東京リージョン
ー検証前提
今回の検証は下記前提を基に行っています。
・AWSのアカウントは作成済み
・AWSにてアクセスキーとシークレットアクセスキーを作成済み
・作業用PCは準備済み
・AWS環境に接続可能なインターネット環境が設定済み
ー検証準備
今回は検証を行うための準備として、以下の作業を行いました。
＜導入＞
OpenShift
MCM
Terraform
Ansible
＜アカウント連携＞
TerraformとAWS連携
MCMとAnsible連携
ここでは各種導入や連携方法について簡単に説明していきます。
※OpenShiftやMCMの導入は第1回と同じ作業なため、第1回の記事をご覧ください。
(https://www.niandc.co.jp/sol/tech/date20201009_1892.php)
＜導入＞
Terraform
Terraformの導入は第1回のMonitoringと同じようにYamlを変更し導入します。
OpenShiftコンソール画面にてIBM Cloud Pak for Multicloud Managementを選択後、タブより[Yaml]をクリックします。
[Yaml]を選択後、下記画面にアクセスできます。
下記画面より直接変更が可能なため、変更箇所を変更し適応するとTerraformの導入が完了です。
変更が完了したら左下にある[Save]をクリックします。
Yamlの変更内容は下記を参考にしてください。
-Yaml修正内容-
修正前
enabled: false
name: infrastructureManagement
修正後
enabled: true
name: infrastructureManagement
[Save]をクリック後、下記画面に移行します。
StatusがUpdatingからRunningに変わりましたら、これでTerraformの導入は完了です。
Ansible
Ansibleの導入はIBM社がWebで公開しているマニュアルを参考に導入しました。www.ibm.com/support/knowledgecenter/ja/SSFC4F_2.0.0/install/ansible_tower.html
導入はCLIにて行い、マニュアルに記載されている手順に沿ってコマンドを入力していきました。
導入の際に注意点がありましたので、次項にまとめました。
-Ansible導入時の注意点-
注意点１
Ansibleを対象環境に導入する前に作業端末(Linux)に対してAnsibleを導入する必要がありました。
そのためCLIで下記コマンドを実行し、作業端末(Linux)にAnsibleを導入致しました。
-コマンド例-
# sudo yum install ansible
コマンドを実行後[完了しました！]という表示がでたら作業端末に対してのAnsible導入は完了です。
注意点2
Ansibleを対象環境に導入する前に作業端末(Linux)に対してPython及びlibselinux-pythonを導入する必要がありました。
今回の検証ではPython2を導入しました。。
-Pythonインストールコマンド例-
# yum install python2
# dnf module enable libselinux-python
# dnf install libselinux-python
これでPythonの導入は完了です。
上記2点を実施後、マニュアルの手順通りにコマンドを実施し、Ansibleの導入を行いました。
＜アカウント連携＞
TerraformとAWSの連携
仮想サーバを自動構築するクラウド先を登録します。
今回はAWSを自動構築先として選択しました。
連携はMCMのGUIより行います。
MCMのホーム画面より左上のタブから[Automation Infrastructure]配下にある[Manage services]をクリックします。
クリックするとサービス・ライブラリーの管理画面にアクセスできます。
サービス・ライブラリーの管理画面にアクセス後、再度左上のタブをクリックします。
クリック後、リストが表示されます。
リストから[Manage]配下にある[Cloud connections]をクリックします。
クリック後、クラウド接続の画面にアクセスできます。
クラウド接続の画面より[接続の作成]をクリックします。
クリック後、接続の作成画面にアクセスできます。
ここから利用するクラウドを登録します。
名前空間の選択では[接続をグローバルにアクセス可能にする]を選択します。
クラウド・プロバイダーの選択ではリストから選択できるので、リストから対象のクラウド選択します。
(今回利用するプロバイダーはAWSなので、Amazon EC2を選択します。)
接続名には任意の接続名を入力してください。
(今回はAWS_EC2_Tokyoと入力します。)
先ほど、設定した画面から下にスクロールすると接続先の情報を入力する画面となります。
利用するクラウドプロバイダーによって入力する内容は異なります。
今回は利用プロバイダーがAWSなので、アクセスキーとシークレットアクセスキー、利用リージョンを選択しました。
ここでは、事前にAWSにて取得した、アクセスキーとシークレットアクセスキーを入力してください。
入力が完了したら、右下の[作成]をクリックします。
クリック後、クラウド接続の画面に戻ります。
クラウド接続画面に移るので、下記のように登録したクラウドプロバイダーが一覧に表示されます。状況が有効になっていることを確認します。
これでMCMとAWSの連携は完了です。
MCMとAnsibleの連携
MCMとAnsibleの連携はIBM社がWebで公開しているマニュアルを参考に連携しました。
www.ibm.com/support/knowledgecenter/ja/SSFC4F_2.0.0/install/ansible_tower.html
作業はCLIにて行い、マニュアルに記載されている手順に沿ってコマンドを入力していきました。
連携の際に1点注意点がありました。
注意点
マニュアルの手順4にて-tは必須パラメーターという記載があります。
スクリプト上そのようなオプションはありません。
そのため-aを指定しました。
-コマンド例-
# ./automation-navigation-updates.sh -a ansible-tower
上記コマンドを実行後[Success!]という表示がでたら連携は完了です。
連携完了後、MCMのポータルで確認するとタブ内に[Ansible automation]のメニューが表示されます。
これで検証の準備は完了です。
次から実際の検証内容の説明に移ります。
ー検証内容
ここからは実際の検証内容と検証手順について記載します。
検証の内容としてはTerraformとAnsibleを利用してWebシステムの自動構築を行いました。こちらが検証のイメージ図となっております。
・検証の手順
1.Terraformのテンプレートを作成
2.AnsibleのPlaybook(テンプレート)を作成
3.Ansibleの設定
4.サービスの作成
5.サービスの実行
6.サービスの自動処理実行
7.Webシステムの確認
また、自動構築する詳細は以下の通りです。
自動構築内容
＜AWS＞
仮想サーバ
ロードバランサー
＜仮想サーバ内＞
監視Agent(ICAM)
ウィルス対策ソフトウェア
Webサーバソフトウェア
Webコンテンツの配置
次に各手順の詳細を記載します。
1.Terraformのテンプレートを作成
Terraformのテンプレートを作成するためにコードを記述します。
今回コードで作成するテンプレートの内容は下記の通りです。
・EC2インスタンス作成
・ロードバランサー作成
・ネットワーク接続設定
・負荷分散定義の設定
コード等はTerraformのオフィシャルマニュアルを参考に作成しました。
https://www.terraform.io/docs/configuration/index.html
また、MCMにはGUIよりコードを編集するツール(Template Designer)があるので、CLIとGUIの両方でコード編集が可能です。
下記に一部抜粋ですが、コードを記載いたしますのでご参考ください。
また、実際には一つのファイルに上記で記載したテンプレートの内容を全て記載しております。
-負荷分散定義のコード例-
resource “aws_alb_target_group” “alb” {
name = “${var.system_tag}-applb-target-group”
port = 80
protocol = “HTTP”
vpc_id = “${var.vpc_id}”
health_check {
interval = 30
path = “/index.html”
port = 80
protocol = “HTTP”
timeout = 5
unhealthy_threshold = 2
matcher = 200
}
}
resource “aws_alb_listener” “alb” {
load_balancer_arn = “${aws_alb.alb.arn}”
port = “80”
protocol = “HTTP”
default_action {
type = “forward”
target_group_arn = “${aws_alb_target_group.alb.arn}”
}
}
resource “aws_alb_target_group_attachment” “alb01” {
target_group_arn = “${aws_alb_target_group.alb.arn}”
port = 80
target_id = “${aws_instance.webserver01.id}”
}
コードが完成したらInfrastructure Managementと連携できるようにGitHub上に登録します。
以下画面がGitHubに登録した画面となっております。
こちらのURLを後ほど使うので忘れずコピーしておいてください。
2.AnsibleのPlaybook(テンプレート)を作成
AnsibleのPlaybookを作成するためにコードを記述します。
今回コードで作成するテンプレートの内容は下記の通りです。
・監視Agentソフトウェア導入設定
・ウイルス対策ソフトウェア導入設定
・Webサーバソフトウェア導入設定
・Webシステムの取得/配置
※各ソフトウェア導入する際に、対象ソフトウェア導入の有無を確認し、未導入の場合に導入・設定を行います。
PlaybookのコードはAnsibleのオフィシャルサイトを参考に作成いたしました。
https://docs.ansible.com/ansible/2.9_ja/user_guide/playbooks_intro.html
下記に一部抜粋ですが、コードを記載いたしますのでご参考ください。
また、実際には一つのファイルに上記で記載したテンプレートの内容を全て記載しております。
-Webサーバソフトウェア導入設定コード例-
name: Webserver Setup
hosts: all
become: yes
tasks:
– name: Installation Apache
yum:
name: httpd
state: latest
– name: Installation wget command
yum:
name: wget
state: latest
コードが完成したらTerraformと同じくInfrastructure Managementと連携するためGitHub上に登録します。
以下画面がGitHubに登録した画面となっております。
こちらのURLを後ほど使うので忘れずコピーしておいてください。
3.Ansibleの設定
手順2.で作成したPlaybookの設定等をAnsibleに行っていきます。
主にAnsibleの設定はAnsibleのマニュアルに沿って作成しました。
下記に概要とURLを記載しているのでご確認ください。
① AWSへの接続設定
https://docs.ansible.com/ansible-tower/3.6.0/html_ja/userguide/credentials.html#amazon-web-services
② インベントリーの定義
https://docs.ansible.com/ansible-tower/3.6.0/html_ja/userguide/inventories.html#ug-source-ec2
4.サービスの作成
Infrastructure Managementでは複数の自動処理を組み合わせて一つのサービスを作成できます。
始めに、TerraformのテンプレートとInfrastructure Managementを連携する必要があります。
サービス・ライブラリーの管理画面より[Terraformテンプレート]タブを選択後、[テンプレートのインポート]をクリックします。
クリック後、テンプレートインポートのPOPが出てきます。
テンプレートのインポートPOPに対して値を入力していきます。
今回、テンプレートはGitHub上に保存したので、テンプレート・ソースのインポートはGitHubを選択します。
GitHubリポジトリ―URLは、テンプレートを保存したGitHubのURLを入力します。
その後右下にある[インポート]をクリックします。
クリック後、テンプレートの概要を入力する画面になります。
概要画面ではテンプレートの名前や説明を入力します。
任意の名前や説明を入力して、右上の保存ボタンをクリックします。
(今回、名前はDemo Aws Webapp Serviceと入力しています。）
クリック後、サービス・ライブラリーの管理画面に戻ります。
サービス・ライブラリーの管理画面に戻ってきたら、先ほどインポートしたサービスを確認します。
下記の通り、設定した名前(Demo Aws Webapp Service)のサービスが一覧に表示されています。
これで、テンプレートの連携は終了です。
ここからは、先ほど作成したテンプレートとPlaybookを利用してサービスを作成します。
サービス・ライブラリーの管理画面より[サービスの作成]をクリックします。
クリック後、下記POPが表示されるので入力していきます。
サービス名は作成するサービスの名前を入力します。
検証では[Demo Aws Webapp Service]と入力します。
バージョン名の書式は必ず1.0.0.0などの4つの数字で記載してください。
カテゴリーは利用者がサービスの種別に合わせて任意のカテゴリから選択できます。
今回は[Hybrid Cloud]を選択します。
値が入力出来たら左下にある[作成]をクリックします。
[作成]をクリック後、作成したサービスの画面に移るので、[構成]タブを選択します。
こちらで先ほど作成したTerraformのテンプレートとAnsibleのPlaybookをGUI上から導入します。
導入方法としては左側のリストから対応のアイコンを選択し、1次フローにドラック&ドロップします。
ドラック&ドロップ後、処理順に左の〇から繋げたら完成です。
今回の場合、Terraformの処理が先なので、左側にTerraformの処理を置き、Ansibleを右側に置きます。
次に、AWSのリージョン等を事前に定義します。
事前に定義した項目は、サービスをデプロイする際に設定済みで払い出されるためユーザ側がデプロイする際に入力する項目を制限することができます。
[パラメータ]タブを選択後、下記画面が表示されるので変更したい、項目を選択します。
(今回はAWSのリージョンを変更設定するのでリージョンの項目を選択します。)
項目の右端に3つの点が表示されるので、選択後[編集]をクリックします。
[編集]をクリックすると、リージョンを選択する画面に移動します。
パラメータの編集画面になります。
[値の選択]に利用するリージョンを入力します。
(検証ではAsia Pacific(Tokyo)を入力します。 )
リージョンを選択後、下にスクロールして[保存]をクリックします。
これで事前定義の完了です。
事前定義完了後、パラメータ画面に自動で戻ります。
その後、サービス自体を保存する必要があるので、右上にある[保存]タブをクリックし、サービスの保存をします。
これでサービスの作成が完了です。
5.AWS上にサービスの実行
手順3にて作成したサービスを実行しAWS上にサーバを構築します。
作成したサービスを選択し、[デプロイ]をクリックします。
概要はそのまま、[次へ]をクリックします。
下記画面では名前空間やサービス・インスタンス名を入力します。
必須入力は名前空間・サービスインスタンス名・Environment(環境)です。
今回サービスインスタンス名は”WebAppsys01″にします。
下にスクロールするとインスタンス名やリージョンを選択する画面になります。
今回はサービスを作成した時に、初期値を事前定義済みなのでデフォルトのまま利用します。
内容を確認したら、右下にある[デプロイ]をクリックします。
これで、サービスの実行は完了です。
6.サービスの自動処理実行
サービスが自動的に処理をされているか確認します。
[デプロイ]をクリック後、下記POPが表示されます。
インスタンスのデプロイ状況を確認するため[インスタンスに移動]をクリックします。
クリック後、デプロイ済みインスタンス画面が表示されます。
実際に設定した、名前のインスタンスがデプロイされています。
デプロイ状況の詳細を確認するためにインスタンス名をクリックします。
クリック後、ログ画面が表示されます。
こちらの画面ではログが確認できます。
リアルタイムで更新されるため、正常にデプロイされているか確認できます。
WebAppsys01-00-instとWebAppsys01-01-instの2つが表示されていますが、
WebAppsys01-00-instを選択するとTerraformのログが表示されます。
WebAppsys01-01-instを選択するとAnsibleのログが表示されます。
デプロイが完了すると概要タブのアクションのリストに[デプロイメントが完了しました]という表示が出ます。
これでWebシステムのデプロイは完了です。
実際にAWSのポータルで仮想サーバがデプロイされているか確認してみると、設定したインスタンス名であるWebAppSys01-Webserver01がデプロイされています。
ロードバランサーも同様に設定した物がデプロイされています。
7.Webシステムの確認
Webシステムにアクセスが可能となるので、AWSのロードバランサに接続します。
ロードバランサに表記されているDNS名をコピーしアクセスします。
下記の通り、Web画面が表示されました。
結果
テンプレートとPlaybookで作成したサービス通りにサーバのデプロイやOSの設定が行われました。
一度サービスを作成すれば、同じ構成のシステムを容易に追加作成することが可能です。
今まではデプロイするごとに発生していた各種設定やインストールの作業が自動的に行われるため、インフラ担当者の環境構築の稼働やコストの削減、ヒューマンエラーの予防に繋がると考えています。
・まとめ
本記事でInfrastructure Managementについて少しでも理解を深めるための一助となっていれば幸いです。
今回検証した機能以外にInfrastructure ManagementにはCloud Formsが内包されており、当ソフトウェアを活用することで、ハイブリッドクラウドやマルチクラウドの環境情報を自動集約可能となります。
今回で一旦MCMの内容は終了となります。
MCMを活用することでマルチクラウド・ハイブリッドクラウド環境の統合管理と自動化を実現することができます。これによりユーザのインフラ基盤運用業務負荷を軽減し、品質向上につながります。
一つでもご興味を持っていただけましたら、是非MCMをご検討してみてはいかがでしょうか。
今後も他のIBM Cloud Paksやコンテナ関連情報を発信していきたいと思いますのでお楽しみにしていただければ幸いです。
この記事に関するご質問等があれば「こちら」からお問い合わせください。
担当者からご連絡させていただきます。
