-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLIP-1826: Add user provided certificates to the default Java truststore #663
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -55,6 +55,18 @@ spec: | |
command: ["sh", "-c", {{ include "bamboo.sharedHome.permissionFix.command" . | quote }}] | ||
{{- end }} | ||
{{- include "common.jmx.initContainer" . | nindent 8 }} | ||
{{- if .Values.bamboo.additionalCertificates.secretName }} | ||
- name: import-certs | ||
image: {{ include "bamboo.image" . | quote }} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we are running this image because we want to run the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great question :) In fact, it does not really matter if we use temurin image for keytool init container. This won't save us any time since product image needs to be pulled anyways. It's a matter of which phase takes longer - init or containers start. If we pull product image in the init phase, container runtime will have it available when the product container starts. No gains/benefits with either of the approaches, imho. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for confirming this. I was thinking that because we pull the image anyway, it is faster on the pull time but for a very short period we take more resources than we need but as the execution is super quick, it is negligible. Last thing, if this fails, does it stop container execution, and how will customers get to the error logs (are they sufficient to understand why it failed?) |
||
imagePullPolicy: {{ .Values.image.pullPolicy }} | ||
volumeMounts: | ||
- name: keystore | ||
mountPath: /var/ssl | ||
- name: certs | ||
mountPath: /tmp/crt | ||
command: ["/bin/bash"] | ||
args: ["-c", {{ include "bamboo.addCrtToKeystoreCmd" . }}] | ||
{{- end }} | ||
containers: | ||
- name: {{ if .Values.bamboo.useHelmReleaseNameAsContainerName}}{{ include "common.names.fullname" . }}{{ else }}{{ .Chart.Name }}{{ end }} | ||
image: {{ include "bamboo.image" . | quote }} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when customer has or wants to define different passkey than the default
changeit
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We assume that the official image is used. In case of a custom truststore, it should be already mounted as a secret. So, if a user already mounts a custom truststore, importing new certs happens outside helm then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right and if customer wants to do something specific in this command, they can always redefine the
customCmd
.