I gave a talk at Devops 2016 last week. The topic for the talk was Dockerising the IT infrastructure. The talk consisted of two stories from our internal improvement efforts, both of which related to Docker. In this blog post, I'm going to cover both of the stories in high level. You may also find the actual talk from YouTube and the slides from SlideShare.
First story: Deveo installation
Deveo can be either used from the cloud or installed on customers premises. In on-premise installations, Deveo supports multiple versions of four different Linux distributions. The supported systems can be found from our Administration guide. Our customers can set-up Deveo with three different deployment options based on the high availability and scalability needs. The deployment options are a combo, where everything is on one server, clustered, where the database and application nodes are separated, and high availability, where there can be multiple application nodes with a shared storage in addition to a separate database node.
During our history, we have faced a lot of problems in customer installations. Our installation followed the basic pattern of compiling everything from scratch. The problems we had with customer installations can be categorized into two different category.
- The installation took 90 minutes
- The installation was error-prone
In order to offer better installation experience to our customers, we replaced our installation process with Omnibus Chef. The purpose of Omnibus Chef is to easily create full-stack installers for your project across a variety of platforms. I found Ross Duggan's post describing what Omnibus Chef is and what it isn't.
The long story short, with the help of Omnibus Chef, we were able to cut down our installations from 90 minutes to 9 minutes. In addition, we were able to cut down problems during customer installations and upgrades tremendously. Last but not least, before we took Omnibus Chef based delivery pipeline into use, we were releasing on-premises packages rarely due to the error-prone nature of things. We got rid of our fear of releasing often and are now shipping Deveo to our customers monthly.
Second story: Dockerizing internal IT services
We have this thing called "office server". The server is dedicated hardware from Hetzner and it does many of our all-around things. We had various different services running on the same server with configurations varying even more. This kind of "office server" is typically considered as the largest technical debt for the organization from IT point of view due to reasons below:
- Losing of such server is critical
- Adding new services takes time
- Data safety and backups are often forgotten
In order to solve this mess of a server, we went on and dockerized everything. By running every service within their own containers were able to separate the namespace and storage for each of our services. Using Docker-compose, we were able to link services together and build such requirement chains as "Our self-built CRM requires a running Database".
Since nowadays Docker supports native disk volumes as well as native networking, tools such as Convoy can be used to build backup and recovery mechanisms for persistent data. This is exactly what we did, and it already allowed us to recover from one disk corruption within hours, whereas earlier it would have taken us days if not weeks to reinstall everything and play around with different backup solutions.
In the second story, our improvements were, and still are, that we are now able to provision new production level internal IT services within hours, where it used to take days. In addition, we are able to recover from disasters faster.
If you liked what you read above, you should definitely watch the presentation on Youtube, or read the slides from SlideShare. Both of them are embedded for your convenience below.