One of the great benefits of using Ansible to manage services is that you can easily make changes to your code and quickly push the change. In some situations where you have a big fleet of services managed by Ansible, you may wish to push out a change just to a single host to make sure things are how you expect them to be. This is often called canary testing. With Ansible, doing that is really easy. To illustrate that, we are going open the file roles/helloworld/files/helloworld.js and then simply change the response on Line 11 from Hello World to Hello New World:

    // Send the response body as "Hello World" 
    response.end('Hello New World
'); 
}).listen(3000); 

Save the file. Then run ansible-playbook again, first with the --check option:

$ ansible-playbook helloworld.yml 
      --private-key ~/.ssh/EffectiveDevOpsAWS.pem 
      -e target=54.175.86.38 
      --check  

This time Ansible detects only two changes. The first one overwrites the application file and the second one executes the notify statement, which means restarting the application. Seeing that it is what we expect, we can run our playbook without the --check options:

$ ansible-playbook helloworld.yml 
      --private-key ~/.ssh/EffectiveDevOpsAWS.pem 
      -e target=54.175.86.38  

This produces the same output as in our previous command but this time the change is in effect:

$ curl 54.175.86.38:3000
Hello New World  

Our change was very simple but if we had done that same change by updating our CloudFormation template, CloudFormation would have had to create a new EC2 instance to make it happen. Here we simply updated the code of the application and pushed it through Ansible on the target host.

We will now revert this change locally in Git:

$ git checkout roles/helloworld/files/helloworld.js  

We will remove it from the EC2 instance as we illustrate a new concept, running Ansible asynchronously.