Continuous Delivery - not only for containers

Everyone is currently talking about containers and Platform as a Service (PaaS) when it comes to DevOps and Continuous Deployment.

Author: Christian Sanabria

There is talk of packing applications into a container and distributing them automatically across all stages. However, platforms such as security gateways or messaging systems, which are only controlled by deploying configurations, are still available. How can such platforms also be integrated into a modern deployment process with continuous delivery pipelines? The following blog answers exactly this question and shows how you can increase the business value of your application portfolio.

Interfaces

A prerequisite for the integration of platforms into a pipeline is the existence of an interface outside of a graphical user interface. This can be either a classic rest API. But also commands on the command line or the exchange of configuration files fall into this category. These interfaces can be used to import configuration changes. With the integration into a pipeline the graphical user interface should no longer be used or only in support cases.

Example: A web service can be configured on a security gateway via a SOAP interface.

Continuous-Delivery-3.png
Fig. 1: Visualization of a gateway

Abstraction

Now, not every person should have access to such platform interfaces and therefore not every person should have access to the platform directly. With an automation tool such as Ansible from Red Hat, such calls can be made remotely. The calls themselves are abstracted by a specific description language and summarized in scripts. With Ansible, these scripts are called playbooks.

Example: The SOAP interface must not be called directly by developers, so the call is executed remotely using a special Ansible User. The call is abstracted via an Ansible Playbook, which greatly simplifies the handling of request and response. The playbook is created by the platform operation.

Continuous-Delivery-2.png
Fig. 2: Visualization of the use of Ansible and Playbook

Control

The call of such a playbook should be limited and above all monitored, especially in an operation- or safety-critical environment. For this purpose, practically all tool manufacturers have extended functions for companies in their portfolio. Such features include central authentication and authorization, auditing and monitoring, and configuration management. For Ansible, there is Ansible Tower from Red Hat as an example, which offers such enterprise features via a graphical user interface.

Example: The Playbook may only be executed directly by developers in non-production stages. For an execution on the Production Stage, however, an approval is required. For this purpose, roles and rules are defined in Ansible Tower to control access to the individual stages. These roles and rules are also managed and assigned by the platform operation. The configuration for the individual stages is defined by developers.

Continuous-Delivery-1-460x262.png
Fig. 3: Visualization of the Ansible Tower

Orchestration

Ideally, a Playbook via Ansible Tower can be called not only via the graphical interface, but also via a rest API. This API plays the central role in the integration into an existing development and deployment process. Developers, especially in an agile environment, want to control their continuous delivery pipeline using a central tool. Automation tools can be easily integrated into a pipeline tool (e.g. Jenkins) via an API.

Example: When the Web service is released, the Continuous Delivery Pipeline is triggered in Jenkins. The pipeline starts the deployments of the configuration to the individual stages of the security gateway via the Ansible Tower API. Since the Jenkins user has no authorization for the Production Stage, the pipeline waits for approval in Ansible Tower. As soon as the platform operation has given the approval, the Web service is also deployed on the production stage of the security gateway.

Continuous-Delivery-4-460x181.png
Fig. 4: Visualization of the orchestration

Conclusion

Even without containers and PaaS it is possible to introduce DevOps and Continuous Delivery. The effort involved is often high, since many platforms offer their own interfaces without standards and these must first be abstracted in an automation tool. However, once this initial effort has been implemented, the investment is quickly justified.

Developers can continue to use their existing continuous delivery pipelines and focus fully on implementing business features. Platform operators no longer need to manually import configurations on demand, but can focus entirely on the platform.

This shortens the time-to-market of new features and increases quality through automated testing in the pipeline. Both increases business value. On the one hand, business ideas can be published faster, which can lead to a market advantage. On the other hand, the reputation is enhanced by stable software, which can help to win new customers.

ipt supports your company at every step in the implementation of automation and the introduction of continuous delivery pipelines. Starting with the creation of a concept, through the evaluation of suitable tools and the integration of the tools into your existing IT landscape.