Hi there, Community! My name is Steve and I'm a senior developer on the DC deployments team at Atlassian.
Atlassian has a repository of Ansible roles and playbooks that we use to support our CloudFormation templates and internal deployments; check them out here.
It's very-much "some assembly required" right now.
We think this might be the basis of something useful to the wider community,
but we need your input to decide.
Read-on for more details and to have your say.
For the last 18 months or so the Atlassian DC deployments and internal IT teams have been slowly building and expanding a curated set of Ansible roles and playbooks to automate deployment, configuration, and maintenance of our Data Center products. While these roles were originally intended to be used in conjunction with our AWS CloudFormation templates , we’ve deliberately built them to be as general as possible as we didn’t want to limit their use-case. The roles are also increasingly being used internally by our IT operations team.
We're now thinking that these roles may be the basis of a useful toolkit for Atlassian administrators such as yourselves - especially those running Data Center deployments at scale.
This is a slightly contrived example of a playbook that will configure nodes of a Jira Software cluster, with an existing Postgres database that is deployed elsewhere, and a shared home mounted on /media/atl:
# Invoked with:
# ansible-playbook -v -i inv/standalone_instances -e atl_db_root_password=XXX -e atl_jdbc_password=XXX standalone_jira_software_dc_node.yml
- hosts: jira_software_node
- role: linux_common
- role: database_init
- role: product_common
- role: product_install
- role: jira_config
- role: product_startup
As you can see, almost all of the functionality is embedded in the roles, with the rest of the playbook being parameters supplied to the roles (in the vars section). I say this is "slightly contrived" as often these variables would be provided at runtime via the environment, although checking your playbooks configuration into a repository and fetching it at runtime (AKA GitOps) is certainly a valid approach.
The canonical use of these roles is to bring up new product nodes on-the-fly, with the runtime parameters being supplied by the environment and any configuration generated on first-run; cattle in the DevOps parlance. In the Cloudformation templates, we dump the stack details to a file and pull the variables in via group-vars. Depending on your infrastructure, these variables could come from a cloud configuration provider (such as etcd or Zookeeper), or just checked-in to Git.
This suite is intended to consist of many small, composable roles that can be combined together into playbooks. Wherever possible, roles are product-agnostic and platform-agnostic. To ensure quality and cross-platform compatibility Ansible's Molecule test-framework is used to test each role against multiple Linux distributions (currently Amazon Linux 2 and Ubuntu).
As mentioned at the start, this suite has primarily been used internally at Atlassian for our own purposes, and mostly on AWS. If you’re interested in trying the suite out in your infrastructure it's definitely “some assembly required”. But the repository is available to use or fork, and is under a permissive open-source license.
While we've tried to keep things general as possible, and produce tests for compatibility, it's inevitable that some assumptions are baked-in and there are still rough-edges:
The roles don't configure infrastructure; as far as possible, they are infrastructure agnostic. We made this choice deliberately, as the suite is intended to be used in conjunction with other infrastructure tools, such as CloudFormation or Terraform.
So far, our focus has been on working with AWS infrastructure, in particular CloudFormation and Amazon Linux 2. While we actively test against a non-RPM Linux distribution (Ubuntu) we know that there could be some blind-spots.
Speaking of Linux, we only support that; no other OSs are currently on our radar at this point.
Within the Linux sphere, we assume systemd, although other runtime configurations are possible.
We assume AdoptOpenJDK is available on the target platform.
So with all that said, what do you think? Is this something that would be useful to the Atlassian administrator community? What features are missing that you might want, and what forms of infrastructure would you like to see supported?
Steve SmithAtlassian Team
Hello folks! To the member of organizations who are still running their Atlassian applications on the server, we are on the side of the bridge, and if we need to sail the boat with confidence either...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events