DevOps Home Server – Part two – Software

For the purposes of my own home DevOps server, I decided to use the range of Atlassian software.

Source Code Control Atlassian Bitbucket
Project and Issues tracking Atlassian JIRA
Documentation Atlassian Confluence
Build and Deploy server Atlassian Bamboo
Code Analysis SonarQube

The main reasons for this are :

  • I have used these applications in a previous job
  • They all integrate really nicely with each other
  • They are affordable (even though there are free open source equivalents)

Once they are all set up, and connected together, you can quickly change between them when browsing the web interfaces.

In terms of price, each one of these applications (apart from SonarQube which is free) costs $10 for a permanent license for 10 users.  If you wish to get software maintenance, then you can pay that price every year (actually, its half that for extending the maintenance after the initial purchase), but in my case, the initial purchase is going to be fine, costing not much more than a decent takeaway.

The Virtual Machines

Both VM’s are running on my original Intel NUC Server (i7, 16GB RAM), set-up with Microsoft Windows Server 2012.  I decided to create a separate SQL Server machine for a couple of reasons, one to reduce risk of failure (so one VM is not hosting everything), but also in case I ever need a general purpose SQL Server, it can be used for that as well.

SQL Server

I have installed Microsoft SQL Server 2016 on the VM, opened up appropriate ports, firewall rules etc., and that was about it.  It now sits there chugging away nicely.  I have still yet to sort out any form of backup system.  I will probably set up some automated database backups, but I will also aim to have the actual VM backed up as well.

DevOps Server

The DevOps Server is another VM, although I have given it a big more power than the SQL one purely as it will be hosting a number of applications at the same time, and it will need a fair amount of oomph to keep it all running smoothly.

Installing the software

NOTE: this is not a guide on how to install everything, just an overview of the experience.

The first step was to install Java as most of the Atlassian products are built on Java, after which I also installed Visual Studio as I knew that was a requirement for the Bamboo Build and Deploy server.  I then one by one installed and configured the following applications :

  • Atlassian JIRA
  • Atlassian Confluence
  • Atlassian Bitbucket
  • Atlassian Bamboo
  • SonarQube

Each piece of software required me to choose a program location, and a data directory.  Most software also added a Windows Service as well (although some had to be manually installed by running some command scripts).  Each application would start, and allow me to perform the first time configuration.  This involved the usual initial settings, database connection etc.  Most Databases had to be created prior to running the first time config, and also had to adhere to the softwares requirements in terms of collation settings.  Each Database was given its own specific user for the application to use (a standard sql user).

As I was wanting them all to have the same user database, I elected to use Active Directory, although this had to be set up after the initial install.  Most of the applications required the same AD config, and once I had figured it out for the first one, the others were straight forward.

Once everything was up and running, I was able to connect all of the Atlassian applications together so they show up on each applications hamburger menu, and as they are all configured with the same set of AD users, I am able to switch seamlessly between the applications.

External access

Obviously, as this is all just running on my home network, if I ever have to go anywhere, I don’t want to not be able to access it all, so I wanted to expose it to the outside world.  I am not worried about security, or about having my home broadband thrashed by outside users as its only going to be me using it.

To expose them online, all I had to do was configure up some port redirects on my router, so that any traffic hitting it on the relevant applications ports where forwarded to the correct port on the virtual server.  I configured my router to use a dynamic DNS service (Netgear’s own service) so that my home network could be reached on on all of the configured ports.

I then configured an appropriate domain so that the various sub domains would also redirect to the → → → → →

Unfortunately, this means that everything is still reliant on ports, so when accessing one of the sites, I would still need to use something like, but I am not too bothered about that.

Internal DNS

Now, one issue that I discovered with this plan was that each application, when trying to internally communicate with the other applications, because all URL’s (on the server itself) where full domains, and not just IP addresses, they would actually do the round trip to the internet and back.  This was not good as it would of caused delays etc.  What I did to fix this was to go on to my Active Directory VM, and set up DNS so that forward lookup DNS settings meant that any machine on the internal network, using AD, would not need to go outside the network for these URL’s.


In terms of performance, it all seems to work well.  There are times (such as if there is a build job running), that things seem to slow down somewhat, but I would say its no worse than I have seen in a real production environment.  It all works rather well, and it feels like I have my own professional business environment right at home.  The only issue is that the actual server makes a bit of noise. The fan seems to be working pretty hard, but I can just shut the door on my office and forget about it.

In the next blog post, I am going to describe the workflow of using it all.