快速入门是 OpenShift Container Platform 上运行的应用程序的基本示例。Quickstarts 提供多种语言和框架，并在模板中定义， 模板 由一组服务、构建配置和部署配置组成。该模板引用了构建和部署应用程序所需的镜像和源存储库。 要探索快速入门，请从模板创建应用程序。您的管理员可能已在您的 OpenShift Container Platform 集群中安装了这些模板，在这种情况下，您只需从 web 控制台中选择即可。有关如何上传、从中创建和修改 模板 的更多信息，请参阅模板文档。 Quickstarts 是指包含应用程序源代码的源存储库。要自定义 Quickstart，请分叉存储库，并在从模板创建应用程序时，用分叉的存储库替换默认的源存储库名称。这将导致使用您的源代码而非所提供的示例源来执行构建。然后，您可以更新源存储库中的代码，并启动新的构建来查看反映在所部署的应用程序中的更改。

这些快速入门提供了指定框架和语言的基本应用程序： Cakephp：PHP web 框架（包括 MySQL 数据库） Dancer：Perl web 框架（包括 MySQL 数据库） Django：Python web 框架（包括 PostgreSQL 数据库） NodeJS：NodeJS web 应用程序（包括 MongoDB 数据库） Rails：Ruby web 框架（包括 PostgreSQL 数据库）

Ruby on Rails 是使用 Ruby 编写的流行 web 框架。本指南介绍在 OpenShift Container Platform 上使用 Rails 4。 我们强烈建议您完成整个教程，以概述在 OpenShift Container Platform 上运行应用程序所需的所有步骤。如果遇到问题，请尝试通读整个教程，然后再回看问题。该教程还可用于审查您之前采取的步骤，以确保正确执行了所有步骤。 对于本指南，您需要： 基本 Ruby/Rails 知识 本地安装的 Ruby 2.0.0+ 版本、Rubygems、Bundler 基本的 Git 知识 运行 OpenShift Container Platform v3 实例

首先，确保 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
config
config.ru
Gemfile
Gemfile.lock
public
Rakefile
README.rdoc
vendor

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

$ git remote add origin [email protected]:<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 中部署应用程序涉及三个步骤： 从 OpenShift Container Platform 的 PostgreSQL 镜像 创建数据库 服务 。 从 OpenShift Container Platform 的 Ruby 2.0 构建器镜像 和用来与数据库服务进行连接的 Ruby on Rails 源代码创建一个前端 service 为应用程序创建路由。

$ 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

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

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

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

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

$ 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
							要使用的模板的路径。
							要创建的模板的名称。
							启动 node.js slave Pod，以运行此构建。
							为此管道设置 20 分钟超时。
							使用此模板标签删除所有内容。
							使用此模板标签删除任何 secret。
							从 templatePath 创建一个新应用程序。
							等待最多五分钟以完成构建。
							等待最多五分钟以完成部署。
							如果其余部分都成功，则将 $ {templateName}:latest 镜像标记为 $ {templateName}-staging:latest。staging 环境的管道 BuildConfig 可以监控 $ {templateName}-staging:latest 镜像更改，然后将其部署到 stage 环境中。
						上例使用 declarative pipeline 风格编写，但较旧的 scripted pipeline 风格也受到支持。
					

您可以通过运行以下命令，在 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 同步插件监控开发人员在其中工作的一组项目。以下小节概述了完成此过程的步骤。 要禁用 Jenkins auto=provisioning，请参阅 配置管道执行 。 要使 Jenkins 服务帐户能够访问要运行 OpenShift Pipelines 的每个项目，请参阅 跨项目访问 。 要添加项目来监控，请执行以下任一操作： 登录 Jenkins 控制台。 导航到 Manage Jenkins ，再单击 配置系统 。 更新 OpenShift Jenkins Sync 下的 Namespace 字段。 使用 S2I 扩展名选项或扩展 OpenShift Jenkins 镜像，以更新 Jenkins 配置文件。 避免从运行 OpenShift 同步插件的多个 Jenkins 部署中监控同一项目。这些实例之间没有协调，可能会发生不可预测的结果。

OpenShift 中的二进制构建功能使开发人员能够将源或工件直接上传到构建中，而不是从 Git 存储库 URL 中拉取源。任何带有 source、Docker 或 custom 的 BuildConfig 都可以作为二进制构建启动。从本地工件启动构建时，现有源引用将被替换为来自本地用户机器的源。 源可以通过几种方法提供，它们对应于使用 start-build 命令时可用的参数： 来自一个文件( --from-file )：构建整个源都由一个文件组成，就会出现这种情况。例如，它可能是用于 Wildfly 构建的 Docker 构建、 pom.xml 的 Dockerfile ，或用于 Ruby 构建的 Gemfile 。 来自一个目录( --directory )：当源位于本地目录且未提交到 Git 存储库时，请使用此选项。 start-build 命令将创建给定目录的存档，并将它上传到构建器，作为来源。 来自存档( --from-archive ）：当存档和源已存在时，请使用此选项。归档可以是 tar 、 tar.gz 或 zip 格式。 来自 Git 存储库( --from-repo )：这是用于当前用户本地计算机上的 Git 存储库一部分的源。当前存储库的 HEAD 提交将存档，并发送到 OpenShift 以进行构建。

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

$ mkdir mavenapp
$ cd mavenapp

FROM wildfly:latest
COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
CMD  $STI_SCRIPTS_PATH/run

$ cat Dockerfile | oc new-build -D - --name mavenapp

apiVersion: v1
kind: BuildConfig
metadata:
  name: mavenapp-pipeline
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        pipeline {
          agent { label "maven" }
          stages {
            stage("Clone Source") {
              steps {
                checkout([$class: 'GitSCM',
                            branches: [[name: '*/master']],
                            extensions: [
                              [$class: 'RelativeTargetDirectory', relativeTargetDir: 'mavenapp']
                            userRemoteConfigs: [[url: 'https://github.com/openshift/openshift-jee-sample.git']]
            stage("Build WAR") {
              steps {
                dir('mavenapp') {
                  sh 'mvn clean package -Popenshift'
            stage("Build Image") {
              steps {
                dir('mavenapp/target') {
                  sh 'oc start-build mavenapp --from-dir . --follow'
    type: JenkinsPipeline
  triggers: []

$ oc create -f ./mavenapp-pipeline.yml

$ oc start-build mavenapp-pipeline

$ oc new-app mavenapp
$ oc expose svc/mavenapp

$ oc get route mavenapp

OpenShift Container Platform 中的 构建 是将输入参数转换为结果对象的过程。大多数情况下，构建用于将源代码转换为可运行的容器镜像。 构建配置 或 BuildConfig 的特征就是 构建策略 和一个或多个源。策略决定上述过程，而源则提供输入。 构建策略有： Source-to-Image (S2I) ( description , options ) Pipeline ( description , options ) Docker ( description , options ) Custom ( description , options ) 有六种类型的源作为 构建输入 提供 ： Docker Image 输入 secret 外部工件 (artifact) 每个构建策略最多可考虑或忽略特定类型的源，并确定要使用方法。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
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 5
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 6
      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 命令指定以下选项之一来完成：

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

$ oc cancel-build <build_name>

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

$ oc cancel-build bc/<buildconfig_name>

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

$ oc delete bc <BuildConfigName>

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

$ oc describe build <build_name>

$ oc logs -f build/<build_name>

$ oc logs -f bc/<buildconfig_name>

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

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

构建输入 提供构建操作的源内容。在 OpenShift Container Platform 中，可以通过几种方法提供源。顺序排列： 内联 Dockerfile 定义 从现有镜像中提取内容 Git 存储库 二进制（本地）输入 输入 secret 和 ConfigMap 外部工件 (artifact) 不同的输入可以合并为一个构建。由于内联 Dockerfile 具有优先权，它可覆盖由另一个输入提供的名为 Dockerfile 的任何其他文件。二进制（本地）和 Git 存储库是互斥的输入。 当您不希望在构建生成的最终应用程序镜像中提供构建期间使用的某些资源或凭证，或者想要消耗在 Secret 资源中定义的值时，输入 secret 很有用。外部工件可用于拉取不以其他任一构建输入类型提供的额外文件。 每当运行构建时： 构造工作目录，并将所有输入内容放进工作目录中。例如，把输入 Git 存储库克隆到工作目录中，并且把由输入镜像指定的文件通过目标目录复制到工作目录中。 构建过程将目录更改到 contextDir （若已指定）。 内联 Dockerfile（若有）写入当前目录中。 当前目录中的内容提供给构建过程，供 Dockerfile、自定义构建器逻辑或 assemble 脚本引用。这意味着，构建将忽略所有驻留在 contextDir 之外的输入内容。 以下源定义示例包括多种输入类型，以及它们如何组合的说明。如需有关如何定义各种输入类型的更多详细信息，请参阅每种输入类型的具体小节。

source:
    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:
    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

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

集群管理员也可使用 Ansible 为 Git 克隆配置全局代理 。 对于 Pipeline 策略构建，因为 Jenkins Git 插件当前限制的缘故，通过 Git 插件执行的任何 Git 操作都不会利用 BuildConfig 中定义的 HTTP 或 HTTPS 代理。Git 插件将仅使用 Plugin Manager 面板上 Jenkins UI 中配置的代理。然后，在所有任务中，此代理都会被用于 Jenkins 内部与 git 的所有交互。您可以在 JenkinsBehindProxy 上找到有关如何通过 Jenkins UI 配置代理的说明。

构建器 pod 需要访问定义为构建源的任何 Git 存储库。源克隆 secret 为构建器 pod 提供了通常无权访问的资源的访问权限，例如私有存储库或具有自签名或不可信 SSL 证书的存储库。 支持以下源克隆 secret 配置。 .gitconfig 文件 基本身份验证 SSH 密钥身份验证 可信证书颁发机构 您还可以 组合使用 这些配置来满足特定的需求。 使用 builder 服务帐户运行构建，该帐户必须能够访问所使用的任何源克隆 secret。使用以下命令授予访问权限：

$ 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:
							使用以下命令将 build.openshift.io/source-secret-match-uri- 注解添加到预先存在的 secret：
						
$ 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:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
      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

# cat .gitconfig
[user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

$ oc create secret generic <secret_name> \
--from-literal=username=<user_name> \ 1
--from-literal=password=<password> \ 2
--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key

$ 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 "[email protected]"

$ 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

$ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt

$ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1

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

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

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

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

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca.crt=</path/to/file> \
    --type=kubernetes.io/basic-auth

将输入 secret 和/或 ConfigMap 添加到现有的 BuildConfig 中： 如果 ConfigMap 不存在，则进行创建：

$ oc create configmap settings-mvn \
    --from-file=settings.xml=<path/to/settings.xml>

这会创建一个名为 settings-mvn 的新 ConfigMap，其包含 settings.xml 文件的纯文本内容。 如果 secret 不存在，则进行创建：

$ oc create secret generic secret-mvn \
    --from-file=id_rsa=<path/to/.ssh/id_rsa>

这会创建一个名为 secret-mvn 的新 secret，其包含 id_rsa 私钥的 base64 编码内容。 将 ConfigMap 和 secret 添加到现有 BuildConfig 的 source 部分中：

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

要在新 BuildConfig 中包含 secret 和 ConfigMap，请运行以下命令：

$ 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"

在构建期间， settings.xml 和 id_rsa 文件将复制到源代码所在的目录中。在 OpenShift Container Platform S2I 构建器镜像中，这是镜像的工作目录，使用 Dockerfile 中的 WORKDIR 指令设置。如果要指定其他目录，请在定义中添加 destinationDir ：

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

您还可以指定创建新 BuildConfig 时的目标目录：

$ 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"

在这两种情况下， settings.xml 文件都添加到构建环境的 ./.m2 目录中，而 id_rsa 密钥则添加到 ./.ssh 目录中。请注意，对于 Docker 策略 ，目标目录必须是相对路径。

采用 Source 策略时，所有定义的输入 secret 都复制到对应的 destinationDir 中。如果 destinationDir 留空，则 secret 会放置到构建器镜像的工作目录中。 destinationDir 是相对路径时采用相同的规则；secret 将放置到相对于镜像工作目录的路径中。如果构建器镜像中不存在 destinationDir 路径中的最终目录，则会创建该目录。 destinationDir 中的所有上述目录都必须存在，否则会发生错误。 输入 secret 将以全局可写（具有 0666 权限）形式添加，并且在执行 assemble 脚本后其大小会被截断为零。也就是说，生成的镜像中会包括这些 secret 文件，但出于安全原因，它们将为空。 assemble 脚本完成后不会截断输入 ConfigMap。

采用 Docker 策略时，您可以使用 Dockerfile 中的 ADD 和 COPY 指令 ，将所有定义的输入 secret 添加到容器镜像中。 如果没有为 secret 指定 destinationDir ，则文件将复制到 Dockerfile 所在的同一目录中。如果将一个相对路径指定为 destinationDir ，则 secret 将复制到相对于 Dockerfile 所在位置的这个目录中。这样，secret 文件可供 Docker 构建操作使用，作为构建期间使用的上下文目录的一部分。

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

使用 Custom 策略时，所有定义的输入 secret 和 ConfigMap 都位于 /var/run/secrets/openshift.io/build 目录下的构建器容器内。自定义构建镜像负责适当地使用这些 secret 和 ConfigMap。 Custom 策略还允许按照 Custom 策略选项 中所述定义 secret。 现有策略 secret 与输入 secret 之间没有技术差异。但是，构建器镜像可以区分它们并以不同的方式加以使用，具体取决于您的构建用例。 输入 secret 始终挂载到 /var/run/secrets/openshift.io/build 目录中，或您的构建器可以解析 $BUILD 环境变量（包含完整构建对象）。