🥇Configuration du serveur pour le déploiement d'une application Rails à l'aide d'Ansible

Il n'y a pas si longtemps, j'avais besoin d'écrire plusieurs playbooks Ansible pour préparer un serveur au déploiement d'une application Rails. À ma surprise, je n'ai trouvé aucun manuel simple étape par étape. Copier le playbook de quelqu'un d'autre sans comprendre ce qui se passe n'était pas ma volonté, et j'ai finalement dû lire la documentation, assemblant tout moi-même. Peut-être que je pourrai aider certains à accélérer ce processus grâce à cet article.

Tout d'abord, il est important de comprendre qu'Ansible vous offre une interface pratique pour exécuter une liste d'actions prédéfinies sur un ou plusieurs serveurs distants via SSH. Il n'y a pas de magie ici, vous ne pouvez pas simplement installer un plugin et obtenir un déploiement sans temps d'arrêt de votre application avec Docker, un monitoring, et d'autres avantages prêts à l'emploi. Pour écrire un playbook, vous devez savoir ce que vous voulez faire et comment le faire. C'est pourquoi je ne suis pas satisfait des playbooks prêts à l'emploi sur GitHub, ou des articles du type : "Copiez et exécutez, ça fonctionnera".

De quoi avons-nous besoin ?

Comme je l'ai déjà mentionné, pour écrire un playbook, il faut savoir ce que vous voulez faire et comment le faire. Définissons ce dont nous avons besoin. Pour une application Rails, nous aurons besoin de plusieurs paquets système : nginx, postgresql (redis, etc.). De plus, nous avons besoin de Ruby dans une version spécifique. Il est préférable de l'installer via rbenv (rvm, asdf…). Exécuter tout cela sous l'utilisateur root n'est jamais une bonne idée, donc il faut créer un utilisateur séparé et lui attribuer des droits. Après cela, il est nécessaire de transférer notre code sur le serveur, de copier les configurations pour nginx, postgres, etc., et de démarrer tous ces services.

Ainsi, l'ordre des opérations est le suivant :

Nous nous connectons en tant que root
nous installons les paquets système
nous créons un nouvel utilisateur, configurons les droits, la clé ssh
nous configurons les paquets système (nginx, etc.) et les démarrons
Nous créons un utilisateur dans la base de données (nous pouvons aussi créer la base en même temps)
Nous nous connectons avec le nouvel utilisateur
Nous installons rbenv et Ruby
Nous installons Bundler
Nous déployons le code de l'application
Nous lançons le serveur Puma

D'ailleurs, les dernières étapes peuvent être effectuées avec Capistrano, car au moins elle sait par défaut copier le code dans les répertoires de publication, changer le lien symbolique de la publication lors d'un déploiement réussi, copier les configurations à partir du répertoire partagé, redémarrer Puma, etc. Tout cela peut également être fait avec Ansible, mais pourquoi faire ?

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 distinct. Peu importe s'il se trouve dans l'application Rails ou à l'extérieur. On peut conserver les fichiers dans un dépôt git séparé. Personnellement, j'ai trouvé qu'il était plus pratique de créer un répertoire ansible dans /config du répertoire de l'application Rails et de tout conserver dans un seul dépôt. Playbook simple

Un playbook est un fichier yml qui décrit, à l'aide d'une syntaxe spéciale, ce qu'Ansible doit faire et comment cela doit être fait. Créons notre premier playbook qui ne fait rien :

--- - name: Playbook simple hosts: all

Ici, nous disons simplement que notre playbook s'appelle

et que son contenu doit être exécuté pour tous les hôtes. Nous pouvons l'enregistrer dans le répertoire /ansible sous le nom Un playbook est un fichier yml qui décrit, à l'aide d'une syntaxe spéciale, ce qu'Ansible doit faire et comment cela doit être fait. Créons notre premier playbook qui ne fait rien : playbook.yml playbook.yml et essayer de l'exécuter :

ansible-playbook ./playbook.yml

PLAY [Playbook simple] ************************************************************************************************************************************
skipping: aucun hôte correspondant

Ansible dit qu'il ne connaît pas d'hôtes correspondant à la liste all. Ils doivent être énumérés dans un fichier d'inventaire..

Créons-le dans le même répertoire ansible :

123.123.123.123

Ici, nous indiquons simplement un hôte (idéalement l'hôte de votre VPS pour les tests, ou vous pouvez spécifier localhost) et l'enregistrer sous le nom inventory.
Vous pouvez essayer d'exécuter Ansible avec le fichier d'inventaire :

ansible-playbook ./playbook.yml -i inventory
PLAY [Playbook simple] ************************************************************************************************************************************

TASK [Collecte de faits] ************************************************************************************************************************************

PLAY RECAP ************************************************************************************************************************************

Si vous avez accès par ssh à l'hôte spécifié, Ansible se connectera et collectera des informations sur le système distant. (la tâche par défaut [Collecte de faits]) puis fournira un rapport succinct sur l'exécution (PLAY RECAP).

Par défaut, le nom d'utilisateur utilisé pour la connexion est celui avec lequel vous êtes connecté au système. Il n'existe probablement pas sur l'hôte. Dans le fichier de playbook, vous pouvez indiquer quel utilisateur utiliser pour la connexion à l'aide de la directive remote_user. Les informations sur le système distant peuvent également souvent ne pas vous intéresser, et il n'est pas nécessaire de perdre du temps à les collecter. Cette tâche peut également être désactivée :

---
- name: Playbook simple
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

Essayez de redémarrer le playbook et assurez-vous que la connexion fonctionne. (Si vous avez spécifié l'utilisateur root, vous devez également indiquer la directive become: true pour obtenir des droits d'administrateur. Comme indiqué dans la documentation : become défini sur ‘true’/’yes’ pour activer l'escalade des privilèges. bien que ce ne soit pas tout à fait clair pourquoi).

Vous pourriez rencontrer une erreur due au fait qu'Ansible ne peut pas déterminer l'interpréteur Python, alors vous pouvez le spécifier manuellement :

ansible_python_interpreter: /usr/bin/python3

où se trouve votre Python peut être vérifié avec la commande whereis python.

Installation de paquets système

La distribution standard d'Ansible comprend de nombreux modules pour travailler avec divers paquets système, ce qui évite d'avoir à écrire des scripts bash pour chaque situation. Nous allons maintenant utiliser l'un de ces modules pour mettre à jour le système et installer des paquets système. Sur mon VPS, j'ai Ubuntu Linux, donc pour installer des paquets, j'utilise apt-get et le module pour cela.Si vous utilisez un autre système d'exploitation, un autre module sera peut-être nécessaire (rappelez-vous que j'ai mentionné au début qu'il fallait savoir à l'avance ce que nous allons faire). Cependant, la syntaxe sera probablement similaire.

Ajoutons les premières tâches à notre playbook :

---
- name: Playbook simple
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

  tasks:
    - name: Mettre à jour le système
      apt: update_cache=yes
    - name: Installer les dépendances système
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

Une tâche — c'est exactement ce que Ansible va exécuter sur les serveurs distants. Nous donnons un nom à la tâche afin de suivre son exécution dans les logs. Et nous décrivons, à l'aide de la syntaxe du module spécifique, ce qu'il doit faire. Dans ce cas apt: update_cache=yes — indique de mettre à jour les paquets système à l'aide du module apt. La deuxième commande est un peu plus complexe. Nous passons une liste de paquets au module apt et lui disons que leur state doit devenir présent, c'est-à-dire que nous demandons d'installer ces paquets. De la même manière, nous pouvons indiquer de les supprimer ou de les mettre à jour, simplement en changeant state. Notez que pour que Rails fonctionne avec PostgreSQL, nous avons besoin du paquet postgresql-contrib, que nous installons actuellement. Encore une fois, il faut le savoir et le faire, Ansible ne le fera pas de lui-même.

Essayez de relancer le playbook et vérifiez que les paquets s'installent.

Création de nouveaux utilisateurs.

Pour interagir avec les utilisateurs, Ansible dispose également d'un module : user. Ajoutons une tâche supplémentaire (j'ai masqué les parties déjà connues du playbook par des commentaires, afin de ne pas avoir à le copier entièrement à chaque fois) :

---
- name: Playbook simple
  # ...
  tasks:
    # ...
    - name: Ajouter un nouvel utilisateur
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

Nous créons un nouvel utilisateur, lui attribuons un shell et un mot de passe. Et nous rencontrons immédiatement plusieurs problèmes. Que faire si les noms d'utilisateur doivent être différents pour différents hôtes ? De plus, stocker le mot de passe en clair dans le playbook est une très mauvaise idée. Commençons par déplacer le nom d'utilisateur et le mot de passe dans des variables, et plus loin dans l'article, je vous montrerai comment chiffrer le mot de passe.

---
- name: Playbook simple
  # ...
  tasks:
    # ...
    - name: Ajouter un nouvel utilisateur
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

Les variables sont définies dans les playbooks à l'aide de doubles accolades.

Nous indiquerons les valeurs des variables dans le fichier d'inventaire :

123.123.123.123

[all:vars]
user=my_user
user_password=123qweasd

Notez la directive [all:vars] — elle indique que le bloc de texte suivant est constitué de variables (vars) et qu'elles s'appliquent à tous les hôtes (all).

La construction est également intéressante "{{ user_password | password_hash('sha512') }}". En effet, Ansible n'ajoute pas l'utilisateur via user_add comme vous le feriez manuellement. Il enregistre directement toutes les données, c'est pourquoi nous devons également préalablement transformer le mot de passe en hachage, ce que fait cette commande.

Ajoutons notre utilisateur au groupe sudo. Cependant, avant cela, il est nécessaire de s'assurer qu'un tel groupe existe car personne ne fera cela pour nous :

---
- name: Playbook simple
  # ...
  tasks:
    # ...
    - name: Assurer l'existence d'un groupe 'sudo'
      group:
        name: sudo
        state: present
    - name: Ajouter un nouvel utilisateur
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"

Tout est assez simple, nous avons également un module group pour créer des groupes, avec une syntaxe très similaire à apt. Ensuite, il suffit d'attribuer ce groupe à l'utilisateur (groups: "sudo").
Il est également utile d'ajouter une clé SSH à cet utilisateur, afin que nous puissions nous connecter sous son compte sans mot de passe :

---
- name: Playbook simple
  # ...
  tasks:
    # ...
    - name: Assurer un groupe 'sudo'
      group:
      name: sudo
        state: present
    - name: Ajouter un nouvel utilisateur
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: Déployer la clé SSH
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

Dans ce cas, la construction est intéressante "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — elle copie le contenu du fichier id_rsa.pub (vous pouvez avoir un nom différent), c'est-à-dire la partie publique de la clé SSH et l'ajoute à la liste des clés autorisées pour l'utilisateur sur le serveur.

Rôles

Les trois tâches pour la création d'utilisateurs peuvent facilement être regroupées en une seule catégorie de tâches, et il serait bon de garder ce groupe séparé du playbook principal pour qu'il ne devienne pas trop encombré. Pour cela, Ansible propose des rôles.
Conformément à la structure de fichiers indiquée au début, les rôles doivent être placés dans un répertoire séparé roles, chaque rôle ayant un répertoire distinct avec le même nom, à l'intérieur du répertoire tasks, files, templates, etc.
Créons la structure de fichiers : ./ansible/roles/user/tasks/main.yml (main est le fichier principal qui sera chargé et exécuté lors de la connexion du rôle au playbook, où l'on peut inclure d'autres fichiers du rôle). Nous pouvons maintenant transférer dans ce fichier toutes les tâches relatives à 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, il est nécessaire d'indiquer d'utiliser le rôle user :

---
- name: Playbook simple
  hosts: all
  remote_user: root
  gather_facts: no

  tasks:
    - name: Mettre à jour le système
      apt: update_cache=yes
    - name: Installer les dépendances système
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

  roles:
    - user

Il se peut également qu'il soit judicieux d'exécuter la mise à jour du système avant toutes les autres tâches, on peut alors renommer le bloc tasks dans lequel elles sont définies en pre_tasks.

Configuration de nginx

Nginx doit déjà être installé, il faut le configurer et le lancer. Faisons cela directement dans le rôle. Créons la structure de fichiers :

- ansible
  - roles
    - nginx
      - files
      - tasks
        - main.yml
      - templates

Nous aurons maintenant besoin de fichiers et de modèles. La différence entre eux est que les fichiers sont copiés tels quels par Ansible, tandis que les modèles doivent avoir l'extension j2 et peuvent utiliser des valeurs de variables avec les mêmes accolades doubles.

Intégrons nginx dans main.yml fichier. Pour cela, nous avons le module systemd :

# Copy nginx configs and start it
- name: enable service nginx and start
  systemd:
    name: nginx
    state: started
    enabled: yes

Ici, non seulement nous disons que nginx doit être démarré (c'est-à-dire que nous le lançons), mais nous indiquons aussi qu'il doit être activé.
Nous allons maintenant copier 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). Ainsi qu'un fichier de configuration pour notre application dans le répertoire sites_available (ce n'est pas obligatoire mais utile). Dans le premier cas, nous utilisons le module copy pour copier les fichiers (le fichier doit se trouver dans /ansible/roles/nginx/files/nginx.conf). Dans le second, nous copions le modèle en remplaçant les valeurs des variables. Le modèle doit se trouver dans /ansible/roles/nginx/templates/my_app.j2). Et il peut ressembler approximativement à 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 seront remplacées par ansible dans le modèle avant la copie. Cela est utile si vous utilisez un 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 lançons maintenant notre playbook, il exécutera les tâches spécifiées pour les deux hôtes. Mais pour l'hôte de staging, les variables seront différentes de celles de production, et pas seulement dans les rôles et les playbooks, mais aussi dans les configs de nginx. {{ inventory_hostname }} il n'est pas nécessaire de spécifier dans le fichier d'inventaire — c'est une variable spéciale d'ansible et elle contient l'hôte pour lequel le playbook est actuellement exécuté.
Si vous souhaitez avoir un fichier d'inventaire pour plusieurs hôtes, et exécuter uniquement pour un seul groupe, vous pouvez le faire avec la commande suivante :

ansible-playbook -i inventory .\/playbook.yml -l "staging"

une autre option consiste à avoir des fichiers d'inventaire séparés pour différents groupes. Ou vous pouvez combiner les deux approches si vous avez beaucoup d'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 sites_enabled pour my_app.conf à partir de sites_available. Et redémarrer nginx.

... # ancien code dans mail.yml

- name: Créer un lien symbolique vers sites-enabled
  file:
    src: \/etc\/nginx\/sites-available\/my_app.conf
    dest: \/etc\/nginx\/sites-enabled\/my_app.conf
    state: link

- name: redémarrer nginx
  service:
    name: nginx
    state: restarted

Tout est assez simple ici - encore des modules Ansible avec une syntaxe plutôt standard. Mais il y a un point important. Redémarrer Nginx à chaque fois n'a pas de sens. Vous avez remarqué que nous n'écrivons pas des commandes du type : « faites cela ainsi », la syntaxe ressemble plutôt à « cet élément doit avoir tel état ». C'est généralement ainsi qu'Ansible fonctionne. Si le groupe existe déjà, ou si le paquet système est déjà installé, Ansible le vérifiera et passera la tâche. De même, les fichiers ne seront pas copiés s'ils correspondent exactement à ce qui est déjà sur le serveur. Nous pouvons en profiter et redémarrer Nginx uniquement si les fichiers de configuration ont été modifiés. Pour cela, il existe la directive register :

# 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, le fichier sera copié et une variable sera enregistrée restart_nginx. Et ce n'est que si cette variable a été enregistrée que le redémarrage du service sera effectué.

Bien sûr, il faut également ajouter le rôle Nginx au playbook principal.

Configuration de PostgreSQL

Nous devons activer PostgreSQL avec systemd exactement comme nous l'avons fait avec Nginx, et créer un utilisateur que nous allons utiliser pour accéder à la base de données ainsi que la base de données elle-même.
Créons un 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étaillerai pas comment ajouter des variables dans l'inventaire, cela a déjà été fait de nombreuses fois, de même que la syntaxe des modules postgresql_db et postgresql_user. Des informations supplémentaires peuvent être trouvées dans la documentation. Ici, la directive la plus intéressante est become_user: postgres. En fait, par défaut, l'accès à la base de données PostgreSQL se fait uniquement par l'utilisateur postgres et seulement localement. Cette directive nous permet d'exécuter des commandes au nom de cet utilisateur (si bien sûr nous avons accès).
De plus, il se peut que vous deviez ajouter une ligne dans pg_hba.conf pour ouvrir l'accès au nouveau utilisateur à la base. Cela peut être réalisé de la même manière que nous avons modifié la configuration de Nginx.

Et bien sûr, il faut ajouter le rôle PostgreSQL au playbook principal.

Installation de Ruby via rbenv

Ansible n'a pas de modules pour travailler avec rbenv, et il s'installe en clonant le dépôt Git. Par conséquent, cette tâche devient la plus non standard. Créons un rôle pour cela /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 become_user pour travailler sous l'utilisateur que nous avons créé à cet effet. Comme rbenv est installé dans son répertoire personnel et non de manière globale. Nous utilisons également le module git pour cloner le dépôt, en indiquant repo et dest.

Ensuite, nous devons ajouter rbenv init dans bashrc et y ajouter rbenv dans PATH. Pour cela, nous avons le module lineinfile :

- name: Ajouter rbenv au PATH
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'export PATH="${HOME}/.rbenv/bin:${PATH}"'

- name: Ajouter rbenv init à bashrc
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'eval "$(rbenv init -)"'

Après cela, il faut installer ruby_build :

- name: Installer 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 simplement avec une commande bash :

- name: Installer ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    rbenv install {{ ruby_version }}
  args:
    executable: /bin/bash

Nous indiquons quelle commande exécuter et avec quoi. Cependant, ici nous ferons face à un problème, car ansible ne lance pas le code contenu dans bashrc avant d'exécuter les commandes. Ainsi, rbenv devra être défini directement dans ce même script.

Le problème suivant est lié au fait que la commande shell n'a pas d'état du point de vue d'ansible. Il n'y aura donc pas de vérification automatique pour savoir si cette version de ruby est installée ou non — nous devons le faire nous-mêmes :

- name: Installer 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

Il reste à installer bundler :

- name: Installer bundler
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    gem install bundler

Et encore une fois, ajouter notre rôle ruby_rbenv au playbook principal.

Fichiers partagés.

En général, à ce stade, la configuration pourrait être terminée. Ensuite, il suffit d'exécuter capistrano et il copiera automatiquement le code, créera les répertoires nécessaires et lancera l'application (si tout est configuré correctement). Cependant, capistrano nécessite souvent des fichiers de configuration supplémentaires, tels que database.yml ou .env Ils peuvent être copiés de la même manière que les fichiers et modèles pour nginx. Il y a juste un petit détail. Avant de copier les fichiers, il faut créer leur structure de répertoires, quelque chose comme cela :

# Copy shared files for deploy
- name: Ensure shared dir
  become_user: "{{ user }}"
  file:
    path: "{{ app_path }}/shared/config"
    state: directory

nous indiquons seulement un répertoire et ansible créera automatiquement les parents, si besoin.

Ansible Vault

Nous avons déjà rencontré le fait que des données sensibles telles que le mot de passe utilisateur peuvent se retrouver dans les variables. Si vous avez créé .env un fichier pour l'application, et database.yml il devrait y avoir encore plus de ces données critiques. Il serait préférable de les cacher des yeux indiscrets. Pour cela, nous utilisons ansible vault.

Créons un fichier pour les variables /ansible/vars/all.yml (vous pouvez créer différents fichiers pour différents groupes d'hôtes, tout comme dans le fichier d'inventaire : production.yml, staging.yml, etc.).
Ce fichier doit contenir toutes les variables qui doivent être encryptées, en utilisant 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

Après quoi ce fichier peut être encrypté avec la commande :

ansible-vault encrypt ./vars/all.yml

Évidemment, lors de l'encryptage, vous devrez définir un mot de passe pour le décryptage. Vous pouvez voir ce qu'il y a à l'intérieur du fichier après avoir exécuté cette commande.

À l'aide de ansible-vault decrypt vous pouvez déchiffrer le fichier, le modifier et le chiffrer à nouveau.

Pour travailler, il n'est pas nécessaire de déchiffrer le fichier. Vous le conservez sous forme chiffrée et exécutez le playbook avec l'argument --ask-vault-pass. Ansible demandera le mot de passe, récupérera les variables et exécutera les tâches. Toutes les données resteront chiffrées.

La commande complète pour plusieurs groupes d'hôtes et ansible vault ressemblera à quelque chose comme ceci :

ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass

Et je ne vous donnerai pas le texte complet des playbooks et des rôles, écrivez vous-même. Parce qu'ansible est une chose comme ça - si vous ne comprenez pas ce qu'il faut faire, il ne le fera pas non plus.

Source : habr.com

Configuration du serveur pour déployer une application Rails avec Ansible