An Operations department in one of the world’s leading multimedia provider, operating in 26 countries and in partnership with networks in over 55 more. This particular project for a DevOps application in the German OpCo.
The challenge was to bring fully automated continuous integration together with continuous deployments and integrate it with customer’s infrastructure.
The single commit to the so called “Release” branch in a Git repository should trigger a process which results in the fully functional environment being deployed. Along with the deployment, there is also a set of tests and environment checks run against the setup to ensure a healthy state of the entire set of applications.
In the current age of rapid development and continuous upgrade of services, there is a need for safe yet dynamic code deployment. From such requirements emerged a paradigm known as continuous deployment. In few words, it can be described as a set of processes designed for automatic deployment of new versions of a software on the production environment. To ensure that at every point in time you can deliver a stable application, a set of automated tests and mirror environments are set up and on every environment the same single artefact is promoted.
Having all that in mind we started looking at how we could hack through the Ansible structure to deliver not only automation for a single application but the whole environment with dependencies and customizations.
The challenge was not only a static deployment but deployments which can vary based on supplied arguments and variables. After a little bit of a research we were able to define a structure of nested Ansible roles which are pretty much meta roles consisting of a cascade of lower meta roles which at some point consist of what we call an atomic-roles.
Atomic-roles are the smallest bits of code in which specific tasks are defined. This cascade is built automatically based on variables provided to Ansible by the CI tools. This setup allows our customer’s developers to deploy the exact part of the environment they need for testing making sure that all dependencies for the chosen part are considered.
Looking at how developers and operation teams started working with the concept of nested and atomic-roles we came to the conclusion that we might be able to provide even more flexibility to the Ansible structure.
To achieve this we locked Ansible PlayBooks in a so called “Common” Git repository. “Common” in our case, is a skeleton of default Ansible Plays which, when executed, will deploy a default environment but if customizing parts of the setup is necessary it can be done by editing files in another repository which we call “Dev”.
At the beginning of “Dev” is an exact copy of a “Common” repository but it can be edited and customized according to the requirements. How this plays together is pretty simple: When an operator starts a deployment process via the CI tool, CI first checks out the “Common” repository and in the next step overrides it with the content of the “Dev” repository and triggers the Ansible Playbook binary to start deployment. This approach helped us to bring not only more flexibility to the whole Ansible tool but also secure deployments on near-production environments like integration and pre-production keeping a unified Ansible code base in one place for all environments and at the same time allowing changes in the inventory files.
In the past we have used Saltstack which turned up to be too complicated for managing and implementing it on a level that not only operation teams are able to use it but also developers or even project managers. The simplicity of the Ansible structure, mostly because of YAML, and the readability of PlayBooks gave us an opportunity to engage not only technical employees but also all sorts of non-technical staff. Achieved state is especially beneficial for managers who accept changes to the infrastructure and can easily track differences in the environment setup.
We are thrilled how easy and efficient Ansible really is. We managed to present and demo out first results to our customer within a couple of days. What is also important is that ease of use does not kill flexibility when working with Ansible. As mentioned in the paragraphs above we managed to develop a cascade of roles and an entity which we call an atomic-role. Something which was at least not so easy with other products.
The next step on the journey with Ansible is to implement Ansible Tower within customer premises. An extra layer would help us to manage access control and privileges sets, which currently are divided throughout CI/CD tools like Atlassian Bamboo and BitBucket.
NetworkedAssets is a specialist for software architecture and development located in Berlin and Wrocław. Our technological ecosystem is the JVM on Linux/Unix and our areas of expertise are: Technical processes in large networks, especially integration of data, processes and devices in Operations Support Systems (OSS) for telecommunications and technical process in software development, using the newest techniques like automated testing, continuous delivery in agile development projects.