Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第3章 ホストの準備

3.1. オペレーティングシステム要件

マスターおよびノードホストのオペレーティングシステムの要件は使用するサーバーのアーキテクチャーによって異なります。

  • x86_64 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む Red Hat Enterprise Linux (RHEL) 7.4 または 7.5 のベースインストールまたは RHEL Atomic Host 7.4.2 以降を使用します。
  • クラスドベースのインストールの場合は、Extras チャンネルからの最新パッケージを含む RHEL 7.4 または 7.5 のベースインストールを使用します。
  • IBM POWER8 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む RHEL 7.5 のベースインストールを使用します。
  • IBM POWER9 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む RHEL-ALT 7.5 のベースインストールを使用します。

それぞれのインストール方法については、必要に応じて以下のドキュメントを参照してください。

3.2. サーバータイプの要件

ノードに IBM POWER サーバーを使用する場合は、IBM POWER サーバーのみを使用できます。IBM POWER サーバーで実行されるノードを x86_64 サーバーを使用する既存クラスターに追加したり、クラスターノードを IBM POWER および x86_64 サーバーの混在環境にデプロイできません。

3.3. パスの設定

各ホストの root ユーザーの PATH には以下のディレクトリーが含まれている必要があります。

  • /bin
  • /sbin
  • /usr/bin
  • /usr/sbin

これらすべてはデフォルトで新規の RHEL 7.x インストールに含まれています。

3.4. ホストアクセスの確保

OpenShift Container インストーラーでは、すべてのホストにアクセスできるユーザーが必要になります。インストーラーを非 root ユーザーとして実行する場合は、それぞれの宛先ホストでパスワードレス sudo 権限を設定する必要があります。

たとえば、インストールプロセスを起動するホストで SSH キーを生成できます。

# ssh-keygen

パスワードは使用しないでください。

SSH キーを配布する簡単な方法として、bash ループを使用できます。

# for host in master.example.com \
    master.example.com \
    node1.example.com \
    node2.example.com; \
    do ssh-copy-id -i ~/.ssh/id_rsa.pub $host; \
    done

設定に従って、上記コマンドのホスト名を変更します。

bash ループの実行後に、SSH でループに一覧表示されている各ホストにアクセスできます。

3.5. プロキシーの上書きの設定

ノードの /etc/environment ファイルに http_proxy または https_proxy 値のいずれかが含まれる場合、OpenShift Container Platform コンポーネント間でのオープンな通信を可能にするため、そのファイルに no_proxy 値を設定する必要もあります。

注記

/etc/environment ファイルの no_proxy パラメーターは、インベントリーファイルに設定するグローバルプロキシー値と同じ値ではありません。グローバルプロキシー値では、プロキシーの設定を使って特定の OpenShift Container Platform サービスを設定します。詳細は、「グローバルプロキシーオプションの設定」を参照してください。

/etc/environment ファイルにプロキシー値が含まれる場合、以下の値を、各ノードでこのファイルの no_proxy パラメーターに以下の値を定義します。

  • マスターおよびノードのホスト名またはそれらのドメインサフィックス。
  • 他の内部ホスト名またはそれらのドメインサフィックス。
  • etcd IP アドレス。etcd アクセスはアドレスで制御されるので、ホスト名ではなく IP アドレスを指定する必要があります。
  • Kubernetes IP アドレス (デフォルトは 172.30.0.1)。インベントリーファイルの openshift_portal_net パラメーターに設定される値である必要があります。
  • Kubernetes の内部ドメインサフィックス: cluster.local
  • Kubernetes の内部ドメインサフィックス: .svc
注記

no_proxy は CIDR をサポートしないので、ドメインサフィックスを使用できます。

http_proxy または https_proxy 値のいずれかを使用する場合、 no_proxy パラメーターの値は以下の例のようになります。

no_proxy=.internal.example.com,10.0.0.1,10.0.0.2,10.0.0.3,.cluster.local,.svc,localhost,127.0.0.1,172.30.0.1

3.6. ホスト登録

各ホストは Red Hat サブスクリプションマネージャー (RHSM) を使用して登録されており、必要なパッケージにアクセスできるようアクティブな OpenShift Container Platform サブスクリプションがアタッチされている必要があります。

  1. 各ホストで RHSM に登録します。

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM から最新サブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Yum リポジトリーをすべて無効にします。

    1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"
    2. 残りの Yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist
    3. yum-config-manager を使用して、残りの Yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

       yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

  6. OpenShift Container Platform 3.10 で必要なリポジトリーのみを有効にします。

    • x86_64 サーバーでのクラウドインストールおよびオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-server-rpms" \
          --enable="rhel-7-server-extras-rpms" \
          --enable="rhel-7-server-ose-3.10-rpms" \
          --enable="rhel-7-server-ansible-2.4-rpms"
    • IBM POWER8 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-le-rpms" \
          --enable="rhel-7-for-power-le-extras-rpms" \
          --enable="rhel-7-for-power-le-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-le-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"
    • IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-9-rpms" \
          --enable="rhel-7-for-power-9-extras-rpms" \
          --enable="rhel-7-for-power-9-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-9-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"

3.7. 基本パッケージのインストール

注記

ホストで RHEL 7.5 が実行されており、OpenShift Container Platform のデフォルト docker 設定 (OverlayFS ストレージおよびすべてのデフォルトロギングオプションを使用) を受け入れる場合、「インベントリーファイルの設定」に移動し、クラスターを表すインベントリーを作成できます。インストールの実行時に使用される prerequisites.yml Playbook により、デフォルトのパッケージおよび設定が適切に適用されるようになります。

ホストで RHEL 7.4 を実行しているか、または RHEL 7.5 を実行しており、さらに docker 設定をカスタマイズする必要がある場合、このトピックの残りのセクションのガイダンスに従ってください。

RHEL 7 システムの場合:

  1. 以下の基本パッケージをインストールします。

    # yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
  2. システムを最新パッケージに更新します。

    # yum update
    # systemctl reboot
  3. RPM ベースのインストーラーを使用してインストールを実行することを計画している場合は、この手順を省略できます。ただし、 コンテナー化されたインストーラーの使用を計画している場合は、以下を実行します。

    1. atomic パッケージをインストールします。

      # yum install atomic
    2. Docker のインストール に進みます。
  4. RPM ベースの OpenShift Container Platform インストーラーユーティリティーを提供する以下のパッケージをインストールし、Ansible、Playbook および関連する設定ファイルなどのクラスターインストールプロセスで必要な他のパッケージをプルします。

    # yum install openshift-ansible
    注記

    以前の OpenShift Container Platform リリースでは、この手順で atomic-openshift-utils パッケージがインストールされていましたが、OpenShift Container Platform 3.10 以降ではこのパッケージが削除され、openshift-ansible パッケージが必要な内容をすべて提供しています。

RHEL Atomic Host 7 システムの場合:

  1. 最新の Atomic ツリーにアップグレードしてホストが最新の状態にあることを確認します (利用可能な場合)。

    # atomic host upgrade
  2. アップグレードが完了し、以下の起動の準備ができたら、ホストを再起動します。

    # systemctl reboot

3.8. Docker のインストール

ここで、すべてのマスターおよびノードホストで Docker をインストールする必要があります。これにより、OpenShift Container Platform をインストールする前に Docker ストレージオプション を設定することができます。

RHEL 7 システムの場合は、Docker 1.13 をインストールします。

注記

RHEL Atomic Host 7 システムには、Docker がデフォルトでインストールされ、設定され、実行されている必要があります。

# yum install docker-1.13.1

パッケージのインストールが完了したら、バージョン 1.13 がインストールされていることを確認します。

# rpm -V docker-1.13.1
# docker version
注記

クラスターインストールプロセスは、/etc/sysconfig/docker ファイルを自動的に変更します。

3.9. Docker ストレージの設定

作成元のコンテナーとイメージは Docker のストレージバックエンドに保存されます。このストレージは一時的なストレージであり、アプリケーションの必要を満たすために割り当てられる 永続ストレージ とは区別されます。一時ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されると失われます。永続ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されてもそのまま残ります。

コンテナーデーモンを実行する各システムにストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要です。また、デフォルトで Web コンソールがマスターのコンテナーで実行されますが、Web コンソールを実行するためにストレージがマスター上で必要になります。コンテナーはノードで実行されるため、ストレージは常にノード上で必要になります。ストレージのサイズは、ワークロード、コンテナーの数、実行されているコンテナーのサイズ、およびコンテナーのストレージ要件によって異なります。また、コンテナー化された etcd には設定済みのコンテナーストレージが必要です。

注記

ホストで RHEL 7.5 が実行されており、OpenShift Container Platform のデフォルト docker 設定 (OverlayFS ストレージおよびすべてのデフォルトロギングオプションを使用) を受け入れる場合、「インベントリーファイルの設定」に移動し、クラスターを表すインベントリーを作成できます。インストールの実行時に使用される prerequisites.yml Playbook により、デフォルトのパッケージおよび設定が適切に適用されるようになります。

ホストで RHEL 7.4 を実行しているか、または RHEL 7.5 を実行しており、さらに docker 設定をカスタマイズする必要がある場合、このトピックの残りのセクションのガイダンスに従ってください。

RHEL Atomic Host の場合

RHEL Atomic Host の Docker のデフォルトストレージバックエンドはシンプール論理ボリュームで、実稼働環境でサポートされています。システム要件にある Docker ストレージ要件に対して、このボリュームに十分なスペースが割り当てられていることを確認する必要があります。

十分なスペースが割り当てられていない場合、docker-storage-setup の使用と RHEL Atomic Host におけるストレージ管理の基本手順については、「Managing Storage with Docker Formatted Containers」を参照してください。

Red Hat Enterprise Linux の場合:

RHEL 7 の Docker のデフォルトストレージバックエンドは、ループバックデバイスにあるシンプールです。これは実稼働環境でサポートされておらず、概念実証向けの環境のみに適しています。実稼働環境の場合、シンプール論理ボリュームを作成し、Docker をそのボリュームを使用するよう再設定する必要があります。

Docker はグラフドライバーにイメージとコンテナーを保存します。グラフドライバーは DeviceMapperOverlayFSBtrfs などのプラグ可能なストレージ技術です。これらにはそれぞれメリットとデメリットがあります。たとえば、OverlayFS のコンテナーを起動し、停止するスピードは DeviceMapper よりも速いですが、Overlay FS はユニオンファイルシステムのアーキテクチャー上の制限により Portable Operating System Interface for Unix (POSIX) に準拠しておらず、Red Hat Enterprise Linux 7.2 よりも前のバージョンではサポートされていません。お使いの RHEL バージョンで OverlayFS を使用する方法についての情報は Red Hat Enterprise Linux リリースノートを参照してください。

DeviceMapper と OverlayFS のメリットと制限に関する情報は、「Choosing a Graph Driver」を参照してください。

3.9.1. OverlayFS の設定

OverlayFS はユニオンファイルシステムの一種です。これにより、あるファイルシステムを別のファイルシステムに重ねる (オーバーレイする) ことができます。上位のファイルシステムで変更が記録されても、下位のファイルシステムは変更されません。

Comparing the Overlay Versus Overlay2 Graph Drivers 」には、overlay および overlay2 ドライバーの詳細情報が記載されています。

Docker サービスの OverlayFS ストレージドライバーの有効化については、Red Hat Enterprise Linux Atomic Host ドキュメントを参照してください。

3.9.2. シンプールストレージの設定

Docker に含まれる docker-storage-setup スクリプトを使用してシンプールデバイスを作成し、Docker ストレージドライバーを設定できます。これは Docker のインストール後に実行でき、イメージまたはコンテナーの作成前に実行する必要があります。このスクリプトは /etc/sysconfig/docker-storage-setup ファイルから設定オプションを読み取り、論理ボリュームを作成するための 3 つのオプションをサポートします。

  • オプション A: 追加のブロックデバイスを使用する。
  • オプション B: 既存の指定されたボリュームグループを使用する。
  • オプション C: root ファイルシステムが置かれている残りのボリュームグループの空きスペースを使用する。

オプション A は最も信頼性の高いオプションですが、この場合 Docker ストレージを設定する前にブロックデバイスをホストに追加する必要があります。オプション B と C はどちらもホストのプロビジョニング時に利用可能な空きスペースを残しておく必要があります。オプション C は、Red Hat Mobile Application Platform (RHMAP) などの一部のアプリケーションで問題が発生することが確認されています。

  1. 以下の 3 つのオプションのいずれかを使用して docker-pool ボリュームを作成します。

    • オプション A: 追加のブロックデバイスを使用する。

      /etc/sysconfig/docker-storage-setup で、使用するブロックデバイスのパスに DEVS を設定します。作成するボリュームグループ名に VG を設定します。docker-vg は適切なオプションになります。以下は例になります。

      # cat <<EOF > /etc/sysconfig/docker-storage-setup
      DEVS=/dev/vdc
      VG=docker-vg
      EOF

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup                                                                                                                                                                                                                                [5/1868]
      0
      Checking that no-one is using this disk right now ...
      OK
      
      Disk /dev/vdc: 31207 cylinders, 16 heads, 63 sectors/track
      sfdisk:  /dev/vdc: unrecognized partition table type
      
      Old situation:
      sfdisk: No partitions found
      
      New situation:
      Units: sectors of 512 bytes, counting from 0
      
         Device Boot    Start       End   #sectors  Id  System
      /dev/vdc1          2048  31457279   31455232  8e  Linux LVM
      /dev/vdc2             0         -          0   0  Empty
      /dev/vdc3             0         -          0   0  Empty
      /dev/vdc4             0         -          0   0  Empty
      Warning: partition 1 does not start at a cylinder boundary
      Warning: partition 1 does not end at a cylinder boundary
      Warning: no primary partition is marked bootable (active)
      This does not matter for LILO, but the DOS MBR will not boot this disk.
      Successfully wrote the new partition table
      
      Re-reading the partition table ...
      
      If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
      to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
      (See fdisk(8).)
        Physical volume "/dev/vdc1" successfully created
        Volume group "docker-vg" successfully created
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション B: 既存の指定されたボリュームグループを使用する。

      /etc/sysconfig/docker-storage-setup で、VG を必要なボリュームグループに設定します。以下は例になります。

      # cat <<EOF > /etc/sysconfig/docker-storage-setup
      VG=docker-vg
      EOF

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション C: root ファイルシステムが置かれているボリュームグループの残りの空きスペースを使用する。

      root ファイルシステムが置かれているボリュームグループに必要な空きスペースがあることを確認してから、docker-storage-setup を実行して、出力で docker-pool ボリュームが作成されていることを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 32.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume rhel/docker-pool and rhel/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted rhel/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
  2. 設定を確認します。/etc/sysconfig/docker-storage ファイルに dm.thinpooldev 値と docker-pool 論理ボリュームが含まれている必要があります。

    # cat /etc/sysconfig/docker-storage
    DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/rhel-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "
    
    # lvs
      LV          VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      docker-pool rhel twi-a-t---  9.29g             0.00   0.12
    重要

    Docker または OpenShift Container Platform を使用する前に、docker-pool 論理ボリュームが要求を満たす程度のサイズであることを確認します。docker-pool ボリュームは利用可能なボリュームグループの 60% である必要があり、これは LVM モニタリングによって拡張し、ボリュームグループを埋めていきます。

  3. Docker がホストでまだ起動されていない場合は、サービスを有効にしてから起動し、それが実行されていることを確認します。

    # systemctl enable docker
    # systemctl start docker
    # systemctl is-active docker

    Docker がすでに実行されている場合は、Docker を再初期化します。

    警告

    これは現在ホストにあるコンテナーまたはイメージを破棄します。

    # systemctl stop docker
    # rm -rf /var/lib/docker/*
    # systemctl restart docker

    /var/lib/docker/ にコンテンツがある場合、これを削除する必要があります。OpenShift Container Platform のインストール前に Docker が使用されていた場合にはファイルが存在します。

3.9.3. Docker ストレージの再設定

docker-pool を作成した後に Docker ストレージを再設定する必要がある場合は、まず docker-pool 論理ボリュームを削除する必要があります。専用のボリュームグループを使用している場合は、上記の手順に従って、docker-storage-setup を再設定する前にそのボリュームグループと関連する物理ボリュームを削除する必要もあります。

LVM 管理の詳細は、「論理ボリュームマネージャー管理」を参照してください。

3.9.4. イメージ署名サポートの有効化

OpenShift Container Platform は、イメージが信頼済みのソースのものかを暗号で確認することができます。『Container Security Guide』には、イメージ署名の仕組みの概要が記載されています。

atomic コマンドラインインターフェース (CLI) (バージョン 1.12.5 以降) を使用してイメージ署名の検証を設定できます。atomic CLI は RHEL Atomic Host システムにプリインストールされています。

注記

atomic CLI の詳細は、Atomic CLI についてのドキュメントを参照してください。

ホストシステムにインストールされていない場合は、atomic パッケージをインストールします。

$ yum install atomic

atomic trust サブコマンドは信頼設定を管理します。デフォルトの設定では、すべてのレジストリーをホワイトリストに入れます。これは、署名の検証が設定されていないことを意味します。

$ atomic trust show
* (default)                         accept

適切な設定として、特定のレジストリーまたは namespace をホワイトリストに入れ、信頼されていないレジストリーはブラックリストに入れ (拒否)、ベンダーレジストリーで署名検証が必要になるようにします。以下のコマンドセットは、この設定例を実行します。

Atomic の信頼の設定例

$ atomic trust add --type insecureAcceptAnything 172.30.1.1:5000

$ atomic trust add --sigstoretype atomic \
  --pubkeys pub@example.com \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype atomic \
  --pubkeys /etc/pki/example.com.pub \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype web \
  --sigstore https://access.redhat.com/webassets/docker/content/sigstore \
  --pubkeys /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \
  registry.access.redhat.com

# atomic trust show
* (default)                         accept
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

署名されたすべてのソースが検証される場合、グローバルの reject デフォルトによりノードをさらに強化できます。

$ atomic trust default reject

$ atomic trust show
* (default)                         reject
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

追加の例として atomic man ページの man atomic-trust を使用します。

以下のファイルとディレクトリーは、ホストの信頼設定を構成しています。

  • /etc/containers/registries.d/*
  • /etc/containers/policy.json

信頼設定は、各ノードまたは個別のホストで管理される生成ファイル上で直接管理でき、 Ansible などを使用して適切なノードに配布できます。Ansible を使用したファイル配布の自動化の例については、『Container Image Signing Integration Guide』を参照してください。

3.9.5. コンテナーログの管理

コンテナーのログファイル (コンテナーが実行されているノード上の /var/lib/docker/containers/<hash>/<hash>-json.log ファイル) が問題を生じさせかねないサイズに拡張してしまうことがあります。これは、Docker の json-file ロギングドライバーを設定し、ログファイルのサイズと数を制限して管理できます。

オプション目的

--log-opt max-size

作成される新規ログファイルのサイズを設定します。

--log-opt max-file

ホストごとに保持するログファイルの最大数を設定します。

たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1Mmax-file=3 を設定します。

OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'

次に Docker サービスを再起動します。

# systemctl restart docker

3.9.6. 利用可能なコンテナーログの表示

コンテナーログは、コンテナーが実行されているノードの /var/lib/docker/containers/<hash>/ ディレクトリーに保存されます。以下は例になります。

# ls -lh /var/lib/docker/containers/f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8/
total 2.6M
-rw-r--r--. 1 root root 5.6K Nov 24 00:12 config.json
-rw-r--r--. 1 root root 649K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.1
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.2
-rw-r--r--. 1 root root 1.3K Nov 24 00:12 hostconfig.json
drwx------. 2 root root    6 Nov 24 00:12 secrets

ロギングドライバーの設定方法に関する詳細は、Docker ドキュメントを参照してください。

3.9.7. ローカルボリューム使用のブロック

ボリュームのプロビジョニングが DockerfileVOLUME 指示または docker run -v <volumename> コマンドを使用して実行されると、ホストのストレージ領域が使用されます。このストレージを使用すると、予期しない領域不足の問題が生じ、ホストが停止する可能性があります。

OpenShift Container Platform では、独自のイメージを実行しようとするユーザーには、ノードホストのストレージ領域全体が一杯になるリスクがあります。この問題に対する 1 つの解決策として、ユーザーがボリュームを持つイメージを実行できないようにする方法があります。これにより、ユーザーがアクセスできるストレージのみを制限し、クラスター管理者はストレージのクォータを割り当てることができます。

docker-novolume-plugin を使用して、ローカルボリュームが定義されたコンテナーの起動を禁止することにより、この問題を解決することができます。とくに、このプラグインは以下を含む docker run コマンドをブロックします。

  • --volumes-from オプション
  • VOLUME が定義されたイメージ
  • docker volume コマンドを使ってプロビジョニングされた既存ボリュームの参照

プラグインはバインドマウントへの参照をブロックしません。

docker-novolume-plugin を有効にするには、各ノードホストで以下の手順を実行します。

  1. docker-novolume-plugin パッケージをインストールします。

    $ yum install docker-novolume-plugin
  2. docker-novolume-plugin サービスを有効にし、起動します。

    $ systemctl enable docker-novolume-plugin
    $ systemctl start docker-novolume-plugin
  3. /etc/sysconfig/docker ファイルを編集し、以下を OPTIONS 一覧に追加します。

    --authorization-plugin=docker-novolume-plugin
  4. docker サービスを再起動します。

    $ systemctl restart docker

このプラグインを有効にした後に、ローカルボリュームが定義されたコンテナーは起動に失敗し、以下のエラーメッセージを表示します。

runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed

3.10. Red Hat Gluster Storage ソフトウェア要件

GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。

# yum install glusterfs-fuse

このパッケージはすべての RHEL システムにインストールされています。ただし、サーバーが x86_64 アーキテクチャーを使用する場合は Red Hat Gluster Storage の最新バージョンに更新することを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

glusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。

# yum update glusterfs-fuse

3.11. 次のステップ

ホストの準備が完了したら、インベントリーファイルの設定に移行できます。

注記

スタンドアロンレジストリーをインストールする場合は、スタンドアロンレジストリーのインストールを続行します。