diff --git a/publish/working-with-pipelines/working-with-pipelines.md b/publish/working-with-pipelines/working-with-pipelines.md index ad63d30..14d77c8 100644 --- a/publish/working-with-pipelines/working-with-pipelines.md +++ b/publish/working-with-pipelines/working-with-pipelines.md @@ -32,7 +32,7 @@ guide-category: pipelines // --> -# Introduction +## Introduction [Pipelines](https://github.com/tektoncd/pipeline/tree/master/docs#usage) enable a continuous integration and continuous delivery (CI/CD) workflow. A set of default tasks and pipelines are provided that can be associated with application stacks. These pipelines leverage steps and tasks that provide the following capabilities: - build the application stack @@ -51,83 +51,92 @@ To learn more about pipelines and creating new tasks, see [the pipeline tutorial ## Kabanero tasks and pipelines -A set of Kabanero tasks and pipelines are provided in the [Kabanero pipelines repository](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/). Details of some of the primary pipelines and tasks are described below. +A set of Kabanero tasks and pipelines are provided in the [Kabanero pipelines repository](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/). Details of some of the primary pipelines and tasks are described in the following sections. ### Events pipelines The tasks and pipelines provided in the [Kabanero pipelines repository events directory](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/incubator/events) are geared to work with the Kabanero events operator. Follow the instructions in the [Integrating the events operator](../integrating-events-operator/integating-events-operator.html) guide to set up the organization webhook and EventMediator to drive these pipelines. -There are four primary pipelines provided here to help illustrate the following work flow. +There are four primary pipelines that help illustrate the following work flow: -* **A developer makes an update to the application and creates a new pull request** +1. **A developer makes an update to the application and creates a new pull request** -This action triggers the [build-pl](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-pl.yaml) pipeline which builds the application code and builds the application image using the [build-task](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-task.yaml). The pull request (PR) is updated with the results of the build pipeline. + This action triggers the [build-pl](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-pl.yaml) pipeline, which builds the application code and builds the application image using the [build-task](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-task.yaml). The pull request (PR) is updated with the results of the build pipeline. -* **The pull request is then merged into the master branch** +2. **The pull request is then merged into the master branch** -This action triggers the [build-push-promote-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-push-promote-pl.yaml) pipeline which enforces the governance policy, builds the code, optionally signs the image, pushes it to the image registry, scans the image, optionally deploys the image on the cluster, and optionally promotes the service to the configured GitOps repository. + This action triggers the [build-push-promote-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-push-promote-pl.yaml) pipeline, which completes the following tasks: -The pipeline invokes the following tasks to accomplish the steps listed: - * [build-push-promote-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-push-promote-task.yaml) - This task first does a pre-build governance policy check to validate the stack version in the application repository is allowed to build based on the governance policy that is configured. It then builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages [Buildah](https://github.com/containers/buildah) to build the image. The command also generates the `app-deploy.yaml` that is used for deployment. If there is already a copy of the `app-deploy.yaml` file in the source repository, it is merged with the new one generated by this step. After the image is built, the image is then optionally signed if the necessary configuration is setup. Refer to the [image signing operator](https://github.com/kabanero-io/kabanero-security/tree/master/pipelines/samples/signing-operator) for more information on configuring image signing. The image is then pushed to the configured image registry. - - (Tech preview feature) A configmap called `gitops-map` in the Kabanero namespace can optionally be configured to promote the service to a GitOps repository after the build. The step will invoke the [`services promote`](https://github.com/rhd-gitops-example/services) command to create a PR with the updated `app-deploy.yaml` file in the configured GitOps repository. The following key value pairs should be setup in the configmap: - ``` - kind: ConfigMap - apiVersion: v1 - metadata: - name: gitops-map - namespace: kabanero - data: - gitops-repository-url: - gitops-repository-type: - gitops-commit-user-name: - gitops-commit-user-email: - ``` - - A secret called `gitops-token` also has to be created in the Kabanero namspace. This example yaml creates the secret. - ``` - apiVersion: v1 - kind: Secret - metadata: - name: gitops-token - annotations: - tekton.dev/git-0: https://github.com - namespace: kabanero - type: kubernetes.io/basic-auth - stringData: - username: - password: - ``` - - * [deploy-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-task.yaml) - If the `webhooks-tekton-local-deploy` property is set to `true` in the mediator, the image is deployed to the namespace configured in the `app-deploy.yaml`. By default, the application will be deployed in the `kabanero` namespace. - - * [image-scan-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-scan-task.yaml) - The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task. + * enforces the governance policy + * builds the code + * signs the image (optional) + * pushes the image to the image registry + * scans the image + * deploys the image on the cluster (optional) + * promotes the service to the configured GitOps repository (optional). + + The pipeline invokes the following tasks to accomplish these steps: + * [build-push-promote-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-push-promote-task.yaml): + This task runs a pre-build governance policy check to validate that the stack version in the application repository is allowed to build, based on the governance policy that is configured. If successful, a container image is built from the artifacts in the GitHub source repository by using the `appsody build` command. This command leverages [Buildah](https://github.com/containers/buildah) to build the image and generates the `app-deploy.yaml` that is used for deployment. If there is already a copy of the `app-deploy.yaml` file in the source repository, it is merged with the new one generated by this step. After the image is built, the image is signed if signing has been configured. For more information on configuring image signing, which is an optional step, see the [image signing operator](https://github.com/kabanero-io/kabanero-security/tree/master/pipelines/samples/signing-operator). The image is then pushed to the configured image registry. + + **(Tech preview feature)** A `ConfigMap` called `gitops-map` in the Kabanero namespace can optionally be configured to promote the service to a GitOps repository after the build. This step invokes the [`services promote`](https://github.com/rhd-gitops-example/services) command to create a PR with the updated `app-deploy.yaml` file in the configured GitOps repository. The following key value pairs should be setup in the `ConfigMap`: + ``` + kind: ConfigMap + apiVersion: v1 + metadata: + name: gitops-map + namespace: kabanero + data: + gitops-repository-url: + gitops-repository-type: + gitops-commit-user-name: + gitops-commit-user-email: + ``` -* **A release of the application is created** + A secret called `gitops-token` must also be created in the Kabanero namspace. The following example yaml creates the secret. + ``` + apiVersion: v1 + kind: Secret + metadata: + name: gitops-token + annotations: + tekton.dev/git-0: https://github.com + namespace: kabanero + type: kubernetes.io/basic-auth + stringData: + username: + password: + ``` -This event triggers the [image-retag-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-pl.yaml) pipeline, which leverages the [image-retag-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-task.yaml) to create a new tag of the image to match with the git release. + * [deploy-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-task.yaml): + If the `webhooks-tekton-local-deploy` property is set to `true` in the mediator, the image is deployed to the namespace configured in the `app-deploy.yaml`. By default, the application is deployed in the `kabanero` namespace. -* **The pull request in the GitOps repository is merged** (This feature is Tech Preview in this release) -When the PR that was created by the promote step of the `build-push-promote-pl` is merged in the GitOps repository, it triggers the [deploy-kustomize-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-pl.yaml) pipeline, which leverages the [deploy-kustomize-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-task.yaml) to trigger a deployment to the environment configured in the GitOps repository. + * [image-scan-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-scan-task.yaml): + The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task. + +3. **A release of the application is created** + + This event triggers the [image-retag-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-pl.yaml) pipeline, which leverages the [image-retag-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-task.yaml) to create a new tag of the image to match with the git release. + +4. **(Tech preview feature) The pull request in the GitOps repository is merged** + + When the PR that was created by the promote step of the `build-push-promote-pl` is merged in the GitOps repository, it triggers the [deploy-kustomize-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-pl.yaml) pipeline, which leverages the [deploy-kustomize-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-task.yaml) to trigger a deployment to the environment configured in the GitOps repository. ### Incubator pipelines -The set of Kabanero tasks and pipelines are provided in the [Kabanero pipelines repository](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/incubator) illustrate work flows that work best with the Tekton webhooks extension. +The set of Kabanero tasks and pipelines that are provided in the [Kabanero pipelines repository](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/incubator) illustrate work flows that work best with the Tekton webhooks extension. Details of some of the primary pipelines and tasks: - [build-deploy-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/build-deploy-pl.yaml) -This is the primary pipeline that showcases a majority of the tasks supplied in the Kabanero pipelines incubator repository. It enforces governance policy, builds the code, optionally signs the image, pushes it to the image registry, scans the image, and can conditionally deploy the image on the cluster. When running the pipeline via a webhook, the pipeline leverages the triggers functionality to conditionally deploy the application only when a pull request is merged in the GitHub repository. Other actions that trigger the pipeline run enforce governance policy, build, push, and scan the image. + This is the primary pipeline that showcases a majority of the tasks supplied in the Kabanero pipelines incubator repository. It enforces governance policy, builds the code, optionally signs the image, pushes it to the image registry, scans the image, and can conditionally deploy the image on the cluster. When running the pipeline via a webhook, the pipeline leverages the triggers functionality to conditionally deploy the application only when a pull request is merged in the GitHub repository. Other actions that trigger the pipeline run enforce governance policy, build, push, and scan the image. - [build-push-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/build-push-task.yaml) - This file builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages the [Buildah](https://github.com/containers/buildah) options. After the image is built, the image is published to the configured container registry. The build-push-task also generates the `app-deploy.yaml` that is used by the `deploy-task`. If there is already a copy of the `app-deploy.yaml` file in the source repository, it is merged with the new one generated by this step. - - To enable image signing, please refer to the [image signing operator](https://github.com/kabanero-io/kabanero-security/tree/master/pipelines/samples/signing-operator). + This file builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages the [Buildah](https://github.com/containers/buildah) options. After the image is built, the image is published to the configured container registry. The build-push-task also generates the `app-deploy.yaml` that is used by the `deploy-task`. If there is already a copy of the `app-deploy.yaml` file in the source repository, it is merged with the new one generated by this step. + + To enable image signing, please refer to the [image signing operator](https://github.com/kabanero-io/kabanero-security/tree/master/pipelines/samples/signing-operator) documentation. - [deploy-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/deploy-task.yaml) @@ -136,33 +145,38 @@ This is the primary pipeline that showcases a majority of the tasks supplied in - [image-scan-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/image-scan-task.yaml) The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task. - -For more tasks and pipelines, see [the kabanero-pipelines repository](https://github.com/kabanero-io/kabanero-pipelines). + +For more tasks and pipelines, see the [kabanero-pipelines repository](https://github.com/kabanero-io/kabanero-pipelines). ### Experimental GitOps pipelines (Tech Preview) There are two pipelines in the the experimental GitOps directory that demonstrate GitOps workflows. -The [build-push-promote-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/build-push-promote-pl.yaml) pipeline enforces the governance policy, builds the code, optionally signs the image, pushes it to the image registry, scans the image, and optionally promotes the service to the configured GitOps repository. +The [build-push-promote-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/build-push-promote-pl.yaml) pipeline runs the following tasks: + * enforces the governance policy + * builds the code + * signs the image (optional) + * pushes the image to the image registry + * scans the image + * promotes the service to the configured GitOps repository (optional) + +The pipeline invokes the following tasks to accomplish the steps listed: + * [build-push-promote-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/build-push-promote-task.yaml): This task first does a pre-build governance policy check to validate the stack version in the application repository is allowed to build based on the governance policy that is configured. It then builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages [Buildah](https://github.com/containers/buildah) to build the image. The image is then optionally signed and pushed to the configured image registry. -The pipeline invokes the following tasks to accomplish the steps listed: - * [build-push-promote-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/build-push-promote-task.yaml) - This task first does a pre-build governance policy check to validate the stack version in the application repository is allowed to build based on the governance policy that is configured. It then builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages [Buildah](https://github.com/containers/buildah) to build the image. The image is then optionally signed and pushed to the configured image registry. - A `configmap` file called `gitops-map` in the Kabanero namespace can optionally be configured to promote the service to a GitOps repository after the build. The step will invoke the [`services promote`](https://github.com/rhd-gitops-example/services) command to create a PR with the updated `app-deploy.yaml` file in the configured GitOps repository. The following key value pairs should be set up in the `configmap` file: ``` - kind: ConfigMap - apiVersion: v1 + kind: ConfigMap + apiVersion: v1 metadata: name: gitops-map namespace: kabanero data: - gitops-repository-url: + gitops-repository-url: gitops-repository-type: gitops-commit-user-name: gitops-commit-user-email: ``` - + A secret called `gitops-token` also has to be created in the Kabanero namspace. This example yaml creates the secret: ``` apiVersion: v1 @@ -177,68 +191,70 @@ The pipeline invokes the following tasks to accomplish the steps listed: username: password: ``` - * [image-scan-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/image-scan-task.yaml) + * [image-scan-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/image-scan-task.yaml): The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task. - The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task. +The [deploy-kustomize-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/deploy-kustomize-pl.yaml)pipeline leverages the [deploy-kustomize-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/deploy-kustomize-task.yaml) task to trigger a deployment to the environment configured in the GitOps repository. -The [deploy-kustomize-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/deploy-kustomize-pl.yaml) pipeline, which leverages the [deploy-kustomize-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/experimental/gitops/deploy-kustomize-task.yaml) to trigger a deployment to the environment configured in the GitOps repository. +## Before running pipelines -# Before running pipelines +Before you run a pipeline, a number of tasks might be required. These tasks are covered in the following sections. -## Associating pipelines with applications stacks in Kabanero custom resource +### Associating pipelines with application stacks in the Kabanero custom resource -### Events pipelines +The pipelines can be associated with an application stack in the Kabanero custom resource definition (CRD). Use the examples shown to update your configuration. -The pipelines can be associated with an application stack in the Kabanero custom resource definition (CRD). For example: +* Events pipelines -```yaml -apiVersion: kabanero.io/v1alpha1 -kind: Kabanero -metadata: - name: kabanero -spec: - version: "0.9.0" - stacks: - repositories: - - name: central - https: - url: https://github.com/kabanero-io/collections/releases/download/0.9.0/kabanero-index.yaml - pipelines: - - id: default - sha256: 14d59b7ebae113c18fb815c2ccfd8a846c5fbf91d926ae92e0017ca5caf67c95 - https: - url: https://github.com/kabanero-io/kabanero-pipelines/releases/download/0.9.0/kabanero-events-pipelines.tar.gz -``` + Example: -When the product operator activates the Kabanero CRD, it associates the pipelines in the pipelines archive with each of the stacks in the stack hub. The default pipelines are intended to work with all the stacks in the stack hub in the previous example. When the operator activates all the pipeline resources (such as the tasks, trigger bindings, and pipelines) in the archive, it adds a suffix to the name of the resource with the shorted digest of the pipelines archive. This configuration provides an easy way to have multiple versions of the same pipeline to be active on the cluster. + ```yaml + apiVersion: kabanero.io/v1alpha1 + kind: Kabanero + metadata: + name: kabanero + spec: + version: "0.9.0" + stacks: + repositories: + - name: central + https: + url: https://github.com/kabanero-io/collections/releases/download/0.9.0/kabanero-index.yaml + pipelines: + - id: default + sha256: 14d59b7ebae113c18fb815c2ccfd8a846c5fbf91d926ae92e0017ca5caf67c95 + https: + url: https://github.com/kabanero-io/kabanero-pipelines/releases/download/0.9.0/kabanero-events-pipelines.tar.gz + ``` -### Incubator pipelines + When the product operator activates the Kabanero CRD, it associates the pipelines in the pipelines archive with each of the stacks in the stack hub. The default pipelines are intended to work with all the stacks in the stack hub in the previous example. When the operator activates all the pipeline resources (such as the tasks, trigger bindings, and pipelines) in the archive, it adds a suffix to the name of the resource with the shorted digest of the pipelines archive. This configuration provides an easy way to have multiple versions of the same pipeline to be active on the cluster. -The pipelines can be associated with an application stack in the Kabanero CRD. For example: +* Incubator pipelines -```yaml -apiVersion: kabanero.io/v1alpha2 -kind: Kabanero -metadata: - name: kabanero - namespace: kabanero -spec: - version: "0.9.0" - stacks: - repositories: - - name: central - https: - url: https://github.com/kabanero-io/stacks/releases/download/0.9.0/kabanero-index.yaml - pipelines: - - id: default - sha256: 14d59b7ebae113c18fb815c2ccfd8a846c5fbf91d926ae92e0017ca5caf67c95 - https: - url: https://github.com/kabanero-io/kabanero-pipelines/releases/download/0.9.0/default-kabanero-pipelines.tar.gz -``` + Example: -When the product operator activates the CRD, it associates the pipelines in the pipelines archive with each of the stacks in the stack hub. The default pipelines are intended to work with all the stacks in the stack hub in the previous example. All of the pipeline-related resources (such as the tasks, trigger bindings, and pipelines) prefix the name of the resource with the keyword `StackId`. When the operator activates these resources, it replaces the keyword with the name of the stack it is activating. + ```yaml + apiVersion: kabanero.io/v1alpha2 + kind: Kabanero + metadata: + name: kabanero + namespace: kabanero + spec: + version: "0.9.0" + stacks: + repositories: + - name: central + https: + url: https://github.com/kabanero-io/stacks/releases/download/0.9.0/kabanero-index.yaml + pipelines: + - id: default + sha256: 14d59b7ebae113c18fb815c2ccfd8a846c5fbf91d926ae92e0017ca5caf67c95 + https: + url: https://github.com/kabanero-io/kabanero-pipelines/releases/download/0.9.0/default-kabanero-pipelines.tar.gz + ``` -## Creating and updating your own tasks and pipelines + When the product operator activates the CRD, it associates the pipelines in the pipelines archive with each of the stacks in the stack hub. The default pipelines are intended to work with all the stacks in the stack hub in the previous example. All of the pipeline-related resources (such as the tasks, trigger bindings, and pipelines) prefix the name of the resource with the keyword `StackId`. When the operator activates these resources, it replaces the keyword with the name of the stack it is activating. + +### Creating and updating your own tasks and pipelines The default tasks and pipelines can be updated by forking the Kabanero Pipelines repository and editing the files under `pipelines/`. An easy way to generate the archive for use by the Kabanero CRD is to run the [package.sh](https://github.com/kabanero-io/kabanero-pipelines/blob/master/ci/package.sh) script from the root directory of the pipelines project. The script generates the archive files with the necessary pipeline artifacts and a `manifest.yaml` file that describes the contents of the archive. It generates the pipelines archive file under `ci/assests`. It generates separate archives for the legacy incubator pipelines, events pipelines, and the experimental GitOps pipleines. @@ -252,7 +268,7 @@ For more detailed instructions, see [Curating Pipelines](../curating-pipelines/c // ================================================================================================= --> -## Using stacks published to internal and private registries in pipelines +### Using stacks published to internal and private registries in pipelines If you are publishing your application stack images to any registry other than Docker hub, you can specify your custom registry when you initialize a stack by using the `--stack-registry` option in the `appsody init` command. Specifying a custom registry updates the stack name in the `.appsody-config.yaml` to include the registry information that is consumed by the pipeline. @@ -261,13 +277,12 @@ If you are publishing your application stack images to any registry other than D // Transport layer security (TLS) verification for image registry access in pipelines // ================================================================================================= --> -## Transport layer security (TLS) verification for image registry access in pipelines +### Transport layer security (TLS) verification for image registry access in pipelines When accessing image registries to pull and push images, pipelines use the configuration the user established in the cluster resource, [image.config.openshift.io/cluster](https://docs.openshift.com/container-platform/4.2/openshift_images/image-configuration.html#images-configuration-file_image-configuration). Scenarios are presented of image registries that can be used and the setup steps required. -### Enable TLS verification for image registry access: +#### Enable TLS verification for Private image registries: -#### Private image registries: If you use a private image registry and your registry uses certificates that are signed by trusted CA authorities, no further configuration is needed to enable TLS verification. Review the default truststore on the nodes of your cluster to ensure that you have the CA of your certificate in the list. With self-signed certificates, you must ensure that the CA certificate is added to the appropriate config map. Use the steps that follow to add the CA to the appropriate configmap. @@ -275,7 +290,7 @@ If you use a private image registry and your registry uses certificates that are - Use the instructions for [adding certificate authorities to the cluster](https://docs.openshift.com/container-platform/4.3/builds/setting-up-trusted-ca.html#configmap-adding-ca_setting-up-trusted-ca) to create a configmap with the `key` as your private registry `hostname` and value as the content of your private registry `ca.crt` file. This configmap must be present in the `openshift-config` namespace. -#### Internal OpenShift image registry external route +##### Enable TLS verification for Internal OpenShift image registry external routes When you use the internal OpenShift image registry that is provided in your OCP cluster and want to access it using the external route, @@ -312,6 +327,7 @@ status: ``` - Once you have the external route set up, you can find the ca certificate value for the external route hostname by following these steps from the cluster. + ``` oc get configmap -n openshift-image-registry @@ -319,14 +335,14 @@ NAME DATA AGE image-registry-certificates 2 7d serviceca 1 7d trusted-ca 1 7d -[root@rugger-inf ~]# +[root@rugger-inf ~]# ``` - From the above command results try to search the content of configmap `image-registry-certificates` and find relevant external route certificate. - + From the results of this command, try to search the content of configmap `image-registry-certificates` to find the relevant external route certificate. + - Once you get the certifiate value for internal image registry external route from previous step, use the steps in section, [Private image registries](https://github.com/kabanero-io/guides/blob/master/publish/working-with-pipelines/working-with-pipelines.md#private-image-registries) to create a configmap in `openshift-config` namespace with the `key` as your internal registry external route as `hostname` and value as the content of your external route certificate value. -### Disable TLS verification for image registry access: +#### Disable TLS verification for image registry access If your private or internal registry does not have a valid TLS certificate or supports only HTTP connections, you must configure your cluster differently by disabling TLS verification first to allow pulling images from this registry. Use the `oc patch` command with your registry to accomplish this. If you use the `oc path` command for multiple image registries, the registry URL entries must be separated by commas. @@ -352,11 +368,11 @@ oc patch --type=merge --patch='{ // ================================================================================================= --> -# Running pipelines +## Running pipelines Explore how to use pipelines to build and manage application stacks. -## Prerequisites +### Prerequisites 1. [Kabanero foundation](https://github.com/kabanero-io/kabanero-foundation) must be installed on a supported Kubernetes deployment. @@ -364,7 +380,7 @@ Explore how to use pipelines to build and manage application stacks. 1. Secrets for the GitHub repository (if private) and image repository -## Getting started +### Getting started Follow these steps: @@ -386,11 +402,11 @@ Follow these steps: Alternatively, you can [configure secrets in the Kubernetes console or set them up by using the Kubernetes CLI](https://docs.okd.io/latest/dev_guide/secrets.html#creating-secrets). -## Running pipelines by using the pipelines dashboard webhook extension (Deprecated) +### Running pipelines by using the pipelines dashboard webhook extension (Deprecated) You can use the [pipelines dashboard webhook extension](https://github.com/tektoncd/experimental/blob/master/webhooks-extension/docs/GettingStarted.md) to drive pipelines that automatically build and deploy an application whenever you update the code in your GitHub repository. Events such as commits or pull requests can be set up to automatically trigger pipeline runs. -## Running pipelines by using a script +### Running pipelines by using a script If you are developing a new pipeline and want to test it in a tight loop, you can use a script or manually drive the pipeline. @@ -424,7 +440,7 @@ If you are developing a new pipeline and want to test it in a tight loop, you ca ./manual-pipeline-run-script.sh -r https://github.com/mygitid/appsody-test-project -i docker-registry.default.svc:5000/kabanero/my-java-openliberty-image -c java-openliberty" ``` -## Running pipelines manually from the command line +### Running pipelines manually from the command line Follow these steps to run a pipeline directly from the command line: @@ -451,7 +467,7 @@ Follow these steps to run a pipeline directly from the command line: oc apply -f -pipeline-resources.yaml ``` -## Activating tasks and pipelines +### Activating tasks and pipelines The installations that activate the featured application stacks also activate the tasks and pipelines. If you are creating a new task or pipeline, activate it manually, as shown in this example: @@ -460,7 +476,7 @@ oc apply -f oc apply -f ``` -## Running the pipeline +### Running the pipeline A sample `manual-pipeline-run-template.yaml` file is provided in the [/pipelines/sample-helper-files](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/sample-helper-files) directory. Rename the template file to a name of your choice (for example, pipeline-run.yaml), and update the file to replace `application-stack-name` with the name of your application stack. After you update the file, run it as shown in this example: @@ -474,17 +490,17 @@ oc apply -f -pipeline-run.yaml // ================================================================================================= --> -## Checking the status of the pipeline run +### Checking the status of the pipeline run You can check the status of the pipeline run from the Kubernetes console, command line, or pipelines dashboard. -### Checking pipeline run status from the pipelines dashboard +#### Checking pipeline run status from the pipelines dashboard 1. Log in to the pipelines dashboard and click `Pipeline runs` in the sidebar menu. 1. Find your pipeline run in the list and click it to check the status and find logs. You can see logs and status for each step and task. -### Checking pipeline run status from the command line +#### Checking pipeline run status from the command line Enter the following command in the terminal: