Openshift 4 hands on Lab - Build and update images with Build, Builder Trigger, Webhook

Article directory

Related concepts of building image

Applications running on OpenShift must ultimately run as containers. In the traditional way, the application container image can only be obtained after the Dockerfile is configured by the user and the docker build is run. In order to simplify the process of building image based on Dockerfile, OpenShift puts forward the concept of Build, which is used to define and manage image building with it and related objects. This includes the very easy-to-use Source-2-Image (S2I) tool, which can Build the application container image directly from the application source according to the best practice. Therefore, S2I function becomes a major function of OpenShift superior to Kubernetes.

To run the Build process and manage the Build, OpenShift uses two internal objects: BuildConfig and Build.

BuildConfig

BuildConfig is the object used to define the build policy, that is, to define what to do and how to do it. BuildConfig supports the following four build strategies:

  1. Dockerfile - that is, directly use dockerfile to build an image.
  2. S2I - use S2I tools to build images from application sources or application packages. The basic image of S2I is also known as Builder Image. OpenShift provides the corresponding Builder Image for the current mainstream development languages (such as Java, PHP, GO, NodeJS, Python, Ruby, HTML, etc.). S2I will automatically find the corresponding Builder Image according to the characteristics of the application source to be deployed, and then build it into the target container image with the application source.
  3. Pipeline - use the pipeline of Jenkins or Tekon (Kubernetes native CI/CD function, which is the default CI/CD environment in OpenShift 4).
  4. Custom - you can define a specific Builder Image instead of using the default Builder Image.
    In OpenShift, in addition to defining BuildConfig with YAML, you can also use the "OC new build" command to create a built configuration.

Build

Do you remember that in the "deploy application code" section of OpenShift 4 hands on Lab (1) - deploy application, after using S2I command, we used to view the log of build? Build is an object used to record the running status of each build. Every time a build is run, OpenShift will generate a build object corresponding to it. Use the following command in OpenShift to operate on the build process:

  1. OC start build: start a build process.
  2. OC cancel build: temporarily stop a build.
    OpenShift runs the Build process in a dedicated Pod. When the Build process is complete, the Pod becomes Completed. In fact, when we look at the Build log, we look at the Pod log.

Builder Image

The input to run a build process is BuildConfig and the original basic image (Builder Image), and the output of the build process is the result image. By default, OpenShift provides Builder Image for major language development applications, and users can customize their own Builder Image as required.

Build Trigger and Build Chain

In addition to using the above commands to manually trigger and run Build, Build also supports automatic triggering of the Build process based on events. OpenShift supports the following three Build triggers:

  1. Webhook: register the webhook address corresponding to the build to the Code Repository, such as the most commonly used Github. When the code on Github changes, Github can use webhook to start a build process from a remote trigger.
  2. Builder Image change: when a Builder Image changes, OpenShift can trigger the build process to update all the images that depend on the Builder Image.
  3. BuildConfig: when BuildConfig is created, OpenShift automatically triggers a build process to complete the S2I process.

In OpenShift, when the basic image changes, which is implemented by Build Trigger, it will automatically trigger to build the image that depends on it, so the relationship between the two images will form Build Chain.

Trigger Build to create or update images

Because in Pipeline, we can realize various CI/CD functions in addition to Build, so we will introduce Pipeline in the following chapters separately, and in this section we will introduce how to configure Webhook and Build Trigger.

Build Trigger based on Webhook

Before you start, you need to make sure you have an account on Github called "my & Github".

  1. Copy https://Github.com/liusiaoyu-git/php-helloworld to your Github account.
  2. Create a new project webhook user ID in OpenShift.
$ oc new-project webhook-USER-ID
  1. Execute the following command to create a PHP HelloWorld application based on PHP
$ oc new-app php~https://github.com/MY_GITHUB/php-helloworld
  1. Check buildconifg, find the bottom, and confirm that there is only one build in the buildconfig, namely php-helloworld-1. Then copy the address after the URL of "Webhook GitHub", which we call "webhook" URL.
$ oc describe bc/php-helloworld
Name:           php-helloworld
Namespace:      webhook-user-1
Created:        38 seconds ago
Labels:         app=php-helloworld
                app.kubernetes.io/component=php-helloworld
                app.kubernetes.io/instance=php-helloworld
Annotations:    openshift.io/generated-by=OpenShiftNewApp
Latest Version: 1
 
Strategy:       Source
URL:            https://github.com/liuxiaoyu-git/php-helloworld
From Image:     ImageStreamTag openshift/php:7.2
Output to:      ImageStreamTag php-helloworld:latest
 
Build Run Policy:       Serial
Triggered by:           Config, ImageChange
Webhook GitHub:
        URL:    		https://api.cluster-beijing-4af7.beijing-4af7.example.opentlc.com:6443/apis/build.openshift.io/v1/namespaces/webhook-user-1/buildconfigs/php-helloworld/webhooks/<secret>/github
Webhook Generic:
        URL:            https://api.cluster-beijing-4af7.beijing-4af7.example.opentlc.com:6443/apis/build.openshift.io/v1/namespaces/webhook-user-1/buildconfigs/php-helloworld/webhooks/<secret>/generic
        AllowEnv:       false
Builds History Limit:
        Successful:     5
        Failed:         5
 
Build                   Status          Duration                Creation Time
php-helloworld-1        running         running for 38s         2020-02-11 15:36:59 +0000 UTC
 
Events: <none>
  1. Execute the command to check the configuration of buildconfig, find "github" in the "triggers" section, and then replace the "< secret >" area in the "webbook? URL" string with the string after "secret".
$ oc get bc/php-helloworld -o yaml
. . . 
  triggers:
  -- github:
      secret: bhZIQnufyQZ3246OhM9Q
    type: GitHub
  -- generic:
      secret: -4UndTQhFrASVoqgNNUt
    type: Generic
  -- type: ConfigChange
  -- imageChange:
      lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/openshift/php@sha256:a5aaaae5baf98cb674ac2352429e0450591b45d3674e44c516612a9ee67282d5
    type: ImageChange
. . . 
  1. Execute the command to check build, and make sure that "STATUS" of php-helloworld-1 is "compiled".
$ oc get build
NAME               TYPE     FROM          STATUS     STARTED             DURATION
php-helloworld-1   Source   Git@8cb7578   Complete   About an hour ago   1m49s
  1. Execute the command to check the pod. You can see that the pod (PHP helloworld-1-Build) specially responsible for Build is in the Completed state, except for a pod running the application.
$ oc get pod
NAME                      READY   STATUS      RESTARTS   AGE
php-helloworld-1-build    0/1     Completed   0          9h
php-helloworld-1-deploy   0/1     Completed   0          9h
php-helloworld-2-z4r4l    1/1     Running     1          7h53m
  1. Generate route and then visit the page.
$ oc expose svc/php-helloworld
route.route.openshift.io/php-helloworld exposed
$ curl http://$(oc get route php-helloworld -o template='{{.spec.host}}')
  1. Enter the repository of github's PHP HelloWorld, and click the "Setting" tab.
  2. Enter Webhooks in the settings and click the "add Webhooks" button. Copy the webhook? URL to the Payload URL, select Content type as application/json, SSL verification as Disable, and then click Add webhook. You can see that the webhook is in the "green" state as shown below.
  3. Modify the index.php page of PHP HelloWorld on github, and then submit the modification. After submission, github will trigger a new build run on OpenShift through webhook.
  4. Execute the following command to confirm that "STATUS" of php-helloworld-2 is "Complete".
$ oc get build
NAME               TYPE     FROM          STATUS     STARTED             DURATION
php-helloworld-1   Source   Git@8cb7578   Complete   About an hour ago   1m32s
php-helloworld-2   Source   Git@e78c498   Complete   About an hour ago	 1m18s
  1. Visit route again to confirm that the page has been updated.
$ curl http://$(oc get route php-helloworld -o template='{{.spec.host}}')
  1. Check the build named php-helloworld-2 and confirm that "Build trigger cause" is "GitHub WebHook".
$ oc describe build/php-helloworld-2
. . 
Build trigger cause:    GitHub WebHook
Commit:                 e78c498 (change)
Author/Committer:       liuxiaoyu-git / GitHub
. . . 

Using Build Trigger to update Image automatically

Imagine that your container image is multi-layer (as shown in the figure below). In fact, each adjacent lower layer image is the basic image of the upper layer image (i.e. Builder Image). When the image of the lower layer is updated, the image of the upper layer that depends on it needs to be rebuilt so that the whole image is in the latest state. The process of automatically triggering the Builder needs to be implemented by Build Trigger of Image type in OpenShift.

  1. Create a new project, and then execute the following command to create a new build based on a Docker. Note: we can see from the returned results that after running the new build command, OpenShift will automatically create BuildConfig, and then run the build process once. During the construction process, OpenShift first recognizes that the Buider Image of this construction is the image named busybox according to https://github.com/liusiaoyu-git/welcome/blob/master/sh/dockerfile. Through the statement of "Every time" busybox:latest "changes a new build will be triggered", we can know that OpenShift will automatically build the builder Build Trigger is built between image and target image to realize automatic update. In addition, OpenShift creates the ImageStream object corresponding to the Buider Image (busybox) and the built output image (ops).
$ oc new-project build-trigger-USER-ID
$ oc new-build --name=ops https://github.com/liuxiaoyu-git/welcome --context-dir=sh
--> Found container image 6d5fcfe (6 weeks old) from docker.io for "docker.io/busybox"
 
    * An image stream tag will be created as "busybox:latest" that will track the source image
    * A Docker build using source code from https://github.com/liuxiaoyu-git/welcome will be created
      * The resulting image will be pushed to image stream tag "ops:latest"
      * Every time "busybox:latest" changes a new build will be triggered
 
--> Creating resources with label build=ops ...
    imagestream.image.openshift.io "busybox" created
    imagestream.image.openshift.io "ops" created
    buildconfig.build.openshift.io "ops" created
--> Success 
  1. Execute the command to view the build chain related to the ImageStream named busybox formed by Builder Trigger. The following shows that when the "busybox:latest" image changes, "bc/ops" will be triggered to update the image "ops:latest".
$ oc adm build-chain busybox
istag/busybox:latest
        bc/ops
                istag/ops:latest
  1. Execute the following command to create another Build named foo based on another Docker.
$ oc new-build --name=foo https://github.com/liuxiaoyu-git/welcome --context-dir=foo
  1. Check the situation of BuildConfig and BuildConfig. Currently, two builds are running according to the corresponding BuildConfig.
$ oc get bc
NAME   TYPE     FROM   LATEST
foo    Docker   Git    1
ops    Docker   Git    1
$ oc get build
NAME    TYPE     FROM          STATUS     STARTED              DURATION
ops-1   Docker   Git@359ea3d   Complete   2 minutes ago        27s
foo-1   Docker   Git@359ea3d   Complete   About a minute ago   23s
  1. Execute the command to view the build chain related to the ImageStream named busybox formed by Builder Trigger. Compared with the last view, a new build chain relationship has been formed between the "ops:latest" image and the "foo:latest" image.
$ oc adm build-chain busybox -n build-trigger
istag/busybox:latest
        bc/ops
                istag/ops:latest
                        bc/foo
                                istag/foo:latest
  1. Execute the following commands to view the build chain related to the ImageStream named ops and foo, respectively.
$ oc adm build-chain ops -n build-trigger
istag/ops:latest
        bc/foo
                istag/foo:latest
$ oc adm build-chain foo -n build-trigger
istag/foo:latest
  1. View Trigger in BuildConfig. You can see that each BuildConfig includes four kinds of triggers, among which only those with "TYPE" as "image" have corresponding triggers at present.
$ oc set triggers bc/foo -n build-trigger
NAME              TYPE     VALUE       AUTO
buildconfigs/foo  config               true
buildconfigs/foo  image    ops:latest  true
buildconfigs/foo  webhook  <secret>
buildconfigs/foo  github   <secret>
$ oc set triggers bc/ops -n build-trigger
NAME              TYPE     VALUE           AUTO
buildconfigs/ops  config                   true
buildconfigs/ops  image    busybox:latest  true
buildconfigs/ops  webhook  <secret>
buildconfigs/ops  github   <secret>
  1. Run a new build for ops.
$ oc start-build bc/ops
build.build.openshift.io/ops-2 started
  1. Execute the following command to find that there are 4 build records, because after ops-2 completes the build, it will automatically trigger the execution of foo-2 build according to build chain.
$ oc get build -w
NAME    TYPE     FROM          STATUS     STARTED          DURATION
ops-1   Docker   Git@359ea3d   Complete   12 minutes ago   27s
foo-1   Docker   Git@359ea3d   Complete   11 minutes ago   23s
ops-2   Docker   Git@359ea3d   Complete   4 minutes ago    27s
foo-2   Docker   Git@359ea3d   Complete   3 minutes ago    23s
  1. Execute the following command to delete the Trigger of build chain between foo and ops.
$ oc set triggers bc/foo --from-image=ops:latest --remove
buildconfig.build.openshift.io/foo triggers updated
  1. Check Build Chain again and find that there is no longer a BuildConfig process of foo after ops:latest
oc adm build-chain busybox
istag/busybox:latest
        bc/ops
                istag/ops:latest
  1. Run the OPS build again, and check to make sure there are only 5 build records. This is because we deleted the Build Trigger between Foo and ops in the previous step, so the new build ops-3 will not automatically trigger the build of foo-3.
$ oc start-build bc/ops
build.build.openshift.io/ops-3 started
$ oc get build
NAME    TYPE     FROM          STATUS     STARTED          DURATION
ops-1   Docker   Git@359ea3d   Complete   29 minutes ago   27s
foo-1   Docker   Git@359ea3d   Complete   27 minutes ago   23s
ops-2   Docker   Git@359ea3d   Complete   20 minutes ago   27s
foo-2   Docker   Git@359ea3d   Complete   20 minutes ago   23s
ops-3   Docker   Git@359ea3d   Complete   47 seconds ago   27s
  1. Execute the following command to restore the Build Chain between foo and ops.
$ oc set triggers bc/foo --from-image=ops:latest --remove=false
buildconfig.build.openshift.io/foo triggers updated
  1. Run OPS build again, and check to make sure there are 8 build records. There are not only ops-4 and foo-4, but also foo-3 that is missing after Build Chain is broken.
$ oc start-build bc/ops
build.build.openshift.io/ops-4 started
$ oc get build
NAME    TYPE     FROM          STATUS     STARTED              DURATION
ops-1   Docker   Git@359ea3d   Complete   43 minutes ago       27s
foo-1   Docker   Git@359ea3d   Complete   42 minutes ago       23s
ops-2   Docker   Git@359ea3d   Complete   35 minutes ago       27s
foo-2   Docker   Git@359ea3d   Complete   34 minutes ago       23s
ops-3   Docker   Git@359ea3d   Complete   15 minutes ago       27s
foo-3   Docker   Git@359ea3d   Complete   9 minutes ago        19s
ops-4   Docker   Git@359ea3d   Complete   About a minute ago   28s
foo-4   Docker   Git@359ea3d   Complete   51 seconds ago       24s
Published 61 original articles, praised 0, visited 5401
Private letter follow

Tags: PHP git Docker github

Posted on Wed, 12 Feb 2020 04:18:38 -0800 by Stressed