iocanel
commented
4 years ago Feature, implemented in dekorate 0.12.3. Need to apply this version to quarkus and possibly perform minor tuning on the quarkus side.
Closed snowdrop-bot closed 4 years ago
iocanel
commented
4 years ago Feature, implemented in dekorate 0.12.3. Need to apply this version to quarkus and possibly perform minor tuning on the quarkus side.
Description I like the Kubernetes and OpenShift extensions since they generate the yaml files and if necessary you can change these settings easily, for example via properties file. I think that's the right approach. Make it simple for first time Quarkus developers, but allow them to change things later when needed. The same goes for the generated Dockerfiles, so that, for example, you can change to OpenJ9.
It's too bad though that you can only use S2I to deploy to OpenShift. In my case I used Java 11 locally which didn't work with the S2I standard image which only supports Java 8 since I had to compile locally rather than on the server. I could implement my own image builder, but why should I have to do this? I have my Dockerfile and yaml files exactly how I want them. Even if there were a Java 11 S2I, I'd prefer to use my own Dockerfile.
The alternatives have weaknesses for my requirements too: Binary builds allow you to build on the server side and to use existing Dockerfiles and yaml files, but I don't see how you can refer to existing (remote) Git repos. When you create builds from remote Git repos, you cannot apply your own yaml files. The Jib and Docker options I didn't get to work on my Mac even after I created a route to the registry.
I think it would be great to have solutions for two scenarios:
1) Developer wants to quickly push and test The Quarkus extensions come very close to solving this already. Unfortunately S2I is the only option which means I cannot use my own Dockerfile and I'm forced to use an older Java version I haven't tested with.
2) Deployments to production environments In this case the code is pushed to a Git repo first, tagged, etc. which means that mechanisms like binary builds cannot be used. Jenkins pipelines seem to be deprecated. I haven't seen documentation or best practices for how to do this.
Implementation ideas For scenario (1): Could the Kubernetes/OpenShift extension be extended to use the Dockerfile in the project rather than using S2I?
For scenario (2) it seems like there is a discussion going on already: https://github.com/quarkusio/quarkus/issues/6147
https://github.com/quarkusio/quarkus/issues/9663
$upstream:9663$