イメージの使用

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

共有ボリュームを初めて使用する場合には、データベース、データベースの管理ユーザー、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/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 には影響なく、常にリモートからアクセスできます。また、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>

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

新規パスワードが有効になっていることを確認するには、まず実行中の 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 つのインスタンスのみを起動します。複数のインスタンス (マルチマスター) はサポートされていないため、このレプリケーションコントローラーはスケーリングできません。

テンプレートにデプロイメント設定を定義して、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 にクエリーも送信します。

ヘッドレスサービスを含めるには、サービス定義の portalIP パラメーターを 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"
  portalIP: "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 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

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.access.redhat.com/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.access.redhat.com/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 スレーブとして使用するのに適したイメージを 3 つ (Base、Maven および Node.js) 提供します。詳しい情報は、「Jenkins スレーブ」を参照してください。

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 同期プラグイン では、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-slave
  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-slave-maven-centos7:v3.9</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 同期プラグイン は、ImageStreams、ImageStreamTags および ConfigMaps に更新がないか、OpenShift Container Platform の API サーバーをモニタリングして、Kubernetes プラグインの設定を調節します。

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

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

テンプレート には各種パラメーターフィールドがあり、事前定義されたデフォルト値で全環境変数 (パスワード) を定義できます。OpenShift Container Platform では、新規の Jenkins サービスを簡単に作成できるようにテンプレートが提供されています。クラスター管理者は、初期のクラスター設定時に、Jenkins テンプレートをデフォルトの openshift プロジェクトに登録しておく必要があります。詳細は、必要に応じて、「デフォルトのイメージストリームとテンプレートの読み込み」を参照してください。

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

テンプレートをインスタンス化して、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-slave-maven-centos7:v3.9", 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

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

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

Jenkins が使用する JVM のチューニングに関する参考情報は 「OpenShift Container Platform での OpenJDK のサイジング」を参照してください。

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

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

デフォルトでは、パイプラインからローカルで実行されるシェルスクリプトや 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 ビルドのチュートリアル」および プラグインの README を参照してください。

OpenShift Container Platform Pipeline プラグインは、Jenkins と OpenShift Container Platform が統合する前のプラグインで、OpenShift Container Platform クライアントプラグインよりも機能が少なくなっています。このプラグインは依然として利用でき、サポートが提供されます。

詳しい情報は、プラグインの READMEを参照してください。

OpenShift Container Platform Pipeline ビルドストラテジーが Jenkins と OpenShift Container Platform をスムーズに統合できるように、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 プラグインの自動設定については、「Jenkins Kubernetes プラグインの使用」で説明されています。

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

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

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

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

デフォルトでは、パイプラインから実行されるシェルスクリプトや oc コマンドなど、Jenkins エージェントコンテナーで実行される他の全プロセスでは、OOM kill を呼び出さずに、メモリー制限の残り 50% を超えたメモリーを使用できる可能性が低い点を考慮してください。

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

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