Most application development lifecycles do not implement a continuous integration and continuous delivery process (CI/CD). The ability to deploy, monitor, or change your application with one step is often the most challenging part of the CI/CD process.
Another important part of CI/CD is summarizing configuration items for your application in one file. So, an application should be deployable with one step and with one configuration file. To help reduce the size and complexity of the configuration file, defaults can be predefined so that they do not need to be included in the configuration file, which is known as “convention over configuration.” These predefined defaults should follow
common sense and best practices.
For example, the configuration file can be as small as two lines: the name and the version of the instance of the application. The configuration of a specific application should be easy to understand because convention is used, and only deviations from convention would need to be understood in a configuration file.
Deployments with various configurations can be automated with a CI/CD framework. Three popular CI technologies are Docker/Coreos, Jenkins/Nexus, and Ansible/AWX. Docker normally focuses on stateless applications and is good for a rapid development and deployment cycle with scalability in the cloud. Jenkins normally focuses on Java and code reuse in an open-source and code-sharing heterogeneous distributed model. If you are running a more traditional stateful application, ansible/AWX might be a great fit, but Ansible is very flexible and can also be used with Docker, Jenkins, and Nexus, as well as other use cases.
The earliest and closest predecessors of Ansible were Puppet and Chef. In our Community, Puppet has been very popular, but many offices are starting to move from Puppet to Ansible. So, if you know of an office that is using Puppet but has not learned about Ansible, chances are that they can benefit from an upgrade.
3 Main Differences between Ansible and Puppet
1. Ansible is Lightweight
There is no master node and clients do not need to be installed. It relies on SSH to do most of the heavy lifting. So, if the device already has SSH installed, Ansible can be used. This makes Ansible particularly popular with networking, since it works with existing network equipment. In contrast, Puppet would require a Puppet client which is not commonly available on things like network equipment. Nevertheless, Puppet has its own communication protocol, so it might be better for some high-leniency connections or other situations. Still, Ansible is very flexible, so if SSH is not stable on the connection, Ansible can be configured to use another connection protocol, but that would be a deviation from the conventional setup.2. Ansible Follows Simple and Concise Syntax
Ansible has a domain-specific language that follows the already well-known and conventional syntax of Yaml and Jinja2.Example Ansible file:
--- - hosts: webservers vars: http_port: 80 remote_user: root tasks: - name: ensure apache is running service: name: httpd state: startedMost people can probably guess what this configuration is doing: ensuring that the service on the webserver is running.
