Simplify and Document how to customize the "wait-for" image when using init tasks on kubernetes #35455
Closed
2 of 5 tasks
Labels
area/jbang
Issues related to when using jbang.dev with Quarkus
area/kubernetes
kind/epic
Large issue with links to sub-issues
Milestone
Context
When using an init task (Liquibase, Flyway, or soon Kafka and AMQP), Quarkus generates multiple resources:
Note that each init task runs in a separate job and introduces another init container in the application pod.
By default, Quarkus init-container uses the
https://github.com/groundnuty/k8s-wait-for/
image to wait for the job execution.The init container runs that image with the following command line argument:
job <name of the job>
.Also, Quarkus generates a service account, adding the view-jobs roles (batch -> job -> get) to allow the init container to check the job execution status.
Problem
The image used by default is not following our image recommendation and, at the moment, contains two critical CVEs and 11 high CVEs (and a myriad of minors and lows).
Fortunately, it's possible to customize the image. However, the process is a bit cumbersome.
First, you need to provide an image following the exact same "way" to run and not requiring any more permission than "batch->jobs->GET" (so you cannot list the jobs). Then, you need to configure for each init task:
The
coffeeshop-service-kafka-topic-init
mixes the task name and the application name. As reported in #35436, an end user can't guess this name (without reading the Quarkus code).Also, you need to comply with the launch parameter of the container and the granted permissions.
Some parts of the solution
I came up with a containerized JBang script replacing the "wait-for" image:
Once built and deployed, you can replace the init container image.
Pending issues
The text was updated successfully, but these errors were encountered: