an-introduction-to-cloud-config-scripting
前書き
最近のディストリビューション(この記事の執筆時点ではUbuntu 14.04およびCentOS 7のみ)で利用可能な `+ cloud-init `プログラムは、https://の ` user-data `フィールドのデータを消費して実行できます。 www.digitalocean.com/community/tutorials/an-introduction-to-droplet-metadata[DigitalOceanメタデータサービス]。 このプロセスは、検出した情報の形式によって動作が異なります。 ` user-data +`内のスクリプトの最も一般的な形式の1つは、* cloud-config *ファイル形式です。
cloud-configファイルは、cloud-initプロセスによって実行されるように設計された特別なスクリプトです。 これらは通常、サーバーの最初の起動時の初期構成に使用されます。 このガイドでは、cloud-configファイルの形式と使用方法について説明します。
Cloud-Configに関する一般情報
`+ cloud-config +`形式は、多くの一般的な設定項目の宣言構文を実装しており、多くのタスクを簡単に実行できます。 また、定義済みの宣言機能の範囲外にあるものに任意のコマンドを指定できます。
この「両方のベスト」アプローチにより、ファイルは一般的なタスクの構成ファイルのように機能し、より複雑な機能のスクリプトの柔軟性を維持します。
YAMLフォーマット
ファイルはYAMLデータシリアル化形式を使用して書き込まれます。 YAML形式は、人間が理解しやすく、プログラムで解析しやすいように作成されました。
YAMLファイルは一般に、それらを読むときに理解するのがかなり直感的ですが、それらを支配する実際のルールを知っているのは良いことです。
YAMLファイルの重要なルールは次のとおりです。
-
空白を含むインデントは、アイテムの構造と相互の関係を示します。 よりインデントされたアイテムは、最初のアイテムのサブアイテムであり、その上のインデントのレベルは低くなります。
-
リストのメンバーは、先頭のダッシュで識別できます。
-
連想配列エントリは、コロン(:)の後にスペースと値を続けて作成されます。
-
テキストのブロックはインデントされます。 フォーマットを維持したままブロックをそのまま読み込む必要があることを示すには、ブロックの前にパイプ文字(|)を使用します。
これらのルールを使用して、フォーマットのみに注意して、サンプルの「+ cloud-config +」ファイルを分析しましょう。
#cloud-config
users:
- name: demo
groups: sudo
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
ssh-authorized-keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDf0q4PyG0doiBQYV7OlOxbRjle026hJPBWD+eKHWuVXIpAiQlSElEBqQn0pOqNJZ3IBCvSLnrdZTUph4czNC4885AArS9NkyM7lK27Oo8RV888jWc8hsx4CD2uNfkuHL+NI5xPB/QT3Um2Zi7GRkIwIgNPN5uqUtXvjgA+i1CS0Ku4ld8vndXvr504jV9BMQoZrXEST3YlriOb8Wf7hYqphVMpF3b+8df96Pxsj0+iZqayS9wFcL8ITPApHi0yVwS8TjxEtI3FDpCbf7Y/DmTGOv49+AWBkFhS2ZwwGTX65L61PDlTSAzL+rPFmHaQBHnsli8U9N6E4XHDEOjbSMRX [email protected]
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcthLR0qW6y1eWtlmgUE/DveL4XCaqK6PQlWzi445v6vgh7emU4R5DmAsz+plWooJL40dDLCwBt9kEcO/vYzKY9DdHnX8dveMTJNU/OJAaoB1fV6ePvTOdQ6F3SlF2uq77xYTOqBiWjqF+KMDeB+dQ+eGyhuI/z/aROFP6pdkRyEikO9YkVMPyomHKFob+ZKPI4t7TwUi7x1rZB1GsKgRoFkkYu7gvGak3jEWazsZEeRxCgHgAV7TDm05VAWCrnX/+RzsQ/1DecwSzsP06DGFWZYjxzthhGTvH/W5+KFyMvyA+tZV4i1XM+CIv/Ma/xahwqzQkIaKUwsldPPu00jRN [email protected]
runcmd:
- touch /test.txt
このファイルを見ると、多くの重要なことがわかります。
最初に、各 `+ cloud-config `ファイルは最初の行で `#cloud-config `のみで始まる必要があります。 これはcloud-initプログラムに、これが ` cloud-config +`ファイルとして解釈されるべきであることを通知します。 これが通常のスクリプトファイルである場合、最初の行はファイルの実行に使用されるインタープリターを示します。
上記のファイルには、2つのトップレベルのディレクティブ、「+ users 」と「 runcmd +」があります。 これらは両方ともキーとして機能します。 これらのキーの値は、キーの後のインデントされたすべての行で構成されます。
`+ users `キーの場合、値は単一のリスト項目です。 これは、次のレベルのインデントがリスト項目を指定するダッシュ(-)であり、このインデントレベルにダッシュが1つしかないためです。 ` users +`ディレクティブの場合、これは偶発的に、単一のユーザーのみを定義していることを示します。
リスト項目自体には、より多くのキーと値のペアを持つ連想配列が含まれています。 これらはすべて同じレベルのインデントで存在するため、兄弟要素です。 各ユーザー属性は、上で説明した単一のリストアイテムに含まれています。
注意すべき点は、表示される文字列は引用符を必要とせず、関連付けを定義するための不必要な括弧がないことです。 インタプリタはデータタイプをかなり簡単に判断でき、インデントは人間とプログラムの両方のアイテムの関係を示します。
ここまでで、YAML形式の実用的な知識が得られ、上記で説明したルールを使用して情報を快適に操作できるはずです。
これで、 `+ cloud-config +`の最も一般的なディレクティブのいくつかの調査を開始できます。
ユーザーとグループの管理
システムで新しいユーザーを定義するには、上記のサンプルファイルで見た `+ users +`ディレクティブを使用できます。
ユーザー定義の一般的な形式は次のとおりです。
#cloud-config
users:
-
-
新しいユーザーはそれぞれダッシュで始める必要があります。 各ユーザーは、キーと値のペアでパラメーターを定義します。 次のキーを定義に使用できます。
-
* name *:アカウントのユーザー名。
-
* primary-group *:ユーザーのプライマリグループ。 デフォルトでは、これはユーザー名に一致するグループが作成されます。 ここで指定するグループは、すでに存在するか、明示的に作成する必要があります(これについてはこのセクションで後述します)。
-
グループ:任意の補足グループをコンマで区切ってここにリストできます。
-
* gecos *:ユーザーに関する補足情報のフィールド。
-
* shell *:ユーザーに設定するシェル。 これを設定しない場合、非常に基本的な `+ sh +`シェルが使用されます。
-
* expiredate *:アカウントが期限切れになる日付、YYYY-MM-DD形式。
-
* sudo *:ユーザー名フィールドなしでsudo特権を定義する場合に使用するsudo文字列。
-
* lock-passwd *:これはデフォルトで「True」に設定されています。 これを「False」に設定して、ユーザーがパスワードでログインできるようにします。
-
* passwd *:アカウントのハッシュ化されたパスワード。
-
* ssh-authorized-keys *: `+ .ssh `ディレクトリにあるこのユーザーの ` authorized_keys +`ファイルに追加する必要がある完全なSSH公開キーのリスト。
-
* inactive *:アカウントを非アクティブに設定するブール値。
-
* system *:「True」の場合、このアカウントはホームディレクトリのないシステムアカウントになります。
-
* homedir *:デフォルトの `+ / home / <username> +`をオーバーライドするために使用されます。それ以外の場合は作成および設定されます。
-
* ssh-import-id *:LaunchPadからインポートするSSH ID。
-
* selinux-user *:これは、このアカウントのログインに使用するSELinuxユーザーを設定するために使用できます。
-
* no-create-home *:ユーザーの `+ / home / <username> +`ディレクトリを作成しないようにするには、「True」に設定します。
-
* no-user-group *:「True」に設定すると、ユーザーと同じ名前のグループが作成されなくなります。
-
* no-log-init *:「True」に設定すると、ユーザーログインデータベースが開始されません。
`+ name +`キーのようないくつかの基本的な情報以外に、デフォルトから逸脱したり、必要なデータを提供したりするエリアのみを定義する必要があります。
ユーザーが理解するために重要なことの1つは、指定された値をすぐに変更するメカニズムがない限り、実稼働システムで `+ passwd +`フィールドを使用しないことです。 ユーザーデータとして送信されたすべての情報と同様に、サーバーの全寿命の間、システム上のすべてのユーザーがハッシュにアクセスできます。 最新のハードウェアでは、これらのハッシュは簡単な時間で簡単に解読できます。 ハッシュでさえ公開することは、使い捨てではないマシンでとるべきではない大きなセキュリティリスクです。
ユーザー定義の例として、上で見た例 `+ cloud-config +`の一部を使用できます。
#cloud-config
users:
- name: demo
groups: sudo
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
ssh-authorized-keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDf0q4PyG0doiBQYV7OlOxbRjle026hJPBWD+eKHWuVXIpAiQlSElEBqQn0pOqNJZ3IBCvSLnrdZTUph4czNC4885AArS9NkyM7lK27Oo8RV888jWc8hsx4CD2uNfkuHL+NI5xPB/QT3Um2Zi7GRkIwIgNPN5uqUtXvjgA+i1CS0Ku4ld8vndXvr504jV9BMQoZrXEST3YlriOb8Wf7hYqphVMpF3b+8df96Pxsj0+iZqayS9wFcL8ITPApHi0yVwS8TjxEtI3FDpCbf7Y/DmTGOv49+AWBkFhS2ZwwGTX65L61PDlTSAzL+rPFmHaQBHnsli8U9N6E4XHDEOjbSMRX [email protected]
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcthLR0qW6y1eWtlmgUE/DveL4XCaqK6PQlWzi445v6vgh7emU4R5DmAsz+plWooJL40dDLCwBt9kEcO/vYzKY9DdHnX8dveMTJNU/OJAaoB1fV6ePvTOdQ6F3SlF2uq77xYTOqBiWjqF+KMDeB+dQ+eGyhuI/z/aROFP6pdkRyEikO9YkVMPyomHKFob+ZKPI4t7TwUi7x1rZB1GsKgRoFkkYu7gvGak3jEWazsZEeRxCgHgAV7TDm05VAWCrnX/+RzsQ/1DecwSzsP06DGFWZYjxzthhGTvH/W5+KFyMvyA+tZV4i1XM+CIv/Ma/xahwqzQkIaKUwsldPPu00jRN [email protected]
グループを定義するには、 `+ groups +`ディレクティブを使用する必要があります。 このディレクティブは、作成するグループのリストを取得するという点で比較的単純です。
これに対するオプションの拡張機能は、作成しているグループのサブリストを作成することです。 この新しいリストは、このグループに配置されるユーザーを定義します。
#cloud-config
groups:
-
- : [, ]
既存のユーザーのパスワードを変更する
すでに存在するユーザーアカウント( `+ root `アカウントが最も適切です)の場合、 ` chpasswd +`ディレクティブを使用してパスワードを追加できます。
注:このディレクティブは、デバッグの状況でのみ使用する必要があります。これは、サーバーの存続期間中、システム上のすべてのユーザーが再び値を使用できるためです。 このディレクティブで送信されるパスワードは*プレーンテキスト*で指定する必要があるため、これはこのセクションでさらに関連します。
基本的な構文は次のようになります。
#cloud-config
chpasswd:
list: |
:
:
:
expire: False
このディレクティブには、2つの連想配列キーが含まれています。 `+ list `キーには、割り当てたいアカウント名と関連パスワードをリストするブロックが含まれます。 ` expire +`キーは、初回起動時にパスワードを変更する必要があるかどうかを決定するブール値です。 デフォルトは「True」です。
注意すべきことは、パスワードを「ランダム」または「R」に設定すると、ランダムなパスワードが生成され、それが「+ / var / log / cloud-init-output.log +」に書き込まれることです。 このファイルはシステム上のすべてのユーザーがアクセスできるため、これ以上安全ではないことに注意してください。
ファイルをディスクに書き込む
ファイルをディスクに書き込むには、 `+ write_files +`ディレクティブを使用する必要があります。
書き込まれる各ファイルは、ディレクティブの下のリスト項目によって表されます。 これらのリスト項目は、各ファイルのプロパティを定義する連想配列になります。
この配列に必要なキーは、ファイルを書き込む場所を定義する「+ path 」と、ファイルに含めるデータを含む「 content +」のみです。
`+ write_files +`アイテムを設定するために利用可能なキーは次のとおりです。
-
* path *:ファイルを書き込むファイルシステム上の場所への絶対パス。
-
* content *:ファイルに配置する必要があるコンテンツ。 複数行入力の場合、「コンテンツ」行でパイプ文字(|)を使用してブロックを開始し、コンテンツを含むインデントされたブロックを続けます。 バイナリファイルには、「!! binary」とパイプ文字の前にスペースを含める必要があります。
-
所有者:ファイルの所有権を付与する必要があるユーザーアカウントとグループ。 これらは「username:group」形式で指定する必要があります。
-
* permissions *:このファイルに与えられるべき8進数の許可セット。
-
* encoding *:ファイルのオプションのエンコード仕様。 これは、Base64ファイルの場合は「b64」、Gzip圧縮ファイルの場合は「gzip」、組み合わせの場合は「gz + b64」です。 これを省略すると、デフォルトの従来のファイルタイプが使用されます。
たとえば、次の内容でファイルを `+ / test.txt +`に書き込むことができます。
Here is a line.
Another line is here.
これを達成する `+ cloud-config +`の部分は次のようになります。
#cloud-config
write_files:
- path: /test.txt
content: |
Here is a line.
Another line is here.
サーバーでパッケージを更新またはインストールする
パッケージを管理するには、いくつかの関連する設定とディレクティブに留意する必要があります。
Debianベースのディストリビューションでaptデータベースを更新するには、 `+ package_update `ディレクティブを“ true”に設定する必要があります。 これは、コマンドラインから「 apt-get update」を呼び出すことと同義です。
デフォルト値は実際には「true」であるため、無効にする場合にのみこのディレクティブについて心配する必要があります。
#cloud-config
package_update: false
サーバーの初回起動後にサーバー上のすべてのパッケージをアップグレードする場合、 `+ package_upgrade `ディレクティブを設定できます。 これは、手動で実行される ` apt-get upgrade +`に似ています。
これはデフォルトで「false」に設定されているため、機能が必要な場合は必ず「true」に設定してください。
#cloud-config
package_upgrade: true
追加のパッケージをインストールするには、「packages」ディレクティブを使用してパッケージ名をリストするだけです。 各リスト項目はパッケージを表す必要があります。 上記の2つのコマンドとは異なり、このディレクティブはyumまたはapt管理対象ディストリビューションで機能します。
これらのアイテムは、2つの形式のいずれかを取ることができます。 最初は、パッケージの名前を含む単純な文字列です。 2番目の形式は、2つの項目を持つリストです。 この新しいリストの最初の項目はパッケージ名であり、2番目の項目はバージョン番号です。
#cloud-config
packages:
-
-
- [, ]
「packages」ディレクティブは `+ apt_update +`をtrueに設定し、以前の設定を上書きします。
ユーザーアカウントとSSHデーモンのSSHキーを構成する
SSHキーは `+ users `ディレクティブで管理できますが、専用の ` ssh_authorized_keys +`セクションで指定することもできます。 これらは、最初に定義されたユーザーのauthorized_keysファイルに追加されます。
これは、 `+ users +`ディレクティブ内のキー仕様と同じ一般的な形式を取ります。
#cloud-config
ssh_authorized_keys:
-
-
SSHサーバーの秘密鍵を事前に生成して、ファイルシステムに配置することもできます。 これは、クライアントに事前にこのサーバーに関する情報を提供し、サーバーがオンラインになるとすぐにサーバーを信頼できるようにする場合に便利です。
これを行うには、 + ssh_keys +`ディレクティブを使用できます。 これは、 `+ rsa_private +
、 + rsa_public +
、 + dsa_private +
、 + dsa_public +
、 + ecdsa_private +
、および `+ ecdsa_public +`サブアイテムを使用して、RSA、DSA、またはECDSAキーのキーペアを取得できます。
秘密鍵ではフォーマットと改行が重要であるため、これらを指定するときは必ずパイプキーを持つブロックを使用してください。 また、キーを有効にするには、開始キーと終了キーの行を含める必要があります。
#cloud-config
ssh_keys:
rsa_private: |
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
rsa_public:
信頼できるCA証明書を設定する
インフラストラクチャが内部認証局によって署名されたキーに依存している場合、証明書情報を注入することにより、CA証明書を信頼するように新しいマシンをセットアップできます。 このために、 `+ ca-certs +`ディレクティブを使用します。
このディレクティブには2つのサブアイテムがあります。 1つ目は `+ remove-defaults +`で、trueに設定すると、デフォルトで含まれる通常の証明書信頼情報がすべて削除されます。 これは通常必要ではなく、何をしているのかわからない場合はいくつかの問題を引き起こす可能性があるため、注意して使用してください。
2番目の項目は「+ trusted +」であり、それぞれが信頼できるCA証明書を含むリストです:
#cloud-config
ca-certs:
remove-defaults: true
trusted:
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
特定のDNSサーバーを使用するようにresolv.confを構成する
使用する独自のDNSサーバーを設定している場合は、 `+ resolv_conf +`ディレクティブを使用してサーバーのresolv.confファイルを管理できます。 これは現在、RHELベースのディストリビューションでのみ機能します。
+ resolv_conf +`ディレクティブの下で、 `+ nameservers +
、 + searchdomains +
、 + domain +
、および `+ options +`アイテムで設定を管理できます。
`+ nameservers `ディレクティブは、ネームサーバーのIPアドレスのリストを取る必要があります。 ` searchdomains +`ディレクティブは、ユーザーがドメインではなくホストを指定したときに検索するドメインとサブドメインのリストを受け取ります。
`+ domain `は、解決できないリクエストに使用するドメインを設定し、 ` options +`にはresolv.confファイルで定義できるオプションのセットが含まれます。
`+ resolv_conf `ディレクティブを使用している場合、 ` manage-resolv-conf +`ディレクティブもtrueに設定されていることを確認する必要があります。 そうしないと、設定が無視されます。
#cloud-config
manage-resolv-conf: true
resolv_conf:
nameservers:
- ''
- ''
searchdomains:
-
-
domain:
options:
:
:
:
より詳細な制御のための任意のコマンドの実行
`+ cloud-config `が提供する管理アクションのどれもがやりたいことに対して機能しない場合、任意のコマンドを実行することもできます。 これを行うには、 ` runcmd +`ディレクティブを使用します。
このディレクティブは、実行するアイテムのリストを取ります。 これらのアイテムは、2つの異なる方法で指定できます。これは、アイテムの処理方法に影響します。
リスト項目が単純な文字列である場合、項目全体が実行される `+ sh +`シェルプロセスに渡されます。
もう1つのオプションは、リストを渡すことです。リストの各項目は、 `+ execve +`がコマンドを処理する方法と同様の方法で実行されます。 最初の項目は実行するコマンドまたはスクリプトとして解釈され、次の項目はそのコマンドの引数として渡されます。
ほとんどのユーザーはこれらの形式のいずれかを使用できますが、柔軟性があるため、特別な要件がある場合は最適なオプションを選択できます。 出力はすべて標準出力と `+ / var / log / cloud-init-output.log +`ファイルに書き込まれます:
#cloud-config
runcmd:
- [ sed, -i, -e, 's/here/there/g', some_file]
- echo "modified some_file"
- [cat, some_file]
サーバーのシャットダウンまたは再起動
場合によっては、他の項目を実行した後にサーバーをシャットダウンまたは再起動する必要があります。 これを行うには、 `+ power_state +`ディレクティブを設定します。
このディレクティブには、設定可能な4つのサブアイテムがあります。 これらは、「+ delay」、「+ timeout」、「+ message」、および「+ mode +」です。
`+ delay `は、再起動またはシャットダウンがいつまで発生するかを指定します。 デフォルトでは、これは「今」になり、手順がすぐに開始されることを意味します。 遅延を追加するには、ユーザーは `+ <num_of_mins> +`形式を使用して経過する時間を分単位で指定する必要があります。
「+ timeout 」パラメーターは、「 delay +」カウントダウンを開始する前にcloud-initが完了するまで待機する秒数を表す単位なしの値を取ります。
`+ message `フィールドでは、システムのすべてのユーザーに送信されるメッセージを指定できます。 ` mode +`は、開始する電源イベントのタイプを指定します。 これは、サーバーをシャットダウンする「poweroff」、サーバーを再起動する「reboot」、またはシステムに最適なアクションを決定させる「halt」(通常はシャットダウン)です。
#cloud-config
power_state:
timeout: 120
delay: "+5"
message: Rebooting in five minutes. Please save your work.
mode: reboot
結論
上記の例は、 `+ cloud-config +`ファイルを実行するときに利用できる一般的な設定項目の一部を表しています。 このガイドでは説明しなかった追加機能があります。 これには、構成管理のセットアップ、追加のリポジトリーの構成、およびサーバーの初期化時に外部URLを登録することも含まれます。
これらのオプションの詳細については、 `+ / usr / share / doc / cloud-init / examples `ディレクトリを確認してください。 ` cloud-config +`ファイルに慣れるのに役立つ実用的なガイドについては、https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for-のチュートリアルに従ってください。 your-initial-server-setup [cloud-configを使用して基本的なサーバー構成を完了する方法]はこちらです。