nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Atlassian Data Center on Kubernetes Community series #1

Gaby Cardona

Hi everyone,

Here’s the first session in our ongoing Atlassian Data Center on Kubernetes Community series! In this video, Mike talks about why we’ve focused on building K8 support for Data Center - but that’s not all.

We want your feedback on where we take this feature next, so we have some questions and we’d love to hear your thoughts.

Would you prefer to have a flexible version of the helm charts, or would you rather that we make every component pre-defined?

Why we ask

Providing a flexible version of the helm charts will enable you to customize them to fit your unique business needs. However, while we can test against the most common setups, your environment may be unique. Having the components be pre-defined will enable us to fully optimize the helm charts, but these components may not be exactly what you’re using today.

Should we provide deployment templates based on cloud-native managed K8s engines, or would you rather have the option to deploy on your selected platform?

Why we ask

Once the helm charts have been made generally available, you can use them to deploy Data Center products on either your own hardware or a cloud provider. Having the flexibility to select what platform you deploy on enables organizations to take advantage of modern infrastructure while maintaining their requirements, but it would require some level of localization.

Providing templates based on cloud-native managed K8s engines, such as EKS, AKE, GKE, or ACK, would allow us to build additional support, such as automation. However, they may not be applicable to your environments, and the compatibility of our templates would be more limited.

Do you like the helm chart-only approach that we’ve taken so far, or would you prefer a more powerful tool like Terraform and Openshift K8s operator?

Why we ask

The helm charts provide the essential building blocks needed to deploy Data Center in K8s clusters and give you the capability to integrate with your operation and automation tools.

Terraform and Opensfhit operators are more powerful and opinionated - they have control over how you upgrade, manage the lifecycle of software, and autopilot the operations. Those tools are less flexible than helm charts and you may need to work out your own approach to integrate with them.

Let us know your thoughts and questions in the comments below and stay tuned for the next video in our series coming out soon.

Comments

Jared Dohrman {ANZ}

Hi Gaby,

We just went live on EKS using Atlassian's Helm charts for both Jira and Confluence (25k users)

There were a few flexible changes we took advantage of and a few additional changes we had to incorporate in order to work with our k8s.

I'd be happy to connect and run through all the configuration observations along with Max Bern (Atlassian TAM) was with us throughout the entire journey.

Thanks,

Jared.

Michiel Schuijer_yj4jdb

Hello and thanks for the update.

My answers, after checking with my team, are: yes, yes and yes!

prefer to have a flexible version of the helm charts
provide deployment templates based on cloud-native managed K8s engines
like the helm chart-only approach

Cheers

Michiel

Gaby Cardona

Thanks for sharing Michiel!

Gaby Cardona

Thanks Jared! We'll work with Max to get some time booked smile

Jan B_

Hello.

for a few years we use Jira and Confluence on premise in our self manages k8s cluster.

Because of that we would prefer the flexible helm chart. Having a fully optimized version by just using the default values is great, but being able to modify as much as possible during the deployment without changing the helm chart would save a lot of time.

Unfortunately we cannot deploy our instances on any cloud-native managed K8s engine due to data protection requirements. That means we would be happy to see the option to deploy on our self managed k8s.

Last but not least, we do not work with any tools like Terraform so far which means the helm chart-only approach suits perfect for us.

Regards,

Jan

Gaby Cardona

Thanks for sharing Jan and welcome!

Gary Nguyen

Hi Gaby,

As an administrator for JIRA/Confluence, we're not expert in infrastructures and k8s.

Reading instructions from Atlassian documentation on helm charts/k8s, to tell you the true, we're totally lost with too much general details and all over the place with different technologies.

Therefore, we would love to have to things pre-defined and don't need much generalize.

What we're looking for:
- JIRA/Confluence DC front end nodes are k8s containers on AWS EKS
- DB backend using AWS RDS, and sharehome AWS EFS

I think it's a very typical common way for those people are on AWS cloud.
Reading instructions in general ways are hard. Video tutorial with 3-4 common usecase and scenarios would be good to understand the idea. Then we can modify from there....

My 2 cents...

Gary Nguyen

@Jared Dohrman , would you be able to share you helm charts? We're looking for the similar.

Gary Nguyen

@Gaby Cardona ,

In short, highly recommend 3 or 4 common specific scenarios (on youtube video please).

Most of us here are JIRA/Confluence admin but not System Admin with not much knowledges in Infra/k8s.

Jared Dohrman {ANZ}

Hi @Gary Nguyen ,

90% of what you need is in this file: https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/jira/values.yaml with some additional values that can be inspired from https://github.com/atlassian/data-center-helm-charts/blob/main/src/test/config/jira/values-EKS.yaml

Hope this helps!

Jared.

Xiaoxiang _Mike_ Ni

Hi Gary,

Thank you for giving us your feedback. This is a good suggestion. So if I understand you correctly, you are looking for a predefined Kubernetes deployment manual that you can simply follow to complete the installation step by step, correct?

At the moment, we build our helm templates flexible and provide an EKS example here if you haven't checked them out. https://atlassian.github.io/data-center-helm-charts/examples/cluster/EKS_SETUP/

This seems to be a good approach for those experienced system admins. But we heard you and will consider some opinioned scenarios for admin with simple deployment needs.

Besides, I want to point out that you can still choose non-Kubernetes cluster deployment. (we call classic cluster deployment) if Kubernetes does not add extra value to your organisations.

Gary Nguyen

Hi @Mike Ni .

We're Atlassian Platinum partner (we're expert in JIRA/Confluence but very basic in k8s). We're helping a few customers to move their existing JIRA/Confluence DC into k8s.

As we're suggesting them going into AWS EKS/RDS/EFS but then what, we're stuck and struggling doing the POC ourselves now.

So we can setup EKS cluster, configure RDS and EFS on AWS console manually.

So how do we make the helm chart to scale JIRA/Confluence up and down or easily spin up a new environment when we need to test on a new JIRA/Confluence version upgrade?

We're aware of all the instructions from Atlassian above, but then again, swimming into those, we got lost. Does Atlassian provide some specific scenarios for customers on AWS? (not generalize please). Are there any video tutorial for such those specific scenarios????

Thx

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

kubernetes