第3章 データベースイメージ
3.1. 概要
以下のトピックには、OpenShift Container Platform ユーザーに提供される、さまざまなデータベースイメージに関する情報が含まれます。
現在、テクノロジープレビューとして、データベースイメージ用にクラスター化を有効にできますが、この機能は実稼働環境での使用を目的としていません。
3.2. MySQL
3.2.1. 概要
OpenShift Container Platform には、MySQL の実行用のコンテナーイメージがあります。このイメージでは、設定で指定されるユーザー名、パスワード、データベース名に基づいてデータベースサービスが提供されます。
3.2.2. バージョン
現時点では、OpenShift Container Platform では、MySQL のバージョン 5.5、5.6 および 5.7 を提供しています。
3.2.3. イメージ
イメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/mysql-55-rhel7 $ docker pull registry.access.redhat.com/rhscl/mysql-56-rhel7 $ docker pull registry.access.redhat.com/rhscl/mysql-57-rhel7
CentOS 7 ベースのイメージ
MySQL 5.5 および 5.6 の CentOS イメージは、Docker Hub で入手できます。
$ docker pull openshift/mysql-55-centos7 $ docker pull openshift/mysql-56-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する 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.access.redhat.com/openshift3/mysql-55-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.5.37 MySQL Community Server (GPL) ... mysql>
完了したら、quit または exit を入力して MySQL セッションを終了します。
3.2.4.3. 環境変数
MySQL ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。
変数名 | 説明 |
---|---|
|
アプリケーションで使用するために作成されたデータベースユーザーのユーザー名を指定します。 |
|
|
|
|
|
root ユーザーの任意パスワード。これが設定されていない場合には、root アカウントにリモートログインできません。コンテナーからはいつでも、パスワードなしにローカル接続が可能です。 |
|
Kubernetes が自動作成したサービスホストの変数 |
|
Kubernetes が自動作成したサービスポートの変数 |
ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。
MySQL 設定は、以下の環境変数で設定できます。
変数名 | 説明 | デフォルト |
---|---|---|
|
テーブル名の保存および比較方法を設定します。 |
0 |
|
クライアントが同時に接続可能な最大数 |
151 |
|
生成された文字列/中間文字列または 1 つのパケットの最大サイズ |
200M |
|
FULLTEXT インデックスに含める文字の最小長 |
4 |
|
FULLTEXT インデックスに含める文字の最大長 |
20 |
|
ネイティブの AIO が壊れている場合に innodb_use_native_aio の設定値を制御します。 |
1 |
|
全スレッド用に開くテーブル数 |
400 |
|
インデックスブロックに使用するバッファーサイズ |
32M (または利用可能なメモリーの 10%) |
|
分類に使用するバッファーサイズ |
256K |
|
シーケンススキャンに使用するバッファーサイズ |
8M (または利用可能メモリーの 5%) |
|
InnoDB がテーブルやインデックスデータをキャッシュするバッファープールのサイズ |
32M (または利用可能なメモリーの 50%) |
|
ロググループにある各ログファイルのサイズ |
8M (または利用可能メモリーの 15%) |
|
InnoDB がディスクのログファイルへの書き込みに使用するバッファーサイズ |
8M (または利用可能メモリーの 15%) |
メモリー関連のパラメーターによっては、デフォルト値が 2 つあるものもあります。コンテナーにメモリーの制限が割り当てられていない場合には、固定値が使用されます。他の値は、コンテナーの起動中に利用可能なメモリーを基に動的に計算されます。
3.2.4.4. ボリュームのマウントポイント
MySQL イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。
- /var/lib/mysql/data: これは、MySQL がデータベースのファイルを保存するデータディレクトリーです。
3.2.4.5. パスワードの変更
パスワードはイメージ設定の一部であるため、データベースユーザー (MYSQL_USER
) と root ユーザーのパスワードを変更する唯一のサポートされている方法として、環境変数 MYSQL_PASSWORD
と MYSQL_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/openshift/mysql/master/5.5/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 レプリケーションでは、マスターとスレーブ間のデータをリレーする特別ユーザーが必要です。この目的で使用できるように、以下の環境変数をテンプレートに定義します。
変数名 | 説明 | デフォルト |
---|---|---|
|
レプリケーションユーザーのユーザー名 |
master |
|
レプリケーションユーザーのパスワード |
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-55-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-55-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
の値を検証して、倍にします。
$ 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.access.redhat.com/rhscl/postgresql-94-rhel7 $ docker pull registry.access.redhat.com/rhscl/postgresql-95-rhel7
CentOS 7 ベースのイメージ
これらのイメージは、Docker Hub で入手できます。
$ docker pull centos/postgresql-94-centos7 $ docker pull centos/postgresql-95-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する 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.access.redhat.com/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 ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。
変数名 | 説明 |
---|---|
|
作成予定の PostgreSQL アカウントのユーザー名。このユーザーには、対象のデータベースに対する完全な権限があります。 |
|
ユーザーアカウントのパスワード |
|
データベース名 |
|
postgres 管理ユーザーの任意パスワード。これが設定されていない場合には、postgres アカウントにリモートからログインができません。コンテナーからはいつでも、パスワードなしにローカル接続が可能です。 |
ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。
PostgreSQL 設定は、以下の環境変数で設定できます。
変数名 | 説明 | デフォルト |
---|---|---|
|
許容範囲の最大クライアント接続数 |
100 |
|
「準備」状態にすることのできる最大トランザクション数。準備状態のトランザクションを使用する場合には、値は |
0 |
|
データのキャッシュ用に PostgreSQL 専用に割り当てられたメモリー量 |
32M |
|
オペレーティングシステム別または PostgreSQL 自体で、ディスクキャッシュに利用可能な予想メモリー量 |
128M |
3.3.4.4. ボリュームのマウントポイント
PostgreSQL イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。
- /var/lib/pgsql/data: これは、PostgreSQL がデータベースファイルを保存するデータベースクラスターのディレクトリーです。
3.3.4.5. パスワードの変更
パスワードはイメージ設定の一部であるため、データベースユーザー (POSTGRESQL_USER
) と postgres 管理者ユーザーのパスワードを変更する唯一のサポートされている方法として、環境変数 POSTGRESQL_PASSWORD
と POSTGRESQL_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.4、2.6、3.2 および 3.4 を提供しています。
3.4.3. イメージ
これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/mongodb-24-rhel7 $ docker pull registry.access.redhat.com/rhscl/mongodb-26-rhel7 $ docker pull registry.access.redhat.com/rhscl/mongodb-32-rhel7 $ docker pull registry.access.redhat.com/rhscl/mongodb-34-rhel7
CentOS 7 ベースのイメージ
これらのイメージは、Docker Hub で入手できます。
$ docker pull openshift/mongodb-24-centos7 $ docker pull centos/mongodb-26-centos7 $ docker pull centos/mongodb-32-centos7 $ docker pull centos/mongodb-34-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する 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.access.redhat.com/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.4.9 connecting to: sampledb >
完了したら、CTRL+D を押して、MongoDB セッションを終了します。
3.4.4.3. 環境変数
MongoDB ユーザー名、パスワード、データベース名および admin のパスワードは、以下の環境変数で設定する必要があります。
変数名 | 説明 |
---|---|
|
作成する MongoDB アカウントのユーザー名 |
|
ユーザーアカウントのパスワード |
|
データベース名 |
|
admin ユーザーのパスワード |
ユーザー名、パスワード、データベース名および admin パスワードを指定する必要があります。この 4 つすべてを指定しない場合には、Pod は起動できず、OpenShift Container Platform は継続して Pod の再起動を試行します。
管理者のユーザー名は admin に設定されます。admin のパスワードは、MONGODB_ADMIN_PASSWORD
環境変数で設定する必要があります。このプロセスは、データベースの初期化の実行時に行います。
MongoDB 設定は、以下の環境変数で設定できます。
変数名 | 説明 | デフォルト |
---|---|---|
|
データファイルの事前割り当てを無効にします。 |
|
|
MongoDB がより小さなデータファイルサイズを使用するようにデフォルト設定します。 |
|
|
MongoDB を Quiet モードで実行して、出力量を制限しようとします。 |
|
|
(MongoDB バージョン 2.4 のみ) テキスト検索機能を有効にします。 |
|
テキスト検索は、MongoDB バージョン 2.6 以降ではデフォルトで有効になっているので、設定可能なパラメーターはありません。
3.4.4.4. ボリュームのマウントポイント
MongoDB イメージはマウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。
- /var/lib/mongodb/data: これは、MongoDB がデータベースファイルを保存するデータベースのディレクトリーです。
3.4.4.5. パスワードの変更
パスワードはイメージ設定の一部であるため、データベースユーザー (MONGODB_USER
) と admin ユーザーのパスワードを変更するための唯一のサポートされている方法とし、環境変数 MONGODB_PASSWORD
と MONGODB_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.4.9 connecting to: admin 2.4.9
3.4.5. テンプレートからのデータベースサービスの作成
OpenShift Container Platform には テンプレート が含まれており、新規データベースサービスの作成を簡素化します。テンプレートには、必須の環境変数をすべて定義するパラメーターフィールドがあり (ユーザー、パスワード、データベース名など)、自動生成されたパスワード値など、事前定義済みのデフォルト値が設定されます。また、テンプレートは デプロイメント設定 および サービス の両方を定義します。
PostgreSQL テンプレートは、クラスターの初期設定時にクラスター管理者により、デフォルトの 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 つまたは複数で、クラッシュまたは障害が発生すると、レプリカセットメンバーは再起動されます。
レプリカセットのメンバーがダウンまたは再起動している場合に考えられるシナリオは以下のいずれかです。
プライマリーメンバーがダウンしている:
このような場合には、他の 2 つのメンバーが新しいプライマリーを選択します。新しいプライマリーが選択されるまで、読み取りには影響はありませんが、書き込みが失敗してしまいます。正常に選択された後には、書き込みおよび読み取りは通常通りに処理されます。
セカンダリーメンバーの 1 つがダウンしている:
読み取りおよび書き込みには影響はありません。
oplogSize
設定と書き込み速度によって、3 番目のメンバーがレプリカセットへの参加に失敗する可能性があるため、手動の介入によりデータベースのコピーをもう一度同期する必要があります。2 つのメンバーがダウンしている:
3 つのメンバーで構成されるレプリカセットメンバーが他のメンバーに到達できない場合には、プライマリーロールが指定されていれば、そのロールが取り消されます。このような場合には、読み取りはセカンダリーメンバーが行い、書き込みに失敗します。他のメンバーが 1 つでも起動したらすぐに、新しいプライマリーメンバーが選択され、読み取りおよび書き込みが通常通りに処理されます。
全メンバーがダウンしている:
このように極端な場合は、読み取りおよび書き込み両方に失敗します。2 つ以上のメンバーが起動してくると、レプリカセットメンバーにプライマリーとセカンダリーメンバーが含まれるように選択が行われ、その後に読み取りと書き込みが通常通りに処理されます。
これが MongoDB の推奨のレプリケーションストラテジーです。
実稼働環境の場合には、できるだけメンバー間の分離を確保する必要があります。StatefulSet Pod を異なるノードにスケジューリングするノード選択機能を 1 つまたは複数使用し、個別のボリュームでサポートされるストレージを提供することを推奨します。
3.4.6.1. 制限
- MongoDB 3.2 のみがサポートされます。
- スケールダウンする場合には、レプリカセットの設定は手動で更新する必要があります。
ユーザーおよび管理者のパスワードの変更は手動のプロセスで行います。以下を実行する必要があります。
- StatefulSet 設定の環境変数の値を更新する
- データベースのパスワードを変更する
- 順次 Pod をすべて再起動する
3.4.6.2. サンプルのテンプレートの使用
事前作成されている永続ボリューム 3 つあり、永続ボリュームのプロビジョニングが設定されていることを前提とします。
MongoDB クラスターを作成する新規プロジェクトを作成します。
$ oc new-project mongodb-cluster-example
サンプルテンプレートを使用して新規アプリケーションを作成します。
$ oc new-app https://raw.githubusercontent.com/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml
このコマンドでは、3 つのレプリカセットメンバーを含む MongoDB クラスターが作成されました。
新規の 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
) を満たす場合には、手動での介入なしにスケールアップができますが、スケールダウンは常に手動での介入が必要です。
スケールダウンを実行するには、以下を実行します。
oc scale
コマンドを使用して、新しいレプリカ数を設定します。$ oc scale --replicas=3 statefulsets/mongodb
新しいレプリカ数が以前の数の過半数を占める場合には、削除された Pod の 1 つに、プライマリーメンバーロールを指定されていた時のために、レプリカセットにより新しいプライマリーが選択される場合があります。たとえば、メンバーを 5 から 3 にスケールダウンする場合などです。
また、少ない数にスケールダウンすると一時的に、レプリカセットに含まれるのがセカンダリーメンバーだけで、読み取り専用モードとなることがあります。たとえば、メンバーを 5 から 1 にスケールダウンする場合などです。
存在しなくなったメンバーを削除するように、レプリカセットの設定を更新します。
これは、レプリカ数の検査 (downward API 経由で公開) や StatefulSet から削除された Pod を判断する
PreStop
Pod フックを設定し、それ以外の理由で再起動されないようにする実装など、今後改善される可能性があります。- 無効になった 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.access.redhat.com/rhscl/mariadb-100-rhel7 $ docker pull registry.access.redhat.com/rhscl/mariadb-101-rhel7
CentOS 7 ベースのイメージ
これらのイメージは、Docker Hub で入手できます。
$ docker pull openshift/mariadb-100-centos7 $ docker pull centos/mariadb-101-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する 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.access.redhat.com/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 ユーザー名、パスワード、データベース名は、以下の環境変数で設定する必要があります。
変数名 | 説明 |
---|---|
|
作成する MySQL アカウントのユーザー名 |
|
ユーザーアカウントのパスワード |
|
データベース名 |
|
root ユーザーのパスワード (オプション) |
ユーザー名、パスワード、データベース名を指定する必要があります。この 3 つすべてを指定しない場合には、Pod は起動に失敗し、OpenShift Container Platform は Pod の再起動を継続的に試行します。
MariaDB 設定は、以下の環境変数で設定できます。
変数名 | 説明 | デフォルト |
---|---|---|
|
テーブル名の保存および比較方法を設定します。 |
0 |
|
クライアントが同時に接続可能な最大数 |
151 |
|
生成された文字列/中間文字列または 1 つのパケットの最大サイズ |
200M |
|
FULLTEXT インデックスに含める文字の最小長 |
4 |
|
FULLTEXT インデックスに含める文字の最大長 |
20 |
|
ネイティブの AIO が壊れている場合に innodb_use_native_aio の設定値を制御します。 |
1 |
|
全スレッド用に開くテーブル数 |
400 |
|
インデックスブロックに使用するバッファーサイズ |
32M (または利用可能なメモリーの 10%) |
|
分類に使用するバッファーサイズ |
256K |
|
シーケンススキャンに使用するバッファーサイズ |
8M (または利用可能メモリーの 5%) |
|
InnoDB がテーブルやインデックスデータをキャッシュするバッファープールのサイズ |
32M (または利用可能なメモリーの 50%) |
|
ロググループにある各ログファイルのサイズ |
8M (または利用可能メモリーの 15%) |
|
InnoDB がディスクのログファイルへの書き込みに使用するバッファーサイズ |
8M (または利用可能メモリーの 15%) |
|
別の設定ファイルを参照します。 |
/etc/my.cnf |
|
binlog 形式で設定します。サポートされる値は、 |
statement |
3.5.4.4. ボリュームのマウントポイント
MariaDB イメージは、マウントしたボリュームで実行して、データベース用に永続ストレージを有効化できます。
- /var/lib/mysql/data: MySQL のデータディレクトリーは、MariaDB がデータベースファイルを保存する場所にあります。
ホストからコンテナーにディレクトリーをマウントする場合には、マウントしたディレクトリーに適切なパーミッションが設定されていることを確認してください。また、ディレクトリーの所有者とグループが、コンテナー内で実行中のユーザー名と一致することを確認します。
3.5.4.5. パスワードの変更
パスワードはイメージ設定の一部であるため、データベースユーザー (MYSQL_USER
) と admin ユーザーのパスワードを変更するための唯一のサポートされる方法とし、環境変数 MYSQL_PASSWORD
と MYSQL_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
の値を検証して、倍にします。
$ sysctl fs.aio-max-nr fs.aio-max-nr = 1048576 # sysctl -w fs.aio-max-nr=2097152
これはノードごとの解決策であるため、効果があるのは次にノードが再起動されるまでです。