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.

[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.

[Gaby Cardona]

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

[Gary Nguyen]

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

[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.

[Michiel Schuijer]

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!

[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]

@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.

[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

[Gary Nguyen]

FYI. in particularly, we stuck where we could run the helm chart to spin up JIRA in our EKS but then don't know how to configure ingress, ALB and expose the port to the world so user can connect to the JIRA. 
We are what we stuck:

[root@ip-172-31-38-42 helm-charts3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jira-software-db-0 1/1 Running 0 9h
myjiratest-jira-software-c644c8c75-5sbft 1/1 Running 0 9h

[root@ip-172-31-38-42 helm-charts3]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
jira-software-db ClusterIP 10.100.184.178 <none> 5432/TCP 9h
jira-software-db-headless ClusterIP None <none> 5432/TCP 9h
myjiratest-jira-software ClusterIP 10.100.43.223 <none> 80/TCP 9h

[root@ip-172-31-38-42 helm-charts3]# kubectl get ingress
No resources found in jira-test namespace.

[Mike Ni]

Hi Gary,

let me connect you with the K8s Dev team for this time. So that your concern can get properly resolved. stay tuned 

[Gary Nguyen]

@Mike Ni  @Gaby Cardona , here is our specific use case:
- We want to spin-up JIRA/Confluence DC front end nodes on AWS/EKS (Dynamic)
- Database will be postgrep on AWS/RDS (Static)
- Data Share, AWS/EFS (Static)

I would think this is very common scenarios for those users who are on AWS. Little disappointed that Atlassian doesn't provide specific user case like this.

Here is our support ticket that I submitted:https://getsupport.atlassian.com/servicedesk/customer/portal/20/GHS-236717

[Gary Nguyen]

@Mike Ni , not sure if this ticket will help but doesnt sound like they do anything good.

Would your team (dev team) have some tutorial?

[Mike Ni]

@Gary Nguyen  Having a support ticket is a good approach. Our support team have comprehensive Kubernetes knowledge. They can help with some basics.

[Gary Nguyen]

I was hoping Atlassian would have specific documentation or tutorial for such a common usercase like us...

Little disappointed .... :-(

FYI, the support ticket doesn't go any where, except they give us some blogs from "google search", lol