Depla web applications using Ansistrano

ansistrano.deploy and ansistrano.rollback are Ansible roles designed to control the deployment of applications created in scripting programming languages (for example, PHP, Python, and Ruby). Essentially, this is Capistrano's implementation of Ansible.

Using Ansistrano provides the following benefits:

rollback in seconds (with the role of ansistrano.rollback);
setting up a deployment procedure using event handlers for “before” and “after” critical steps;
optimizing disk space usage by storing a limited number of releases;
choice between SCP, RSYNC, GIT, SVN, HTTP Download or S3 GET deployment strategies (in addition, unarchive use is possible ).

How did Ansistrano come about?

At the beginning was Capistrano , which is a server management automation tool; its current version is number 3. Version 2.0 was created to deploy RoR applications. Using plugins, you could work with non-Rails applications written, for example, in PHP or Python, using different deployment strategies, test environments, and more. And it was good.

Capistrano 2 is a great tool that still works. But it is no longer supported, as the developers have switched to the third version. At the same time, according to the creators of Ansistrano, Capistrano 3 is less flexible and not as powerful, and also does not have the feature set that the previous version had. In addition, other application deployment tools (for example, Ansible) do not stand still and are constantly being improved.

The Ansistrano developers explain the rejection of Capistrano by the lack of support for version 2 and the lack of functionality in v3, as well as by the fact that all the necessary tasks are accomplished with the help of Ansible. Alternatively, it is proposed to look at Fabric and Chef Solo.

By the way, the name of the project - Ansistrano - was obtained by combining Ansible and Capistrano.

Anonymous Ansistrano usage statistics

An additional optional step has recently been added to Ansistrano, which gives developers the opportunity to find out how many people are deploying applications with Ansistrano. Since Ansible Galaxy does not provide statistics on downloads or usage, the authors of Ansistrano claim that this was almost the only way to find out the number of users of the project.

The code for collecting anonymous statistics, see here . In addition, this ~~probe~~ the functionality can be disabled by setting the ansistrano_allow_anonymous_stats setting in all playbuttons to false.

Who uses Ansistrano?

Is Ansistrano ready for use?

Here are some companies that work with Ansistrano:

Installation and Update

To deploy applications with Ansistrano you will need:

Ansible on the central machine;
rsync on target machine (if rsync , git or ansistrano_current_via = rsync deployment strategy is used).

Ansistrano is available via Ansible Galaxy . To start the installation, run:

 $ ansible-galaxy install carlosbuenosvinos.ansistrano-deploy carlosbuenosvinos.ansistrano-rollback

To update Ansistrano, add the --force parameter:

 $ ansible-galaxy install --force carlosbuenosvinos.ansistrano-deploy carlosbuenosvinos.ansistrano-rollback

The main scheme of work

Deploying applications with Ansistrano follows the same pattern as Capistrano.

Setup: creates a directory structure for storing releases.
Code Update: Download release to target machines.
Link Update (Symlink): After deploying a new release on target machines, the current link is set to the new release.
Cleaning (Cleanup): taking into account the parameter ansistrano_keep_releases , old versions are removed (see “Role Variables”).

Variable roles

The following is a list of Ansistrano variables for reference.

List of role variables

 - vars: ansistrano_deploy_from: "{{ playbook_dir }}" #   (   ). ansistrano_deploy_to: "/var/www/my-app" #   . ansistrano_version_dir: "releases" #    . ansistrano_current_dir: "current" #     ,  . ansistrano_current_via: "symlink" #     "current". : "symlink"  "rsync". ansistrano_shared_paths: [] #        . ansistrano_shared_files: [] #        . ansistrano_keep_releases: 0 # ,   . . «  ». ansistrano_deploy_via: "rsync" #     . : "copy", "rsync", "git", "svn", "s3"  "download".  "copy", "download"  "s3"    (unarchive)   (  "_unarchive").        *tasks/update-code*. ansistrano_allow_anonymous_stats: yes # ,     "rsync" ansistrano_rsync_extra_params: "" #  ,        rsync  .  Ansible   ,         "--include". .     https://github.com/ansistrano/deploy/commit/e98942dc969d4e620313f00f003a7ea2eab67e86 ansistrano_rsync_set_remote_user: yes # . [ansible synchronize module](http://docs.ansible.com/ansible/synchronize_module.html). : "yes", "no". # ,     Git ansistrano_git_repo: git@github.com:USERNAME/REPO.git #   git. ansistrano_git_branch: master #    .     40-  SHA-1,  HEAD,      (tag name). ansistrano_git_repo_tree: "" #    (subtree)   . ansistrano_git_identity_key_path: "" #  ,             git,    ,   . # ,     SVN #  :  Ansible 1.8.x     subversion (https://github.com/ansible/ansible-modules-core/issues/370),        Ansible 1.9. ansistrano_svn_repo: "https://svn.company.com/project" #   svn ansistrano_svn_branch: "trunk" #    . ansistrano_svn_revision: "HEAD" #    . ansistrano_svn_username: "user" # SVN authentication username ansistrano_svn_password: "Pa$$word" # SVN authentication password # ,     download ansistrano_get_url: https://github.com/someproject/somearchive.tar.gz # ,     S3 ansistrano_s3_bucket: s3bucket ansistrano_s3_object: s3object.tgz #   _unarchive  ansistrano_deploy_via,      (, s3_unarchive) ansistrano_s3_region: eu-west-1 ansistrano_s3_rgw: false #   Ansible >= 2.2,  Ceph RGW (   "true",  ansistrano_s3_region) ansistrano_s3_url: http://rgw.example.com #   Ceph RGW  url #  ,     ansistrano_s3_aws_access_key: YOUR_AWS_ACCESS_KEY ansistrano_s3_aws_secret_key: YOUR_AWS_SECRET_KEY # Hooks: (     ) ansistrano_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-setup-tasks.yml" ansistrano_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-setup-tasks.yml" ansistrano_before_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-update-code-tasks.yml" ansistrano_after_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-update-code-tasks.yml" ansistrano_before_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-shared-tasks.yml" ansistrano_after_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-shared-tasks.yml" ansistrano_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-tasks.yml" ansistrano_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-tasks.yml" ansistrano_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-cleanup-tasks.yml" ansistrano_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-cleanup-tasks.yml"

{{ playbook_dir }} - Ansible variable, which stores the path to the current playbook.

Deployment

To deploy with Ansistrano, take a few steps.

Create a new hosts . For questions, see the Ansible Inventory documentation . The target machines will be listed in this file.
Create a new playbook to deploy the application (for example, deploy.yml ).
Configure variable roles.
Include the role of carlosbuenosvinos.ansistrano-deploy in the script (play).
Start the playbook.

 ansible-playbook -i hosts deploy.yml

If everything was configured correctly, this command will create approximately the following directory structure on the server. Check out what the hosts directory will look like after one, two and three deployments.

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100509145325 |-- releases | |-- 20100509145325 |-- shared

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100509150741 |-- releases | |-- 20100509150741 | |-- 20100509145325 |-- shared

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100512131539 |-- releases | |-- 20100512131539 | |-- 20100509150741 | |-- 20100509145325 |-- shared

Sequential deployments

To prevent different timestamps from being deployed to multiple servers using the serial option, set the variable ansistrano_release_version .

 ansible-playbook -i hosts -e "ansistrano_release_version=`date -u +%Y%m%d%H%M%SZ`" deploy.yml

Rollback

To roll back with Ansistrano, you must configure the deployment and perform a rollback playbook.

 ansible-playbook -i hosts rollback.yml

If you try to rollback with the number of deployed releases equal to 1 or 0, the system will generate an error; no action will be performed.

In a rollback scenario, compared to a deployment, there are far fewer custom variables:

 - vars: ansistrano_deploy_to: "/var/www/my-app" #   . ansistrano_version_dir: "releases" #    . ansistrano_current_dir: "current" #     ,  . # Hooks: (     ) ansistrano_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-tasks.yml" ansistrano_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-tasks.yml" ansistrano_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-cleanup-tasks.yml" ansistrano_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-cleanup-tasks.yml"

Multistage environments (devel, preprod, prod, etc.)

When deploying to different environments (for example, devel , preprod and prod ), it is recommended to create different hosts files for them. The same playbook can be launched for different hosts files using the -i parameter. In each of these files, you can specify different data (usernames, passwords, connection settings, etc.).

 ansible-playbook -i hosts_devel deploy.yml ansible-playbook -i hosts_preprod deploy.yml ansible-playbook -i hosts_prod deploy.yml

Hooks: custom tasks

After the Symlink step, it is usually necessary to restart the server, or download dependencies before Code update , or even do it in production before Symlink . So, to perform custom tasks, you need handlers (hooks) that Ansistrano will perform before or after each of the 3 basic steps.

 -- /my-local-machine/my-app.com |-- hosts |-- deploy.yml |-- my-custom-tasks | |-- before-code-update.yml | |-- after-code-update.yml | |-- before-symlink.yml | |-- after-symlink.yml | |-- before-cleanup.yml | |-- after-cleanup.yml

For example, to restart Apache after the after-symlink.yml step, add the following lines to after-symlink.yml :

 - name: Restart Apache service: name=httpd state=reloaded

How to add mail notification of deployment completion or clear the cache? Very simple! Using the variables of the role ansistrano_before_*_tasks_file and ansistrano_after_*_tasks_file you can specify a file with custom tasks for the “before” and “after” points of each step.

Variables in custom tasks

When writing custom task files, you may need some variables that are available in Ansistrano:

{{ ansistrano_release_path.stdout }} : the path to the current release for deployment (this is probably the most needed variable);
{{ ansistrano_releases_path.stdout }} : path to the directory with releases;
{{ ansistrano_shared_path.stdout }} : path to the shared folder (where files common to all releases can be stored);
{{ ansistrano_release_version }} : relative name of the directory with the release (default is the current timestamp in the UTC zone).

Remove old releases

In environments where Continuous delivery is applied, many releases are usually put into commercial operation. Those lucky ones who may have an excess of free space on disks may not see this as a problem, but it’s common practice to store only a limited number of releases.

To remove old releases after deployment, write to the variable ansistrano_keep_releases amount you want to keep.

Let's take a look at how Ansistrano will behave when deploying three releases and ansistrano_keep_releases: 2 :

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100509145325 |-- releases | |-- 20100509145325 |-- shared

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100509150741 |-- releases | |-- 20100509150741 | |-- 20100509145325 |-- shared

 -- /var/www/my-app.com |-- current -> /var/www/my-app.com/releases/20100512131539 |-- releases | |-- 20100512131539 | |-- 20100509150741 |-- shared

Note that the release 20100509145325 been removed.

Example playbook

In the example directory of the Ansistrano repository, you can find a demonstration project that gives an example of deploying a small application.

To run it, you will need Vagrant and Ansistrano roles. For information on working with Vagrant, see https://www.vagrantup.com .

 $ cd example/my-playbook $ vagrant up $ ansible-playbook -i hosts deploy.yml

After executing these commands, the index.html file located in the my-app directory will be deployed to both machines created using Vagrant.

To test a rollback, you need to run deploy.yml at least twice (in order to roll back to something). After that do:

 $ ansible-playbook -i hosts rollback.yml

In the test folder there are more complex examples that use Travis-CI.

Source: https://habr.com/ru/post/317922/

All Articles