コンテナー化されたサービスへの移行
コンテナー化された OpenStack Platform サービスの操作に関する基本ガイド
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
Jira でドキュメントのフィードバックを提供する
ドキュメントに関するフィードバックを提供するには、Create Issue フォームを使用します。Red Hat OpenStack Platform Jira プロジェクトで Jira Issue が作成され、フィードバックの進行状況を追跡できます。
- Jira にログインしていることを確認してください。Jira アカウントをお持ちでない場合は、アカウントを作成してフィードバックを送信してください。
- Create Issue をクリックして、Create Issue ページを開きます。
- Summary フィールドと Description フィールドに入力します。Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。フォーム内の他のフィールドは変更しないでください。
- Create をクリックします。
第1章 概要 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの Red Hat OpenStack Platform は、Systemd の管理するサービスを使用していました。しかし、より新しいバージョンの OpenStack Platform は、コンテナーを使用してサービスを実行するようになりました。コンテナー化された OpenStack Platform サービスがどのように動作するか、理解が十分ではない管理者もいます。本ガイドの目的は、OpenStack Platform のコンテナーイメージおよびコンテナー化されたサービスを理解するのに役立つ情報を提供することです。ここでは、以下の点について説明します。
- コンテナーイメージを取得および変更する方法
- コンテナー化されたサービスをオーバークラウドで管理する方法
- コンテナーと Systemd サービスの相違点の理解
本書の主目的は、Systemd ベースの環境からコンテナーベースの環境に移行するために、コンテナー化された OpenStack Platform サービスに関する十分な知識を習得するのに役立つ情報を提供することです。
1.1. コンテナー化されたサービスおよび Kolla リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) の各主要サービスは、コンテナー内で実行されます。このことにより、それぞれのサービスが、ホストから独立した専用の分離名前空間内に維持されます。これには次の効果があります。
- デプロイ中、RHOSP は Red Hat カスタマーポータルからコンテナーイメージをプルして実行する。
-
podmanコマンドは、サービスの起動や停止などの管理機能を実行する。 - コンテナーをアップグレードするには、新しいコンテナーイメージをプルし、既存のコンテナーを新しいバージョンのコンテナーに置き換える必要がある。
Red Hat OpenStack Platform は、Kolla ツールセットによりビルド/管理されるコンテナーセットを使用します。
第2章 コンテナーイメージの取得および変更 リンクのコピーリンクがクリップボードにコピーされました!
コンテナー化されたオーバークラウドには、必要なコンテナーイメージを含むレジストリーへのアクセスが必要です。本章では、Red Hat OpenStack Platform 向けのコンテナーイメージを使用するためのレジストリーおよびアンダークラウドとオーバークラウドの設定の準備方法について説明します。
2.1. コンテナーイメージの準備 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドのインストールには、コンテナーイメージの取得先およびその保存方法を定義するための環境ファイルが必要です。この環境ファイルを生成してカスタマイズし、コンテナーイメージの準備に使用します。
オーバークラウド用に特定のコンテナーイメージバージョンを設定する必要がある場合は、イメージを特定のバージョンに固定する必要があります。詳しい情報は、Pinning container images for the overcloud を参照してください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 デフォルトのコンテナーイメージ準備ファイルを生成します。
sudo openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yaml
$ sudo openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドでは、以下の追加オプションを使用しています。
-
--local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。 --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名はcontainers-prepare-parameter.yamlです。注記アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ
containers-prepare-parameter.yamlファイルを使用することができます。
-
-
要件に合わせて
containers-prepare-parameter.yamlを変更します。
2.2. コンテナーイメージ準備のパラメーター リンクのコピーリンクがクリップボードにコピーされました!
コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。
それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare ストラテジーの各設定で使用することのできるサブパラメーターの情報をまとめています。
| パラメーター | 説明 |
|---|---|
|
| 設定からイメージ名を除外する正規表現のリスト |
|
|
設定に含める正規表現のリスト。少なくとも 1 つのイメージ名が既存のイメージと一致している必要があります。 |
|
|
対象となるイメージのタグに追加する文字列。たとえば、16.2.3-5.161 のタグが付けられたイメージをプルし、 |
|
| 変更するイメージを絞り込むイメージラベルのディクショナリー。イメージが定義したラベルと一致する場合には、director はそのイメージを変更プロセスに含めます。 |
|
| イメージのアップロード中 (ただし目的のレジストリーにプッシュする前) に実行する Ansible ロール名の文字列 |
|
|
|
|
| アップロードプロセス中にイメージをプッシュするレジストリーの名前空間を定義します。
実稼働環境でこのパラメーターを
|
|
| 元のコンテナーイメージをプルするソースレジストリー |
|
|
初期イメージの取得場所を定義する、 |
|
|
指定したコンテナーイメージのメタデータラベルの値を使用して、すべてのイメージのタグを作成し、そのタグが付けられたイメージをプルします。たとえば、 |
イメージをアンダークラウドにプッシュする場合は、push_destination: UNDERCLOUD_IP:PORT の代わりに push_destination: true を使用します。push_destination: true 手法を使用することで、IPv4 アドレスおよび IPv6 アドレスの両方で一貫性が確保されます。
set パラメーターには、複数の キー: 値 定義を設定することができます。
| キー | 説明 |
|---|---|
|
| Ceph Storage コンテナーイメージの名前 |
|
| Ceph Storage コンテナーイメージの名前空間 |
|
| Ceph Storage コンテナーイメージのタグ |
|
| Ceph Storage Alert Manager コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Grafana コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Node Exporter コンテナーイメージの名前、namespace、およびタグ。 |
|
| Ceph Storage Prometheus コンテナーイメージの名前、namespace、およびタグ。 |
|
| 各 OpenStack サービスイメージの接頭辞 |
|
| 各 OpenStack サービスイメージの接尾辞 |
|
| 各 OpenStack サービスイメージの名前空間 |
|
|
使用する OpenStack Networking (neutron) コンテナーを定義するのに使用するドライバー。標準の |
|
|
ソースからの全イメージに特定のタグを設定します。定義されていない場合は、director は Red Hat OpenStack Platform のバージョン番号をデフォルト値として使用します。このパラメーターは、 |
コンテナーイメージでは、Red Hat OpenStack Platform のバージョンに基づいたマルチストリームタグが使用されます。したがって、今後 latest タグは使用されません。
2.3. コンテナーイメージタグ付けのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
Red Hat コンテナーレジストリーでは、すべての Red Hat OpenStack Platform コンテナーイメージをタグ付けするのに、特定のバージョン形式が使用されます。この形式は、version-release のように各コンテナーのラベルのメタデータに従います。
- version
- Red Hat OpenStack Platform のメジャーおよびマイナーバージョンに対応します。これらのバージョンは、1 つまたは複数のリリースが含まれるストリームとして機能します。
- release
- バージョンストリーム内の、特定コンテナーイメージバージョンのリリースに対応します。
たとえば、Red Hat OpenStack Platform の最新バージョンが 16.2.3 で、コンテナーイメージのリリースが 5.161 の場合、コンテナーイメージのタグは 16.2.3-5.161 となります。
Red Hat コンテナーレジストリーでは、コンテナーイメージバージョンの最新リリースとリンクするメジャーおよびマイナー version タグのセットも使用されます。たとえば、16.2 と 16.2.3 の両方が、16.2.3 コンテナーストリームの最新 release とリンクします。16.2 の新規マイナーリリースが公開されると、16.2 タグは新規マイナーリリースストリームの最新 release とリンクします。一方、16.2.3 タグは、引き続き 16.2.3 ストリーム内の最新 release とリンクします。
ContainerImagePrepare パラメーターには 2 つのサブパラメーターが含まれ、これを使用してダウンロードするコンテナーイメージを定義することができます。これらのサブパラメーターは、set ディクショナリー内の tag パラメーターおよび tag_from_label パラメーターです。以下のガイドラインを使用して、tag または tag_from_label のどちらを使用するかを判断してください。
tagのデフォルト値は、お使いの OpenStack Platform のメジャーバージョンです。本バージョンでは、16.2 です。これは常に最新のマイナーバージョンおよびリリースに対応します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenStack Platform コンテナーイメージの特定マイナーバージョンに変更するには、タグをマイナーバージョンに設定します。たとえば、16.2.2 に変更するには、
tagを 16.2.2 に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
tagを設定すると、インストールおよび更新時に、director は必ずtagで設定したバージョンの最新のコンテナーイメージreleaseをダウンロードします。 tagを設定しないと、director は最新のメジャーバージョンと共にtag_from_labelの値を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow tag_from_labelパラメーターは、Red Hat コンテナーレジストリーから検査する最新コンテナーイメージリリースのラベルメタデータからタグを生成します。たとえば、特定のコンテナーのラベルは、以下のversionおよびreleaseメタデータを使用します。"Labels": { "release": "5.161", "version": "16.2.3", ... }"Labels": { "release": "5.161", "version": "16.2.3", ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
tag_from_labelのデフォルト値は{version}-{release}です。これは、各コンテナーイメージのバージョンおよびリリースのメタデータラベルに対応します。たとえば、コンテナーイメージのversionに 16.2.3 が、releaseに 5.161 が、それぞれ設定されている場合、コンテナーイメージのタグは 16.2.3-5.161 となります。 -
tagパラメーターは、常にtag_from_labelパラメーターよりも優先されます。tag_from_labelを使用するには、コンテナー準備の設定でtagパラメーターを省略します。 -
tagおよびtag_from_labelの主な相違点は、次のとおりです。director がtagを使用してイメージをプルする場合は、Red Hat コンテナーレジストリーがバージョンストリーム内の最新イメージリリースとリンクするメジャーまたはマイナーバージョンのタグだけに基づきます。一方、tag_from_labelを使用する場合は、director がタグを生成して対応するイメージをプルできるように、各コンテナーイメージのメタデータの検査を行います。
2.4. プライベートレジストリーからのコンテナーイメージの取得 リンクのコピーリンクがクリップボードにコピーされました!
registry.redhat.io レジストリーにアクセスしてイメージをプルするには、認証が必要です。registry.redhat.io およびその他のプライベートレジストリーで認証するには、containers-prepare-parameter.yaml ファイルに ContainerImageRegistryCredentials および ContainerImageRegistryLogin パラメーターを含めます。
ContainerImageRegistryCredentials
一部のコンテナーイメージレジストリーでは、イメージにアクセスするのに認証が必要です。そのような場合には、containers-prepare-parameter.yaml 環境ファイルの ContainerImageRegistryCredentials パラメーターを使用します。ContainerImageRegistryCredentials パラメーターは、プライベートレジストリーの URL に基づくキーのセットを使用します。それぞれのプライベートレジストリーの URL は、独自のキーと値のペアを使用して、ユーザー名 (キー) およびパスワード (値) を定義します。これにより、複数のプライベートレジストリーに対して認証情報を指定することができます。
上記の例の my_username および my_password を、実際の認証情報に置き換えてください。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。
複数のレジストリーの認証情報を指定するには、ContainerImageRegistryCredentials でレジストリーごとに複数のキー/ペアの値を設定します。
デフォルトの ContainerImagePrepare パラメーターは、認証が必要な registry.redhat.io からコンテナーイメージをプルします。
詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。
ContainerImageRegistryLogin
ContainerImageRegistryLogin パラメーターを使用して、コンテナーイメージを取得するために、オーバークラウドノードシステムがリモートレジストリーにログインする必要があるかどうかを制御します。このような状況は、アンダークラウドを使用してイメージをホストする代わりに、オーバークラウドノードがイメージを直接プルする場合に発生します。
特定の設定について、push_destination が false に設定されている、または使用されていない場合は、ContainerImageRegistryLogin を true に設定する必要があります。
ただし、オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がなく、ContainerImageRegistryLogin を true に設定すると、ログインを試みる際にデプロイメントが失敗する可能性があります。オーバークラウドノードに ContainerImageRegistryCredentials で定義されたレジストリーホストへのネットワーク接続がない場合、push_destination を true に、ContainerImageRegistryLogin を false に設定して、オーバークラウドノードがアンダークラウドからイメージをプルできるようにします。
2.5. イメージ準備エントリーの階層化 リンクのコピーリンクがクリップボードにコピーされました!
ContainerImagePrepare パラメーターの値は YAML リストです。したがって、複数のエントリーを指定することができます。
次の例は、16.2.1-hotfix のタグが付いた nova-api イメージ以外のすべてのイメージの最新版を director が使用する 2 つのエントリーを示しています。
includes および excludes のパラメーターでは、各エントリーのイメージの絞り込みをコントロールするのに正規表現が使用されます。includes 設定と一致するイメージが、excludes と一致するイメージに優先します。一致するとみなされるためには、イメージ名に includes または excludes の正規表現の値が含まれている必要があります。
ブロックストレージ (シンダー) ドライバーがプラグインと呼ばれるベンダー提供のシンダーボリュームイメージを必要とする場合も、同様の手法が使用されます。Block Storage ドライバーにプラグインが必要な場合は、Advanced Overcloud Customization ガイドの Deploying a vendor plugin を参照してください。
2.6. 準備プロセスにおけるイメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
イメージの準備中にイメージを変更し、変更したそのイメージで直ちにオーバークラウドをデプロイすることが可能です。
Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーの準備中にイメージを変更することをサポートします。
イメージを変更するシナリオを以下に示します。
- デプロイメント前にテスト中の修正でイメージが変更される、継続的インテグレーションのパイプラインの一部として。
- ローカルの変更をテストおよび開発のためにデプロイしなければならない、開発ワークフローの一部として。
- 変更をデプロイしなければならないが、イメージビルドパイプラインでは利用することができない場合。たとえば、プロプライエタリーアドオンの追加または緊急の修正など。
準備プロセス中にイメージを変更するには、変更する各イメージで Ansible ロールを呼び出します。ロールはソースイメージを取得して必要な変更を行い、その結果をタグ付けします。prepare コマンドでイメージを目的のレジストリーにプッシュし、変更したイメージを参照するように heat パラメーターを設定することができます。
Ansible ロール tripleo-modify-image は要求されたロールインターフェイスに従い、変更のユースケースに必要な処理を行います。ContainerImagePrepare パラメーターの変更固有のキーを使用して、変更をコントロールします。
-
modify_roleでは、変更する各イメージについて呼び出す Ansible ロールを指定します。 -
modify_append_tagは、ソースイメージタグの最後に文字列を追加します。これにより、そのイメージが変更されていることが明確になります。すでにpush_destinationレジストリーに変更されたイメージが含まれている場合には、このパラメーターを使用して変更を省略します。イメージを変更する場合には、必ずmodify_append_tagを変更します。 -
modify_varsは、ロールに渡す Ansible 変数のディクショナリーです。
tripleo-modify-image ロールが処理するユースケースを選択するには、tasks_from 変数をそのロールで必要なファイルに設定します。
イメージを変更する ContainerImagePrepare エントリーを開発およびテストする場合には、イメージが想定どおりに変更されることを確認するために、追加のオプションを指定せずにイメージの準備コマンドを実行します。
sudo openstack tripleo container image prepare \ -e ~/containers-prepare-parameter.yaml
sudo openstack tripleo container image prepare \
-e ~/containers-prepare-parameter.yaml
openstack tripleo container image prepare コマンドを使用するには、アンダークラウドに実行中の image-serve レジストリーが含まれている必要があります。したがって、image-serve レジストリーがインストールされないため、新しいアンダークラウドのインストール前にこのコマンドを実行することはできません。アンダークラウドが正常にインストールされた後に、このコマンドを実行することができます。
2.7. コンテナーイメージの既存パッケージの更新 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーのコンテナーイメージ上の既存のパッケージの更新をサポートします。
手順
以下の
ContainerImagePrepareエントリーは、アンダークラウドホストの dnf リポジトリー設定を使用してコンテナーイメージのパッケージをすべて更新する例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8. コンテナーイメージへの追加 RPM ファイルのインストール リンクのコピーリンクがクリップボードにコピーされました!
RPM ファイルのディレクトリーをコンテナーイメージにインストールすることができます。この機能は、ホットフィックスやローカルパッケージビルドなど、パッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。
Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナーのコンテナーイメージへの追加の RPM ファイルのインストールをサポートします。
既存のデプロイメントでコンテナーイメージを変更する場合は、変更後にマイナー更新を実行して変更をオーバークラウドに適用する必要があります。詳細は、Red Hat OpenStack Platform を最新状態に保つ を参照してください。
手順
次の
ContainerImagePrepareエントリーの例では、いくつかのホットフィックスパッケージをnova-computeイメージにのみインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9. カスタム Dockerfile を使用したコンテナーイメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
Dockerfile を含むディレクトリーを指定して、必要な変更を加えることができます。tripleo-modify-image ロールを呼び出すと、ロールは Dockerfile.modified ファイルを生成し、これにより FROM ディレクティブが変更され新たな LABEL ディレクティブが追加されます。
Red Hat OpenStack Platform (RHOSP) ディレクターは、Ceph コンテナーではなく、RHOSP コンテナー用のカスタム Dockerfile を使用したコンテナーイメージの変更をサポートします。
手順
以下の例では、
nova-computeイメージでカスタム Dockerfile が実行されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow /home/stack/nova-custom/Dockerfileファイルの例を以下に示します。USERroot ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.10. コンテナーイメージ管理用 Satellite サーバーの準備 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Satellite 6 には、レジストリーの同期機能が備わっています。これにより、複数のイメージを Satellite Server にプルし、アプリケーションライフサイクルの一環として管理することができます。また、他のコンテナー対応システムも Satellite をレジストリーとして使うことができます。コンテナーイメージ管理についての詳細は、Red Hat Satellite 6 コンテンツ管理ガイドの コンテナーイメージの管理 を参照してください。
以下の手順は、Red Hat Satellite 6 の hammer コマンドラインツールを使用した例を示しています。組織には、例として ACME という名称を使用しています。この組織は、実際に使用する Satellite 6 の組織に置き換えてください。
この手順では、registry.redhat.io のコンテナーイメージにアクセスするために認証情報が必要です。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。詳しくは、Red Hat コンテナーレジストリーの認証 を参照してください。
手順
すべてのコンテナーイメージのリストを作成します。
sudo podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | sort > satellite_images sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-dashboard-rhel8 sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-rhel8 sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus$ sudo podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | sort > satellite_images $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-dashboard-rhel8 $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-rhel8 $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ceph をインストールして Ceph Dashboard を有効にする場合は、次の ose-prometheus コンテナーが必要です。
registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6 registry.redhat.io/openshift4/ose-prometheus:v4.6 registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6
registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6 registry.redhat.io/openshift4/ose-prometheus:v4.6 registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Satellite 6 の
hammerツールがインストールされているシステムにsatellite_imagesファイルをコピーします。あるいは、Hammer CLI ガイド に記載の手順に従って、アンダークラウドにhammerツールをインストールします。 以下の
hammerコマンドを実行して、実際の Satellite 組織に新規製品 (OSP Containers) を作成します。hammer product create \ --organization "ACME" \ --name "OSP Containers"
$ hammer product create \ --organization "ACME" \ --name "OSP Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow このカスタム製品に、イメージを保管します。
satellite_imagesファイルからオーバークラウドのコンテナーイメージを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ceph Storage 4 コンテナーイメージを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ceph Dashboard をインストールする場合は、
hammer repository createコマンドに--name rhceph-4-dashboard-rhel8を含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーイメージを同期します。
hammer product synchronize \ --organization "ACME" \ --name "OSP Containers"
$ hammer product synchronize \ --organization "ACME" \ --name "OSP Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Satellite Server が同期を完了するまで待ちます。
注記設定によっては、
hammerから Satellite Server のユーザー名およびパスワードが要求される場合があります。設定ファイルを使用して自動的にログインするようにhammerを設定することができます。詳しくは、Red Hat Satellite Hammer CLI ガイド の 認証 セクションを参照してください。-
お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように設定するかに大きく依存します。たとえば、ライフサイクルに
productionという名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューをproduction環境にプロモートします。詳しくは、Red Hat Satellite コンテンツ管理ガイドの コンテンツビューの管理 を参照してください。 baseイメージに使用可能なタグを確認します。hammer docker tag list --repository "base" \ --organization "ACME" \ --lifecycle-environment "production" \ --product "OSP Containers"
$ hammer docker tag list --repository "base" \ --organization "ACME" \ --lifecycle-environment "production" \ --product "OSP Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。
アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージを準備するデフォルトの環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。
sudo openstack tripleo container image prepare default \ --output-env-file containers-prepare-parameter.yaml
$ sudo openstack tripleo container image prepare default \ --output-env-file containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
--output-env-file: 環境ファイルの名前です。このファイルには、アンダークラウド用コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名はcontainers-prepare-parameter.yamlです。
-
containers-prepare-parameter.yamlファイルを編集して以下のパラメーターを変更します。-
push_destination: 選択したコンテナーイメージの管理手段に応じて、これをtrueまたはfalseに設定します。このパラメーターをfalseに設定すると、オーバークラウドノードはイメージを直接 Satellite からプルします。このパラメーターをtrueに設定すると、director はイメージを Satellite からアンダークラウドレジストリーにプルし、オーバークラウドはそのイメージをアンダークラウドレジストリーからプルします。 -
namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 443 です。 name_prefix: 接頭辞は Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。-
コンテンツビューを使用する場合、設定は
[org]-[environment]-[content view]-[product]-です。例:acme-production-myosp16-osp_containers-。 -
コンテンツビューを使用しない場合、設定は
[org]-[product]-です。例:acme-osp_containers-。
-
コンテンツビューを使用する場合、設定は
-
ceph_namespace、ceph_image、ceph_tag: Ceph Storage を使用する場合には、Ceph Storage コンテナーイメージの場所を定義するこれらの追加パラメーターを指定します。ceph_imageに Satellite 固有の接頭辞が追加された点に注意してください。この接頭辞は、name_prefixオプションと同じ値です。
-
Satellite 固有のパラメーターが含まれる環境ファイルの例を、以下に示します。
Red Hat SatelliteServer に保存されている特定のコンテナーイメージのバージョンを使用するには、tag のキーと値のペアを set ディクショナリー内の特定のバージョンに設定します。たとえば、16.2.2 イメージストリームを使用するには、set ディクショナリーに tag: 16.2.2 を設定します。
undercloud.conf 設定ファイルで containers-prepare-parameter.yaml 環境ファイルを定義する必要があります。定義しないと、アンダークラウドはデフォルト値を使用します。
container_images_file = /home/stack/containers-prepare-parameter.yaml
container_images_file = /home/stack/containers-prepare-parameter.yaml
第3章 コンテナーを使用したアンダークラウドのインストール リンクのコピーリンクがクリップボードにコピーされました!
本章では、コンテナーベースのアンダークラウドを作成し、最新の状態に維持する方法について説明します。
3.1. director の設定 リンクのコピーリンクがクリップボードにコピーされました!
director のインストールプロセスでは、director が stack ユーザーのホームディレクトリーから読み取る undercloud.conf 設定ファイルに、特定の設定が必要になります。設定のベースとするためにデフォルトのテンプレートをコピーするには、以下の手順を実施します。
手順
デフォルトのテンプレートを
stackユーザーのホームディレクトリーにコピーします。cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.conf
[stack@director ~]$ cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
undercloud.confファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。
3.2. director の設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下のリストで、undercloud.conf ファイルを設定するパラメーターについて説明します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。
少なくとも、コンテナーイメージの設定が含まれる環境ファイルに container_images_file パラメーターを設定する必要があります。このパラメーターに適切なファイルを正しく設定しないと、director は ContainerImagePrepare パラメーターからコンテナーイメージのルールセットを取得することや、ContainerImageRegistryCredentials パラメーターからコンテナーレジストリーの認証情報を取得することができなくなります。
デフォルト
undercloud.conf ファイルの [DEFAULT] セクションで定義されているパラメーターを以下に示します。
- additional_architectures
オーバークラウドがサポートする追加の (カーネル) アーキテクチャーのリスト。現在、オーバークラウドは、デフォルトの
x86_64アーキテクチャーに加えてppc64leアーキテクチャーをサポートしています。注記ppc64le のサポートを有効にする場合には、
ipxe_enabledをFalseに設定する必要もあります。複数の CPU アーキテクチャーを使用したアンダークラウドの設定の詳細については、Configuring a multiple CPU architecture overcloud を参照してください。- certificate_generation_ca
-
要求した証明書に署名する CA の
certmongerのニックネーム。generate_service_certificateパラメーターを設定した場合に限り、このオプションを使用します。localCA を選択する場合は、certmonger はローカルの CA 証明書を/etc/pki/ca-trust/source/anchors/cm-local-ca.pemに抽出し、証明書をトラストチェーンに追加します。 - clean_nodes
- デプロイメントを再実行する前とイントロスペクションの後にハードドライブを消去するかどうかを定義します。
- cleanup
-
一時的なファイルを削除します。デプロイメント中に使用される一時ファイルを保持するには、これを
Falseに設定します。一時ファイルは、エラーが発生した場合にデプロイメントのデバッグに役立ちます。 - container_cli
-
コンテナー管理用の CLI ツール。このパラメーターは、
podmanに設定したままにしてください。Red Hat Enterprise Linux 8.4 がサポートするのは、podmanだけです。 - container_healthcheck_disabled
-
コンテナー化されたサービスのヘルスチェックを無効にします。Red Hat は、ヘルスチェックを有効にし、このオプションを
falseに設定したままにすることを推奨します。 - container_images_file
コンテナーイメージ情報が含まれる heat 環境ファイル。このファイルには、以下のエントリーを含めることができます。
- 必要なすべてのコンテナーイメージのパラメーター
-
必要なイメージの準備を実施する
ContainerImagePrepareパラメーター。このパラメーターが含まれるファイルの名前は、通常containers-prepare-parameter.yamlです。
- container_insecure_registries
-
podmanが使用するセキュアではないレジストリーのリスト。プライベートコンテナーレジストリー等の別のソースからイメージをプルする場合には、このパラメーターを使用します。多くの場合、podmanは Red Hat Container Catalog または Satellite サーバー (アンダークラウドが Satellite に登録されている場合) のいずれかからコンテナーイメージをプルするための証明書を持ちます。 - container_registry_mirror
-
設定により
podmanが使用するオプションのregistry-mirror - custom_env_files
- アンダークラウドのインストールに追加する新たな環境ファイル
- deployment_user
-
アンダークラウドをインストールするユーザー。現在のデフォルトユーザー
stackを使用する場合には、このパラメーターを未設定のままにします。 - discovery_default_driver
-
自動的に登録されたノードのデフォルトドライバーを設定します。
enable_node_discoveryパラメーターを有効にし、enabled_hardware_typesのリストにドライバーを含める必要があります。 - enable_ironic、enable_ironic_inspector、enable_mistral、enable_nova、enable_tempest、enable_validations、enable_zaqar
-
director で有効にするコアサービスを定義します。これらのパラメーターは
trueに設定されたままにします。 - enable_node_discovery
-
introspection ramdisk を PXE ブートする不明なノードを自動的に登録します。新規ノードは、
fakeドライバーをデフォルトとして使用しますが、discovery_default_driverを設定して上書きすることもできます。また、イントロスペクションルールを使用して、新しく登録したノードにドライバーの情報を指定することもできます。 - enable_novajoin
-
アンダークラウドに
novajoinメタデータサービスをインストールするかどうかを定義します。 - enable_routed_networks
- ルーティングされたコントロールプレーンネットワークのサポートを有効にするかどうかを定義します。
- enable_swift_encryption
- 保存データの Swift 暗号化を有効にするかどうかを定義します。
- enable_telemetry
-
アンダークラウドに OpenStack Telemetry サービス (gnocchi、aodh、panko) をインストールするかどうかを定義します。Telemetry サービスを自動的にインストール/設定するには、
enable_telemetryパラメーターをtrueに設定します。デフォルト値はfalseで、アンダークラウド上の telemetry が無効になります。このパラメーターは、メトリックデータを消費する Red Hat CloudForms などの他の製品を使用する場合に必要です。
RBAC はすべてのコンポーネントでサポートされているわけではありません。Alarming サービス (aodh) と Gnocchi は、安全な RBAC ルールを考慮していません。
- enabled_hardware_types
- アンダークラウドで有効にするハードウェアタイプのリスト
- generate_service_certificate
-
アンダークラウドのインストール時に SSL/TLS 証明書を生成するかどうかを定義します。これは
undercloud_service_certificateパラメーターに使用します。アンダークラウドのインストールで、作成された証明書/etc/pki/tls/certs/undercloud-[undercloud_public_vip].pemを保存します。certificate_generation_caパラメーターで定義される CA はこの証明書に署名します。 - heat_container_image
- 使用する heat コンテナーイメージの URL。未設定のままにします。
- heat_native
-
heat-allを使用してホストベースのアンダークラウド設定を実行します。trueのままにします。 - hieradata_override
-
director に Puppet hieradata を設定するための
hieradataオーバーライドファイルへのパス。これにより、サービスに対してundercloud.confパラメーター以外のカスタム設定を行うことができます。設定すると、アンダークラウドのインストールでこのファイルが/etc/puppet/hieradataディレクトリーにコピーされ、階層の最初のファイルに設定されます。この機能の使用に関する詳細は、アンダークラウドへの hieradata の設定 を参照してください。 - inspection_extras
-
イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。このパラメーターを使用するには、イントロスペクションイメージに
python-hardwareまたはpython-hardware-detectパッケージが必要です。 - inspection_interface
-
ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。
LOCAL_INTERFACEでこのブリッジをアタッチします。これは、デフォルトのbr-ctlplaneのままにします。 - inspection_runbench
-
ノードイントロスペクション時に一連のベンチマークを実行します。ベンチマークを有効にするには、このパラメーターを
trueに設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。 - ipa_otp
-
IPA サーバーにアンダークラウドノードを登録するためのワンタイムパスワードを定義します。これは、
enable_novajoinが有効な場合に必要です。 - ipv6_address_mode
アンダークラウドのプロビジョニングネットワーク用の IPv6 アドレス設定モード。このパラメーターに設定できる値のリストを以下に示します。
- dhcpv6-stateless: ルーター広告 (RA) を使用するアドレス設定と DHCPv6 を使用するオプションの情報
- dhcpv6-stateful: DHCPv6 を使用するアドレス設定とオプションの情報
- ipxe_enabled
-
iPXE か標準の PXE のいずれを使用するか定義します。デフォルトは
trueで iPXE を有効化します。標準の PXE を使用するには、このパラメーターをfalseに設定します。PowerPC デプロイメント、またはハイブリッド PowerPC および x86 デプロイメントの場合は、この値をfalseに設定します。 - local_interface
director のプロビジョニング NIC 用に選択するインターフェイス。director は、DHCP および PXE ブートサービスにもこのデバイスを使用します。この値を選択したデバイスに変更します。接続されているデバイスを確認するには、
ip addrコマンドを使用します。ip addrコマンドの出力結果の例を、以下に示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、外部 NIC は
em0を使用し、プロビジョニング NIC は、現在設定されていないem1を使用します。この場合は、local_interfaceをem1に設定します。この設定スクリプトにより、このインターフェイスがinspection_interfaceパラメーターで定義したカスタムのブリッジにアタッチされます。- local_ip
director のプロビジョニング NIC 用に定義する IP アドレス。director は、DHCP および PXE ブートサービスにもこの IP アドレスを使用します。この IP アドレスが環境内の既存の IP アドレスまたはサブネットと競合するなどの理由により、プロビジョニングネットワークに別のサブネットを使用する場合以外は、この値をデフォルトの
192.168.24.1/24のままにします。IPv6 の場合、ステートフル接続とステートレス接続の両方をサポートするには、ローカル IP アドレス接頭辞接頭辞の長さを
/64にする必要があります。- local_mtu
-
local_interfaceに使用する最大伝送単位 (MTU)。アンダークラウドでは 1500 以下にします。 - local_subnet
-
PXE ブートと DHCP インターフェイスに使用するローカルサブネット。
local_ipアドレスがこのサブネットに含まれている必要があります。デフォルトはctlplane-subnetです。 - net_config_override
-
ネットワーク設定のオーバーライドテンプレートへのパス。このパラメーターを設定すると、アンダークラウドは JSON または YAML 形式のテンプレートを使用して、
os-net-configでネットワークを設定し、undercloud.confで設定されたネットワークパラメーターを無視します。ボンディングを設定する場合、またはインターフェイスにオプションを追加する場合に、このパラメーターを使用します。アンダークラウドネットワークインターフェイスのカスタマイズの詳細については、Configuring undercloud network interfaces を参照してください。 - networks_file
-
heatをオーバーライドするネットワークファイル - output_dir
- 状態、処理された heat テンプレート、および Ansible デプロイメントファイルを出力するディレクトリー
- overcloud_domain_name
オーバークラウドをデプロイする際に使用する DNS ドメイン名
注記オーバークラウドを設定する際に、
CloudDomainにこのパラメーターと同じ値を設定する必要があります。オーバークラウドを設定する際に、環境ファイルでこのパラメーターを設定します。- roles_file
- アンダークラウドのインストールで、デフォルトロールファイルを上書きするのに使用するロールファイル。director のインストールにデフォルトのロールファイルが使用されるように、このパラメーターは未設定のままにすることを強く推奨します。
- scheduler_max_attempts
- スケジューラーがインスタンスのデプロイを試行する最大回数。スケジューリング時に競合状態にならないように、この値を 1 度にデプロイする予定のベアメタルノードの数以上に指定する必要があります。
- service_principal
- この証明書を使用するサービスの Kerberos プリンシパル。FreeIPA など CA で Kerberos プリンシパルが必要な場合に限り、このパラメーターを使用します。
- subnets
-
プロビジョニングおよびイントロスペクション用のルーティングネットワークのサブネットのリスト。デフォルト値に含まれるのは、
ctlplane-subnetサブネットのみです。詳細は、サブネット を参照してください。 - templates
- 上書きする heat テンプレートファイル
- undercloud_admin_host
SSL/TLS 経由の director の管理 API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは
/32ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。undercloud_admin_hostがlocal_ipと同じ IP ネットワークにない場合は、Undercloud の管理 API がリッスンするインターフェイスにControlVirtualInterfaceパラメーターを設定する必要があります。デフォルトでは、管理 API はbr-ctlplaneインターフェイスでリッスンします。ControlVirtualInterfaceパラメーターをカスタム環境ファイルに設定し、custom_env_filesパラメーターを設定して、undercloud.confファイルにカスタム環境ファイルを含めます。アンダークラウドネットワークインターフェイスのカスタマイズについての詳細は、Configuring undercloud network interfaces を参照してください。
- undercloud_debug
-
アンダークラウドサービスのログレベルを
DEBUGに設定します。DEBUGログレベルを有効にするには、この値をtrueに設定します。 - undercloud_enable_selinux
-
デプロイメント時に、SELinux を有効または無効にします。問題をデバッグする場合以外は、この値を
trueに設定したままにすることを強く推奨します。 - undercloud_hostname
- アンダークラウドの完全修飾ホスト名を定義します。本パラメーターを指定すると、アンダークラウドのインストールでホスト名すべてに設定されます。指定しないと、アンダークラウドは現在のホスト名を使用しますが、システムのホスト名すべてを適切に設定しておく必要があります。
- undercloud_log_file
-
アンダークラウドのインストールログおよびアップグレードログを保管するログファイルへのパス。デフォルトでは、ログファイルはホームディレクトリー内の
install-undercloud.logです。たとえば、/home/stack/install-undercloud.logのようになります。 - undercloud_nameservers
- アンダークラウドのホスト名解決に使用する DNS ネームサーバーのリスト
- undercloud_ntp_servers
- アンダークラウドの日付と時刻を同期できるようにする Network Time Protocol サーバーのリスト
- undercloud_public_host
SSL/TLS 経由の director のパブリック API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは
/32ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。undercloud_public_hostがlocal_ipと同じ IP ネットワークにない場合は、PublicVirtualInterfaceパラメーターを、アンダークラウド上のパブリック API がリッスンする公開インターフェイスに設定する必要があります。デフォルトでは、パブリック API はbr-ctlplaneインターフェイスでリッスンします。カスタム環境ファイルにPublicVirtualInterfaceパラメーターを設定し、custom_env_filesパラメーターを設定して、undercloud.confファイルにカスタム環境ファイルを含めます。アンダークラウドネットワークインターフェイスのカスタマイズについての詳細は、Configuring undercloud network interfaces を参照してください。
- undercloud_service_certificate
- OpenStack SSL/TLS 通信の証明書の場所とファイル名。理想的には、信頼できる認証局から、この証明書を取得します。それ以外の場合は、独自の自己署名の証明書を生成します。
- undercloud_timezone
- アンダークラウド用ホストのタイムゾーン。タイムゾーンを指定しなければ、director は既存のタイムゾーン設定を使用します。
- undercloud_update_packages
- アンダークラウドのインストール時にパッケージを更新するかどうかを定義します。
サブネット
undercloud.conf ファイルには、各プロビジョニングサブネットの名前が付いたセクションがあります。たとえば、ctlplane-subnet という名前のサブネットを作成するには、undercloud.conf ファイルで以下のような設定を使用します。
プロビジョニングネットワークは、環境に応じて、必要なだけ指定することができます。
director がサブネットを作成した後、director はサブネットの IP アドレスを変更することはできません。
- cidr
-
オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの
neutronサービスが管理するプロビジョニングネットワークです。プロビジョニングネットワークに別のサブネットを使用しない限り、この値はデフォルト (192.168.24.0/24) のままにします。 - masquerade
外部アクセスのために、
cidrで定義したネットワークをマスカレードするかどうかを定義します。このパラメーターにより、director 経由で外部アクセスすることができるように、プロビジョニングネットワークにネットワークアドレス変換 (NAT) のメカニズムが提供されます。注記director 設定は、適切な
sysctlカーネルパラメーターを使用して IP フォワーディングも自動的に有効化します。- dhcp_start、dhcp_end
オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。サブネットに指定されていない場合、director は
local_ip、gateway、undercloud_admin_host、undercloud_public_host、およびInspection_iprangeパラメーターに設定された値をサブネットの完全な IP 範囲から削除して、割り当てプールを決定します。開始アドレスと終了アドレスのペアのリストを指定することで、アンダークラウドのコントロールプレーンのサブネットに非連続割り当てプールを設定することができます。または、
dhcp_excludeオプションを使用して、IP アドレス範囲内の IP アドレスを除外することもできます。たとえば、次の設定は両方とも割り当てプール172.20.0.100-172.20.0.150と172.20.0.200-172.20.0.250を作成します。オプション 1
dhcp_start = 172.20.0.100,172.20.0.200 dhcp_end = 172.20.0.150,172.20.0.250
dhcp_start = 172.20.0.100,172.20.0.200 dhcp_end = 172.20.0.150,172.20.0.250Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション 2
dhcp_start = 172.20.0.100 dhcp_end = 172.20.0.250 dhcp_exclude = 172.20.0.151-172.20.0.199
dhcp_start = 172.20.0.100 dhcp_end = 172.20.0.250 dhcp_exclude = 172.20.0.151-172.20.0.199Copy to Clipboard Copied! Toggle word wrap Toggle overflow - dhcp_exclude
DHCP 割り当て範囲で除外する IP アドレスたとえば、次の設定では、IP アドレス
172.20.0.105と IP アドレス範囲172.20.0.210-172.20.0.219が除外されます。dhcp_exclude = 172.20.0.105,172.20.0.210-172.20.0.219
dhcp_exclude = 172.20.0.105,172.20.0.210-172.20.0.219Copy to Clipboard Copied! Toggle word wrap Toggle overflow - dns_nameservers
-
サブネットに固有の DNS ネームサーバー。サブネットにネームサーバーが定義されていない場合には、サブネットは
undercloud_nameserversパラメーターで定義されるネームサーバーを使用します。 - gateway
-
オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または直接外部ゲートウェイを使用する場合以外は、この値はデフォルト (
192.168.24.1) のままにします。 - host_routes
-
このネットワーク上のオーバークラウドインスタンス用の neutron が管理するサブネットのホストルート。このパラメーターにより、アンダークラウド上の
local_subnetのホストルートも設定されます。 - inspection_iprange
-
検査プロセス中に使用するこのネットワーク上のノードの一時的な IP 範囲。この範囲は、
dhcp_startとdhcp_endで定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。
これらのパラメーターの値は、設定に応じて変更してください。完了したら、ファイルを保存します。
3.3. director のインストール リンクのコピーリンクがクリップボードにコピーされました!
director をインストールして基本的なインストール後タスクを行うには、以下の手順を実施します。
手順
以下のコマンドを実行して、アンダークラウドに director をインストールします。
openstack undercloud install
[stack@director ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、director の設定スクリプトが起動します。director は追加のパッケージをインストールし、
undercloud.confの設定に従ってサービスを設定し、すべての RHOSP サービスコンテナーを起動します。このスクリプトは、完了までに数分かかります。スクリプトにより、2 つのファイルが生成されます。
-
undercloud-passwords.conf: director サービスの全パスワードリスト -
stackrc: director コマンドラインツールへアクセスできるようにする初期化変数セット
-
RHOSP サービスコンテナーが実行中であることを確認します。
sudo podman ps -a --format "{{.Names}} {{.Status}}"[stack@director ~]$ sudo podman ps -a --format "{{.Names}} {{.Status}}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンド出力は、RHOSP サービスコンテナーが実行中 (
Up) であることを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow stackユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。
(undercloud) [stack@director ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow
director のインストールが完了しました。これで、director コマンドラインツールが使用できるようになりました。
3.4. コンテナー化されたアンダークラウドのマイナー更新の実施 リンクのコピーリンクがクリップボードにコピーされました!
director では、アンダークラウドノード上の主要なパッケージを更新するためのコマンドが提供されています。Director を使用して、RHOSP 環境の現在のバージョン内でマイナー更新を実行します。
手順
-
アンダークラウドノードで、
stackユーザーとしてログインします。 stackrcファイルを取得します。source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow dnfupdateコマンドを使用して director メインパッケージを更新します。sudo dnf update -y python3-tripleoclient* tripleo-ansible ansible
$ sudo dnf update -y python3-tripleoclient* tripleo-ansible ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow openstack undercloudupgradeコマンドを使用してアンダークラウド環境を更新します。openstack undercloud upgrade
$ openstack undercloud upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - アンダークラウドの更新プロセスが完了するまで待ちます。
アンダークラウドをリブートして、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートするまで待ちます。
第4章 コンテナーベースのオーバークラウドのデプロイおよび更新 リンクのコピーリンクがクリップボードにコピーされました!
本章では、コンテナーベースのオーバークラウドを作成し、最新の状態に維持する方法について説明します。
4.1. オーバークラウドのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
最小設定のオーバークラウドをデプロイする方法を、以下の手順で説明します。デプロイの結果、2 つのノードを持つ基本的なオーバークラウド (1 つのコントローラーノードおよび 1 つのコンピュートノード) が得られます。
手順
stackrcファイルを取得します。source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow deployコマンドを実行し、オーバークラウドイメージの場所を定義したファイル (通常はovercloud_images.yaml) を含めます。(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/overcloud_images.yaml \ --ntp-server pool.ntp.org
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/overcloud_images.yaml \ --ntp-server pool.ntp.orgCopy to Clipboard Copied! Toggle word wrap Toggle overflow - オーバークラウドがデプロイメントを完了するまで待ちます。
4.2. オーバークラウドの更新 リンクのコピーリンクがクリップボードにコピーされました!
コンテナー化されたオーバークラウドの更新に関する情報は、Keeping Red Hat OpenStack Platform Updated を参照してください。
第5章 コンテナー化されたサービスの操作 リンクのコピーリンクがクリップボードにコピーされました!
本章では、コンテナーを管理するコマンドの例および OpenStack Platform コンテナーに関するトラブルシューティング方法について説明します。
5.1. コンテナー化されたサービスの管理 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) では、アンダークラウドおよびオーバークラウドノード上のコンテナー内でサービスが実行されます。特定の状況では、1 つのホスト上で個別のサービスを制御する必要がある場合があります。本項では、コンテナー化されたサービスを管理するためにノード上で実行することのできる、一般的なコマンドについて説明します。
コンテナーとイメージのリスト表示
実行中のコンテナーをリスト表示するには、以下のコマンドを実行します。
sudo podman ps
$ sudo podman ps
コマンド出力に停止中またはエラーの発生したコンテナーを含めるには、コマンドに --all オプションを追加します。
sudo podman ps --all
$ sudo podman ps --all
コンテナーイメージをリスト表示するには、以下のコマンドを実行します。
sudo podman images
$ sudo podman images
コンテナーの属性の確認
コンテナーまたはコンテナーイメージのプロパティーを表示するには、podman inspect コマンドを使用します。たとえば、keystone コンテナーを検査するには、以下のコマンドを実行します。
sudo podman inspect keystone
$ sudo podman inspect keystone
Systemd サービスを使用したコンテナーの管理
以前のバージョンの OpenStack Platform では、コンテナーは Docker およびそのデーモンで管理されていました。OpenStack Platform 16 では、Systemd サービスインターフェイスでコンテナーのライフサイクルが管理されます。それぞれのコンテナーはサービスであり、Systemd コマンドを実行して各コンテナーに関する特定の操作を実施します。
Systemd は再起動ポリシーを適用するため、Podman CLI を使用してコンテナーを停止、起動、および再起動することは推奨されません。その代わりに、Systemd サービスコマンドを使用してください。
コンテナーのステータスを確認するには、systemctl status コマンドを実行します。
コンテナーを停止するには、systemctl stop コマンドを実行します。
sudo systemctl stop tripleo_keystone
$ sudo systemctl stop tripleo_keystone
コンテナーを起動するには、systemctl start コマンドを実行します。
sudo systemctl start tripleo_keystone
$ sudo systemctl start tripleo_keystone
コンテナーを再起動するには、systemctl restart コマンドを実行します。
sudo systemctl restart tripleo_keystone
$ sudo systemctl restart tripleo_keystone
コンテナーステータスを監視するデーモンはないので、以下の状況では Systemd はほとんどのコンテナーを自動的に再起動します。
-
podman stopコマンドの実行など、明瞭な終了コードまたはシグナル - 起動後に podman コンテナーがクラッシュするなど、不明瞭な終了コード
- 不明瞭なシグナル
- コンテナーの起動に 1 分 30 秒以上かかった場合のタイムアウト
Systemd サービスに関する詳しい情報は、systemd.service のドキュメント を参照してください。
コンテナー内のサービス設定ファイルに加えた変更は、コンテナーの再起動後には元に戻ります。これは、コンテナーがノードのローカルファイルシステム上の /var/lib/config-data/puppet-generated/ にあるファイルに基づいてサービス設定を再生成するためです。たとえば、keystone コンテナー内の /etc/keystone/keystone.conf を編集してコンテナーを再起動すると、そのコンテナーはノードのローカルシステム上にある /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf を使用して設定を再生成します。再起動前にコンテナー内で加えられた変更は、この設定によって上書きされます。
Systemd タイマーを使用した podman コンテナーの監視
Systemd タイマーインターフェイスは、コンテナーのヘルスチェックを管理します。各コンテナーのタイマーがサービスユニットを実行し、そのユニットがヘルスチェックスクリプトを実行します。
すべての OpenStack Platform コンテナーのタイマーをリスト表示するには、systemctl list-timers コマンドを実行し、出力を tripleo が含まれる行に限定します。
特定のコンテナータイマーのステータスを確認するには、healthcheck サービスに対して systemctl status コマンドを実行します。
コンテナータイマーを停止、起動、再起動、およびコンテナータイマーのステータスを表示するには、.timer Systemd リソースに対して該当する systemctl コマンドを実行します。たとえば、tripleo_keystone_healthcheck.timer リソースのステータスを確認するには、以下のコマンドを実行します。
sudo systemctl status tripleo_keystone_healthcheck.timer ● tripleo_keystone_healthcheck.timer - keystone container healthcheck Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.timer; enabled; vendor preset: disabled) Active: active (waiting) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
$ sudo systemctl status tripleo_keystone_healthcheck.timer
● tripleo_keystone_healthcheck.timer - keystone container healthcheck
Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
healthcheck サービスは無効だが、そのサービスのタイマーが存在し有効になっている場合には、チェックは現在タイムアウトしているが、タイマーに従って実行されることを意味します。チェックを手動で開始することもできます。
podman ps コマンドは、コンテナーのヘルスステータスを表示しません。
コンテナーログの確認
OpenStack Platform 16 では、新たなロギングディレクトリー /var/log/containers/stdout が導入されています。ここには、すべてのコンテナーの標準出力 (stdout) と標準エラー (stderr) が、コンテナーごとに 1 つのファイルに統合されて保存されます。
paunch および container-puppet.py スクリプトは、出力を /var/log/containers/stdout ディレクトリーにプッシュするように podman コンテナーを設定します。これにより、container-puppet-* コンテナー等の削除されたコンテナーを含め、すべてのログのコレクションが作成されます。
また、ホストはこのディレクトリーにログローテーションを適用し、大きな容量のファイルがディスク容量を消費する問題を防ぎます。
コンテナーが置き換えられた場合には、新しいコンテナーは同じログファイルにログを出力します。podman はコンテナー ID ではなくコンテナー名を使用するためです。
podman logs コマンドを使用して、コンテナー化されたサービスのログを確認することもできます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを実行します。
sudo podman logs keystone
$ sudo podman logs keystone
コンテナーへのアクセス
コンテナー化されたサービスのシェルに入るには、podman exec コマンドを使用して /bin/bash を起動します。たとえば、keystone コンテナーのシェルに入るには、以下のコマンドを実行します。
sudo podman exec -it keystone /bin/bash
$ sudo podman exec -it keystone /bin/bash
root ユーザーとして keystone コンテナーのシェルに入るには、以下のコマンドを実行します。
sudo podman exec --user 0 -it <NAME OR ID> /bin/bash
$ sudo podman exec --user 0 -it <NAME OR ID> /bin/bash
コンテナーから出るには、以下のコマンドを実行します。
exit
# exit
5.2. コンテナー化されたサービスに関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドのデプロイメント中またはデプロイメント後にコンテナー化されたサービスでエラーが発生した場合には、以下の推奨事項に従って、エラーの根本的な原因を特定してください。
これらのコマンドを実行する前には、オーバークラウドノードにログイン済みであることを確認し、これらのコマンドをアンダークラウドで実行しないようにしてください。
コンテナーログの確認
各コンテナーは、主要プロセスからの標準出力を保持します。この出力はログとして機能し、コンテナー実行時に実際に何が発生したのかを特定するのに役立ちます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを使用します。
sudo podman logs keystone
$ sudo podman logs keystone
大半の場合は、このログにコンテナーのエラーの原因が記載されています。
コンテナーの検査
状況によっては、コンテナーに関する情報を検証する必要がある場合があります。たとえば、以下のコマンドを使用して keystone コンテナーのデータを確認します。
sudo podman inspect keystone
$ sudo podman inspect keystone
これにより、ローレベルの設定データが含まれた JSON オブジェクトが提供されます。その出力を jq コマンドにパイプで渡して、特定のデータを解析することが可能です。たとえば、keystone コンテナーのマウントを確認するには、以下のコマンドを実行します。
sudo podman inspect keystone | jq .[0].Mounts
$ sudo podman inspect keystone | jq .[0].Mounts
--format オプションを使用して、データを単一行に解析することもできます。これは、コンテナーデータのセットに対してコマンドを実行する場合に役立ちます。たとえば、keystone コンテナーを実行するのに使用するオプションを再生成するには、以下のように inspect コマンドに --format オプションを指定して実行します。
sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
$ sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
--format オプションは、Go 構文を使用してクエリーを作成します。
これらのオプションを podman run コマンドと共に使用して、トラブルシューティング目的のコンテナーを再度作成します。
OPTIONS=$( sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
sudo podman run --rm $OPTIONS /bin/bash
$ OPTIONS=$( sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo podman run --rm $OPTIONS /bin/bash
コンテナー内でのコマンドの実行
状況によっては、特定の Bash コマンドでコンテナー内の情報を取得する必要がある場合があります。このような場合には、以下の podman コマンドを使用して、稼働中のコンテナー内でコマンドを実行します。たとえば、keystone コンテナーで次のコマンドを実行します。
sudo podman exec -ti keystone <COMMAND>
$ sudo podman exec -ti keystone <COMMAND>
-ti オプションを指定すると、コマンドは対話式の擬似ターミナルで実行されます。
<COMMAND> は必要なコマンドに置き換えます。たとえば、各コンテナーには、サービスの接続を確認するためのヘルスチェックスクリプトがあります。keystone にヘルスチェックスクリプトを実行するには、以下のコマンドを実行します。
sudo podman exec -ti keystone /openstack/healthcheck
$ sudo podman exec -ti keystone /openstack/healthcheck
コンテナーのシェルにアクセスするには、コマンドとして /bin/bash を使用して podman exec を実行します。
sudo podman exec -ti keystone /bin/bash
$ sudo podman exec -ti keystone /bin/bash
コンテナーのエクスポート
コンテナーに障害が発生した場合には、ファイルの内容を詳細に調べる必要があります。この場合は、コンテナーの全ファイルシステムを tar アーカイブとしてエクスポートすることができます。たとえば、keystone コンテナーのファイルシステムをエクスポートするには、以下のコマンドを実行します。
sudo podman export keystone -o keystone.tar
$ sudo podman export keystone -o keystone.tar
このコマンドにより keystone.tar アーカイブが作成されます。これを抽出して、調べることができます。
第6章 Systemd サービスとコンテナー化されたサービスの比較 リンクのコピーリンクがクリップボードにコピーされました!
本章では、コンテナー化されたサービスと Systemd サービスの相違点を示す参考資料を提供します。
6.1. Systemd サービスとコンテナー化されたサービスの比較 リンクのコピーリンクがクリップボードにコピーされました!
Systemd ベースのサービスと、Systemd サービスで制御する podman コンテナー間の相関を以下の表に示します。
| コンポーネント | Systemd サービス | コンテナー |
|---|---|---|
| OpenStack Image Storage (glance) |
|
|
| HAProxy |
|
|
| OpenStack Orchestration (heat) |
|
|
| OpenStack Bare Metal (ironic) |
|
|
| Keepalived |
|
|
| OpenStack Identity (keystone) |
|
|
| Logrotate |
|
|
| Memcached |
|
|
| OpenStack Workflow (mistral) |
|
|
| MySQL |
|
|
| OpenStack Networking (neutron) |
|
|
| OpenStack Compute (nova) |
|
|
| RabbitMQ |
|
|
| OpenStack Object Storage (swift) |
|
|
| OpenStack Messaging (zaqar) |
|
|
| Aodh |
|
|
| Gnocchi |
|
|
| Ceilometer |
|
|
6.2. Systemd のログの場所とコンテナーベースのログの場所の比較 リンクのコピーリンクがクリップボードにコピーされました!
Systemd ベースの OpenStack ログと対応するコンテナーベースの等価ログを、以下の表に示します。すべてのコンテナーベースのログは物理ホストにマウントされたディレクトリーに保管されるので、物理ホストからログにアクセスすることができます。
| OpenStack サービス | Systemd サービスのログ | コンテナーログ |
|---|---|---|
| aodh |
|
|
| ceilometer |
|
|
| cinder |
|
|
| glance |
|
|
| gnocchi |
|
|
| heat |
|
|
| horizon |
|
|
| keystone |
|
|
| databases |
|
|
| neutron |
|
|
| nova |
|
|
| panko |
| |
| rabbitmq |
|
|
| redis |
|
|
| swift |
|
|
6.3. Systemd の設定とコンテナーベースの設定の比較 リンクのコピーリンクがクリップボードにコピーされました!
Systemd ベースの OpenStack 設定と対応するコンテナーベースの等価設定を、以下の表に示します。すべてのコンテナーベースの設定の場所は物理ホストで利用可能で、コンテナーにマウントされます。また、それぞれの該当コンテナー内の設定にマージされます (kolla により)。
| OpenStack サービス | Systemd サービスの設定 | コンテナーの設定 |
|---|---|---|
| aodh |
|
|
| ceilometer |
|
|
| cinder |
|
|
| glance |
|
|
| gnocchi |
|
|
| haproxy |
|
|
| heat |
|
|
| horizon |
|
|
| keystone |
|
|
| databases |
|
|
| neutron |
|
|
| nova |
|
|
| panko |
| |
| rabbitmq |
|
|
| redis |
|
|
| swift |
|
|