SSL certs, upgrades, rollbacks

[Brian Leysath]

Some questions that have come in from a customer - posting them here as the answers would likely be helpful to others:

How some things are handled in a K8 / Data Center config:

· automated deployment of SSL certs from a source other than the image, as the cadence of their being updated may differ

· pre-determined cluster.properties settings (for JIRA) per node, or automated discovery of the scheme used in that cluster

· indexes, i.e. can a redeployed node be set to automatically dupe the index of another node in the cluster, before starting

· the handling of upgrades, complete with rollback options if things go awry

Thanks!

[Dylan Rathbone · Accepted solution]

Hi @Brian Leysath some great questions :)

Without passing the buck, Im going to refer you to our fantastic documentation. It's quite expansive, and I think it should cover most of these.

For each question I'll link in the relevant section that should hopefully provide the answers:

· automated deployment of SSL certs from a source other than the image, as the cadence of their being updated may differ

Response: For SSL management we've developed and tested the Helm Chart's using cert-manager. The documentation provides instructions on installation and configuration here

· pre-determined cluster.properties settings (for JIRA) per node, or automated discovery of the scheme used in that cluster

Response: Jira config can be pre-seeded with config data via the Helm Chart's values.yaml file. Config data that can be supplied up-front as part of a deployment are; Jira license, and database connectivity details. Details on how the values.yaml can be updated with these details can be found here

· indexes, i.e. can a redeployed node be set to automatically dupe the index of another node in the cluster, before starting

Response: This is something that Jira already performs under the hood. However, because of the speed at which K8s schedules new pod's, there are some associated limitations with indexing and Jira in K8s. Work is being performed to address these indexing limitations, but in the meantime there is a documented work around.

· the handling of upgrades, complete with rollback options if things go awry

Response: This is where K8s comes into its own. Using a RollingUpdate strategy it pretty much takes care of all this stuff for you ;) At a high-level, you decide on the version to upgrade to, K8s then cycles each pod in turn - upgrading to the new version and ensures that each pod successfully comes up with that version. Only then is the pod added to the cluster and traffic routed to it. For a rollback, scale the cluster down to zero pod's and then scale them back up with the previous product version. For more details on how to perform a Jira upgrade in K8s see here.

[Gaby Cardona]

Thanks for sharing @Brian Leysath