Ansible を使用して Rails アプリケーションをデプロイするためのサーバーのセットアップ

少し前まで、Rails アプリケーションをデプロイするためにサーバーを準備するために、いくつかの Ansible Playbook を作成する必要がありました。 そして驚いたことに、簡単なステップバイステップのマニュアルは見つかりませんでした。 何が起こっているのか理解せずに他の人のプレイブックをコピーしたくなかったので、最終的にはドキュメントを読んですべてを自分で収集する必要がありました。 おそらく、この記事の助けを借りて、誰かがこのプロセスをスピードアップするのを助けることができるでしょう。

まず理解すべきことは、ansible は、SSH 経由でリモート サーバー上で事前定義されたアクションのリストを実行するための便利なインターフェイスを提供するということです。 ここには魔法はありません。プラグインをインストールして、Docker、モニタリング、その他のすぐに使用できる機能を使用してアプリケーションをダウンタイムゼロでデプロイすることはできません。 プレイブックを作成するには、正確に何をしたいのか、そしてそれをどのように行うのかを知る必要があります。 だからこそ、私は GitHub の既成の Playbook や、「コピーして実行すればうまくいきます」のような記事には満足できません。

私たちは何が必要なのか？

すでに述べたように、プレイブックを作成するには、何をしたいのか、そしてそれをどのように行うのかを知る必要があります。 何が必要かを決めましょう。 Rails アプリケーションの場合、nginx、postgresql (redis など) などのいくつかのシステム パッケージが必要になります。 さらに、特定のバージョンの Ruby が必要です。 rbenv (rvm、asdf...) 経由でインストールするのが最善です。 これらすべてを root ユーザーとして実行するのは常に悪い考えであるため、別のユーザーを作成してその権限を構成する必要があります。 この後、コードをサーバーにアップロードし、nginx、postgres などの構成をコピーし、これらのサービスをすべて開始する必要があります。

その結果、一連のアクションは次のようになります。

1. rootとしてログイン
2. システムパッケージをインストールする
3. 新しいユーザーの作成、権限の構成、SSH キー
4. システムパッケージ (nginx など) を構成して実行する
5. データベースにユーザーを作成します（データベースはすぐに作成できます）
6. 新規ユーザーとしてログイン
7. rbenv と Ruby をインストールする
8. バンドラーのインストール
9. アプリケーションコードのアップロード
10. Pumaサーバーの起動

さらに、最後の段階は capistrano を使用して実行でき、少なくともすぐに使用できるコードをリリース ディレクトリにコピーし、デプロイメントが成功したときにシンボリック リンクを使用してリリースを切り替え、共有ディレクトリから構成をコピーし、puma を再起動することができます。 これらはすべて Ansible を使用して実行できますが、なぜでしょうか?

ファイル構造

Ansible には厳密な制限があります ファイル構造 すべてのファイルが対象となるため、すべてを別のディレクトリに保存することをお勧めします。 さらに、Rails アプリケーション自体に含めるか、個別に含めるかはそれほど重要ではありません。 ファイルを別の git リポジトリに保存できます。 個人的には、rails アプリケーションの /config ディレクトリに ansible ディレクトリを作成し、すべてを XNUMX つのリポジトリに保存するのが最も便利であると感じました。

シンプルなプレイブック

Playbook は、特別な構文を使用して、Ansible が何をどのように行うべきかを説明する yml ファイルです。 何も行わない最初の Playbook を作成しましょう。

---
- name: Simple playbook
  hosts: all

ここでは、単にプレイブックの名前を言うだけです。 Simple Playbook そしてその内容はすべてのホストに対して実行される必要があります。 /ansible ディレクトリに次の名前で保存できます。 playbook.yml そして実行してみてください:

ansible-playbook ./playbook.yml

PLAY [Simple Playbook] ************************************************************************************************************************************
skipping: no hosts matched

Ansible は、すべてのリストに一致するホストを認識していないと言います。 それらは特別なリストに記載されている必要があります インベントリファイル.

同じ ansible ディレクトリに作成しましょう。

123.123.123.123

これは、ホスト (理想的にはテスト用の VPS のホスト、または localhost を登録することもできます) を指定し、名前で保存する方法です。 inventory.
インベントリ ファイルを使用して ansible を実行してみることができます。

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

TASK [Gathering Facts] ************************************************************************************************************************************

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

指定したホストに ssh アクセスできる場合、ansible はリモート システムに接続して情報を収集します。 (デフォルトのタスク [事実の収集]) その後、実行に関する短いレポートが提供されます (PLAY RECAP)。

デフォルトでは、接続ではシステムにログインしているユーザー名が使用されます。 おそらくホスト上には存在しないでしょう。 Playbook ファイルでは、remote_user ディレクティブを使用して、接続に使用するユーザーを指定できます。 また、リモート システムに関する情報は多くの場合不要であるため、収集に時間を無駄にすべきではありません。 このタスクは無効にすることもできます。

---
- name: Simple playbook
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

プレイブックを再度実行して、接続が機能していることを確認してください。 (root ユーザーを指定した場合は、昇格された権限を取得するために become: true ディレクティブも指定する必要があります。ドキュメントに記載されているように: become set to ‘true’/’yes’ to activate privilege escalation. その理由は完全には明らかではありませんが）。

おそらく、ansible が Python インタープリターを決定できないことが原因でエラーが発生する可能性がありますが、その場合は手動で指定できます。

ansible_python_interpreter: /usr/bin/python3 

コマンドを使用してPythonがどこにあるかを確認できます whereis python.

システムパッケージのインストール

Ansible の標準ディストリビューションには、さまざまなシステム パッケージを操作するためのモジュールが多数含まれているため、何らかの理由で bash スクリプトを作成する必要はありません。 ここで、システムを更新し、システム パッケージをインストールするには、これらのモジュールの XNUMX つが必要です。 VPS に Ubuntu Linux があるので、パッケージをインストールするために使用します apt-get и それ用のモジュール。 別のオペレーティング システムを使用している場合は、別のモジュールが必要になる可能性があります (最初に、何をどのように行うかを事前に知る必要があると述べたことを思い出してください)。 ただし、構文はほぼ同様になります。

最初のタスクでプレイブックを補足しましょう。

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

Task は、まさに Ansible がリモートサーバー上で実行するタスクです。 タスクの実行をログで追跡できるように、タスクに名前を付けます。 そして、特定のモジュールの構文を使用して、そのモジュールが何を行う必要があるかを説明します。 この場合 apt: update_cache=yes - apt モジュールを使用してシステム パッケージを更新するように指示されています。 XNUMX 番目のコマンドは少し複雑です。 パッケージのリストを apt モジュールに渡し、それらが state なるはず present、つまり、これらのパッケージをインストールすると言います。 同様の方法で、それらを削除するか、単に変更するだけで更新するように指示できます。 state。 Rails を postgresql で動作させるには、現在インストールしている postgresql-contrib パッケージが必要であることに注意してください。 繰り返しますが、これを知って実行する必要があります。ansible だけではこれを実行できません。

Playbook を再度実行して、パッケージがインストールされていることを確認してください。

新しいユーザーの作成。

ユーザーと連携するために、Ansible にはユーザーというモジュールもあります。 もう XNUMX つタスクを追加しましょう (毎回完全にコピーしないように、プレイブックの既知の部分をコメントの後ろに隠しました)。

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Add a new user
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

新しいユーザーを作成し、そのユーザーのシェルとパスワードを設定します。 そして、いくつかの問題に遭遇します。 ホストごとにユーザー名を変える必要がある場合はどうすればよいでしょうか? また、プレイブックにパスワードを平文で保存するのは非常に悪い考えです。 まず、ユーザー名とパスワードを変数に入れて、記事の終わりの方でパスワードを暗号化する方法を示します。

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Add a new user
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

変数は二重中括弧を使用して Playbook に設定されます。

インベントリ ファイル内の変数の値を示します。

123.123.123.123

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

指令に注意してください [all:vars] - テキストの次のブロックは変数 (vars) であり、それらはすべてのホスト (all) に適用できると書かれています。

デザインも面白いですね "{{ user_password | password_hash('sha512') }}"。 問題は、ansible がユーザーをインストールしないことです。 user_add 手動で行うのと同じように。 また、すべてのデータを直接保存するため、事前にパスワードをハッシュに変換する必要もあり、それがこのコマンドの目的です。

ユーザーを sudo グループに追加しましょう。 ただし、これを行う前に、そのようなグループが存在することを確認する必要があります。これは、誰も私たちの代わりにやってくれるわけではないためです。

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

すべては非常に単純です。apt に非常によく似た構文を使用して、グループを作成するための group モジュールもあります。 その後、このグループをユーザーに登録するだけで十分です (groups: "sudo").
パスワードなしでログインできるように、このユーザーに ssh キーを追加すると便利です。

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

この場合、デザインが面白いです "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — id_rsa.pub ファイル (名前は異なる場合があります) の内容、つまり ssh キーの公開部分をコピーし、サーバー上のユーザーの許可されたキーのリストにアップロードします。

役割

使用を作成するための XNUMX つのタスクはすべて、XNUMX つのタスク グループに簡単に分類できます。大きくなりすぎないように、このグループをメインのプレイブックとは別に保存することをお勧めします。 この目的のために、Ansible には 役割.
一番最初に示したファイル構造に従って、ロールは別のロール ディレクトリに配置する必要があります。ロールごとに、タスク、ファイル、テンプレートなどのディレクトリ内に同じ名前の別のディレクトリがあります。
ファイル構造を作成しましょう。 ./ansible/roles/user/tasks/main.yml (main は、ロールが Playbook に接続されるときにロードされて実行されるメイン ファイルです。他のロール ファイルをそれに接続できます)。 これで、ユーザーに関連するすべてのタスクをこのファイルに転送できるようになりました。

# 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

メイン プレイブックでは、ユーザー ロールを使用するように指定する必要があります。

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

また、他のすべてのタスクの前にシステムを更新することが合理的である場合があります。これを行うには、ブロックの名前を変更します。 tasks で定義されています pre_tasks.

nginxのセットアップ

Nginx はすでにインストールされているはずなので、それを構成して実行する必要があります。 早速役でやってみましょう。 ファイル構造を作成しましょう。

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

次に、ファイルとテンプレートが必要です。 それらの違いは、ansible がファイルをそのまま直接コピーすることです。 また、テンプレートには j2 拡張子が必要で、同じ二重中括弧を使用して変数値を使用できます。

nginxを有効にしてみましょう main.yml ファイル。 このために systemd モジュールがあります。

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

ここでは、nginx を開始する必要がある (つまり、起動する) だけでなく、すぐに有効にする必要があるとも述べています。
次に、構成ファイルをコピーしましょう。

# 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'

メインの nginx 構成ファイルを作成します (サーバーから直接取得することも、自分で作成することもできます)。 また、アプリケーションの構成ファイルも sites_available ディレクトリにあります (これは必須ではありませんが、便利です)。 最初のケースでは、copy モジュールを使用してファイルをコピーします (ファイルは /ansible/roles/nginx/files/nginx.conf）。 XNUMX つ目では、テンプレートをコピーし、変数の値を置き換えます。 テンプレートは次のとおりです /ansible/roles/nginx/templates/my_app.j2）。 そして、それは次のようになります:

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 }};
  ....
}

インサートに注目 {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — これらはすべて、Ansible がコピーする前にその値をテンプレートに代入する変数です。 これは、ホストのさまざまなグループに Playbook を使用する場合に便利です。 たとえば、インベントリ ファイルを追加できます。

[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

ここでプレイブックを起動すると、両方のホストに対して指定されたタスクが実行されます。 しかし同時に、ステージング ホストの場合、変数は本番環境の変数とは異なり、ロールやプレイブックだけでなく、nginx 構成も異なります。 {{ inventory_hostname }} インベントリーファイルで指定する必要はありません - これ 特別な ansible 変数 プレイブックが現在実行されているホストがそこに保存されます。
複数のホストのインベントリ ファイルが必要で、XNUMX つのグループに対してのみ実行したい場合は、次のコマンドを使用して実行できます。

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

もう XNUMX つのオプションは、異なるグループに対して個別のインベントリ ファイルを用意することです。 または、異なるホストが多数ある場合は、XNUMX つのアプローチを組み合わせることもできます。

nginxの設定に戻りましょう。 構成ファイルをコピーした後、sitest_enabled に sites_available から my_app.conf へのシンボリックリンクを作成する必要があります。 そして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

ここではすべてが単純です。やはり、かなり標準的な構文を持つ ansible モジュールです。 しかし、ポイントが XNUMX つあります。 毎回nginxを再起動するのは意味がありません。 「これをこうする」というようなコマンドを書いているのではなく、構文は「これはこの状態でなければならない」というようなものであることに気づいたでしょうか。 そしてほとんどの場合、これがまさに ansible の仕組みです。 グループがすでに存在する場合、またはシステム パッケージがすでにインストールされている場合、ansible はこれを確認してタスクをスキップします。 また、ファイルがサーバー上に既に存在するものと完全に一致する場合、ファイルはコピーされません。 これを利用して、構成ファイルが変更された場合にのみ nginx を再起動できます。 これには 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

設定ファイルのいずれかが変更されると、コピーが作成され、変数が登録されます。 restart_nginx。 この変数が登録されている場合にのみ、サービスが再起動されます。

そしてもちろん、nginx ロールをメイン プレイブックに追加する必要があります。

postgresqlのセットアップ

nginx の場合と同じ方法で systemd を使用して postgresql を有効にし、データベースとデータベース自体へのアクセスに使用するユーザーを作成する必要があります。
ロールを作成しましょう /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 }}"

インベントリーに変数を追加する方法、および postgresql_db および postgresql_user モジュールの構文については、すでに何度も実行されているため説明しません。 詳細については、ドキュメントを参照してください。 ここで最も興味深いディレクティブは、 become_user: postgres。 実際のところ、デフォルトでは、postgres ユーザーのみが postgresql データベースにローカルでのみアクセスできます。 このディレクティブにより、このユーザーに代わってコマンドを実行できるようになります (もちろんアクセス権がある場合)。
また、新しいユーザーがデータベースにアクセスできるようにするには、pg_hba.conf に行を追加する必要がある場合があります。 これは、nginx 構成を変更したのと同じ方法で行うことができます。

そしてもちろん、postgresql ロールをメイン プレイブックに追加する必要があります。

rbenv経由でrubyをインストールする

Ansible には rbenv を操作するためのモジュールはありませんが、git リポジトリのクローンを作成することでインストールされます。 したがって、この問題は最も非標準的な問題になります。 彼女の役割を作成しましょう /ansible/roles/ruby_rbenv/main.yml 記入を始めましょう:

# Install rbenv and ruby
- name: Install rbenv
  become_user: "{{ user }}"
  git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv

これらの目的のために作成したユーザーの下で作業するために、become_user ディレクティブを再度使用します。 rbenv はグローバルではなくホーム ディレクトリにインストールされるためです。 また、git モジュールを使用してリポジトリのクローンを作成し、repo と dest を指定します。

次に、rbenv init を bashrc に登録し、そこの PATH に rbenv を追加する必要があります。 このために、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 -)"'

次に、ruby_build をインストールする必要があります。

- name: Install ruby-build
  become_user: "{{ user }}"
  git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build

そして最後にrubyをインストールします。 これは rbenv を介して、つまり単に 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

どのコマンドを何を使って実行するかを指定します。 ただし、ここで、ansible はコマンドを実行する前に bashrc に含まれるコードを実行しないという事実に遭遇します。 これは、rbenv を同じスクリプト内で直接定義する必要があることを意味します。

次の問題は、シェル コマンドには Ansible の観点からは状態がないことが原因です。 つまり、このバージョンの Ruby がインストールされているかどうかの自動チェックは行われません。 これは自分でも行うことができます。

- 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

残っているのはバンドラーをインストールすることだけです。

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

そしてもう一度、ロール Ruby_rbenv をメイン プレイブックに追加します。

共有ファイル。

通常、セットアップはここで完了します。 次に、残っているのは、capistrano を実行することだけです。これにより、コード自体がコピーされ、必要なディレクトリが作成され、アプリケーションが起動されます (すべてが正しく構成されている場合)。 ただし、capistrano では多くの場合、次のような追加の構成ファイルが必要になります。 database.yml または .env これらは、nginx のファイルやテンプレートと同じようにコピーできます。 微妙な点が XNUMX つだけあります。 ファイルをコピーする前に、次のようなディレクトリ構造を作成する必要があります。

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

ディレクトリを XNUMX つだけ指定すると、必要に応じて Ansible が自動的に親ディレクトリを作成します。

アンシブルボールト

変数にはユーザーのパスワードなどの機密データが含まれる可能性があるという事実はすでにわかっています。 作成した場合 .env アプリケーション用のファイル、および database.yml そうすると、そのような重要なデータがさらに存在するはずです。 覗き見から隠すのが良いでしょう。 この目的のために使用されます ansible ボールト.

変数用のファイルを作成しましょう /ansible/vars/all.yml (ここでは、インベントリ ファイルと同様に、ホストの異なるグループに対して異なるファイルを作成できます:production.yml、staging.yml など)。
暗号化する必要があるすべての変数は、標準の yml 構文を使用してこのファイルに転送する必要があります。

# 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

その後、このファイルは次のコマンドで暗号化できます。

ansible-vault encrypt ./vars/all.yml

当然ですが、暗号化する場合には復号化用のパスワードを設定する必要があります。 このコマンドを呼び出した後、ファイルの内容を確認できます。

用いて ansible-vault decrypt ファイルを復号化して変更し、再度暗号化することができます。

作業するためにファイルを復号化する必要はありません。 暗号化して保存し、引数を指定してプレイブックを実行します。 --ask-vault-pass。 Ansible はパスワードを要求し、変数を取得し、タスクを実行します。 すべてのデータは暗号化されたままになります。

ホストのいくつかのグループと Ansible Vault の完全なコマンドは次のようになります。

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

ただし、プレイブックとロールの全文は提供しません。自分で書いてください。 ansible はそのようなものであるため、何をする必要があるのか​​理解していなければ、それを行うことはできません。

出所： habr.com