Il n'y a pas si longtemps, j'avais besoin d'écrire des playbooks ansibles pour préparer le serveur au déploiement de l'application rails. Et, étonnamment, je n'ai pas trouvé de manuel pas à pas simple. Je ne voulais pas copier le livre de jeu de quelqu'un d'autre sans comprendre ce qui se passait et, par conséquent, j'ai dû lire la documentation, rassemblant tout moi-même. Peut-être que quelqu'un que je peux aider à accélérer ce processus avec cet article.
La première chose à comprendre est qu'ansible vous fournit une interface pratique pour effectuer une liste prédéfinie d'actions sur le ou les serveurs distants via SSH. Il n'y a pas de magie ici, vous ne pouvez pas installer le plugin et sortir de la boîte zéro temps d'arrêt un déploiement de votre application avec docker, surveillance et autres goodies. Pour écrire un livre de jeu, vous devez savoir exactement ce que vous voulez faire et comment le faire. Par conséquent, je n'aime pas les playbooks prêts à l'emploi du github, ni les articles comme: "Copiez et exécutez, cela fonctionnera."
De quoi avons-nous besoin?
Comme je l'ai dit, pour écrire un livre de jeu, vous devez savoir ce que vous voulez faire et comment le faire. Décidons ce dont nous avons besoin. Pour une application Rails, nous aurons besoin de plusieurs packages système: nginx, postgresql (redis, etc.). En plus de cela, nous avons besoin de rubis d'une certaine version. Il est préférable de l'installer via rbenv (rvm, asdf ...). Exécuter tout cela à partir de la racine de l'utilisateur est toujours une mauvaise idée, vous devez donc créer un utilisateur distinct et configurer les droits pour lui. Après cela, vous devez télécharger notre code sur le serveur, copier les configurations pour nginx, postgres, etc. et exécuter tous ces services.
En conséquence, la séquence d'actions est la suivante:
- Connectez-vous en tant que root
- installer des packages système
- créer un nouvel utilisateur, configurer les droits, clé ssh
- configurer les packages système (nginx, etc.) et les exécuter
- Créer un utilisateur dans la base de données (vous pouvez immédiatement créer une base de données)
- Connectez-vous en tant que nouvel utilisateur
- Installer rbenv et ruby
- Installer le bundler
- Remplissez le code d'application
- Nous démarrons le serveur Puma
De plus, les dernières étapes peuvent être effectuées à l'aide de capistrano, au moins elle peut copier le code dans les répertoires de version à partir de la boîte, basculer la version avec un lien symbolique sur un déploiement réussi, copier les configurations depuis le répertoire partagé, redémarrer puma, etc. Tout cela peut être fait avec Ansible, mais pourquoi?
Structure des fichiers
Ansible a une structure de fichiers stricte pour tous ses fichiers, il est donc préférable de tout conserver dans un répertoire séparé. Et ce n'est pas si important que ce soit dans l'application de rails elle-même, ou séparément. Vous pouvez stocker des fichiers dans un référentiel git séparé. Personnellement, il était plus pratique pour moi de créer le répertoire ansible dans / config du répertoire rails de l'application et de tout stocker dans un référentiel.
Playbook simple
Playbook est un fichier yml qui décrit ce que et comment ansible doit faire en utilisant une syntaxe spéciale. Créons le premier playbook qui ne fait rien:
--- - name: Simple playbook hosts: all
Ici, nous disons simplement que notre playbook s'appelle Simple Playbook et que son contenu devrait fonctionner pour tous les hôtes. Nous pouvons l'enregistrer dans le répertoire / ansible avec le nom playbook.yml et essayer d'exécuter:
ansible-playbook ./playbook.yml PLAY [Simple Playbook] ************************************************************************************************************************************ skipping: no hosts matched
Ansible dit qu'il ne connaît pas les hôtes qui correspondent à la liste de tous. Ils doivent être répertoriés dans un fichier d'inventaire spécial.
Créons-le dans le même répertoire ansible:
123.123.123.123
Il vous suffit donc de spécifier l'hôte (idéalement, l'hôte de votre VPS pour les tests, ou vous pouvez enregistrer localhost) et l'enregistrer sous l' inventory noms.
Vous pouvez essayer d'exécuter ansible avec un fichier d'inversion:
ansible-playbook ./playbook.yml -i inventory PLAY [Simple Playbook] ************************************************************************************************************************************ TASK [Gathering Facts] ************************************************************************************************************************************ PLAY RECAP ************************************************************************************************************************************
Si vous avez accès ssh à l'hôte spécifié, ansible se connectera et collectera des informations sur le système distant. (tâche par défaut [Gathering Facts]), après quoi il fera un bref rapport d'étape (PLAY RECAP).
Par défaut, le nom d'utilisateur sous lequel vous êtes connecté au système est utilisé pour la connexion. Il ne sera probablement pas sur l'hôte. Dans le fichier playbook, vous pouvez spécifier l'utilisateur à utiliser pour se connecter à l'aide de la directive remote_user. De plus, les informations sur un système distant peuvent souvent être inutiles pour vous et vous ne devriez pas perdre de temps à les collecter. Vous pouvez également désactiver cette tâche:
--- - name: Simple playbook hosts: all remote_user: root become: true gather_facts: no
Essayez de relancer le playbook et assurez-vous que la connexion fonctionne. (Si vous avez spécifié la racine de l'utilisateur, vous devez également spécifier la directive devient: vrai pour obtenir des droits élevés. Comme le dit la documentation: become set to 'true'/'yes' to activate privilege escalation. Bien qu'il ne soit pas clair pourquoi) .
Peut-être que vous obtenez une erreur causée par l'ansible que l'interpréteur python ne peut pas déterminer, vous pouvez alors la spécifier manuellement:
ansible_python_interpreter: /usr/bin/python3
où vous avez python peut être trouvé avec la commande whereis python .
Installer des packages système
Ansible est livré avec de nombreux modules pour travailler avec divers packages système, nous n'avons donc pas à écrire de scripts bash pour une raison quelconque. Maintenant, nous avons besoin de l'un de ces modules pour mettre à jour le système et installer les packages système. J'ai Ubuntu Linux sur VPS, respectivement, pour installer des paquets, j'utilise apt-get et un module pour cela . Si vous utilisez un système d'exploitation différent, vous aurez peut-être besoin d'un module différent (rappelez-vous, j'ai dit au début que nous devons savoir à l'avance quoi et comment nous allons faire). Cependant, la syntaxe est probablement similaire.
Nous complétons notre playbook avec les premières tâches:
--- - name: Simple playbook hosts: all remote_user: root become: true gather_facts: no tasks: - name: Update system apt: update_cache=yes - name: Install system dependencies apt: name: git,nginx,redis,postgresql,postgresql-contrib state: present
La tâche est juste la tâche qu'ansible effectuera sur des serveurs distants. Nous donnons un nom à la tâche pour suivre sa progression dans le journal. Et nous décrivons, en utilisant la syntaxe d'un module spécifique, ce qu'il doit faire. Dans ce cas, apt: update_cache=yes - indique mettre à jour les packages système à l'aide du module apt. La deuxième équipe est un peu plus compliquée. Nous passons la liste des packages au module apt, et disons que leur state devrait devenir present , c'est-à-dire que nous disons d'installer ces packages. De même, nous pouvons leur dire d'être supprimés ou mis à jour, simplement en changeant d' state . Veuillez noter que pour que les rails fonctionnent avec postgresql, nous avons besoin du package postgresql-contrib que nous installons actuellement. Cela doit encore une fois être connu et fait, ansible en soi ne le fera pas.
Essayez de réexécuter le playbook et vérifiez que les packages sont installés.
Création de nouveaux utilisateurs.
Pour travailler avec les utilisateurs, Ansible dispose également d'un module - utilisateur. Ajoutez une autre tâche (j'ai caché les parties déjà connues du playbook derrière les commentaires, afin de ne pas le copier entièrement à chaque fois):
--- - name: Simple playbook # ... tasks: # ... - name: Add a new user user: name: my_user shell: /bin/bash password: "{{ 123qweasd | password_hash('sha512') }}"
Nous créons un nouvel utilisateur, lui définissons un schell et un mot de passe. Et puis nous sommes confrontés à plusieurs problèmes. Que faire si les noms d'utilisateur doivent être différents pour différents hôtes? Oui, et garder le mot de passe ouvert dans le playbook est une très mauvaise idée. Pour commencer, nous allons mettre le nom d'utilisateur et le mot de passe dans des variables, et vers la fin de l'article, je montrerai comment crypter le mot de passe.
--- - name: Simple playbook # ... tasks: # ... - name: Add a new user user: name: "{{ user }}" shell: /bin/bash password: "{{ user_password | password_hash('sha512') }}"
Les variables sont définies à l'aide de crochets doubles dans les livres de lecture.
Nous indiquerons les valeurs des variables dans le fichier d'inventaire:
123.123.123.123 [all:vars] user=my_user user_password=123qweasd
Faites attention à la directive [all:vars] - elle dit que le prochain bloc de texte est des variables (vars) et elles sont applicables à tous les hôtes (tous).
La construction de "{{ user_password | password_hash('sha512') }}" également intéressante. Le fait est qu'ansible ne définit pas l'utilisateur via user_add comme vous le feriez manuellement. Et il enregistre toutes les données directement, c'est pourquoi nous devons également convertir le mot de passe en hachage à l'avance, ce que fait cette commande.
Ajoutons notre utilisateur au groupe sudo. Cependant, avant cela, vous devez vous assurer qu'un tel groupe existe, car personne ne le fera pour nous:
--- - name: Simple playbook # ... tasks: # ... - name: Ensure a 'sudo' group group: name: sudo state: present - name: Add a new user user: name: "{{ user }}" shell: /bin/bash password: "{{ user_password | password_hash('sha512') }}" groups: "sudo"
C'est assez simple, nous avons également un module de groupe pour créer des groupes, avec une syntaxe très similaire à apt. Il suffit ensuite d'enregistrer ce groupe auprès de l'utilisateur ( groups: "sudo" ).
Il est également utile d'ajouter une clé ssh à cet utilisateur afin que nous puissions nous connecter sans mot de passe:
--- - name: Simple playbook # ... tasks: # ... - name: Ensure a 'sudo' group group: name: sudo state: present - name: Add a new user user: name: "{{ user }}" shell: /bin/bash password: "{{ user_password | password_hash('sha512') }}" groups: "sudo" - name: Deploy SSH Key authorized_key: user: "{{ user }}" key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" state: present
Dans ce cas, la construction "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" est intéressante - elle copie le contenu du fichier id_rsa.pub (votre nom peut différer), c'est-à-dire la partie publique de la clé ssh et le télécharge dans la liste des clés autorisées pour l'utilisateur sur le serveur.
Rôles
Les trois tâches de création peuvent être facilement utilisées comme un seul groupe de tâches, et il serait bien de garder ce groupe séparé du livre de jeu principal afin qu'il ne se développe pas trop. Il y a des rôles pour cela dans ansible.
Selon la structure de fichiers indiquée au tout début, les rôles doivent être placés dans un répertoire de rôles séparé, pour chaque rôle - un répertoire séparé avec le même nom, à l'intérieur du répertoire des tâches, fichiers, modèles, etc.
Créons la structure du fichier: ./ansible/roles/user/tasks/main.yml (main est le fichier principal qui sera chargé et exécuté lorsque le rôle sera connecté au playbook, d'autres fichiers de rôle pourront y être connectés). Vous pouvez maintenant transférer dans ce fichier toutes les tâches liées à l'utilisateur:
# Create user and add him to groups - name: Ensure a 'sudo' group group: name: sudo state: present - name: Add a new user user: name: "{{ user }}" shell: /bin/bash password: "{{ user_password | password_hash('sha512') }}" groups: "sudo" - name: Deploy SSH Key authorized_key: user: "{{ user }}" key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" state: present
Dans le playbook principal, vous devez spécifier d'utiliser le rôle d'utilisateur:
--- - name: Simple playbook hosts: all remote_user: root gather_facts: no tasks: - name: Update system apt: update_cache=yes - name: Install system dependencies apt: name: git,nginx,redis,postgresql,postgresql-contrib state: present roles: - user
En outre, il peut être judicieux d'effectuer une mise à jour du système avant toutes les autres tâches, pour cela, vous pouvez renommer le bloc de tasks dans lequel elles sont définies dans les pre_tasks .
Configuration de Nginx
Nginx devrait déjà être installé avec nous, vous devez le configurer et l'exécuter. Faisons-le tout de suite dans le rôle. Créez une structure de fichiers:
- ansible - roles - nginx - files - tasks - main.yml - templates
Maintenant, nous avons besoin de fichiers et de modèles. La différence entre les deux est que les fichiers ansible sont copiés directement tels quels. Et les modèles devraient avoir l'extension j2 et ils peuvent utiliser les valeurs des variables en utilisant les mêmes crochets doubles.
main.yml nginx dans le fichier main.yml . Pour cela, nous avons un module systemd:
# Copy nginx configs and start it - name: enable service nginx and start systemd: name: nginx state: started enabled: yes
Ici, nous disons non seulement que nginx doit être démarré (c'est-à-dire l'exécuter), mais nous disons immédiatement qu'il doit être activé.
Copiez maintenant les fichiers de configuration:
# Copy nginx configs and start it - name: enable service nginx and start systemd: name: nginx state: started enabled: yes - name: Copy the nginx.conf copy: src: nginx.conf dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' backup: yes - name: Copy template my_app.conf template: src: my_app_conf.j2 dest: /etc/nginx/sites-available/my_app.conf owner: root group: root mode: '0644'
Nous créons le fichier de configuration principal de nginx (vous pouvez le prendre directement depuis le serveur, ou l'écrire vous-même). Et aussi le fichier de configuration de notre application dans le répertoire sites_available (ce n'est pas nécessaire mais utile). Dans le premier cas, nous utilisons le module de copie pour copier des fichiers (le fichier doit être dans /ansible/roles/nginx/files/nginx.conf ). Dans le second - copiez le modèle, en remplaçant les valeurs des variables. Le modèle doit être dans /ansible/roles/nginx/templates/my_app.j2 ). Et cela peut ressembler à ceci:
upstream {{ app_name }} { server unix:{{ app_path }}/shared/tmp/sockets/puma.sock; } server { listen 80; server_name {{ server_name }} {{ inventory_hostname }}; root {{ app_path }}/current/public; try_files $uri/index.html $uri.html $uri @{{ app_name }}; .... }
Faites attention aux insertions {{ app_name }} , {{ app_path }} , {{ server_name }} , {{ inventory_hostname }} - ce sont toutes des variables dont les valeurs ansible se substitueront dans le modèle avant de copier. Ceci est utile si vous utilisez Playbook pour différents groupes d'hôtes. Par exemple, nous pouvons compléter notre fichier d'inventaire:
[production] 123.123.123.123 [staging] 231.231.231.231 [all:vars] user=my_user user_password=123qweasd [production:vars] server_name=production app_path=/home/www/my_app app_name=my_app [staging:vars] server_name=staging app_path=/home/www/my_stage app_name=my_stage_app
Si nous exécutons notre playbook maintenant, il effectuera les tâches spécifiées pour les deux hôtes. Mais en même temps, pour l'hôte intermédiaire, les variables différeront de la production, et pas seulement dans les rôles et les playbooks, mais aussi dans les configurations nginx. {{ inventory_hostname }} n'a pas besoin d'être spécifié dans le fichier d'inventaire - il s'agit d'une variable spéciale ansible et l'hôte pour lequel le playbook est en cours d'exécution y est stocké.
Si vous souhaitez avoir un fichier d'inventaire pour plusieurs hôtes et ne l'exécuter que pour un seul groupe, cela peut être fait avec la commande suivante:
ansible-playbook -i inventory ./playbook.yml -l "staging"
une autre option consiste à avoir des fichiers d'inventaire distincts pour différents groupes. Ou vous pouvez combiner deux approches si vous avez de nombreux hôtes différents.
Revenons à la configuration de nginx. Après avoir copié les fichiers de configuration, nous devons créer un lien symbolique dans sitest_enabled sur my_app.conf à partir de sites_available. Et redémarrez nginx.
... # old code in mail.yml - name: Create symlink to sites-enabled file: src: /etc/nginx/sites-available/my_app.conf dest: /etc/nginx/sites-enabled/my_app.conf state: link - name: restart nginx service: name: nginx state: restarted
Tout est simple ici - encore une fois, des modules ansibles avec une syntaxe assez standard. Mais il y a un point. Redémarrer nginx à chaque fois n'a pas de sens. Vous avez remarqué que nous n'écrivons pas de commandes du formulaire: "faites ceci comme ceci", la syntaxe ressemble plus à "ceci devrait avoir cet état". Et le plus souvent, c'est ainsi que fonctionne ansible. Si le groupe existe déjà ou que le package système est déjà installé, alors ansible le vérifiera et ignorera la tâche. De plus, les fichiers ne seront pas copiés s'ils coïncident complètement avec ce qui se trouve déjà sur le serveur. Nous pouvons en profiter et redémarrer nginx uniquement si les fichiers de configuration ont été modifiés. Il existe une directive d'enregistrement pour cela:
# Copy nginx configs and start it - name: enable service nginx and start systemd: name: nginx state: started enabled: yes - name: Copy the nginx.conf copy: src: nginx.conf dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' backup: yes register: restart_nginx - name: Copy template my_app.conf template: src: my_app_conf.j2 dest: /etc/nginx/sites-available/my_app.conf owner: root group: root mode: '0644' register: restart_nginx - name: Create symlink to sites-enabled file: src: /etc/nginx/sites-available/my_app.conf dest: /etc/nginx/sites-enabled/my_app.conf state: link - name: restart nginx service: name: nginx state: restarted when: restart_nginx.changed
Si l'un des fichiers de configuration change, la copie sera effectuée et la variable restart_nginx sera enregistrée. Et seulement si cette variable a été enregistrée, le service redémarrera.
Bien sûr, vous devez ajouter le rôle nginx au playbook principal.
Configuration de PostgreSQL
Nous devons activer postgresql avec systemd comme nous l'avons fait avec nginx, et également créer un utilisateur que nous utiliserons pour accéder à la base de données et à la base de données elle-même.
Créez le rôle /ansible/roles/postgresql/tasks/main.yml :
# Create user in postgresql - name: enable postgresql and start systemd: name: postgresql state: started enabled: yes - name: Create database user become_user: postgres postgresql_user: name: "{{ db_user }}" password: "{{ db_password }}" role_attr_flags: SUPERUSER - name: Create database become_user: postgres postgresql_db: name: "{{ db_name }}" encoding: UTF-8 owner: "{{ db_user }}"
Je ne décrirai pas comment ajouter des variables à l'inventaire, cela a déjà été fait plusieurs fois, ainsi que la syntaxe des modules postgresql_db et postgresql_user. Plus de données peuvent être trouvées dans la documentation. La directive become_user: postgres plus intéressante become_user: postgres . Le fait est que, par défaut, seul l'utilisateur postgres a accès à la base de données postgresql et uniquement localement. Cette directive nous permet d'exécuter des commandes au nom de cet utilisateur (à moins bien sûr que nous ayons accès).
De plus, vous devrez peut-être ajouter une ligne à pg_hba.conf pour ouvrir l'accès à la base de données à un nouvel utilisateur. Cela peut être fait de la même manière que nous avons changé la configuration de nginx.
Et bien sûr, vous devez ajouter le rôle de postgresql au playbook principal.
Installer ruby via rbenv
Ansible n'a pas de modules pour travailler avec rbenv, mais il est installé en clonant un référentiel git. Par conséquent, cette tâche devient la plus non standard. Créons pour elle le rôle /ansible/roles/ruby_rbenv/main.yml et commençons à le remplir:
# Install rbenv and ruby - name: Install rbenv become_user: "{{ user }}" git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv
Nous utilisons à nouveau la directive devient_utilisateur pour travailler sous l'utilisateur que nous avons créé à ces fins. Depuis rbenv est installé dans son répertoire personnel, pas dans le monde. Et nous utilisons également le module git pour cloner le référentiel en spécifiant repo et dest.
Ensuite, nous devons enregistrer rbenv init dans bashrc et ajouter rbenv à PATH au même endroit. Pour cela, nous avons le module lineinfile:
- name: Add rbenv to PATH become_user: "{{ user }}" lineinfile: path: ~/.bashrc state: present line: 'export PATH="${HOME}/.rbenv/bin:${PATH}"' - name: Add rbenv init to bashrc become_user: "{{ user }}" lineinfile: path: ~/.bashrc state: present line: 'eval "$(rbenv init -)"'
Ensuite, installez ruby_build:
- name: Install ruby-build become_user: "{{ user }}" git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build
Et enfin installer ruby. Cela se fait via rbenv, c'est-à-dire juste une commande bash:
- name: Install ruby become_user: "{{ user }}" shell: | export PATH="${HOME}/.rbenv/bin:${PATH}" eval "$(rbenv init -)" rbenv install {{ ruby_version }} args: executable: /bin/bash
Nous disons quelle équipe exécuter et comment. Cependant, nous rencontrons ici le fait qu'ansible n'exécute pas le code contenu dans bashrc avant d'exécuter les commandes. Donc, rbenv devra être défini directement dans le même script.
Le problème suivant est que la commande shell n'a pas d'état en termes de ansible. Autrement dit, une vérification automatique si cette version de ruby est installée ou non ne le sera pas. Nous pouvons le faire nous-mêmes:
- name: Install ruby become_user: "{{ user }}" shell: | export PATH="${HOME}/.rbenv/bin:${PATH}" eval "$(rbenv init -)" if ! rbenv versions | grep -q {{ ruby_version }} then rbenv install {{ ruby_version }} && rbenv global {{ ruby_version }} fi args: executable: /bin/bash
Et il reste à installer bundler:
- name: Install bundler become_user: "{{ user }}" shell: | export PATH="${HOME}/.rbenv/bin:${PATH}" eval "$(rbenv init -)" gem install bundler
Et encore une fois, ajoutez notre rôle ruby_rbenv au playbook principal.
Fichiers partagés.
En général, ce paramètre peut être effectué. Ensuite, il reste à exécuter capistrano et il copiera le code lui-même, créera les répertoires nécessaires et lancera l'application (si tout est correctement configuré). Cependant, capistrano a souvent besoin de fichiers de configuration supplémentaires, tels que database.yml ou .env pouvez les copier comme des fichiers et des modèles pour nginx. Il n'y a qu'une subtilité. Avant de copier des fichiers, vous devez créer une structure de répertoires pour eux, quelque chose comme ceci:
# Copy shared files for deploy - name: Ensure shared dir become_user: "{{ user }}" file: path: "{{ app_path }}/shared/config" state: directory
nous spécifions un seul répertoire et ansible créera automatiquement le parent, si nécessaire.
Voûte Ansible
Nous sommes déjà tombés sur le fait que des données secrètes telles que le mot de passe utilisateur peuvent apparaître dans des variables. Si vous avez créé un fichier .env pour l'application et database.yml il devrait y avoir encore plus de telles données critiques. Ce serait bien de les cacher des regards indiscrets. Un coffre-fort Ansible est utilisé pour cela.
Créons un fichier pour les variables /ansible/vars/all.yml (ici vous pouvez créer des fichiers différents pour différents groupes d'hôtes, tout comme dans le fichier d'inventaire: production.yml, staging.yml, etc.).
Dans ce fichier, vous devez transférer toutes les variables qui doivent être chiffrées à l'aide de la syntaxe yml standard:
# System vars user_password: 123qweasd db_password: 123qweasd # ENV vars aws_access_key_id: xxxxx aws_secret_access_key: xxxxxx aws_bucket: bucket_name rails_secret_key_base: very_secret_key_base
Ensuite, ce fichier peut être crypté avec la commande:
ansible-vault encrypt ./vars/all.yml
Naturellement, lors du cryptage, il sera nécessaire de définir un mot de passe pour le décryptage. Vous pouvez voir ce qui apparaît dans le fichier après avoir appelé cette commande.
À l'aide de ansible-vault decrypt fichier peut être déchiffré, modifié, puis à nouveau chiffré.
Pour fonctionner, déchiffrer le fichier n'est pas nécessaire. Vous le stockez sous forme cryptée et exécutez le playbook avec l'argument --ask-vault-pass . Ansible vous demandera un mot de passe, récupérera les variables et terminera les tâches. Toutes les données resteront cryptées.
Une commande complète pour plusieurs groupes d'hôtes et coffre-fort ansible ressemblerait à ceci:
ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass
Et je ne vous donnerai pas le texte intégral des manuels et des rôles, écrivez pour vous-même. Parce que la chose ansible est la suivante - si vous ne comprenez pas ce qui doit être fait, alors il ne le fera pas.