第3章 データベースイメージ

3.1. 概要

以下のトピックには、OpenShift Container Platform ユーザーに提供される、さまざまなデータベースイメージに関する情報が含まれます。

注記

現在、テクノロジープレビューとして、データベースイメージ用にクラスター化を有効にできますが、この機能は実稼働環境での使用を目的としていません。

3.2. MySQL

3.2.1. 概要

OpenShift Container Platform には、MySQL の実行用のコンテナーイメージがあります。このイメージでは、設定で指定されるユーザー名、パスワード、データベース名に基づいてデータベースサービスが提供されます。

3.2.2. バージョン

現時点で、OpenShift Container Platform では、MySQL のバージョン 5.6 および 5.7 を提供しています。

3.2.3. イメージ

イメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/rhscl/mysql-56-rhel7
$ docker pull registry.redhat.io/rhscl/mysql-57-rhel7

CentOS 7 ベースのイメージ

MySQL 5.6 および 5.7 の CentOS イメージは、Docker Hub で入手できます。

$ docker pull centos/mysql-56-centos7
$ docker pull centos/mysql-57-centos7

これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリーにプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する ImageStream を作成することもでき、OpenShift Container Platform リソースがこの ImageStream を参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して ImageStream の 定義例 があります。

3.2.4. 設定および用途

3.2.4.1. データベースの初期化

共有ボリュームを初めて使用する場合には、データベース、データベースの管理ユーザー、MySQL root ユーザー (MYSQL_ROOT_PASSWORD 環境変数を指定した場合) が作成され、次に MySQL デーモンが起動します。別のコンテナーにボリュームを再アタッチする場合には、データベース、データベースユーザー、管理者ユーザーは作成されず、MySQL デーモンが開始されます。

以下のコマンドは、新しいデータベースの Pod を作成し、さらにコンテナー内で MySQL を実行します。

$ oc new-app \
    -e MYSQL_USER=<username> \
    -e MYSQL_PASSWORD=<password> \
    -e MYSQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/mysql-56-rhel7

3.2.4.2. コンテナーでの MySQL コマンドの実行

OpenShift Container Platform は Software Collections (SCL) を使用して、MySQL をインストールし、起動します。(デバッグ用に) 実行中のコンテナー内で MySQL コマンドを実行する場合には bash を使用して呼び出す必要があります。

これを実行するには、まず Pod 名を特定します。たとえば、現在のプロジェクトで Pod の一覧を表示できます。

$ oc get pods

次に、Pod に対してリモートシェルセッションを開始します。

$ oc rsh <pod>

コンテナーに入ると、必要な SCL が自動的に有効になります。

Bash シェルから mysql コマンドを実行し、MySQL の対話セッションを開始して通常の MySQL 操作が実行できるようになりました。たとえば、データベースユーザーとして認証するには、以下を実行します。

bash-4.2$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -h $HOSTNAME $MYSQL_DATABASE
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.6.37 MySQL Community Server (GPL)
...
mysql>

完了したら、quit または exit を入力して MySQL セッションを終了します。

3.2.4.3. 環境変数

MySQL ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。

表3.1 MySQL 環境変数

変数名説明

MYSQL_USER

アプリケーションで使用するために作成されたデータベースユーザーのユーザー名を指定します。

MYSQL_PASSWORD

MYSQL_USER のパスワード

MYSQL_DATABASE

MYSQL_USER が完全な権限を持つデータベースの名前

MYSQL_ROOT_PASSWORD

root ユーザーの任意のパスワード。これが設定されていない場合には、root アカウントにリモートログインできません。コンテナーからはいつでも、パスワードなしにローカル接続が可能です。

MYSQL_SERVICE_HOST

Kubernetes が自動作成したサービスホストの変数

MYSQL_SERVICE_PORT

Kubernetes が自動作成したサービスポートの変数

警告

ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。

MySQL 設定は、以下の環境変数で設定できます。

表3.2 MySQL の他の設定

変数名説明デフォルト

MYSQL_LOWER_CASE_TABLE_NAMES

テーブル名の保存および比較方法を設定します。

0

MYSQL_MAX_CONNECTIONS

クライアントが同時に接続可能な最大数

151

MYSQL_MAX_ALLOWED_PACKET

生成された文字列/中間文字列または 1 つのパケットの最大サイズ

200M

MYSQL_FT_MIN_WORD_LEN

FULLTEXT インデックスに含める文字の最小長

4

MYSQL_FT_MAX_WORD_LEN

FULLTEXT インデックスに含める文字の最大長

20

MYSQL_AIO

ネイティブの AIO が壊れている場合に innodb_use_native_aio の設定値を制御します。

1

MYSQL_TABLE_OPEN_CACHE

全スレッド用に開くテーブル数

400

MYSQL_KEY_BUFFER_SIZE

インデックスブロックに使用するバッファーサイズ

32M (または利用可能なメモリーの 10%)

MYSQL_SORT_BUFFER_SIZE

分類に使用するバッファーサイズ

256K

MYSQL_READ_BUFFER_SIZE

シーケンススキャンに使用するバッファーサイズ

8M (または利用可能メモリーの 5%)

MYSQL_INNODB_BUFFER_POOL_SIZE

InnoDB がテーブルやインデックスデータをキャッシュするバッファープールのサイズ

32M (または利用可能なメモリーの 50%)

MYSQL_INNODB_LOG_FILE_SIZE

ロググループにある各ログファイルのサイズ

8M (または利用可能メモリーの 15%)

MYSQL_INNODB_LOG_BUFFER_SIZE

InnoDB がディスクのログファイルへの書き込みに使用するバッファーサイズ

8M (または利用可能メモリーの 15%)

メモリー関連のパラメーターによっては、デフォルト値が 2 つあるものもあります。コンテナーにメモリーの制限が割り当てられていない場合には、固定値が使用されます。他の値は、コンテナーの起動中に利用可能なメモリーを基に動的に計算されます。

3.2.4.4. ボリュームのマウントポイント

MySQL イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。

  • /var/lib/mysql/data: これは、MySQL がデータベースのファイルを保存するデータディレクトリーです。

3.2.4.5. パスワードの変更

パスワードはイメージ設定の一部であるため、データベースユーザー (MYSQL_USER) と root ユーザーのパスワードを変更する唯一のサポートされている方法として、環境変数 MYSQL_PASSWORDMYSQL_ROOT_PASSWORD をそれぞれ変更することができます。

現在のパスワードは、Pod またはデプロイメント設定を Web コンソールで表示するか、CLI で環境変数を表示して、確認できます。

$ oc set env pod <pod_name> --list

MYSQL_ROOT_PASSWORD が設定されている場合は常に、root ユーザーに特定のパスワードを指定してリモートアクセスを有効にできます。また、設定されていない場合には、root ユーザーのリモートアクセスが無効になります。これは、一般ユーザー MYSQL_USER には影響なく、常にリモートからアクセスできます。また、root ユーザーのローカルアクセスにも影響なく、localhost でパスワードなしにいつでもログインできます。

SQL ステートメントや、前述した環境変数以外の方法でデータベースのパスワードを変更すると、変数に保存されている値と、実際のパスワードが一致しなくなる可能性があります。データベースコンテナーが起動するたびに、パスワードは環境変数に保存されている値にリセットされます。

これらのパスワードを変更するには、oc set env コマンドを使用して、関連するデプロイメント設定の任意の環境変数 1 つまたは両方を更新します。たとえば、テンプレートからアプリケーションを作成する場合など、複数のデプロイメント設定がこれらの環境変数を使用する場合には、デプロイメント設定ごとに変数を更新し、パスワードがどこでも同期されるようにします。これは、すべて同じコマンドで実行できます。

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MYSQL_PASSWORD=<new_password> \
  MYSQL_ROOT_PASSWORD=<new_root_password>
重要

アプリケーションによっては、アプリケーションの他の場所にあるパスワードの他の環境変数を更新して一致させる必要があるものもあります。たとえば、フロントエンド Pod のより一般的な DATABASE_USER 変数などは、データベースユーザーのパスワードと一致する必要がある場合があります。必要とされる環境変数すべてにおいて、パスワードがアプリケーションごとに一致しているようにしてください。一致しない場合には、トリガーされた時点で、Pod の再デプロイメントが失敗する場合があります。

設定変更トリガーが設定されている場合には、環境変数を更新すると、データベースサーバーの再デプロイメントがトリガーされます。設定されていない場合には、新しいデプロイメントを手動で起動して、パスワードの変更を適用する必要があります。

新規パスワードが有効になっていることを確認するには、まず実行中の MySQL Pod に対してリモートシェルセッションを開きます。

$ oc rsh <pod>

Bash シェルから、データベースユーザーの新規パスワードを確認します。

bash-4.2$ mysql -u $MYSQL_USER -p<new_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

+------------+---------------------+
| database() | user()              |
+------------+---------------------+
| sampledb   | user0PG@172.17.42.1 |
+------------+---------------------+

root ユーザーの新規パスワードを確認するには、以下を実行します。

bash-4.2$ mysql -u root -p<new_root_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

+------------+------------------+
| database() | user()           |
+------------+------------------+
| sampledb   | root@172.17.42.1 |
+------------+------------------+

3.2.5. テンプレートからのデータベースサービスの作成

OpenShift Container Platform には テンプレート が含まれており、新規データベースサービスの作成を簡素化します。テンプレートには、必須の環境変数をすべて定義するパラメーターフィールドがあり (ユーザー、パスワード、データベース名など)、自動生成されたパスワード値など、事前定義済みのデフォルト値が設定されます。また、テンプレートは デプロイメント設定 および サービス の両方を定義します。

MySQL テンプレートは、クラスターの初期設定時にクラスター管理者により、デフォルトの openshift プロジェクトに登録しておく必要があります。詳細については、必要に応じて、「デフォルトのイメージストリームおよびテンプレートの読み込み」を参照してください。

利用可能なテンプレートは以下の 2 種類です。

  • mysql-ephemeral は、データベースのコンテンツ用に一時ストレージを使用するので、開発またはテスト目的にのみ使用します。つまり、Pod が別の Pod に移動されたり、デプロイメント設定が更新され、再デプロイがトリガーされたりなど、データベース Pod が何らかの理由で再起動された場合には、データはすべて失われます。
  • mysql-persistent は、データベースのデータ用に永続ボリュームストアを使用するので、データは Pod が再起動されても残ります。永続ボリュームを使用する場合には、OpenShift Container Platform デプロイメントで定義された永続ボリュームプールが必要です。プールの設定に関するクラスター管理者向けの説明は、こちらを参照してください。

この説明に従い、テンプレートをインスタンス化できます。

サービスをインスタンス化したら、データベースにアクセスする予定のある別のコンポーネントのデプロイメント設定に、ユーザー名、パスワード、データベース名の環境変数をコピーできます。このコンポーネントは、定義したサービスを使用してこのデータベースにアクセスできます。

3.2.6. MySQL のレプリケーションの使用

注記

現在、テクノロジープレビューとして、データベースイメージ用にクラスター化を有効にできますが、この機能は実稼働環境での使用を目的としていません。

Red Hat は、MySQL のマスター、スレーブのレプリケーション (クラスタリング) 用に概念実証テンプレートを提供します。GitHub からサンプルテンプレート を入手できます。

現在のプロジェクトのテンプレートライブラリーにテンプレートのサンプルをアップロードするには、以下を実行します。

$ oc create -f \
    https://raw.githubusercontent.com/sclorg/mysql-container/master/examples/replica/mysql_replica.json

以下のセクションでは、サンプルのテンプレートに定義されているオブジェクト、およびそれらのオブジェクトが連携してマスターとスレーブのレプリケーションを実装する MySQL サーバークラスターをどのように起動するのかを詳しく説明します。これは、MySQL 向けに推奨されるレプリケーションストラテジーです。

3.2.6.1. MySQL マスターのデプロイメント設定の作成

MySQL レプリケーションを設定するには、デプロイメント設定 を、レプリケーションコントローラー を定義するテンプレート例に定義します。MySQL のマスターとスレーブレプリケーションには、デプロイメント設定が 2 つ必要です。1 つ目のデプロイメント設定では、MySQL マスター サーバーを、2 つ目で MySQL スレーブ サーバーを定義します。

MySQL サーバーに対してマスターとして機能するように指示するには、デプロイメント設定のコンテナー定義にある command フィールドに、run-mysqld-master を設定する必要があります。このスクリプトは、MySQL イメージの別のエントリーポイントとして機能し、MySQL サーバーがレプリケーションのマスターとして実行するように設定します。

MySQL レプリケーションでは、マスターとスレーブ間のデータをリレーする特別ユーザーが必要です。この目的で使用できるように、以下の環境変数をテンプレートに定義します。

変数名説明デフォルト

MYSQL_MASTER_USER

レプリケーションユーザーのユーザー名

master

MYSQL_MASTER_PASSWORD

レプリケーションユーザーのパスワード

generated

例3.1 サンプルテンプレートでの MySQL マスターデプロイメント設定のオブジェクト定義

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "mysql-master"
spec:
  strategy:
    type: "Recreate"
  triggers:
    - type: "ConfigChange"
  replicas: 1
  selector:
    name: "mysql-master"
  template:
    metadata:
      labels:
        name: "mysql-master"
    spec:
      volumes:
        - name: "mysql-master-data"
          persistentVolumeClaim:
            claimName: "mysql-master"
      containers:
        - name: "server"
          image: "openshift/mysql-56-centos7"
          command:
            - "run-mysqld-master"
          ports:
            - containerPort: 3306
              protocol: "TCP"
          env:
            - name: "MYSQL_MASTER_USER"
              value: "${MYSQL_MASTER_USER}"
            - name: "MYSQL_MASTER_PASSWORD"
              value: "${MYSQL_MASTER_PASSWORD}"
            - name: "MYSQL_USER"
              value: "${MYSQL_USER}"
            - name: "MYSQL_PASSWORD"
              value: "${MYSQL_PASSWORD}"
            - name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"
            - name: "MYSQL_ROOT_PASSWORD"
              value: "${MYSQL_ROOT_PASSWORD}"
          volumeMounts:
            - name: "mysql-master-data"
              mountPath: "/var/lib/mysql/data"
          resources: {}
          terminationMessagePath: "/dev/termination-log"
          imagePullPolicy: "IfNotPresent"
          securityContext:
            capabilities: {}
            privileged: false
      restartPolicy: "Always"
      dnsPolicy: "ClusterFirst"

デプロイメント設定で永続ボリュームを要求し、MySQL マスターサーバー用に全データを永続化したため、ストレージを要求できる永続ボリュームを作成するように、クラスター管理者に依頼する必要があります。

デプロイメント設定を作成し、MySQL マスターサーバーが指定された Pod を起動した後には、MYSQL_DATABASE で定義されたデータベースが作成され、このデータベースをスレーブに複製するようにサーバーが設定されます。

提供されているサンプルでは、MySQL マスターサーバーのレプリカ 1 つのみが定義されているため、OpenShift Container Platform はサーバーの 1 つのインスタンスのみを起動します。複数のインスタンス (マルチマスター) はサポートされていないため、このレプリケーションコントローラーはスケーリングできません。

テンプレートにデプロイメント設定を定義して、MySQL マスターで作成したデータベースを複製します。このデプロイメント設定は、command フィールドが run-mysqld-slave に設定されている、MySQL イメージを起動するレプリケーションコントローラーを作成します。このもう 1 つのエントリーポイントでは、データベースの初期化をスキップし、MySQL サーバーが mysql-master サービスに接続するように設定します。これについても、サンプルのテンプレートに定義されています。

例3.2 サンプルテンプレートでの MySQL スレーブデプロイメント設定のオブジェクト定義

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "mysql-slave"
spec:
  strategy:
    type: "Recreate"
  triggers:
    - type: "ConfigChange"
  replicas: 1
  selector:
    name: "mysql-slave"
  template:
    metadata:
      labels:
        name: "mysql-slave"
    spec:
      containers:
        - name: "server"
          image: "openshift/mysql-56-centos7"
          command:
            - "run-mysqld-slave"
          ports:
            - containerPort: 3306
              protocol: "TCP"
          env:
            - name: "MYSQL_MASTER_USER"
              value: "${MYSQL_MASTER_USER}"
            - name: "MYSQL_MASTER_PASSWORD"
              value: "${MYSQL_MASTER_PASSWORD}"
            - name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"
          resources: {}
          terminationMessagePath: "/dev/termination-log"
          imagePullPolicy: "IfNotPresent"
          securityContext:
            capabilities: {}
            privileged: false
      restartPolicy: "Always"
      dnsPolicy: "ClusterFirst"

このデプロイメント設定のサンプルでは、最初のレプリカ数を 1 に設定して、レプリケーションコントローラーを開始します。アカウントのリソース容量に達するまで、両方向にこのレプリケーションコントローラーをスケーリングできます。

3.2.6.2. ヘッドレスサービスの作成

MySQL スレーブのレプリケーションコントローラーで作成した Pod は、レプリケーションを登録するために、MySQL マスターサーバーに到達する必要があります。この目的のために、サンプルテンプレートでは、mysql-master と呼ばれるヘッドレスサービスを定義します。このサービスは、レプリケーションだけに使用するのではなく、クライアントは MySQL ホストとして mysql-master:3306 にクエリーも送信します。

ヘッドレスサービスを含めるには、サービス定義の portalIP パラメーターを None に設定します。このように設定すると、DNS クエリーを使用して、このサービスの現在のエンドポイントを表す Pod の IP アドレス一覧を取得できるようになります。

例3.3 サンプルテンプレートでのヘッドレスサービスのオブジェクト定義

kind: "Service"
apiVersion: "v1"
metadata:
  name: "mysql-master"
  labels:
    name: "mysql-master"
spec:
  ports:
    - protocol: "TCP"
      port: 3306
      targetPort: 3306
      nodePort: 0
  selector:
    name: "mysql-master"
  portalIP: "None"
  type: "ClusterIP"
  sessionAffinity: "None"
status:
  loadBalancer: {}

3.2.6.3. MySQL スレーブのスケーリング

クラスターのメンバー数を増やすには、以下を実行します。

$ oc scale rc mysql-slave-1 --replicas=<number>

このコマンドは、レプリケーションコントローラーに対して、新しい MySQL スレーブ Pod を作成するように指示します。新しいスレーブが作成されると、スレーブのエントリーポイントが最初に mysql-master サービスに問い合わせして、レプリケーションセットに登録しようとします。これが完了すると、MySQL マスターサーバーはスレーブに複製されたデータベースを送信します。

スケールダウン時には、MySQL スレーブがシャットダウンされ、スレーブに永続ストレージが定義されていないので、スレーブ上の全データが失われます。MySQL マスターサーバーは、スレーブに到達できないことを検出し、自動的にレプリケーションからそのスレーブを取り除きます。

3.2.7. トラブルシューティング

以下のセクションでは、発生する可能性のある問題と、考えられる解決策を説明します。

3.2.7.1. Linux ネイティブの AIO の障害

現象

MySQL コンテナーが起動に失敗し、以下のようなログを出力します。

151113  5:06:56 InnoDB: Using Linux native AIO
151113  5:06:56  InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() attempt 1 failed.
InnoDB: Warning: io_setup() attempt 2 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 3 failed.
InnoDB: Warning: io_setup() attempt 4 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 5 failed.
151113  5:06:59  InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
InnoDB: You can disable Linux Native AIO by setting innodb_use_native_aio = 0 in my.cnf
151113  5:06:59 InnoDB: Fatal error: cannot initialize AIO sub-system
151113  5:06:59 [ERROR] Plugin 'InnoDB' init function returned error.
151113  5:06:59 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151113  5:06:59 [ERROR] Unknown/unsupported storage engine: InnoDB
151113  5:06:59 [ERROR] Aborting

説明

MySQL のストレージエンジンは、リソース制限が原因で、カーネルの AIO (非同期 I/O) 機能を使用できませんでした。

解決策

環境変数 MYSQL_AIO の値を 0 に設定して、AIO の使用を完全に停止します。今後のデプロイメントでは、この設定により MySQL の設定変数 innodb_use_native_aio の値が 0 に指定されます。

または aio-max-nr カーネルリソースを増やします。以下の例では、現在の aio-max-nr の値を検証して、この値を 2 倍にします。

$ sysctl fs.aio-max-nr
fs.aio-max-nr = 1048576
# sysctl -w fs.aio-max-nr=2097152

これはノードごとの解決策であるため、次にノードが再起動されるまで有効です。

3.3. PostgreSQL

3.3.1. 概要

OpenShift Container Platform には、PostgreSQL の実行用のコンテナーイメージがあります。このイメージでは、設定で指定されるユーザー名、パスワード、データベース名を基にデータベースサービスが提供されます。

3.3.2. バージョン

現時点で、OpenShift Container Platform は PostgreSQL バージョン 9.4 および 9.5 をサポートします。

3.3.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/rhscl/postgresql-94-rhel7
$ docker pull registry.redhat.io/rhscl/postgresql-95-rhel7

CentOS 7 ベースのイメージ

これらのイメージは、Docker Hub で入手できます。

$ docker pull centos/postgresql-94-centos7
$ docker pull centos/postgresql-95-centos7

これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリーにプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する ImageStream を作成することもでき、OpenShift Container Platform リソースがこの ImageStream を参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して ImageStream の 定義例 があります。

3.3.4. 設定および用途

3.3.4.1. データベースの初期化

共有ボリュームを初めて使用する場合には、データベース、データベースの管理ユーザー、PostgreSQL root ユーザー (POSTGRESQL_ADMIN_PASSWORD 環境変数を指定した場合) が作成され、次に PostgreSQL デーモンが起動します。別のコンテナーにボリュームを再アタッチする場合には、データベース、データベースユーザー、管理者ユーザーは作成されず、PostgreSQL デーモンが起動します。

以下のコマンドは、新しいデータベースの Pod を作成し、さらにコンテナー内で PostgreSQL を実行します。

$ oc new-app \
    -e POSTGRESQL_USER=<username> \
    -e POSTGRESQL_PASSWORD=<password> \
    -e POSTGRESQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/postgresql-95-rhel7

3.3.4.2. コンテナーでの PostgreSQL コマンドの実行

OpenShift Container Platform は Software Collections (SCL) を使用して、PostgreSQL をインストール、起動します。(デバッグ用に) 実行中のコンテナー内で PostgreSQL コマンドを実行する場合には bash を使用して呼び出す必要があります。

これには、まず、実行中の PostgreSQL Pod の名前を特定します。たとえば、現在のプロジェクトで Pod の一覧を表示できます。

$ oc get pods

次に、任意の Pod に対してリモートシェルセッションを開きます。

$ oc rsh <pod>

コンテナーに入ると、必要な SCL が自動的に有効になります。

Bash シェルから psql コマンドを実行し、PostgreSQL の対話セッションを開始して通常の PostgreSQL 操作が実行できるようになりました。たとえば、データベースユーザーとして認証するには、以下を実行します。

bash-4.2$ PGPASSWORD=$POSTGRESQL_PASSWORD psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER
psql (9.5.16)
Type "help" for help.

default=>

完了したら、\q と入力して PostgreSQL セッションを終了します。

3.3.4.3. 環境変数

PostgreSQL ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。

表3.3 PostgreSQL 環境変数

変数名説明

POSTGRESQL_USER

作成予定の PostgreSQL アカウントのユーザー名。このユーザーには、対象のデータベースに対する完全な権限があります。

POSTGRESQL_PASSWORD

ユーザーアカウントのパスワード

POSTGRESQL_DATABASE

データベース名

POSTGRESQL_ADMIN_PASSWORD

postgres 管理ユーザーの任意パスワード。これが設定されていない場合には、postgres アカウントにリモートからログインができません。コンテナーからはいつでも、パスワードなしにローカル接続が可能です。

警告

ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。

PostgreSQL 設定は、以下の環境変数で設定できます。

表3.4 PostgreSQL の他の設定

変数名説明デフォルト

POSTGRESQL_MAX_CONNECTIONS

許容範囲の最大クライアント接続数

100

POSTGRESQL_MAX_PREPARED_TRANSACTIONS

「準備」状態にすることのできる最大トランザクション数。準備状態のトランザクションを使用する場合には、値は POSTGRESQL_MAX_CONNECTIONS 以上に指定する必要があります。

0

POSTGRESQL_SHARED_BUFFERS

データのキャッシュ用に PostgreSQL 専用に割り当てられたメモリー量

32M

POSTGRESQL_EFFECTIVE_CACHE_SIZE

オペレーティングシステム別または PostgreSQL 自体で、ディスクキャッシュに利用可能な予想メモリー量

128M

3.3.4.4. ボリュームのマウントポイント

PostgreSQL イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。

  • /var/lib/pgsql/data: これは、PostgreSQL がデータベースファイルを保存するデータベースクラスターのディレクトリーです。

3.3.4.5. パスワードの変更

パスワードはイメージ設定の一部であるため、データベースユーザー (POSTGRESQL_USER) と postgres 管理者ユーザーのパスワードを変更する唯一のサポートされている方法として、環境変数 POSTGRESQL_PASSWORDPOSTGRESQL_ADMIN_PASSWORD をそれぞれ変更することができます。

現在のパスワードは、Pod またはデプロイメント設定を Web コンソールで表示するか、CLI で環境変数を表示して、確認できます。

$ oc set env pod <pod_name> --list

SQL ステートメントや、前述した環境変数以外の方法でデータベースのパスワードを変更すると、変数に保存されている値と、実際のパスワードが一致しなくなる可能性があります。データベースコンテナーが起動するたびに、パスワードは環境変数に保存されている値にリセットされます。

これらのパスワードを変更するには、oc set env コマンドを使用して、関連するデプロイメント設定の任意の環境変数 1 つまたは両方を更新します。たとえば、テンプレートからアプリケーションを作成する場合など、複数のデプロイメント設定がこれらの環境変数を使用する場合には、デプロイメント設定ごとに変数を更新し、パスワードがどこでも同期されるようにします。これは、すべて同じコマンドで実行できます。

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  POSTGRESQL_PASSWORD=<new_password> \
  POSTGRESQL_ADMIN_PASSWORD=<new_admin_password>
重要

アプリケーションによっては、アプリケーションの他の場所にあるパスワードの他の環境変数を更新して一致させる必要があるものもあります。たとえば、フロントエンド Pod のより一般的な DATABASE_USER 変数などは、データベースユーザーのパスワードと一致する必要がある場合があります。必要とされる環境変数すべてにおいて、パスワードがアプリケーションごとに一致しているようにしてください。一致しない場合には、トリガーされた時点で、Pod の再デプロイメントが失敗する場合があります。

設定変更トリガーが設定されている場合には、環境変数を更新すると、データベースサーバーの再デプロイメントがトリガーされます。設定されていない場合には、新しいデプロイメントを手動で起動して、パスワードの変更を適用する必要があります。

新規パスワードが有効になっていることを確認するには、まず、実行中の PostgreSQL Pod に対してリモートシェルセッションを開きます。

$ oc rsh <pod>

Bash シェルから、データベースユーザーの新規パスワードを確認します。

bash-4.2$ PGPASSWORD=<new_password> psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

 current_database | current_user
------------------+--------------
 default          | django
(1 row)

Bash シェルから postgres 管理者ユーザーの新規パスワードを検証します。

bash-4.2$ PGPASSWORD=<new_admin_password> psql -h postgresql $POSTGRESQL_DATABASE postgres -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

 current_database | current_user
------------------+--------------
 default          | postgres
(1 row)

3.3.5. テンプレートからのデータベースサービスの作成

OpenShift Container Platform には テンプレート が含まれており、新規データベースサービスの作成を簡素化します。テンプレートには、必須の環境変数をすべて定義するパラメーターフィールドがあり (ユーザー、パスワード、データベース名など)、自動生成されたパスワード値など、事前定義済みのデフォルト値が設定されます。また、テンプレートは デプロイメント設定 および サービス の両方を定義します。

PostgreSQL テンプレートは、クラスターの初期設定時にクラスター管理者により、デフォルトの openshift プロジェクトに登録しておく必要があります。詳細については、必要に応じて、「デフォルトのイメージストリームおよびテンプレートの読み込み」を参照してください。

利用可能なテンプレートは以下の 2 種類です。

  • PostgreSQL-ephemeral は、データベースのコンテンツ用に一時ストレージを使用するので、開発またはテスト目的にのみ使用します。つまり、Pod が別の Pod に移動されたり、デプロイメント設定が更新され、再デプロイがトリガーされたりなど、データベース Pod が何らかの理由で再起動された場合には、データはすべて失われます。
  • PostgreSQL-persistent は、データベースのデータ用に永続ボリュームストアを使用するので、データは Pod が再起動されても残ります。永続ボリュームを使用する場合には、OpenShift Container Platform デプロイメントで定義された永続ボリュームプールが必要です。プールの設定に関するクラスター管理者向けの説明は、こちらを参照してください。

この説明に従い、テンプレートをインスタンス化できます。

サービスをインスタンス化したら、データベースにアクセスする予定のある別のコンポーネントのデプロイメント設定に、ユーザー名、パスワード、データベース名の環境変数をコピーできます。このコンポーネントは、定義したサービスを使用してこのデータベースにアクセスできます。

3.4. MongoDB

3.4.1. 概要

OpenShift Container Platform には、MongoDB の実行用のコンテナーイメージがあります。このイメージでは、設定で指定されるユーザー名、パスワード、データベース名に基づくデータベースサービスが提供されます。

3.4.2. バージョン

現時点で、OpenShift Container Platform では、MongoDB のバージョン 2.63.2 および 3.4 を提供しています。

3.4.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/rhscl/mongodb-26-rhel7
$ docker pull registry.redhat.io/rhscl/mongodb-32-rhel7
$ docker pull registry.redhat.io/rhscl/mongodb-34-rhel7

CentOS 7 ベースのイメージ

これらのイメージは、Docker Hub で入手できます。

$ docker pull centos/mongodb-26-centos7
$ docker pull centos/mongodb-32-centos7
$ docker pull centos/mongodb-34-centos7

これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリーにプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する ImageStream を作成することもでき、OpenShift Container Platform リソースがこの ImageStream を参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して ImageStream の 定義例 があります。

3.4.4. 設定および用途

3.4.4.1. データベースの初期化

MongoDB は、一時ボリュームまたは永続ボリュームで設定できます。ボリュームを初めて使用する場合には、データベースとデータベースの管理ユーザーが作成され、次に MongoDB デーモンが起動します。別のコンテナーにボリュームを再アタッチする場合には、データベース、データベースユーザー、管理者ユーザーは作成されず、MongoDB デーモンが起動します。

以下のコマンドは、新しいデータベースの Pod を作成し、さらに一時ボリュームが含まれるコンテナー内で MongoDB を実行します。

$ oc new-app \
    -e MONGODB_USER=<username> \
    -e MONGODB_PASSWORD=<password> \
    -e MONGODB_DATABASE=<database_name> \
    -e MONGODB_ADMIN_PASSWORD=<admin_password> \
    registry.redhat.io/rhscl/mongodb-26-rhel7

3.4.4.2. コンテナーでの MongoDB コマンドの実行

OpenShift Container Platform は Software Collections (SCL) を使用して、MongoDB をインストールし、起動します。(デバッグ用に) 実行中のコンテナー内で MongoDB コマンドを実行する場合には bash を使用して呼び出す必要があります。

これを実行するには、まず 実行中の MongoDB Pod の名前を特定します。たとえば、現在のプロジェクトで Pod の一覧を表示できます。

$ oc get pods

次に、任意の Pod に対してリモートシェルセッションを開きます。

$ oc rsh <pod>

コンテナーに入ると、必要な SCL が自動的に有効になります。

Bash シェルから mongo コマンドを実行し、MongoDB の対話セッションを開始して通常の MongoDB 操作が実行できるようになりました。たとえば、sampledb データベースに切り替えてデータベースユーザーとして認証するには、以下を実行します。

bash-4.2$ mongo -u $MONGODB_USER -p $MONGODB_PASSWORD $MONGODB_DATABASE
MongoDB shell version: 2.6.9
connecting to: sampledb
>

完了したら、CTRL+D を押して、MongoDB セッションを終了します。

3.4.4.3. 環境変数

MongoDB ユーザー名、パスワード、データベース名および admin のパスワードは、以下の環境変数で設定する必要があります。

表3.5 MongoDB 環境変数

変数名説明

MONGODB_USER

作成する MongoDB アカウントのユーザー名

MONGODB_PASSWORD

ユーザーアカウントのパスワード

MONGODB_DATABASE

データベース名

MONGODB_ADMIN_PASSWORD

admin ユーザーのパスワード

警告

ユーザー名、パスワード、データベース名および admin パスワードを指定する必要があります。この 4 つすべてを指定しない場合には、Pod は起動できず、OpenShift Container Platform は継続して Pod の再起動を試行します。

注記

管理者のユーザー名は admin に設定されます。admin のパスワードは、MONGODB_ADMIN_PASSWORD 環境変数で設定する必要があります。このプロセスは、データベースの初期化の実行時に行います。

MongoDB 設定は、以下の環境変数で設定できます。

表3.6 MongoDB の他の設定

変数名説明デフォルト

MONGODB_NOPREALLOC

データファイルの事前割り当てを無効にします。

true

MONGODB_SMALLFILES

MongoDB がより小さなデータファイルサイズを使用するようにデフォルト設定します。

true

MONGODB_QUIET

MongoDB を Quiet モードで実行して、出力量を制限しようとします。

true

注記

テキスト検索は、MongoDB バージョン 2.6 以降ではデフォルトで有効になっているので、設定可能なパラメーターはありません。

3.4.4.4. ボリュームのマウントポイント

MongoDB イメージはマウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。

  • /var/lib/mongodb/data: これは、MongoDB がデータベースファイルを保存するデータベースのディレクトリーです。

3.4.4.5. パスワードの変更

パスワードはイメージ設定の一部であるため、データベースユーザー (MONGODB_USER) と admin ユーザーのパスワードを変更するための唯一のサポートされている方法とし、環境変数 MONGODB_PASSWORDMONGODB_ADMIN_PASSWORD をそれぞれ変更することができます。

現在のパスワードは、Pod またはデプロイメント設定を Web コンソールで表示するか、CLI で環境変数を表示して、確認できます。

$ oc set env pod <pod_name> --list

MongoDB で直接データベースのパスワードを変更すると、変数に保存されている値と実際のパスワードが一致しなくなる可能性があります。データベースコンテナーが起動するたびに、パスワードは環境変数に保存されている値にリセットされます。

これらのパスワードを変更するには、oc set env コマンドを使用して、関連するデプロイメント設定の任意の環境変数 1 つまたは両方を更新します。たとえば、テンプレートからアプリケーションを作成する場合など、複数のデプロイメント設定がこれらの環境変数を使用する場合には、デプロイメント設定ごとに変数を更新し、パスワードがどこでも同期されるようにします。これは、すべて同じコマンドで実行できます。

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MONGODB_PASSWORD=<new_password> \
  MONGODB_ADMIN_PASSWORD=<new_admin_password>
重要

アプリケーションによっては、アプリケーションの他の場所にあるパスワードの他の環境変数を更新して一致させる必要があるものもあります。たとえば、フロントエンド Pod のより一般的な DATABASE_USER 変数などは、データベースユーザーのパスワードと一致する必要がある場合があります。必要とされる環境変数すべてにおいて、パスワードがアプリケーションごとに一致しているようにしてください。一致しない場合には、トリガーされた時点で、Pod の再デプロイメントが失敗する場合があります。

設定変更トリガーが設定されている場合には、環境変数を更新すると、データベースサーバーの再デプロイメントがトリガーされます。設定されていない場合には、新しいデプロイメントを手動で起動して、パスワードの変更を適用する必要があります。

新規パスワードが有効になっていることを確認するには、まず、実行中の MongoDB Pod に対してリモートシェルセッションを開きます。

$ oc rsh <pod>

Bash シェルから、データベースユーザーの新規パスワードを確認します。

bash-4.2$ mongo -u $MONGODB_USER -p <new_password> $MONGODB_DATABASE --eval "db.version()"

パスワードが正しく変更された場合には、以下のような出力が表示されるはずです。

MongoDB shell version: 2.6.9
connecting to: sampledb
2.6.9

admin ユーザーの新規パスワードを確認するには、以下を実行します。

bash-4.2$ mongo -u admin -p <new_admin_password> admin --eval "db.version()"

パスワードが正しく変更された場合には、以下のような出力が表示されるはずです。

MongoDB shell version: 2.6.9
connecting to: admin
2.6.9

3.4.5. テンプレートからのデータベースサービスの作成

OpenShift Container Platform には テンプレート が含まれており、新規データベースサービスの作成を簡素化します。テンプレートには、必須の環境変数をすべて定義するパラメーターフィールドがあり (ユーザー、パスワード、データベース名など)、自動生成されたパスワード値など、事前定義済みのデフォルト値が設定されます。また、テンプレートは デプロイメント設定 および サービス の両方を定義します。

MongoDB テンプレートは、クラスターの初期設定時にクラスター管理者により、デフォルトの openshift プロジェクトに登録しておく必要があります。詳細については、必要に応じて、「デフォルトのイメージストリームおよびテンプレートの読み込み」を参照してください。

利用可能なテンプレートは以下の 2 種類です。

  • mongodb-ephemeral は、データベースのコンテンツ用に一時ストレージを使用するので、開発またはテスト目的にのみ使用します。つまり、Pod が別の Pod に移動されたり、デプロイメント設定が更新され、再デプロイがトリガーされたりなど、データベース Pod が何らかの理由で再起動された場合には、データはすべて失われます。
  • mongodb-persistent は、データベースのデータ用に永続ボリュームストアを使用するので、データは Pod が再起動されても残ります。永続ボリュームを使用する場合には、OpenShift Container Platform デプロイメントで定義された永続ボリュームプールが必要です。プールの設定に関するクラスター管理者向けの説明は、こちらを参照してください。

この説明に従い、テンプレートをインスタンス化できます。

サービスをインスタンス化したら、データベースにアクセスする予定のある別のコンポーネントのデプロイメント設定に、ユーザー名、パスワード、データベース名の環境変数をコピーできます。このコンポーネントは、定義したサービスを使用してこのデータベースにアクセスできます。

3.4.6. MongoDB レプリケーション

注記

現在、テクノロジープレビューとして、データベースイメージ用にクラスター化を有効にできますが、この機能は実稼働環境での使用を目的としていません。

Red Hat は、StatefulSet を使用した MongoDB のレプリケーション (クラスタリング) 用に、概念実証 テンプレートを提供します。GitHub からサンプルテンプレート を入手できます。

たとえば、現在のプロジェクトのテンプレートライブラリーにテンプレートのサンプルをアップロードするには、以下を実行します。

$ oc create -f \
    https://raw.githubusercontent.com/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml
重要

以下のテンプレートサンプルでは、永続ストレージを使用します。このテンプレートを使用するには、クラスターで永続ボリュームが利用できるようにする必要があります。

OpenShift Container Platform は正常でない Pod (コンテナー) を自動的に再起動するので、レプリカセットのメンバーの 1 つまたは複数で、クラッシュまたは障害が発生すると、レプリカセットメンバーは再起動されます。

レプリカセットのメンバーがダウンまたは再起動している場合に考えられるシナリオは以下のいずれかです。

  1. プライマリーメンバーがダウンしている:

    このような場合には、他の 2 つのメンバーが新しいプライマリーを選択します。新しいプライマリーが選択されるまで、読み取りには影響はありませんが、書き込みが失敗してしまいます。正常に選択された後には、書き込みおよび読み取りは通常通りに処理されます。

  2. セカンダリーメンバーの 1 つがダウンしている:

    読み取りおよび書き込みには影響はありません。oplogSize 設定と書き込み速度によって、3 番目のメンバーがレプリカセットへの参加に失敗する可能性があるため、手動の介入によりデータベースのコピーをもう一度同期する必要があります。

  3. 2 つのメンバーがダウンしている:

    3 つのメンバーで構成されるレプリカセットメンバーが他のメンバーに到達できない場合には、プライマリーロールが指定されていれば、そのロールが取り消されます。このような場合には、読み取りはセカンダリーメンバーが行い、書き込みに失敗します。他のメンバーが 1 つでも起動したらすぐに、新しいプライマリーメンバーが選択され、読み取りおよび書き込みが通常通りに処理されます。

  4. 全メンバーがダウンしている:

    このように極端な場合は、読み取りおよび書き込み両方に失敗します。2 つ以上のメンバーが起動してくると、レプリカセットメンバーにプライマリーとセカンダリーメンバーが含まれるように選択が行われ、その後に読み取りと書き込みが通常通りに処理されます。

これが MongoDB の推奨のレプリケーションストラテジーです。

注記

実稼働環境の場合には、できるだけメンバー間の分離を確保する必要があります。StatefulSet Pod を異なるノードにスケジューリングするノード選択機能を 1 つまたは複数使用し、個別のボリュームでサポートされるストレージを提供することを推奨します。

3.4.6.1. 制限

  • MongoDB 3.2 のみがサポートされます。
  • スケールダウンする場合には、レプリカセットの設定は手動で更新する必要があります。
  • ユーザーおよび管理者のパスワードの変更は手動のプロセスで行います。以下を実行する必要があります。

    • StatefulSet 設定の環境変数の値を更新する
    • データベースのパスワードを変更する
    • 順次 Pod をすべて再起動する

3.4.6.2. サンプルテンプレートの使用

事前作成されている永続ボリューム 3 つあり、永続ボリュームのプロビジョニングが設定されていることを前提とします。

  1. MongoDB クラスターを作成する新規プロジェクトを作成します。

    $ oc new-project mongodb-cluster-example
  2. サンプルテンプレートを使用して新規アプリケーションを作成します。

    $ oc new-app https://raw.githubusercontent.com/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml

    このコマンドでは、3 つのレプリカセットメンバーを含む MongoDB クラスターが作成されました。

  3. 新規の MongoDB Pod のステータスを確認します。

    $ oc get pods
    NAME        READY     STATUS    RESTARTS   AGE
    mongodb-0   1/1       Running   0          50s
    mongodb-1   1/1       Running   0          50s
    mongodb-2   1/1       Running   0          49s

サンプルのテンプレートからクラスターを作成すると、3 つのメンバーを含むレプリカセットが作成されます。Pod が実行されると、以下のようにこれらの Pod でさまざまなアクションを実行できます。

  • Pod の 1 つのログを確認します。

    $ oc logs mongodb-0
  • Pod にログインします。

    $ oc rsh mongodb-0
    sh-4.2$
  • MongoDB インスタンスにログインします。

    sh-4.2$ mongo $MONGODB_DATABASE -u $MONGODB_USER -p$MONGODB_PASSWORD
    MongoDB shell version: 3.2.6
    connecting to: sampledb
    rs0:PRIMARY>

3.4.6.3. スケールアップ

MongoDB は、レプリカセット内に奇数の数のメンバーを指定することを推奨します。永続ボリュームが十分に存在し、動的ストレージプロビジョナーがある場合には、oc scale を使用してスケールアップを行います。

$ oc scale --replicas=5 statefulsets/mongodb

$ oc get pods
NAME        READY     STATUS    RESTARTS   AGE
mongodb-0   1/1       Running   0          9m
mongodb-1   1/1       Running   0          8m
mongodb-2   1/1       Running   0          8m
mongodb-3   1/1       Running   0          1m
mongodb-4   1/1       Running   0          57s

これにより、レプリカセットと接続する新規 Pod が作成され、設定が更新されます。

注記

oplogSize 設定よりもデータベースのサイズが大きい場合には、既存のデータベースは手動でスケールアップする必要があります。このような場合には、新規メンバーの初回同期を手動で行う必要があります。詳しい情報は、「Check the Size of the Oplog」および「MongoDB Replication」ドキュメントを参照してください。

3.4.6.4. スケールダウン

レプリカセットをスケールダウンするには、メンバー数を 5 つから 3 つ、または 3 つから 1 つのみに変更することができます。

前提条件 (ストレージの空き容量、既存のデータベースのサイズ、oplogSize) を満たす場合には、手動での介入なしにスケールアップができますが、スケールダウンは常に手動での介入が必要です。

スケールダウンを実行するには、以下を実行します。

  1. oc scale コマンドを使用して、新しいレプリカ数を設定します。

    $ oc scale --replicas=3 statefulsets/mongodb

    新しいレプリカ数が以前の数の過半数を占める場合には、削除された Pod の 1 つに、プライマリーメンバーロールを指定されていた時のために、レプリカセットにより新しいプライマリーが選択される場合があります。たとえば、メンバーを 5 から 3 にスケールダウンする場合などです。

    また、少ない数にスケールダウンすると一時的に、レプリカセットに含まれるのがセカンダリーメンバーだけで、読み取り専用モードとなることがあります。たとえば、メンバーを 5 から 1 にスケールダウンする場合などです。

  2. 存在しなくなったメンバーを削除するように、レプリカセットの設定を更新します。

    これは、レプリカ数の検査 (downward API 経由で公開) や StatefulSet から削除された Pod を判断する PreStop Pod フックを設定し、それ以外の理由で再起動されないようにする実装など、今後改善される可能性があります。

  3. 無効になった Pod が使用するボリュームを消去します。

3.5. MariaDB

3.5.1. 概要

OpenShift Container Platform には、MariaDB の実行用のコンテナーイメージがあります。このイメージでは、設定ファイルで指定されるユーザー名、パスワード、データベース名の設定に基づいてデータベースサービスが提供されます。

3.5.2. バージョン

現時点では、OpenShift Container Platform は MariaDB のバージョン 10.0 および 10.1 をサポートします。

3.5.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/rhscl/mariadb-100-rhel7
$ docker pull registry.redhat.io/rhscl/mariadb-101-rhel7

CentOS 7 ベースのイメージ

これらのイメージは、Docker Hub で入手できます。

$ docker pull openshift/mariadb-100-centos7
$ docker pull centos/mariadb-101-centos7

これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリーにプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する ImageStream を作成することもでき、OpenShift Container Platform リソースがこの ImageStream を参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して ImageStream の 定義例 があります。

3.5.4. 設定および用途

3.5.4.1. データベースの初期化

共有ボリュームを初めて使用する場合には、データベース、データベースの管理ユーザー、MariaDB root ユーザー (MYSQL_ROOT_PASSWORD 環境変数を指定した場合) が作成され、次に MariaDB デーモンが起動します。別のコンテナーにボリュームを再アタッチする場合には、データベース、データベースユーザー、管理者ユーザーは作成されず、MariaDB デーモンが起動します。

以下のコマンドは、新しいデータベースの Pod を作成し、さらにコンテナー内で MariaDB を実行します。

$ oc new-app \
    -e MYSQL_USER=<username> \
    -e MYSQL_PASSWORD=<password> \
    -e MYSQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/mariadb-101-rhel7

3.5.4.2. コンテナーでの MariaDB コマンドの実行

OpenShift Container Platform は Software Collections (SCL) を使用して、MariaDB をインストール、起動します。(デバッグ用に) 実行中のコンテナー内で MariaDB コマンドを実行する場合には bash を使用して呼び出す必要があります。

これを実行するには、まず、実行中の MariaDB Pod の名前を特定します。たとえば、現在のプロジェクトで Pod の一覧を表示できます。

$ oc get pods

次に、Pod に対してリモートシェルセッションを開始します。

$ oc rsh <pod>

コンテナーに入ると、必要な SCL が自動的に有効になります。

Bash シェルから mysql コマンドを実行し、MariaDB の対話セッションを開始して通常の MariaDB 操作が実行できるようになりました。たとえば、データベースユーザーとして認証するには、以下を実行します。

bash-4.2$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -h $HOSTNAME $MYSQL_DATABASE
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.5.37 MySQL Community Server (GPL)
...
mysql>

完了したら、quit または exit を入力して MySQL セッションを終了します。

3.5.4.3. 環境変数

MariaDB ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。

表3.7 MariaDB 環境変数

変数名説明

MYSQL_USER

作成する MySQL アカウントのユーザー名

MYSQL_PASSWORD

ユーザーアカウントのパスワード

MYSQL_DATABASE

データベース名

MYSQL_ROOT_PASSWORD

root ユーザーのパスワード (オプション)

警告

ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。

MariaDB 設定は、以下の環境変数で設定できます。

表3.8 MariaDB の他の設定

変数名説明デフォルト

MYSQL_LOWER_CASE_TABLE_NAMES

テーブル名の保存および比較方法を設定します。

0

MYSQL_MAX_CONNECTIONS

クライアントが同時に接続可能な最大数

151

MYSQL_MAX_ALLOWED_PACKET

生成された文字列/中間文字列または 1 つのパケットの最大サイズ

200M

MYSQL_FT_MIN_WORD_LEN

FULLTEXT インデックスに含める文字の最小長

4

MYSQL_FT_MAX_WORD_LEN

FULLTEXT インデックスに含める文字の最大長

20

MYSQL_AIO

ネイティブの AIO が壊れている場合に innodb_use_native_aio の設定値を制御します。

1

MYSQL_TABLE_OPEN_CACHE

全スレッド用に開くテーブル数

400

MYSQL_KEY_BUFFER_SIZE

インデックスブロックに使用するバッファーサイズ

32M (または利用可能なメモリーの 10%)

MYSQL_SORT_BUFFER_SIZE

分類に使用するバッファーサイズ

256K

MYSQL_READ_BUFFER_SIZE

シーケンススキャンに使用するバッファーサイズ

8M (または利用可能メモリーの 5%)

MYSQL_INNODB_BUFFER_POOL_SIZE

InnoDB がテーブルやインデックスデータをキャッシュするバッファープールのサイズ

32M (または利用可能なメモリーの 50%)

MYSQL_INNODB_LOG_FILE_SIZE

ロググループにある各ログファイルのサイズ

8M (または利用可能メモリーの 15%)

MYSQL_INNODB_LOG_BUFFER_SIZE

InnoDB がディスクのログファイルへの書き込みに使用するバッファーサイズ

8M (または利用可能メモリーの 15%)

MYSQL_DEFAULTS_FILE

別の設定ファイルを参照します。

/etc/my.cnf

MYSQL_BINLOG_FORMAT

binlog 形式で設定します。サポートされる値は、row および statement です。

statement

3.5.4.4. ボリュームのマウントポイント

MariaDB イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。

  • /var/lib/mysql/data: MySQL のデータディレクトリーは、MariaDB がデータベースファイルを保存する場所にあります。
注記

ホストからコンテナーにディレクトリーをマウントする場合には、マウントしたディレクトリーに適切なパーミッションが設定されていることを確認してください。また、ディレクトリーの所有者とグループが、コンテナー内で実行中のユーザー名と一致することを確認します。

3.5.4.5. パスワードの変更

パスワードはイメージ設定の一部であるため、データベースユーザー (MYSQL_USER) と admin ユーザーのパスワードを変更するための唯一のサポートされる方法とし、環境変数 MYSQL_PASSWORDMYSQL_ROOT_PASSWORD をそれぞれ変更することができます。

現在のパスワードは、Pod またはデプロイメント設定を Web コンソールで表示するか、CLI で環境変数を表示して、確認できます。

$ oc set env pod <pod_name> --list

SQL ステートメントや、前述した環境変数以外の方法でデータベースのパスワードを変更すると、変数に保存されている値と、実際のパスワードが一致しなくなる可能性があります。データベースコンテナーが起動するたびに、パスワードは環境変数に保存されている値にリセットされます。

これらのパスワードを変更するには、oc set env コマンドを使用して、関連するデプロイメント設定の任意の環境変数 1 つまたは両方を更新します。たとえば、テンプレートからアプリケーションを作成する場合など、複数のデプロイメント設定がこれらの環境変数を使用する場合には、デプロイメント設定ごとに変数を更新し、パスワードがどこでも同期されるようにします。これは、すべて同じコマンドで実行できます。

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MYSQL_PASSWORD=<new_password> \
  MYSQL_ROOT_PASSWORD=<new_root_password>
重要

アプリケーションによっては、アプリケーションの他の場所にあるパスワードの他の環境変数を更新して一致させる必要があるものもあります。たとえば、フロントエンド Pod のより一般的な DATABASE_USER 変数などは、データベースユーザーのパスワードと一致する必要がある場合があります。必要とされる環境変数すべてにおいて、パスワードがアプリケーションごとに一致しているようにしてください。一致しない場合には、トリガーされた時点で、Pod の再デプロイメントが失敗する場合があります。

設定変更トリガーが設定されている場合には、環境変数を更新すると、データベースサーバーの再デプロイメントがトリガーされます。設定されていない場合には、新しいデプロイメントを手動で起動して、パスワードの変更を適用する必要があります。

新規パスワードが有効になっていることを確認するには、まず、実行中の MariaDB Pod へのリモートシェルセッションを開始します。

$ oc rsh <pod>

Bash シェルから、データベースユーザーの新規パスワードを確認します。

bash-4.2$ mysql -u $MYSQL_USER -p<new_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

+------------+---------------------+
| database() | user()              |
+------------+---------------------+
| sampledb   | user0PG@172.17.42.1 |
+------------+---------------------+

root ユーザーの新規パスワードを確認するには、以下を実行します。

bash-4.2$ mysql -u root -p<new_root_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

パスワードが正しく変更された場合には、以下のような表が表示されるはずです。

+------------+------------------+
| database() | user()           |
+------------+------------------+
| sampledb   | root@172.17.42.1 |
+------------+------------------+

3.5.5. テンプレートからのデータベースサービスの作成

OpenShift Container Platform には テンプレート が含まれており、新規データベースサービスの作成を簡素化します。テンプレートには、必須の環境変数をすべて定義するパラメーターフィールドがあり (ユーザー、パスワード、データベース名など)、自動生成されたパスワード値など、事前定義済みのデフォルト値が設定されます。また、テンプレートは デプロイメント設定 および サービス の両方を定義します。

MariaDB テンプレートは、クラスターの初期設定時にクラスター管理者により、デフォルトの openshift プロジェクトに登録しておく必要があります。詳細については、必要に応じて、「デフォルトのイメージストリームおよびテンプレートの読み込み」を参照してください。

利用可能なテンプレートは以下の 2 種類です。

  • mariadb-ephemeral は、データベースのコンテンツ用に一時ストレージを使用するので、開発またはテスト目的にのみ使用します。つまり、Pod が別の Pod に移動されたり、デプロイメント設定が更新され、再デプロイがトリガーされたりなど、データベース Pod が何らかの理由で再起動された場合には、データはすべて失われます。
  • mariadb-persistent は、データベースのデータ用に永続ボリュームストアを使用するので、データは Pod が再起動されても残ります。永続ボリュームを使用する場合には、OpenShift Container Platform デプロイメントで定義された永続ボリュームプールが必要です。プールの設定に関するクラスター管理者向けの説明は、こちらを参照してください。

この説明に従い、テンプレートをインスタンス化できます。

サービスをインスタンス化したら、データベースにアクセスする予定のある別のコンポーネントのデプロイメント設定に、ユーザー名、パスワード、データベース名の環境変数をコピーできます。このコンポーネントは、定義したサービスを使用してこのデータベースにアクセスできます。

3.5.6. トラブルシューティング

以下のセクションでは、発生する可能性のある問題と、考えられる解決策を説明します。

3.5.6.1. Linux ネイティブの AIO の障害

現象

MySQL コンテナーが起動に失敗し、以下のようなログを出力します。

151113  5:06:56 InnoDB: Using Linux native AIO
151113  5:06:56  InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() attempt 1 failed.
InnoDB: Warning: io_setup() attempt 2 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 3 failed.
InnoDB: Warning: io_setup() attempt 4 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 5 failed.
151113  5:06:59  InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
InnoDB: You can disable Linux Native AIO by setting innodb_use_native_aio = 0 in my.cnf
151113  5:06:59 InnoDB: Fatal error: cannot initialize AIO sub-system
151113  5:06:59 [ERROR] Plugin 'InnoDB' init function returned error.
151113  5:06:59 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151113  5:06:59 [ERROR] Unknown/unsupported storage engine: InnoDB
151113  5:06:59 [ERROR] Aborting

説明

MariaDB のストレージエンジンは、リソース制限が原因で、カーネルの AIO (非同期 I/O) 機能を使用できませんでした。

解決策

環境変数 MYSQL_AIO の値を 0 に設定して、AIO の使用を完全に停止します。今後のデプロイメントでは、この設定により MySQL の設定変数 innodb_use_native_aio の値が 0 に指定されます。

または aio-max-nr カーネルリソースを増やします。以下の例では、現在の aio-max-nr の値を検証して、この値を 2 倍にします。

$ sysctl fs.aio-max-nr
fs.aio-max-nr = 1048576
# sysctl -w fs.aio-max-nr=2097152

これはノードごとの解決策であるため、次にノードが再起動されるまで有効です。