アプリケーションの DocumentRoot がソースディレクトリー /opt/openshift/src にネストされている場合は、独自の .htaccess ファイルを指定して、デフォルトの Apache の動作を上書きし、アプリケーションの要求の処理方法を指定できます。.htaccess ファイルは、アプリケーションソースの root に置く必要があります。

共有ボリュームを初めて使用する場合には、データベース、データベースの管理ユーザー、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

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 セッションを終了します。

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

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

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

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

パスワードはイメージ設定の一部であるため、データベースユーザー (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 には影響を与えません。これは、localhostにパスワードなしでいつでもログインできるrootユーザーによるローカルアクセスにも影響しません。

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

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

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

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

新規のパスワードが有効になっていることを確認するには、まず、実行中の 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 |
+------------+------------------+

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

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

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 つのインスタンスのみを起動します。複数のインスタンス (multi-master) はサポートされていないため、このレプリケーションコントローラーをスケーリングできません。

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

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 に設定して、レプリケーションコントローラーを開始します。このレプリケーションコントローラー は、アカウントのリソース容量まで、両方向にスケーリングできます。

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

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

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"
  clusterIP: "None"
  type: "ClusterIP"
  sessionAffinity: "None"
status:
  loadBalancer: {}

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

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

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

スケールダウン時には、MySQL スレーブがシャットダウンされ、スレーブに永続ストレージが定義されていないので、スレーブ上のすべてのデータが失われます。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

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

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

これはノードごとの解決策であり、次のノードが再起動するまで続きます。

共有ボリュームを初めて使用する場合は、データベース、データベースの管理ユーザー、PostgreSQL postgres ユーザー (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

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 セッションを終了します。

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

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

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

パスワードはイメージ設定の一部であるため、データベースユーザー (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>

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

新規のパスワードが有効になっていることを確認するには、まず、実行中の 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)

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

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 セッションを終了します。

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

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

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

パスワードはイメージ設定の一部であるため、データベースユーザー (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>

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

新規のパスワードが有効になっていることを確認するには、まず、実行中の 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 つあるか、または永続ボリュームのプロビジョニングが設定されていることを前提とします。

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

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 が作成されます。

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

前提条件 (ストレージの可用性、既存のデータベースのサイズ、oplogSize) を満たす場合には、スケールアップを手動で実行することはありませんが、スケールダウンは常に手動で実行する必要があります。

スケールダウンの方法:

共有ボリュームを初めて使用する場合は、データベース、データベースの管理ユーザー、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

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 セッションを終了します。

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

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

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

パスワードはイメージ設定の一部であるため、データベースユーザー (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>

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

新規パスワードが有効になっていることを確認するには、まず、実行中の 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 |
+------------+------------------+

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

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

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

これはノードごとの解決策であり、次のノードが再起動するまで続きます。

Jenkins 認証は、以下の 2 つの方法で管理できます。

$ oc new-app -e \
    JENKINS_PASSWORD=<password> \
    openshift/jenkins-2-centos7

Jenkins サーバーは、以下の環境変数で設定できます。

同じプロジェクト内のデプロイメントとしてではなく、別の場所で Jenkins を実行する場合には、プロジェクトにアクセスするために、Jenkins にアクセストークンを提供する必要があります。

トークンフィールドには、Jenkins がプロジェクトへのアクセスに必要なトークンの値が含まれます。

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

正式な OpenShift Container Platform Jenkins イメージをカスタマイズするには、以下の 2 つのオプションがあります。

S2I を使用して、カスタムの Jenkins ジョブ定義をコピーしたり、プラグインを追加したり、同梱の config.xml ファイルを独自のカスタムの設定に置き換えたりできます。

Jenkins イメージに変更を追加するには、以下のディレクトリー構造を持つ Git リポジトリーが必要です。

pluginId:pluginVersion

configuration/ ディレクトリーのコンテンツは、/var/lib/jenkins/ ディレクトリーにコピーされるので、このディレクトリーに credentials.xml などのファイルをさらに追加することもできます。

以下のビルド設定のサンプルは、OpenShift Container Platform で Jenkins イメージをカスタマイズします。

apiVersion: v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       1
    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     2
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:latest
        namespace: openshift
    type: Source
  output:                       3
    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

OpenShift Container Platform Jenkins イメージには、事前にインストール済みの Kubernetes プラグイン が含まれ、Kubernetes および OpenShift Container Platform を使用して、Jenkins エージェントを複数のコンテナーホストで動的にプロビジョニングできるようにします。

OpenShift Container Platform は、Kubernetes プラグインを使用するために、Jenkins エージェントとして使用するのに適したイメージを 5 つ (Base、Maven、および Node.js イメージ) 提供します。詳細は、Jenkins Agents を参照してください。

Maven および Node.js のエージェントイメージは、Kubernetes プラグイン用の OpenShift Container Platform Jenkins イメージの設定内で、Kubernetes Pod テンプレートイメージとして自動的に設定されます。この設定にはイメージごとのラベルが含まれており、"Restrict where this project can be run" の設定にある Jenkins ジョブのいずれかに適用できます。ラベルが適用されると、指定されたジョブの実行は、それぞれのエージェントイメージを実行している OpenShift Container Platform Pod の下で実行されます。

Jenkins イメージは、Kubernetes プラグインの追加のエージェントイメージの自動検出および自動設定を実行します。OpenShift Sync プラグイン では、Jenkins イメージは Jenkins の起動時に、実行中のプロジェクトまたはプラグインの設定に具体的に一覧表示されているプロジェクト内で以下を検索します。

適切なラベルが付いたイメージストリームまたは、適切なアノテーションが付いたイメージストリームタグが見つかると、対応する Kubernetes プラグイン設定が生成されるため、イメージストリームから提供されるコンテナーイメージを実行する Pod で、Jenkins ジョブを実行するように割り当てることができます。

イメージストリームまたはイメージストリームタグのイメージ参照および名前が、Kubernetes プラグインの Pod テンプレートにある名前およびイメージフィールドにマッピングされます。Kubernetes プラグインの Pod テンプレートのラベルフィールドは、イメージストリームにアノテーションを設定するか、イメージストリームタグオブジェクトに slave-label キーを設定して、制御できます。これらを使用しない場合には、名前をラベルとして使用します。

適切なラベルが指定された ConfigMap が検出される場合は、ConfigMap のキーと値のデータペイロードの値に、Jenkins および Kubernetes プラグインの Pod テンプレートの設定形式に準拠する XML が含まれることが想定されます。ConfigMap を使用する時に注意すべき主な差別化要因は、イメージストリームまたはイメージストリームタグの代わりに、Kubernetes プラグインの Pod テンプレートのさまざまなフィールドをすべて制御できることです。

以下は ConfigMap の例になります。

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-slave
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

起動後、OpenShift Sync プラグイン は、OpenShift Container Platform の API サーバーを監視して、ImageStreams、ImageStreamTags、および ConfigMaps の更新を確認し、Kubernetes プラグインの設定を調整します。

特に、以下のルールが適用されます。

Jenkins エージェントとしてコンテナーイメージを使用するには、イメージは、エントリーポイントとしてスレーブエージェントを実行する必要があります。これに関する詳細情報は、公式の Jenkins ドキュメント を参照してください。

テンプレート にはパラメーターフィールドがあり、事前定義されたデフォルト値ですべての環境変数を定義します。OpenShift Container Platform では、新規の Jenkins サービスを簡単に作成できるようにテンプレートが提供されています。Jenkins テンプレートは、クラスターの初期設定時にクラスター管理者によって、デフォルトの openshift プロジェクトに登録されている必要があります。詳細は、必要に応じて、Loading the Default Image Streams and Templates を参照してください。

デプロイメント設定 および サービス。

Jenkins を使用可能にするには、テンプレートを インスタンス化 する必要があります。

同様のゴールを達成するより完全なサンプルは、こちら から入手できます。

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

動的に作成された Jenkins エージェント Pod の仕様を上書きすることも可能です。以下は、コンテナーメモリーを上書きして、環境変数を指定する上記の例を変更したものです。

kind: BuildConfig
apiVersion: v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 1
                    cloud: "openshift", 2
                    inheritFrom: "maven", 3
                    containers: [
            containerTemplate(name: "jnlp", 4
                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5
                              resourceRequestMemory: "512Mi", 6
                              resourceLimitMemory: "512Mi", 7
                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8
            ])
          ]) {
          node("mypod") { 9
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

デフォルトで、Pod はビルドの完了時に削除されます。この動作は、プラグインを使用するか、またはパイプライン Jenkinsfile 内で変更できます。詳細は、Agent Pod Retention を参照してください。

Kubernetes プラグインの設定に関する詳細は、Kubernetes プラグインドキュメント を参照してください。

提供される Jenkins の一時また永続テンプレートでデプロイする場合、デフォルトのメモリー制限は 512MiB です。

Jenkins が使用する JVM のチューニングに関する背景情報は、Sizing OpenJDK on OpenShift Container Platform を参照してください。

メモリー効率のために、メモリー制限が 2GiB 未満のコンテナーで実行されている場合、デフォルトで Jenkins イメージは 32 ビット JVM を動的に使用します。この動作は、OPENSHIFT_JENKINS_JVM_ARCH 環境変数で上書きできます。

デフォルトで、Jenkins JVM は、ヒープにコンテナーメモリー制限の 50% を使用します。この値は、CONTAINER_HEAP_PERCENT の環境変数で変更可能です。また、上限を指定することも、すべて上書きすることも可能です。詳細は、Environment Variables を参照してください。

デフォルトでは、パイプラインからローカルで実行されるシェルスクリプトや oc コマンドなど、Jenkins コンテナーで実行される他のすべてのプロセスでは、OOM kill を引き起こさずに、残りの 256MiB メモリーの合計を超えるメモリーを使用できる可能性はありません。そのため、パイプラインは可能な限り、エージェントコンテナーで外部コマンドを実行することを強くお勧めします。

Jenkins Kubernetes プラグインによって作成されるエージェントコンテナーで、メモリー要求および制限の値を指定することが推奨されます。管理者は、Jenkins 設定を使用して、エージェントごとのイメージに基づいてデフォルトを設定できます。メモリー要求および制限は、上記 のように、コンテナーベースでも上書きできます。

Jenkins で利用可能なメモリー量を増やすには、Jenkins の一時テンプレートまたは永続テンプレートをインスタンス化する際に MEMORY_LIMIT パラメーターを上書きします。

OpenShift Container Platform クライアントプラグインは、OpenShift Container Platform との高度な対話を実現するために、読み取り可能かつ簡潔で、包括的で Fluent (流れるような) な Jenkins Pipeline 構文を提供することを目指しています。このプラグインは oc バイナリーを活用しますが、このバイナリーは、スクリプトを実行するノードで利用できるようにしておく必要があります。

このプラグインは完全にサポートされ、Jenkins イメージに含まれています。以下を提供します。

詳細は、OpenShift Pipeline Builds tutorial および the plug-in's README を参照してください。

OpenShift Container Platform Pipeline プラグインは、Jenkins と OpenShift Container Platform の以前の統合で、OpenShift Container Platform クライアントプラグインよりも機能が少なくなっています。これは非推奨になっていますが、引き続き v3.11 までの OpenShift Container Platform バージョンで機能します。OpenShift Container Platform の後のバージョンについては、oc バイナリーを Jenkins Pipeline から直接使用するか、または OpenShift Container Platform クライアントプラグイン を使用します。

詳細は、the plug-in's README を参照してください。

Jenkins と OpenShiftContainerPlatform を統合するための OpenShiftContainer Platform Pipeline ビルドストラテジー を容易にするために、OpenShift Sync プラグイン は、OpenShift Container Platform の API サーバーを監視して、Pipeline ストラテジーを採用する BuildConfigs および Builds への更新を確認し、Jenkins Pipeline プロジェクトを作成するか (BuildConfig の作成時)、作成されるプロジェクトでジョブを開始します (Build の開始時)。

Jenkins Kubernetes プラグインの設定 で説明されているように、このプラグインは、OpenShift Container Platform に定義済みで具体的に引用された ImageStream、ImageStreamTag または ConfigMap オブジェクトをベースに、Kubernetes プラグインの PodTemplate 設定を作成できます。

このプラグインは、credential.sync.jenkins.openshift.io のラベルキーと、true のラベルの値が指定された Secret オブジェクトを取得し、Jenkins 認証情報の階層内のデフォルトのグローバルドメインに配置される Jenkins 認証情報を構築できるようになりました。認証情報の ID は、Secret が定義されている namespace、ハイフン (-)、そして Secret の名前で設定されます。

PodTemplates の ConfigMaps の処理と同様に、OpenShift Container Platform で定義された Secret オブジェクトは、マスター設定とみなされます。OpenShift Container Platform のオブジェクトへのその後の更新は、Jenkins 認証情報に適用されます (暫定的に認証情報に加えられた変更を上書きします)。

credential.sync.jenkins.openshift.io プロパティーを削除したり、このプロパティーを true 以外に設定したり、OpenShift Container Platform から Secret を削除したりすると、Jenkins で関連する認証情報が削除されます。

シークレットのタイプは、以下のように jenkins 認証情報タイプにマッピングされます。

Kubernetes プラグインを使用して、クラスターの Pod として Jenkins エージェントを実行します。Kubernetes プラグインの自動設定については、Using the Jenkins Kubernetes Plug-in で説明しています。

各 Jenkins エージェントコンテナーは、以下の環境変数で設定できます。

JVM はすべての Jenkins エージェントで使用され、Jenkins JNLP エージェントをホストし、Java アプリケーション (javac、Maven または Gradle など) を実行します。Jenkins エージェントが使用する JVM のチューニングに関する参考情報は、Sizing OpenJDK on OpenShift Container Platform を参照してください。

メモリー効率のために、メモリー制限が 2GiB 未満のコンテナーで実行されている場合、デフォルトで Jenkins イメージは 32 ビット JVM を動的に使用します。この動作は、OPENSHIFT_JENKINS_JVM_ARCH 環境変数で上書きできます。JVM の選択は、デフォルトで JenkinsJNLP エージェントとエージェントコンテナー内の他の Java プロセスの両方に適用されます。

デフォルトで、Jenkins JNLP エージェントの JVM は、ヒープにコンテナーメモリー制限の 50% を使用します。この値は、CONTAINER_HEAP_PERCENT の環境変数で変更可能です。また、上限を指定することも、すべて上書きすることも可能です。詳細は、Environment Variables を参照してください。

デフォルトでは、パイプラインから実行されるシェルスクリプトや oc コマンドなど、Jenkins エージェントコンテナーで実行される他のすべてのプロセスでは、OOM kill を引き起こさずに、残りの 50% のメモリー制限を超えるメモリーを使用することはできません。

デフォルトでは、Jenkins エージェントコンテナーで実行される他の各 JVM プロセスは、最大でコンテナーメモリー制限の 25% をヒープに使用します。これは、多くのビルドワークロード用にチューニングする必要がある場合があります。詳細は、Sizing OpenJDK on OpenShift Container Platform を参照してください。

Jenkins エージェントコンテナーのメモリー要求や制限の指定に関する情報は、Jenkins ドキュメント を参照してください。