Cloud-Configスクリプティングの概要

投稿日: 2019-11-08 2022-10-11
タグ: API, DigitalOcean

序章

The cloud-init 最近のディストリビューションで利用可能なプログラム（この記事の執筆時点ではUbuntu14.04とCentOS7のみ）は、 user-data DigitalOceanメタデータサービスのフィールド。このプロセスは、検出した情報の形式に応じて動作が異なります。内のスクリプトで最も人気のある形式の1つ user-data cloud-configファイル形式です。

Cloud-configファイルは、cloud-initプロセスによって実行されるように設計された特別なスクリプトです。これらは通常、サーバーの最初の起動時の初期構成に使用されます。このガイドでは、cloud-configファイルの形式と使用法について説明します。

Cloud-Configに関する一般情報

The cloud-config formatは、多くの一般的な構成項目の宣言型構文を実装しているため、多くのタスクを簡単に実行できます。また、事前定義された宣言機能の範囲外の任意のコマンドを指定することもできます。

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

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 ファイル。これが通常のスクリプトファイルである場合、最初の行は、ファイルの実行に使用する必要があるインタープリターを示します。

上記のファイルには、2つのトップレベルのディレクティブがあります。 users と runcmd. これらは両方ともキーとして機能します。これらのキーの値は、キーの後のすべてのインデントされた行で構成されます。

の場合 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 ：「True」に設定して、 /home/<username> ユーザーのディレクトリ。
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つの連想配列キーが含まれています。 The list キーには、割り当てたいアカウント名と関連するパスワードを一覧表示するブロックが含まれます。 The expire keyは、最初の起動時にパスワードを変更する必要があるかどうかを決定するブール値です。これはデフォルトで「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 「真」への指示。これは呼び出しと同義です 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、DSA、またはECDSAキーのキーペアを使用して取得できます。 rsa_private, rsa_public, dsa_private, dsa_public, ecdsa_private、と 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つのサブアイテムがあります。最初は 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 アイテム。

The nameservers ディレクティブは、ネームサーバーのIPアドレスのリストを取得する必要があります。 The searchdomains ディレクティブは、ユーザーがドメインを指定せずにホストを指定した場合に検索するドメインとサブドメインのリストを取得します。

The 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.

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

The timeout パラメーターは、cloud-initが完了するのを待ってから開始するまでの秒数を表す単位なしの値を取ります。 delay 秒読み。

The message フィールドでは、システムのすべてのユーザーに送信されるメッセージを指定できます。 The 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を使用して基本的なサーバー構成を完了する方法に関するチュートリアルに従ってください。

getdocs

13036