Bake additional cert into Jenkins controller image #775
Conversation
|
I don't really have a good grasp of the jenkins architecture here so it might help to name things a little more explicitly to try to hint at what the architecture is. How about we go for something like I wouldn't be opposed to putting |
|
I like the
? IOW, this is saying "these are the same as the regular OpenShift images, except they have a cert added". And then we rename our S2I buildconfig and output to And I'll add a diagram somewhere showing how they're connected. |
|
yeah let's try that and see what it looks like in the next upload. |
The `jenkins-agent` BuildConfig outputs an image that is basically the same as the `jenkins-agent-base` image from OpenShift but with a cert, so use `jenkins-agent-base-with-cert` as its name to be clear. While we're here, rename the template filename to `jenkins-with-cert` to match (a future patch will add another buildconfig in there for the controller too).
Prep for next patch where we use this tag not just for the agent.
Just like we did for the agent image, play a similar trick to have the additional cert baked into the controller image. This is required if we need to fetch resources from HTTPS URLs covered by the root CA in code that runs directly on the controller. This situation comes up in RHCOS where we want to be able to load the pipecfg from an internal repo early on in jobs.
The `jenkins` word is overloaded. Add `-s2i` to make it clear this is the S2I build. This also matches the template name and filename it's part of.
This adds a diagram to make it easier to picture how the different imagestreams and buildconfigs are connected.
jlebon
force-pushed
the
pr/controller-cert
branch
from
1527816
to
cab85ff
Compare
|
Updated this now with better naming and a diagram! |
|
Looks much better now. Thanks for the diagram! |
Just like we did for the agent image, play a similar trick to have the
additional cert baked into the controller image. This is required if we
need to fetch resources from HTTPS URLs covered by the root CA in code
that runs directly on the controller. This situation comes up in RHCOS
where we want to be able to load the pipecfg from an internal repo early
on in jobs.