トップ > Red Hat OpenShift > OpenShift 4.2におけるネットワーク制限環境下でのインストール

OpenShift 4.2におけるネットワーク制限環境下でのインストール

Red Hat OpenShift Red Hat OpenShift Container Platform

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 今回はOpenShift 4.2で追加された「ネットワークが制限された環境でのインストール」について説明します。

説明に使用する環境構成は以前に書いた記事と同様ですので、合わせてこちらもご参照ください。

rheb.hatenablog.com

本記事の章立てはこのようになります。

（2019/12/7追記。項目にOperatorの利用を追加）

  • ネットワークが制限された環境でのインストール概要
  • 検証環境解説
  • インストール手順解説
  • レジストリーホストの構築
  • UPIインストールの実行
  • アップグレード
  • Operatorの利用
  • 参考：Podmanコマンド

ネットワークが制限された環境でのインストール概要

ネットワークが制限された環境は、英語ドキュメントではrestricted networkと表記されています。 他の呼び方として、DisconnectedやAir-gappedなどと呼ばれることもあります。 今回取り扱う内容においては、いずれもOpenShiftクラスターがインターネットへの通信ができない環境を指す、とご理解の上読み進めてください。

OpenShift 4はインストールの要件としてインターネットへの接続が必須となっています。 しかしながら、特にオンプレミスの環境では強固に制限されたネットワーク環境があることが多く、またそこへOpenShiftクラスターを展開したいという要望もあると思います。 今回ご紹介する方法により、OpneShiftクラスターをネットワークが制限された環境への導入が可能となります。

[図1]

ネットワーク制限環境下のインストール
ネットワーク制限環境下のインストール

注意点としては、本来のOpenShift 4で提供できる下記のような機能が使えなくなることをご理解ください

  • Over-The-Air Update
  • cloud.redhat.comへのクラスターの自動登録、モニタリング（Telemetry）
  • Operator HubからのOperatorインストール
  • インターネットのソースやイメージを利用したデプロイ
  • etc...

検証環境解説

インストール手順の説明の前に、今回の説明に使用する検証環境の説明を行います。 下記の図は4.1 UPIインストール記事からお馴染みの図となりますが、今回はネットワークの制限をより明確にしています。 また、ミラーされたイメージをホストするためのレジストリーホストを追加しています。

[図2]

検証環境ネットワーク構成図
検証環境ネットワーク構成図

ネットワークの通信可否は下記のようになっており、検証用ネットワークからは社内ネットワーク側には通信ができません。

  • 社内ネットワーク：インターネット通信可能
  • 検証用ネットワーク：インターネット通信不可

また、今回の構成においてOpenShiftクラスターへのアクセスは社内ネットワークからとし、片方向からのみのアクセスを許可する構成となっています。

[図3]

ネットワーク通信詳細
ネットワーク通信詳細

踏み台サーバーのfirewalldは下記のように変更します。

# firewall-cmd --zone=block --add-rich-rule='rule family="ipv4" destination address="172.16.0.1/32" accept' --permanent
# firewall-cmd --zone=block --add-rich-rule='rule family="ipv4" port port=67 protocol=udp accept' --permanent
# firewall-cmd --change-zone=ens224 --zone=block --permanent
# firewall-cmd --reload
  • 検証用ネットワークからのDHCPパケットに応答するためにUDP:67のアクセスは許可
  • 検証用ネットワークからの各種通信（DNS/Web/LB）に応答するために、172.16.0.1/32のアクセスは許可

インストール手順解説

今回もベアメタルへのUPIインストールをベースに説明していきます。 該当するドキュメントは下記です。

インストール 4.2 | Red Hat Customer Portal

  • 第9章 ネットワークが制限されたインストール
    • 9.1. 接続するネットワークが制限された環境でのインストール用のミラーレジストリーの作成
    • 9.3. ネットワークが制限された環境でのクラスターのベアメタルへのインストール

※注意）公式ドキュメント上のbationホストは、本文中ではレジストリーホストを指します。*1

また、下記のblog.openshift.com 記事も参考にし、ドキュメントに足りない情報を付け加えています。

blog.openshift.com

作業項目が多いので、まずは下記の作業サマリをご確認ください。

インストール作業サマリ

  • レジストリーホストの構築
    1. ミラーレジストリーの作成
    2. ミラーレジストリーのプルシークレットの作成
    3. イメージリポジトリーのミラーリング
  • UPIインストールの実行（4.1/4.2 UPIと同様）
    1. インストール設定ファイルの手動作成（ネットワーク制限用設定を追加 ※新規設定）
    2. インストールの実行
  • インストール後の作業
    1. エラー表示への対処
    2. Samples Operatorの設定
    3. Cluster Managerの登録

UPIインストール作業自体は4.1/4.2と同様ですが、前後に独自の作業が追加となっています。 次の項目からが実際の作業となります。

レジストリーホストの構築

基本的にはドキュメント通りの作業となります。必要最低限の前提条件は下記です。

  • 前提条件
    • ocコマンドがインストールされていること（レジストリーホスト用のRHELサーバーが既にある前提）
    • レジストリーホストのホスト名がDNSで名前解決できること

1. ミラーレジストリーの作成

ここでの作業の目的は、podmanコマンドを使ってmirror-registryコンテナを起動することです。 また、コンテナ起動時に必要な証明書の作成も行います。 前提条件は下記の通りです。

  • 前提条件
    • レジストリーホストとして使用する Red Hat Enterprise Linux (RHEL) サーバーがネットワーク上にある
    • レジストリーホストはインターネットにアクセスできる。

今回はレジストリーホストにRHEL8を利用しています*2

1.1 作業に必要なパッケージをインストールします
  • インストールパッケージ
    • podman: レジストリーを実行する際に使用するコンテナーパッケージを提供します
    • httpd-tools: ユーザーの作成に使用する htpasswd ユーティリティーを提供します
# yum -y install podman httpd-tools
1.2 レジストリーのフォルダーを作成します。
# mkdir -p /opt/registry/{auth,certs,data}
# tree /opt/registry/
/opt/registry/
├── auth
├── certs
└── data

3 directories, 0 files

これらのフォルダーはレジストリーコンテナー内にマウントされます。

1.3 証明書を作成します

下記は自己署名の証明書生成の例です*3

# cd /opt/registry/certs
# openssl req -newkey rsa:4096 -nodes -sha256 -keyout domain.key -x509 -days 365 -out domain.crt

下記は証明書作成時の情報入力のサンプルです。

  • Country Name (2 letter code) [XX]:JP
  • State or Province Name (full name) :Fukuoka
  • Locality Name (eg, city) [Default City]:Fukuoka
  • Organization Name (eg, company) [Default Company Ltd]:[改行]
  • Organizational Unit Name (eg, section) :[改行]
  • Common Name (eg, your name or your server's hostname) :registry.test.example.local
  • Email Address :[改行]

※ Common NameはFQDNで指定します

1.4 bcrpt 形式を使用するレジストリー用のユーザー名およびパスワードを生成します。

下記は、/opt/registry/auth/htpasswdにユーザー名:user、パスワード:userのユーザー作成例です。

# htpasswd -bBc /opt/registry/auth/htpasswd user user
Adding password for user user
1.5 レジストリーに必要なポートを開きます

ドキュメントの通りにinternalとpublicゾーンに設定を行うため、NICのゾーン変更も合わせて行います。 デフォルト状態からの設定変更についてのみ記載しています。不要なサービスなどは個々の環境に合わせて調整してください。

# firewall-cmd --add-port=5000/tcp --zone=internal --permanent
# firewall-cmd --add-port=5000/tcp --zone=public   --permanent
# firewall-cmd --change-zone=ens224 --zone=internal --permanent
# firewall-cmd --change-zone=ens192 --zone=public --permanent
# firewall-cmd --reload

ポートの開放後は下記のような状態になります

  • internalゾーン
# firewall-cmd --list-all --zone=internal 
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens224
  sources: 
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports: 5000/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
  • publicゾーン
# firewall-cmd --list-all --zone=public 
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 5000/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
1.6 信頼された証明書の一覧に自己署名証明書を追加します

システム全体で使用されるトラストストアに作成した自己署名証明書を追加し、この後の作業で証明書が信頼された物として実行できるようにします。*4

# cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust
1.7 レジストリーをホストする mirror-registry コンテナーを作成します。

＜参考/注意＞ ここで指定するパラメーターに間違いや、環境不備などがあるとコンテナが正常に起動しません。 podmanコマンドを使用したコンテナの簡単な実行/リカバリー方法について記事末尾にまとめましたので、詳細はそちらを参照ください。

下記は待ち受けポートをtcp:5000 で指定し、コンテナをバックグラウンド起動するコマンド例です。*5 この時点でdocker.ioからイメージをダウンロードするので、インターネットへアクセスができる必要があります。

# podman run --name mirror-registry -p 5000:5000 \
     -v /opt/registry/data:/var/lib/registry:z \
     -v /opt/registry/auth:/auth:z \
     -e "REGISTRY_AUTH=htpasswd" \
     -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
     -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
     -v /opt/registry/certs:/certs:z \
     -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
     -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
     -d docker.io/library/registry:2

下記のコマンドを実行し てコンテナが正常に起動しているか確認します

# podman ps -a
CONTAINER ID  IMAGE                         COMMAND               CREATED        STATUS            PORTS                   NAMES
af99e9675c96  docker.io/library/registry:2  /entrypoint.sh /e...  5 seconds ago  Up 5 seconds ago  0.0.0.0:5000->5000/tcp  mirror-registry

STATUS がUpで、PORTS に指定したポート番号が表示されていることを確認します

1.8 レジストリーが使用できることを確認します

下記のコマンドを実行します。合わせてfirewallの設定を確認する場合は、別のホストから実行してください。

# curl -u user:user -k https://registry.test.example.local:5000/v2/_catalog

下記のように空のリポジトリの情報が表示されれば、正常にレジストリーコンテナが起動しています。　

{"repositories":[]}

2. ミラーレジストリーのプルシークレットの作成

ここでは、起動したレジストリーコンテナに登録したユーザー名/パスワードで接続を行い、プルシークレットを入手します。 使用するユーザー名/パスワードは、 1.4で作成した物を使用します。

# podman login --authfile ~/pullsecret_config.json registry.test.example.local:5000
Authenticating with existing credentials...
Existing credentials are invalid, please enter valid username and password
Username: user
Password: 
Login Succeeded!

入手したプルシークレットの中身を確認します。

# cat ~/pullsecret_config.json
{
    "auths": {
        "registry.test.example.local:5000": {
            "auth": "dXNlcjp1c2Vy"
        }
    }

なお、authに指定されているパラメーターは、ユーザー名:パスワードをbase64でエンコードした値になっています。

# echo -n 'user:user' | base64 -w0
dXNlcjp1c2Vy
2.1 追加作業

ドキュメントには記載されていませんが、追加で必要な作業を実施します。*6

  • 2.1.1 cloud.redhat.comからpull-secret.txtをダウンロード

    • ブラウザで下記へアクセスし、Download pull secretを選択*7

    https://cloud.redhat.com/openshift/install/metal/user-provisioned

  • 2.1.2 プルシークレットのマージ

    • 下記のコマンドを実行して、ミラーレジストリーから作成した物とcloud.redhat.comからダウンロードした物をマージします
    • jqコマンドが無い場合は先にインストール
# yum -y install jq

下記のコマンドを実行して、2つのプルシークレットをマージします

# cd ~
# ls pull*
pull-secret.txt  pullsecret_config.json
# jq -s '.[0] * .[1]'  pullsecret_config.json pull-secret.txt > pull-secret-2.txt

※ ここから以降は、マージしたプルシークレットpull-secret-2.txtを使用します

これ以降の手順では、ドキュメント上では一般ユーザーでの実行となっており、同様に行うためにプルシークレットを一般ユーザーディレクトリにコピーします。

# cp pull-secret-2.txt /home/user/

3. イメージリポジトリーのミラーリング

ここでは、インターネット上（quay.io）のインストールに必要なイメージをレジストリーホストにダウンロードします

  • 前提条件
    • ミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできること
    • ミラーレジストリーおよびcloud.redhat.comから取得したプルシークレットをマージした物があること*8
3.1 ダウンロードバージョンの確認

下記のページを確認し、インストールする OpenShift Container Platform のバージョンを確認します

https://access.redhat.com/downloads/content/290/

3.2 環境変数を設定します
$ export OCP_RELEASE='4.2.4'
$ export LOCAL_REGISTRY='registry.test.example.local:5000'
$ export LOCAL_REPOSITORY='ocp4/openshift4'
$ export PRODUCT_REPO='openshift-release-dev'
$ export LOCAL_SECRET_JSON='/home/user/pull-secret-2.txt'
$ export RELEASE_NAME="ocp-release"

各パラメーター解説

  • OCP_RELEASE='4.2.4' # バージョンを指定
  • LOCAL_REGISTRY='registry.test.example.local:5000' #絶対パス:ポート番号を指定
  • LOCAL_REPOSITORY='ocp4/openshift4' # 任意。ここではドキュメント通り。
  • PRODUCT_REPO='openshift-release-dev' # 実稼働環境のリリースの場合には、openshift-release-devを指定する必要があり
  • LOCAL_SECRET_JSON='/home/user/pull-secret-2.txt' #マージしたプルシークレットを絶対パスで指定。
  • RELEASE_NAME="ocp-release" # 実稼働環境のリリースについては、ocp-releaseを指定する必要があり
3.3 リポジトリのミラーリング実行
$ oc adm -a ${LOCAL_SECRET_JSON} release mirror \
     --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
     --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
     --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}

ミラーリング成功時の結果

〜省略〜
Success
Update image:  registry.test.example.local:5000/ocp4/openshift4:4.2.4
Mirror prefix: registry.test.example.local:5000/ocp4/openshift4

To use the new mirrored repository to install, add the following section to the install-config.yaml:

imageContentSources:
- mirrors:
  - registry.test.example.local:5000/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - registry.test.example.local:5000/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
〜省略〜
3.4 imageContentSources セクションを記録

上記の結果に含まれる、imageContentSources セクションを記録します。この情報は、この後のUPIインストールの設定ファイルの作成時に使用します。

3.5 インストールプログラムの作成

この手順は、ミラーしたイメージからopenshift-installコマンドを入手する手順となります。*9

$ oc adm release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}" -a ${LOCAL_SECRET_JSON}

$ ./openshift-install version
./openshift-install v4.2.4
built from commit 425e4ff0037487e32571258640b39f56d5ee5572
release image registry.test.example.local:5000/ocp4/openshift4@sha256:cebce35c054f1fb066a4dc0a518064945087ac1f3637fe23d2ee2b0c433d6ba8

ocコマンド入手時にopenshift-installも入手されている場合はこの手順は不要です。*10

参考

ドキュメントではこの後、 9.1.6. ネットワークが制限されたインストールでのイメージストリームサンプルの使用 という手順がありますが、実際にはこの手順はクラスターのインストール実行後に行う作業となります。 詳細は本記事の、

  • インストール後の設定
    • Samples Operatorの設定

を参照ください。

UPIインストールの実行

UPIインストール方法自体は4.1 UPIインストールと同様です。 本記事では追加となる作業についてのみ記載します。

インストール設定ファイルの手動作成

該当するドキュメントは下記の章になります。

  • 第9章 ネットワークが制限されたインストール
    • 9.3.6. インストール設定ファイルの手動作成

ここでは、インストール設定ファイルinstall-config.yamlを作成しますが、その中にミラーレジストリーの情報を追加します。

  • install-config.yaml
apiVersion: v1
baseDomain: example.local
compute:
- hyperthreading: Enabled
  name: worker
  replicas: 0
controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3
metadata:
  name: test
networking:
  clusterNetworks:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {}
pullSecret: '{"auths":{"registry.test.example.local:5000":{"auth":"dXNlcjp1c2Vy"}}}'
sshKey: 'ssh-rsa AAAA...' 
additionalTrustBundle: |
  -----BEGIN CERTIFICATE-----
  〜省略〜
  -----END CERTIFICATE-----

pullSecret:にはミラーレジストリーから入手したプルシークレットの内容を記載します

。 下記のjqコマンドを使うとプルシークレットの内容を一行で表示できます。

$ jq -c . ~/pullsecret_config.json
{"auths":{"registry.test.example.local:5000":{"auth":"dXNlcjp1c2Vy"}}}

additionalTrustBundle:には作成した自己署名証明書の内容を記載します。証明書の内容は下記のコマンドで確認できます。

$ cat /etc/pki/ca-trust/source/anchors/domain.crt
-----BEGIN CERTIFICATE-----
〜省略〜
-----END CERTIFICATE-----

※注意：install-config.yamlに証明書の内容を記載する際は、各行頭にスペースを追加してインデントしてください

インストールの実行

install-config.yaml作成後の手順は通常と同じです。4.1 UPIインストールの手順を参考にしてください。

インストール後の作業

エラー表示への対処

インストール後、ダッシュボードおよびMonitoring/Alertingに、TelemeterClientDownのアラートが表示されます。 クラスターからインターネットへの接続が制限されているためにこのエラーが発生しています。 今回の構成において、クラスターのグローバルクラスタープルシークレットはミラーレジストリーから入手した内容になっていますので、事実上Telemetry機能は無効です。

3.3. リモートヘルスレポートのオプトアウト 4.2 | Red Hat Customer Portal

この状態でもアラートは表示され続けるため、アラートをサイレンスに設定します。

Monitoring > Alerting > Alertタブで、TelemeterClientDownのSilence Alertを選択します。

[図4]

Silence Alert設定前
Silence Alert

Silence Alertの詳細入力画面になったら、StartとEndの期間を指定し、必要に応じてCreator/Commentを記入してCreateを選択します。

[図5]

Silence Alert詳細入力画面
Silence Alert詳細入力画面

その後、TelemeterClientDownのStateがSilencedに変化し、ダッシュボードのアラート表示も消えます。

[図6]

Silence Alert設定後
Silence Alert設定後

Samples Operatorの設定

インストール前に行ったリポジトリのミラーリングでは、インストールに必要なイメージのミラーリングが行われました。しかしながらイメージストリームで使われるほとんどのイメージは registry.redhat.ioにあり、ミラーリングの作業ではこれらは対象外となります。 そのため、ネットワーク制限環境下のクラスターではこれらのイメージへの参照ができず、各イメージは参照エラーとなります。さらに一定時間経過度、Samples OperatorもDegratedになります。 対処法は二つあります。

  • Samples Operatorで全てのイメージの管理を無効化する
  • Samples Operatorで管理除外するイメージを個別指定する*11

2019/12/1追記。 Samples Operatorの設定について別記事を書きました。管理除外する方法など詳細はこちら。

rheb.hatenablog.com

本記事では全てのイメージの管理の無効化について説明します。

全てのイメージの管理の無効化

下記のコマンドを実行します。

$ oc edit configs.samples.operator.openshift.io

下記の、managementState: をRemovedに変更します

  • 変更前
〜省略〜
spec:
  architectures:
  - x86_64
  managementState: Managed
status:
  architectures:
〜省略〜
  • 変更後
〜省略〜
spec:
  architectures:
  - x86_64
  managementState: Removed
status:
  architectures:
〜省略〜

設定変更後、Builds >Image Streamsに表示されるイメージ数が一気に減ります。

  • 変更前

[図7]

イメージ管理の設定変更前
イメージ管理の設定変更前

  • 変更後

[図8]

イメージ管理の設定変更後
イメージ管理の設定変更後

変更後に残っているものは、インストールペイロードの一部で、ミラーリング時にquay.ioからミラーされたものです。またSamples Operator の管理対象外です。

Cluster Managerの登録

  • OpenShift Cluster Managerへアクセスします

https://cloud.redhat.com

  • 非接続のクラスターを登録します Register disconnected clusterを選択します

[図9]

クラスターの登録
クラスターの登録

  • クラスターの詳細情報を入力します

[図10]

クラスターの情報入力画面
クラスターの情報入力画面

  • Cluster ID:必須 # Dashboards参照
  • Display Name: #任意の名前
  • Web Console URL: # 例) https://console-openshift-console.apps.test.example.local/dashboards
  • Operating System:必須 # 選択(Red Hat Enterprise Linux CoreOS/Red Hat Enterprise Linux)
  • System Type:必須 # 選択(Physical/Virtual)
  • Number of vCPUs:必須 # Worker Nodeの合計
  • Memory Capacity (GiB): # Worker Nodeの合計
  • Number of compute nodes: # Worker Nodeの台数

登録が完了すると自動登録された場合と同様の画面が出ますが、MonitoringタブにはDisconnected clusterと表示され、Telemetryデータの受信が行われていないことが確認できます。

[図11]

クラスターの登録後、Monitoring画面
クラスターの登録後、Monitoring画面

アップグレード

ネットワーク制限環境下のクラスターではOTAが使えません。 クラスターのアップグレードを行う場合は、ミラーレジストリーにアップグレードイメージをダウンロードし、そのイメージを指定して実行する必要があります。

アップグレードイメージのダウンロード

手順は本記事の「3. イメージリポジトリーのミラーリング」と同様です。

まず、ダウンロードバージョンの確認を行い、環境変数を設定します。 OCP_RELEASE=にアップグレード先のバージョンを指定し、リポジトリのミラーリング実行を実行します。

コマンドでのアップグレード

手動でアップグレードを行う場合は下記のocコマンドを使用します。下記はv4.2.7を指定したアップグレードの例です。 --to-imageに指定するイメージ名は、ミラーリング成功結果のUpdate image: を参照してください。

$ oc adm upgrade --to-image=registry.test.example.local:5000/ocp4/openshift4:4.2.7 --allow-explicit-upgrade --force

コマンド実行後に下記のように表示されたらアップグレードが開始しています。

Updating to release image registry.test.example.local:5000/ocp4/openshift4:4.2.7

以降は、通常のOTAと同様にWebコンソールでアップグレードの進捗を確認します

[図12]

アップグレード中の進捗
アップグレード中の進捗

アップグレード完了後、指定したバージョンになっているか確認します。Desired Release Imageにはコマンドで指定したレジストリーミラーのイメージが指定されています。

[図13]

アップグレード完了後
アップグレード完了後

Operatorの利用

ネットワーク制限環境下でのOperatorの利用については、下記のドキュメントに記載があります。

本記事では内容の詳細には触れませんが、ざっと下記のような流れになります。

quay.ioからOperatorのパッケージをプルし、新しくカタログイメージにして、クラスタがアクセスできるローカルレジストリー（OCP内部も可）にプッシュする。クラスタから新規カタログを参照するように変更し、最後にoc image mirrorでソースイメージをローカルレジストリーにプッシュする。

別記事のイメージストリームのミラーと近い内容になっていますので、こちらも合わせて参考にしてみてください。

まとめ

ネットワーク制限環境下でのインストール方法について解説しました。 ここまでに記載した通り、非常に多くの手順がありその上で制限も多くあります。 可能であればこの方法を行う前に、Proxy経由などでクラスターをインターネットに接続する方法をご検討ください。

Let's get Big Ideas!

参考：Podmanコマンド

イメージリポジトリーのミラーリング時にpodman run を実行したのに、コンテナーが正常に起動しないなどの時に必要なコマンドの解説です。 Podmanコマンドのその他の詳細は、man podman を実行するか、下記のドキュメントを参考にして下さい。

第7章 コンテナーのコマンドライン参照 Red Hat Enterprise Linux 8 | Red Hat Customer Portal

  • コンテナーの確認

podman run を実行後、正常にコンテナが起動していない例

# podman ps -a
CONTAINER ID  IMAGE                         COMMAND               CREATED         STATUS                       PORTS  NAMES
4ae1ce8416f3  docker.io/library/registry:2  /entrypoint.sh ?...  26 seconds ago  Exited (127) 26 seconds ago         mirror-registry
  • コンテナーの停止
# podman stop mirror-registry
529d1a5c19faf973c1cadc6ce024a69d979c67e2b25527cc014c445a2e085757
  • コンテナーの削除
# podman rm mirror-registry 
529d1a5c19faf973c1cadc6ce024a69d979c67e2b25527cc014c445a2e085757

# podman ps -a
CONTAINER ID  IMAGE                         COMMAND               CREATED         STATUS                       PORTS  NAMES
  • ローカルコンテナーのイメージの確認
# podman images
REPOSITORY                   TAG   IMAGE ID       CREATED        SIZE
docker.io/library/registry   2     f32a97de94e1   8 months ago   26.4 MB
  • ローカルコンテナーのイメージの削除

上記で確認したIMAGE ID を指定して実行

# podman rmi f32a97de94e1
f32a97de94e13d29835a19851acd6cbc7979d1d50f703725541e44bb89a1ce91

# podman images

ローカルコンテナーのイメージが削除されたことにより、リカバリーが完了です。

  • 正常にコンテナーが起動した場合は、podman stop podman start でコンテナーの停止、実行が行えます
# podman stop mirror-registry 
a51a43a67d82adb46f3c3be3c0846cee59f353850054c569827afa3a94dc3d08
# podman ps -a
CONTAINER ID  IMAGE                         COMMAND               CREATED     STATUS                    PORTS                   NAMES
a51a43a67d82  docker.io/library/registry:2  /entrypoint.sh /e...  2 days ago  Exited (2) 6 seconds ago  0.0.0.0:5000->5000/tcp  mirror-registry

# podman start mirror-registry 
mirror-registry
# podman ps -a
CONTAINER ID  IMAGE                         COMMAND               CREATED     STATUS            PORTS                   NAMES
a51a43a67d82  docker.io/library/registry:2  /entrypoint.sh /e...  2 days ago  Up 5 seconds ago  0.0.0.0:5000->5000/tcp  mirror-registry

*1:本記事ではレジストリーホストの役割を明確にするために、踏み台サーバーとは別に構成しています。

*2:インストールはサーバーGUIを使用。RHELの基本的な設定については、4.1 UPIインストール記事中の踏み台サーバーの構築を参照

*3:既存の認証局などがあればそちらを使っても構いません

*4:システム全体のトラストストアについては、次の記事を参照ください。 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/sec-shared-system-certificates

*5:2019/12/5時点で、英語/日本語の公式ドキュメントがバックグラウンド起動に修正されています。

*6:以降の3.3 リポジトリのミラーリング実行時に、2つのプルシークレット情報が無いとミラーリングに失敗するため。英語のblog記事には手順記載あり。フィードバックは登録されているので、ドキュメント修正待ち。

*7:現在はコマンドで入手する方法が無いためブラウザで実行してください

*8:2.1追加作業を参照

*9:ドキュメントにはオプションにプルシークレットの指定が無いので追加。これもドキュメントの修正待ち。

*10:確認できた違いとしては、Desired Release Imageに表示されるイメージ名がquay.ioなのかローカルレジストリーなのか、程度

*11:これについてだけでも結構なボリュームの内容があるので、別記事にする予定です。→書きました。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。