APC Automation blog

ネットワーク自動化支援のAutomation Coordinatorを提供する、エーピーコミュニケーションズ ACTの自動化ブログ

TerraformとAnsibleの連携「効率的なITインフラ運用の実現」

はじめに

こんにちは、iTOC事業部ACTのエンジニアKです。
IaCツールで有名なものとしてTerraformとAnsibleがありますが、これらはどちらもコードとしてインフラを定義し管理します。
そのため、どちらか片方のツールのみでもインフラプロビジョニングは可能です。
ですが、AnsibleとTerraformを組み合わせることで効率的なITインフラ運用を実現することができます。
そこで今回はAnsibleとTerraformの連携について紹介します。
業務等でAnsibleやTerraformを使用されている方に読んでいただきたい内容です。

AnsibleとTerraformの違いについて

まずは本記事で扱うAnsibleとTerraformの違いについて簡単に説明します。
・得意な領域が異なるため、自動化を行いたい対象や範囲によって使うツールを選び使い分ける ・オンプレミスのNW機器やセキュリティ製品、OSレイヤ以上の自動化はAnsibleが得意とする領域 ・ハイパーバイザーやクラウドサービス上のインフラリソースの自動化はTerraformが得意とする領域 違いについて、より詳細に知りたい方は、弊ブログにそれぞれを解説した記事があるのでそちらを参照してください。
AnsibleとTerraformの違い、使い分けについて

連携することのメリット

ここからはAnsibleとTerraformの得意領域について言及しつつ、連携することのメリットを説明します。

①インフラのプロビジョニングと構成管理の統合

Terraformはインフラのプロビジョニングに優れており、クラウドリソースの作成や管理をコードで行います。
一方、Ansibleは構成管理に強く、サーバやアプリケーションの設定をコードで自動化します。
AnsibleとTerraformを連携することにより、インフラのセットアップからアプリケーションのデプロイまで、一貫した自動化が可能になります。

②柔軟性の向上

Terraformの宣言型アプローチとAnsibleの手続き型アプローチを組み合わせることで、複雑なインフラとアプリケーションの管理がより柔軟に行えます。
Terraformでインフラの状態を定義し、Ansibleで詳細な設定やデプロイを行うことで、より細かい制御が可能になります。

③一貫性と再現性の確保

両ツールを併せて使用することで、インフラとアプリケーションの設定がコードとして管理されるため、一貫性と再現性が向上します。
これにより、環境間での差異を減らし、デプロイの信頼性を高めることができます。

3点のメリットを簡単にまとめると、「AnsibleはGUIで管理をするがTerraformはコードで管理をするため、AnsibleとTerraformを連携すると、インターフェースがひとつに統一できるから管理が楽になる」です。

連携の方法

AnsibleからTerraformを呼び出す方法にはいくつかのアプローチがあります。以下にその方法を説明します。

①ansible.builtin.shellモジュールの利用

ansible.builtin.shellモジュールを使用して、シェルコマンドとしてTerraformを実行する方法もあります。
この方法では、Ansibleタスク内で直接terraform initやterraform applyなどのコマンドを実行します。

②cloud.terraformコレクションの利用

Ansibleのcloud.terraform.terraformモジュールを利用して、Terraformプロジェクトを呼び出すことができます。
このモジュールを使うことで、Ansible Playbook内で直接Terraformの操作を行うことが可能です。   cloud.terraformモジュールはterraformを呼び出す際の設定をyaml形式で入れることができるため視認性が上がります。
またoutputを構造化してくれるのでその後の処理などでも使いやすくなります。
次項目にてcloud.terraformモジュールを詳しく紹介します。

cloud.terraformモジュールの紹介

Ansibleでcloud.terraformモジュールを使用してTerraformを実行する簡単なコードを例に説明します。

以下のコード例は、AnsibleのPlaybookでTerraformを実行し、指定されたプロジェクトパス内のTerraform設定ファイルを適用するものです。

まず、ディレクトリ構成は以下のようにします。

.
├── terraform_test_playbook.yml
└── terraform
    └── main.tf

Terraform設定ファイル(main.tfと) main.tfとvariables.tfには、Terraformの設定を記述します。 ここでは簡単な例として、「sample_instance」というNameタグを持つAWS EC2インスタンスオハイオリージョン(us-east-2)に作成する設定を示します。
AWSの認証については今回省略しています。)

main.tf
provider "aws" {
  region = "us-east-2"
}

resource "aws_instance" "example" {
  ami           = "ami-037774efca2da0726"
  instance_type = "t2.micro"
  tags = {
    Name = "sample_instance"
  }
}

Ansible Playbook(terraform_test_playbook.yml) 次に、Ansible Playbookを作成します。このPlaybookは、ローカルホストでTerraformを実行します。

terraform_test_playbook.yml
---
- name: Execute Terraform from Ansible
  hosts: localhost
  connection: local
  tasks:
    - name: Run Terraform
      cloud.terraform.terraform:
        project_path: "./terraform"
        state: present
        force_init: true

このようにして、AnsibleからTerraformを実行することができるようになります。

Automation ControllerからTerraformを実行する場合の例

ここまではオープンソースのAnsibleでの連携を紹介してきました。 しかし、商用導入する場合はRed Hatからエンタープライズ版の製品群であるAnsible Automation Platformを使用する場合が多いです。
AnsibleとAnsible Automation Platformについて AAPの中でAnsibleを用いた自動化の製品としてAutomation Controllerが提供されているので、 Automation ControllerからTerraformを実行する例を紹介します。
Automation ControllerからTerraformを 実行する際には、Terraformが導入されたコンテナ環境(Execution Environment 以下 EE)を構築する必要があります。

EEの構築

AnsibleのEEを利用して、Terraformを実行するためには、EE内にTerraformをインストールする必要があります。
Automation Controllerで使用されているデフォルトの EEにはTerraformが含まれていないため、独自にビルドする必要があります。

execution-environment.ymlの作成

・execution-environment.ymlファイルを作成し、必要なパッケージや依存関係を定義します。 ・ansible-builderを使用して、EEをビルドします。 以下に簡単な例を紹介します。

exection-environment.ymlのファイルを作成し、下記を記述します。

version: 3
images:
  base_image:
    name: quay.io/centos/centos:stream9
dependencies:
  ansible_core:
    package_pip: ansible-core
  ansible_runner:
    package_pip: ansible-runner
  galaxy:
    collections:
      - name: cloud.terraform
additional_build_steps:
  append_base: |
    RUN yum install -y git
    RUN curl https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo | tee /etc/yum.repos.d/terraform.repo
    RUN yum install -y terraform


EEのビルド

上記の設定でansible-builder buildコマンドを実行し、Terraformが含まれたEEを作成します。

$ ansible-builder build -t localhost/terraform-ee


Terraformがインストールされていることを確認

ビルドしたEEにTerraformがインストールされているかを確認します。
例えば、以下のコマンドでバージョン確認ができればTerraformがインストールされています。

$ docker run localhost/terraform-ee terraform –version
Terraform v1.9.6
on linux_amd64

このEEを用いることで、AAPからTerraformを用いたジョブを実行することが可能になります。

作成したEEを利用してEC2を構築する

TerraformがインストールされたEEを作成できたので、これでAutomation Controller上から先ほど作成した、AnsibleとTerraformを連携させたPlaybookも実行できるようになります。

細かい設定についてはこの記事内では割愛しますが、最終的には下記のようにボタン一つでクラウドリソースの構築ができるようになります。

上記はAutomation Controllerに設定したAWS EC2インスタンスをプロビジョニングするジョブテンプレートの詳細画面です。 ジョブテンプレートには先ほど紹介したPlaybookを設定しています。

画面下部にある起動ボタンをクリックすることで、ジョブが起動して下記の画面に移ります。

Playbookで設定されているTerraformを利用したEC2プロビジョニングのタスクの結果が「changed」となり、成功していることがわかります。

Automation Controllerのジョブによって「sample_instance」という名前のEC2インスタンスオハイオリージョン(us-east-2)に作成されていることがわかります。

まとめ

本記事ではAnsibleとTerraformの連携について説明してきました。 内容を簡単にまとめると

・インフラのプロビジョニングと構成管理の統合が可能になる
・複雑なインフラとアプリケーションの管理が柔軟に行える
・インフラとアプリケーションの設定がコードとして管理されるため一貫性と再現性が確保できる

となります。 AnsibleとTerraformはどちらか一方を選択するのではなく、AnsibleとTerraformを連携させることで、それぞれのツールの強みを活かしつつ、自動化の範囲を広げられるだけでなく、自動化フローを1つのツールに集約できるため、インフラとアプリケーションの管理がより効率的になります。

これから自動化を進める方だけでなく、AnsibleやTerraform単体で自動化を進めていた方は、是非TerraformとAnsibleの連携もご一考ください。

AnsibleとTerraformの違い、使い分け

はじめに

こんにちは、iTOC事業部 ACTの西城です。
今回はAnsibleとTerraformにはどういった違いがあるのか、どう使い分けるかを紹介します。
それぞれの名前は分かるが具体的にどう違うのか知らない方や、業務の自動化を検討しているがどのツールを選べばよいか分からない方に読んでいただきたい内容です。
※技術的な内容より、端的にツール毎の特徴を知りたい方は末尾から先に読んでいただけると分かりやすいかもしれません。
 

AnsibleとTerraformについて

まずは本記事で扱うツールについて簡単に説明します。
各ツールについて詳細に知りたい方は、弊ブログにそれぞれを解説した記事があるのでそちらを参照してください。
Ansibleについて
-> Ansibleとはなにか [特徴 | 製品紹介 | 入門 | できること/できないこと] - APC Automation blog
Terraformについて
-> ITインフラ自動化推進: Terraformとは - APC Automation blog

Ansible

現在はRed Hat社が開発しているOSSの構成管理、自動化ツールです。 Pythonで開発されており、インフラの構成を記述したコードはYAML形式で記述します。

Terraform

HashiCorp社が開発したIaCツールです。
Go言語で開発されており、インフラの構成を記述したコードはHCL*形式で記述します。
※HCL(HashiCorp Configuration Language)はHashicorpが開発した言語です。
 
 
開発言語やコードの記述形式は異なりますが、両者ともインフラ構成をコードとして記述するIaC、自動化ツールです。また、AnsibleもTerraformも共に多機能なツールであるため、同様の機能が多くあります。
しかし、特徴や得意な領域が異なるため、自動化を行う対象や範囲によって使い分けることで、ツールを最大限に活用することができます。

Ansible、Terraformがどういったシーンで活用できるか

ここからはAnsibleとTerraformはそれぞれどういった特徴を持っていて、どういったシーンで活用できるのかを説明します。
 

Ansibleの特徴① 得意なこと

エージェントレスでありSSHログイン可能な機器は自動化対象であること

Ansibleは自動化対象の機器にSSHでログインし操作を行います。 自動化対象の機器で事前に行う設定はSSHサーバの設定だけなので、エージェントソフトといった特別なソフトがインストールできない機器または環境でも動作可能です。
※自動化対象の機器やサービスによってはSSHではなく、APIなどを使用して操作するものもあります。

豊富なモジュールにより様々なOS、機器に対応

LinuxWindowsといったOSや、Cisco, Juniper, F5, Fortinetなど様々なベンダの機器に対応するモジュールが存在します。豊富なモジュールにより、サーバOSの設定、ソフトウェアの設定やNW機器、セキュリティ機器の設定の自動化が行えます。

冪等性が確保しやすい

Ansibleはこれから設定しようとしているコンフィグが既に設定されているかどうかをモジュールが判断してくれるので、冪等性を確保しやすいです。 そのため、冪等性確保のために処理を追加する開発を減らすことができます。

冪等性の例:新規でファイルを作成するコードでは、ファイル作成前に該当のファイルが存在するかを確認して、存在しない場合は作成を行う、既に存在する場合はファイル作成の処理をスキップする。このような動作により同じコードを複数回実行しても結果は同じになる。
 

Terraformの特徴① 得意なこと

豊富なプロバイダーにより、多くのクラウドサービスや仮想化基盤に対応

クラウドサービス(AWS, Azure, Google Cloudなど)はもちろん、オンプレミスで動かしているハイパーバイザー(ESXiやHyper-Vなど)にも使用可能です。

様々なプラットフォームに対する統一された操作

上記のようにTerraformは様々なプラットフォームで使用可能です。そのため、複数種類のクラウドサービスや、クラウドサービスとオンプレミスを組み合わせた環境などで、環境ごとに異なるIaCツールを使用することなくTerraformで管理することが可能になります。

構築したインフラのリソース情報はファイルとして保持

Terraformは構築したリソースの情報を基に、現在のインフラ構成がどうなっているかをテキスト形式の「状態ファイル」で保持します。
Terraform実行時にはコードに記述された理想の状態と、「状態ファイル」に記述された現在の状態を比較し、どのリソースを作成、変更、削除するのかを決定します。必要な変更だけを加えるため、予期しない構成の変更を防ぐことができます。
 
 

Ansibleの特徴② 苦手なこと

自動化対象の機器やサービスに外部からコマンドを入力できる環境が必要

Ansibleは主にSSHを使用して機器に接続するので、対象機器がSSHサーバとして動作する必要があります。 (SSHに対応していない古いNW機器などの場合はTelnet接続も一応できます。)
そのため、SSHサーバおよびIPアドレスの設定は手動または別の方法で行う必要が出てきます。
また、SSH以外の接続方式を使用するモジュールも存在します。
Windowsを操作するモジュールの場合、SSHサーバではなくWinRMの設定を事前に行う必要があります。
APIを使用して接続するモジュールの場合、自動化対象のサービスでAPIから設定が行えるように事前準備を行う必要があります。

対応するモジュールがないと、Ansibleの真価が発揮できない

行いたい設定に対応するモジュールがなくても、CLIで入力するコマンドを使用して設定を行うことは可能ですが、Ansibleの特徴の1つである冪等性が確保できません(冪等性を確保する処理を追加する必要が出てきます)。
 

Terraformの特徴② 苦手なこと

自動化対象のプロバイダー(API)がないと何もできない

IssSや仮想化基盤へのアクセス方法はAPIを経由したものなので、そもそもシステムを操作できるAPIがなかったり、そのAPIを利用したプロバイダーが提供されていないとTerraformは何もできません。

コンフィグの自動化

Terraformでもシェルスクリプトを使用することでVMに対してコンフィグを投入することが可能ですが、Ansibleと比べると柔軟性や再利用性で劣ります。

構築済みの環境への導入

Terraformが正常に動作するには、状態ファイルと実際のインフラ構成が一致している必要があります。そのため、既に構築されている環境にTerraformを導入したい場合は、状態ファイルを実際の構成に合わせる形で修正する作業が必要になります。

管理体制の統一が求められる

理由は1つ上のものと同じになりますが、Terraformで構築した環境にTerraform以外の方法で変更を加えてしまうと、状態ファイルと実際の構成がズレてしまいTerraformの動作に支障が生じます。
そのため、Terraformで構築した環境はTerraform以外からは変更を加えない、といった統一された管理体制が必要になります。
   
 

Ansible、Terraform、特徴のまとめ

2つのツールについて簡単にまとめると
・AnsibleはOSレイヤ以上の自動化が得意で、機器の初期設定の自動化が苦手
・Terraformはクラウドサービスやハイパーバイザー上のリソースの自動化が得意、OSレイヤ以上の自動化が苦手
となります。
 
 

既にAnsibleが導入されている環境にTerraformを導入すると、どのようなメリットがあるのか

Ansibleは導入しているがTerraformは導入しておらず、クラウドサービスやハイパーバイザーの管理をAnsibleまたは手動で行っている環境にTerraformを導入することで、どういったメリットがあるかを説明します。

作成したインフラリソースの情報をTerraform側で管理してくれる

Terraformでは構築したインフラリソースを状態ファイルとして保持しますが、Ansibleには作成したインフラリソースの状態を保持する機能はありません。
構築されたインフラがどういった状態かをTerraformが把握することで下記のようなメリットがあります。

変更を適用する前に具体的な変更点を確認できる

Terraformでは状態ファイルとコードに記述された構成を比較し、具体的にどのリソースが作成、削除、変更されるのかを表示します。
具体的な変更点を確認してから、反映させることができます。

Ansibleにもドライラン機能(チェック機能)がありますが、モジュールによっては対応していなかったり、表示内容は変更点があるか否かしか表示されず、具体的に何が作成、削除、変更されるのかまでは分かりません。

環境の削除が容易になる

Terraformは状態ファイルにより現在のインフラ構成を把握するので、Terraformの削除用コマンドを実行するだけで作成した環境を削除することができます。

一方でAnsibleは構築したインフラ構成を把握していないため、環境を削除するためには削除用のコードを別途開発する必要があります。

コード内で依存関係を意識しなくても良い

Ansibleは手続き型のため、作成するリソースの依存関係を意識してコードを記述する必要があります。一方、Terraformは宣言型であり依存関係をツール側が解決してくれるため、依存関係を厳密に意識することなく開発することができます。
例:EC2とそのEC2が接続するVPCを同時に作成するコードで、EC2->VPCの順に記述しても、Terraformが依存関係を解決し実行時にはVPC->EC2の順で作成を行い、VPCにEC2が接続されます。
 
 

既にTerraformが導入されている環境にAnsibleを導入すると、どのようなメリットがあるのか

Terraformは導入しているがAnsibleは導入しておらず、VMのコンフィグをスクリプト等で投入している。または手動で行っている環境にAnsibleを導入することでどのようなメリットがあるかを説明します。

OSやソフトウェアの設定が容易に

TerraformでもスクリプトでOSやソフトウェアの設定をある程度行えますが、Ansibleで設定を行うことで下記のようなメリットがあります。

冪等性を確保しやすい

シェルスクリプトでは現在の設定やファイルの有無に関わらずコマンドが実行されるため、複数回スクリプトを実行した際にコマンドによってはエラーとなってしまいます。そのため、エラーを回避するための処理を追加で書く必要があります。
Ansibleでは設定変更やファイル作成などを行う前に、該当の設定値やファイルの有無をモジュールが確認してくれるため、別途確認処理を記述しなくても冪等性を確保できます。

再利用しやすい形でコードを開発できる

Ansibleではコードを分割することで再利用しやすい形での開発が可能です。
多くの機器に対して使用する処理を分割し使いまわすことで、システムが大規模になった際に開発コストの削減が見込めます。

記述方法の統一

AnsibleのコードはYAMLという形式で書く必要があります。また、Ansibleのコードでは変数の宣言や処理を記述するディレクティブが決まっています。そのため、スクリプトと比べて誰が書いても統一感のあるコードになりやすいです。
また、Ansibleではディレクトリやファイルを名前で判別し読み込みます。そのため、必然的に名前が統一され乱雑になることもありません。

自動化の対象を増やせる

Terraformが管理できるリソースはプロバイダーが提供されているものに限られますが、AnsibleはSSH接続できれば管理可能なため、今までは自動化の範囲外だった機器も自動化の対象にすることが可能です。 例:オンプレミスのルータやスイッチ、セキュリティ製品など  
 

まとめ

本記事ではAnsibleとTerraformの違い、使い分けについて説明してきました。
内容を簡単にまとめると。
・得意な領域が異なるため自動化を行いたい対象、範囲によって使うツールを選び使い分ける。
・オンプレミスのNW機器やセキュリティ製品、OSレイヤ以上の自動化はAnsibleが得意とする領域
・ハイパーバイザーやクラウドサービス上のリソースの自動化はTerraformが得意とする領域
となります。
 
また、この2つのツールは連携させて併用することが可能です。
連携時はAnsibleからTerraformを呼び出すことも、TerraformからAnsibleを呼び出すこともできます。
連携させることでお互いの強みを活かしつつ自動化の範囲を広げることができるので、自動化対象の範囲によっては両方とも導入することを検討してください。
連携、併用の具体的な方法については次回掲載予定の記事で説明します。

Terraformとは

Terraformとは

はじめに

こんにちは、エーピーコミュニケーションズ iTOC事業部ACTの相場です。
今回はTerraformについて紹介します。
Terraformとは何なのか?どんなことが出来るのか?特徴は?といった疑問や、クラウド自動化やIaC、構成管理について情報収集をしている方は、是非本記事を読んでいただけると嬉しいです。

Terraformとは

まず、Terraformとは何なのかについて説明します。
TerraformはHashiCorp社が提供するプロビジョニングソフトウェアです。

Terraform公式ページのリンク

プロビジョニングソフトウェアとは、インフラを構成するサーバーなどを作成する役割を持ったソフトウェアです。
コードによってインフラを構築するInfrastructure as Code(IaC)ツールの一つです。

Terraformでは、主にクラウド上でのインフラ構築を自動的に行うソフトウェアとなっています。
AWS CLIなどのCLIクラウドを管理する場合とTerraformでクラウドを管理する場合では、以下のような違いがあります。

CLIとTerraformの比較表

項目 CLI Terraform
設定方法 命令型
具体的な手順をコマンドで明示的に定義する。
宣言型
インフラの状態をコードで明示的に定義する。
冪等性 コマンドごとに異なる。
同じコマンドを再実行しても、異なるインフラ状態になる可能性がある。
殆どのリソースで冪等性を確保。
同じコードを再実行しても、同じインフラ状態になる。
再現性 スクリプトの再実行で可能。
結果は実行の順序やタイミングに依存する。
コードにより再現性を保証。
同じコードから常に同じインフラ状態が生成される。
状態管理 無し。
リソースの状態を追跡する方法を開発する必要がある。
状態ファイルによりインフラの状態を自動的に管理する。
コードの再利用 スクリプトとして実装することで再利用可能。 モジュールとしてコードを再利用可能。コードの集合体として再利用可能なコンポーネント

CLIの場合は管理をする必要がない簡単なタスクを手早く実行する点において便利です。
Terraformは大規模なインフラストラクチャの管理や、コードによる厳密なインフラ状態の制御を必要とする場合に適しています。

Terraformが提供しているクラウドリソースを管理するためのプラグインとTerraformを組み合わせると、サーバー、データベース、ロードバランサーなどインフラの構築に欠かせないパーツを作成できます。
対応しているクラウドサービスは、AWS、Azure、Google Cloudなどの主要なクラウドサービスを含めた複数のクラウドサービスです。

他のクラウドリソース管理ツールとの比較表

管理ツール 対応クラウド 記法 公式サポート コミュニティサポート
Terraform 複数 HCL Official Tireの範囲内 広範囲
CloudFormation AWS JSON/YAML 対応しているAWSリソース 限定的
Bicep Azure Bicep DSL 対応しているAzureリソース 限定的
Resource Manager Google Cloud JSON/YAML 対応しているGoogle Cloudリソース 限定的

Official Tireについては後ほど説明します。

また、クラウド以外でもTerraformを利用することができます。
例えばVMwareKubernetesなど、様々なプラットフォームにもTerraformは対応しています。

なぜTerraformで管理が実現できるのか

Terraformでの管理は、プロバイダーによって実現しています。
プロバイダーとは、Terraformが様々なサービスや製品とやり取りするためのプラグインです。
管理したいサービスが提供しているAPIを介してTerraformで操作を行います。

Terraform Providerの一覧ページのリンク

Terraform公式やTerraformのパートナー企業、コミュニティも合わせるとおよそ、4000を超えるプロバイダーが存在します。(2024年8月時点)

Terraformで利用可能なプロバイダーには3つのTierがあります。
Official』、『Partner』、『Community』です。

OfficialはHashiCorpが所有、維持管理を行っているプロバイダーです。
主要なプラットフォームを対象としており、それぞれのプロバイダーが独自のリリースサイクルを持っています。
公式からリリースされているため、他Tierのプロバイダーと比べて安定性、信頼性が高いです。
また、継続的なサポートやアップデートも行われています。
その他にも、Officialのプロバイダーはドキュメント類が豊富にそろっています。
管理したい対象サービスや製品がOfficialのプロバイダーであれば安心して利用できます。

Partnerはパートナー企業が所有、維持管理を行っているプロバイダーです。
HashiCorpとパートナー導入プロセスを経て、認定された企業が提供を行っています。
パートナー企業が提供するプロバイダーは、それぞれのパートナーが所有するサービスや製品をTerraformで扱うためのものです。
パートナー企業が提供するプロバイダーは、機能追加・改善、バグ修正などのサポートが積極的に行われます。
そのため、Officialと同様にPartnerのプロバイダーで管理可能なサービスや製品の管理から始めてみるのも良いです。
また、PartnerのプロバイダーもOfficialほどではありませんがドキュメントが整っています。

Communityはコミュニティが所有、維持管理を行っているプロバイダーです。
OfficialやPartnerで提供されていない技術やサービスをTerraformで管理できるように、プロバイダーの提供が行われています。
これらのプロバイダーの所有者は世界中の開発者、エンジニア、Terraformユーザーです。
Communityのプロバイダーは所有者によってドキュメントの充実度はまちまちです。
ですが、人気の高いプロバイダーや技術やサービスのコミュニティはドキュメントが充実しています。

Terraformの特徴

Terraformの特徴として、HCLという独自の言語を使用します。
独自の言語と書かれると取っつきにくいように感じますが、人間が比較的簡単に読み書きできるように設計された非常にシンプルな記法です。表現がやや複雑になりますが、JSONで記述することもできます。

シンプルな記法ですのでプログラミングを熟知していなくても、コードを見ればどのようなインフラが構築されたのか分かりやすいです。
これがTerraformの特徴であり、シンプルなコードをインフラ構成のドキュメントとすることで、厳密に定義されたネットワークの状態を確認することができます。これによって、特定の個人へのインフラの管理や構築を依存させません。(=属人化の解消)

また、十分な検証が行われた既存の手順をTerraformに落とし込むことで、インフラ構築作業における人為的なミスを減らすことができます。(=インフラ品質の向上)

Terraform単体では上記のようなメリットがありますが、Gitなどのバージョン管理システムを組み合わせることで、更なるメリットを生み出すことができます。
例えば、コードの変更履歴を確認することで過去にどのようなインフラが構築されたのか追跡することができます。
その他には、コードの変更により問題が発生した場合でも、変更履歴を確認して正常に動作していたコードに切り戻すことが可能になります。

このようにTerraformを他のシステムと組み合わせることで、更なるインフラの運用、構築の効率化を実現できます。

Terraformで出来ること

Terraformのコード

Terraformのコードを使うことで簡単にクラウド上にリソースを作成することができます。
以下のようなシンプルな記法を使い、リージョンやリソースのタイプを指定します。

EC2インスタンスを作成するサンプルコード

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "tf_blog_ec2" {
  ami           = "ami-0b9593848b0f1934e" 
  instance_type = "t2.micro" 
}

さらにコードを拡張することで、以下の構成図の各種インフラリソースを作成することが出来ます。

今回は作成するリソースにtf_blogのプレフィックスをつけています。
tf_blogでリソースの検索を行い、作成されていることを確認します。

コード実行後の各種リソースの状態

Terraformのコミュニティ

コミュニティの比較は同一条件下での比較が難しいです。
ですが、大まかにコミュニティの規模を把握することで、その技術を採用すべきかの判断基準を一つ設けることができます。
以下の表から、Terraformのコミュニティ規模は他のIaCツールと比較して大きいことが分かります。

ツール ソース クラウド コントリビューター スター ライブラリ Stack Overflow
Terraform オープン 複数 1,621 33,019 9,641 13,370
Pulumi オープン 複数 1,402 12,723 15 327
CloudFormation クローズ AWS ? ? 369 7,252
Heat オープン 複数 395 379 0 103

詳解Terraform 第3版』の『IaCのコミュニティの比較』から引用。

コミュニティの規模が大きいことで以下のような利点があります。
コミュニティ製のプラグイン拡張機能が利用可能。
オンラインで情報を得る機会が増える。(ブログやStack Overflowなど)
Terraformを扱う協力者の確保がしやすい。(従業員、コンサルタントSIerなど)

Terraformはコミュニティ活動により、ツールセットやベストプラクティス、学習のためのリソースなどが整っている状態です。
様々なナレッジが集まることで、より使いやすいソフトウェアとして成熟していきます。

まとめ

TerraformはITインフラにおける自動化を実現するためのソフトウェアです。
公式やパートナー企業、コミュニティから提供されるプロバイダーによって、サービスや技術の管理を実現しています。 コードによってインフラの状態を定義することで、特定の個人に依存しないインフラ構築・管理が可能になります。また、シンプルな記法のHCLにより可読性の高いコードを書くことが可能です。 人気のツールであるTerraformは公式からの情報以外に、コミュニティから提供される情報も豊富です。
公式がサポートしているサービス以外にも、様々なサービスに関する情報が集まります。 複数のサービスや技術を組み合わせたインフラ環境において、Terraformは他の管理ツールにはない独自の強みを持っています。
複雑なインフラ環境でなかなか業務の効率化を進められない、という方がいらっしゃいましたら是非一度Terraformの導入を検討してみてください。

私たちエーピーコミュニケーションズではITインフラ自動化推進をご検討の方に向けて、オンラインでの無料相談を随時実施しています。(30分~1時間程)
Terraformについてのご相談に限らず、自動化推進の為の情報収集としてもご活用いただけますので、よろしければお気軽にご利用ください。

【無料相談・お問合せフォーム】 https://www.ap-com.co.jp/contact/act.html

経験が少なくてもAIで効率的なAnsible Playbookの作成が可能!? Ansible Lightspeedを試してみた

Designed by Freepik

初めに

こんにちは、エーピーコミュニケーションズ iTOC事業部の相場です。
今回の記事では、AIによってAnsible Playbook(以下、Playbook)の作成を支援するAnsible Lightspeedを実際に試してみたので紹介します。
なお、本記事ではTech Preview版のAnsible Lightspeed(以下、Lightspeed)を使用しています。

Tech Preview版は本記事公開時点では利用不可能なため、Lightspeedを利用したい場合は、有償で一般提供されている製品版の「Red Hat Ansible Lightspeed with IBM watsonx Code Assistant」をご利用ください。

Ansible Lightspeedとは?

Ansibleは、ネットワーク機器の設定やサーバの構成管理などを自動化するツールです。しかし、Playbook作成には経験と知識を必要とします。ここでAnsible Lightspeedの出番です。この拡張機能は、AIによるサポートで経験の少ない人材でも効率的なPlaybookの作成を可能にします。

他の生成系AIとの違いは?

先ほど「AIによるサポートで効率的なPlaybookの作成が可能」と記述しましたが、ChatGPTなどの他の生成系AIとはどう違うのか?という疑問を持った方もいらっしゃると思います。そこで簡単にAnsibleを使用する環境において、Lightspeedが他の生成系AIと比べてどのように優れているのか説明します。

①コンテンツソースの照合
Lightspeedは生成したコンテンツ(Playbookなど)に対して、その出典や信頼性を示すタグやリンクを付与します。これにより、コンテンツの品質や正確性を確認できます。

②ポスト処理
Lightspeedは生成したコンテンツに対して、文法や表現や論理性などをチェックして修正します。これにより、コンテンツの読みやすさや理解しやすさが向上します。

③前後のタスクを見て適切なPlaybookを生成
Lightspeedは生成したコンテンツに対して、その目的や背景や状況などを考慮して、最適な手順や方法を提案します。これにより、従来手作業で行っていたPlaybookの作成時間が削減されます。

実際に試してみた

実際に幾つかのパターンでLightspeedを試してみました。
①タスク名 “Debug hello world
まずは簡単にお試し。タスク名の一番後ろにカーソルを移動した後、Enterを押すことでAIがタスクの内容を作成します。その後Tabを押せば作成した内容を反映できます。

また、学習に使用したコンテンツソースは以下のように表示されます。

② タスク名 “Run show version”
ベンダ専用のモジュールでもタスク名から作成可能です。ただし特に指定をしない場合、ネットワーク機器関連はciscoのモジュールが使用されました。

③ タスク名 “Run show version on juniper”
こちらもjuniper用のモジュールですが、タスク名で明示的に指定することでjuniper用のモジュールを使用しました。

また、異なるタスク名でも同じタスクを生成する場合もあります。
以下はOSPFのコストを変更(設定)するタスクです。

このようにタスク名が違う場合であっても、目的に対して手段が同じであればこのような結果になります。

Cisco RouterへのHSRPの設定(ChatGPTとの比較)

まず1枚目はChatGPTにより生成したものです。『Configure HSRPというタスク名でansibleのタスクを作成してください。』というプロンプトを入力しました。基本的な設定はコンフィグが入っていることが確認できます。
設定を行うだけであればこのタスクでも十分ですが、モジュール名がFQCNではないこと、IPアドレスやインターフェースを直接書いているため再利用がしづらいことはマイナスです。

2枚目がLightspeedにより生成されたものです。かなり内容が異なります。
まず、コンフィグやインターフェースが変数で指定されています。これはPlaybookの再利用性を高めるうえで適切な手段です。またモジュール名をFQCNで記述することでansible-lintによる構文検査をパス出来ます。

おわりに

以上がAnsible Lightspeedに関する紹介です。
Lightspeedは、Ansibleの経験が少ない人材でも効率的なPlaybookの作成を実現できる画期的なツールです。現段階では、商用環境に適用するにはまだまだリファクタリング要素がありますが、Playbookの書き方を学ぶ上で、初心者の入り口としては有効なツールになり得ます。
Ansibleを利用した自動化の内製化を目指していたり、人材不足に悩まれている方は要チェックです!
製品版のLightspeedはAAPのライセンスを購入することで製品版が利用可能になるので、是非試してみて下さい。

ネットワーク自動化が体感出来る!Interop Tokyoなどの展示会にて実施している自動化デモの詳細やポイントについて

エーピーコミュニケーションズは毎年いくつかの展示会に出展し、ネットワーク自動化の便利さを実感していただくために、実際に発生しうる業務をAnsibeleを使って自動化するデモンストレーションを行っています。 今回はそのデモの詳細やポイントについて紹介させていただきます。

※展示会出展時の様子については下記の記事をご覧ください。

2023年上半期の展示会イベント参加報告 - APC Automation blog

――――――――――――――――――――――――――――――

デモはAnsibleで出来る事のほんの一部の内容ですが、実際にどんな事が自動化できるかを知っていただければ、自社の課題解決のヒントになるかもしれません。

自動化デモの概要

拠点Aとの間のメインWANを繋ぐセンター側ルーターのインタフェース設定を、Ansibleを使用して自動で切り替えるデモになります。 下図センターのバーチャルルーターに対して、下図拠点Aと通信するためのインターフェースの有効化/無効化とpingの疎通テスト、configのバックアップをGitのリポジトリにアップする所までの流れを一度の操作で行います。Slackへの通知設定もしてありますので、リアルタイムに進捗を確認します。

工程(有効化ver)

  1. テンプレート起動
  2. pingで疎通テスト
  3. 失敗した場合、有効化
  4. configをGitへバックアップ
  5. pingで疎通テスト

ポイント

  • ワンクリックで全ての工程が進行
  • 途中に承認操作を挿入する事が可能
  • 工程の都度、Slackで通知することで進捗管理が可能
  • 各操作のテンプレートを組んで自動化を構築している為、組み替える事で様々な設定にも対応可能
  • 自動化のテンプレートを作成しておく事により、経験や知識の無いメンバーでも品質を一定に保つことが可能
  • その他分岐や切り戻しなどの工程の自動化が可能
  • 直感的に操作できるUI
  • 各作業内容を記すPlaybookの記述には可読性の高いYAMLまたはJsonを使用

デモにかかる時間は2~3分ほどで、展示会では少しお話をしている間に全工程が終わってしまいます。 もし手作業で行った場合どれぐらいかかりそうかをイメージしながらご体感いただくと、より魅力を感じていただけるのではないかと思います。

show int 様に取材していただきました

Interop Tokyo 2023に出展した際にYou tubeチャンネル「show int」様に取材していただきました。 動画内では「Automation Coordinator」のご紹介と、自動化デモンストレーションの概要を説明させていただいています。 動画を視聴していただいてから記事を読んでいただけると、より分かりやすいのではないかと思います。

show int インターネットの裏側解説 チャンネル 国内最大級イベント Interop Tokyo 2023 に参加してきました - YouTube



今後の展示会出展予定(2023年秋以降)

今年は10/25から幕張メッセにて開催されるJapan IT week 2023秋を含めて3つの展示会に出展致します。 まだご覧になられてない方はもちろん、以前聞いてから自動化について更に情報収集をしたい方も、現在の状況に合わせてご案内いたしますので、お気軽にお越しください!

出展する展示会情報

10月25日~27日に幕張メッセにて開催のJapanITweek秋
参考リンク :Japan IT Week【秋】|RX Japan株式会社

11月8日~9日に兵庫県のアクリエひめじにて開催されるDISわぁるど2023
参考リンク :Disわぁるど in 姫路

11月20日~22日に東京大学にて開催されるInternet Week2023
参考リンク :Internet Week 2023

2023年上半期の展示会イベント参加報告

今年度も半年が経過しようとしていますので、
今回の記事では、2023年上半期に催され、我々ACTが参加したイベントの紹介をいたします。

Japan IT Week 春 2023

Japan IT Weekは様々なIT業界が集まり開催される日本最大級の展示会です。
参考リンク :Japan IT Week【春】|RX Japan株式会社

今季開催された Japan IT Week春は、4月24日~26日の3日間、東京ビッグサイトにて開催されました。
ソフトウェア&アプリ開発、営業DX、IT運用管理&データセンター、情報セキュリティ、デジタルマーケティングクラウド業務改革、IoTソリューション、次世代EC&店舗、AI・業務自動化、メタバース活用、データドリブン、の展示に分けられており、エーピーコミュニケーションズも 情報セキュリティEXPOの一画にブースを設けさせていただきました。

(株) エーピーコミュニケーションズ - 出展社詳細 | Japan IT Week 春

弊社ブースでは、ネットワークテスト・Firewallのポリシーテストを自動化する自社開発プロダクトのNEEDLEWORKと、Ansibleによるネットワーク自動化のデモ展示をさせていただきました。
当日の様子につきましては、Insider APCブログにてレポート記事を記載させていただいておりますので、こちらもご覧いただければと思います。
【イベントレポート】Japan IT Week 春に出展しました! | INSIDE APC

Interop Tokyo 2023

Interop Tokyo はITインフラ業界が集まり開催される国内最大級の展示会です。
参考リンク :Interop Tokyo 2023

毎年6月に開催されていて、今年は6月14日~16日の3日間、幕張メッセにて開催されました。 エーピーコミュニケーションズはこれまでで一番広いブースを確保して参加させていただきました。

エーピーコミュニケーションズ | Interop Tokyo 2023

Interopにおいても、Japan IT Weekと同様にNEEDLEWORKとAnsibleのデモ展示をさせていただきました。
ホールの中心近くにブースを設置させていただくことができ、ご来場いただいた方々の目にも多く留まったのではないかと思います。
今回から打ち出している「ルーティンワークからエンジニアを解放しよう!」というコピーに反応していただいたお客様も多く、現状エンジニアの方々の多くがルーティンワークを煩わしく思っている事や、ベテランエンジニアをより有意義な業務に関わらせたいといった考えをお持ちの経営者・管理者の方が多い事が分かりました。
広いブースで出展したおかげで、多数のご来場者様と接する機会を設ける事ができ、ネットワーク自動化の可能性についてお伝え出来たと実感しております。

また、弊社が企画・監修した「手のひらネットワーク機器」のカプセルトイをアンケートにご協力いただいた方へ配布していたのですが、補充される度に列が出来るほどの大反響でした。
ここまでの反響は想定外だったこともあり、あっという間に在庫が無くなってしまいましたので、ゲットできた方はおめでとうございます!
ゲットできなかった方は・・・9月26日以降順次再販されるそうなので、その機会にゲットしてください! 参考リンク : 手のひらネットワーク機器 プレスリリース │ エーピーコミュニケーションズ

JANOG 52

JANOGはネットワークエンジニアのための技術交流会です。 毎年2回、1月と7月に全国各地の会場を移りながら実施されています。 ※上記の定期開催しているものとは別で、企業主催の交流会が開催されることもあります。
参考リンク :JANOG52 Meeting in Nagasaki

ネットワークエンジニアの為の技術交流が主な目的なだけあり、現場のエンジニアや経験知識が豊富なお客様が多く集まり、とても濃いコミュニケーションを図る事ができました。
会期中には参加企業がセミナー形式の発表を行い、最新技術や自社の運用事例などを紹介していくため、 エンジニアの方の情報収集にはピッタリな会となっています。 2023年は7月5日~7日長崎県で開催されました。 今回弊社は登壇しませんでしたが、会場では他社のエンジニアと知識や交流を深める良い機会となりました。 毎回開催される地域は変わりますが、エンジニアで参加されたことが無い方は、一度は参加されることをお勧め致します。

下期の出展予定について

10月25日~27日に幕張メッセにて開催のJapanITweek秋
参考リンク :Japan IT Week【秋】|RX Japan株式会社

11月8日~9日に兵庫県のアクリエ姫路にて開催されるDISわぁるど2023
参考リンク :Disわぁるど in 姫路

11月20日~22日に東京大学にて開催されるInternet Week2023
参考リンク :Internet Week 2023

以上の展示会に出展予定です。 「ルーティンワークからエンジニアを解放しよう!」にピンと来た方や、ITインフラの自動化デモや、自動化についてエンジニアに直接質問してみたい方は、是非弊社ブースまでお越しいただけたら幸いです。
会場でお会いできる日を楽しみにしています!
※出展時のブースの位置などは開催日が近づいたら追ってお知らせ致します。

初動対応のスピードと品質、更にその対応工数等の課題をまるっと改善!? Ansible Automation Platform(ver2.4)の新機能「EDA」とは!?

EDA(Event-Driven Ansible)とは

今回は、最近発表された”Red Hat Ansible Automation Platform 2.4(以降AAP 2.4)”の新機能のうち、 目玉となる「Event-Driven Ansible(以降EDA)」について紹介します。
EDAを使用する事で「監視や検知したイベントをトリガーにした対応の自動化」を実現でき、
 ・セキュリティ対応や障害対応の迅速化
 ・ルーチンタスクの工数削減
 ・サービスの品質や安全性の向上
  などが図れるとされています。

つまり、何かしらの事象が発生してからの、初動対応のスピードと作業の確実性、更にその対応工数でお困りの組織にはピッタリな機能となっています。

また、Red Hat社のプレスリリース記事(1)の、サポートコメントの中では
「Event-Driven Ansibleは、決して帰宅しないチームメンバーです」
とも記載されていましたが、具体的にどのような機能で、どのように使われる事を想定しているのかを次項から記載します。
www.redhat.com

さらっと機能概要を簡単にご紹介

 ・AAP 2.4から実装された新機能
 ・ Automation Controllerと連携して動作する
 ・ 手動実行していたジョブテンプレート(Playbook)を自動実行する
 ・ Playbookと同様、Rulebookという可読性の高いテキスト形式ファイルで操作を定義する
 ・ トリガーとしてサードパーティ製品と連携できる

・システム障害対応のユースケース

なんらかのシステム障害が起こった際に、管理職の方たちが必ず思われるのは
「早く直せ(復旧しろ)」
だと思います。
その為に、監視ツールやメール通知などの何かしらの方法で、
障害の発生に気づける仕組みを導入されている事と思います。

では気づいたその後のアクションはどうでしょうか?
 ・発生事象と影響度の確認
 ・原因調査のための情報取得
 ・上記を含めた関係者へのエスカレーション
  等、色々とありますね。

実際の現場では、
監視のオペレータだけでは次のアクションが取れない。↓
上長を経由して別のチームの詳しい人を深夜に捕まえる。↓
それらに時間を取られて復旧が遅れて他の箇所にも障害が広がる・・・↓
詳しい人間に聞いたら特定のサービスを再起動するだけで復旧した。

なんて事もあるかと思います。
そして今後同様の事象("イベント")が再発した時にオペレータが対応できるように、

 ① 詳しい人間が、イベント発生時に実行して欲しい事の手順書を作る
 ② イベントと手順書を紐づけてナレッジ化する
 ③ オペレータはナレッジを検索して手順書に沿って手動で操作する
   が、オペレータが操作を間違える
 ④ 手順を見直す、手順実行は二人で行う・・・
   そんな負のスパイラルが見えますね。

これを解決してくれるのがEDAです。


監視ツールなどとEDAが連携し、
発生したイベント毎にあらかじめ定義した手順を自動実行します。
Red Hat社のデモ(https://www.youtube.com/watch?v=rfrtYn7s3IA)では、
実際にWEBサーバがサービス停止した場合に自動復旧させるケースを紹介しています。

詳細は省きますが、以下のような流れでした。
 ① イベント発生(WEBサーバのサービス停止)を検知
 ② ITSMツールへの起票と同時にWEBサーバのサービスを再デプロイ&再起動
 ③ 復旧したらITSMツールのチケットをクローズ
   復旧しなかった場合や、通信出来なかった場合は次の手順へ
 ④ 仮想基盤にアクセスしWEBサーバの仮想マシンを正常な時のスナップショットに戻す
 ⑤ 復旧を確認し、ITSMツールのチケットをクローズ

これらが、ものの数分で実行されサービスが復旧に至っています。
そしてどこにも人間の手による操作は必要ありません。

また、オペレータからのエスカレーションも、
「障害が発生しましたが、すでに復旧済みです 収集されたログとともにベンダに調査依頼を実施します」と言った内容になり、場合によっては事後報告だけで良く、管理者は安心して眠る事が出来るでしょう。
障害復旧にかかる工数の削減が実現され、システムに詳しい人間≒優秀な人間の稼働は、より高度な業務に集中させる事が可能になります。

しかし、EDAおよび自動化の本質は単なる「工数削減」ではありません。
このケースで言うと、迅速な対応によるシステムの安定性向上、つまりサービスレベルの向上です。
さらに発展させると、顧客満足度の向上や社内システムであれば生産性の向上だと思います。
是非、サービス自体の価格や利益率向上につながるものとお考えください。


・セキュリティ対応のユースケース


次にセキュリティ対応のケースを紹介します。
セキュリティの世界では"対応速度"がとても重要である事はご存じかと思います。
外部からの攻撃に関しては、特に即時性が求められます。
ひと昔前までは、海外や特定の国のグローバルIPアドレスからの通信を全てブロックするような方法をとっていたケースもあるかと思います。しかし最近では国内のグローバルIPアドレスを使用した攻撃も多く観測されるようになって来ました。
また、攻撃者は多種多様な方法で攻撃を連続的に行ってきます。適切に設置・定義更新されているWAFやUTMなどによりほとんどの攻撃は無効化できるとはいえ、ゼロデイ攻撃DDoS攻撃など放置しておいて良いものではありません。攻撃を検知したら早急にWAFやUTMのポリシーを変更して防御する対応が必要です。
しかしシステムのセキュリティに関わる設定変更を、手動で、事前の手順レビューや作業承認無く、だれでも即時行える組織は存在しないでしょう。また、誰かの意思決定を待ったり、作業準備している間にも攻撃は続き、最悪突破されるかもしれません。

これもEDAで解決できます。
F5社のコミュニティブログで、
EDAを使って、ログをもとにBIG-IPの設定変更(追加)を自動化する
以下のようなケースが紹介されていました。
community.f5.com


具体的には以下のような流れとなっています。
 ① BIG-IP(WAF)のログを監視しているツール(Elastic Stack)で基準を超えたものを検知
 ② Elastic Stackから自動的に、EDAに送信元IPアドレス等の情報を含めて送信(Webhook)
 ③ EDAがElastic Stackから渡された情報を元にBIG-IPのWAFポリシーを自動的に追加

こちらはまだDemo動画はUPされていませんでしたが、GitHubにコードが公開されており、
とてもシンプルな構成になっています。
基準値のチューニングが難しいかもしれませんが、設定追加対応自体は非常に迅速に行う事が出来そうです。

・製品サポート対応のユースケース

なんらかのソフトウェア製品のサポートを行っている場合、
使用しているソフトのバージョンや、動作させているOSなどの情報は1次受付の際にヒアリングされる事が多いと思います。単純な仕様に関する問い合わせや、既知の事象であれば特に問題ありませんが、新規の不具合が疑われる場合は実際にヒアリングしたバージョンとOSを検証環境に用意して動作検証を行う事があるでしょう。
しかし、エンジニアをアサインして確認依頼を行ってから、エンジニア自身が検証環境を用意していてはその分時間がかかってしまいます。検証環境に潤沢なリソースがあれば多種の組み合わせの環境を事前に用意しておけば良いかもしれませんが、現実的で無い場合も多いです。
例えば以下のようにEDAを使えば、限られたリソースの中で迅速な検証環境の用意が可能です。

 ① 1次受付時にバージョン等の環境情報を受付管理システムに入力するor入力してもらう
 ② 受付管理システムに入力された時点で内容をEDAに自動的に送信(Webhook)
 ※利用しているシステムがWebhook送信に対応していない場合は、
 別途Google FormsやMicrosoft Forms等をベースにしたシステムを用意しても良いでしょう。
 ③ EDAが受け取った内容をもとに自動的に、検証環境用の仮想基盤やクラウド基盤に検証サーバ等を作成、
   指定されたバージョンのソフトをインストール
※検証が不要だと判断された場合は、別途環境削除用のトリガーを用意してそれを動かす等も可能です。

こうする事で、エンジニアがアサインされた時にはすでに検証環境が出来ており、
すぐに検証が可能な運用が可能になります。

・パスワードリセットやアカウント発行/削除などの日常の定型業務対応ユースケース

いわゆる定型業務などにもEDAを使用できると思います。
セルフパスワードリセットに対応していないシステムのパスワードリセットや、
アカウント連携に対応していないシステムへの新規アカウント作成や削除等です。
今回は例として新規に入社された方がいた場合を想定します。

例えば・・・
 ・Active Directory への新規ユーザ作成、各プロパティ登録、グループやOUへの配置
 ・社内へのリモート接続用のVPN機器(Fortigate)へのユーザ追加
 ・社内ファイルサーバへの個人フォルダ作成

等が発生しそうです。
こういった一連の作業も、例えばGoogle FormsやMicrosoft Forms等をベースにしたシステム(入力フォームと入力された内容をWebhookで送信する仕組み)を作成し、各パラメータをEDAに連携する事で自動的に行う事が可能です。社内の各システム部門の手を煩わせる必要はありません。


まとめ

ここまででEDAを利用した具体的な想定ユースケースを紹介しました。
改めてメリットをまとめます。

 ・問題や機能停止に迅速に対処できる
 ・セキュリティリスクに迅速に対処できる
 ・ユーザの新規作成に伴う処理、検証用VMの作成、等のルーチンタスクを軽減できる
 ・Rulebookというテキスト形式のファイルで対応を管理する事で、体系化して管理できる
 ・Ansible Automation Platformという一つのソリューションで、幅広いIT自動化ニーズに対応する事が出来る
 

結論

EDAの登場により、Ansible Automation Platformで出来る事の可能性は飛躍的に高まりました。
Ansible Automation Platformを使用して、これからのビジネスやそれを支えるITに、さらなるスピードと可用性を付加しませんか?



APC-ACT
ACTは株式会社エーピーコミュニケーションズ(APC)の自動化に特化したチームです。現在は特にネットワーク自動化に重点を置いています。
当ブログは、執行役員 名田と、マーケ担当 嶋津が主に情報発信を行っています。