s2i builds a runnable container image inside OpenShift from a locally packaged application. With Quarkus, the OpenShift image-building extension uploads the built artifact and its dependencies; OpenShift performs the image build. This avoids building and pushing the application image separately. section 11.2 section 11.8
For a JAR-based service, an OpenShift BuildConfig takes binary input and uses a JDK builder image. It outputs an ImageStreamTag for the new application image. A deployment configured to watch that tag can redeploy when another s2i build produces an image. section 11.3.4
Listing 11.15 Continuation of the simplified generated openshift.yml
---
apiVersion: build.openshift.io/v1
kind: BuildConfig
...
name: inventory-service
namespace: default
spec:
output:
to:
kind: ImageStreamTag
name: inventory-service:1.0.0-SNAPSHOT
source:
binary: {}
strategy:
sourceStrategy:
from:
kind: ImageStreamTag
name: openjdk-21:1.20
---
apiVersion: apps/v1
kind: Deployment
...
name: inventory-service
namespace: default
spec:
...
spec:
containers:
...
- name: JAVA_APP_JAR
value: /deployments/quarkus-run.jar
image: quay.io/quarkus-in-action/inventory-service:1.0.0
imagePullPolicy: Always
The generated manifest shows the binary source, JDK-based source strategy, output ImageStreamTag, and application Deployment together. section 11.3.4
To deploy a Quarkus service with this workflow:
- Add the OpenShift extension and set `quarkus.container-image.builder=openshift`. section 11.3.4
- Use an `s2i` profile to clear container-image registry, group, and tag settings when deploying to OpenShift. section 11.3.4
- Package and deploy with `./mvnw clean package -Dquarkus.profile=prod,s2i -Dquarkus.openshift.deploy=true`; check `oc get pods` for the completed build pod and running application pod. section 11.3.4
Deploying several services
Apply the same builder and profile configuration to each Quarkus service. Replace `localhost` URLs with OpenShift Service names, and use generated manifest environment variables for service-specific endpoints. Expose routes where external access is needed. An application may still need separately deployed dependencies, such as its database; an s2i build does not supply them. section 11.6.3 section 11.3.4
s2i is specific to OpenShift. It can also supply the image for a Quarkus Knative function deployed on an OpenShift cluster; Knative’s scaling behavior is separate from the image build. section 11.8 section 11.5.4
