{"id":53444,"date":"2018-08-15T09:00:27","date_gmt":"2018-08-15T08:00:27","guid":{"rendered":"http:\/\/content.n4stack.io\/?p=53444"},"modified":"2018-09-10T14:46:45","modified_gmt":"2018-09-10T13:46:45","slug":"automating-deployments-ansible-jenkins","status":"publish","type":"post","link":"http:\/\/content.n4stack.io\/2018\/08\/15\/automating-deployments-ansible-jenkins\/","title":{"rendered":"Automating Deployments Using Ansible AWX & Jenkins"},"content":{"rendered":"

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12″]<\/p>\n

Sharing an office with a development team can be a challenge when you are a system administrator, you are always finding yourself doing \u201cquick deploys\u201d or logging into servers to take a look at configuration changes which \u201cdidn\u2019t quite go as planned\u201d.<\/p>\n

As the team I work alongside currently have three projects in flight and each project is made up of three servers, development, staging and production, rather than carry on with giving the development team access to the servers or doing the deployments for them we decided it was time to make a few changes and automate their deployments.<\/p>\n

The first thing we did was to sit down with the developers to document all of their different deployment processes and procedures – while each of the applications they are working on is being developed using the same framework there were slight differences in how each of the applications needed to be deployed.<\/p>\n

Once we had the procedures documented we wrote an Ansible playbook which took everything we had learned and standardised them, we tried to make the tasks in the playbook as re-usable as possible, and everything, when it came to deploying and interacting with the code, was an option which could be toggled per project.<\/p>\n

Now that we had a set of playbooks we discussed how best they could be executed, for the development and staging servers we decided that a webhook triggering an unattended deployment when the corresponding branch was updated the best option, for production we needed something which allowed named individuals to trigger a deployment quickly. The solution we came up with was to deploy Ansible AWX<\/a> and Jenkins<\/a>.<\/p>\n

Jenkins was deployed to intercept the webhook from GitHub<\/a> and then trigger the correct playbook run in Ansible AWX; this covered the unattended development and staging deployments meaning that developers were now in control of their deployments, all they needed to do was commit code to the required branch.<\/p>\n

As you can see from the screen below, using Ansible AWX gave the development team an overview of the jobs which had been executed along with the status;<\/p>\n

\"Ansible<\/p>\n

As Ansible AWX allows role-based access, this was also used as the tool which enabled people, such as the development manager, to manually trigger production deployments without having to have Ansible installed.<\/p>\n

All of this means that the developers no longer need to login to any of the servers to action changes, and more importantly, the only time we have to get involved with a deployment is if there is an error flagged within Ansible AWX.<\/p>\n

[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row][et_pb_column type=”4_4″][et_pb_divider _builder_version=”3.12″ background_color=”#e05206″ color=”#e05206″ height=”1px” \/][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.12″ global_module=”53766″][et_pb_column type=”4_4″][et_pb_team_member global_parent=”53766″ _builder_version=”3.12.2″ name=”Russ McKendrick” position=”Practice Manager (SRE & DevOps)” image_url=”http:\/\/content.n4stack.io\/wp-content\/uploads\/2018\/07\/Russ-McKendrick.png” saved_tabs=”all”]<\/p>\n

Russ heads up the SRE & DevOps team here at N4Stack.<\/p>\n

He’s spent almost 25 years working in IT and related industries and currently works exclusively with Linux.<\/p>\n

When he’s not out buying way too many records, Russ loves to write and has now published six books.<\/p>\n

To find out more about Russ click here<\/a>!<\/p>\n

[\/et_pb_team_member][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":"

Sharing an office with a development team can be a challenge when you are a system administrator, you are always finding yourself doing \u201cquick deploys\u201d or logging into servers to take a look at configuration changes which \u201cdidn\u2019t quite go as planned\u201d. As the team I work alongside currently have three projects in flight and […]<\/p>\n","protected":false},"author":2,"featured_media":53450,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"

Sharing an office with a development team can be a challenge when you are a system administrator, you are always finding yourself doing \u201cquick deploys\u201d or logging into servers to take a look at configuration changes which \u201cdidn\u2019t quite go as planned\u201d.<\/p>

As the team I work alongside currently have three projects in flight and each project is made up of three servers, development, staging and production, rather than carry on with giving the development team access to the servers or doing the deployments for them we decided it was time to make a few changes and automate their deployments.<\/p>

The first thing we did was to sit down with the developers to document all of their different deployment processes and procedures - while each of the applications they are working on is being developed using the same framework there were slight differences in how each of the applications needed to be deployed.<\/p>

Once we had the procedures documented we wrote an Ansible playbook which took everything we had learned and standardised them, we tried to make the tasks in the playbook as re-usable as possible, and everything, when it came to deploying and interacting with the code, was an option which could be toggled per project.<\/p>

Now that we had a set of playbooks we discussed how best they could be executed, for the development and staging servers we decided that a webhook triggering an unattended deployment when the corresponding branch was updated the best option, for production we needed something which allowed named individuals to trigger a deployment quickly. The solution we came up with was to deploy Ansible AWX<\/a> and Jenkins<\/a>.<\/p>

Jenkins was deployed to intercept the webhook from GitHub<\/a> and then trigger the correct playbook run in Ansible AWX; this covered the unattended development and staging deployments meaning that developers were now in control of their deployments, all they needed to do was commit code to the required branch.<\/p>

As you can see from the screen below, using Ansible AWX gave the development team an overview of the jobs which had been executed along with the status;<\/p>

\"Ansible<\/p>

As Ansible AWX allows role-based access, this was also used as the tool which enabled people, such as the development manager, to manually trigger production deployments without having to have Ansible installed.<\/p>

All of this means that the developers no longer need to login to any of the servers to action changes, and more importantly, the only time we have to get involved with a deployment is if there is an error flagged within Ansible AWX.<\/p>","_et_gb_content_width":""},"categories":[3354,485,3355,3356,3106],"tags":[3092,3096,3095,3093,3094],"yst_prominent_words":[3083,3080,3085,1869,1029,3084,3087,418,3082,3081,3088,3089,220,3109,1994,3606,3086,19,97,3090],"_links":{"self":[{"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/posts\/53444"}],"collection":[{"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/comments?post=53444"}],"version-history":[{"count":11,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/posts\/53444\/revisions"}],"predecessor-version":[{"id":54002,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/posts\/53444\/revisions\/54002"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/media\/53450"}],"wp:attachment":[{"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/media?parent=53444"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/categories?post=53444"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/tags?post=53444"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"http:\/\/content.n4stack.io\/wp-json\/wp\/v2\/yst_prominent_words?post=53444"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}