OpenShift Build Operations: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(91 intermediate revisions by the same user not shown)
Line 3: Line 3:
* [[OpenShift_Operations#Subjects|OpenShift Operations]]
* [[OpenShift_Operations#Subjects|OpenShift Operations]]
* [[OpenShift_Concepts#Build|OpenShift Concepts]]
* [[OpenShift_Concepts#Build|OpenShift Concepts]]
* [[OpenShift Deployment Operations#Overview|Deployment Operations]]


=Overview=
=Overview=
{{Internal|OpenShift_Concepts#Build|Builds}}
=Build and Deploy a JEE Application=
{{Internal|OpenShift Build and Deploy a JEE Application with S2I|Build and Deploy a JEE Application with S2I}}
=Create a Build Configuration=
[[oc new-build]] is the preferred way to create a new [[OpenShift_Concepts#Build_Configuration|build configuration]]. [[oc new-app]] also creates a build configuration, and for an example of how to do so, see [[OpenShift_Build_and_Deploy_a_JEE_Application_with_S2I#Create_the_Application|Build and Deploy a JEE Application]]. The following considerations apply to all types of builds ([[#Source_Build|source]], [[#Docker_Build|docker]] and [[#Pipeline_Build|pipeline]]) that can be created with [[oc new-build]]:
* --dry-run can be used to visualize the results of the operation, without modifying anything on the master server.
==Docker Build==
--binary=true makes sure that restrictions associated with binary builds are enforced. It says that instead of expecting a source URL, set the build to expect binary contents. Will disable triggers.
cp target/session-servlet.war oc-build/deployments
oc new-build --binary=true --name=noss-dev --labels=app=noss-dev --image-stream=jboss-eap70-openshift:1.5
oc start-build noss-dev --from-dir=oc-build --wait=true
Also see: {{Internal|OpenShift_Concepts#Docker_Build|Docker Build}}
==Source Build==
Before declaring the build configuration, define an image stream that will provide the [[OpenShift_Concepts#Builder_Image|builder image]], as shown here:
{{Internal|OpenShift_Image_and_ImageStream_Operations#Create_an_Individual_Image_Stream_from_YAML.2FJSON|Create an Image Stream}}
Use a definition similar to:
apiVersion: v1
kind: ImageStream
metadata:
  name: eap7-builder-image
spec:
  tags:
  - name: latest
    from:
      kind: DockerImage
      name: registry.access.redhat.com/jboss-eap-7/eap70-openshift:latest
The [[OpenShift_Concepts#Source-to-Image_.28S2I.29_Build|source build]] configuration and associated objects is created with:
oc new-build \
  [--dry-run] \
  --strategy=source \
  --image-stream=<''builder-image-image-stream''> \
  [--name=''app-name''] \
  https&#58;//gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git
This will create the build configuration and the image stream for the artifacts. Immediately after the build configuration is declared, a build starts, and if it successful, a new image will be pushed into the artifact image stream.
The following issued may occur during the build configuration creation and the subsequent first build attempt:
* If the application name is not specified with --name, it will default to current project name.
* The command shallow clones the specified repository locally, so if the repository certificate is self-signed, which is almost always the case with internal repositories, it will complain. SSL certificate verification can be turned off as described here: [[Git_config#Turn_Off_SSL_Server_Certificate_Verification_for_a_Specific_Repository|turn off SSL server certificate verification]].
* If the repository uses self-signed certificate, the build pod will fail the same way while attempting to clone. This is fixed by adding the [[Git_Environment_Variables#GIT_SSL_NO_VERIFY|GIT_SSL_NO_VERIFY=true]] Git environment variable to the build configuration <tt>spec.strategy.sourceStrategy.env</tt>, as describe here: [[OpenShift_Build_Configuration_Definition#Turn_Off_SSL_Certificate_Verification_for_Git|turn off SSL server certificate for Git in a build pod]].
The full application template that creates all objects required for a S2I build and subsequent deployment is available here:
{{External|https://github.com/NovaOrdis/playground/blob/master/openshift/templates/eap7-application-s2i-template.yaml}}
==Pipeline Build==
* Git SSL verification:  if the repository uses self-signed certificate, the build pod will fail while attempting to clone. This is fixed by adding the [[Git_Environment_Variables#GIT_SSL_NO_VERIFY|GIT_SSL_NO_VERIFY=true]] Git environment variable to the build configuration <tt>spec.strategy.jenkinsPipelineStrategy.env</tt>, as describe here: [[OpenShift_Build_Configuration_Definition#Turn_Off_SSL_Certificate_Verification_for_Git|turn off SSL server certificate for Git in a build pod]].
Creating a pipeline build configuration automatically deploys a Jenkins pod, service, route. etc. in the project.
Jenkins doesn’t have label agent
===Alternative Pipeline Build Creation===
<font color=red>'''TODO'''</font>. Place a [[OpenShift_CI/CD_Concepts#Jenkinsfile|Jenkinsfile]] that defines the pipeline in the root of the source code repository.
The [[OpenShift_Concepts#Pipeline_Build|pipeline build]] configuration and associated objects is created with:
oc new-build [--dry-run] --strategy=pipeline https&#58;//gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git
==Source Clone Secret==
[[oc set#build-secret|oc set]] build-secret --source bc/<build-configuration-name'> <''secret-name''>
Then the secret can be added to the [[OpenShift_Concepts#Build_Configuration|build configuration]]:
oc new-build .../example.git --build-secret <''secret-name''>
==Set Maximum Duration==
spec:
  completionDeadlineSeconds: 1800
==Configure a Webhook Trigger for a Source Build==
A build can be triggered by a push into the source repository, if the source repository was configured with a webhook, and the build configuration contains a webhook trigger with the correct secret.
Source repository configuration:
* [[GitHub Concepts#Webhook|GitHub webhook configuration]]
* [[OpenShift Gogs Configuration#Configure_a_Webhook|Gogs webhook configuration]]
Build configuration: {{Internal|OpenShift_Build_Configuration_Definition#Enable_a_Generic_Webhook_Trigger|Enable a Generic Webhook Trigger}}
=Manually Start the Build Process=
  [[oc start-build]] <''buildConfig-name''>
The name of a previous build can be specified - it will be used as a starting point.
Options:
* --from-file
* --from-dir
* --from-repo
* --from-archive


=View Builds for Project=
=View Builds for Project=


  oc get builds
  oc get builds
NAME          TYPE      FROM          STATUS                    STARTED            DURATION
bookstore-1  Source    Git@ad0abda  Failed (AssembleFailed)  About an hour ago  2m43s
bookstore-2  Source    Git@ad0abda  Failed (AssembleFailed)  12 minutes ago      2m16s


Each build has an associated build pod, whose names can be obtained with:
Each build has an associated build pod, whose names can be obtained with:


  oc get pods
  oc get pods
NAME                      READY    STATUS    RESTARTS  AGE
bookstore-1-build        0/1      Error    0          57m
bookstore-2-build        0/1      Error    0          13m


=View Build Logs=
=View Build Logs=
Line 18: Line 145:
View build logs associated with a build object:
View build logs associated with a build object:


  oc logs -f builds/<''build-pod-name''>
  oc logs [-f] builds/<''build-name''>
 
If -f|--follow is used, it specifies that the logs should be streamed.
 
Viewing the build logs in this manner is similar to following the build pod's logs.
 
=Stop a Build in Progress=
 
oc cancel-build
 
=Delete a Build=
 
oc delete build/<''build-name''>
 
where the build name is among those returned by [[OpenShift_Build_Operations#View_Builds_for_Project|oc get builds]].
 
=Delete a Build Configuration=
 
oc delete bc/<''build-configuration-name''>  
 
Deleting a build configuration also deletes all associated builds and build pods.

Latest revision as of 22:59, 24 January 2018

Internal

Overview

Builds

Build and Deploy a JEE Application

Build and Deploy a JEE Application with S2I

Create a Build Configuration

oc new-build is the preferred way to create a new build configuration. oc new-app also creates a build configuration, and for an example of how to do so, see Build and Deploy a JEE Application. The following considerations apply to all types of builds (source, docker and pipeline) that can be created with oc new-build:

  • --dry-run can be used to visualize the results of the operation, without modifying anything on the master server.

Docker Build

--binary=true makes sure that restrictions associated with binary builds are enforced. It says that instead of expecting a source URL, set the build to expect binary contents. Will disable triggers.

cp target/session-servlet.war oc-build/deployments
oc new-build --binary=true --name=noss-dev --labels=app=noss-dev --image-stream=jboss-eap70-openshift:1.5 
oc start-build noss-dev --from-dir=oc-build --wait=true

Also see:

Docker Build

Source Build

Before declaring the build configuration, define an image stream that will provide the builder image, as shown here:

Create an Image Stream

Use a definition similar to:

apiVersion: v1
kind: ImageStream
metadata:
  name: eap7-builder-image
spec:
  tags:
  - name: latest
    from:
      kind: DockerImage
      name: registry.access.redhat.com/jboss-eap-7/eap70-openshift:latest

The source build configuration and associated objects is created with:

oc new-build \
  [--dry-run] \
  --strategy=source \
  --image-stream=<builder-image-image-stream> \
  [--name=app-name] \
  https://gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git

This will create the build configuration and the image stream for the artifacts. Immediately after the build configuration is declared, a build starts, and if it successful, a new image will be pushed into the artifact image stream.

The following issued may occur during the build configuration creation and the subsequent first build attempt:

  • If the application name is not specified with --name, it will default to current project name.
  • The command shallow clones the specified repository locally, so if the repository certificate is self-signed, which is almost always the case with internal repositories, it will complain. SSL certificate verification can be turned off as described here: turn off SSL server certificate verification.
  • If the repository uses self-signed certificate, the build pod will fail the same way while attempting to clone. This is fixed by adding the GIT_SSL_NO_VERIFY=true Git environment variable to the build configuration spec.strategy.sourceStrategy.env, as describe here: turn off SSL server certificate for Git in a build pod.

The full application template that creates all objects required for a S2I build and subsequent deployment is available here:

https://github.com/NovaOrdis/playground/blob/master/openshift/templates/eap7-application-s2i-template.yaml

Pipeline Build


Creating a pipeline build configuration automatically deploys a Jenkins pod, service, route. etc. in the project.

Jenkins doesn’t have label agent


Alternative Pipeline Build Creation

TODO. Place a Jenkinsfile that defines the pipeline in the root of the source code repository.

The pipeline build configuration and associated objects is created with:

oc new-build [--dry-run] --strategy=pipeline https://gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git

Source Clone Secret

oc set build-secret --source bc/<build-configuration-name'> <secret-name>

Then the secret can be added to the build configuration:

oc new-build .../example.git --build-secret <secret-name>

Set Maximum Duration

spec:
  completionDeadlineSeconds: 1800

Configure a Webhook Trigger for a Source Build

A build can be triggered by a push into the source repository, if the source repository was configured with a webhook, and the build configuration contains a webhook trigger with the correct secret. Source repository configuration:

Build configuration:

Enable a Generic Webhook Trigger

Manually Start the Build Process

 oc start-build <buildConfig-name>

The name of a previous build can be specified - it will be used as a starting point.

Options:

  • --from-file
  • --from-dir
  • --from-repo
  • --from-archive

View Builds for Project

oc get builds
NAME          TYPE      FROM          STATUS                    STARTED             DURATION
bookstore-1   Source    Git@ad0abda   Failed (AssembleFailed)   About an hour ago   2m43s
bookstore-2   Source    Git@ad0abda   Failed (AssembleFailed)   12 minutes ago      2m16s

Each build has an associated build pod, whose names can be obtained with:

oc get pods
NAME                      READY     STATUS    RESTARTS   AGE
bookstore-1-build         0/1       Error     0          57m
bookstore-2-build         0/1       Error     0          13m

View Build Logs

View build logs associated with a build object:

oc logs [-f] builds/<build-name>

If -f|--follow is used, it specifies that the logs should be streamed.

Viewing the build logs in this manner is similar to following the build pod's logs.

Stop a Build in Progress

oc cancel-build

Delete a Build

oc delete build/<build-name> 

where the build name is among those returned by oc get builds.

Delete a Build Configuration

oc delete bc/<build-configuration-name> 

Deleting a build configuration also deletes all associated builds and build pods.