Troubleshooting EAP 7 local BuildConfig in OCP 4

Environment

• Red Hat Enterprise Application Platform
  • 7.x
• Red hat OpenShift Container Platform (OCP)
  • 4.x
  • BuildConfig

Issue

• Example of EAP 7 buildconfig for localbuild
• How to troubleshoot buildconfig for EAP 7

Resolution

EAP 7 template deployment in OCP 4 will create two buildconfigs because it is a multi-stage (2 stages) build - which is then used by the deployment.yaml/deploymentconfig.yaml to be deployed.

1. First an image eap-artifacts is created with the EAP 7 builder image, and the galleon and maven settings are put in place
2. Second This second stage is just about adding the environment variables on the EAP runtime image; Runtime image is usually used for the eap-app build.

Therefore he template generates two buildconfig: eap-artifacts and the eap-apps and two image Streams, plus the service and the deployment/deploymentconfig yaml to deploy that image:

If the EAP 7 deployment is done with a runtime image different than the builder image, so then the builder image will be used only on the first build.
And the runtime image will be used on the second build process. So this called a multi-stage build process, where one image (via imagestream injection) is used on the next sequential build.

Process:

EAP builder image -> EAP eap-app-build-artifacts Image -> EAP app image

Related solutions

Root Cause

eap-app-build-artifacts BuildConfig

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: eap-app-build-artifacts
  namespace: eap-demo
  labels:
    app: eap74-basic-s2i
    app.kubernetes.io/component: eap74-basic-s2i
    app.kubernetes.io/instance: eap74-basic-s2i
    application: eap-app
    template: eap74-basic-s2i
    xpaas: 7.4.0
spec:
  nodeSelector: null
  output:
    to:
      kind: ImageStreamTag
      name: 'eap-app-build-artifacts:latest'
  resources: {}
  successfulBuildsHistoryLimit: 5
  failedBuildsHistoryLimit: 5
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'jboss-eap74-openjdk8-openshift:7.4.0'
      env:
        - name: MAVEN_MIRROR_URL
        - name: MAVEN_ARGS_APPEND
          value: '-Dcom.redhat.xpaas.repo.jbossorg'
        - name: GALLEON_PROVISION_LAYERS
        - name: GALLEON_PROVISION_DEFAULT_FAT_SERVER
          value: 'true'
        - name: ARTIFACT_DIR
      incremental: true
      forcePull: true
  postCommit: {}
  source:
    type: Git
    git:
      uri: 'https://github.com/jboss-developer/jboss-eap-quickstarts'
      ref: 7.4.x
    contextDir: kitchensink
  triggers:
    - type: GitHub
      github:
        secret: ...
    - type: Generic
      generic:
        secret: ..
    - type: ImageChange
      imageChange: {}
    - type: ConfigChange
  runPolicy: Serial

Above is an incremental buildconfig that takes a ImageStreamTag jboss-eap74-openjdk8-openshift:7.4.0 (builder image) from namespace openshift and forcePull true, so the image will be forced to be pulled even if already on the OCP node. Later then it adds the environment variables GALLEON_PROVISION_LAYERS among others. Then it combines that with the Content from github.com is not included.jboss-eap-quickstarts - Github, specifically the kitchensink, which is then compiled. It has four triggers: github, Generic, ImageChange and ConfigChange. So an image change and a ConfigChange produces a new image. The output is an ImageStreamTag image called eap-app-build-artifacts with tag latest.

eap-app BuildConfig

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: eap-app
  namespace: eap-demo
  labels:
    app: eap74-basic-s2i
    app.kubernetes.io/component: eap74-basic-s2i
    app.kubernetes.io/instance: eap74-basic-s2i
    application: eap-app
    template: eap74-basic-s2i
    xpaas: 7.4.0
spec:
  nodeSelector: null
  output:
    to:
      kind: ImageStreamTag
      name: 'eap-app:latest'
  resources: {}
  successfulBuildsHistoryLimit: 5
  failedBuildsHistoryLimit: 5
  strategy:
    type: Docker
    dockerStrategy:
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'jboss-eap74-openjdk8-runtime-openshift:7.4.0'
      imageOptimizationPolicy: SkipLayers
  postCommit: {}
  source:
    type: Dockerfile
    dockerfile: |-
      FROM jboss-eap74-openjdk8-runtime-openshift:7.4.0
      COPY /server $JBOSS_HOME
      USER root
      RUN chown -R jboss:root $JBOSS_HOME && chmod -R ug+rwX $JBOSS_HOME
      USER jboss
      CMD $JBOSS_HOME/bin/openshift-launch.sh
    images:
      - from:
          kind: ImageStreamTag
          name: 'eap-app-build-artifacts:latest'
        paths:
          - sourcePath: /s2i-output/server/
            destinationDir: .
  triggers:
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: 'eap-app-build-artifacts:latest'
    - type: ConfigChange
  runPolicy: Serial

Above is an serial buildconfig that takes two ImageStreamTag inputs, the runtime image jboss-eap74-openjdk8-runtime-openshift:7.4.0 (not tagged) and the ImageStreamTag eap-app-build-artifacts tag latest.
It runs the dockerfile and fetches the runtime image then it combines that with the image eap-app-build-artifacts tag latest.
It has two triggers: ImageChange and ConfigChange. So an image change and a ConfigChange produces a new image. The output is an ImageStreamTag image stream tag called 'eap-app' with tag latest. So if the eap-app-build-artifacts:latest changes, a new build is triggered.

Diagnostic Steps

1. Get an inspect from the namespace deploying the build: $ oc adm inspect ns/project
   The inspect will bring:

• the build configuration yaml: build.openshift.io/buildconfigs.yaml
• the build yaml: build.openshift.io/builds.yaml
• build pod yaml: /namespaces/namespace/pods/pod_name/pod/current.log
• image stream: image.openshift.io/imagestreams.yaml
• build pods (logs and yaml): something-build

The Inspect also brings other yamls, and the deploy and application pod logs. The build is done in a pod, i.e. the build pod, so the inspect will bring all this information at once. However, the Inspect will not bring the ServiceAccount, ClusterRole, or Rolebinding - given those are global, not namespace specific. Nor it will bring CustomResources, CR, because those are not native to OCP/Kubernetes, but instead are custom resources created by Operator as APIs upon their installations.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.