序章
最近のディストリビューションで利用可能なcloud-init
プログラム(この記事の執筆時点ではUbuntu14.04とCentOS7のみ)は、DigitalOceanのuser-data
フィールドからのデータを消費および実行できます。メタデータサービス。 このプロセスは、検出した情報の形式に応じて動作が異なります。 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 user@desktop runcmd: - touch /test.txt
このファイルを見ることで、私たちは多くの重要なことを学ぶことができます。
まず、各cloud-config
ファイルは、最初の行で#cloud-config
のみで始まる必要があります。 これは、cloud-initプログラムに、これをcloud-config
ファイルとして解釈する必要があることを通知します。 これが通常のスクリプトファイルである場合、最初の行は、ファイルの実行に使用する必要があるインタープリターを示します。
上記のファイルには、users
とruncmd
の2つの最上位ディレクティブがあります。 これらは両方ともキーとして機能します。 これらのキーの値は、キーの後のすべてのインデントされた行で構成されます。
users
キーの場合、値は単一のリスト項目です。 これは、次のレベルのインデントがリスト項目を指定するダッシュ(-)であり、このインデントレベルにはダッシュが1つしかないためです。 users
ディレクティブの場合、これは偶然にも、単一のユーザーのみを定義していることを示しています。
リストアイテム自体には、より多くのキーと値のペアを持つ連想配列が含まれています。 これらはすべて同じレベルのインデントで存在するため、兄弟要素です。 各ユーザー属性は、上記で説明した単一のリスト項目に含まれています。
注意すべき点は、表示される文字列には引用符が不要であり、関連付けを定義するための不要な角かっこがないことです。 インタプリタはデータ型をかなり簡単に判別でき、インデントは人間とプログラムの両方のアイテムの関係を示します。
これで、YAML形式の実用的な知識が得られ、上記で説明したルールを使用して情報を快適に操作できるようになります。
これで、cloud-config
の最も一般的なディレクティブのいくつかを調べ始めることができます。
ユーザーとグループの管理
システムで新しいユーザーを定義するには、上記のサンプルファイルで見たusers
ディレクティブを使用できます。
ユーザー定義の一般的な形式は次のとおりです。
#cloud-config users: - first_user_parameter first_user_parameter - second_user_parameter second_user_parameter second_user_parameter second_user_parameter
新しいユーザーはそれぞれダッシュで始める必要があります。 各ユーザーは、キーと値のペアでパラメーターを定義します。 次のキーを定義に使用できます。
- name :アカウントのユーザー名。
- primary-group :ユーザーのプライマリグループ。 デフォルトでは、これはユーザー名に一致するように作成されたグループになります。 ここで指定するグループは、すでに存在するか、明示的に作成する必要があります(これについてはこのセクションの後半で説明します)。
- groups :任意の補足グループをコンマで区切ってここにリストできます。
- gecos :ユーザーに関する補足情報のフィールド。
- shell :ユーザーに設定する必要のあるシェル。 これを設定しない場合、非常に基本的な
sh
シェルが使用されます。 - Expiredate :アカウントの有効期限が切れる日付(YYYY-MM-DD形式)。
- sudo :ユーザー名フィールドなしでsudo権限を定義する場合に使用するsudo文字列。
- lock-passwd :これはデフォルトで「True」に設定されています。 これを「False」に設定すると、ユーザーはパスワードを使用してログインできます。
- passwd :アカウントのハッシュ化されたパスワード。
- ssh-authorized-keys :このユーザーの
.ssh
ディレクトリにあるauthorized_keys
ファイルに追加する必要がある完全なSSH公開キーのリスト。 - 非アクティブ:アカウントを非アクティブに設定するブール値。
- system :「True」の場合、このアカウントはホームディレクトリのないシステムアカウントになります。
- homedir :デフォルトの
/home/<username>
をオーバーライドするために使用されます。これは、別の方法で作成および設定されます。 - ssh-import-id :LaunchPadからインポートするSSHID。
- 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 user@desktop
グループを定義するには、groups
ディレクティブを使用する必要があります。 このディレクティブは、作成するグループのリストを取得するだけであるという点で、比較的単純です。
これに対するオプションの拡張は、作成しているグループのサブリストを作成することです。 この新しいリストは、このグループに配置する必要があるユーザーを定義します。
#cloud-config groups: - group1 - group2: [user1, user2]
既存ユーザーのパスワードを変更する
すでに存在するユーザーアカウント(root
アカウントが最も適切です)の場合、chpasswd
ディレクティブを使用してパスワードを指定できます。
注:このディレクティブは、デバッグ状況でのみを使用する必要があります。これも、サーバーの存続期間中、システム上のすべてのユーザーが値を使用できるためです。 このディレクティブで送信されるパスワードはプレーンテキストで指定する必要があるため、これはこのセクションでさらに関連性があります。
基本的な構文は次のようになります。
#cloud-config chpasswd: list: | user1:password1 user2:password2 user3:password3 expire: False
ディレクティブには、2つの連想配列キーが含まれています。 list
キーには、割り当てたいアカウント名と関連するパスワードを一覧表示するブロックが含まれます。 expire
キーは、最初の起動時にパスワードを変更する必要があるかどうかを決定するブール値です。 これはデフォルトで「True」になります。
注意すべき点の1つは、パスワードを「RANDOM」または「R」に設定できることです。これにより、ランダムなパスワードが生成され、/var/log/cloud-init-output.log
に書き込まれます。 このファイルはシステム上のすべてのユーザーがアクセスできるため、これ以上安全ではないことに注意してください。
ディスクにファイルを書き込む
ディスクにファイルを書き込むには、write_files
ディレクティブを使用する必要があります。
書き込む必要のある各ファイルは、ディレクティブの下のリスト項目で表されます。 これらのリスト項目は、各ファイルのプロパティを定義する連想配列になります。
この配列に必要なキーは、ファイルの書き込み先を定義するpath
と、ファイルに含めるデータを含むcontent
のみです。
write_files
アイテムを構成するために使用できるキーは次のとおりです。
- path :ファイルが書き込まれるファイルシステム上の場所への絶対パス。
- content :ファイルに配置する必要のあるコンテンツ。 複数行の入力の場合、「コンテンツ」行でパイプ文字(|)を使用してブロックを開始し、その後にコンテンツを含むインデントされたブロックを続ける必要があります。 バイナリファイルには、「!!binary」とパイプ文字の前のスペースを含める必要があります。
- owner :ファイルの所有権を付与する必要があるユーザーアカウントとグループ。 これらは「username:group」形式で指定する必要があります。
- permits :このファイルに指定する必要がある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つの形式のいずれかを取ることができます。 1つ目は、パッケージの名前が付いた単純な文字列です。 2番目の形式は、2つの項目を含むリストです。 この新しいリストの最初の項目はパッケージ名であり、2番目の項目はバージョン番号です。
#cloud-config packages: - package_1 - package_2 - [package_3, version_num]
「packages」ディレクティブはapt_update
をtrueに設定し、以前の設定をオーバーライドします。
ユーザーアカウントとSSHデーモンのSSHキーを構成する
SSHキーはusers
ディレクティブで管理できますが、専用のssh_authorized_keys
セクションで指定することもできます。 これらは、最初に定義されたユーザーのauthorized_keysファイルに追加されます。
これは、users
ディレクティブ内のキー仕様と同じ一般的な形式を取ります。
#cloud-config ssh_authorized_keys: - ssh_key_1 - ssh_key_2
SSHサーバーの秘密鍵を事前に生成して、ファイルシステムに配置することもできます。 これは、クライアントにこのサーバーに関する情報を事前に提供して、サーバーがオンラインになるとすぐにサーバーを信頼できるようにする場合に役立ちます。
これを行うには、ssh_keys
ディレクティブを使用できます。 これは、rsa_private
、rsa_public
、dsa_private
、dsa_public
、ecdsa_private
を使用して、RSA、DSA、またはECDSAキーのキーペアを取得できます。 、およびecdsa_public
サブアイテム。
秘密鍵では書式設定と改行が重要であるため、これらを指定するときは必ずパイプ鍵付きのブロックを使用してください。 また、キーを有効にするには、開始キーと終了キーの行を含める必要があります。
#cloud-config ssh_keys: rsa_private: | -----BEGIN RSA PRIVATE KEY----- your_rsa_private_key -----END RSA PRIVATE KEY----- rsa_public: your_rsa_public_key
信頼できるCA証明書を設定する
インフラストラクチャが内部認証局によって署名されたキーに依存している場合は、証明書情報を挿入することで、CA証明書を信頼するように新しいマシンを設定できます。 このために、ca-certs
ディレクティブを使用します。
このディレクティブには2つのサブアイテムがあります。 1つ目はremove-defaults
で、trueに設定すると、デフォルトで含まれている通常の証明書の信頼情報がすべて削除されます。 これは通常は必要ありません。何をしているのかわからない場合は問題が発生する可能性があるため、注意して使用してください。
2番目の項目はtrusted
です。これはリストであり、それぞれに信頼できるCA証明書が含まれています。
#cloud-config ca-certs: remove-defaults: true trusted: - | -----BEGIN CERTIFICATE----- your_CA_cert -----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: - 'first_nameserver' - 'second_nameserver' searchdomains: - first.domain.com - second.domain.com domain: domain.com options: option1: value1 option2: value2 option3: value3
より詳細な制御のために任意のコマンドを実行する
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
は、開始する電源イベントのタイプを指定します。 これは、サーバーをシャットダウンするための「電源オフ」、サーバーを再起動するための「再起動」、またはシステムに最適なアクション(通常はシャットダウン)を決定させるための「停止」の場合があります。
#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
ファイルに慣れるための実用的なガイドについては、cloud-configを使用して基本的なサーバー構成を完了する方法に関するチュートリアルに従ってください。