diff --git a/architecture/core_objects/builds.adoc b/architecture/core_objects/builds.adoc index e1aaa23581f4..adc82fa3faae 100644 --- a/architecture/core_objects/builds.adoc +++ b/architecture/core_objects/builds.adoc @@ -15,75 +15,12 @@ A build is the end result of transforming input parameters, typically source cod For a list of build commands, see the link:../../dev_guide/builds.html[Developer's Guide]. -== BuildConfig -The `BuildConfig` object is the definition of the entire build process, and is dictated by link:../../dev_guide/builds.html#build-triggers[build triggers]: - -==== ----- -apiVersion: v1beta3 -kind: BuildConfig -metadata: - labels: - name: ruby-sample-build - template: application-template-stibuild - name: ruby-sample-build - namespace: ruby - resourceVersion: "7246" - selfLink: /osapi/v1beta3/namespaces/ruby/buildconfigs/ruby-sample-build - uid: 9c3d9693-0822-11e5-9deb-080027c5bfa9 -spec: - output: <1> - to: - kind: ImageStreamTag - name: origin-ruby-sample:latest - resources: {} <2> - source: <3> - git: - uri: git://github.com/openshift/ruby-hello-world.git - type: Git - strategy: <4> - sourceStrategy: - from: - kind: ImageStreamTag - name: ruby-20-centos7:latest - incremental: true - type: Source - triggers: - - github: <5> - secret: secret101 - type: github - - generic: <6> - secret: secret101 - type: generic - - imageChange: <7> - lastTriggeredImageID: openshift/ruby-20-centos7:latest - type: imageChange - ----- -<1> *output* describes the resulting ImageStream source to which the -image should be pushed. -<2> *resources* describes the resource limits (cpu, memory) that should be used -by pods that run a build. -<3> *source* describes the SCM used to locate the sources. Currently only -supports Git. -<4> *strategy* describes which build type is invoked along with build type -specific details. -<5> *gitHub* triggers are Github-specific webhooks that specify which repository -changes, such as a new commit, should invoke a new build. This trigger is -specific to the GitHub API. -<6> *generic* triggers are similar to GitHub webhooks in that they invoke a new -build when notified, but different in that the payload is slightly different -than GitHub's. -<7> *imageChange* triggers define a trigger which is invoked upon availability -of a new image in the specified ImageStream. -==== - == Build Strategies There are three available link:openshift_model.html#build-strategies[build strategies]: * link:#docker-build[Docker build] -* link:#sti-build[STI build] +* link:#source-build[Source-to-Image build] * link:#custom-build[Custom build] The resulting object depends on the builder used to create the image. @@ -92,31 +29,31 @@ The resulting object depends on the builder used to create the image. === Docker Build Docker builds invoke the plain https://docs.docker.com/reference/commandline/cli/#build[docker build command], and therefore expect a repository with a *_Dockerfile_* and all required directories. -[#sti-build] -=== STI Build -link:../../creating_images/sti.html[Source-to-image (STI)] is a tool for +[#source-build] +=== Source-to-Image Build +link:../../creating_images/sti.html[Source-to-Image (S2I)] is a tool for building reproducible Docker images. It produces ready-to-run images by injecting a user source into a docker image and assembling a new docker image. The new image incorporates the base image and built source, and is ready to use -with the `docker run` command. STI supports incremental builds, which re-use +with the `docker run` command. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts, etc. -The advantages of STI include: +The advantages of S2I include: [horizontal] -Image flexibility:: STI scripts can be written to layer application code onto +Image flexibility:: S2I scripts can be written to layer application code onto almost any existing Docker image, taking advantage of the existing ecosystem. -Note that, currently, STI relies on `tar` to inject application +Note that, currently, S2I relies on `tar` to inject application source, so the image needs to be able to process tarred content. -Speed:: With STI, the assemble process can perform a large number of complex +Speed:: With S2I, the assemble process can perform a large number of complex operations without creating a new layer at each step, resulting in a fast -process. In addition, STI scripts can be written to re-use artifacts stored in a +process. In addition, S2I scripts can be written to re-use artifacts stored in a previous version of the application image rather than having to download or build them each time the build is run. -Patchability:: STI allows you to rebuild the application consistently if an -underlying image needs a patch due to a security issue +Patchability:: S2I allows you to rebuild the application consistently if an +underlying image needs a patch due to a security issue. Operational efficiency:: By restricting build operations instead of allowing arbitrary actions, such as in a *_Dockerfile_*, the PaaS operator can avoid @@ -125,14 +62,14 @@ accidental or intentional abuses of the build system. Operational security:: Building an arbitrary *_Dockerfile_* exposes the host system to root privilege escalation. This can be exploited by a malicious user because the entire docker build process is run as a user with docker privileges. -STI restricts the operations performed as a root user, and can run the scripts -as an individual user. +S2I restricts the operations performed as a root user, and can run the scripts +as an non-root user. -User efficiency:: STI prevents developers from performing arbitrary `yum +User efficiency:: S2I prevents developers from performing arbitrary `yum install` type operations during their application build, which results in slow development iteration. -Ecosystem:: STI encourages a shared ecosystem of images where you can leverage +Ecosystem:: S2I encourages a shared ecosystem of images where you can leverage best practices for your applications. [#custom-build] @@ -141,203 +78,3 @@ Custom builds allow developers to define the specific builder image responsible for the entire build process. The custom builder image is a plain Docker image with embedded build process logic, such as building RPMs or building base Docker images. - -[#using-docker-credentials-for-pushing-and-pulling-images] -== Using Docker Credentials for Pushing and Pulling Images - -Supply the `.dockercfg` file with valid Docker Registry credentials in order to push the output image into a private Docker Registry or pull the -builder image from the private Docker Registry that requires authentication. -For the OpenShift Docker Registry, you don't have to do this because the Secrets -are generated automatically for you by OpenShift. - -The *_.dockercfg_* JSON file exists in your home directory by default and has -following format: - -==== - ----- -{ - "https://index.docker.io/v1/": { <1> - "auth": "YWRfbGzhcGU6R2labnRib21ifTE=", <2> - "email": "user@example.com" <3> - } -} ----- - -<1> URL of the registry. -<2> Encrypted password. -<3> Email address for the login. -==== - -You can define multiple Docker registry entries in this file. Alternatively, you -can also add authentication entries to this file by running the `docker login` -command. The file will be created if it does not exist. - -Kubernetes provides the https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret] -resource, which is used to store your configuration and passwords. - -To create the `*Secret*` resource from your local `.dockercfg` file, you can run -following command: - -==== ----- -$ openshift ex bundle-secret dockerhub ~/.dockercfg | oc create -f - ----- -==== - -This command generates JSON specification of the Secret resource named -'dockerhub'. Then this resource is passed to the standard input of `*oc create*` -command. - -Once you have the `*Secret*` created, you can add a `PushSecret` field into the -`Output` section of the `BuildConfig` and set it to the name of the `*Secret*` -that you created, which in the above example is `*dockerhub*`: - -==== ----- -"parameters": { - "output": { - "to": { - "name": "private-image" - }, - "pushSecret":{ - "name":"dockerhub" - } - } -} ----- -==== - -Pull the builder Docker image from a private Docker registry by specifying the -`PullSecret` field, which is part of the build strategy definition: - -==== ----- -{ - "strategy": { - "sourceStrategy": { - "from": { - "kind": "DockerImage", - "name": "docker.io/user/private_repository" - }, - "pullSecret": { - "name": "dockerhub" - }, - }, - "type": "Source" - } -} ----- -==== - -[#using-private-repositories-for-builds] -== Using Private Repositories for Builds - -Supply valid credentials to build an application from a private repository. -Currently, only SSH key based authentication is supported. The repository keys -are located in the `$HOME/.ssh/` directory, and are named `id_dsa.pub`, -`id_ecdsa.pub`, `id_ed25519.pub` or `id_rsa.pub` by default. Generate SSH key -credentials with the following command: - -==== - ----- -$ ssh-keygen -t rsa -C "your_email@example.com" ----- -==== - -Two files will be created: the public key (as explained above) and a -corresponding private key (one of `id_dsa`, `id_ecdsa`, `id_ed25519` or -`id_rsa`). With both of these in place you should consult your source control -management (SCM) system's manual on how to upload the public key. The private -key will be used to access your private repository. - -The -https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret] -resource is used to store your keys. Create the `*Secret*` first before using -the ssh key to access the private repository. The `*data*` field for the -`*Secret*` object must contain your private key with the value set to the -base64-encoded content of that file: - -==== - ----- -$ base64 -w 0 $HOME/.ssh/id_rsa -6yJodHRwc1ovL2zuZGV4LmRvY21lci5aby92MS8iOnsiYXV0aCI6ImJXWnZhblJwYXpwdVoybGxkR2d4TUE9PSIsImVtYWlsIj8ibWlAbWlmby5zayJ9fQ== ----- -==== - -Copy the value returned from the above command and place it into the -`ssh-privatekey` field in `*_secret.json_*` file: - -==== - ----- -{ - "apiVersion": "v1beta3", - "kind": "Secret", - "metadata": { - "name": "scmsecret" - }, - "data": { - "ssh-privatekey": "6yJodHRwc1ovL2zuZGV4LmRvY21lci5aby92MS8iOnsiYXV0aCI6ImJXWnZhblJwYXpwdVoybGxkR2d4TUE9PSIsImVtYWlsIj8ibWlAbWlmby5zayJ9fQ==" - } -} - ----- -==== - -Then, create the `*Secret*` from the *_secret.json_* file using the following -command: - -==== ----- -$ oc create -f secret.json ----- -==== - -Add a `SourceSecret` field into the `Source` section inside the `BuildConfig` -and set it to the name of the `*Secret*` that you created, in this case -`*scmsecret*`: - -==== - ----- -{ - "apiVersion": "v1beta3", - "kind": "BuildConfig", - "metadata": { - "name": "sample-build", - }, - "parameters": { - "output": { - "to": { - "name": "sample-image" - } - }, - "source": { - "git": { - "uri": "git@repository.com:user/app.git" - }, - "sourceSecret": { - "name": "scmsecret" - }, - "type": "Git" - }, - "strategy": { - "sourceStrategy": { - "from": { - "kind": "ImageStreamTag", - "name": "python-33-centos7:latest" - } - }, - "type": "Source" - } - } ----- -==== - -[NOTE] -==== -The URL of private repository is usually in the form `git@example.com:username/repository` -==== diff --git a/architecture/core_objects/openshift_model.adoc b/architecture/core_objects/openshift_model.adoc index cd3b18e02cb1..bba7dfc19a6e 100644 --- a/architecture/core_objects/openshift_model.adoc +++ b/architecture/core_objects/openshift_model.adoc @@ -34,7 +34,7 @@ https://docs.docker.com/reference/commandline/cli/#build[Docker build]. *Source-to-Image (STI) Build* [[source-to-image]] -link:builds.html#sti-build[STI builds] are a replacement for the OpenShift +link:builds.html#source-build[STI builds] are a replacement for the OpenShift v2-like developer experience. The developer specifies the repository where their project is located and a builder image, which defines the language and framework used for writing their application. STI then assembles a new image which runs diff --git a/creating_images/sti.adoc b/creating_images/sti.adoc index f1b7bc3151c3..3a8eb1aa9c77 100644 --- a/creating_images/sti.adoc +++ b/creating_images/sti.adoc @@ -10,7 +10,7 @@ toc::[] == Overview -link:../architecture/core_objects/builds.html#sti-build[Source-to-Image (STI)] +link:../architecture/core_objects/builds.html#source-build[Source-to-Image (STI)] is a framework that makes it easy to write images that take application source code as an input and produce a new image that runs the assembled application as output. diff --git a/dev_guide/builds.adoc b/dev_guide/builds.adoc index d6ef68bd9ebf..45b43e99404f 100644 --- a/dev_guide/builds.adoc +++ b/dev_guide/builds.adoc @@ -11,11 +11,78 @@ toc::[] == Overview A link:../architecture/core_objects/builds.html[build] is a process of creating -runnable images to be used on OpenShift. There are three types of builds: +runnable images to be used on OpenShift. There are three build strategies: -- Docker build -- STI build -- custom build +- link:../architecture/core_objects/builds.html#source-build[Source-To-Image] +- link:../architecture/core_objects/builds.html#docker-build[Docker] +- link:../architecture/core_objects/builds.html#custom-build[Custom] + +== Defining a buildConfig + +A `*buildConfig*` describes a single build definition and a +set of link:#triggers[triggers] for when a new build should be created. + +A buildConfig is a REST object, which can be used in a POST to the API server to +create a new instance. The following configuration results in a new build +every time a Docker image tag or the source code changes: + +[source.json] +---- +{ + "kind": "BuildConfig", + "apiVersion": "v1", + "metadata": { + "name": "ruby-sample-build", <1> + }, + "spec": { + "triggers": [ <2> + { + "type": "Github", + "github": { + "secret": "secret101" + } + }, + { + "type": "Generic", + "generic": { + "secret": "secret101" + } + }, + { + "type": "ImageChange" + } + ], + "source": { <3> + "type": "Git", + "git": { + "uri": "git://github.com/openshift/ruby-hello-world.git" + } + }, + "strategy": { <4> + "type": "Source", + "sourceStrategy": { + "from": { + "kind": "ImageStreamTag", + "name": "ruby-20-centos7:latest" + } + } + }, + "output": { <5> + "to": { + "kind": "ImageStreamTag", + "name": "origin-ruby-sample:latest" + } + }, + }, +} +---- + +<1> This specification will create a new buildConfig named ruby-sample-build. +<2> You can specify a list of triggers, which causes a new build to be created. +The `*ImageChange*` trigger creates a new build each time the Docker image specified in the `*strategy.from*` field changes. The `*github*` and `*generic*` triggers starts the build when a callback is made from the GitHub or other source code repository hosting service, indicating change in the source code specified in `*source*` section. +<3> The `*source*` section defines the source code repository location. You can provide additional options, such as `*sourceSecret*` or `*contextDir*` here. +<4> The `*strategy*` section describes the build strategy used to execute the build. You can specify `*Source*`, `*Docker*` and `*Custom*` strategies here. This specification uses the `*ruby-20-centos7*` Docker image that Source-To-Image will use for the application build. +<5> After the Docker image is successfully built, it will be pushed into the repository described in the `*output*` section. == Starting a Build You can manually invoke a build using the following command: @@ -50,9 +117,9 @@ To allow access to build logs, use the following command: `$ oc build-logs __` **** -*STI Build Logs* +*Source Build Logs* -link:../architecture/core_objects/builds.html#sti-build[STI builds] by default +link:../architecture/core_objects/builds.html#source-build[Source builds] by default show full output of the *_assemble_* script and all subsequent errors. To enable more verbose output, you can pass the `*BUILD_LOGLEVEL*` environment variable as part of the `*sourceStrategy*` in BuildConfig: @@ -80,7 +147,7 @@ NOTE: A platform administrator can set verbosity for the entire OpenShift instance by passing the `--loglevel` option to the `openshift start` command. If both `--loglevel` and `BUILD_LOGLEVEL` are specified, `BUILD_LOGLEVEL` takes precedence. -Available log levels for STI are as follows: +Available log levels for Source builds are as follows: [horizontal] Level 0:: Produces output from containers running the *_assemble_* script and all encountered errors. This is the default. @@ -119,20 +186,20 @@ code. If your application exists inside a sub-directory, you can override the default location (the root folder) using this field. ==== -[[configuring-the-sti-environment]] -== STI Environment +[[configuring-the-source-environment]] +== Source Environment -There are two ways to make environment variables available to the link:../architecture/core_objects/builds.html#sti-build[STI] +There are two ways to make environment variables available to the link:../architecture/core_objects/builds.html#source-build[Source] build process and resulting image, Environment files and BuildConfig environment values. === Environment files -STI enables you to set environment values +Source enables you to set environment values in your application by specifying them in a *_.sti/environment_* file in the source repository. The environment variables are then present during the build process and in the final docker image. The complete list of supported environment variables are available in the documentation for each image. -If you provide a *_.sti/environment_* file in your source repository, STI reads +If you provide a *_.sti/environment_* file in your source repository, S2I reads this file during the build. This allows customization of the build behavior as the *_assemble_* script may use these variables. @@ -354,3 +421,203 @@ If a build is triggered due to a webhook trigger or manual request, the build that is created uses the `*immutableid*` resolved from the `*ImageStream*` referenced by the `*Strategy*`. This ensures that builds are performed using consistent image tags for ease of reproduction. + +[#using-docker-credentials-for-pushing-and-pulling-images] +== Using Docker Credentials for Pushing and Pulling Images + +Supply the `.dockercfg` file with valid Docker Registry credentials in order to push the output image into a private Docker Registry or pull the +builder image from the private Docker Registry that requires authentication. +For the OpenShift Docker Registry, you don't have to do this because the Secrets +are generated automatically for you by OpenShift. + +The *_.dockercfg_* JSON file exists in your home directory by default and has +following format: + +==== + +---- +{ + "https://index.docker.io/v1/": { <1> + "auth": "YWRfbGzhcGU6R2labnRib21ifTE=", <2> + "email": "user@example.com" <3> + } +} +---- + +<1> URL of the registry. +<2> Encrypted password. +<3> Email address for the login. +==== + +You can define multiple Docker registry entries in this file. Alternatively, you +can also add authentication entries to this file by running the `docker login` +command. The file will be created if it does not exist. + +Kubernetes provides the https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret] +resource, which is used to store your configuration and passwords. + +To create the `*Secret*` resource from your local `.dockercfg` file, you can run +following command: + +==== +---- +$ openshift ex bundle-secret dockerhub ~/.dockercfg | oc create -f - +---- +==== + +This command generates JSON specification of the Secret resource named +'dockerhub'. Then this resource is passed to the standard input of `*oc create*` +command. + +Once you have the `*Secret*` created, you can add a `PushSecret` field into the +`Output` section of the `BuildConfig` and set it to the name of the `*Secret*` +that you created, which in the above example is `*dockerhub*`: + +==== +---- +"parameters": { + "output": { + "to": { + "name": "private-image" + }, + "pushSecret":{ + "name":"dockerhub" + } + } +} +---- +==== + +Pull the builder Docker image from a private Docker registry by specifying the +`PullSecret` field, which is part of the build strategy definition: + +==== +---- +{ + "strategy": { + "sourceStrategy": { + "from": { + "kind": "DockerImage", + "name": "docker.io/user/private_repository" + }, + "pullSecret": { + "name": "dockerhub" + }, + }, + "type": "Source" + } +} +---- +==== + +[#using-private-repositories-for-builds] +== Using Private Repositories for Builds + +Supply valid credentials to build an application from a private repository. +Currently, only SSH key based authentication is supported. The repository keys +are located in the `$HOME/.ssh/` directory, and are named `id_dsa.pub`, +`id_ecdsa.pub`, `id_ed25519.pub` or `id_rsa.pub` by default. Generate SSH key +credentials with the following command: + +==== + +---- +$ ssh-keygen -t rsa -C "your_email@example.com" +---- +==== + +Two files will be created: the public key (as explained above) and a +corresponding private key (one of `id_dsa`, `id_ecdsa`, `id_ed25519` or +`id_rsa`). With both of these in place you should consult your source control +management (SCM) system's manual on how to upload the public key. The private +key will be used to access your private repository. + +The +https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret] +resource is used to store your keys. Create the `*Secret*` first before using +the SSH key to access the private repository. The `*data*` field for the +`*Secret*` object must contain your private key with the value set to the +base64-encoded content of that file: + +==== + +---- +$ base64 -w 0 $HOME/.ssh/id_rsa +6yJodHRwc1ovL2zuZGV4LmRvY21lci5aby92MS8iOnsiYXV0aCI6ImJXWnZhblJwYXpwdVoybGxkR2d4TUE9PSIsImVtYWlsIj8ibWlAbWlmby5zayJ9fQ== +---- +==== + +Copy the value returned from the above command and place it into the +`ssh-privatekey` field in `*_secret.json_*` file: + +==== + +---- +{ + "apiVersion": "v1beta3", + "kind": "Secret", + "metadata": { + "name": "scmsecret" + }, + "data": { + "ssh-privatekey": "6yJodHRwc1ovL2zuZGV4LmRvY21lci5aby92MS8iOnsiYXV0aCI6ImJXWnZhblJwYXpwdVoybGxkR2d4TUE9PSIsImVtYWlsIj8ibWlAbWlmby5zayJ9fQ==" + } +} + +---- +==== + +Then, create the `*Secret*` from the *_secret.json_* file using the following +command: + +==== +---- +$ oc create -f secret.json +---- +==== + +Add a `SourceSecret` field into the `Source` section inside the `BuildConfig` +and set it to the name of the `*Secret*` that you created, in this case +`*scmsecret*`: + +==== + +---- +{ + "apiVersion": "v1", + "kind": "BuildConfig", + "metadata": { + "name": "sample-build", + }, + "parameters": { + "output": { + "to": { + "name": "sample-image" + } + }, + "source": { + "git": { + "uri": "git@repository.com:user/app.git" + }, + "sourceSecret": { + "name": "scmsecret" + }, + "type": "Git" + }, + "strategy": { + "sourceStrategy": { + "from": { + "kind": "ImageStreamTag", + "name": "python-33-centos7:latest" + } + }, + "type": "Source" + } + } +---- +==== + +[NOTE] +==== +The URL of private repository is usually in the form `git@example.com:username/repository` +==== diff --git a/using_images/sti_images/java.adoc b/using_images/sti_images/java.adoc index 9dbf4f290d06..facfba60faa7 100644 --- a/using_images/sti_images/java.adoc +++ b/using_images/sti_images/java.adoc @@ -10,7 +10,7 @@ toc::[] == Overview -OpenShift provides https://github.com/openshift/source-to-image[STI] enabled Java images for building and running Java applications. These images can be used with the link:../../architecture/core_objects/builds.html#sti-build[STI build strategy]. +OpenShift provides https://github.com/openshift/source-to-image[STI] enabled Java images for building and running Java applications. These images can be used with the link:../../architecture/core_objects/builds.html#source-build[STI build strategy]. This image is intended for use with maven based java standalone projects (that are run via main class). == Versions @@ -70,4 +70,4 @@ is considered 'target' dir inside the sources directory, but it can be overridde There are couple of options available for configuring the main class of the project: * [envvar]#JAVA_MAIN# as an env var passed to the sti or inside `.sti/environment` -* #docker.env.Main# as a maven property inside the project. \ No newline at end of file +* #docker.env.Main# as a maven property inside the project. diff --git a/using_images/sti_images/nodejs.adoc b/using_images/sti_images/nodejs.adoc index 290de83b52f8..7342392e8b41 100644 --- a/using_images/sti_images/nodejs.adoc +++ b/using_images/sti_images/nodejs.adoc @@ -11,7 +11,7 @@ toc::[] == Overview OpenShift provides -link:../../architecture/core_objects/builds.html#sti-build[STI] enabled +link:../../architecture/core_objects/builds.html#source-build[STI] enabled NodeJS images for building and running NodeJS applications. ifdef::openshift-origin[] The https://github.com/openshift/sti-nodejs[NodeJS STI builder image] diff --git a/using_images/sti_images/perl.adoc b/using_images/sti_images/perl.adoc index a7b17fdaeb6d..99d1bbd20d82 100644 --- a/using_images/sti_images/perl.adoc +++ b/using_images/sti_images/perl.adoc @@ -11,7 +11,7 @@ toc::[] == Overview OpenShift provides -link:../../architecture/core_objects/builds.html#sti-build[STI] enabled +link:../../architecture/core_objects/builds.html#source-build[STI] enabled Perl images for building and running Perl applications. ifdef::openshift-origin[] The https://github.com/openshift/sti-perl[Perl STI builder image] diff --git a/using_images/sti_images/php.adoc b/using_images/sti_images/php.adoc index be06a61d474c..591af241fece 100644 --- a/using_images/sti_images/php.adoc +++ b/using_images/sti_images/php.adoc @@ -11,7 +11,7 @@ toc::[] == Overview OpenShift provides -link:../../architecture/core_objects/builds.html#sti-build[STI] enabled +link:../../architecture/core_objects/builds.html#source-build[STI] enabled PHP images for building and running PHP applications. ifdef::openshift-origin[] The https://github.com/openshift/sti-php[PHP STI builder image] diff --git a/using_images/sti_images/python.adoc b/using_images/sti_images/python.adoc index b1bc62eccc1f..500b03f366d6 100644 --- a/using_images/sti_images/python.adoc +++ b/using_images/sti_images/python.adoc @@ -11,7 +11,7 @@ toc::[] == Overview OpenShift provides -link:../../architecture/core_objects/builds.html#sti-build[STI] enabled +link:../../architecture/core_objects/builds.html#source-build[STI] enabled Python images for building and running Python applications. ifdef::openshift-origin[] The https://github.com/openshift/sti-python[Python STI builder image] diff --git a/using_images/sti_images/ruby.adoc b/using_images/sti_images/ruby.adoc index 3667cbf5a9dc..a38df34ea4c5 100644 --- a/using_images/sti_images/ruby.adoc +++ b/using_images/sti_images/ruby.adoc @@ -11,7 +11,7 @@ toc::[] == Overview OpenShift provides -link:../../architecture/core_objects/builds.html#sti-build[STI] enabled +link:../../architecture/core_objects/builds.html#source-build[STI] enabled Ruby images for building and running Ruby applications. ifdef::openshift-origin[] The https://github.com/openshift/sti-ruby[Ruby STI builder image] diff --git a/whats_new/terminology.adoc b/whats_new/terminology.adoc index 3361d224822b..0a216a910d81 100644 --- a/whats_new/terminology.adoc +++ b/whats_new/terminology.adoc @@ -30,7 +30,7 @@ does more than a cartridge from a packaging perspective, providing better encapsulation and flexibility. But the cartridge concept also included logic for building, deploying, and routing which do not exist in images. In OpenShift v3, these additional needs are met by -link:../architecture/core_objects/builds.html#sti-build[Source-to-Image (STI)] +link:../architecture/core_objects/builds.html#source-build[Source-to-Image (STI)] and link:../architecture/core_objects/openshift_model.html#template[templated configuration].