开发人员指南

OpenShift Container Platform 专为构建和部署应用程序而设计。根据开发过程中涉及的 OpenShift Container Platform 量，您可以选择：

您可以直接使用 OpenShift Container Platform 从头开始开始应用程序的开发。在规划此类型的开发过程中请考虑以下步骤：

初始规划

访问 OpenShift Container Platform

开发

Generate

管理

验证

另一种可能的应用程序开发策略是在本地开发，然后使用 OpenShift Container Platform 部署您完全开发的应用程序。如果计划已有应用程序代码，请使用以下步骤，然后在完成后构建并部署到 OpenShift Container Platform 安装中：

初始规划

开发

访问 OpenShift Container Platform

Generate

验证

管理

您可以使用 OpenShift CLI 或 Web 控制台，从包括源代码或二进制代码、镜像和/或模板在内的组件创建一个新的 OpenShift Container Platform 应用程序。

应用程序提升意味着通过各种运行时环境迁移应用程序，通常具有更高程度的成熟度。例如，应用程序可能会在开发环境中启动，然后提升到暂存环境以进一步进行测试，然后才会出现在生产环境中。随着应用中引入的变化，再次更改将在开发中开始，并在 stage 和生产环境中推广。

当今的"应用程序"不仅仅是使用 Java、Perl 和 Python 等编写的源代码。现在，它比静态 Web 内容、集成脚本或应用特定运行时的相关配置更多。它不仅仅是由那些语言特定运行时使用的应用程序特定存档。

在 OpenShift Container Platform 及其 Kubernetes 和 Docker 的组合部分中，额外的应用程序工件包括：

在 OpenShift Container Platform 中如何推广应用程序，这个主题将：

在这种情况下，部署环境描述了在 CI/CD 管道的特定阶段运行应用程序的不同空间。典型环境包括 开发、测试、stage 和生产，例如：环境边界可以以不同的方式定义，例如：

它取决于您的组织是否全部利用了所有三个产品。

从根本上而言，应用程序提升是一种将上述应用程序组件从一个环境移至另一个环境的过程。以下小节概述了可用于手动移动各种组件的工具，然后再讨论用于自动化应用程序提升的完整解决方案。

在 Docker、Kubernetes 和 OpenShift Container Platform 生态系统中定义了新的应用程序工件组件，本节介绍了如何使用 OpenShift Container Platform 提供的机制和工具在环境之间提升这些组件。

镜像是组成应用程序的组件的主要工件。采用该内部环境并将其扩展至应用程序提升、核心、基本应用程序提升模式是映像提升，其中工作单元是镜像。大多数应用程序促销方案通过提升管道管理和传播镜像。

仅仅通过管道管理和传播镜像的简单场景。随着推广方案的范围广泛，其他应用程序工件（特别是 API 对象）都包含在通过管道进行管理和传播的项目清单中。

本主题介绍了一些有关使用手动和自动化方法来提升镜像以及 API 对象的特定示例。但请注意以下设置应用程序提升管道的环境。

若要使用 Web 控制台创建新项目，请单击 Projects 面板或 Projects 页面上的 Create Project 按钮。

默认情况下会显示 Create Project 按钮，但可以选择进行隐藏或自定义。

使用 CLI 创建新项目：

$ oc new-project <project_name> \
    --description="<description>" --display-name="<display_name>"

例如：

$ oc new-project hello-openshift \
    --description="This is an example project to demonstrate OpenShift v3" \
    --display-name="Hello OpenShift"

本节复习如何将 MySQL、PostgreSQL 和 MongoDB 数据库应用程序从 OpenShift 版本 2(v2)迁移到 OpenShift 版本 3(v3)。

支持的 MySQL 环境变量

支持的 PostgreSQL 环境变量

支持的 MongoDB 环境变量

本主题介绍了如何将 Python、Ruby、PHP、Perl、Node.js、WordPress、Ghost、JBoss EAP、JBoss WS(Tomcat)和 Wildfly 10(JBoss AS)Web 框架应用程序从 OpenShift 版本 2(v2)迁移到 OpenShift 版本 3(v3)。

支持的 Python 版本

支持的 Ruby 版本

支持的 PHP 版本

$ oc new-app https://github.com/<github-id>/<repo-name>.git

支持的 Perl 版本

支持的 Node.js 版本

有关将 WordPress 应用程序迁移到 OpenShift Container Platform v3 的指南，请参阅 OpenShift 博客。

有关将 Ghost 应用程序迁移到 OpenShift Container Platform v3 的指导，请参阅 OpenShift 博客。

虽然 v2 quickstart to v3 Quickstart 没有清晰的迁移路径，但 v3 当前有以下快速入门。如果您的应用程序带有数据库，而不是使用 oc new-app 创建应用程序，则 oc new-app 会再次启动一个单独的数据库服务并使用通用环境变量将这两个应用程序链接到一起，您可以使用以下方法一次性从包含您的源代码的 GitHub 存储库中实例化链接的应用程序和数据库。您可以使用 oc get templates -n openshift 列出所有可用模板：

本地运行上述模板 URL 的 git clone。添加并提交应用程序源代码并推送 GitHub 存储库，然后从上面列出的其中一个模板启动 v3 Quickstart 应用程序：

本节回顾 OpenShift 版本 2(v2)和 OpenShift 版本 3(v3)之间的持续集成和部署(CI/CD)应用的不同，以及如何将这些应用程序迁移到 v3 环境中。

OpenShift 版本 2(v2)和 OpenShift 版本 3(v3)中的 Jenkins 应用会因为架构中的基本差异而进行不同的配置。例如，在 v2 中，应用程序使用托管在 gear 中的集成 Git 存储库来存储源代码。在 v3 中，源代码位于托管在 pod 之外的公共或私有 Git 存储库中。

另外，在 OpenShift v3 中，Jenkins 作业只能被源代码更改触发，还由 ImageStream 中的更改，后者会更改用于构建应用的镜像及其源代码。因此，强烈建议您通过在 v3 中创建新的 Jenkins 应用来手动迁移 Jenkins 应用，然后使用适合 OpenShift v3 环境的配置重新创建作业。

请参考这些资源以了解有关如何创建 Jenkins 应用程序、配置作业和正确使用 Jenkins 插件的更多信息：

本节回顾 OpenShift 版本 2(v2)和 OpenShift 版本 3(v3)之间的 webhook 和操作 hook，以及如何将这些应用迁移到 v3 环境中。

您应该看到一条来自 GitHub 的消息，说明您的 Webhook 已配置成功。

现在，每当您将更改推送到 GitHub 存储库时，新构建会自动启动，成功构建后也会启动新部署。

在 OpenShift 版本 2(v2)中，有构建、部署、post_deploy 和 pre_build 脚本或 action_hooks 位于 .openshift/action_hooks 目录中。虽然 v3 中没有适用于这些功能的一个一对一映射，但 v3 中的 S2I 工具有添加可自定义脚本的选项，在指定的 URL 或您的源存储库的 .s2i/bin 目录中。

OpenShift 版本 3(v3)还提供 post-build hook，用于运行镜像构建后镜像的基本测试，然后再推送到 registry。部署 hook 在部署配置中配置。

在 v2 中，action_hooks 通常用于设置环境变量。在 v2 中，任何环境变量都应该传递：

$ oc new-app <source-url> -e ENV_VAR=env_var

或：

$ oc new-app <template-name> -p ENV_VAR=env_var

另外，也可使用以下方法添加或更改环境变量：

$ oc set env dc/<name-of-dc>
ENV_VAR1=env_var1 ENV_VAR2=env_var2’

Source-to-Image(S2I)工具将应用源代码注入到容器镜像中，最终产品是一个新的、可直接运行的容器镜像，它融合了构建器镜像和构建的源代码。S2I 工具可以安装到本地机器上，而没有来自存储库的 OpenShift Container Platform。

S2I 工具是一个非常强大的工具，用于在 OpenShift Container Platform 上使用应用程序之前在本地测试和验证应用程序和镜像。

本主题回顾了 OpenShift 版本 2(v2)和 OpenShift 版本 3(v3)支持的语言、框架、数据库和标记。

如需有关 OpenShift Container Platform 客户使用的通用组合的更多信息，请参阅 OpenShift Container Platform 测试的集成。

请参阅 Database Applications 的支持的 Databases 部分。

快速入门是 OpenShift Container Platform 上运行的应用程序的基本示例。Quickstarts 提供多种语言和框架，并在模板中定义，模板由一组服务、构建配置和部署配置组成。该模板引用了构建和部署应用程序所需的镜像和源存储库。

要探索快速入门，请从模板创建应用程序。您的管理员可能已在您的 OpenShift Container Platform 集群中安装了这些模板，在这种情况下，您只需从 web 控制台中选择即可。有关如何上传、从中创建和修改 模板 的更多信息，请参阅模板文档。

Quickstarts 是指包含应用程序源代码的源存储库。要自定义 Quickstart，请分叉存储库，并在从模板创建应用程序时，用分叉的存储库替换默认的源存储库名称。这将导致使用您的源代码而非所提供的示例源来执行构建。然后，您可以更新源存储库中的代码，并启动新的构建来查看反映在所部署的应用程序中的更改。

这些快速入门提供了指定框架和语言的基本应用程序：

Ruby on Rails 是使用 Ruby 编写的流行 web 框架。本指南介绍在 OpenShift Container Platform 上使用 Rails 4。

对于本指南，您需要：

首先，确保 OpenShift Container Platform 实例正在运行且可用。有关如何启动并运行 OpenShift Container Platform 的更多信息，请检查 安装方法。另外，确保已安装 oc CLI 客户端，且可从命令 shell 访问命令，因此您可以使用您的电子邮件地址和密码使用它来 登录。

$ sudo yum install -y postgresql postgresql-server postgresql-devel

$ sudo postgresql-setup initdb

$ sudo systemctl start postgresql.service

$ sudo -u postgres createuser -s rails

如果您要从头开始启动 Rails 应用程序，则需要首先安装 Rails gem。

$ gem install rails
Successfully installed rails-4.2.0
1 gem installed

安装完 Rails gem 后，使用 PostgreSQL 创建一个新应用程序，作为数据库：

$ rails new rails-app --database=postgresql

然后，更改到您的新应用目录。

$ cd rails-app

如果您已有应用程序，请确保 Gemfile 中存在 pg (postgresql) gem。如果没有通过添加 gem 来编辑 Gemfile ：

gem 'pg'

使用您的所有依赖项生成一个新的 Gemfile.lock ：

$ bundle install

除了将 postgresql 数据库与 pg gem 结合使用外，还需要确保 config/database.yml 正在使用 postgresql 适配器。

请确保更新了 config/database.yml 文件中的 default 部分，如下所示：

default: &default
  adapter: postgresql
  encoding: unicode
  pool: 5
  host: localhost
  username: rails
  password:

使用此 rake 命令创建应用程序的开发和测试数据库：

$ rake db:create

这将在您的 PostgreSQL 服务器中创建 development 和 test 数据库。

$ rails generate controller welcome index

root 'welcome#index'

$ rails server

<% 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"] %>

$ ls -1
app
bin
config
config.ru
db
Gemfile
Gemfile.lock
lib
log
public
Rakefile
README.rdoc
test
tmp
vendor

$ git init
$ git add .
$ git commit -m "initial commit"

$ git remote add origin git@github.com:<namespace/repository-name>.git

$ git push

要部署 Ruby on Rails 应用程序，为应用程序创建一个新项目：

$ oc new-project rails-app --description="My Rails application" --display-name="Rails Application"

创建 rails-app 项目 后，您将自动切换到新的项目命名空间。

在 OpenShift Container Platform 中部署应用程序涉及三个步骤：

$ 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

$ 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

$ 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

$ oc get pods

$ oc rsh <FRONTEND_POD_ID>

$ RAILS_ENV=production bundle exec rake db:migrate

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

使用 Java 和 Maven 开发应用时，您很可能会构建多次。为了缩短容器集的构建时间，可将 Maven 依赖项缓存在本地 Nexus 存储库中。本教程将指导您在群集上创建 Nexus 存储库。

本教程假设您正在处理已经设置用于 Maven 的项目。如果您有兴趣将 Maven 与 Java 项目搭配使用，则强烈建议您查阅 其指南。

另外，请确定检查应用程序的镜像以获取 Maven 镜像功能。使用 Maven 的许多镜像都有 MAVEN_MIRROR_URL 环境变量，可用于简化此过程。如果它没有这一功能，请阅读 Nexus 文档 以正确配置您的构建。

另外，请确保为每个 pod 有足够的资源才能正常工作。您可能必须 编辑 Nexus 部署配置中的 Pod 模板，以请求更多资源。

后续步骤中演示定义使用新的 Nexus 存储库的构建。教程的其余部分将这个示例存储库 与 wildfly-100-centos7 一起用作构建器，但这些更改应该可用于任何项目。

示例构建器镜像 支持 MAVEN_MIRROR_URL 作为其环境的一部分，因此我们可以使用此 将构建器镜像指向我们的 Nexus 存储库。如果您的镜像不支持使用环境变量来配置 Maven 镜像，您可能需要修改构建器镜像，以提供正确的 Maven 设置以指向 Nexus 镜像。

$ oc new-build openshift/wildfly-100-centos7:latest~https://github.com/openshift/jee-ex.git \
	-e MAVEN_MIRROR_URL='http://nexus.<Nexus_Project>:8081/nexus/content/groups/public'
$ oc logs build/jee-ex-1 --follow

将 <Nexus_Project> 替换为 Nexus 存储库的项目名称。如果该项目与正在使用的应用程序位于同一个项目中，您可以删除 <Nexus_Project>.。在 OpenShift Container Platform 中了解更多有关 DNS 解析的信息。

在 Web 浏览器中，导航到 http://<NexusIP>:8081/nexus/content/groups/public，以确认它已存储了应用程序的依赖项。您还可以检查构建日志，以查看 Maven 是否使用 Nexus 镜像。如果成功，您应该会看到引用 URL http://nexus:8081 的输出。

无论您创建简单的网站还是复杂的微服务 Web，请使用 OpenShift Pipelines 在 OpenShift 中构建、测试、部署和推进您的应用程序。

除了标准的 Jenkins 管道语法外，OpenShift Jenkins 镜像还提供 OpenShift 域特定语言(DSL)（通过 OpenShift Jenkins 客户端插件），其旨在提供易读、简洁、全面和流畅的语法，以便与 OpenShift API 服务器进行丰富的交互，甚至能更好地控制 OpenShift 集群上的应用程序的构建、部署和推广。

本例演示如何创建 OpenShift Pipeline，以使用 nodejs-mongodb.json 模板构建、部署和验证 Node.js/MongoDB 应用程序。

要创建 Jenkins master，请运行：

  $ oc project <project_name> 1
  $ oc new-app jenkins-ephemeral 2

现在 Jenkins master 已启动并运行，请创建一个 BuildConfig，它将使用 Jenkins Pipeline 策略来构建、部署和扩展 Node.js/MongoDB 示例应用程序。

使用以下内容，创建名为 nodejs-sample-pipeline.yaml 的文件：

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "nodejs-sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: <pipeline content from below>
    type: JenkinsPipeline

有关配置 Pipeline 构建策略的更多信息，请参阅 Pipeline 策略选项。

使用 jenkinsPipelineStrategy 创建 BuildConfig 后，通过使用内联 jenkinsfile 告知管道做什么。本例没有为应用程序设置 Git 存储库。

以下 jenkinsfile 内容使用 OpenShift DSL 以 Groovy 语言编写。在本例中，请使用 YAML Literal Style 在 BuildConfig 中包含内联内容，但首选的方法是使用源存储库中的 jenkinsfile。

完成的 BuildConfig 可以在示例目录 nodejs-sample-pipeline.yaml 中的 OpenShift Origin 存储库中查看。

def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1
def templateName = 'nodejs-mongodb-example' 2
pipeline {
  agent {
    node {
      label 'nodejs' 3
    }
  }
  options {
    timeout(time: 20, unit: 'MINUTES') 4
  }
  stages {
    stage('preamble') {
        steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                        echo "Using project: ${openshift.project()}"
                    }
                }
            }
        }
    }
    stage('cleanup') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.selector("all", [ template : templateName ]).delete() 5
                  if (openshift.selector("secrets", templateName).exists()) { 6
                    openshift.selector("secrets", templateName).delete()
                  }
                }
            }
        }
      }
    }
    stage('create') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.newApp(templatePath) 7
                }
            }
        }
      }
    }
    stage('build') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def builds = openshift.selector("bc", templateName).related('builds')
                  timeout(5) { 8
                    builds.untilEach(1) {
                      return (it.object().status.phase == "Complete")
                    }
                  }
                }
            }
        }
      }
    }
    stage('deploy') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def rm = openshift.selector("dc", templateName).rollout().latest()
                  timeout(5) { 9
                    openshift.selector("dc", templateName).related('pods').untilEach(1) {
                      return (it.object().status.phase == "Running")
                    }
                  }
                }
            }
        }
      }
    }
    stage('tag') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10
                }
            }
        }
      }
    }
  }
}

您可以通过运行以下命令，在 OpenShift 集群中创建 BuildConfig：

$ oc create -f nodejs-sample-pipeline.yaml

如果您不想自行创建文件，可以通过运行以下命令来使用 Origin 存储库中的示例：

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

有关此处使用的 OpenShift DSL 语法的更多信息，请参阅 OpenShift Jenkins 客户端插件。

使用以下命令启动管道：

$ oc start-build nodejs-sample-pipeline

管道启动之后，您应该看到项目中执行了以下操作：

使用 OpenShift Pipelines，您可以在一个项目中启动 Jenkins，然后让 OpenShift 同步插件监控开发人员在其中工作的一组项目。以下小节概述了完成此过程的步骤。

OpenShift 中的二进制构建功能使开发人员能够将源或工件直接上传到构建中，而不是从 Git 存储库 URL 中拉取源。任何带有 source、Docker 或 custom 的 BuildConfig 都可以作为二进制构建启动。从本地工件启动构建时，现有源引用将被替换为来自本地用户机器的源。

源可以通过几种方法提供，它们对应于使用 start-build 命令时可用的参数：

以下教程假设您有一个可用的 OpenShift 集群，并且具有可在创建工件的项目。它需要在本地同时拥有 git 和 oc。

$ git checkout -b my_branch
$ git add .
$ git commit -m "My changes"
$ oc start-build ruby-hello-world --from-repo="." --follow

OpenShift Container Platform 中的 构建 是将输入参数转换为结果对象的过程。大多数情况下，构建用于将源代码转换为可运行的容器镜像。

构建配置或 BuildConfig 的特征就是构建策略和一个或多个源。策略决定上述过程，而源则提供输入。

构建策略有：

有六种类型的源作为构建输入提供 ：

每个构建策略最多可考虑或忽略特定类型的源，并确定要使用方法。Binary 和 Git 是互斥源类型。Dockerfile 和镜像可以单独单独使用，也可以与 Git 或 Binary 一起使用。Binary 源类型在 向系统指定选项中的其它选项 中是唯一的。

构建配置描述了单个构建定义，以及应该创建新构建时的一组 触发器。构建配置通过 BuildConfig 定义，它是一种 REST 对象，可在对 API 服务器的 POST 中使用以创建新实例。

根据您选择使用 OpenShift Container Platform 创建应用程序的方式，如果使用 Web 控制台或 CLI，通常会自动生成 BuildConfig，并且可以随时对其进行编辑。如果选择稍后手动调整配置，则了解 BuildConfig 的组成部分及其可用选项可能会有所帮助。

以下示例 BuildConfig 在每次容器镜像标签或源代码改变时产生新的构建：

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "ruby-sample-build" 1
spec:
  runPolicy: "Serial" 2
  triggers: 3
    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 4
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 5
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 6
    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 7
      script: "bundle exec rake test"

使用以下命令，从当前项目中的现有构建配置手动启动新构建：

$ oc start-build <buildconfig_name>

使用 --from-build 标志重新运行构建：

$ oc start-build --from-build=<build_name>

指定 --follow 标志，在 stdout 中流传输构建日志：

$ oc start-build <buildconfig_name> --follow

指定 --env 标志来为构建设置任何所需的环境变量：

$ oc start-build <buildconfig_name> --env=<key>=<value>

您可以通过直接推送源来启动构建，而不依赖于 Git 源拉取或构建的 Dockerfile；源可以是 Git 或 SVN 工作目录的内容、您想要部署的一组预构建二进制工件，或者单个文件。这可以通过为 start-build 命令指定以下选项之一来完成：

将任何这些选项直接传递给构建时，内容将流传输到构建中并覆盖当前的构建源设置。

例如，以下命令将发送本地 Git 存储库的内容作为标签 v2 的存档，再启动构建：

$ oc start-build hello-world --from-repo=../hello-world --commit=v2

使用 Web 控制台或以下 CLI 命令手动取消构建：

$ oc cancel-build <build_name>

同时取消多个构建：

$ oc cancel-build <build1_name> <build2_name> <build3_name>

取消从构建配置创建的所有构建：

$ oc cancel-build bc/<buildconfig_name>

取消给定状态下的所有构建（如 new 或 pending状态），忽略其他状态下的构建：

$ oc cancel-build bc/<buildconfig_name>  --state=<state>

使用以下命令删除 BuildConfig ：

$ oc delete bc <BuildConfigName>

这也会删除从此 BuildConfig 实例化的所有构建。如果您不想删除构建，请指定 --cascade=false 标志：

$ oc delete --cascade=false bc <BuildConfigName>

您可以使用 Web 控制台或 oc describe CLI 命令查看构建详情：

$ oc describe build <build_name>

这将显示诸如以下信息：

如果构建采用 Docker 或 Source 策略，则 oc describe 输出还包括用于构建的源修订的相关信息，包括提交 ID、作者、提交者和消息等。

您可以使用 Web 控制台或 CLI 访问构建日志。

直接使用构建来流传输日志：

$ oc logs -f build/<build_name>

流传输构建配置的最新构建的日志：

$ oc logs -f bc/<buildconfig_name>

返回构建配置的给定版本构建的日志：

$ oc logs --version=<number> bc/<buildconfig_name>

日志详细程度

要启用更为详细的输出，请传递 BUILD_LOGLEVEL 环境变量作为 BuildConfig 中 sourceStrategy 或 dockerStrategy 的一部分：

sourceStrategy:
...
  env:
    - name: "BUILD_LOGLEVEL"
      value: "2" 1

Source 构建的可用日志级别如下：

构建输入提供构建操作的源内容。在 OpenShift Container Platform 中，可以通过几种方法提供源。顺序排列：

不同的输入可以合并为一个构建。由于内联 Dockerfile 具有优先权，它可覆盖由另一个输入提供的名为 Dockerfile 的任何其他文件。二进制（本地）和 Git 存储库是互斥的输入。

当您不希望在构建生成的最终应用程序镜像中提供构建期间使用的某些资源或凭证，或者想要消耗在 Secret 资源中定义的值时，输入 secret 很有用。外部工件可用于拉取不以其他任一构建输入类型提供的额外文件。

每当运行构建时：

以下源定义示例包括多种输入类型，以及它们如何组合的说明。如需有关如何定义各种输入类型的更多详细信息，请参阅每种输入类型的具体小节。

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 1
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 2
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 3
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4

提供 dockerfile 值时，此字段的内容将写到磁盘上，存为名为 Dockerfile 的文件。这是处理完其他输入源之后完成的；因此，如果输入源存储库的根目录中包含 Dockerfile，它会被此内容覆盖。

此字段的典型用途是为 Docker 策略构建 提供 Dockerfile。

源定义是 BuildConfig 的 spec 部分的一部分：

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1

可以通过镜像为构建过程提供额外的文件。输入镜像的引用方式与定义 From 和 To 镜像目标的方式相同。这意味着可以引用容器镜像和 镜像流标签。在使用镜像时，必须提供一个或多个路径对，以指示要复制镜像的文件或目录的路径以及构建上下文中要放置它们的目的地。

源路径可以是指定镜像内的任何绝对路径。目的地必须是相对目录路径。构建时会加载镜像，并将指定的文件和目录复制到构建过程上下文目录中。这与源存储库内容（若有）要克隆到的目录相同。如果源路径以 /. 结尾，则复制目录的内容，但不在目的地上创建该目录本身。

镜像输入在 BuildConfig 的 source 定义中指定：

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
  images: 1
  - from: 2
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 3
    - destinationDir: injected/dir 4
      sourcePath: /usr/lib/somefile.jar 5
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 6
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

指定后，将从提供的位置获取源代码。

如果提供了内联 Dockerfile，它将覆盖 Git 存储库的 contextDir 中的 Dockerfile （若有）。

源定义是 BuildConfig 的 spec 部分的一部分：

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3

如果 ref 字段注明拉取请求，则系统将使用 git fetch 操作，然后 checkout FETCH_HEAD。

如果未提供 ref 值，OpenShift Container Platform 将执行浅克隆 (--depth=1)。这时，仅下载与默认分支（通常为 master）上最近提交相关联的文件。这将使存储库下载速度加快，但不会有完整的提交历史记录。要对指定存储库的默认分支执行完整 git clone，请将 ref 设为默认分支（如 master）的名称。

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

$ oc secrets link builder mysecret

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...

kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

$ oc set build-secret --source bc/sample-build basicsecret

$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

[http]
        sslVerify=false

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth

$ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth

$ ssh-keygen -t rsa -C "your_email@example.com"

$ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/known_hosts> \ 1
    --type=kubernetes.io/ssh-auth

从本地文件系统流传输内容到构建器称为 Binary 类型构建。对于此类构建，BuildConfig.spec.source.type 的对应值为 Binary。

这种源类型的独特之处在于，它仅基于您对 oc start-build 的使用而加以利用。

要使用二进制构建，请使用以下选项之一调用 oc start-build：

在以上每个情况下：

您可以将 HTTP 或 HTTPS 方案的 URL 传递给 --from-file 和 --from-archive，而不传递文件名。将 -from-file 与 URL 结合使用时，构建器镜像中文件的名称由 web 服务器发送的 Content-Disposition 标头决定，如果该标头不存在，则由 URL 路径的最后一个组件决定。不支持任何形式的身份验证，也无法使用自定义 TLS 证书或禁用证书验证。

使用 oc new-build --binary =true 时，该命令可确保强制执行与二进制构建关联的限制。生成的 BuildConfig 将具有 Binary 源类型，这意味着为此 BuildConfig 运行构建的唯一有效方法是使用 oc start-build 和其中一个 --from 选项来提供必需的二进制数据。

dockerfile 和 contextDir 源选项对 二进制构建具有特殊含义。

dockerfile 可以与任何二进制构建源一起使用。如果使用 dockerfile 且二进制流是存档，则其内容将充当存档中任何 Dockerfile 的替代 Dockerfile。如果结合使用 dockerfile 和 --from-file 参数，并且文件参数指定为 dockerfile，则 dockerfile 的值将取代二进制流中的值。

如果是二进制流封装提取的存档内容，contextDir 字段的值将解释为存档中的子目录，并且在有效时，构建器将在执行构建之前更改到该子目录。

有时候，构建操作需要凭证或其他配置数据才能访问依赖的资源，但又不希望将这些信息放在源代码控制中。您可以定义输入 secret 和输入 ConfigMap 来实现这一目的。

例如，在通过 Maven 构建 Java 应用程序时，您可以设置通过私钥访问的 Maven Central 或 JCenter 的私有镜像。要从该私有镜像下载库，您必须提供以下内容：

为安全起见，不应在应用程序镜像中公开您的凭证。

示例中描述的是 Java 应用程序，但您可以使用相同的方法将 SSL 证书添加到 /etc/ssl/certs 目录，以及添加 API 密钥或令牌、许可证文件等。

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

建议不要将二进制文件存储在源存储库中。因此，您可能会发现有必要定义一个构建，在构建过程中拉取其他文件（如 Java .jar 依赖项）。具体方法取决于使用的构建策略。

对于 Source 构建策略，必须在 assemble 脚本中放入适当的 shell 命令：

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
exec java -jar app.jar

对于 Docker 构建策略，您必须修改 Dockerfile 并通过 RUN 指令调用 shell 命令：

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

在实践中，您可能希望将环境变量用于文件位置，以便要下载的具体文件能够使用 BuildConfig 中定义的环境变量来自定义，而不必更新 Dockerfile 或 assemble 脚本。

您可以选择不同方法来定义环境变量：

您可以为构建提供 .docker/config.json 文件，在文件中包含私有容器 registry 的有效凭证。这样，您可以将输出镜像推送到私有容器镜像 registry 中，或从需要身份验证的私有容器镜像 registry 中拉取构建器镜像。

默认情况下，.docker/config.json 文件位于您的主目录中，并具有如下格式：

auths:
  https://index.docker.io/v1/: 1
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2
    email: "user@example.com" 3

您可以在此文件中定义多个容器镜像 registry 条目。或者，也可以通过运行 docker login 命令将身份验证条目添加到此文件中。如果文件不存在，则会创建此文件。

Kubernetes 提供 Secret 对象，可用于存储配置和密码。

使用 Docker 或 Source 策略的构建会创建新的容器镜像。镜像而后被推送到由 Build 规格的 output 部分中指定的容器镜像 registry 中。

如果输出类型是 ImageStreamTag，则镜像将推送到集成的 OpenShift Container Platform registry，并在指定的镜像流中标记。如果输出类型是 DockerImage，则输出引用的名称将用作 Docker 推送规格。规格中可以包含 registry；如果没有指定 registry，则默认为 DockerHub。如果 Build 规格的 output 部分为空，则构建结束时不推送镜像。

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

Docker 和 Source 策略构建在输出镜像上设置以下环境变量：

此外，任何用户定义的环境变量（例如，通过 Source 或 Docker 策略选项配置的环境变量）也将是输出镜像环境变量列表的一部分。

Docker 和 Source 构建在输出镜像上设置以下标签：

您还可以使用 BuildConfig.spec.output.imageLabels 字段指定将应用到从 BuildConfig 构建的每个镜像的自定义标签列表。

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

构建的镜像可由其 digest 唯一识别，后来可用于通过 digest（无论其当前标签是什么）来拉取镜像。

Docker 和 Source 构建会在镜像推送到 registry 后将摘要存储在 Build.status.output.to.imageDigest 中。摘要在 registry 中计算。因此，它可能无法始终存在，例如当 registry 没有返回摘要时，或者构建器镜像不知道其格式时。

status:
  output:
    to:
      imageDigest: sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912

要将镜像推送到私有容器镜像 registry，可以使用 secret 来提供凭证。具体步骤请参阅构建输入。

以下选项特定于 S2I 构建策略 ：

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest" 1
    forcePull: true 2

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "incremental-image:latest" 1
    incremental: true 2

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest"
    scripts: "http://somehost.com/scripts_directory" 1

sourceStrategy:
...
  env:
    - name: "DISABLE_ASSET_COMPILATION"
      value: "true"

以下选项特定于 Docker 构建策略 ：

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

strategy:
  dockerStrategy:
    noCache: true

strategy:
  dockerStrategy:
    forcePull: true 1

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

以下选项特定于 Custom 构建策略。

strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "registry.access.redhat.com/openshift3/ose-docker-builder"

strategy:
  customStrategy:
    exposeDockerSocket: true

strategy:
  customStrategy:
    secrets:
      - secretSource: 1
          name: "secret1"
        mountPath: "/tmp/secret1" 2
      - secretSource:
          name: "secret2"
        mountPath: "/tmp/secret2"

strategy:
  customStrategy:
    forcePull: true 1

customStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

以下选项特定于 Pipeline 构建策略。

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 1

jenkinsPipelineStrategy:
...
  env:
    - name: "FOO"
      value: "BAR"

与 pod 环境变量一样，可以使用 Downward API 在引用其他资源/变量时定义构建环境变量。但是，有几个例外情况如下。

您可以注入构建对象的信息，使用 fieldPath 环境变量源指定要获取值的字段的 JsonPath。

env:
  - name: FIELDREF_ENV
    valueFrom:
      fieldRef:
        fieldPath: metadata.name

不支持在构建环境变量中使用 valueFrom 引用容器资源，因为这种引用在创建容器之前解析。

您可以使用 valueFrom 语法，将 secret 的键值作为环境变量提供。

apiVersion: v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: MYVAL
        valueFrom:
          secretKeyRef:
            key: myval
            name: mysecret

在定义 BuildConfig 时，您可以定义触发器来控制应该运行 BuildConfig 的环境。可用的构建触发器如下：

Webhook 触发器通过发送请求到 OpenShift Container Platform API 端点来触发新构建。您可以使用 GitHub、GitLab、Bitbucket 或通用 Webhook 来定义这些触发器。

目前，OpenShift Container Platform Webhook 仅支持各种基于 Git 的源代码管理系统 (SCM) 的推送事件的类同版本。所有其他事件类型都会忽略。

处理推送事件时，会确认事件内的分支引用是否与相应 BuildConfig 中的分支引用匹配。如果匹配，则针对 OpenShift Container Platform 构建签出 Webhook 事件中记录的准确提交引用。如果不匹配，则不触发构建。

对于所有 Webhook，您必须使用名为 WebHookSecretKey 的键定义 Secret，并且其值是调用 Webhook 时要提供的值。然后，Webhook 定义必须引用该 secret。secret可确保 URL 的唯一性，防止他人触发构建。键的值将与 Webhook 调用期间提供的 secret 进行比较。

例如，此处的 GitHub Webhook 具有对名为 mysecret 的 secret 的引用：

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

该 secret 的定义如下。注意 secret 的值采用 base64 编码，如 Secret 对象的 data 字段所要求。

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

$ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

$ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

$ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

$ curl -X POST -k https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

git:
  uri: "<url to git repository>"
  ref: "<optional git reference>"
  commit: "<commit hash identifying a specific git commit>"
  author:
    name: "<author name>"
    email: "<author e-mail>"
  committer:
    name: "<committer name>"
    email: "<committer e-mail>"
  message: "<commit message>"
env: 1
   - name: "<variable name>"
     value: "<variable value>"

$ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

$ oc describe bc <name>

通过镜像更改触发器，您可以在上游镜像有新版本可用时自动调用构建。例如，如果构建以 RHEL 镜像为基础，那么您可以触发该构建在 RHEL 镜像更改时运行。因此，应用程序镜像始终在最新的 RHEL 基础镜像上运行。

配置镜像更改触发器需要以下操作：

将镜像更改触发器用于策略镜像流时，生成的构建会获得一个不可变 docker 标签，指向与该标签对应的最新镜像。在执行构建时，策略将使用此新镜像引用。

对于不引用策略镜像流的其他镜像更改触发器，系统会启动新构建，但不会使用唯一镜像引用来更新构建策略。

在上例中，如果策略有镜像更改触发器，生成的构建将是：

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

这将确保触发的构建使用刚才推送到存储库的新镜像，并且可以使用相同的输入随时重新运行构建。

您可以暂停镜像更改触发器，以便在构建开始之前对引用的镜像流进行多次更改。在将 ImageChangeTrigger 添加到 BuildConfig 时，您也可以将 paused 属性设为 true，以避免立即触发构建。

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

除了设置适用于所有 Strategy 类型的镜像字段外，自定义构建还需要检查 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE 环境变量。如果不存在，则使用不可变镜像引用来创建它。如果存在，则使用不可变镜像引用进行更新。

如果因为 Webhook 触发器或手动请求而触发构建，则创建的构建将使用从 Strategy 引用的 ImageStream 解析而来的 <immutableid>。这将确保使用一致的镜像标签来执行构建，以方便再生。

通过配置更改触发器，您可以在创建新 BuildConfig 时立即自动调用构建。如下是 BuildConfig 中的示例触发器定义 YAML：

  type: "ConfigChange"

$ oc set triggers bc <name> --from-github

$ oc set triggers bc <name> --from-image='<image>'

$ oc set triggers bc <name> --from-bitbucket --remove

通过构建 hook，可以将行为注入到构建过程中。

BuildConfig 对象的 postCommit 字段在运行构建输出镜像的临时容器内执行命令。Hook 的执行时间是紧接在提交镜像的最后一层后，并且在镜像推送到 registry 之前。

当前工作目录设置为镜像的 WORKDIR，即容器镜像的默认工作目录。对于大多数镜像，这是源代码所处的位置。

如果脚本或命令返回非零退出代码，或者启动临时容器失败，则 hook 将失败。当 hook 失败时，它会将构建标记为失败，并且镜像也不会推送到 registry。可以通过查看构建日志来检查失败的原因。

构建 hook 可用于运行单元测试，以在构建标记为完成并在 registry 中提供镜像之前验证镜像。如果所有测试都通过并且测试运行器返回退出代码 0，则构建标记为成功。如果有任何测试失败，则构建标记为失败。在所有情况下，构建日志将包含测试运行器的输出，这可用于识别失败的测试。

postCommit hook 不仅限于运行测试，也可用于运行其他命令。由于它在临时容器内运行，因此 hook 所做的更改不会持久存在；也就是说，hook 执行无法对最终镜像造成影响。除了其他用途外，也可借助此行为来安装和使用会自动丢弃并且不出现在最终镜像中的测试依赖项。

配置提交后构建 hook 的方法有多种。以下示例中所有形式具有同等作用，也都执行 bundle exec rake test --verbose：

$ oc set build-hook bc/mybc \
    --post-commit \
    --command \
    -- bundle exec rake test --verbose

$ oc set build-hook bc/mybc --post-commit --script="bundle exec rake test --verbose"

构建运行策略描述从构建配置创建的构建应运行的顺序。这可以通过更改 Build 规格的 spec 部分中的 runPolicy 字段的值来完成。

也可以更改现有构建配置的 runPolicy 值。

将 runPolicy 字段设置为 Serial 将会导致从 Build 配置创建的所有新构建按顺序运行。这意味着每次只有一个构建运行，每次新构建将等候到上一构建完成。使用此策略将导致一致且可预测的构建输出。这是默认的 runPolicy。

使用 Serial 策略从 sample-build 配置触发三个构建将导致：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git           New
sample-build-3   Source    Git           New

当 sample-build-1 构建完成时，sample-build-2 构建将运行：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Completed 43 seconds ago   34s
sample-build-2   Source    Git@1aa381b   Running   2 seconds ago    2s
sample-build-3   Source    Git           New

将 runPolicy 字段设置为 SerialLatestOnly 将使 Build 配置创建的所有新构建都按顺序运行，这与使用 Serial run 策略相同。区别在于，当当前运行的构建完成时，将运行的下一个构建是最新构建。换句话说，您不会等待排队的构建运行，因为跳过它们。跳过的构建标记为 Cancelled。此策略可用于快速迭代开发。

使用 SerialLatestOnly 策略从 sample-build 配置触发三个构建将导致：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git           Cancelled
sample-build-3   Source    Git           New

sample-build-2 构建将被取消(skipped)，在 sample-build-1 完成后运行的下一个构建将是 sample-build-3 构建：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Completed 43 seconds ago   34s
sample-build-2   Source    Git           Cancelled
sample-build-3   Source    Git@1aa381b   Running   2 seconds ago    2s

将 runPolicy 字段设置为 Parallel 会导致从 Build 配置创建的所有新构建并行运行。这可以产生无法预计的结果，因为第一次创建的构建可以最后完成，这会替换之前由最后一个构建生成的推送容器镜像。

在您不关心构建完成的顺序时，请使用并行 run 策略。

使用 Parallel 策略从 sample-build 配置触发三个构建将导致三个同时构建：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git@a76d881   Running   15 seconds ago   3s
sample-build-3   Source    Git@689d111   Running   17 seconds ago   3s

无法保证完成顺序：

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git@a76d881   Running   15 seconds ago   3s
sample-build-3   Source    Git@689d111   Completed 17 seconds ago   5s

默认情况下，构建由 Pod 使用未绑定的资源（如内存和 CPU）来完成。通过在项目的默认容器限值中指定资源限值来限制这些资源。

您还可以在构建配置中指定资源限值来限制资源使用。在以下示例中，每个 resources、cpu 和 memory 参数都是可选的。

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m" 1
      memory: "256Mi" 2

但是，如果您的项目定义了 配额，则需要以下两项之一：

否则，构建 Pod 创建将失败，说明无法满足配额要求。

定义 BuildConfig 时，您可以通过设置 completionDeadlineSeconds 字段来定义其最长持续时间。以秒为单位指定，默认情况下不设置。若未设置，则不强制执行最长持续时间。

最长持续时间从构建 Pod 调度到系统中的时间开始计算，并且定义它在多久时间内处于活跃状态，这包括拉取构建器镜像所需的时间。达到指定的超时后，OpenShift Container Platform 将终止构建。

下例显示了 BuildConfig 的部分内容，它指定了值为 30 分钟的 completionDeadlineSeconds 字段：

spec:
  completionDeadlineSeconds: 1800

通过在构建配置的 nodeSelector 字段中指定标签，可以将构建定位到在特定节点上运行。nodeSelector 值是一组键/值对，在调度构建 Pod 时与 node 标签匹配。

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:1
    key1: value1
    key2: value2

nodeSelector 值也可以由集群范围的默认值和覆盖值控制。只有构建配置没有为 nodeSelector 定义任何键/值对，也没有为 nodeSelector:{} 定义显式的空映射值，才会应用默认值。覆盖值将逐个键地替换构建配置中的值。

如需更多信息，请参阅配置全局构建默认值和覆盖。

对于编译语言（Go、C、C ++、Java 等），在应用程序镜像中包含编译所需的依赖项可能会增加镜像的大小，或者引入可被利用的漏洞。

为避免这些问题，可以将两个构建串联在一起：一个用于生成编译的工件，另一个将该工件放置在运行工件的独立镜像中。在以下示例中，Source-to-Image 构建与 Docker 构建相结合，以编译工件并将其置于单独的运行时镜像中。

第一个构建获取应用程序源，并生成含有 WAR 文件的镜像。镜像推送到 artifact-image 镜像流。输出工件的路径将取决于所用 Source-to-Image 构建器的 assemble 脚本。在本例中，它将输出到 /wildfly/standalone/deployments/ROOT.war。

apiVersion: v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
    type: Git
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift
    type: Source

第二个构建使用带有指向第一个构建中输出镜像内的 WAR 文件的路径的镜像源。内联 Dockerfile 将该 WAR 文件复制到运行时镜像中。

apiVersion: v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    type: Dockerfile
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from: 1
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 2
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 3
        kind: ImageStreamTag
        name: jee-runtime:latest
    type: Docker
  triggers:
  - imageChange: {}
    type: ImageChange

此设置的结果是，第二个构建的输出镜像不需要包含创建 WAR 文件所需的任何构建工具。此外，由于第二个构建包含镜像更改触发器，因此每当运行第一个构建并生成含有二进制工件的新镜像时，将自动触发第二个构建，以生成包含该工件的运行时镜像。所以，两个构建表现为一个具有两个阶段的构建。

默认情况下，生命周期已结束的构建将无限期保留。您可以通过为 successfulBuildsHistoryLimit 或 failedBuildsHistoryLimit 提供正整数值来限制保留的旧构建数量，如以下示例构建配置中所示。

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 1
  failedBuildsHistoryLimit: 2 2

构建修剪由以下操作触发：

构建按其创建时间戳排序，首先修剪最旧的构建。

OpenShift Container Platform 部署提供对常见用户应用程序的精细管理。它们使用三个独立的 API 对象进行描述：

在创建部署配置时，会创建一个复制控制器来代表部署配置的 pod 模板。如果部署配置更改，则使用最新的 pod 模板创建一个新的复制控制器，并运行部署过程来缩减旧复制控制器并扩展新的复制控制器。

在创建时，自动从服务负载均衡器和路由器中添加和移除应用程序的实例。只要您的应用程序支持收到 TERM 信号时 安全关闭，您可以确保运行的用户连接能够正常完成。

部署系统提供的功能：

部署配置是 deploymentConfig OpenShift Container Platform API 资源，可以像任何其他资源一样通过 oc 命令进行管理。以下是 deploymentConfig 资源的示例：

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "frontend"
spec:
  template: 1
    metadata:
      labels:
        name: "frontend"
    spec:
      containers:
        - name: "helloworld"
          image: "openshift/origin-ruby-sample"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 5 2
  triggers:
    - type: "ConfigChange" 3
    - type: "ImageChange" 4
      imageChangeParams:
        automatic: true
        containerNames:
          - "helloworld"
        from:
          kind: "ImageStreamTag"
          name: "origin-ruby-sample:latest"
  strategy: 5
    type: "Rolling"
  paused: false 6
  revisionHistoryLimit: 2 7
  minReadySeconds: 0 8

您可以使用 Web 控制台或 CLI 手动启动新的部署过程：

$ oc rollout latest dc/<name>

要获取有关应用程序所有可用修订的基本信息：

$ oc rollout history dc/<name>

这将显示有关所有最近为提供的部署配置创建的复制控制器的详细信息，包括任何当前运行的部署过程。

您可以使用 --revision 标志查看特定于修订版本的详情：

$ oc rollout history dc/<name> --revision=1

如需有关部署配置和最新修订的详细信息：

$ oc describe dc <name>

如果部署配置的当前修订无法部署，您可以使用以下方法重启部署过程：

$ oc rollout retry dc/<name>

如果成功部署了最新的修订，命令会显示一条消息，且不会重试部署过程。

回滚将应用恢复到上一修订，可通过 REST API、命令行或 Web 控制台进行。

回滚到配置的最近一次部署成功的修订：

$ oc rollout undo dc/<name>

将恢复部署配置的模板以匹配 undo 命令中指定的部署修订，并且会启动新的复制控制器。如果没有通过 --to-revision 指定修订，则使用上一次成功部署的版本。

在回滚过程中，部署配置的镜像更改触发器会被禁用，以防止在回滚完成不久后意外启动新的部署过程。重新启用镜像更改触发器：

$ oc set triggers dc/<name> --auto

您可以为容器添加命令，用来覆盖决镜像的 ENTRYPOINT 设置来改变容器的启动行为。这与生命周期 hook 不同，后者在每个部署的指定时间点上运行一次。

在部署配置的 spec 字段中添加 command 参数。您也可以添加 args 字段来修改 command（如果 command 不存在，则修改 ENTRYPOINT）。

...
spec:
  containers:
    -
    name: <container_name>
    image: 'image'
    command:
      - '<command>'
    args:
      - '<argument_1>'
      - '<argument_2>'
      - '<argument_3>'
...

例如，使用 -jar 和 /opt/app-root/springboots2idemo.jar 参数执行 java 命令：

...
spec:
  containers:
    -
    name: example-spring-boot
    image: 'image'
    command:
      - java
    args:
      - '-jar'
      - /opt/app-root/springboots2idemo.jar
...

输出给定部署配置的最新修订的日志：

$ oc logs -f dc/<name>

如果最新的修订正在运行或失败，oc logs 将返回负责部署 pod 的进程的日志。如果成功，oc logs 会从应用程序的 pod 返回日志。

您还可以查看来自旧的失败部署进程的日志，只要存在这些进程（旧的复制控制器及其部署器 pod）并且没有手动清理或删除：

$ oc logs --version=1 dc/<name>

有关获取日志的更多选项，请参阅：

$ oc logs --help

部署配置可以包含触发器，推动创建新部署过程以响应集群内的事件。

triggers:
  - type: "ConfigChange"

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

$ oc set triggers dc/frontend --from-image=myproject/origin-ruby-sample:latest -c helloworld

$ oc set triggers --help

部署由部署 Pod 完成。默认情况下，部署 pod 会在调度它的计算节点上消耗无限的节点资源。在大多数情况下，未绑定资源消耗不会导致问题，因为部署 pod 会消耗较低资源，并在短时间内运行。如果项目指定了默认容器限值，则部署 Pod 使用的资源以及其他 pod 数（针对这些限制）。

您可以通过在部署配置中通过部署策略限制部署 Pod 使用的资源。部署 pod 的资源限制可与 Recreate、Rolling 或 Custom 部署策略一起使用。

在以下示例中，resources、cpu、memory 和 ephemeral-storage 中每一个都是可选的：

type: "Recreate"
resources:
  limits:
    cpu: "100m" 1
    memory: "256Mi" 2
    ephemeral-storage: "1Gi" 3

不过，如果您的项目定义了配额，则需要以下两项之一：

否则，部署 pod 创建将失败，显示无法满足配额要求。

除了回滚外，您还可以对 Web 控制台中的副本数量进行精细控制，或者使用 oc scale 命令进行精细的控制。例如，以下命令将部署配置 frontend 中的副本设置为 3。

$ oc scale dc frontend --replicas=3

副本数量最终会传播到部署配置 frontend 配置的部署的预期和当前状态。

您可以结合使用节点选择器和带标签的节点来控制 pod 的放置。

集群管理员可为项目设置默认节点选择器，以便将 pod 放置限制到特定的节点。作为 OpenShift Container Platform 开发人员，您可以设置 pod 配置的节点选择器来进一步限制节点。

要在创建 pod 时添加节点选择器，请编辑 pod 配置并添加 nodeSelector 值。这可添加到单个 pod 配置中，也可以添加到 pod 模板中：

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    disktype: ssd
...

具有节点选择器时创建的 Pod 会分配给带有指定标签的节点。

这里指定的标签将与集群管理员添加的标签结合使用。

例如，如果项目中包含由集群管理员添加的 type=user-node 和 region=east 标签，并且您将上述 disktype: ssd 标签添加到某一 pod，则 pod 只会调度到具有所有这三个标签的节点上。

您可以使用非默认服务帐户运行 pod：

将 secret 添加到部署配置中，以便它可以访问私有存储库。

部署策略是更改或升级应用程序的方法。其目的是在无需停机的前提下进行修改，从而使用户几乎不会注意到这些变化。

最常见的 策略是使用蓝绿部署。新版本（蓝色版本）上线进行测试和评估，同时用户仍然使用稳定版本（绿色版本）。准备就绪后，用户切换到蓝色版本。如果出现问题，您可以切回到绿色版本。

常见的替代策略是使用同时活跃的 A/B 版本，有些用户使用一个版本，而一些用户使用另一个版本。这可用于试验用户界面变化和其他功能，以获取用户反馈。它还可用来在影响有限用户的生产环境中验证正确的操作。

Canary 部署会测试新版本，但在检测到问题时，迅速回退到上一版本。这可以通过以上两个策略实现。

基于路由的部署策略不会缩放服务中的 pod 数量。为了保持所需的性能特性，部署配置可能需要扩展。

选择部署策略时需要考虑一些事项。