由于 Rails 4 在生产中不再提供静态 public/index.html 页面，您必须创建一个新的 root 页面。 要想具有自定义欢迎页面，必须执行以下步骤： 使用 index 操作创建控制器。 为 welcome 控制器 index 操作创建 view 页面。 使用所创建的 controller 和 view 创建一个提供应用程序 root 页面的路由。 Rails 提供了一个生成器，用于完成您所有必要的步骤。 运行 Rails 生成器：

$ rails generate controller welcome index

已创建所有必要文件。 按如下方式编辑 config/routes.rb 文件中第 2 行：

root 'welcome#index'

$ rails server

要让您的应用程序与 OpenShift Container Platform 中运行的 PostgreSQL 数据库服务通信，必须编辑 config/database.yml 中的 default 部分，以便在创建数据库服务时使用环境变量，稍后会对这些变量进行定义。 使用预定义的变量按照以下方式编辑 config/database.yml 中的 default 部分：

<% user = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? "root" : ENV["POSTGRESQL_USER"] %>
<% password = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? ENV["POSTGRESQL_ADMIN_PASSWORD"] : ENV["POSTGRESQL_PASSWORD"] %>
<% db_service = ENV.fetch("DATABASE_SERVICE_NAME","").upcase %>
default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV["POSTGRESQL_MAX_CONNECTIONS"] || 5 %>
  username: <%= user %>
  password: <%= password %>
  host: <%= ENV["#{db_service}_SERVICE_HOST"] %>
  port: <%= ENV["#{db_service}_SERVICE_PORT"] %>
  database: <%= ENV["POSTGRESQL_DATABASE"] %>

在 OpenShift Container Platform 中构建应用程序通常需要将源代码存储在 git 存储库中，因此如果还没有 git ，必须要安装。 安装 git。 运行 ls -1 命令，确保已在 Rails 应用程序目录中。命令输出应类似于：

$ ls -1

$ git init

$ git add .

$ git commit -m "initial commit"

$ git remote add origin [email protected]:<namespace/repository-name>.git

$ git push

您的 Rails 应用程序需要一个正在运行的数据库服务。对于此服务，请使用 PostgreSQL 数据库镜像。 要创建数据库服务，使用 oc new-app 命令。您必须将一些在数据库容器中使用的必要环境变量传递给此命令。设置用户名、密码和数据库名称需要这些环境变量。您可随意更改这些环境变量的值。变量如下： POSTGRESQL_DATABASE POSTGRESQL_USER POSTGRESQL_PASSWORD 设置这些变量可确保： 存在具有指定名称的数据库。 存在具有指定名称的用户。 用户可使用指定密码访问指定数据库。 创建数据库服务：

$ oc new-app postgresql -e POSTGRESQL_DATABASE=db_name -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password

若也要为数据库管理员设置密码，请将以下内容附加至上一命令中：

-e POSTGRESQL_ADMIN_PASSWORD=admin_pw

$ oc get pods --watch

要将应用程序添加到 OpenShift Container Platform 中，您必须指定应用程序所在存储库。 创建前端服务，并指定创建数据库服务时设置的数据库相关环境变量：

$ oc new-app path/to/source/code --name=rails-app -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password -e POSTGRESQL_DATABASE=db_name -e DATABASE_SERVICE_NAME=postgresql

通过此命令，OpenShift Container Platform 可获取源代码，设置构建程序来构建应用程序镜像，并与指定的环境变量一同来部署新创建的镜像。该应用程序命名为 rails-app 。 通过查看 rails-app 部署配置的 JSON 文档来验证环境变量是否已添加：

$ oc get dc rails-app -o json

您应看到以下部分：

env": [
        "name": "POSTGRESQL_USER",
        "value": "username"
        "name": "POSTGRESQL_PASSWORD",
        "value": "password"
        "name": "POSTGRESQL_DATABASE",
        "value": "db_name"
        "name": "DATABASE_SERVICE_NAME",
        "value": "postgresql"
							检查构建流程：
						
$ oc logs -f build/rails-app-1

							构建完成后，查看 OpenShift Container Platform 中运行的 pod：
						
$ oc get pods

							您应看到其中一行命令以 myapp-<number>-<hash> 开头，这是您在 OpenShift Container Platform 中运行的应用程序。
							在应用程序正常工作前，您必须运行数据库迁移脚本来初始化数据库。具体可通过两种方式实现：
									从正在运行的前端容器手动实现：
											使用 rsh 命令执行到前端容器中：
										
$ oc rsh <frontend_pod_id>

											从容器内部运行迁移：
										
$ RAILS_ENV=production bundle exec rake db:migrate

											如果在 development 或 test 环境中运行 Rails 应用程序，则不必指定 RAILS_ENV 环境变量。
									通过在模板中添加部署前生命周期 hook。
								

您可公开服务来为您的应用程序创建路由。 要通过向服务提供外部可访问的主机名（如 www.example.com ）来公开服务，请使用 OpenShift Container Platform 路由。对于您的情况，需要通过键入以下命令来公开前端服务：

$ oc expose service rails-app --hostname=www.example.com

您可采用两种方式管理 Jenkins 身份验证： OpenShift Container Platform OAuth 身份验证由 OpenShift Container Platform Login 插件提供。 由 Jenkins 提供的标准身份验证。

$ oc new-app -e \
    JENKINS_PASSWORD=<password> \
    openshift4/ose-jenkins

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

如果要在与您的项目不同的其他位置运行 Jenkins，则必须向 Jenkins 提供访问令牌来访问您的项目。 识别对 Jenkins 必须访问的项目具有适当访问权限的服务帐户的 secret：

$ oc describe serviceaccount jenkins

Name:       default
Labels:     <none>
Secrets:    {  jenkins-token-uyswp    }
            {  jenkins-dockercfg-xcr3d    }
Tokens:     jenkins-token-izv1u
            jenkins-token-uyswp

$ oc describe secret <secret name from above>

Name:       jenkins-token-uyswp
Labels:     <none>
Annotations:    kubernetes.io/service-account.name=jenkins,kubernetes.io/service-account.uid=32f5b661-2a8f-11e5-9528-3c970e3bf0b7
Type:   kubernetes.io/service-account-token
ca.crt: 1066 bytes
token:  eyJhbGc..<content cut>....wRA

可使用挂载卷运行 Jenkins 镜像，以便为配置启用持久性存储： /var/lib/jenkins 是 Jenkins 存储配置文件的数据目录，包括任务定义。

要自定义官方 OpenShift Container Platform Jenkins 镜像，您可以使用该镜像作为 Source-to-image（S2I）构建程序。 您可使用 S2I 来复制自定义 Jenkins 任务定义，添加其它插件，或使用您自己的自定义配置来替换所提供的 config.xml 文件。 要在 Jenkins 镜像中包括您的修改，必须要有采用以下目录结构的 Git 存储库：

pluginId:pluginVersion

OpenShift Container Platform Jenkins 镜像包含预装的 Kubernetes 插件 ，支持使用 Kubernes 和 OpenShift Container Platform 在多个容器主机上动态置备 Jenkins 代理。 为了使用 Kubernetes 插件，OpenShift Container Platform 提供了适合用作 Jenkins 代理的镜像，包括 Base、Maven 和 Node.js 镜像。 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 Container Platform Sync 插件，Jenkins 启动上的 Jenkins 镜像会在其运行的项目中或插件配置中特别列出的项目中搜索以下内容： 将标签 role 设置为 jenkins-agent 的镜像流。 将注解 role 设置为 jenkins-agent 的镜像流标签。 将标签 role 设置为 jenkins-agent 的配置映射。 当找到具有适当标签的镜像流或带有适当注解的镜像流标签时，它会生成对应的 Kubernetes 插件配置，以便您可以将 Jenkins 任务分配在运行镜像流提供的容器镜像的 pod 中运行。 镜像流或镜像流标签的名称和镜像引用映射到 Kubernetes 插件 pod 模板中的名称和镜像字段。您可以通过使用 agent-label 键在镜像流或镜像流标签对象上设置注解来控制 Kubernetes 插件 pod 模板的标签字段。否则，名称将用作标签。 不要登录到 Jenkins 控制台，也不要修改 pod 模板配置。如果您在创建 pod 模板后这样做，且 OpenShift Container Platform Sync 插件检测到与镜像流或镜像流标签关联的镜像已更改，则该插件会替换 pod 模板并覆盖这些配置更改。您无法将新配置与现有配置合并。 如果您的配置需要更复杂的配置需求，请考虑配置映射方法。 当找到具有适当标签的配置映射时，它会假定配置映射的键值数据有效负载中的任何值均包含与 Jenkins 和 Kubernetes 插件 pod 模板的配置格式一致的 XML。使用配置映射而非镜像流或镜像流标签时，需要注意的一个关键区别在于，您可以控制 Kubernetes 插件 pod 模板的所有参数。

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
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>

在 ConfigMap 中，如果 Pod 模板 XML 的 <serviceAccount> 元素是用于生成的 pod 的 OpenShift Container Platform 服务帐户，则服务帐户凭证将挂载到 pod 中。权限与服务帐户关联，并控制允许从 pod 对 OpenShift Container Platform master 执行的操作。 考虑以下场景，服务帐户用于 OpenShift Container Platform Jenkins 镜像中运行的 Kubernetes 插件启动的 pod： 如果您使用 OpenShift Container Platform 提供的 Jenkins 示例模板，则 jenkins 服务帐户将由运行 Jenkins 的项目的 edit 角色定义，且 master Jenkins Pod 已挂载了该服务帐户。 注入 Jenkins 配置的两个默认 Maven 和 NodeJS Pod 模板也将设置为使用与 Jenkins master 相同的服务帐户。 由于镜像流或 imagestreamtag 具有所需的标签或注解而被 OpenShift Container Platform Sync 插件自动发现的任何 Pod 模板均会被配置为使用 Jenkins master 的服务帐户作为其服务帐户。 对于其他方法，您可在 Jenkins 和 Kubernetes 插件中提供 Pod 模板定义，但必须明确指定要使用的服务帐户。其它方法包括 Jenkins 控制台、由 Kubernetes 插件提供的 podTemplate 管道 DSL，或标记其数据为 Pod 模板的 XML 配置的 ConfigMap。 如果没有为服务帐户指定值，则将使用 default 服务帐户。 确保所使用的任何服务帐户均具有 OpenShift Container Platform 中定义的必要权限、角色等，以操作您选择从 pod 中操作的任何项目。

模板提供参数字段来定义具有预定义默认值的所有环境变量。OpenShift Container Platform 提供模板，以简化 Jenkins 服务的新建操作。在初始集群设置期间，您的集群管理员应在默认 openshift 项目中注册 Jenkins 模板。 提供的两个模板均定义了部署配置和服务。两个模板的不同之处在于存储策略，这会影响在 Pod 重启后是否保留 Jenkins 内容。 当 Pod 移到另一节点，或当对部署配置的更新触发了重新部署时，Pod 可能会重启。 jenkins-ephemeral 使用临时存储。Pod 重启时，所有数据都会丢失。该模板仅适用于开发或测试。 jenkins-persistent 使用持久性卷（PV）存储。数据不会因 Pod 重启而丢失。 要使用 PV 存储，集群管理员必须在 OpenShift Container Platform 部署中定义一个 PV 池。 选好所需模板后，您还必须对模板进行实例化，才能使用 Jenkins。 使用以下任一方法新建 Jenkins 应用程序： 一个 PV：

$ oc new-app jenkins-persistent

$ oc new-app jenkins-ephemeral

在以下示例中， openshift-jee-sample BuildConfig 对象会导致 Jenkins Maven 代理 pod 动态置备。pod 会克隆一些 Java 源代码，构建一个 WAR 文件，并导致第二个 BuildConfig openshift-jee-sample-docker 运行。第二个 BuildConfig 会将新的 WAR 文件分层到一个容器镜像中。

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: image.openshift.io/v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: build.openshift.io/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:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: build.openshift.io/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

kind: BuildConfig
apiVersion: build.openshift.io/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

使用所提供的 Jenkins Ephemeral 或 Jenkins Persistent 模板部署时，默认内存限值为 1 Gi 。 默认情况下，Jenkins 容器中运行的所有其他进程使用的内存总量不超过 512 MiB 。如果这些进程需要更多内存，容器将停止。因此，我们强烈建议管道尽可能在代理容器中运行外部命令。 如果 Project 配额允许，请参阅 Jenkins 文档，了解 Jenkins master 应具有多少内存的建议。这些建议禁止为 Jenkins master 分配更多内存。 建议您为 Jenkins Kubernetes 插件创建的代理容器指定内存请求和限制值。管理员用户可通过 Jenkins 配置基于每个代理镜像设置默认值。内存请求和限值参数也可基于每个容器覆盖。 在实例化 Jenkins Ephemeral 或 Jenkins Persistent 模板时，您可通过覆盖 MEMORY_LIMIT 参数来增加 Jenkins 的可用内存量。

OpenShift Container Platform Jenkins 代理镜像在 Quay.io 或 registry.redhat.io 上提供。 Jenkins 镜像通过 Red Hat Registry 提供：

$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-10-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-12-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-maven:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-base:<v4.5.0>

要使用这些镜像，您可直接从 Quay.io 或 registry.redhat.io 访问或将其推送（push）到 OpenShift Container Platform 容器镜像 registry 中。

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

所有 Jenkins 代理均使用 JVM 来托管 Jenkins JNLP 代理和运行任何 Java 应用程序，如 javac 、Maven 或 Gradle。 默认情况下，Jenkins JNLP 代理 JVM 会将容器内存限值的 50% 用于其堆。该值可通过 CONTAINER_HEAP_PERCENT 环境变量修改，还可设置上限或整个覆盖。 默认情况下，Jenkins 代理容器中运行的其它进程（如 shell 脚本或从管道运行的 oc 命令）在不引发 OOM 终止的情况下，所用内存均不得超过剩余的 50% 内存限值。 默认情况下，Jenkins 代理容器中运行的每个其他 JVM 进程最多可将 25％ 的容器内存限值用于其堆。对于很多构建工作负载，可能还需调整此限值。

在 OpenShift Container Platform 上的 Jenkins 代理中托管 Gradle 构建会出现其他复杂情况，因为除了 Jenkins JNLP 代理和 Gradle JVM 外，Gradle 还会生成第三个 JVM 来运行测试（若已指定）。 建议将以下设置作为起始点，在 OpenShift Container Platform 上内存受限的 Jenkins 代理中运行 Gradle 构建。您还可按需修改这些设置。 通过将 org.gradle.daemon=false 添加到 gradle.properties 文件中来确保禁用长期 Gradle 守护进程。 通过确保 gradle.properties 文件中未设置 org.gradle.parallel=true 且 --parallel 未设置为命令行参数来禁用并行构建执行。 要防止 Java 编译超出进程范围，请在 build.gradle 文件中设置 java { options.fork = false } 。 通过确保在 build.gradle 文件中设置 test { maxParallelForks = 1 } 来禁用多个附加测试进程。 使用 GRADLE_OPTS 、 JAVA_OPTS 或 JAVA_TOOL_OPTIONS 环境变量覆盖 Gradle JVM 内存参数。 通过在 build.gradle 中定义 maxHeapSize 和 jvmArgs 设置，或通过 -Dorg.gradle.jvmargs 命令行参数来为任何 Gradle 测试 JVM 设置最大堆大小和 JVM 参数。

构建完成后或停止后会默认删除 Jenkins 代理 pod。此行为可通过 Kubernetes 插件 pod 保留设置来更改。Pod 保留可针对所有 Jenkins 构建设置，并覆盖每个 pod 模板。支持以下行为： Always 保留构建 pod，不受构建结果的限制。 Default 使用插件值，即仅限 pod 模板。 Never 始终删除 pod。 On Failure 如果构建过程中失败，则保留 pod。 您可覆盖管道 Jenkinsfile 中的 pod 保留：

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 1
  containers: [
  node("mypod") {
							podRetention 允许的值为 never()、onFailure()、always() 和 default()。
						保留的 Pod 可能会根据资源配额继续运行和计数。
					

Source-to-Image（S2I）通过将源代码注入准备要运行的源代码的容器来生成可随时运行的镜像。它执行以下步骤： 运行 FROM <builder image> 命令 将源代码复制到构建器镜像中定义的位置 在构建器镜像中运行 assemble 脚本 将构建器镜像中的 run 脚本设置为默认命令 然后，Buildah 会创建容器镜像。

构建器镜像提供自己的 Source-to-image（S2I）脚本版本，它适用于最常用的用例。如果这些脚本无法满足您的需要，S2I 提供了在 .s2i/bin 目录中添加自定义脚本覆盖它们的方法。但是，这样做代表完全替换了标准脚本。在某些情况下，替换脚本是可以接受的，但在其他情况下，您可以在脚本之前或之后运行一些命令，同时保留镜像中提供的脚本逻辑。要重复使用标准脚本，您可以创建一个运行自定义逻辑的 wrapper 脚本，并将它进一步分配给镜像中的默认脚本。 查看 io.openshift.s2i.scripts-url 标签的值，以确定构建器镜像中的脚本位置：

$ podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7

image:///usr/libexec/s2i

#!/bin/bash
echo "Before assembling"
/usr/libexec/s2i/assemble
rc=$?
if [ $rc -eq 0 ]; then
    echo "After successful assembling"
    echo "After failed assembling"
exit $rc

#!/bin/bash
echo "Before running application"
exec /usr/libexec/s2i/run