コンポーネントベースのアーキテクチャを使用した実験室の構築

現在、私はSplunkの観測能力チームのサイト信頼性エンジニア(SRE)です.しかし、私がこの解決策で働いたとき、私はSplunkでGDI(Get Data In)組織の一部でした.
さて、問題について話しましょう.
GDIのエンジニアの仕事の一部は、Splunkにアドオンを構築しています.アドオンは、次のパーティションデータソースを接続するプラグインです.
我々は特定のサードパーティの新しいアドオンバージョンで動作する必要があるたびに、我々は2つの研究室、開発目的のための1、およびQAの仕様を持つ他を設定する必要があります.
GDI組織は多くのアドオンを所有しているので、我々はチームとチームの誰が毎回新しいバージョンで働く回転をする戦略を使用します.
これは知識を広めるのに良いですが、私たちは、devのサイクルとチームを通して信頼性と一貫性のあるラボを維持することに問題がありました.
人々の時間のかなりの部分は、研究室をセットアップする手作業でした.開発プロセスに費やされる多くの時間とともに、マニュアル作業は開発者のために大きな頭痛を引き起こします
チームは、いくつかの自動化が必要な、ラボを作成し、重複や再加工を避けるために痛みを減らすために必要でした.
私たちは、コードとしてInfraaを使用するという考えを思いつきました.他の会社が既にやっていなかったほど特別なことではなかった.
チームが小さいので、アドオンの開発に焦点を合わせているので、チームがカスタマイズされたラボを持っているかもしれませんが、IACスクリプトを書く必要はありません.
反応コンポーネントの設計原理に基づいて、私たちは他のコンポーネントで再利用されて、接続されることができるコンポーネントをつくる考えを思いつきました.そして、各々の構成要素は、terraformモジュール、不可解な脚本または不可解な役割であるでしょう.
より良い解明のために、この例を使いましょう.3つの異なる環境でラボを構築しましょう.

環境Aには、4つのWindowsインスタンスがあります

ドメインコントローラとしてのWindows Server 2016.

3メンバーサーバーとしてのWindowsサーバー

WindowsイベントコレクタをもつWindowsサーバー2016

フォワードフォワード

ノードからのsysmonイベントのみ収集

Windowsイベント転送による1台のWindows Server

ウィンドウズイベント推進による1台のWindowsサーバー

環境Bには、7つのWindowsインスタンスがあります

ドメインコントローラとしてのWindows Server 2016.

メンバーサーバーとしての6台のWindowsサーバ

Windowsイベントコレクタ( WEC A )を伴うWindows Server 2016

フォワードフォワード

ノードからのアプリケーションイベントのみ収集

ウィンドウズイベント推進による1台のWindows Server

ウィンドウズイベント推進を伴う1台のWindows Server

Windowsイベントコレクタ( WEC B )を伴うWindows Server

フォワードフォワード

ノードからのセキュリティイベントのみ収集

ウィンドウズイベント推進による1台のWindows Server

ウィンドウズイベント推進を伴う1台のWindows Server

環境Cには、3つのWindowsインスタンスがあります

Windowsイベントコレクタをもつドメインコントローラとしての1台のWindows Server

フォワードフォワード

ノードからのセキュリティとsysmonイベントだけを集める

メンバーサーバーとしての2つのWindowsサーバー

Windowsイベント転送による1台のWindows Server

ウィンドウズイベント推進による1台のWindowsサーバー

通常、地形やモジュールを使用して、これらの環境を再現することができます.
私たちは、それぞれの環境のために特定のplaybooksとterraform設定を作成する必要があります.
そしてここに問題がある.いくつかの類似構成における時間‐符号化順列の使用
これを避けるために、コンポーネントベースのアーキテクチャを使用したアプローチでは、これらのラボがどのようなモジュールを使用しても、どんな形式のスクリプトや可用性のあるブックにも触れずに実行する必要があります.

建築

我々が作った解決は、AWSで展開されるLabs構成の多くの種類と互換性を持ちます.
terraformスクリプトは、インフラストラクチャを展開し、EC 2インスタンスやその他のAWSリソースを展開するために使用されます.そして、EC 2インスタンスの中にソフトウェアとシステム構成を提供するために、Terraformは適切な脚本を呼びます.
PlayBooksは、役割のグループです.ロールは、独立した方法で特定の構成の実装を表します.
役割を果たすwindows_splunk_universal_forward 例として.このロールのダウンロードは、WindowsでのSplunk汎用フォワードインスタンスをインストールして設定します.このロールは、任意のWindowsバージョンを使用するように符号化されます.
Repo Structure:

   ├── ansible
   │   ├── all_roles
   │   │   └── distros
   │   │       ├── linux
   │   │       │   └── roles
   │   │       │       └── <new-linux-role>
   │   │       └── windows
   │   │           └── roles
   │   │               └── <new-windows-role>
   │   └── playbooks
   │       └── <new-playbook>
   └── terraform
       └── modules
           ├── distros
           │   └── <new-distro-type>
           └── environments
               └── <new-environment-type>

地形

Terraformは、何百ものクラウドサービスを管理するために一貫したCLIワークフローを提供するコードソフトウェアツールとしてのオープンソースインフラストラクチャです.TerraformはクラウドAPIを宣言的な設定ファイルにまとめる.
詳細についてはofficial documentation .
地形構造

   terraform/
   ├── modules
   │   ├── constants
   │   ├── core
   │   ├── distros
   │   │   └── <distro-type>
   │   └── environments
   │       └── <environment-type>
   └── wire

環境とは
環境は、ノード間の関係の定義済みの種類です.
各モジュールenvironment がパスterraform/modules/environments . で、terraform/modules/distros 適切な関係を構築する.
解明のために、この例を例に挙げてください.

1 Windowsドメインコントローラ.

Xサーバメンバーの数.

我々はこの階層を持っています.なぜなら、最初にDCを作成する必要があるからです.

```
# file: terraform/modules/environments/linux-standalone/main.tf

module "windows-domain-controller" {
    source = "../../distros/windows-server"
    ...
}

module "windows-server-member" {
    source = "../../distros/windows-server"
    ...
    windows_domain_controller = module.windows-domain-controller
    ...
}
```

何がディストリビューションですか?
ディストリビューションは、セットアップと/またはプロビジョニングの特定の種類のamiの事前定義された種類です.
各モジュールdistro がパスterraform/modules/distros . プロビジョニングを実行するには、適切な再生可能な脚本を持っている.
これらの例を例に挙げて説明します.

Linux

Windows

スパンク

自由なBSD

terraformの例

```

locals {
...
provisioning_command     = "ansible-playbook -i $PUBLIC_IP /opt/automation/tools/ansible/playbooks/windows.yml --extra-vars='${local.extra_vars}'"
}

...

resource "aws_instance" "windows_server" {
...
}

resource "null_resource" "ansible" {

triggers = {
    command = replace(local.provisioning_command, "$PUBLIC_IP", "'${aws_instance.windows_server.public_ip},'")
}

provisioner "local-exec" {
    command = replace(local.provisioning_command, "$PUBLIC_IP", "'${aws_instance.windows_server.public_ip},'")
}
}
```

分別のある

オープンソースのソフトウェアプロビジョニング、構成管理、およびアプリケーション展開ツールをコードとしてインフラストラクチャを有効にします.これは多くのUnixライクなシステムで動作し、マイクロソフトWindowsと同様にUnixライクなシステムを設定することができます.
詳細についてはofficial documentation .
不安定な構造

```
ansible/
├── all_roles
│   ├── distros
│   │   └── <distro-type>
│   │       └── roles
│   │           └── <distro-role>
└── playbooks
```

どのようなディストリビューションのタイプですか?
ディストリビューション型は、特定の実行で使用できるすべての操作可能なロールを集中するフォルダです.
Windowsを例にとります.ansible/all_roles/distros/windows . このフォルダは、Windowsマシンで実行される使用可能なすべてのロールを集中します.
どのようなディストリビューションの役割ですか?
ディストリビューションロールは、機能を表す関連する構成を実装する、わかりやすいタスクのグループです.
詳細については、次のようにします.
をダウンロード
ダウンロードファイルをインストールします
-設定のデフォルト設定
を開始します.

設定ファイルの説明

ここでは、完全な設定例を見つけることができます.

config = {
  "myenv01" = {
    "type" = "windows_standalone"
    "nodes" = {
      "myvm01" = {
        "type" = "windows"
        "enabled_roles" = {
          "windows_funcionality01" = true
          "windows_funcionality02" = true
        }
        "os" = {
          "size"    = "t2.medium"
          "distro"  = "windows"
          "type"    = "windows"
          "version" = "2016"
        }
      }
    }
  }
  "myvm02" = {
    "type" = "linux_standalone"
    "nodes" = {
      "mylinux01" = {
        "type" = "linux"
        "enabled_roles" = {
          "linux_funcionality01" = true
          "linux_funcionality02" = true
        }
        "os" = {
          "size"    = "t2.medium"
          "distro"  = "ubuntu"
          "type"    = "linux"
          "version" = "20"
        }
      }
    }
  }
}

フードの下で、この構成はAWSで2つのEC 2インスタンスをつくるために翻訳されます、そして、各々の例は特定の役割で脚本を走らせます.
ブロック説明:

各ブロックmyenv0x 環境がどのように展開されるかを表します.この型はどの定義済み環境を使用するかを表します.

各ブロックmyvm0x 作成されるVMを表します.この型は、定義済みのディストリビューションを使用することを表します.

ブロックos 適切なEC 2インスタンスを作成する4つのプロパティがあります.

AWSタイプのインスタンス

ディストリビューションの種類( Windows , Linuxなど)

OSのディストリビューション( Ubuntu , Debian , SUSE , Windowsなど)

OSのバージョン

この情報を使用すると、TorraformはどのAWS AmiがEC 2インスタンスでスピンを使用するかを知るでしょう

ブロックenabled_roles 各インスタンスで実行可能なロールの一覧を表します

コードと実装の詳細についてはcode demo , 完全に機能.