The aim of this post is to demonstrate how to use Ansible for environment provisioning and application deployment in a Continuous Integration/Continuous Delivery (CI/CD) process using a Jenkin
Ansible is a powerful tool for IT automation and can be used in a CI/CD process to provision the target environment and to then deploy the application on it.
Jenkins is a well-known tool for implementing CI/CD. Shell scripts are commonly used for provisioning environments or to deploy apps during the pipeline flow. Although this could work, it is cumbersome to maintain and reuse scripts in the long run.
Useful Links:
Jenkisn UI Console:
Step 1: Install ansible plugin using Manage Jenkins Plugins console
Step 2: Configure the ansible installation configuration in Jenkins “Global Tool Configuration” as shown in below pic.
Note: Path of the ansible installed in Jenkins can be found with the below command.
# which ansible /usr/bin/ansible.
Playbook/ansible commands executed correctly when i gave ‘/usr/bin’ in the “path of ansible executable directory”.
step 3: Configure the Jenkins job.
In build step of Jenkins job, select “Invoke Ansible Playbook” and specify the entries of Ansible installation name, playbook path, inventory file path, host subset pattern and the user to execute the command as shown in the below picture.
Note: In host subset entry to limit the group of servers the playbook executed -do not provide quotes as we do in regular playbook command ‘${group}’ /’hostname’. Just provide ${group} /hostname without quotes. It’s the default behavior for Jenkins-ansible plugin.
Note: You can use vault passwords too.
Read More: Install jenkins using Ansible
Advantages of Using Jenkins
- Most of the complexities associated with running a playbook can be coded away in the Jenkins form and the Execute Shell. This would enable operations staff with little or no experience with Ansible to run playbooks.
- The Jenkins build log is an excellent resource to keep track and audit the changes pushed to a specific environment.
- Jenkins has a good interface to group jobs, tabbed views, that would help with organizing your playbooks. Jenkins also lets you document a job and the parameters on the same form interface. It is more handy to refer to documentation on the form itself than look up for that info in a wiki.
What else is great about using Jenkins to deploy your code? Here’s some quick hits:
- Historical build data: Jenkins stores a record of every deployment. Should a deploy fail, you can see exactly when things broke down and why. Jenkins records everything that happened in a Console Output tab.
- Empower non server admins: Jenkins users can login to Jenkins and kick off manual deployments or jobs at the push of a button. They don’t need to know how to login via ssh or even how to run a single command from the command line.
- Enforce Consistent Workflow: By using Jenkins to deploy your code you also end up enforcing consistent workflow. In our example, drush will revert features on every single deployment. This means that devs can’t be lazy and just switch things in production. Those changes would be lost on the next deploy!
- Status Indicators across projects: The Jenkins dashboard shows a quick overview of all of your jobs. There’s status of the last build, an aggregated “weather report” of the last few builds, last build duration, etc. Super useful.
- Slack Integration: You can easily configure jobs to report statuses back to Slack. We have ours set to report to each project channel when a build begins and when it succeeds or fails. Great visibility for everyone on the project.
 process using a Jenkins.){kind=link}