Este conteúdo não está disponível no idioma selecionado.
Work with Builds
Using Builds
Abstract
Chapter 1. Managing Builds Copiar o linkLink copiado para a área de transferência!
After installing Builds, you can create builds using buildah or source-to-image. You can also use an Open Container Initiative (OCI) to create your build. You can also delete custom resources that are not required for a build.
1.1. Creating a buildah build Copiar o linkLink copiado para a área de transferência!
You can create a buildah build and push the created image to the target registry.
Prerequisites
- You have installed the Builds for Red Hat OpenShift Operator on the OpenShift Container Platform cluster.
-
You have installed the
ocCLI. -
Optional: You have installed the
shpCLI.
Procedure
Create a
Buildresource and apply it to the OpenShift Container Platform cluster by using one of the CLIs:Example: Using
ocCLI$ oc apply -f - <<EOF apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source:1 type: Git git: url: https://github.com/shipwright-io/sample-go contextDir: docker-build strategy:2 name: buildah kind: ClusterBuildStrategy paramValues:3 - name: dockerfile value: Dockerfile output:4 image: image-registry.openshift-image-registry.svc:5000/buildah-example/sample-go-app EOF- 1
- The location where the source code is placed.
- 2
- The build strategy that you use to build the container.
- 3
- The parameter defined in the build strategy. To set the value of the
dockerfilestrategy parameter, specify the Dockerfile location required to build the output image. - 4
- The location where the built image is pushed. In this procedural example, the built image is pushed to the OpenShift Container Platform cluster internal registry.
buildah-exampleis the name of the current project. Ensure that the specified project exists to allow the image push.
Example: Using
shpCLI$ shp build create buildah-golang-build \ --source-url="https://github.com/redhat-openshift-builds/samples" --source-context-dir="buildah-build" \1 --strategy-name="buildah" \2 --dockerfile="Dockerfile" \3 --output-image="image-registry.openshift-image-registry.svc:5000/buildah-example/go-app"4 - 1
- The location where the source code is placed.
- 2
- The build strategy that you use to build the container.
- 3
- The parameter defined in the build strategy. To set the value of the
dockerfilestrategy parameter, specify the Dockerfile location required to build the output image. - 4
- The location where the built image is pushed. In this procedural example, the built image is pushed to the OpenShift Container Platform cluster internal registry.
buildah-exampleis the name of the current project. Ensure that the specified project exists to allow the image push.
Check if the
Buildresource is created by using one of the CLIs:Example: Using
ocCLI$ oc get builds.shipwright.io buildah-golang-buildExample: Using
shpCLI$ shp build listCreate a
BuildRunresource and apply it to the OpenShift Container Platform cluster by using one of the CLIs:Example: Using
ocCLI$ oc apply -f - <<EOF apiVersion: shipwright.io/v1beta1 kind: BuildRun metadata: name: buildah-golang-buildrun spec: build: name: buildah-golang-build1 EOF- 1
- The
spec.build.namefield denotes the respective build to run, which is expected to be available in the same namespace.
Example: Using
shpCLI$ shp build run buildah-golang-build --follow1 - 1
- Optional: By using the
--followflag, you can view the build logs in the output result.
Check if the
BuildRunresource is created by running one of the following commands:Example: Using
ocCLI$ oc get buildrun buildah-golang-buildrunExample: Using
shpCLI$ shp buildrun listThe
BuildRunresource creates aTaskRunresource, which then creates the pods to execute build strategy steps.
Verification
After all the containers complete their tasks, verify the following:
Check whether the pod shows the
STATUSfield asCompleted:$ oc get pods -wExample output
NAME READY STATUS RESTARTS AGE buildah-golang-buildrun-dtrg2-pod 2/2 Running 0 4s buildah-golang-buildrun-dtrg2-pod 1/2 NotReady 0 7s buildah-golang-buildrun-dtrg2-pod 0/2 Completed 0 55sCheck whether the respective
TaskRunresource shows theSUCCEEDEDfield asTrue:$ oc get trExample output
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME buildah-golang-buildrun-dtrg2 True Succeeded 11m 8m51sCheck whether the respective
BuildRunresource shows theSUCCEEDEDfield asTrue:$ oc get brExample output
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME buildah-golang-buildrun True Succeeded 13m 11mDuring verification, if a build run fails, you can check the
status.failureDetailsfield in yourBuildRunresource to identify the exact point where the failure happened in the pod or container.NoteThe pod might switch to a
NotReadystate because one of the containers has completed its task. This is an expected behavior.
Validate whether the image has been pushed to the registry that is specified in the
build.spec.output.imagefield. You can try to pull the image by running the following command from a node that can access the internal registry:$ podman pull image-registry.openshift-image-registry.svc:5000/<project>/<image>1 - 1
- The project name and image name used when creating the
Buildresource. For example, you can usebuildah-exampleas the project name andsample-go-appas the image name.
1.1.1. Creating buildah build in a network-restricted environment Copiar o linkLink copiado para a área de transferência!
You can create a buildah build in a network-restricted environment by mirroring the images required by the buildah build strategy.
Prerequisites
- Your cluster can connect and interact with the git source that you can use to create the buildah build.
Procedure
Run the following command to mirror the images required by the
buildahbuild strategy:$ oc image mirror --insecure -a <registry_authentication> registry.redhat.io/ubi8/buildah@sha256:1c89cc3cab0ac0fc7387c1fe5e63443468219aab6fd531c8dad6d22fd999819e <mirror_registry>/<repo>/ubi8_buildah- Perform the steps mentioned in the "Creating a buildah build" section.
1.2. Creating a source-to-image build Copiar o linkLink copiado para a área de transferência!
You can create a source-to-image build and push the created image to a custom Quay repository.
Prerequisites
- You have installed the Builds for Red Hat OpenShift Operator on the OpenShift Container Platform cluster.
-
You have installed the
ocCLI. -
Optional: You have installed the
shpCLI.
Procedure
Create a
Buildresource and apply it to the OpenShift Container Platform cluster by using one of the CLIs:Example: Using
ocCLI$ oc apply -f - <<EOF apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: s2i-nodejs-build spec: source:1 type: Git git: url: https://github.com/redhat-openshift-builds/samples contextDir: s2i-build/nodejs strategy:2 name: source-to-image kind: ClusterBuildStrategy paramValues:3 - name: builder-image value: quay.io/centos7/nodejs-12-centos7:master output: image: quay.io/<repo>/s2i-nodejs-example4 pushSecret: registry-credential5 EOF- 1
- The location where the source code is placed.
- 2
- The build strategy that you use to build the container.
- 3
- The parameter defined in the build strategy. To set the value of the
builder-imagestrategy parameter, specify the builder image location required to build the output image. - 4
- The location where the built image is pushed. You can push the built image to a custom Quay.io repository. Replace
repowith a valid Quay.io organization or your Quay user name. - 5
- The secret name that stores the credentials for pushing container images. To generate a secret of the type
docker-registryfor authentication, see "Authentication to container registries".
Example: Using
shpCLI$ shp build create s2i-nodejs-build \ --source-url="https://github.com/redhat-openshift-builds/samples" --source-context-dir="s2i-build/nodejs" \1 --strategy-name="source-to-image" \2 --builder-image="quay.io/centos7/nodejs-12-centos7" \3 --output-image="quay.io/<repo>/s2i-nodejs-example" \4 --output-credentials-secret="registry-credential"5 - 1
- The location where the source code is placed.
- 2
- The build strategy that you use to build the container.
- 3
- The parameter defined in the build strategy. To set the value of the
builder-imagestrategy parameter, specify the builder image location required to build the output image. - 4
- The location where the built image is pushed. You can push the built image to a custom Quay.io repository. Replace
repowith a valid Quay.io organization or your Quay user name. - 5
- The secret name that stores the credentials for pushing container images. To generate a secret of the type
docker-registryfor authentication, see "Authentication to container registries".
Check if the
Buildresource is created by using one of the CLIs:Example: Using
ocCLI$ oc get builds.shipwright.io s2i-nodejs-buildExample: Using
shpCLI$ shp build listCreate a
BuildRunresource and apply it to the OpenShift Container Platform cluster by using one of the CLIs:Example: Using
ocCLI$ oc apply -f - <<EOF apiVersion: shipwright.io/v1beta1 kind: BuildRun metadata: name: s2i-nodejs-buildrun spec: build: name: s2i-nodejs-build1 EOF- 1
- The
spec.build.namefield denotes the respective build to run, which is expected to be available in the same namespace.
Example: Using
shpCLI$ shp build run s2i-nodejs-build --follow1 - 1
- Optional: By using the
--followflag, you can view the build logs in the output result.
Check if the
BuildRunresource is created by running one of the following commands:Example: Using
ocCLI$ oc get buildrun s2i-nodejs-buildrunExample: Using
shpCLI$ shp buildrun listThe
BuildRunresource creates aTaskRunresource, which then creates the pods to execute build strategy steps.
Verification
After all the containers complete their tasks, verify the following:
Check whether the pod shows the
STATUSfield asCompleted:$ oc get pods -wExample output
NAME READY STATUS RESTARTS AGE s2i-nodejs-buildrun-phxxm-pod 2/2 Running 0 10s s2i-nodejs-buildrun-phxxm-pod 1/2 NotReady 0 14s s2i-nodejs-buildrun-phxxm-pod 0/2 Completed 0 2mCheck whether the respective
TaskRunresource shows theSUCCEEDEDfield asTrue:$ oc get trExample output
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME s2i-nodejs-buildrun-phxxm True Succeeded 2m39s 13sCheck whether the respective
BuildRunresource shows theSUCCEEDEDfield asTrue:$ oc get brExample output
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME s2i-nodejs-buildrun True Succeeded 2m41s 15sDuring verification, if a build run fails, you can check the
status.failureDetailsfield in yourBuildRunresource to identify the exact point where the failure happened in the pod or container.NoteThe pod might switch to a
NotReadystate because one of the containers has completed its task. This is an expected behavior.
Validate whether the image has been pushed to the registry that is specified in the
build.spec.output.imagefield. You can try to pull the image by running the following command after logging in to the registry:$ podman pull quay.io/<repo>/<image>1 - 1
- The repository name and image name used when creating the
Buildresource. For example, you can uses2i-nodejs-exampleas the image name.
1.2.1. Creating source-to-image build in a network-restricted environment Copiar o linkLink copiado para a área de transferência!
You can create a source-to-image build in a network-restricted environment by mirroring the images required by the source-to-image build strategy.
Prerequisites
- Your cluster can connect and interact with the git source that you can use to create the source-to-image build.
-
You have the builder-image required to create the
source-to-imagebuild in your local registry. If you do not have the builder-image in the local registry, mirror the source image.
Procedure
Run the following command to mirror the images required by the
source-to-imagebuild strategy:$ oc image mirror --insecure -a <registry_authentication> registry.redhat.io/source-to-image/source-to-image-rhel8@sha256:d041c1bbe503d152d0759598f79802e257816d674b342670ef61c6f9e6d401c5 <mirror_registry>/<repo>/source-to-image-source-to-image-rhel8- Perform the steps mentioned in the "Creating a source-to-image build" section.
1.3. Creating a build with OCI artifacts Copiar o linkLink copiado para a área de transferência!
You can create a build using an Open Container Initiative(OCI) artifact as your source code. An OCI artifact, also known as a scratch image, contains only the source code and is not intended to run as a container. You can pull the OCI artifact from a container registry and extract its contents to use as source code to run the build.
Prerequisites
- You have installed the Builds for Red Hat OpenShift Operator on the OpenShift Container Platform cluster.
-
You have installed the
occommand-line interface (CLI). -
You have installed the
shpCLI.
Procedure
Create a
Buildresource and apply it to the OpenShift Container Platform cluster. See the following example configuration:$ oc apply -f - <<EOF apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: my-oci-build1 spec: source: type: OCI ociArtifact: image: <quay.io/org/image:tag>2 strategy: name: <strategy-name>3 kind: ClusterBuildStrategy output: image: <target-image-registry/repository/image:tag>4 pushSecret: <secret-name-for-credentials>5 EOF- 1
- Defines the name of the
Buildresource. - 2
- Replace
<quay.io/org/image:tag>with the location of the OCI artifact source image. - 3
- Replace
<strategy-name>with the name of the build strategy to build the container (buildahorsource-to-image). - 4
- Replace
<target-image-registry/repository/image:tag>with the location where you want to push the built image. - 5
- Optional: Replace
<secret-name-for-credentials>with the secret name that stores the credentials for pushing container images. To generate a secret for a private registry for authentication, see Authentication to container registries
Choose one of the following methods to upload your source code to the required registry and run the build:
Use the
shpCLI:Run the following command in the directory containing the local source code. It packages your source code into a scratch container image, pushes it to the required registry, and runs the build:
$ shp build upload my-oci-build1 - 1
- Defines the name of the
Buildresource.
Upload the OCI artifact manually:
Create a
Containerfilein the root directory of your source code and add the following configuration:FROM scratch COPY . /Run the following command in the root directory of your source code to build the container image using Podman:
$ podman build -t <registry-path>/<image-name>:<tag>1 - 1
- Replace <registry-path>/<image-name>:<tag> with the build location for the container image.
Push the container image to the required location using the following command:
$ podman push <registry-path>/<image-name>:<tag>1 - 1
- Replace <registry-path>/<image-name>:<tag> with the location where you want to push the built image.
Run the build using the following command:
$ shp build run my-oci-build1 - 1
- Defines the name of the
Buildresource.
1.4. Editing the resources Copiar o linkLink copiado para a área de transferência!
You can edit the resources that are created by buildah and source-to-image build processes using the oc CLI. You can modify the resources as needed in your project.
Prerequisites
-
You have installed the
ocCLI.
Procedure
Run the following command to open the YAML definition in the default editor:
$ oc edit <resource_name> <build_resource_name>1 - 1
- Replace
<resource_name>with the name of the resource (build,buildrunorbuildstrategy) and<build_resource_name>with the name of the build resource that you want to edit.
- Edit the YAML definition and save the file.
1.5. Deleting the resources Copiar o linkLink copiado para a área de transferência!
You can delete resources created by the buildah and source-to-image (S2I) build processes using the oc CLI or the shp CLI. Deleting these resources helps you to clean up build configurations that are no longer required in your project.
1.5.1. Deleting a build resource Copiar o linkLink copiado para a área de transferência!
You can delete a build resource if it is not required in your project.
Prerequisites
-
You have installed the
ocCLI. - Optional: You have installed the shp CLI.
Procedure
Delete a
buildresource by using one of the following CLIs:
1.5.2. Deleting a buildrun resource Copiar o linkLink copiado para a área de transferência!
You can delete a buildrun resource if it is not required in your project.
Prerequisites
-
You have installed the
ocCLI. - Optional: You have installed the shp CLI.
Procedure
Delete a
buildresource by using one of the following CLIs:
1.5.3. Deleting a buildstrategy resource Copiar o linkLink copiado para a área de transferência!
You can delete a buildstrategy resource if it is not required in your project.
Prerequisites
-
You have installed the
ocCLI.
Procedure
Delete a
buildstrategyresource by using theocCLI:$ oc delete buildstrategy <buildstartegy_resource_name>1 - 1
- Replace <buildstartegy_resource_name> with the name of the
buildstrategyresource.
Legal Notice
Copiar o linkLink copiado para a área de transferência!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of the OpenJS Foundation.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.