使用镜像

如果应用程序的 DocumentRoot 位于源目录 /opt/openshift/src 中，您可以提供自己的 .htaccess 文件来覆盖 Apache 默认行为，并指定如何处理应用程序请求。.htaccess 文件必须位于应用程序源的根目录下。

您第一次使用共享卷时，数据库会与数据库管理员用户和 MySQL 根用户一起创建（如果您指定了 MYSQL_ROOT_PASSWORD 环境变量）。之后，MySQL 守护进程会启动。如果您要将卷重新关联到另一个容器，则不会创建数据库、数据库用户和管理员用户，并且会启动 MySQL 守护进程。

以下命令创建一个在容器中运行 MySQL 的新数据库 pod:

$ 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 (SCLs)来安装和启动 MySQL。如果要在正在运行的容器内执行 MySQL 命令（用于调试），则必须使用 bash 调用它。

要做到这一点，首先确定 pod 的名称。例如，您可以查看当前项目中的 pod 列表：

$ oc get pods

然后，打开到 pod 的远程 shell 会话：

$ oc rsh <pod>

在进入容器时，会自动启用所需的 SCL。

您现在可以在 bash shell 中运行 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 设置可使用以下环境变量进行配置：

某些与内存相关的参数有两个默认值。当容器没有分配内存限值时使用这个固定值。其他值会根据可用内存在容器启动过程中动态计算。

可使用挂载卷运行 MySQL 镜像以便为数据库启用持久性存储：

密码是镜像配置的一部分，因此唯一支持的为数据库用户（MYSQL_USER）和 root 用户更改密码的方法是分别更改环境变量 MYSQL_PASSWORD 和 MYSQL_ROOT_PASSWORD。

您可以通过在 web 控制台中查看 pod 或部署配置，或通过 CLI 列出环境变量来查看当前的密码：

$ oc set env pod <pod_name> --list

当设置了 MYSQL_ROOT_PASSWORD 时，它就会为 root 用户启用远程访问，并可在有密码时启用远程访问。如果没有设置，会禁用 root 用户的远程访问。这不会影响通常具有远程访问权限的普通用户 MYSQL_USER。这也不会影响 root 用户的本地访问，root 用户总是可以在 localhost 中不带密码登录。

通过 SQL 语句或者通过环境变量更改数据库密码会导致变量中保存的值与实际密码不匹配。每当数据库容器启动时，它会将密码重置至环境变量中存储的值。

要更改这些密码，使用 oc set env 命令为相关的部署配置更新一个或多个所需的环境变量。如果多个部署配置使用这些环境变量，例如从模板创建应用程序时，您必须更新每个部署配置上的变量，以便密码可在所有方面同步。这可以在同一命令中完成：

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

如果您 配置更改触发器，更新环境变量会触发数据库服务器的重新部署。否则，您必须手动启动新的部署以应用密码更改。

要验证新密码是否生效，首先请打开正在运行的 MySQL pod 的远程 shell 会话：

$ oc rsh <pod>

在 bash shell 中验证数据库用户的新密码：

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 master-slave 复制，需要两个部署配置。一个部署配置定义 MySQL master 服务器，再定义 MySQL 的从 服务器。

要让 MySQL 服务器充当 master，必须将部署配置中容器定义中的 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 master 服务器保留所有数据，所以必须请集群管理员创建一个可以声明存储的持久性卷。

创建部署配置以及启动 MySQL master 服务器的 pod 后，它会创建 MYSQL_DATABASE 定义的数据库，并将服务器配置为将这个数据库复制到辅服务器。

这个示例只定义 MySQL 主服务器的一个副本。这会导致 OpenShift Container Platform 只启动一个服务器实例。不支持多个实例（multi-master），因此您无法扩展此复制控制器。

要复制由 MySQL master 创建的数据库，模板中定义了一个部署配置。这个部署配置会创建一个复制控制器，它会使用将 command 字段设置为 run-mysqld-slave 来启动 MySQL 镜像。这个替代的入口点跳过数据库初始化并将 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 的当前值并加倍。

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

这会针对每个节点进行解析，持续到下一个节点重启为止。

您第一次使用共享卷时，数据库会与数据库管理员用户和 PostgreSQL postgres 用户一起创建（如果您指定了 POSTGRESQL_ADMIN_PASSWORD 环境变量）。之后，PostgreSQL 守护进程会启动。如果您要将卷重新关联到另一个容器，则不会创建数据库、数据库用户和管理员用户，并且会启动 PostgreSQL 守护进程。

以下命令创建使用容器中运行 PostgreSQL 的新数据库 pod:

$ 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 (SCLs)来安装和启动 PostgreSQL。如果要在正在运行的容器内执行 PostgreSQL 命令（用于调试），则必须使用 bash 调用它。

要做到这一点，首先确定正在运行的 PostgreSQL Pod 的名称。例如，您可以查看当前项目中的 pod 列表：

$ oc get pods

然后，打开到所需 pod 的远程 shell 会话：

$ oc rsh <pod>

在进入容器时，会自动启用所需的 SCL。

现在，可以在 bash shell 中运行 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。

您可以通过在 web 控制台中查看 pod 或部署配置，或通过 CLI 列出环境变量来查看当前的密码：

$ oc set env pod <pod_name> --list

通过 SQL 语句或者通过环境变量更改数据库密码会导致变量中保存的值与实际密码不匹配。每当数据库容器启动时，它会将密码重置至环境变量中存储的值。

要更改这些密码，使用 oc set env 命令为相关的部署配置更新一个或多个所需的环境变量。如果多个部署配置使用这些环境变量，例如从模板创建应用程序时，您必须更新每个部署配置上的变量，以便密码可在所有方面同步。这可以在同一命令中完成：

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

如果您 配置更改触发器，更新环境变量会触发数据库服务器的重新部署。否则，您必须手动启动新的部署以应用密码更改。

要验证新密码是否有效，首先请打开一个远程 shell 会话到正在运行的 PostgreSQL pod:

$ oc rsh <pod>

在 bash shell 中验证数据库用户的新密码：

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 shell 中验证 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 守护进程。

以下命令创建一个带有临时卷在容器中运行的 MongoDB 的新数据库 pod:

$ 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 (SCLs)来安装和启动 MongoDB。如果要在运行的容器内执行 MongoDB 命令（用于调试）,则必须使用 bash 调用它。

要做到这一点，首先请确定正在运行的 MongoDB Pod 的名称。例如，您可以查看当前项目中的 pod 列表：

$ oc get pods

然后，打开到所需 pod 的远程 shell 会话：

$ oc rsh <pod>

在进入容器时，会自动启用所需的 SCL。

现在，您可以在 bash shell 中运行 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。

您可以通过在 web 控制台中查看 pod 或部署配置，或通过 CLI 列出环境变量来查看当前的密码：

$ oc set env pod <pod_name> --list

直接在 MongoDB 中更改数据库密码会导致变量中保存的值与实际密码不匹配。每当数据库容器启动时，它会将密码重置至环境变量中存储的值。

要更改这些密码，使用 oc set env 命令为相关的部署配置更新一个或多个所需的环境变量。如果多个部署配置使用这些环境变量，例如从模板创建应用程序时，您必须更新每个部署配置上的变量，以便密码可在所有方面同步。这可以在同一命令中完成：

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

如果您 配置更改触发器，更新环境变量会触发数据库服务器的重新部署。否则，您必须手动启动新的部署以应用密码更改。

要验证新密码是否生效，首先打开正在运行的 MongoDB pod 的远程 shell 会话：

$ oc rsh <pod>

在 bash shell 中验证数据库用户的新密码：

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 个成员设置了副本。运行 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 守护进程。

以下命令创建一个在容器中运行的 MariaDB 的新数据库 pod:

$ 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 (SCLs)来安装和启动 MariaDB。如果要在运行的容器内执行 MariaDB 命令（用于调试）,则必须使用 bash 调用它。

要做到这一点，首先确定正在运行的 MariaDB Pod 的名称。例如，您可以查看当前项目中的 pod 列表：

$ oc get pods

然后，打开到 pod 的远程 shell 会话：

$ oc rsh <pod>

在进入容器时，会自动启用所需的 SCL。

现在，您可以在 bash shell 中运行 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。

您可以通过在 web 控制台中查看 pod 或部署配置，或通过 CLI 列出环境变量来查看当前的密码：

$ oc set env pod <pod_name> --list

通过 SQL 语句或者通过环境变量更改数据库密码会导致变量中保存的值与实际密码不匹配。每当数据库容器启动时，它会将密码重置至环境变量中存储的值。

要更改这些密码，使用 oc set env 命令为相关的部署配置更新一个或多个所需的环境变量。如果多个部署配置使用这些环境变量，例如从模板创建应用程序时，您必须更新每个部署配置上的变量，以便密码可在所有方面同步。这可以在同一命令中完成：

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

如果您 配置更改触发器，更新环境变量会触发数据库服务器的重新部署。否则，您必须手动启动新的部署以应用密码更改。

要验证新密码是否生效，首先请打开正在运行的 MariaDB pod 的远程 shell 会话：

$ oc rsh <pod>

在 bash shell 中验证数据库用户的新密码：

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 的当前值并加倍。

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

这会针对每个节点进行解析，持续到下一个节点重启为止。

您可采用两种方式管理 Jenkins 身份验证：

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

Jenkins 服务器可通过以下环境变量进行配置：

如果您要作为同一项目内的部署在其它位置运行 Jenkins，则需要为 Jenkins 提供访问令牌来访问您的项目。

令牌字段包含 Jenkins 访问项目所需的令牌值。

可使用挂载卷运行 Jenkins 镜像，以便为配置启用持久性存储：

要自定义官方 OpenShift Container Platform Jenkins 镜像，有两个选项：

您可使用 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 插件，支持使用 Kubernes 和 OpenShift Container Platform 在多个容器主机上动态置备 Jenkins 代理。

为了使用 Kubernetes 插件，OpenShift Container Platform 提供了适合用作 Jenkins 代理的五个镜像： Base、Maven 和 Node.js 镜像。如需更多信息，请参阅 Jenkins 代理。

Maven 和 Node.js 代理镜像均会在 OpenShift Container Platform Jenkins 镜像的 Kubernetes 插件配置中自动配置为 Kubernetes Pod 模板镜像。该配置包含各个镜像的标签，可应用于 “Restrict where this project can be run” 设置下的任何 Jenkins 任务。如果应用了标签，则指定任务的执行将在运行相应代理镜像的 OpenShift Container Platform pod 下执行。

Jenkins 镜像还为 Kubernetes 插件提供附加代理镜像的自动发现和自动配置。使用 OpenShift Sync 插件，Jenkins 上的 Jenkins 镜像会在其正在运行的项目中搜索，或搜索在插件配置中特别列出的项目：

当找到具有适当标签的镜像流或带有适当注解的镜像流标签时，它会生成对应的 Kubernetes 插件配置，以便您可以将 Jenkins 任务分配在运行镜像流提供的容器镜像的 pod 中运行。

镜像流或镜像流标签的名称和镜像引用映射到 Kubernetes 插件 pod 模板中的名称和镜像字段。您可以通过使用 slave-label 键在镜像流或镜像流标签对象上设置注解，来控制 Kubernetes 插件 pod 模板的标签字段。否则，名称将用作标签。

当找到具有适当标签的 ConfigMap 时，它会假定 ConfigMap 的键值数据有效负载中的任何值都包含与 Jenkins 和 Kubernetes 插件 pod 模板的配置格式一致的 XML。使用 ConfigMaps 而非镜像流或镜像流标签时，需要注意的一个关键区别在于您可以控制 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 代理，该镜像必须运行 slave 代理，作为入口点。有关此方面的更多详情，请参阅官方 Jenkins 文档。

模板 提供参数字段来定义所有带有预定义的默认值的环境变量（password）。OpenShift Container Platform 提供模板，以简化 Jenkins 服务的新建操作。在初始集群设置过程中，集群管理员应该在默认 openshift 项目中注册 Jenkins 模板。如需了解更多详细信息，请参阅载入默认镜像流和模板。

部署配置和服务。

必须实例化模板才能使用 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 管道中修改 - 请参阅 代理 Pod 保留 以了解更多详细信息。

如需有关 Kubernetes 插件配置的更多信息,请参阅 Kubernetes 插件文档。

使用所提供的 Jenkins Ephemeral 或 Jenkins Persistent 模板部署时，默认内存限值为 512MiB。

如需了解有关调整 Jenkins 使用的 JVM 的后台信息，请参阅 在 OpenShift Container Platform 上调整 OpenJDK。

为提高内存效率，如果容器中运行的内存限值为 2GiB，则默认情况下 Jenkins 镜像会动态使用 32 位 JVM。OPENSHIFT_JENKINS_JVM_ARCH 环境变量可覆盖此行为。

默认情况下，Jenkins JVM 将容器内存限值的 50% 用于其堆。该值可通过 CONTAINER_HEAP_PERCENT 环境变量修改，还可设置上限或整个覆盖。如需了解更多详细信息，请参阅 环境变量。

注意默认情况下，Jenkins 容器中执行的所有进程（如 shell 脚本或从管道中运行的 oc 命令）不可能在不引发 OOM 终止的情况下使用剩余的 256MiB 内存。因此，我们强烈建议管道尽可能在代理容器中运行外部命令。

建议在由 Jenkins Kubernetes 插件创建的代理容器上指定内存请求和限值。作为 admin，可通过 Jenkins 配置基于每个代理镜像设置默认值。如上所述，内存请求和限制也可以基于每个容器覆盖。

在实例化 Jenkins Ephemeral 或 Jenkins Persistent 模板时，您可通过覆盖 MEMORY_LIMIT 参数来增加 Jenkins 的可用内存量。

OpenShift Container Platform 客户端插件旨在提供易读、简洁、全面且流畅的 Jenkins Pipeline 语法,以便与 OpenShift Container Platform 进行丰富的交互。该插件利用 oc 二进制文件，该二进制文件必须在执行脚本的节点上可用。

此插件被完全支持，并包含在 Jenkins 镜像中。它提供：

如需更多信息，请参阅 OpenShift Pipeline Builds 指南 和插件的 README。

OpenShift Container Platform Pipeline 插件是 Jenkins 和 OpenShift Container Platform 之前的一个集成，它的功能比 OpenShift Container Platform 客户端插件要少。它已被弃用，但仍可在 OpenShift Container Platform 版本中使用 v3.11。对于以后的 OpenShift Container Platform 版本，可以直接从 Jenkins Pipelines 中使用 oc 二进制文件，也可以使用 OpenShift Container Platform 客户端插件。

如需更多信息，请参阅插件的 README。

为便于 OpenShift Container Platform Pipeline 构建策略 在 Jenkins 和 OpenShift Container Platform 间集成，OpenShift Sync 插件 监控 OpenShift Container Platform 的 API 服务器，以获取对 BuildConfigs 和 Builds 的更新，以使用 Pipeline 策略并创建 Jenkins Pipeline 项目（在创建 BuildConfig 时）或者在生成的项目中启动作业（在 Build 启动时）。

如 配置 Jenkins Kubernetes 插件中 所述，此插件可根据 OpenShift Container Platform 中定义的 ImageStream、ImageStreamTag 或 ConfigMap 对象的具体情况，为 Kubernetes 插件创建 PodTemplate 配置。

此插件现在可以使用一个带有credentials.sync.jenkins.openshift.io 标签键，标签值为 true 的 Secret 对象，并构建 Jenkins 凭证，这些凭证放置在 Jenkins 凭证层次结构中的默认全局域中。凭证 ID 由在中定义 Secret 的命名空间组成、一个连字符（-），后跟 Secret 的名称。

与处理 PodTemplates 的 ConfigMap 类似 , OpenShift Container Platform 中定义的 Secret 对象被视为主配置。OpenShift Container Platform 中对象的任何后续更新将应用于 Jenkins 凭证（覆盖期间对凭证所做的任何更改）。

移除了 credential.sync.jenkins.openshift.io 属性，将该属性设置为 true 以外的任何属性，或删除 OpenShift Container Platform 中的 Secret，会导致删除 Jenkins 中的相关凭证。

secret 的类型将映射到 jenkins 凭证类型，如下所示：

Kubernetes 插件用于将 Jenkins 代理作为集群中的 pod 运行。使用 Jenkins Kubernetes 插件中提供了 Kubernetes 插件的自动配置信息。

每个 Jenkins 代理容器均可通过以下环境变量进行配置：

所有 Jenkins 代理均使用 JVM 来托管 Jenkins JNLP 代理和运行任何 Java 应用程序，如 javac、Maven 或 Gradle。如需了解有关调整 Jenkins 代理使用的 JVM 的背景资料，请参阅在 OpenShift Container Platform 上调整 OpenJDK。

为提高内存效率，如果容器中运行的内存限值为 2GiB，则默认情况下 Jenkins 镜像会动态使用 32 位 JVM。OPENSHIFT_JENKINS_JVM_ARCH 环境变量可覆盖此行为。JVM 选择默认适用于 Jenkins JNLP 代理以及代理容器内的任何其他 Java 进程。

默认情况下，Jenkins JNLP 代理 JVM 会将容器内存限值的 50% 用于其堆。该值可通过 CONTAINER_HEAP_PERCENT 环境变量修改，还可设置上限或整个覆盖。如需了解更多详细信息，请参阅环境变量。

在默认情况下，Jenkins 代理容器中执行的任何/所有其他进程（如 shell 脚本或从管道运行的 oc 命令）在不引发 OOM 终止的情况下，可能无法使用剩余的 50% 内存限值。

默认情况下，Jenkins 代理容器中运行的每个进一步的 JVM 进程最多可为其堆使用 25% 的容器内存限值。可能需要对许多构建工作负载进行微调。如需更多信息，请参阅 在 OpenShift Container Platform 上调整 OpenJDK。

如需有关指定 Jenkins 代理容器的内存请求和限制的信息，请参阅 Jenkins 文档。