Let’s automate Atlassian!
A complete Atlassian tool stack automatically deployed and configured with Docker. Try out STACI and get some hands-on experience, with the Atlassian tools stack in just 15 mins.
Atlassian is well known for their efficient and scalable software. We use it. Our customers use it. But let’s face it, it takes a lot of effort to install, deploy and maintain the software. You would also like a test- or staging environment, so you need to duplicate the solution. So immediately we start thinking infrastructure as code. Imagine spinning up a complete Atlassian tool stack environment. Furthermore, what about having an easy way to test drive a selection of the products to see if they fit your needs?!
This is where Docker comes into the picture. Docker enables us to automate and deploy a given software stack with ease. It’s a great platform and has a huge community to back it up. Dockerizing Atlassian Jira is nothing new. Nor any of the other Atlassian products for that matter. But there is still some way to go from building one Docker image, to configuring and deploying multiple containers to a datacenter. We simply need a provisioning layer to control and configure our Docker containers. And this is what our STACI project does by creating a complete toolstack for you.
STACI is a proof of concept codebase It’s a bunch of shell scripts that you can play with, to grasp the idea of making containers configurable and deployable with ease.
What we wanted as output from STACI, was a container for each Atlassian tool. And we wanted them to build on the same image, housing the standard tools you would expect to find when dealing with software installations. So, basically we wanted something like this:
Since MySQL doesn’t need Oracle Java, we harness the power of the layered nature of Docker images by basing our MySQL image directly on top of our Debian Jessie image instead of our Base image. This limits the overhead in the image. Also, a MySQL installation normally needs different tools than our other containers. And with STACI it’s really easy to swap out MySQL with eg. PostgreSQL. We have already prepared STACI for that scenario.
Now, the problem is not to create Dockerfiles that give us these images. The problem is rather, that sometimes I would want only Jira and Confluence, while at other times maybe only Jira, Bitbucket and Bamboo. Maybe I want a context path to Jira and Confluence, maybe not. There are a lot of things that could vary between installs. E.g. Java memory, usernames, passwords or the bunch of information needed to deploy to OpenStack or another target. We centralized all the variable information into property files. One for STACI that houses all the specific parameters needed to build the Docker images, and one for each deploy mechanism like OpenStack, VirtualBox and VMware.
To fetch this information from our property files, we created the file
tools.f in the folder
$STACI_HOME/functions. All scripts that need to get information from our property files, need to source this file, and then use the given function.
You would be given the value of the property “
jira_contextpath” by calling :
This way we only load the parameters we need, and they are a lot more visible in the code where they are being used. So when a script needs a specific property, it fetches it.
In order to get OpenStack to work, we need to load a couple of properties. These are normally given by our OpenStack provider in the form of a
Standard-openrc.sh file. Your provider can help you with a url.
openstack.properties are stored in the repository as templates. So the first time you pull the repository, you should copy
staci.properties in the same folder. And do the same for
openstack.properties.template. The same applies for
As of now, you can configure the following through
We aim at expanding this feature list in the near future.
Ok, let’s dive in. Let’s say we want to start a MySQL, Jira and Bitbucket on a VirtualBox provider.
Now, there’s one
vim command to edit
staci.properties. The changes in
conf/staci.properties are simple.
We need to edit
staci.properties to contain these lines:
The above turns on clustering, creating a docker swarm. One node for each application.
It uses VirtualBox as a provider. Then, the template wants us to start Confluence and Crucible, but we turn this off. We turn on bitbucket instead.
If you want to change the CPU count, memory or disk space of VirtualBox instances, edit the file
If not, they will get 10GB disk space, 1 CPU and 1024MB ram.
The last command,
install.sh will start STACI, and do its work. It will create four instances in VirtualBox. One for Consul, a service discovery, a MySQL, a Jira and a Bitbucket instance.
It will then build the base image on each node, and the respective application on its node. So Jira is built on the Jira node and so on.
Then it will fire them up using the generated
docker-compose.yml file in
Before stopping, STACI will connect to the MySQL server and create the databases you need, and then configure them for use. Once done, it will print the information you need to set up each application. If a browser is specified in
staci.properties, it will open the generated
SystemInfo.html where the same information is generated, but in HTML.
Since networking is possible between containers, you can use the container name for the MySQL database as reference from Jira. So the database hostname string for Jira should be
Your Atlassian containers should be up and running now. In the
SystemInfo.html you will find links to these. Click on them, and follow the web guide with information from the html file, and you’re done.
In the root of STACI we have a couple of scripts. The install script is the main script that ties together many of the scripts in the
./bin folder. Helper scripts can be found in the
./functions folder. We have a file in
dockermachine.f where we keep the functionality related to docker-machine. This is where host machines are created, provider properties fetched, and the swarm cluster created.
All images are located in
$STACI_HOME/images folder. These are built on the host that runs them. This way we don’t need to pass them to a registry when using a Docker swarm.
staci.properties you can turn clustering on or off. If set to off, STACI will build and start all containers locally on your machine.
If clustering is turned on, it will use the chosen provider to provision hosts, and then deploy containers there. It will create a host for each application and one for Consul, a service discovering container used for the network between nodes to work.
When the swarm is ready, set your environment up by running :
You will get a
docker info which then looks like this :
STACI can create these hosts via OpenStack, VirtualBox and VMware vSphere as a provider. We use the overlay network to connect the containers on the nodes.
The install script will create hosts (if not run locally), and build the chosen images with their configuration. These are then started via a generated docker-compose file in
$STACI_HOME/compose. This only contains the applications you selected in
It then starts a MySQL container and connects to the database, creates all the databases needed, and configures them. This happens via the script
$STACI_HOME/bin/init-mysql.sh. Later we would like to support PostgreSQL as well. Therefore,the database image is called
atlassiandb, and not
mysql when built.
Once the database is configured, it will generate a html file with the information you need when going through the Atlassian setup guides. If you specify your browser in
staci.properties then STACI will open the html file, when the stack is running. Each application will have a tab with a link to the running instance, and information about the database connection.
If you would like to change things, like the host names to Atlassian-Jira instead of Praqma-Jira, you can change this - and much more - in the configuration files located in
conf/. Also, you can change the usernames, passwords and database names for each application in staci.properties. Take a look, and play around with it.
STACI is a work in progress and we keep adding new features and configuration. This section lists some of the ideas on the roadmap. We would like to add more providers like DigitalOcean, Google Cloud and AWS. Ideally STACI runs everywhere. Right now you can only specify a single host type and size for all hosts. So the host that runs Jira has the same size as the one running Bitbucket and so on. Different teams have different needs, and so it is desirable to make this configurable. For running the Atlassian stack in production, obviously an HTTPS enabled setup is preferable. This could be handled by adding Apache, nginx or some other HTTPS enabled proxy server, perhaps with auto-generated certificates from Let’s Encrypt. Additionally STACI is entirely ephemeral and needs a proper way to provide persistent storage and backup. How to handle upgrades of the Atlassian products, while STACI is running in production is also an issue that needs to be addressed.
While STACI is not yet production ready, it provides an automated way to run the entire Atlassian stack, without much hassle or manual work. The Docker platform allows STACI to target multiple providers both locally and remote in the cloud. Either way the environment is consistent and reproducible. STACI has allowed us to have a testbed for migrations, upgrades, plugin developer, training and demonstrations. We can simply run a script, and then we are ready to run a large workshop, or provide a potential client with a sandbox environment. As such STACI has already provided a lot of value to us, and our customers.
To try out STACI and get some hands-on experience, visit our repository here:
We also encourage you to create GitHub issues or pull requests for any bugs you encounter or future improvements you would like.
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software.
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps