RHEL 8 の cloud-init の設定と管理
Red Hat Enterprise Linux クラウドインスタンスの自動初期化
概要
- cloud-init の仕組み
- cloud-init を使用してクラウドインスタンスを開始する方法
- Red Hat がサポートする cloud-init の用途
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
- Jira の Web サイトにログインします。
- 上部のナビゲーションバーで Create をクリックします。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- ダイアログの下部にある Create をクリックします。
第1章 パブリッククラウドプラットフォームでの RHEL の導入 リンクのコピーリンクがクリップボードにコピーされました!
パブリッククラウドプラットフォームは、コンピューティングリソースをサービスとして提供します。オンプレミスのハードウェアを使用する代わりに、Red Hat Enterprise Linux (RHEL) システムなどの IT ワークロードをパブリッククラウドインスタンスとして実行できます。
パブリッククラウドプラットフォーム上の RHEL の詳細は、以下を参照してください。
1.1. パブリッククラウドで RHEL を使用する利点 リンクのコピーリンクがクリップボードにコピーされました!
パブリッククラウドプラットフォーム上に配置されたクラウドインスタンスとしての RHEL には、RHEL オンプレミスの物理システムまたは仮想マシン (VM) に比べて次の利点があります。
リソースの柔軟性と詳細な割り当て
RHEL のクラウドインスタンスは、クラウドプラットフォーム上の仮想マシンとして実行されます。この仮想マシンは通常、クラウドサービスのプロバイダーによって維持管理されるリモートサーバーのクラスターです。したがって、特定のタイプの CPU やストレージなどのハードウェアリソースのインスタンスへの割り当ては、ソフトウェアレベルで行われ、簡単にカスタマイズできます。
また、ローカルの RHEL システムと比較すると、物理ホストの機能によって制限されることがありません。むしろ、クラウドプロバイダーが提供する選択肢に基づいて、さまざまな機能から選択できます。
領域とコスト効率
クラウドワークロードをホストするためにオンプレミスサーバーを所有する必要がありません。これにより、物理ハードウェアに関連するスペース、電力、メンテナンスの要件が回避されます。
代わりに、パブリッククラウドプラットフォームでは、クラウドインスタンスの使用料をクラウドプロバイダーに直接支払います。通常、コストはインスタンスに割り当てられたハードウェアとその使用時間に基づきます。したがって、要件に基づいてコストを最適化できます。
ソフトウェアで制御される設定
クラウドインスタンスの設定全体がクラウドプラットフォーム上にデータとして保存され、ソフトウェアによって制御されます。したがって、インスタンスの作成、削除、クローン作成、または移行を簡単に行うことができます。また、クラウドインスタンスは、クラウドプロバイダーのコンソールでリモートで操作され、デフォルトでリモートストレージに接続されます。
さらに、クラウドインスタンスの現在の状態をいつでもスナップショットとしてバックアップできます。その後、スナップショットをロードしてインスタンスを保存した状態に復元できます。
ホストからの分離とソフトウェアの互換性
ローカルの仮想マシンと同様に、クラウドインスタンス上の RHEL ゲストオペレーティングシステムは仮想化されたカーネル上で実行されます。このカーネルは、ホストオペレーティングシステムや、インスタンスへの接続に使用する クライアント システムとは別のものです。
したがって、任意のオペレーティングシステムをクラウドインスタンスにインストールできます。つまり、RHEL パブリッククラウドインスタンスでは、ローカルオペレーティングシステムでは使用できない RHEL 固有のアプリケーションを実行できます。
さらに、インスタンスのオペレーティングシステムが不安定になったり侵害されたりした場合でも、クライアントシステムには一切影響がありません。
1.2. RHEL のパブリッククラウドのユースケース リンクのコピーリンクがクリップボードにコピーされました!
パブリッククラウドへのデプロイには多くの利点がありますが、すべてのシナリオにおいて最も効率的なソリューションであるとは限りません。RHEL デプロイメントをパブリッククラウドに移行するかどうかを評価している場合は、ユースケースがパブリッククラウドの利点を享受できるかどうかを検討してください。
有益なユースケース
パブリッククラウドインスタンスのデプロイは、デプロイメントのアクティブなコンピューティング能力を柔軟に増減する (スケールアップ および スケールダウン とも呼ばれます) 場合に非常に効果的です。したがって、次のシナリオではパブリッククラウドで RHEL を使用することを推奨します。
- ピーク時のワークロードが高く、一般的なパフォーマンス要件が低いクラスター。要求に応じてスケールアップおよびスケールダウンすることで、リソースコストの面で高い効率が得られる場合があります。
- クラスターを迅速にセットアップまたは拡張できます。これにより、ローカルサーバーのセットアップにかかる高額な初期費用が回避されます。
- クラウドインスタンスは、ローカル環境で何が起こっても影響を受けません。したがって、バックアップや障害復旧に使用できます。
問題が発生する可能性のあるユースケース
- 調整不可能な既存の環境を運用している場合。既存のデプロイメントの特定のニーズに合わせてクラウドインスタンスをカスタマイズすることは、現在のホストプラットフォームと比較して費用対効果が低い可能性があります。
- 厳しい予算制限の中で運用している場合。通常、ローカルデータセンターでデプロイメントを維持管理すると、パブリッククラウドよりも柔軟性は低くなりますが、最大リソースコストをより細かく制御できます。
次のステップ
1.3. パブリッククラウドへの移行時によくある懸念事項 リンクのコピーリンクがクリップボードにコピーされました!
RHEL ワークロードをローカル環境からパブリッククラウドプラットフォームに移行すると、それに伴う変更について懸念が生じる可能性があります。よくある質問は次のとおりです。
RHEL は、クラウドインスタンスとして動作する場合、ローカル仮想マシンとして動作する場合とは異なる動作になりますか?
パブリッククラウドプラットフォーム上の RHEL インスタンスは、ほとんどの点で、オンプレミスサーバーなどのローカルホスト上の RHEL 仮想マシンと同じように機能します。注目すべき例外には次のようなものがあります。
- パブリッククラウドインスタンスは、プライベートオーケストレーションインターフェイスの代わりに、プロバイダー固有のコンソールインターフェイスを使用してクラウドリソースを管理します。
- ネストされた仮想化などの特定の機能が正しく動作しない可能性があります。特定の機能がデプロイメントにとって重要な場合は、選択したパブリッククラウドプロバイダーとその機能の互換性を事前に確認してください。
ローカルサーバーと比べて、パブリッククラウドではデータは安全に保たれますか?
RHEL クラウドインスタンス内のデータの所有権はユーザーにあり、パブリッククラウドプロバイダーはデータにアクセスできません。さらに、主要なクラウドプロバイダーは転送中のデータ暗号化をサポートしているため、仮想マシンをパブリッククラウドに移行する際のデータのセキュリティーが向上します。
RHEL パブリッククラウドインスタンスの一般的なセキュリティーは次のように管理されます。
- パブリッククラウドプロバイダーは、クラウドハイパーバイザーのセキュリティーを担当します。
- Red Hat は、RHEL ゲストオペレーティングシステムのセキュリティー機能をインスタンスに提供します。
- ユーザーは、クラウドインフラストラクチャーにおける特定のセキュリティー設定とプラクティスを管理します。
ユーザーの地理的リージョンは、RHEL パブリッククラウドインスタンスの機能にどのように影響しますか?
RHEL インスタンスは、地理的な場所に関係なく、パブリッククラウドプラットフォームで使用できます。したがって、オンプレミスサーバーと同じリージョンでインスタンスを実行できます。
ただし、物理的に離れたリージョンでインスタンスをホストすると、操作時に待ち時間が長くなる可能性があります。さらに、パブリッククラウドプロバイダーによっては、特定のリージョンで、追加機能が提供される場合や、より高いコスト効率が得られる場合があります。RHEL インスタンスを作成する前に、選択したクラウドプロバイダーで利用可能なホスティングリージョンのプロパティーを確認してください。
1.4. パブリッククラウドデプロイメント用の RHEL の入手 リンクのコピーリンクがクリップボードにコピーされました!
RHEL システムをパブリッククラウド環境にデプロイするには、次の手順を実行します。
要件と市場の現在のオファーに基づいて、ユースケースに最適なクラウドプロバイダーを選択します。
現在、RHEL インスタンスの実行が認定されているクラウドプロバイダーは次のとおりです。
- 詳細は、Deploying RHEL 9 on Amazon Web Services を参照してください。
- 詳細は、Deploying RHEL 9 on Google Cloud Platform を参照してください。
- 詳細は、Deploying RHEL 9 on Microsoft Azure を参照してください。
- 選択したクラウドプラットフォーム上に RHEL クラウドインスタンスを作成します。詳細は、RHEL クラウドインスタンスを作成する方法 を参照してください。
- RHEL デプロイメントを最新の状態に保つには、Red Hat Update Infrastructure (RHUI) を使用します。
1.5. RHEL クラウドインスタンスを作成する方法 リンクのコピーリンクがクリップボードにコピーされました!
RHEL インスタンスをパブリッククラウドプラットフォームにデプロイするには、次のいずれかの方法を使用できます。
| RHEL のシステムイメージを作成し、クラウドプラットフォームにインポートします。
|
| RHEL インスタンスをクラウドプロバイダーマーケットプレイスから直接購入します。
|
第2章 cloud-init の概要 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init ユーティリティーは、システムの起動時にクラウドインスタンスの初期化を自動化します。cloud-init は、さまざまなタスクを実行するように設定できます。
- ホスト名の設定
- インスタンスへのパッケージのインストール
- スクリプトの実行
- デフォルトの仮想マシン (VM) 動作の抑制
前提条件
- Red Hat カスタマーポータル のアカウントに登録している。
cloud-init は、さまざまなタイプの RHEL イメージで利用できます。以下に例を示します。
-
Red Hat カスタマーポータル から KVM ゲストイメージをダウンロードすると、イメージが
cloud-initパッケージで事前にインストールされます。インスタンスを起動すると、cloud-initパッケージが有効になります。Red Hat カスタマーポータルの KVM ゲストイメージは、Red Hat Virtualization (RHV)、Red Hat OpenStack Platform (RHOSP)、および Red Hat OpenShift Virtualization で使用することを目的としています。 -
Red Hat カスタマーポータルから RHEL ISO イメージをダウンロードして、カスタムゲストイメージを作成することもできます。この場合は、カスタマイズしたゲストイメージに
cloud-initパッケージをインストールする必要があります。 クラウドサービスプロバイダー(AWS または Azure など)からのイメージを使用する必要がある場合は、RHEL イメージビルダーを使用してイメージ を作成します。Image Builder イメージは、特定のクラウドプロバイダー向けにカスタマイズされます。次のイメージタイプには、
cloud-initがすでにインストールされているものがあります。- Amazon Machine Image (AMI)
- 仮想ハードディスク(VHD)
QEMU copy-on-write (qcow2)
RHEL Image Builder の詳細は RHEL システムイメージのカスタマイズ を 参照してください。
ほとんどのクラウドプラットフォームは cloud-init をサポートしますが、設定手順とサポートされるオプションは異なります。また、NoCloud 環境向けに cloud-init を設定できます。
さらに、1 つの仮想マシンで cloud-init を設定し、その仮想マシンをテンプレートとして使用し、追加の仮想マシンまたは仮想マシンクラスターを作成できます。
Red Hat Virtualization などの特定の Red Hat 製品では、これらの製品の cloud-init を設定する手順が文書化されています。
2.1. cloud-init 設定の概要 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init ユーティリティーは、YAML 形式の設定ファイルを使用してユーザー定義のタスクをインスタンスに適用します。インスタンスが起動すると、cloud-init サービスが起動して、YAML ファイルからの指示を実行します。設定によっては、タスクは最初の起動時または仮想マシンの後続の起動時に完了します。
特定のタスクを定義するには、/etc/cloud/cloud.cfg ファイルを設定し、/etc/cloud/cloud.cfg.d/ ディレクトリーの下にディレクティブを追加します。
cloud.cfgファイルには、ユーザーアクセス、認証、システム情報など、さまざまなシステム設定のディレクティブが含まれます。ファイルには、
cloud-initのデフォルトおよびオプションのモジュールも含まれています。これらのモジュールは、のフェーズで順番に実行されます。cloud-init初期化フェーズ ..設定フェーズ ..最終フェーズ。+
cloud.cfgファイルでは、3 つのフェーズのモジュールがcloud_init_modules、cloud_config_modules、およびcloud_final_modulesの下にそれぞれ一覧表示されます。-
cloud.cfg.dディレクトリーに、cloud-initのディレクティブを追加できます。cloud.cfg.dディレクトリーにディレクティブを追加する場合は、それらを*.cfgという名前のカスタムファイルに追加し、ファイルの先頭に常に#cloud-configを含める必要があります。
2.2. cloud-init はステージごとに動作する リンクのコピーリンクがクリップボードにコピーされました!
システムの起動時に、cloud-init ユーティリティーは 5 つの段階で動作し、その他のタスクの中で cloud-init が実行されるかどうか、データソースを見つける場所を決定します。ステージは次のとおりです。
-
ジェネレーターステージ:
systemdサービスを使用することで、このフェーズは、起動時にcloud-initユーティリティーを実行するかどうかを決定します。 -
ローカルステージ:
cloud-initはローカルデータソースを検索し、DHCP ベースのフォールバックメカニズムを含むネットワーク設定を適用します。 -
ネットワークステージ:
cloud-initは、/etc/cloud/cloud.cfgファイルのcloud_init_modulesの下にリストされているモジュールを実行してユーザーデータを処理します。cloud_init_modulesセクションで、モジュールを追加、削除、有効化、または無効化できます。 -
Config stage:
cloud-initは、/etc/cloud/cloud.cfgファイルのcloud_config_modulesセクションに一覧表示されているモジュールを実行します。cloud_config_modulesセクションでモジュールを追加、削除、有効化、または無効にできます。 -
最終ステージ:
cloud-initは、/etc/cloud/cloud.cfgファイルのcloud_final_modulesセクションに含まれるモジュールおよび設定を実行します。これには、特定のパッケージのインストールや、設定管理プラグインおよびユーザー定義のスクリプトのトリガーが含まれます。cloud_final_modulesセクションでモジュールを追加、削除、有効化、または無効にできます。
2.3. cloud-init モジュールはフェーズごとに実行される リンクのコピーリンクがクリップボードにコピーされました!
cloud-init を実行すると、cloud.cfg 内のモジュールが次の 3 つのフェーズで順番に実行されます。
-
ネットワークフェーズ (
cloud_init_modules) -
設定フェーズ (
cloud_config_modules) -
最終フェーズ (
cloud_final_modules)
仮想マシンで cloud-init が初めて実行されると、設定したすべてのモジュールがそれぞれのフェーズで実行されます。cloud-init の後続の実行では、モジュールがフェーズ内で実行されるかどうかは、個々のモジュールの モジュール頻度 により異なります。cloud-init が実行されるたびに実行されるモジュールもあれば、インスタンス ID が変更された場合でも、cloud-init の初回実行時にしか実行されないモジュールもあります。
インスタンス ID はインスタンスを一意に識別します。インスタンス ID が変更されると、cloud-init はそのインスタンスを新しいインスタンスとして処理します。
可能な モジュール周波数 の値は次のとおりです。
-
Per instanceとは、モジュールがインスタンスの初回起動時に実行されることを意味します。たとえば、インスタンスのクローンを作成したり、保存したイメージから新しいインスタンスを作成したりすると、インスタンス別と指定されたモジュールは再度実行されます。 -
Per onceとは、モジュールが 1 回だけ実行されることを意味します。たとえば、インスタンスのクローンを作成したり、保存したイメージから新しいインスタンスを作成したりすると、1 回と指定されたモジュールは、それらのインスタンスでは再度実行されません。 -
Per alwaysとは、モジュールが起動ごとに実行されることを意味します。
モジュールの設定時またはコマンドラインを使用して、モジュールの頻度を上書きできます。
2.4. cloud-init は、ユーザーデータ、メタデータ、およびベンダーデータに対応する リンクのコピーリンクがクリップボードにコピーされました!
cloud-init は、ユーザーデータ、メタデータ、ベンダーデータを消費し、これらに対応します。
-
ユーザーデータには、
cloud.cfgファイルとcloud.cfg.dディレクトリーで指定するディレクティブが含まれます。たとえば、ユーザーデータには、実行するファイル、インストールするパッケージ、およびシェルスクリプトを含むことができます。cloud-initが許可するユーザーデータのタイプに関する詳細は、cloud-initドキュメントの User-Data Formats セクションを参照してください。 -
メタデータには、特定のデータソースに関連付けられたデータが含まれます。たとえば、メタデータにはサーバー名とインスタンス ID を含むことができます。特定のクラウドプラットフォームを使用している場合、インスタンスがユーザーデータとメタデータを見つける場所をプラットフォームが決定します。プラットフォームでは、メタデータとユーザーデータの HTTP サービスへの追加が必要な場合があります。この場合、
cloud-initを実行すると、HTTP サービスからメタデータとユーザーデータが消費されます。 ベンダーデータは、組織 (クラウドプロバイダーなど) がオプションで提供し、イメージが実行される環境に合わせてイメージをカスタマイズできる情報が含まれます。
cloud-initは、メタデータを読み込んでシステムを初期化した後に、オプションのベンダーデータおよびユーザーデータに対応します。デフォルトでは、ベンダーデータは初回起動時に実行されます。ベンダーデータの実行を無効にすることができます。メタデータの説明は
cloud-initドキュメントの Instance Metadata セクション、データソースのリストは Datasources、ベンダーデータの詳細は Vendor Data を参照してください。
2.5. cloud-init はクラウドプラットフォームを識別する リンクのコピーリンクがクリップボードにコピーされました!
cloud-init は、ds-identify スクリプトを使用してクラウドプラットフォームの特定を試みます。スクリプトは、インスタンスの初回起動時に実行されます。
データソースディレクティブを追加すると、cloud-init の実行時に時間を節約できます。ディレクティブは、/etc/cloud/cloud.cfg ファイルまたは /etc/cloud/cloud.cfg.d ディレクトリーに追加します。以下に例を示します。
datasource_list:[Ec2]
クラウドプラットフォームのディレクティブを追加すること以外に、メタデータ URL などの追加の設定詳細を追加して cloud-init をさらに設定できます。
datasource_list: [Ec2]
datasource:
Ec2:
metadata_urls: ['http://169.254.169.254']
cloud-init の実行後に、プラットフォームに関する詳細情報を提供するログファイル (run/cloud-init/ds-identify.log) を表示できます。
第3章 cloud-init の Red Hat サポート リンクのコピーリンクがクリップボードにコピーされました!
本章では、cloud-init の Red Hat サポートについて説明します。これには、cloud-init を使用する Red Hat 製品、Red Hat がサポートする cloud-init モジュール、デフォルトのディレクトリーおよびファイルに関する情報が含まれます。
3.1. cloud-init の重要なディレクトリーおよびファイル リンクのコピーリンクがクリップボードにコピーされました!
以下の表には、重要なディレクトリーおよびファイルが記載されています。これらのディレクトリーおよびファイルを確認します。これらにより、以下のようなタスクを実行することができます。
-
cloud-initの設定 -
cloud-init実行後の設定に関する情報の検索 - ログファイルの検証
- テンプレートの検索
シナリオおよびデータソースに応じて、お使いの設定にとって重要な追加のファイルとディレクトリーが存在する場合があります。
| ディレクトリーまたはファイル | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このディレクトリーには、特定のシナリオの |
|
|
|
|
|
|
3.2. cloud-init を使用する Red Hat 製品 リンクのコピーリンクがクリップボードにコピーされました!
以下の Red Hat 製品で cloud-init を使用できます。
-
Red Hat Virtualization.
cloud-initを仮想マシンにインストールすると、テンプレートを作成し、そのテンプレートから作成したすべての仮想マシンにcloud-init機能を利用できます。仮想マシンでのcloud-initの使用に関する詳細は、Cloud-Init を使用した仮想マシンの設定の自動化 を参照してください。 -
Red Hat OpenStack Platform.
cloud-initを使用して、OpenStack のイメージの設定をサポートできます。詳細は、インスタンスおよびイメージガイド を参照してください。 -
Red Hat Satellite.
cloud-initを Red Hat Satellite で使用することができます。詳細は、Preparing Cloud-init Images in Red Hat Virtualization を参照してください。 -
Red Hat OpenShift.OpenShift 用の仮想マシンを作成する際に
cloud-initを使用できます。詳細は、Creating virtual machines を参照してください。
3.3. Red Hat はこれらの cloud-init モジュールをサポートします。 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、ほとんどの cloud-init モジュールをサポートしています。個々のモジュールには、複数の設定オプションを含めることができます。以下の表は、Red Hat が現在サポートしているすべての cloud-init モジュールのリストで、簡単な説明とデフォルトのモジュール頻度を記載しています。これらのモジュールの完全な説明およびオプションは、cloud-init ドキュメントの Modules セクションを参照してください。
| cloud-init モジュール | 説明 | デフォルトのモジュール頻度 |
|---|---|---|
| bootcmd | ブートプロセスの初期段階でコマンドを実行します。 | 常時 |
| ca_certs | CA 証明書を追加します。 | インスタンス別 |
| debug | デバッグを支援するために内部情報の出力を有効または無効にします。 | インスタンス別 |
| disable_ec2_metadata | AWS EC2 メタデータを有効または無効にします。 | 常時 |
| disk_setup | シンプルなパーティションテーブルとファイルシステムを設定します。 | インスタンス別 |
| final_message |
| 常時 |
| foo | モジュール構造の例 (モジュールは何もしません)。 | インスタンス別 |
| growpart | パーティションのサイズを変更して、利用可能なディスク領域を埋めます。 | 常時 |
| keys_to_console | コンソールに書き込むことができるフィンガープリントとキーの制御を許可します。 | インスタンス別 |
| landscape | ランドスケープクライアントをインストールおよび設定します。 | インスタンス別 |
| locale | システムロケールを設定し、システム全体に適用します。 | インスタンス別 |
| mcollective |
| インスタンス別 |
| migrator |
| 常時 |
| mounts | マウントポイントとスワップファイルを設定します。 | インスタンス別 |
| phone_home | 起動完了後にリモートホストにデータを投稿します。 | インスタンス別 |
| power_state_change | すべての設定モジュールの実行後にシャットダウンを完了し、再起動します。 | インスタンス別 |
| puppet | puppet をインストールおよび設定します。 | インスタンス別 |
| resizefs | ファイルシステムのサイズを変更し、パーティションで利用可能な領域をすべて使用します。 | 常時 |
| resolv_conf |
| インスタンス別 |
| rh_subscription | Red Hat Enterprise Linux システムを登録します。 | インスタンス別 |
| rightscale_userdata |
| インスタンス別 |
| rsyslog |
| インスタンス別 |
| runcmd | 任意のコマンドを実行します。 | インスタンス別 |
| salt_minion |
| インスタンス別 |
| scripts_per_boot | 起動スクリプトごとに実行します。 | 常時 |
| scripts_per_instance | インスタンススクリプトごとに実行します。 | インスタンス別 |
| scripts_per_once | スクリプトを 1 回実行します。 | 1 回 |
| scripts_user | ユーザースクリプトを実行します。 | インスタンス別 |
| scripts_vendor | ベンダースクリプトを実行します。 | インスタンス別 |
| seed_random | ランダムなシードデータを提供します。 | インスタンス別 |
| set_hostname | ホスト名および完全修飾ドメイン名 (FQDN) を設定します。 | 常時 |
| set_passwords | ユーザーパスワードを設定し、SSH パスワード認証を有効または無効にします。 | インスタンス別 |
| ssh_authkey_fingerprints | ユーザーの SSH 鍵のフィンガープリントをログに記録します。 | インスタンス別 |
| ssh_import_id | SSH 鍵をインポートします。 | インスタンス別 |
| ssh | SSH、ホスト、および認可された SSH 鍵を設定します。 | インスタンス別 |
| timezone | システムのタイムゾーンを設定します。 | インスタンス別 |
| update_etc_hosts |
| 常時 |
| update_hostname | ホスト名および FQDN を更新します。 | 常時 |
| users_groups | ユーザーおよびグループを設定します。 | インスタンス別 |
| write_files | 任意のファイルを書き込みます。 | インスタンス別 |
| yum_add_repo | yum リポジトリー設定をシステムに追加します。 | 常時 |
以下の表は、現在 Red Hat がサポートしていないモジュールをリスト表示しています。
| モジュール |
|---|
| apt_configure |
| apt_pipeline |
| byobu |
| chef |
| emit_upstart |
| grub_dpkg |
| ubuntu_init_switch |
3.4. デフォルトの cloud.cfg ファイル リンクのコピーリンクがクリップボードにコピーされました!
/etc/cloud/cloud.cfg ファイルは、cloud-init の基本設定を設定するモジュールをリスト表示します。
ファイルのモジュールは、cloud-init のデフォルトのモジュールです。お使いの環境にモジュールを設定したり、不要なモジュールを削除したりすることができます。cloud.cfg に含まれるモジュールは、ファイルにリスト表示されているだけで、必ずしもなんでも実行する訳ではありません。cloud-init フェーズのいずれかでアクションを実行する必要がある場合は、それらを個別に設定する必要があります。
cloud.cfg ファイルは、個別のモジュールを実行するための時系列を提供します。Red Hat が追加するモジュールをサポートする限り、追加のモジュールを cloud.cfg に追加できます。
Red Hat Enterprise Linux (RHEL) のファイルのデフォルトコンテンツは、以下のとおりです。
-
モジュールは、
cloud.cfgで指定された順序で実行されます。通常、この順序は変更しません。 -
cloud.cfgディレクティブは、ユーザーデータによって上書きされることができます。 -
cloud-initを手動で実行する場合は、コマンドラインオプションでcloud.cfgを上書きできます。 - 各モジュールには独自の設定オプションが含まれており、この設定オプションに特定の情報を追加することができます。
users:
- default
disable_root: 1
ssh_pwauth: 0
mount_default_fields: [~, ~, 'auto', 'defaults,nofail,x-systemd.requires=cloud-init.service', '0', '2']
ssh_deletekeys: 1
ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519']
syslog_fix_perms: ~
disable_vmware_customization: false
cloud_init_modules:
- disk_setup
- migrator
- bootcmd
- write-files
- growpart
- resizefs
- set_hostname
- update_hostname
- update_etc_hosts
- rsyslog
- users-groups
- ssh
cloud_config_modules:
- mounts
- locale
- set-passwords
- rh_subscription
- yum-add-repo
- package-update-upgrade-install
- timezone
- puppet
- chef
- salt-minion
- mcollective
- disable-ec2-metadata
- runcmd
cloud_final_modules:
- rightscale_userdata
- scripts-per-once
- scripts-per-boot
- scripts-per-instance
- scripts-user
- ssh-authkey-fingerprints
- keys-to-console
- phone-home
- final-message
- power-state-change
system_info:
default_user:
name: cloud-user
lock_passwd: true
gecos: Cloud User
groups: [adm, systemd-journal]
sudo: ["ALL=(ALL) NOPASSWD:ALL"]
shell: /bin/bash
distro: rhel
paths:
cloud_dir: /var/lib/cloud
templates_dir: /etc/cloud/templates
ssh_svcname: sshd
# vim:syntax=yaml
- 1
- システムのデフォルトユーザーを指定します。詳細は、Users and Groups を参照してください。
- 2
- root ログインを有効または無効にします。詳細は、Authorized Keys を参照してください。
- 3
sshがパスワード認証を受け入れるよう設定されているかどうかを指定します。詳細は、Set Passwords を参照してください。- 4
- マウントポイントを設定します。6 つの値を含むリストでなければなりません。詳細は、Mounts を参照してください。
- 5
- デフォルトのホスト SSH 鍵を削除するかどうかを指定します。詳細は、Host Keys を参照してください。
- 6
- 生成する鍵のタイプを指定します。詳細は、Host Keys を参照してください。RHEL 8.4 以前の場合、この行のデフォルト値は
~であることに注意してください。 - 7
cloud-initは、起動時に複数のステージで実行されます。cloud-initが、すべてのステージをログファイルにログ記録できるように、このオプションを設定します。このオプションの詳細は、usr/share/doc/cloud-init/examplesディレクトリーのcloud-config.txtファイルを参照してください。- 8
- VMware vSphere のカスタマイズを有効または無効にします。
- 9
- 本セクションのモジュールは、起動プロセスの初期段階における
cloud-initサービスの起動時に実行されるサービスです。 - 10
- これらのモジュールは、初回起動後の
cloud-init設定時に実行されます。 - 11
- これらのモジュールは、設定完了後に
cloud-initの最終フェーズで実行されます。 - 12
- デフォルトユーザーの詳細を指定します。詳細は、Users and Groups を参照してください。
- 13
- ディストリビューションを指定します。
- 14
cloud-init固有のサブディレクトリーが含まれるメインディレクトリーを指定します。詳細は、Directory layout を参照してください。- 15
- テンプレートの場所を指定します。
- 16
- SSH サービスの名前
3.5. cloud.cfg.d ディレクトリー リンクのコピーリンクがクリップボードにコピーされました!
cloud-init は、ユーザーが提供および設定するディレクティブに対応します。通常、これらのディレクティブは cloud.cfg.d ディレクトリーに含まれています。
cloud.cfg ファイル内でユーザーデータディレクティブを追加することでモジュールを設定できますが、cloud.cfg を未変更のままにすること (ベストプラクティス) をご検討ください。ディレクティブを /etc/cloud/cloud.cfg.d ディレクトリーに追加します。このディレクトリーにディレクティブを追加することで、今後の変更およびアップグレードを容易にすることができます。
ディレクティブを追加する方法は複数あります。ディレクティブは、見出し #cloud-config を含む *.cfg という名前のファイルに追加できます。通常、ディレクトリーには複数の *cfg ファイルが含まれます。ディレクティブを追加するオプションは他にもあります。たとえば、ユーザーデータスクリプトを追加できます。詳細は、User-Data Formats を参照してください。
3.6. デフォルトの 05_logging.cfg ファイル リンクのコピーリンクがクリップボードにコピーされました!
05_logging.cfg ファイルは、cloud-init のログ情報を設定します。/etc/cloud/cloud.cfg.d ディレクトリーには、追加する他の cloud-init ディレクティブと共にこのファイルが含まれます。
cloud-init は、デフォルトで 05_logging.cfg のロギング設定を使用します。Red Hat Enterprise Linux (RHEL) のファイルのデフォルトコンテンツは、以下のとおりです。
## This yaml formatted config file handles setting
## logger information. The values that are necessary to be set
## are seen at the bottom. The top '_log' are only used to remove
## redundancy in a syslog and fallback-to-file case.
##
## The 'log_cfgs' entry defines a list of logger configs
## Each entry in the list is tried, and the first one that
## works is used. If a log_cfg list entry is an array, it will
## be joined with '\n'.
_log:
- &log_base |
[loggers]
keys=root,cloudinit
[handlers]
keys=consoleHandler,cloudLogHandler
[formatters]
keys=simpleFormatter,arg0Formatter
[logger_root]
level=DEBUG
handlers=consoleHandler,cloudLogHandler
[logger_cloudinit]
level=DEBUG
qualname=cloudinit
handlers=
propagate=1
[handler_consoleHandler]
class=StreamHandler
level=WARNING
formatter=arg0Formatter
args=(sys.stderr,)
[formatter_arg0Formatter]
format=%(asctime)s - %(filename)s[%(levelname)s]: %(message)s
[formatter_simpleFormatter]
format=[CLOUDINIT] %(filename)s[%(levelname)s]: %(message)s
- &log_file |
[handler_cloudLogHandler]
class=FileHandler
level=DEBUG
formatter=arg0Formatter
args=('/var/log/cloud-init.log',)
- &log_syslog |
[handler_cloudLogHandler]
class=handlers.SysLogHandler
level=DEBUG
formatter=simpleFormatter
args=("/dev/log", handlers.SysLogHandler.LOG_USER)
log_cfgs:
# Array entries in this list will be joined into a string
# that defines the configuration.
#
# If you want logs to go to syslog, uncomment the following line.
# - [ *log_base, *log_syslog ]
#
# The default behavior is to just log to a file.
# This mechanism that does not depend on a system service to operate.
- [ *log_base, *log_file ]
# A file path can also be used.
# - /etc/log.conf
# This tells cloud-init to redirect its stdout and stderr to
# 'tee -a /var/log/cloud-init-output.log' so the user can see output
# there without needing to look on the console.
output: {all: '| tee -a /var/log/cloud-init-output.log'}
3.7. cloud-init /var/lib/cloud ディレクトリーのレイアウト リンクのコピーリンクがクリップボードにコピーされました!
cloud-init を最初に実行すると、インスタンスおよび cloud-init 設定に関する情報が含まれるディレクトリーレイアウトが作成されます。
ディレクトリーには、/scripts/vendor などのオプションのディレクトリーを追加できます。
以下は、cloud-init のサンプルディレクトリーレイアウトです。
/var/lib/cloud/
- data/
- instance-id
- previous-instance-id
- previous-datasource
- previous-hostname
- result.json
- set-hostname
- status.json
- handlers/
- instance
- boot-finished
- cloud-config.txt
- datasource
- handlers/
- obj.pkl
- scripts/
- sem/
- user-data.txt
- user-data.txt.i
- vendor-data.txt
- vendor-data.txt.i
- instances/
f111ee00-0a4a-4eea-9c17-3fa164739c55/
- boot-finished
- cloud-config.txt
- datasource
- handlers/
- obj.pkl
- scripts/
- sem/
- user-data.txt
- user-data.txt.i
- vendor-data.txt
- vendor-data.txt.i
- scripts/
- per-boot/
- per-instance/
- per-once/
- vendor/
- seed/
- sem/
- config_scripts_per_once.once
第4章 cloud-init の設定 リンクのコピーリンクがクリップボードにコピーされました!
本章では、cloud-init で最も一般的な設定タスクの例を紹介します。
cloud-init 設定では、cloud.cfg ファイルおよび cloud.cfg.d ディレクトリーへのディレクティブの追加を必要とすることがあります。あるいは、特定のデータソースでは、ユーザーデータファイルやメタデータファイルなどのファイルにディレクティブを追加する必要がある場合があります。データソースでは、ディレクティブの HTTP サーバーへのアップロードが必要な場合があります。データソースの要件を確認し、それに応じてディレクティブを追加します。
4.1. NoCloud データソースの cloud-init を含む仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init を含む新しい仮想マシン (VM) を作成するには、次の手順を参照してください。この手順では、meta-data ファイルと user-data ファイルを作成します。
-
meta-dataファイルには、インスタンスの詳細が含まれます。 -
user-dataファイルには、ユーザーを作成し、アクセスを付与するための情報が含まれます。
これらのファイルを新しい ISO イメージに追加し、KVM ゲストイメージから作成された新しい仮想マシンに ISO ファイルをアタッチします。このシナリオでは、データソースは NoCloud です。
手順
cloudinitisoという名前のディレクトリーを作成し、作業ディレクトリーとして設定します。$ mkdir cloudinitiso $ cd cloudinitisometa-dataファイルを作成して、以下の情報を追加します。instance-id: citest local-hostname: citest-1user-dataファイルを作成して、以下の情報を追加します。#cloud-config password: cilogon chpasswd: {expire: False} ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AAA...fhHQ== sample@redhat.com注記user-dataファイルの最後の行は、SSH 公開鍵を参照します。~/.ssh/id_rsa.pubで SSH 公開鍵を検索します。このサンプル手順を行う場合は、行を変更して公開鍵の 1 つを含めます。genisoimageコマンドを使用して、user-dataおよびmeta-dataを含む ISO イメージを作成します。# genisoimage -output ciiso.iso -volid cidata -joliet -rock user-data meta-data I: -input-charset not specified, using utf-8 (detected in locale settings) Total translation table size: 0 Total rockridge attributes bytes: 331 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 183 extents written (0 MB)-
Red Hat カスタマーポータルから、
/var/lib/libvirt/imagesディレクトリーに KVM ゲストイメージをダウンロードします。 virt-installユーティリティーを使用して KVM ゲストイメージから新しい仮想マシンを作成し、ダウンロードしたイメージを既存のイメージにアタッチします。# virt-install \ --memory 4096 \ --vcpus 4 \ --name mytestcivm \ --disk /var/lib/libvirt/images/rhel-8.1-x86_64-kvm.qcow2,device=disk,bus=virtio,format=qcow2 \ --disk /home/sample/cloudinitiso/ciiso.iso,device=cdrom \ --os-type Linux \ --os-variant rhel8.0 \ --virt-type kvm \ --graphics none \ --importユーザー名
cloud-userおよびパスワードcilogonでイメージにログオンします。citest-1 login: cloud-user Password: [cloud-user@citest-1 ~]$
検証
cloud-initステータスを確認して、ユーティリティーが定義されたタスクを完了していることを確認します。[cloud-user@citest-1 instance]$ cloud-init status status: donecloud-initユーティリティーは、実行時に/var/lib/cloudの下にcloud-initディレクトリーレイアウトを作成し、指定したディレクティブに基づいて特定のディレクトリーコンテンツを更新または変更します。たとえば、データソースファイルをチェックして、データソースが
NoCloudであることを確認できます。$ cd /var/lib/cloud/instance $ cat datasource DataSourceNoCloud: DataSourceNoCloud [seed=/dev/sr0][dsmode=net]cloud-initcopies user-data into/var/lib/cloud/instance/user-data.txt:$ cat user-data.txt #cloud-config password: cilogon chpasswd: {expire: False} ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AAA...fhHQ== sample@redhat.com
OpenStack の場合、インスタンスの作成と管理 には、cloud-init を使用してインスタンスを設定するための情報が含まれています。特定の手順は、Creating a customized instance を参照してください。
4.2. cloud-init を使用してクラウドユーザーパスワードを期限切れにする リンクのコピーリンクがクリップボードにコピーされました!
初回ログイン時に cloud-user パスワードを変更するよう cloud-user に強制することができます。パスワードを失効させるには、以下の手順を実行します。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。chpasswd: {expire: False}の行をchpasswd: {expire: True}に変更します。#cloud-config password: mypassword chpasswd: {expire: True} ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AAA...SDvz user1@yourdomain.com - ssh-rsa AAB...QTuo user2@yourdomain.comこれはパスワードを失効させます。なぜなら、
passwordとchpasswdは特に指定がない限り、デフォルトのユーザーで動作するからです。注記これはグローバル設定です。
chpasswdをTrueに設定すると、作成するすべてのユーザーが、ログイン時にパスワードを変更する必要があります。
4.3. cloud-init でのデフォルトユーザー名の変更 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのユーザー名は、cloud-user 以外のものに変更できます。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。user: <username> の行を追加します。<username> は新しいデフォルトのユーザー名に置き換えます。#cloud-config user: username password: mypassword chpasswd: {expire: False} ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AAA...SDvz user1@yourdomain.com - ssh-rsa AAB...QTuo user2@yourdomain.com
4.4. cloud-init を使用した root パスワードの設定 リンクのコピーリンクがクリップボードにコピーされました!
root パスワードを設定するには、ユーザーのリストを作成します。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。ファイルの
chpasswdセクションで、ユーザー一覧を作成します。注記空白は重要です。ユーザーリストのコロンの前後に空白を含めないでください。空白が含まれている場合、パスワードは空白を入れた設定となります。
#cloud-config ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AAA...SDvz user1@yourdomain.com - ssh-rsa AAB...QTuo user2@yourdomain.com chpasswd: list: | root:myrootpassword cloud-user:mypassword expire: False注記この方法を使用してユーザーパスワードを設定する場合は、本セクションの すべてのパスワード を設定する必要があります。
4.5. cloud-init を使用した Red Hat サブスクリプションの管理 リンクのコピーリンクがクリップボードにコピーされました!
rh_subscription ディレクティブを使用してシステムを登録できます。サブスクリプションごとに、ユーザーデータを編集する必要があります。以下の手順では、rh_subscription ディレクティブを使用して加えることのできる変更の例をいくつか示します。
手順
自動アタッチオプションとサービスレベルオプションを使用するには、次の手順を実行します。rh_subscriptionの下にusernameとpasswordを追加して、auto-attachをTrueに設定し、service-levelをself-supportに設定します。rh_subscription: username: sample@redhat.com password: 'mypassword' auto-attach: True service-level: self-support注記service-levelオプションでは、auto-attachオプションを使用する必要があります。activation-keyおよびorgオプションを使用するには、以下の手順を実行します。rh_subscriptionの下にactivation keyとorgの番号を追加し、auto-attachをTrueに設定します。rh_subscription: activation-key: example_key org: 12345 auto-attach: Trueサブスクリプションプールを追加するには、以下の手順を実行します。
rh_subscriptionの下に、username、password、およびプール番号を追加します。rh_subscription: username: sample@redhat.com password: 'password' add-pool: XYZ01234567注記このサンプルは、
subscription-manager attach --pool=XYZ01234567コマンドに相当します。/etc/rhsm/rhsm.confファイルでサーバーのホスト名を設定するには、以下の手順を実行します。rh_subscriptionの下にusername、password、server-hostnameを追加し、auto-attachをTrueに設定します。rh_subscription: username: sample@redhat.com password: 'password' server-hostname: test.example.com auto-attach: True
4.6. cloud-init を使用したユーザーおよびユーザーオプションの追加 リンクのコピーリンクがクリップボードにコピーされました!
users セクション でユーザーを作成し、説明します。セクションを変更して初期システム設定にユーザーをさらに追加でき、追加のユーザーオプションを設定できます。
users セクションを追加する場合、本セクションのデフォルトのユーザーオプションを設定する必要もあります。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。usersセクションを追加または変更し、ユーザーを追加します。-
cloud-userを、指定する他のユーザーと共に作成したデフォルトユーザーにするには、セクションの最初のエントリーとしてdefaultを追加することを確認してください。これが最初のエントリーでない場合は、cloud-userは作成されません。 デフォルトでは、
selinux-user値がない場合、ユーザーはunconfined_uとラベル付けされます。#cloud-config users: - default - name: user2 gecos: User N. Ame selinux-user: staff_u groups: users,wheel ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AA..vz user@domain.com chpasswd: list: | root:password cloud-user:mypassword user2:mypassword2 expire: False注記-
この例では、ユーザー
user2を 2 つのグループ (usersとwheel) に配置します。
-
この例では、ユーザー
-
4.7. cloud-init を使用した最初の起動コマンドの実行 リンクのコピーリンクがクリップボードにコピーされました!
runcmd セクションおよび bootcmd セクションを使用して、起動および初期化中にコマンドを実行できます。
bootcmd セクションは、初期化プロセスの早い段階で実行され、デフォルトでは起動ごとに実行されます。runcmd セクションは、プロセスの最後の方で実行され、初回起動時および初期化中にのみ実行されます。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。bootcmdおよびruncmdのセクションを追加します。cloud-initが実行するコマンドを含めます。#cloud-config users: - default - name: user2 gecos: User N. Ame groups: users chpasswd: list: | root:password fedora:myfedpassword user2:mypassword2 expire: False bootcmd: - echo New MOTD >> /etc/motd runcmd: - echo New MOTD2 >> /etc/motd
4.8. cloud-init を使用した sudoers の追加 リンクのコピーリンクがクリップボードにコピーされました!
sudo および groups エントリーを users セクションに追加することで、ユーザーを sudoer として設定できます。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。-
sudoエントリーを追加し、ユーザーアクセスを指定します。たとえば、sudo: ALL=(ALL) NOPASSWD:ALLは、ユーザーに無制限のユーザーアクセスを許可します。 groupsエントリーを追加し、ユーザーを含むグループを指定します。#cloud-config users: - default - name: user2 gecos: User D. Two sudo: ["ALL=(ALL) NOPASSWD:ALL"] groups: wheel,adm,systemd-journal ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AA...vz user@domain.com chpasswd: list: | root:password cloud-user:mypassword user2:mypassword2 expire: False
4.9. cloud-init を使用した静的ネットワーク設定 リンクのコピーリンクがクリップボードにコピーされました!
メタデータに network-interfaces セクションを追加することで、cloud-init を使用したネットワーク設定を設定できます。
Red Hat Enterprise Linux は、動的ネットワークを制御および設定するデーモンである NetworkManager を介してデフォルトのネットワークサービスを提供します。これにより、ネットワークデバイスと接続が利用可能な場合に起動してアクティブな状態を維持します。
データソースがネットワーク設定を提供する場合があります。詳細は、cloud-init の Network Configuration Sources セクションを参照してください。
cloud-init のネットワーク設定を指定せずに、ネットワーク設定を無効にしていない場合、cloud-init は割り当てられているデバイスに接続があるかどうかを判別しようとします。接続されたデバイスを見つけると、インターフェイスで DHCP 要求を発行するネットワーク設定が生成されます。詳細は、cloud-init ドキュメントの Fallback Network Configuration セクションを参照してください。
手順
以下の例では、静的ネットワーク設定を追加します。
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。network-interfacesセクションを追加します。network: version: 1 config: - type: physical name: eth0 subnets: - type: static address: 192.0.2.1/24 gateway: 192.0.2.254
メタデータに以下の情報を追加することで、ネットワーク設定を無効にすることができます。
network:
config: disabled
4.10. cloud-init を使用した root ユーザーのみの設定 リンクのコピーリンクがクリップボードにコピーされました!
root ユーザーがあり、他のユーザーはないようにユーザーデータを設定することができます。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。usersセクションに、ユーザーrootのエントリーを作成します。以下の簡単な例には、
nameオプションのみを持つusersセクションが含まれます。users: - name: root chpasswd: list: | root:password expire: Falseオプションで、root ユーザーの SSH 鍵を設定します。
users: - name: root ssh_pwauth: True ssh_authorized_keys: - ssh-rsa AA..vz user@domain.com
4.11. cloud-init で container-storage-setup を使用したストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
write_files モジュール内で、container-storage-setup ユーティリティーを参照してストレージを設定できます。
手順
データソースの要件に応じて、
user-dataファイルを編集するか、以下のディレクティブをcloud.cfg.dディレクトリーに追加します。注記cloud-initが、ユーザーディレクティブを含むファイルを認識できるように、すべてのユーザーディレクティブはファイルの最上部に#cloud-configが含まれます。cloud.cfg.dディレクトリーにディレクティブを含める場合は、ファイル名を*.cfgとし、ファイルの最上部に常に#cloud-configを含めます。write_filesモジュールを追加または変更して、container-storage-setupユーティリティーへのパスを追加します。以下の例では、root 論理ボリュームのサイズを、デフォルトの 3 GB ではなく 6GB に設定します。
write_files: - path: /etc/sysconfig/docker-storage-setup permissions: 0644 owner: root content: | ROOT_SIZE=6G注記RHEL 7.4 より前のバージョンでは、container-storage-setup は docker-storage-setup と呼ばれていました。RHEL 7.4 の時点で、ストレージに OverlayFS を使用している場合は、SELinux でのこのタイプのファイルシステムを Enforcing モードで使用できるようになりました。
4.12. cloud-init を使用したシステムロケールの変更 リンクのコピーリンクがクリップボードにコピーされました!
locale モジュールを使用して、システムの場所を設定できます。
手順
-
データソースの要件に応じて、
meta-dataファイルを編集します。以下のディレクティブを cloud.cfg ファイルまたはcloud.cfg.d ディレクトリーに追加することもできます。 -
場所を指定して
localeディレクティブを追加します。以下の例では、UTF-8エンコーディングでlocaleをja_JP(日本) に設定しています。
#cloud-config
locale: ja_JP.UTF-8
4.13. cloud-init およびシェルスクリプト リンクのコピーリンクがクリップボードにコピーされました!
bootcmd または runcmd に、リスト値または文字列の値を追加できます。また、ユーザーデータ内にシェルスクリプトを指定することもできます。
-
bootcmdまたはruncmdのリスト値を使用すると、各リスト項目はexecveを使用して順番に実行されます。 - 文字列の値を使用する場合、文字列全体がシェルスクリプトとして実行されます。
-
cloud-initを使用してシェルスクリプトを実行する場合は、cloud-initに.yamlファイルを指定する代わりに、(シバン (#!) 機能を備えた) シェルスクリプトを指定できます。
シェルスクリプトを bootcmd および runcmd に配置する方法の例は、Run commands on first boot を参照してください。
4.14. cloud-init による設定ファイルの更新の阻止 リンクのコピーリンクがクリップボードにコピーされました!
バックアップイメージからインスタンスを作成または復元すると、インスタンス ID が変更されます。インスタンス ID の変更により、cloud-init ユーティリティーは設定ファイルを更新します。
バックアップから作成または復元する際に、cloud-init が特定の設定ファイルを更新しないようにするには、以下の手順を実行します。
手順
/etc/cloud/cloud.cfgファイルを編集します。次に例を示します。# vi /etc/cloud/cloud.cfgインスタンスの復元時に、
cloud-initが更新しない設定をコメントアウトまたは削除します。たとえば、SSH 鍵ファイルの更新を回避するには、cloud_init_modulesセクションから-sshを削除します。cloud_init_modules: - disk_setup - migrator - bootcmd - write-files - growpart - resizefs - set_hostname - update_hostname - update_etc_hosts - rsyslog - users-groups # - ssh
検証
cloud-initによって更新された設定ファイルを確認するには、/var/log/cloud/cloud-init.logファイルを調べます。更新されたファイルは、インスタンスの起動時にWriting toで始まるメッセージでログに記録されます。以下に例を示します。2019-09-03 00:16:07,XXX - util.py[DEBUG]: Writing to /root/.ssh/authorized_keys - wb: [XXX] 554 bytes 2019-09-03 00:16:08,XXX - util.py[DEBUG]: Writing to /etc/ssh/sshd_config - wb: [XXX] 3905 bytes
4.15. cloud-init の実行後に KVM ゲストイメージから作成された仮想マシンの変更 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init ユーティリティーを再実行する前に、cloud-init 設定を変更するには、次の手順を使用します。cloud-init パッケージがインストールされ、有効にして仮想マシンを起動すると、cloud-init は仮想マシンの初回起動時にデフォルト状態で実行されます。
手順
- 仮想マシンにログインします。
-
ディレクティブを追加または変更します。たとえば、
/etc/cloudディレクトリーのcloud.cfgファイルを変更するか、ディレクティブを/etc/cloud/cloud.cfg.dディレクトリーに追加します。 cloud-init cleanコマンドを実行してディレクトリーをクリーンアップし、cloud-initが再実行できるようにします。root で以下のコマンドを実行して、仮想マシンをクリーンアップすることもできます。rm -Rf /var/lib/cloud/instances/ rm -Rf /var/lib/cloud/instance rm -Rf /var/lib/cloud/data/注記クリーニングしたイメージを新しいイメージとして保存し、そのイメージを複数の仮想マシンに使用できます。新しい仮想マシンは、更新された
cloud-init設定を使用してcloud-initを実行します。cloud-initを再実行するか、仮想マシンを再起動します。cloud-initが再実行し、変更した設定を実装します。
4.16. cloud-init 実行後の特定データソースの仮想マシンの変更 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init を再実行する前に、cloud-init 設定を変更するには、次の手順を参照してください。この手順では、例として OpenStack を使用します。実行する必要がある正確な手順は、データソースによって異なることに注意してください。
手順
-
OpenStack Platform のインスタンスを作成して起動します。OpenStack のインスタンスの作成は、インスタンスの作成 を参照してください。この例では、仮想マシン(VM)には
cloud-initが含まれており、これは仮想マシンの起動時に実行されます。 -
ディレクティブを追加または変更します。たとえば、OpenStack HTTP サーバー上に保管されている
user-data.fileファイルを変更します。 仮想マシンをクリーンアップします。以下のコマンドを root 権限で実行します。
# rm -rf /etc/resolv.conf /run/cloud-init # userdel -rf cloud-user # hostnamectl set-hostname localhost.localdomain # rm /etc/NetworkManager/conf.d/99-cloud-init.conf注記クリーニングしたイメージを新しいイメージとして保存し、そのイメージを複数の仮想マシンに使用できます。新しい仮想マシンは、更新された
cloud-init設定を使用して、cloud-initを実行します。cloud-initを再実行するか、仮想マシンを再起動します。cloud-initが再実行し、設定変更を実装します。
4.17. cloud-init のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
cloud-init ユーティリティーの実行後に、設定ファイルとログファイルを確認してインスタンスをトラブルシューティングできます。問題を特定したら、インスタンスで cloud-init を再実行します。コマンドラインから cloud-init を実行できます。詳細は、cloud-init --help コマンドを実行してください。
以下の手順では、cloud-init の問題を特定する手順と、プログラムを再実行するためのサンプルを説明します。
手順
cloud-init設定ファイルを確認します。-
/etc/cloud/cloud.cfg設定ファイルを検証します。cloud_init_modules、cloud_config_modules、およびcloud_final_modulesに含まれるモジュールを確認します。 -
/etc/cloud/cloud.cfg.dディレクトリーで、ディレクティブ (*.cfgfiles) を確認します。
-
特定の問題の詳細については、
/var/log/cloud-init.logファイルおよび/var/log/cloud-init-output.logファイルを確認してください。たとえば、root パーティションが自動的に拡張されなかった場合は、growpartユーティリティーのログメッセージを確認します。ファイルシステムが拡張されなかった場合は、ログメッセージでresizefsを確認します。以下に例を示します。# grep resizefs /var/log/cloud-init.log注記growpartは LVM をサポートしません。root パーティションが LVM をベースとしている場合は、root パーティションは初回起動時に自動的に拡張されません。root で
cloud-initコマンドを再実行します。init モジュールのみで
cloud-initを再実行します。# /usr/bin/cloud-init -d init設定内のすべてのモジュールで
cloud-initを再実行します。# /usr/bin/cloud-init -d modulescloud-initキャッシュを削除し、起動後にcloud-initを強制的に実行します。# rm -rf /var/lib/cloud/ && /usr/bin/cloud-init -d initディレクトリーをクリーンなし、クリーンなインスタンスをシミュレートします。
# rm -rf /var/lib/cloud/instances/ # rm -rf /var/lib/cloud/instance # rm -rf /var/lib/cloud/data/ # rebootcloud-initユーティリティーを再実行します。# cloud-init init --local # cloud-init init