ansistrano.deploy

Ansistrano

ansistrano.deploy et ansistrano.rollback sont des rôles Ansible pour gérer facilement le processus de déploiement d'applications scriptées comme PHP, Python et Ruby. C'est un port Ansible pour Capistrano.

Ansistrano

Historique

Capistrano est un outil d'automatisation de serveur distant et il est actuellement en version 3. Version 2.0 a été initialement conçue pour déployer des applications Ruby on Rails. Avec des plugins supplémentaires, vous pouviez déployer des applications non-Rails telles que PHP et Python, avec différentes stratégies de déploiement, environnements, et bien plus encore. J'ai adoré Capistrano v2. Je l'ai beaucoup utilisé. J'ai développé un plugin pour cela.

Capistrano 2 était un excellent outil et il fonctionne toujours très bien. Cependant, il n'est plus maintenu car l'équipe d'origine travaille sur v3. Cette nouvelle version n'a pas le même ensemble de fonctionnalités, donc elle est moins puissante et flexible. De plus, d'autres outils émergents deviennent plus simples à utiliser pour déployer des applications, comme Ansible.

Donc, j'ai décidé d'arrêter d'utiliser Capistrano parce que v2 n'est plus maintenu, v3 n'a pas suffisamment de fonctionnalités, et je peux faire tout ce que Capistrano faisait avec Ansible. Si vous recherchez des alternatives, examinez Fabric ou Chef Solo.

Nom du projet

Ansistrano vient d'Ansible + Capistrano, c'est simple, n'est-ce pas ?

Statistiques anonymes d'utilisation d'Ansistrano

Il y a une étape facultative dans Ansistrano qui envoie une requête HTTP à nos serveurs. Malheureusement, les métriques que nous pouvons obtenir d'Ansible Galaxy sont limitées, donc c'est l'une des rares façons que nous avons de mesurer combien d'utilisateurs actifs nous avons réellement.

Nous utilisons uniquement ces données pour les statistiques d'utilisation, mais si cela vous dérange, vous pouvez désactiver cette étape supplémentaire en réglant ansistrano_allow_anonymous_stats sur false dans vos playbooks.

Qui utilise Ansistrano ?

Ansistrano est-il prêt à être utilisé ? Voici quelques entreprises qui l’utilisent actuellement :

Si vous l'utilisez également, merci de nous le faire savoir via un PR à ce document.

Exigences

Pour déployer vos applications avec Ansistrano, vous aurez besoin de :

Ansible sur votre machine de déploiement
rsync sur la machine cible si vous utilisez l'une des stratégies de déploiement rsync, rsync_direct, ou git, ou si vous utilisez ansistrano_current_via = rsync

Installation

Ansistrano est un rôle Ansible distribué globalement via Ansible Galaxy. Pour installer le rôle Ansistrano, vous pouvez utiliser la commande suivante.

$ ansible-galaxy install ansistrano.deploy ansistrano.rollback

Mise à jour

Si vous souhaitez mettre à jour le rôle, vous devez passer le paramètre --force lors de l'installation. Voici la commande à vérifier :

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

Fonctionnalités

Restauration en quelques secondes (avec le rôle ansistrano.rollback)
Personnalisez votre déploiement avec des hooks avant et après des étapes critiques
Économisez de l'espace disque en gardant un nombre maximum fixe de versions sur vos hôtes
Choisissez entre SCP, RSYNC, GIT, SVN, HG, téléchargement HTTP ou stratégie de déploiement S3 GET (étape de décompression facultative incluse)

Flux de travail principal

Ansistrano déploie des applications suivant le flux de Capistrano.

Phase de configuration : Crée la structure de dossier pour contenir vos versions
Phase de mise à jour du code : Met la nouvelle version sur vos hôtes
Phase de lien symbolique : Après avoir déployé la nouvelle version sur vos hôtes, cette étape change le lien current vers la nouvelle version
Phase de nettoyage : Supprime toute version ancienne en fonction du paramètre ansistrano_keep_releases (voir "Variables de rôle")

Flux Ansistrano

Variables de rôle

vars:
  ansistrano_deploy_from: "{{ playbook_dir }}/" # Où se trouve mon projet local (chemin relatif ou absolu)
  ansistrano_deploy_to: "/var/www/my-app" # Chemin de base pour le déploiement
  ansistrano_version_dir: "releases" # Nom du dossier des versions
  ansistrano_shared_dir: "shared" # Nom du dossier partagé
  ansistrano_current_dir: "current" # Nom du lien symbolique. Vous devrez rarement le changer.
  ansistrano_current_via: "symlink" # Stratégie de déploiement qui indique où le code doit être déployé. Options : symlink ou rsync
  ansistrano_keep_releases: 0 # Versions à garder après un nouveau déploiement. Voir "Pruning des anciennes versions".

  # Tableaux de répertoires et de fichiers à partager.
  # Les tableaux suivants de répertoires et de fichiers seront liés au répertoire de la version actuelle après l'étape 'update-code' et ses rappels
  # Remarques :
  # * Les chemins sont relatifs au dossier partagé (sans / au début)
  # * Si vos éléments se trouvent dans un sous-répertoire, écrivez le chemin complet pour chaque dossier partagé
  #
  # Exemple :
  # ansistrano_shared_paths:
  #   - path/to/first-dir
  #   - path/next-dir
  # ansistrano_shared_files:
  #   - my-file.txt
  #   - path/to/file.txt
  ansistrano_shared_paths: []
  ansistrano_shared_files: []


  # Création de chemins partagés et de fichiers de base.
  # Par défaut, les répertoires de chemins partagés et les répertoires de base pour les fichiers partagés sont créés automatiquement s'ils n'existent pas. Mais dans certains scénarios, ces chemins pourraient être des liens symboliques vers d'autres répertoires dans le système de fichiers, et le processus de déploiement échouerait. Avec ces variables, vous pouvez désactiver les tâches concernées. Si vous avez deux ou trois chemins partagés, et n'avez pas besoin de création pour certains d'entre eux, vous pouvez toujours désactiver la création automatique et ajouter une tâche personnalisée dans un hook.
  ansistrano_ensure_shared_paths_exist: yes
  ansistrano_ensure_basedirs_shared_files_exist: yes
  
  # Stratégie de déploiement - méthode utilisée pour livrer le code. Options : copy, download, git, rsync, rsync_direct, svn, ou s3. 
  ansistrano_deploy_via: rsync 
  # Copy, download et s3 ont une étape facultative pour décompresser le fichier téléchargé qui peut être utilisée en ajoutant _unarchive. 
  # La stratégie rsync_direct omet une copie de fichier sur la cible offrant une légère augmentation de vitesse si vous déployez sur des hôtes partagés, rencontrez des problèmes de performances de fichiers, ou servez des actifs statiques depuis le même hôte que vous déployez et exécutez de nombreuses opérations rsync.
  # Vous pouvez consulter toutes les options dans le dossier tasks/update-code !
  
  ansistrano_allow_anonymous_stats: yes

  # Variables utilisées dans la stratégie de déploiement rsync/rsync_direct
  ansistrano_rsync_extra_params: "" # Paramètres supplémentaires à utiliser lors du déploiement avec rsync dans une seule chaîne. Bien qu’Ansible permette un tableau, cela peut causer des problèmes si nous essayons d’ajouter plusieurs arguments --include comme indiqué dans https://github.com/ansistrano/deploy/commit/e98942dc969d4e620313f00f003a7ea2eab67e86
  ansistrano_rsync_set_remote_user: yes # Voir [module de synchronisation ansible](http://docs.ansible.com/ansible/synchronize_module.html). Options : yes, no.
  ansistrano_rsync_path: "" # Voir [module de synchronisation ansible](http://docs.ansible.com/ansible/synchronize_module.html). Par défaut c'est "sudo rsync", cela peut être remplacé par (exemple) : "sudo -u user rsync".
  ansistrano_rsync_use_ssh_args: no # Voir [module de synchronisation ansible](http://docs.ansible.com/ansible/synchronize_module.html). Si réglé sur yes, utilisez les ssh_args spécifiés dans ansible.cfg.

  # Variables utilisées dans la stratégie de déploiement Git
  ansistrano_git_repo: [email protected]:USERNAME/REPO.git # Emplacement du dépôt git
  ansistrano_git_branch: master # Quelle version du dépôt vérifier. Cela peut être le hash SHA-1 de 40 caractères, la chaîne littérale HEAD, un nom de branche, ou un nom de balise
  ansistrano_git_repo_tree: "" # Si spécifié, la sous-arborescence du dépôt à déployer
  ansistrano_git_identity_key_path: "" # Si spécifié, ce fichier est copié et utilisé comme clé d'identité pour les commandes git, le chemin est relatif au playbook dans lequel il est utilisé
  ansistrano_git_identity_key_remote_path: "" # Si spécifié, ce fichier sur le serveur distant est utilisé comme clé d'identité pour les commandes git, le chemin distant est absolu
  ansistrano_git_identity_key_shred: true # Détruire la clé d'identité par défaut mais peut être remplacée par false si vous rencontrez le problème suivant (https://github.com/ansistrano/deploy/issues/357)
  # Variables optionnelles, omises par défaut
  ansistrano_git_refspec: ADDITIONAL_GIT_REFSPEC # RefSpec supplémentaire à utiliser par le module 'git'. Utilise la même syntaxe que la commande 'git fetch'.
  ansistrano_git_ssh_opts: "-o StrictHostKeyChecking=no" # Options ssh supplémentaires à utiliser dans Git
  ansistrano_git_depth: 1 # Historique supplémentaire tronqué au nombre spécifié de révisions
  ansistrano_git_executable: /opt/local/bin/git # Chemin vers l'exécutable git à utiliser. S'il n'est pas fourni, le mécanisme normal pour résoudre les chemins d'accès aux binaires sera utilisé.

  # Variables utilisées dans la stratégie de déploiement SVN
  # Veuillez noter qu'il y avait un bogue dans le module subversion dans la série Ansible 1.8.x (https://github.com/ansible/ansible-modules-core/issues/370) donc il n'est pris en charge qu'à partir de Ansible 1.9
  ansistrano_svn_repo: https://svn.company.com/project # Emplacement du dépôt svn
  ansistrano_svn_branch: trunk # Quelle branche du dépôt vérifier.
  ansistrano_svn_revision: HEAD # Quelle révision du dépôt vérifier.
  ansistrano_svn_username: user # Nom d'utilisateur d'authentification SVN
  ansistrano_svn_password: Pa$$word # Mot de passe d'authentification SVN
  ansistrano_svn_environment: {} # Dictionnaire avec des variables d'environnement pour les tâches svn (https://docs.ansible.com/ansible/playbooks_environment.html)

  # Variables utilisées dans la stratégie de déploiement HG
  ansistrano_hg_repo: https://[email protected]/USERNAME/REPO # Emplacement du dépôt hg
  ansistrano_hg_branch: default # Tout identifiant de branche qui fonctionne avec hg -r, donc nom de branche, marque-page, hash de commit...

  # Variables utilisées dans la stratégie de déploiement de téléchargement
  ansistrano_get_url: https://github.com/someproject/somearchive.tar.gz
  ansistrano_download_force_basic_auth: false # pas de valeur par défaut car cela n'est pris en charge qu'à partir d'Ansible 2.0
  ansistrano_download_headers: "" # pas de valeur par défaut car cela n'est pris en charge qu'à partir d'Ansible 2.0

  # Variables utilisées dans la stratégie de déploiement S3
  ansistrano_s3_bucket: s3bucket
  ansistrano_s3_object: s3object.tgz # Ajoutez le suffixe _unarchive à l'ansistrano_deploy_via si votre objet est un package (c'est-à-dire : s3_unarchive)
  ansistrano_s3_region: eu-west-1
  ansistrano_s3_rgw: false # doit être Ansible >= 2.2. utiliser Ceph RGW pour les fournisseurs de cloud compatibles S3
  ansistrano_s3_url: http://rgw.example.com # lorsque vous utilisez Ceph RGW, définissez l'url
  # Variables optionnelles, omises par défaut
  ansistrano_s3_aws_access_key: VOTRE_CLE_DACCES_AWS
  ansistrano_s3_aws_secret_key: VOTRE_CLE_SECRETE_AWS
  ansistrano_s3_ignore_nonexistent_bucket: false
  
  # Variables utilisées dans la stratégie de déploiement GCS
  ansistrano_gcs_bucket: gcsbucket
  ansistrano_gcs_object: gcsobject.tgz # Ajoutez le suffixe _unarchive à l'ansistrano_deploy_via si votre objet est un package (c'est-à-dire : s3_unarchive)
  ansistrano_gcs_region: eu-west-1 # https://cloud.google.com/storage/docs/bucket-locations
  # Variables optionnelles, omises par défaut
  ansistrano_gcs_access_key: VOTRE_CLE_DACCES_GCS # accédez à la console Cloud > Stockage > Paramètres > Interopérabilité
  ansistrano_gcs_secret_key: VOTRE_CLE_SECRETE_GCS

  # Hooks : tâches personnalisées si vous en avez besoin
  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 }} est une variable Ansible qui contient le chemin vers le playbook actuel.

Déploiement

Pour déployer avec Ansistrano, vous devez effectuer certaines étapes :

Créez un nouveau fichier hosts. Consultez la documentation sur l'inventaire d'ansible si vous avez besoin d'aide. Ce fichier identifiera tous les hôtes où déployer. Pour des environnements multistages, consultez Environnements multistages.
Créez un nouveau playbook pour déployer votre application, par exemple, deploy.yml
Configurez les variables de rôle (voir Variables de rôle)
Incluez le rôle ansistrano.deploy comme partie d'un play
Exécutez le playbook de déploiement

ansible-playbook -i hosts deploy.yml

Si tout a été correctement configuré, cette commande créera la structure de répertoire approximative suivante sur votre serveur. Vérifiez comment la structure de dossiers des hôtes apparaîtrait après un, deux et trois déploiements.

-- /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

Déploiements en série

Pour éviter les horodatages différents lors du déploiement sur plusieurs serveurs utilisant l’option serial, vous devez définir la variable ansistrano_release_version.

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

Restauration

Pour restaurer avec Ansistrano, vous devez configurer le déploiement et exécuter le playbook de restauration.

ansible-playbook -i hosts rollback.yml

Si vous essayez de revenir avec zéro ou une version déployée, une erreur sera levée et aucune action ne sera effectuée.

Les variables que vous pouvez ajuster dans le rôle de restauration sont moins nombreuses que dans celui de déploiement :

vars:
  ansistrano_deploy_to: "/var/www/my-app" # Chemin de base pour le déploiement
  ansistrano_version_dir: "releases" # Nom du dossier des versions
  ansistrano_current_dir: "current" # Nom du lien symbolique. Vous devrez rarement le changer.
  ansistrano_rollback_to_release: "" # Si spécifié, l'application sera restaurée à cette version ; sinon, elle reviendra à la version précédente.
  ansistrano_remove_rolled_back: yes # Vous pouvez changer ce paramètre pour garder la version restaurée sur le serveur pour une inspection ultérieure
  ansistrano_allow_anonymous_stats: yes

  # Hooks : tâches personnalisées si vous en avez besoin
  ansistrano_rollback_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-setup-tasks.yml"
  ansistrano_rollback_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-setup-tasks.yml"
  ansistrano_rollback_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-symlink-tasks.yml"
  ansistrano_rollback_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-symlink-tasks.yml"
  ansistrano_rollback_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-before-cleanup-tasks.yml"
  ansistrano_rollback_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-rollback-after-cleanup-tasks.yml"

Environnements multistages (développement, préproduction, production, etc.)

Si vous souhaitez déployer sur différents environnements tels que développement, préproduction et production, il est recommandé de créer différents fichiers d'hôtes. Une fois cela fait, vous pouvez spécifier un fichier d'hôte différent lors de l'exécution du playbook de déploiement en utilisant le paramètre -i. Dans chaque fichier d'hôtes, vous pouvez spécifier des utilisateurs, mots de passe, paramètres de connexion différents, etc.

ansible-playbook -i hosts_devel deploy.yml

ansible-playbook -i hosts_preprod deploy.yml

ansible-playbook -i hosts_prod deploy.yml

Hooks : Tâches personnalisées

Vous aurez typiquement besoin de recharger votre serveur web après l'étape Symlink, ou de télécharger vos dépendances avant Code update ou même de le faire en production avant le Symlink. Donc, pour effectuer vos tâches personnalisées, vous avez quelques hooks qu'Ansistrano exécutera avant et après chacune des trois étapes principales. C'est le principal avantage par rapport à d'autres rôles de déploiement similaires.

-- /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

Par exemple, pour redémarrer Apache après l'étape Symlink, nous ajouterons dans after-symlink.yml

- name: Redémarrer Apache
  service: name=httpd state=reloaded

Q : Où ajouteriez-vous l'envoi d'une notification par e-mail après un déploiement ?
Q : (pour les développeurs PHP et Symfony) Où nettoieriez-vous le cache ?

Vous pouvez spécifier un fichier de tâches personnalisées pour avant et après chaque étape en utilisant ansistrano_before_*_tasks_file et ansistrano_after_*_tasks_file. Voir "Variables de rôle" pour plus d'informations.

Variables dans les tâches personnalisées

Lorsque vous écrivez vos fichiers de tâches personnalisées, vous aurez peut-être besoin de certaines variables qu'Ansistrano met à votre disposition :

{{ ansistrano_release_path.stdout }} : Chemin vers la version actuelle de déploiement (probablement celui que vous utiliserez le plus)
{{ ansistrano_releases_path }} : Chemin vers le dossier des versions
{{ ansistrano_shared_path }} : Chemin vers le dossier partagé (où des actifs communs aux versions peuvent être stockés)
{{ ansistrano_release_version }} : Nom de répertoire relatif pour la version (par défaut égale à l'horodatage actuel en UTC)

Pruning des anciennes versions

Dans les environnements de livraison continue, il se peut que vous ayez un grand nombre de versions en production. Peut-être que vous avez beaucoup d'espace et que cela ne vous dérange pas, mais il est d'usage de garder juste un nombre personnalisé de versions.

Après le déploiement, si vous souhaitez supprimer les anciennes versions, définissez simplement la variable ansistrano_keep_releases au nombre total de versions que vous souhaitez conserver.

Voyons trois déploiements avec une configuration 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

Voyez comment la version 20100509145325 a été supprimée.

Exemple de Playbook

Dans le dossier example, vous pouvez consulter un projet d'exemple qui montre comment déployer une petite application avec Ansistrano.

Pour l'exécuter, vous devrez avoir Vagrant et les rôles ansistrano installés. Veuillez consulter https://www.vagrantup.com pour plus d'informations sur Vagrant et notre section d'installation.

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

Après avoir exécuté ces commandes, le fichier index.html situé dans le dossier my-app sera déployé sur les deux boîtes vagrant.

Pour tester le playbook de restauration, vous devrez exécuter deploy.yml au moins deux fois (de sorte qu'il y ait quelque chose à restaurer). Une fois cela fait, il vous suffit d'exécuter

$ ansible-playbook -i hosts rollback.yml

Vous pouvez consulter des exemples plus avancés dans le dossier test qui sont exécutés contre Travis-CI.

Projets d'exemple

Nous avons ajouté le support d'Ansistrano pour d'autres projets sur lesquels nous travaillons.

LastWishes : Application d'exemple PHP basée sur le design axé sur le domaine : https://github.com/dddinphp/last-wishes

À titre d'exemple, voyez le journal d'exécution du déploiement de LastWishes :

PLAY [Déployer l'application last wishes sur mon serveur] ************************************

RÉUNIFICATION DES FAITS ***************************************************************
ok: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Assurez-vous que le chemin de déploiement de base existe] ***
ok: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Assurez-vous que le dossier des versions existe] ***
ok: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Assurez-vous que le dossier des éléments partagés existe] ***
ok: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Obtenir l'horodatage de version] ***********
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Obtenir le chemin de la version] ****************
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Obtenir le chemin des versions] ***************
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Obtenir le chemin partagé (dans le cas de rsync)] ***
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Rsync des fichiers d'application vers une copie distante (dans le cas de rsync)] ***
changed: [quepimquepam.com -> 127.0.0.1]

TÂCHE : [ansistrano.deploy | Déployer le code existant sur les serveurs] ***
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Déployer le code existant sur les serveurs distants] ***
skipping: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Mettre à jour le dépôt distant] ********
skipping: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Exporter une copie du dépôt] *******
skipping: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Déployer le code sur les serveurs] *****
skipping: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Copier la version de déploiement dans le fichier REVISION] ***
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Finaliser le code de la version] *****
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Changer le lien symbolique vers la nouvelle version] ***
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Recharger Apache] *******************
changed: [quepimquepam.com]

TÂCHE : [ansistrano.deploy | Nettoyer les versions] ***************
skipping: [quepimquepam.com]

RAPPORT FINAL ********************************************************************
quepimquepam.com           : ok=14   changed=10   unreachable=0    failed=0