Chapter 2. Creating container images in a network-restricted environment

Procedure

1. Run the following command to mirror the images that buildah build strategy requires:

   $ oc image mirror --insecure -a <registry_authentication> registry.redhat.io/ubi8/buildah@sha256:1c89cc3cab0ac0fc7387c1fe5e63443468219aab6fd531c8dad6d22fd999819e <mirror_registry>/<repo>/ubi8_buildah

   where:

   <registry_authentication>

   Specifies the authentication credentials used to access a container registry. This is required when pushing to or pulling from a private registry.

   <mirror_registry>

   Specifies the registry where the image you want to mirror is stored.

2. Create a Build resource and apply it to the OpenShift Container Platform cluster. You can do so by using the oc command or the shp command:

   $ oc apply -f - <<EOF
   apiVersion: shipwright.io/v1beta1
   kind: Build
   metadata:
     name: buildah-golang-build
   spec:
     source:
       type: Git
       git:
         url: https://github.com/shipwright-io/sample-go
       contextDir: docker-build
     strategy:
       name: buildah
       kind: ClusterBuildStrategy
     paramValues:
     - name: dockerfile
       value: Dockerfile
     output:
       image: image-registry.openshift-image-registry.svc:5000/buildah-example/sample-go-app
   EOF

   where:

   source

   Defines the location where the source code is placed.

   strategy

   Defines the build strategy that you use to build the container.

   paramValues

   Defines the parameter defined in the build strategy. To set the value of the dockerfile strategy parameter, specify the Dockerfile location required to build the output image.

   output

   Defines 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-example is the name of the current project. Ensure that the specified project exists to allow the image push.

   $ shp build create buildah-golang-build \
   --source-url="https://github.com/redhat-openshift-builds/samples"
   --source-context-dir="buildah-build" \
   --strategy-name="buildah" \
   --dockerfile="Dockerfile" \
   --output-image="image-registry.openshift-image-registry.svc:5000/buildah-example/go-app"

   where:

   source-context-dir

   Defines the location where the source code is placed.

   strategy-name

   Defines the build strategy that you use to build the container.

   dockerfile

   Defines the parameter defined in the build strategy. To set the value of the dockerfile strategy parameter, specifies the Dockerfile location required to build the output image.

   output-image

   Defines 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-example is the name of the current project. Ensure that the specified project exists to allow the image push.

3. Check if the Build resource is created. You can do so by using the oc command or the shp command:

   $ oc get builds.shipwright.io buildah-golang-build

   $ shp build list

4. Create a BuildRun resource and apply it to the OpenShift Container Platform cluster. You can do so by using the oc command or the shp command:

   $ oc apply -f - <<EOF
   apiVersion: shipwright.io/v1beta1
   kind: BuildRun
   metadata:
     name: buildah-golang-buildrun
   spec:
     build:
       name: buildah-golang-build
   EOF

   where:

   spec.build.name

   Defines the build to run, which is expected to be available in the same namespace.

   $ shp build run buildah-golang-build --follow

   • --follow:: (Optional) Use the --follow flag to view the build logs in the output result.

5. Check if the BuildRun resource is created. You can do so by using the oc command or the shp command:

   $ oc get buildrun buildah-golang-buildrun

   $ shp buildrun list

   The BuildRun resource creates a TaskRun resource, which then creates the pods to execute build strategy steps.

1. Check whether the pod shows the STATUS field as Completed:

   $ oc get pods -w

   Example 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          55s

2. Check whether the respective TaskRun resource shows the SUCCEEDED field as True:

   $ oc get tr

   Example output:

   NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
   buildah-golang-buildrun-dtrg2  True       Succeeded  11m         8m51s

3. Check whether the respective BuildRun resource shows the SUCCEEDED field as True:

   $ oc get br

   Example output:

   NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
   buildah-golang-buildrun  True        Succeeded    13m           11m

4. During verification, if a build run fails, you can check the status.failureDetails field in your BuildRun resource to identify the exact point where the failure happened in the pod or container.

   Note

   The pod might switch to a NotReady state because one of the containers has completed its task. This is an expected behavior.

5. Validate whether the image has been pushed to the registry that is specified in the build.spec.output.image field. Run the following command to pull the image from a node that can access the internal registry:

   $ podman manifest inspect image-registry.openshift-image-registry.svc:5000/buildah-example/taxi-app

   In the previous example, the project name is buildah-example, and the image name is taxi-app.

   Example output:

      "schemaVersion": 2,
       "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
       "manifests": [
           {
               "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
               "size": 594,
               "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
               "platform": {
                   "architecture": "amd64",
                   "os": "linux"
               }
        ]

Procedure

1. Run the following command to mirror the images that source-to-image build strategy requires:

   $ 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

   where:

   <registry_authentication>

   Specifies the authentication credentials used to access a container registry. This is required when pushing to or pulling from a private registry.

   <mirror_registry>

   Specifies the registry where the image you want to mirror is stored.

2. Create a Build resource and apply it to the OpenShift Container Platform cluster. You can do so by using the oc command or the shp command:

   $ oc apply -f - <<EOF
   apiVersion: shipwright.io/v1beta1
   kind: Build
   metadata:
     name: s2i-nodejs-build
   spec:
     source:
       type: Git
       git:
         url: https://github.com/redhat-openshift-builds/samples
       contextDir: s2i-build/nodejs
     strategy:
       name: source-to-image
       kind: ClusterBuildStrategy
     paramValues:
     - name: builder-image
       value: quay.io/centos7/nodejs-12-centos7:master
     output:
       image: quay.io/<repo>/s2i-nodejs-example
       pushSecret: registry-credential
   EOF

   where:

   source

   Defines the location where the source code is placed.

   strategy

   Defines the build strategy that you use to build the container.

   paramValues

   Defines the parameters for the build strategy. For source-to-image builds, this includes the builder-image parameter that specifies the base image used to build your application.

   output

   Defines 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-example is the name of the current project. Ensure that the specified project exists to allow the image push.

   pushSecret

   Defines the secret name that stores the credentials for pushing container images. To generate a secret of the type docker-registry for authentication, see "Authentication to container registries".

   $ shp build create s2i-nodejs-build \
   --source-url="https://github.com/redhat-openshift-builds/samples" --source-context-dir="s2i-build/nodejs" \
   --strategy-name="source-to-image" \
   --builder-image="quay.io/centos7/nodejs-12-centos7" \
   --output-image="quay.io/<repo>/s2i-nodejs-example" \
   --output-credentials-secret="registry-credential"

   where:

   source-context-dir

   Defines the location where the source code is placed.

   strategy-name

   The build strategy that you use to build the container.

   builder-image

   The parameter defined in the build strategy. For source-to-image builds, this specifies the base image used to build your application.

   output-image

   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-example is the name of the current project. Ensure that the specified project exists to allow the image push.

   output-credentials-secret

   The secret name that stores the credentials for pushing container images. To generate a secret of the type docker-registry for authentication, see "Authentication to container registries".

3. Check if the Build resource is created. You can do so by using the oc command or the shp command:

   $ oc get builds.shipwright.io s2i-nodejs-build

   $ shp build list

4. Create a BuildRun resource and apply it to the OpenShift Container Platform cluster. You can do so by using the oc command or the shp command:

   $ oc apply -f - <<EOF
   apiVersion: shipwright.io/v1beta1
   kind: BuildRun
   metadata:
     name: s2i-nodejs-buildrun
   spec:
     build:
       name: s2i-nodejs-build
   EOF

   where:

   spec.build.name

   Specifies the respective build to run, which is expected to be available in the same namespace.

   $ shp build run s2i-nodejs-build --follow

   + where:

   --follow

   (Optional) Use the --follow flag to view the build logs in the output result.

5. Check if the BuildRun resource is created. You can do so by using the oc command or the shp command:

   $ oc get buildrun s2i-nodejs-buildrun

   $ shp buildrun list

   The BuildRun resource creates a TaskRun resource, which then creates the pods to execute build strategy steps.

1. Check whether the pod shows the STATUS field as Completed:

   $ oc get pods -w

   Example 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          2m

2. Check whether the respective TaskRun resource shows the SUCCEEDED field as True:

   $ oc get tr

   Example output:

   NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
   s2i-nodejs-buildrun-phxxm      True       Succeeded  2m39s        13s

3. Check whether the respective BuildRun resource shows the SUCCEEDED field as True:

   $ oc get br

   Example output:

   NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
   s2i-nodejs-buildrun      True        Succeeded    2m41s           15s

4. During verification, if a build run fails, you can check the status.failureDetails field in your BuildRun resource to identify the exact point where the failure happened in the pod or container.

   Note

   The pod might switch to a NotReady state because one of the containers has completed its task. This is an expected behavior.

5. Validate whether the image has been pushed to the registry that is specified in the build.spec.output.image field. Log in to the registry and run the following command to pull the image:

   $ podman manifest inspect image-registry.openshift-image-registry.svc:5000/s2i-example/taxi-app

   In the previous example, the project name is s2i-example, and the image name is taxi-app.

   Example output:

      "schemaVersion": 2,
       "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
       "manifests": [
           {
               "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
               "size": 594,
               "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
               "platform": {
                   "architecture": "amd64",
                   "os": "linux"
               }
        ]

Procedure

1. To verify the cluster-wide proxy settings, run the following command:

   $ oc describe proxy/cluster

   Example output:

   Name:         cluster
   Namespace:
   Labels:       hypershift.openshift.io/managed=true
   Annotations:  hypershift.io/hosted-cluster-proxy-config: true
                 include.release.openshift.io/ibm-cloud-managed: true
                 include.release.openshift.io/self-managed-high-availability: true
                 release.openshift.io/create-only: true
   API Version:  config.openshift.io/v1
   Kind:         Proxy
   Metadata:
     Creation Timestamp:  2026-01-05T09:56:06Z
     Generation:          2
     Owner References:
       API Version:     config.openshift.io/v1
       Kind:            ClusterVersion
       Name:            version
       UID:             bfb9588f-106f-4e9f-965b-03daa0cd8c33
     Resource Version:  1451
     UID:               8bbf0aef-6d78-479d-abdf-ddbb34bf3ff1
   Spec:
     Trusted CA:
       Name:
   Events:    <none>

2. To verify the environment variables, run the following command:

   $ oc set env deployment/openshift-builds-operator --list -n openshift-builds | grep PROXY

   Example output:

   HTTP_PROXY=http://192.168.130.1:3128
   HTTPS_PROXY=https://192.168.130.1:3129
   NO_PROXY=.cluster.local,.svc,.testing,10.217.0.0/22,10.217.4.0/23,127.0.0.1,192.168.126.0/24,192.168.1
   30.11,api-int.crc.testing,localhost