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 +`形式は、多くの一般的な設定項目の宣言構文を実装しており、多くのタスクを簡単に実行できます。 また、定義済みの宣言機能の範囲外にあるものに任意のコマンドを指定できます。

この「両方のベスト」アプローチにより、ファイルは一般的なタスクの構成ファイルのように機能し、より複雑な機能のスクリプトの柔軟性を維持します。

システムで新しいユーザーを定義するには、上記のサンプルファイルで見た `+ users +`ディレクティブを使用できます。

ユーザー定義の一般的な形式は次のとおりです。

新しいユーザーはそれぞれダッシュで始める必要があります。 各ユーザーは、キーと値のペアでパラメーターを定義します。 次のキーを定義に使用できます。

`+ name +`キーのようないくつかの基本的な情報以外に、デフォルトから逸脱したり、必要なデータを提供したりするエリアのみを定義する必要があります。

ユーザーが理解するために重要なことの1つは、指定された値をすぐに変更するメカニズムがない限り、実稼働システムで `+ passwd +`フィールドを使用しないことです。 ユーザーデータとして送信されたすべての情報と同様に、サーバーの全寿命の間、システム上のすべてのユーザーがハッシュにアクセスできます。 最新のハードウェアでは、これらのハッシュは簡単な時間で簡単に解読できます。 ハッシュでさえ公開することは、使い捨てではないマシンでとるべきではない大きなセキュリティリスクです。

ユーザー定義の例として、上で見た例 `+ cloud-config +`の一部を使用できます。

グループを定義するには、 `+ groups +`ディレクティブを使用する必要があります。 このディレクティブは、作成するグループのリストを取得するという点で比較的単純です。

これに対するオプションの拡張機能は、作成しているグループのサブリストを作成することです。 この新しいリストは、このグループに配置されるユーザーを定義します。

すでに存在するユーザーアカウント（ `+ root `アカウントが最も適切です）の場合、 ` chpasswd +`ディレクティブを使用してパスワードを追加できます。

注：このディレクティブは、デバッグの状況でのみ使用する必要があります。これは、サーバーの存続期間中、システム上のすべてのユーザーが再び値を使用できるためです。 このディレクティブで送信されるパスワードは*プレーンテキスト*で指定する必要があるため、これはこのセクションでさらに関連します。

基本的な構文は次のようになります。

このディレクティブには、2つの連想配列キーが含まれています。 `+ list `キーには、割り当てたいアカウント名と関連パスワードをリストするブロックが含まれます。 ` expire +`キーは、初回起動時にパスワードを変更する必要があるかどうかを決定するブール値です。 デフォルトは「True」です。

注意すべきことは、パスワードを「ランダム」または「R」に設定すると、ランダムなパスワードが生成され、それが「+ / var / log / cloud-init-output.log +」に書き込まれることです。 このファイルはシステム上のすべてのユーザーがアクセスできるため、これ以上安全ではないことに注意してください。

ファイルをディスクに書き込むには、 `+ write_files +`ディレクティブを使用する必要があります。

書き込まれる各ファイルは、ディレクティブの下のリスト項目によって表されます。 これらのリスト項目は、各ファイルのプロパティを定義する連想配列になります。

この配列に必要なキーは、ファイルを書き込む場所を定義する「+ path 」と、ファイルに含めるデータを含む「 content +」のみです。

`+ write_files +`アイテムを設定するために利用可能なキーは次のとおりです。

たとえば、次の内容でファイルを `+ / test.txt +`に書き込むことができます。

これを達成する `+ cloud-config +`の部分は次のようになります。

パッケージを管理するには、いくつかの関連する設定とディレクティブに留意する必要があります。

Debianベースのディストリビューションでaptデータベースを更新するには、 `+ package_update `ディレクティブを“ true”に設定する必要があります。 これは、コマンドラインから「 apt-get update」を呼び出すことと同義です。

デフォルト値は実際には「true」であるため、無効にする場合にのみこのディレクティブについて心配する必要があります。

サーバーの初回起動後にサーバー上のすべてのパッケージをアップグレードする場合、 `+ package_upgrade `ディレクティブを設定できます。 これは、手動で実行される ` apt-get upgrade +`に似ています。

これはデフォルトで「false」に設定されているため、機能が必要な場合は必ず「true」に設定してください。

追加のパッケージをインストールするには、「packages」ディレクティブを使用してパッケージ名をリストするだけです。 各リスト項目はパッケージを表す必要があります。 上記の2つのコマンドとは異なり、このディレクティブはyumまたはapt管理対象ディストリビューションで機能します。

これらのアイテムは、2つの形式のいずれかを取ることができます。 最初は、パッケージの名前を含む単純な文字列です。 2番目の形式は、2つの項目を持つリストです。 この新しいリストの最初の項目はパッケージ名であり、2番目の項目はバージョン番号です。

「packages」ディレクティブは `+ apt_update +`をtrueに設定し、以前の設定を上書きします。

SSHキーは `+ users `ディレクティブで管理できますが、専用の ` ssh_authorized_keys +`セクションで指定することもできます。 これらは、最初に定義されたユーザーのauthorized_keysファイルに追加されます。

これは、 `+ users +`ディレクティブ内のキー仕様と同じ一般的な形式を取ります。

SSHサーバーの秘密鍵を事前に生成して、ファイルシステムに配置することもできます。 これは、クライアントに事前にこのサーバーに関する情報を提供し、サーバーがオンラインになるとすぐにサーバーを信頼できるようにする場合に便利です。

これを行うには、 + ssh_keys +`ディレクティブを使用できます。 これは、 `+ rsa_private +、 + rsa_public +、 + dsa_private +、 + dsa_public +、 + ecdsa_private +、および `+ ecdsa_public +`サブアイテムを使用して、RSA、DSA、またはECDSAキーのキーペアを取得できます。

秘密鍵ではフォーマットと改行が重要であるため、これらを指定するときは必ずパイプキーを持つブロックを使用してください。 また、キーを有効にするには、開始キーと終了キーの行を含める必要があります。

インフラストラクチャが内部認証局によって署名されたキーに依存している場合、証明書情報を注入することにより、CA証明書を信頼するように新しいマシンをセットアップできます。 このために、 `+ ca-certs +`ディレクティブを使用します。

このディレクティブには2つのサブアイテムがあります。 1つ目は `+ remove-defaults +`で、trueに設定すると、デフォルトで含まれる通常の証明書信頼情報がすべて削除されます。 これは通常必要ではなく、何をしているのかわからない場合はいくつかの問題を引き起こす可能性があるため、注意して使用してください。

2番目の項目は「+ trusted +」であり、それぞれが信頼できるCA証明書を含むリストです：

使用する独自の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 `が提供する管理アクションのどれもがやりたいことに対して機能しない場合、任意のコマンドを実行することもできます。 これを行うには、 ` runcmd +`ディレクティブを使用します。

このディレクティブは、実行するアイテムのリストを取ります。 これらのアイテムは、2つの異なる方法で指定できます。これは、アイテムの処理方法に影響します。

リスト項目が単純な文字列である場合、項目全体が実行される `+ sh +`シェルプロセスに渡されます。

もう1つのオプションは、リストを渡すことです。リストの各項目は、 `+ execve +`がコマンドを処理する方法と同様の方法で実行されます。 最初の項目は実行するコマンドまたはスクリプトとして解釈され、次の項目はそのコマンドの引数として渡されます。

ほとんどのユーザーはこれらの形式のいずれかを使用できますが、柔軟性があるため、特別な要件がある場合は最適なオプションを選択できます。 出力はすべて標準出力と `+ / var / log / cloud-init-output.log +`ファイルに書き込まれます：

場合によっては、他の項目を実行した後にサーバーをシャットダウンまたは再起動する必要があります。 これを行うには、 `+ power_state +`ディレクティブを設定します。

このディレクティブには、設定可能な4つのサブアイテムがあります。 これらは、「+ delay」、「+ timeout」、「+ message」、および「+ mode +」です。

`+ delay `は、再起動またはシャットダウンがいつまで発生するかを指定します。 デフォルトでは、これは「今」になり、手順がすぐに開始されることを意味します。 遅延を追加するには、ユーザーは `+ <num_of_mins> +`形式を使用して経過する時間を分単位で指定する必要があります。

「+ timeout 」パラメーターは、「 delay +」カウントダウンを開始する前にcloud-initが完了するまで待機する秒数を表す単位なしの値を取ります。

`+ message `フィールドでは、システムのすべてのユーザーに送信されるメッセージを指定できます。 ` mode +`は、開始する電源イベントのタイプを指定します。 これは、サーバーをシャットダウンする「poweroff」、サーバーを再起動する「reboot」、またはシステムに最適なアクションを決定させる「halt」（通常はシャットダウン）です。

上記の例は、 `+ 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を使用して基本的なサーバー構成を完了する方法]はこちらです。