SaltStackインフラストラクチャ:DigitalOceanリソースをスピンアップするためのSalt-Cloudの構成

提供:Dev Guides
移動先:案内検索

序章

SaltStack(Salt)は、構造化された反復可能な方法でインフラストラクチャを簡単に管理するために使用できる強力なリモート実行および構成管理システムです。 このシリーズでは、Saltデプロイメントから開発、ステージング、および実稼働環境を管理する1つの方法を示します。 ソルト状態システムを使用して、繰り返し可能なアクションを記述して適用します。 これにより、環境を破壊することができます。後で同じ状態で簡単にオンラインに戻すことができるため、安全です。

最後のガイドでは、Saltマスターサーバーの初期構成を完了することから始めました。 これで、このサーバーが実行され、Saltコマンドを自身に発行できるようになります。 このガイドでは、salt-cloudコンポーネントを構成することにより、Saltマスターの範囲を拡大します。 これにより、DigitalOceanアカウントに接続して、必要に応じてリソースを起動できるようになります。 個々のコンポーネントと環境全体のプロパティを定義するプロファイルを作成します。

前提条件

このチュートリアルを完了するには、このガイドで概説されているようにSaltマスターサーバーを構成する必要があります。 このガイドの手順は、そのサーバーのroot以外のユーザーアカウントを使用して完了します。

また、DigitalOceanアカウントにアクセスする必要があります。 salt-cloudコマンドを介してDigitalOceanAPIを活用し、さまざまな環境を構成するサーバーを作成および制御します。 この目的のためにAPIトークンを作成する必要があります。これについては、ガイドで説明します。

メインクラウドミニオン構成を作成する

まず、/etc/salt/cloudに構成ファイルを作成します。 これは、作成するすべてのサーバーに共通のオプションとして使用されます。 今すぐファイルを作成して開きます。

sudo nano /etc/salt/cloud

この時点で適用する唯一の構成は、作成する各サーバーに設定される/etc/salt/minionオプションです。 minion:キーを使用して、この情報の構造を開始します。

/ etc / salt / cloud

minion:

このキーの下で、SaltマスターサーバーのIPアドレスを指定することから始めます。 これは、プロビジョニング後にソルトミニオンがマスターに接続できるようにするため、最も重要な設定です。

/ etc / salt / cloud

minion:
  master: master_server_ip

ノート

YAMLファイルには非常に注意深い間隔が必要であることに注意してください。 通常、追加のインデントレベルごとに2つのスペースが使用されます。


次に、いくつかの鉱山機能を設定する必要があります。 ソルトミニオンは、ソルト実行モジュールの結果をソルトマスターの中央リポジトリに送り返すように構成できます。 このシステムは、ミニオンサーバーが他のミニオンと重要な情報を共有するための手段を提供します。

2つの鉱山機能を設定したいと思います。 これらは、ミニオンのパブリックIPアドレスとプライベートIPアドレスをSaltマスターに返すだけです。 他のミニオンは、ピアに接続する方法を学習するために、この情報をマスターに照会できます。

/ etc / salt / cloud

minion:
  master: master_server_ip
  mine_functions:
    external_ip:
      - mine_function: network.interface_ip
      - eth0
    internal_ip:
      - mine_function: network.interface_ip
      - eth1

終了したら、ファイルを保存して閉じます。

DigitalOceanクラウドプロバイダーをセットアップする

次に、DigitalOceanクラウドプロバイダーファイルを構成します。 これには、DigitalOceanアカウントに接続するために必要な情報と、作成するサーバーに使用する一般的な設定が含まれます。

プロバイダー情報のディレクトリを作成することから始めます。

sudo mkdir -p /etc/salt/cloud.providers.d

内部で、do.confというファイルを作成して開きます。

sudo nano /etc/salt/cloud.providers.d/do.conf

内部で、別のYAML構造を作成します。 構造の最上位のキーは、プロバイダーの名前になります。 ここでは「do」を使用します。 driverは、使用するクラウドを指定します。 SaltのDigitalOceanのドライバーはdigital_oceanと呼ばれます。

/etc/salt/cloud.providers.d/do.conf

do:
  driver: digital_ocean

次に、DigitalOceanアカウントに移動して、APIトークンを作成する必要があります。 このリンクをたどると、コントロールパネルのAPIセクションにアクセスできます。 ページの右上隅にある[新しいトークンを生成]ボタンをクリックします。

次のページで、わかりやすい名前を入力し、[トークンの生成]をクリックします。

次のページの下部に、新しいトークンが表示されます。

この値は再度表示されないため、ページを離れる前にこの値をコピーしてください。 これを忘れた場合は、トークンを破棄して新しいトークンを生成してください。

プロバイダー構成ファイルに戻り、personal_access_tokenオプションをコピーした生成されたトークンの値に設定します。

/etc/salt/cloud.providers.d/do.conf

do:
  driver: digital_ocean
  personal_access_token: digitalocean_api_token

次に、SSHキー情報を指定します。 salt-cloudコマンドは、Salt minionをセットアップするために、最初にSSHを使用してサーバーにログインする必要があります。 ssh_key_fileキーを設定して、SSH秘密キーをまもなくコピーするファイルシステム上の場所を指すようにします。 ssh_key_namesを、DigitalOceanに追加したSSHキーの名前に設定する必要があります。

/etc/salt/cloud.providers.d/do.conf

do:
  driver: digital_ocean
  personal_access_token: digitalocean_api_token
  ssh_key_file: /etc/salt/pki/cloud/do.pem
  ssh_key_names: Work key,Home key

また、新しいミニオンにデプロイされるSaltの正確なバージョンを制御できるように、スクリプトとスクリプト引数を指定する必要があります。

/etc/salt/cloud.providers.d/do.conf

do:
  driver: digital_ocean
  personal_access_token: digitalocean_api_token
  ssh_key_file: /etc/salt/pki/cloud/do.pem
  ssh_key_names: Work key,Home key
  script: bootstrap-salt
  script_args: -P git v2015.8.0

終了したら、ファイルを保存して閉じます。 次のように入力すると、Saltmaterによってプロバイダー構成が取得されたことがわかります。

sudo salt-cloud --list-providers
Outputdo:
    ----------
    digital_ocean:
        ----------

次のように入力して、APIキーをテストできます。

sudo salt-cloud --list-locations do

展開に使用できるリージョンのリストが表示されます。

SSHキーファイルを作成する

先に進む前に、プロバイダーファイルで参照したSSH秘密鍵ファイルを作成する必要があります。 必要なディレクトリ構造を作成することから始めます。

sudo mkdir -p /etc/salt/pki/cloud

次に、新しく作成したディレクトリ内にdo.pemというファイルを作成します。

sudo nano /etc/salt/pki/cloud/do.pem

プロバイダーファイルのssh_key_namesディレクティブで指定したDigitalOceanキーの1つに関連付けられている秘密キーの内容を貼り付けます。 通常、ローカルコンピューターに次のように入力すると、秘密鍵の内容を取得できます。

cat ~/.ssh/id_rsa

次のようになります。

ローカルコンピューター上の〜/ .ssh / id_rsa

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA39KuD8htHaIgUGFezpTsW0Y5XtNuoSTwVg/nih1rlVyKQIkJ
UhJRAakJ9ktQjSWdyAQr0i563WU1KYeHMzQuPPOQAK0vTbMjO5StuzqPEVfPPI1n
PIbMeAg9rjX5Lhy/jSOcTwf0E91jTMYuxkZCMCIDTzeVEFLV744APotQktCruJXf
L53cVUedOI1fQTEKGa1xEk92Ja4jm/Fn+4WKqYVTKRd2/vHX/ej8bI9Pomamskvc

. . .

hd4tdQKBgQCD8s2IbXVfGQ8x0D12a5K7sfysdnESF5I5ladEAoWP4wYctuGdlDso
lBl+jlm1di+1gPqBDMdJhic48ExRBVjKfB1adDeiwhzD4zNxFakhBXHjXHj6MBps
Oo/13JyvRs6QRpBolJfVaG1b5CAR+EhAJkxxCxWch8dlwE1gb9jxXw==
-----END RSA PRIVATE KEY-----

それを/etc/salt/pki/cloud/do.pemのファイルに貼り付けてから、ファイルを保存して閉じます。

Saltがキーを使用するには、キーを含むファイルとディレクトリに正しい権限が必要です。 次のように入力して権限を設定します。

sudo chmod 700 /etc/salt/pki/cloud
sudo chmod 600 /etc/salt/pki/cloud/do.pem

これで、Saltは秘密鍵を読み取り、それを使用して新しいサーバーにログインできるようになりました。

クラウドプロファイルを設定する

DigitalOceanプロバイダーを構成したので、プロファイルを作成できます。 これらのプロファイルは、新しいサーバーインスタンスを構築するときに使用するプロパティを定義します。 必要な数だけ構成できます。

これらのファイルはcloud.profiles.dディレクトリに保存されます。 今すぐそのディレクトリを作成します。

sudo mkdir -p /etc/salt/cloud.profiles.d

このガイドでは、構成する環境ごとに個別のファイルを使用します。 開発環境から始めましょう:

sudo nano /etc/salt/cloud.profiles.d/dev-profiles.conf

各プロファイルは、トップレベルのプロファイル名で指定されます。 名前は、提供された詳細を使用してドロップレットを作成するときに使用するものです。

base-devプロファイルを指定することから始めます。 これには、すべての開発マシンで共有される基本的なプロパティが含まれます。 このガイドでは、NYC3リージョンの1ギガバイトのドロップレットでUbuntu14.0464ビットを使用することを指定しています。 NYC3は、Saltマスターが展開されているリージョンであり、必要に応じてプライベートネットワークを使用して通信できるようになります。 これを念頭に置いて、プライベートネットワーキング(これは構成で使用されます!)とIPv6を有効にします。

次のコマンドから返される情報を使用して、必要に応じてサイズと領域を変更できます。

sudo salt-cloud --list-locations do
sudo salt-cloud --list-sizes do

返される出力では、使用するサイズと場所に関連付けられている「スラッグ」が、構成内で使用する必要のある名前です。

上記で説明したドロップレット情報を使用すると、base-devは次のようになります。

/etc/salt/cloud.profiles.d/dev-profiles.conf

base-dev:
  provider: do
  image: ubuntu-14-04-x64
  size: 1gb
  location: nyc3
  private_networking: True
  ipv6: True

このプロファイルは、必要な詳細のほとんどを提供しますが、ミニオンにいくつかのカスタムソルトグレインも含めたいと思います。 これらは、特定のマシンがインフラストラクチャおよびその一部である環境で果たす役割に基づいて、それらのマシンをターゲットにするために使用されます。

これは、ベースプロファイルを「拡張」することで実行できます。 拡張すると、既存のプロファイルの特性を継承する新しいプロファイルを指定し、新しい値を追加できます。 ただし、継承はかなり厄介であり、単一の拡張のみを許可します(拡張を拡張することはできません)。 また、リストアイテム(グレインなど)は、以前のデータを追加するのではなく置き換えます(そのため、環境内のすべてのサーバーで共有されているにもかかわらず、ベースで環境を指定できませんでした)。

Webサーバー固有のプロファイルは非常に単純です。 元の属性をすべて使用し、指定した2つのグレインを追加します。 「webserver」の役割を使用しています。 チュートリアル全体を通して、これと照合します。 開発環境は「dev」値で示されます。

/etc/salt/cloud.profiles.d/dev-profiles.conf

base-dev:
  provider: do
  image: ubuntu-14-04-x64
  size: 1gb
  location: nyc3
  private_networking: True
  ipv6: True

dev-web:
  extends: base-dev
  minion:
    grains:
      role: webserver
      env: dev

私たちのデータベースプロファイルは、ほぼ同じように機能します。 「webserver」の代わりに「dbserver」の役割を使用し、dev-dbプロファイルIDを使用します。

/etc/salt/cloud.profiles.d/dev-profiles.conf

base-dev:
  provider: do
  image: ubuntu-14-04-x64
  size: 1gb
  location: nyc3
  private_networking: True
  ipv6: True

dev-web:
  extends: base-dev
  minion:
    grains:
      role: webserver
      env: dev

dev-db:
  extends: base-dev
  minion:
    grains:
      role: dbserver
      env: dev

終了したら、ファイルを保存して閉じます。

ステージング環境用に同様のファイルを作成します。 次のように入力してファイルを作成します。

sudo nano /etc/salt/cloud.profiles.d/stage-profiles.conf

base-stageプロファイルは、base-devプロファイルとまったく同じです。 拡張プロファイルも以前の定義と厳密に一致し、環境と名前のみを変更します。 ロードバランサーの拡張プロファイルも追加します。これは、開発環境には存在しないサーバータイプであるためです。

/etc/salt/cloud.profiles.d/stage-profiles.conf

base-stage:
  provider: do
  image: ubuntu-14-04-x64
  size: 1gb
  location: nyc3
  private_networking: True
  ipv6: True

stage-web:
  extends: base-stage
  minion:
    grains:
      role: webserver
      env: stage

stage-db:
  extends: base-stage
  minion:
    grains:
      role: dbserver
      env: stage

stage-lb:
  extends: base-stage
  minion:
    grains:
      role: lbserver
      env: stage

終了したら、ファイルを保存して閉じます。

最後に、本番プロファイルを作成しましょう。

sudo nano /etc/salt/cloud.profiles.d/prod-profiles.conf

本番プロファイルは、ステージングプロファイルとほぼ完全に同じです。 文字列「stage」のすべてのインスタンスを「prod」に変更するだけです。

/etc/salt/cloud.profiles.d/prod-profiles.conf

base-prod:
  provider: do
  image: ubuntu-14-04-x64
  size: 1gb
  location: nyc3
  private_networking: True
  ipv6: True

prod-web:
  extends: base-prod
  minion:
    grains:
      role: webserver
      env: prod

prod-db:
  extends: base-prod
  minion:
    grains:
      role: dbserver
      env: prod

prod-lb:
  extends: base-prod
  minion:
    grains:
      role: lbserver
      env: prod

終了したら、ファイルを保存して閉じます。

次のように入力して、プロファイルが取得されていることをテストします。

sudo salt-cloud --list-profiles do

構成したすべてのプロファイルのリストが表示されます。

環境マップを作成する

これで、必要な個々のサーバーを作成する方法を正確に定義するプロファイルができました。 これらを使用して、必要なサーバーを1つずつ簡単に作成できます。

ただし、salt-cloudは、「マップ」と呼ばれる追加の構成ファイルを利用することもできます。 マップを使用すると、構築する完全なインフラストラクチャの概要を示すために、作成したプロファイルを参照できます。 プロファイルタイプごとに作成するサーバーの名前を指定します。

cloud.maps.dと呼ばれるマップファイルを保持するディレクトリを作成します。

sudo mkdir -p /etc/salt/cloud.maps.d

開発環境を定義することから始めましょう。 このディレクトリ内にdev-environment.mapというファイルを作成して開きます。

sudo nano /etc/salt/cloud.maps.d/dev-environment.map

構成する環境の概要を説明した前の記事を思い出してください。開発環境には、Webサーバーとデータベースサーバーの2つのサーバーしかありません。 これを知っていると、開発マップファイルは次のようになります。

/etc/salt/cloud.maps.d/dev-environment.map

dev-web:
  - dev-web

dev-db:
  - dev-db

トップレベルの項目は、リソースのプロビジョニングに使用されているプロファイルを示します。 プロファイル名(ダッシュで示されている)の下のリストは、起動するサーバーの名前を示しています。

この例では、「dev-web」と呼ばれるWebサーバーと「dev-db」と呼ばれるデータベースサーバーを定義します。 salt-cloudをこのファイルにポイントすることで、これらのサーバーの両方を同時に作成できます。 終了したら、ファイルを保存して閉じます。

次に、ステージング環境マップを作成しましょう。

sudo nano /etc/salt/cloud.maps.d/stage-environment.map

ステージング環境には、2つのWebサーバー、2つのデータベースサーバー、およびロードバランサーがあります。 冗長サーバーに番号を付けて、それらを区別します。 マップは次のようになります。

/etc/salt/cloud.maps.d/stage-environment.map

stage-web:
  - stage-www1
  - stage-www2

stage-db:
  - stage-db1
  - stage-db2

stage-lb:
  - stage-lb

このファイルには、合計5台のサーバーをプロビジョニングする機能があります。 終了したら、ファイルを保存して閉じます。

最後に、次のように入力して、本番環境のマップファイルを作成できます。

sudo nano /etc/salt/cloud.maps.d/prod-environment.map

これは、ステージング環境マップとかなり似ています(サーバー名と使用されるプロファイルの明らかな例外を除きます)。 本番環境には追加のロードバランサーがあり、フェイルオーバーを構成できます。

/etc/salt/cloud.maps.d/prod-environment.map

prod-web:
  - prod-www1
  - prod-www2

prod-db:
  - prod-db1
  - prod-db2

prod-lb:
  - prod-lb1
  - prod-lb2

本番環境に必要なベアサーバーは、このファイルで試運転できます。 終了したら、保存して閉じます。

環境プロビジョニングのテスト

マップファイルが作成されたので、環境の一部またはすべてを簡単に起動できます。

これを行う前に、Saltブートストラップスクリプトをマスターサーバーにダウンロードする必要があります。 マスターはミニオンに接続し、スクリプトをアップロードして実行し、作成したサーバーでソルトミニオンを起動します。

次のように入力して、ブートストラップスクリプトをダウンロードします。

sudo salt-cloud -u

このコマンドは、最新バージョンのブートストラップスクリプトを使用していることを確認するために、時々実行する必要があります。

ブートストラップスクリプトがダウンロードされると、salt-cloudコマンドを使用して任意の環境を起動できます。 これは、リソースが最も少ないプロセスを示しているため、開発環境でテストします。

salt-cloudにサーバーを並列に作成するように指示するために、-Pフラグを渡します。 これがないと、Saltは1つのサーバーがブートストラップを終了するのを待ってから、次のサーバーでの作業を開始します。 -mフラグを使用して、使用する環境マップを指す必要があります。

完全なコマンドは次のようになります。

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/dev-environment.map

そのファイルで定義されている2つのサーバーの作成を確認するように求められます。

Output[INFO    ] salt-cloud starting
[INFO    ] Applying map from '/etc/salt/cloud.maps.d/dev-environment.map'.
[INFO    ] Starting new HTTPS connection (1): api.digitalocean.com
The following virtual machines are set to be created:
  dev-db
  dev-web

Proceed? [N/y]

「Y」と入力してサーバーを作成します。

サーバーが作成されたら、次のように入力してSalt接続を確認できます。

sudo salt '*' test.ping

ソルトマスターミニオンと両方の新しい開発マシンから応答を受け取る必要があります。 プロビジョニングプロセス中に、Saltマスターは、新しいサーバーをミニオンマシンに配置する前に、それらのキーを生成して受け入れました。 このため、salt-keyを使用して新しい各キーを受け入れる必要はありません。 新しいサーバーはすぐに応答する必要があります。

Outputdev-db:
    True
sm:
    True
dev-web:
    True

マップファイルを使用して、グループとして定義されたサーバーにsalt-cloudコマンドを発行できます。 現時点で開発マシンを使用する予定がない場合は、次のように入力して、開発マシンを再度破棄してください。

sudo salt-cloud -d -m /etc/salt/cloud.maps.d/dev-environment.map

これにより、APIを介してサーバーが破棄され、ストアからミニオンキーが削除されます。

または、名前で個々のマシンを破棄することもできます。

sudo salt-cloud -d dev-db

そうすると、次にマップファイルを使用して作成するときに、salt-cloudはまだ存在していないサーバーのみを作成します。

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/dev-environment.map
Output[INFO    ] salt-cloud starting
[INFO    ] Applying map from '/etc/salt/cloud.maps.d/dev-environment.map'.
[INFO    ] Starting new HTTPS connection (1): api.digitalocean.com
[WARNING ] u'dev-web' already exists, removing from the create map.
The following virtual machines already exist:
  dev-web
The following virtual machines are set to be created:
  dev-db

Proceed? [N/y]

この時点で他のマップファイルを自由にテストして、構成する環境に必要なサーバーを正しくプロビジョニングできることを確認してください。

結論

この時点で、Saltマスターサーバーは、DigitalOceanクラウドプロバイダーを使用してリソースを完全に起動できる必要があります。 個々のマシンの特性のプロファイルを作成し、各セットアップに必要な個々のサーバーを簡単に説明するためのマップを確立しました。

このシリーズの次のガイドでは、再現可能なNginx構成をセットアップすることにより、Saltの構成管理機能について詳しく説明します。