Ansible을 사용하여 Rails 애플리케이션을 배포하기 위한 서버 설정

얼마 전까지만 해도 저는 Rails 애플리케이션 배포를 위해 서버를 준비하기 위해 여러 Ansible 플레이북을 작성해야 했습니다. 그리고 놀랍게도 간단한 단계별 매뉴얼을 찾지 못했습니다. 무슨 일이 일어나고 있는지 이해하지 못한 채 다른 사람의 플레이북을 복사하고 싶지 않았고, 결국 문서를 읽고 모든 것을 직접 수집해야 했습니다. 아마도 이 기사의 도움으로 누군가가 이 프로세스의 속도를 높이도록 도울 수 있을 것입니다.

가장 먼저 이해해야 할 점은 ansible이 SSH를 통해 원격 서버에서 사전 정의된 작업 목록을 수행할 수 있는 편리한 인터페이스를 제공한다는 것입니다. 여기에는 마법이 없습니다. 플러그인을 설치하고 도커, 모니터링 및 기타 기능을 즉시 사용하여 애플리케이션의 다운타임 없이 배포할 수 없습니다. 플레이북을 작성하려면 정확히 무엇을 하고 싶은지, 어떻게 해야 하는지 알아야 합니다. 그렇기 때문에 나는 GitHub에서 미리 만들어진 플레이북이나 "복사하고 실행하면 작동할 것입니다."와 같은 기사에 만족하지 않습니다.

우리는 무엇이 필요한가?

이미 말했듯이 플레이북을 작성하려면 무엇을 하고 싶은지, 어떻게 해야 하는지 알아야 합니다. 무엇이 필요한지 결정합시다. Rails 애플리케이션의 경우 nginx, postgresql(redis 등)과 같은 여러 시스템 패키지가 필요합니다. 또한 특정 버전의 Ruby가 필요합니다. rbenv(rvm, asdf...)를 통해 설치하는 것이 가장 좋습니다. 이 모든 것을 루트 사용자로 실행하는 것은 항상 나쁜 생각이므로 별도의 사용자를 생성하고 해당 권한을 구성해야 합니다. 그런 다음 코드를 서버에 업로드하고 nginx, postgres 등에 대한 구성을 복사하고 이러한 모든 서비스를 시작해야 합니다.

결과적으로 일련의 작업은 다음과 같습니다.

1. 루트로 로그인
2. 시스템 패키지 설치
3. 새 사용자 생성, 권한 구성, SSH 키
4. 시스템 패키지(nginx 등)를 구성하고 실행합니다.
5. 데이터베이스에 사용자를 생성합니다. (즉시 데이터베이스를 생성할 수 있습니다.)
6. 새로운 사용자로 로그인
7. rbenv와 Ruby 설치
8. 번들러 설치
9. 애플리케이션 코드 업로드
10. 푸마 서버 시작

또한, 마지막 단계는 capistrano를 사용하여 수행할 수 있습니다. 적어도 즉시 코드를 릴리스 디렉터리에 복사하고, 성공적인 배포 시 심볼릭 링크로 릴리스를 전환하고, 공유 디렉터리에서 구성을 복사하고, puma를 다시 시작하는 등의 작업을 수행할 수 있습니다. 이 모든 작업은 Ansible을 사용하여 수행할 수 있습니다. 그런데 그 이유는 무엇일까요?

파일 구조

Ansible은 엄격하게 파일 구조 모든 파일에 대해 모든 파일을 별도의 디렉토리에 보관하는 것이 가장 좋습니다. 더욱이, 그것이 레일 애플리케이션 자체에 있을 것인지 아니면 별도로 적용될 것인지는 그다지 중요하지 않습니다. 별도의 Git 저장소에 파일을 저장할 수 있습니다. 개인적으로 저는 Rails 애플리케이션의 /config 디렉토리에 ansible 디렉토리를 생성하고 모든 것을 하나의 저장소에 저장하는 것이 가장 편리하다고 생각했습니다.

간단한 플레이북

플레이북은 특수 구문을 사용하여 Ansible이 수행해야 하는 작업과 방법을 설명하는 yml 파일입니다. 아무것도 하지 않는 첫 번째 플레이북을 만들어 보겠습니다.

---
- name: Simple playbook
  hosts: all

여기서는 간단히 플레이북의 이름을 다음과 같이 말합니다. Simple Playbook 그리고 그 내용은 모든 호스트에 대해 실행되어야 합니다. /ansible 디렉토리에 이름으로 저장할 수 있습니다. playbook.yml 그리고 다음을 실행해 보세요:

ansible-playbook ./playbook.yml

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

Ansible은 all 목록과 일치하는 호스트를 모른다고 말합니다. 특별목록에 기재되어야 합니다. 재고 파일.

동일한 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은 원격 시스템에 연결하고 정보를 수집합니다. (기본 TASK [사실 수집]) 그 후 실행에 대한 간단한 보고서를 제공합니다(PLAY RECAP).

기본적으로 연결은 시스템에 로그인한 사용자 이름을 사용합니다. 호스트에 없을 가능성이 높습니다. 플레이북 파일에서 remote_user 지시문을 사용하여 연결하는 데 사용할 사용자를 지정할 수 있습니다. 또한 원격 시스템에 대한 정보는 종종 불필요할 수 있으므로 정보를 수집하는 데 시간을 낭비해서는 안 됩니다. 이 작업을 비활성화할 수도 있습니다.

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

플레이북을 다시 실행하고 연결이 작동하는지 확인하세요. (루트 사용자를 지정한 경우 상승된 권한을 얻으려면 be: true 지시어도 지정해야 합니다. 문서에 기록된 대로: become set to ‘true’/’yes’ to activate privilege escalation. 이유가 완전히 명확하지는 않지만).

아마도 ansible이 Python 인터프리터를 결정할 수 없다는 사실로 인해 오류가 발생하는 경우 수동으로 지정할 수 있습니다.

ansible_python_interpreter: /usr/bin/python3 

다음 명령을 사용하여 Python이 있는 위치를 찾을 수 있습니다. whereis python.

시스템 패키지 설치

Ansible의 표준 배포판에는 다양한 시스템 패키지 작업을 위한 많은 모듈이 포함되어 있으므로 어떤 이유로든 bash 스크립트를 작성할 필요가 없습니다. 이제 시스템을 업데이트하고 시스템 패키지를 설치하려면 이러한 모듈 중 하나가 필요합니다. 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

작업은 Ansible이 원격 서버에서 수행하는 작업과 정확히 같습니다. 로그에서 실행을 추적할 수 있도록 작업에 이름을 지정합니다. 그리고 특정 모듈의 구문을 사용하여 해당 모듈이 수행해야 하는 작업을 설명합니다. 이 경우 apt: update_cache=yes - apt 모듈을 사용하여 시스템 패키지를 업데이트하라고 말합니다. 두 번째 명령은 조금 더 복잡합니다. 우리는 패키지 목록을 apt 모듈에 전달하고 해당 패키지가 다음과 같다고 말합니다. state 되어야한다 present, 즉, 이러한 패키지를 설치한다고 말합니다. 비슷한 방식으로 간단히 변경하여 삭제하거나 업데이트하도록 지시할 수 있습니다. state. 레일이 postgresql과 작동하려면 지금 설치 중인 postgresql-contrib 패키지가 필요합니다. 다시 말하지만, 이를 알고 수행해야 합니다. Ansible 자체로는 이 작업을 수행할 수 없습니다.

플레이북을 다시 실행하고 패키지가 설치되었는지 확인하세요.

새로운 사용자를 생성합니다.

사용자와 작업하기 위해 Ansible에는 user라는 모듈도 있습니다. 작업을 하나 더 추가해 보겠습니다. (매번 전체 내용을 복사하지 않도록 이미 알려진 플레이북 부분을 댓글 뒤에 숨겼습니다.)

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

새로운 사용자를 생성하고 이에 대한 schell과 비밀번호를 설정합니다. 그리고 우리는 몇 가지 문제에 직면하게 됩니다. 호스트마다 사용자 이름이 달라야 하는 경우 어떻게 해야 합니까? 그리고 플레이북에 비밀번호를 일반 텍스트로 저장하는 것은 매우 나쁜 생각입니다. 먼저 사용자 이름과 비밀번호를 변수에 입력하고, 기사 마지막 부분에서 비밀번호를 암호화하는 방법을 보여드리겠습니다.

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

변수는 이중 중괄호를 사용하여 플레이북에 설정됩니다.

인벤토리 파일에 변수 값을 표시합니다.

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와 매우 유사한 구문을 사용하여 그룹을 생성하기 위한 그룹 모듈도 있습니다. 그런 다음 이 그룹을 사용자에게 등록하면 충분합니다(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 키의 공개 부분을 복사하여 서버의 사용자에 대해 인증된 키 목록에 업로드합니다.

역할

활용을 위한 세 가지 작업은 모두 하나의 작업 그룹으로 쉽게 분류할 수 있으며, 이 그룹은 너무 커지지 않도록 메인 플레이북과 별도로 보관해 두는 것이 좋을 것 같습니다. 이를 위해 Ansible은 역할.
맨 처음에 표시된 파일 구조에 따르면 역할은 별도의 역할 디렉터리에 배치되어야 합니다. 각 역할에는 작업, 파일, 템플릿 등 디렉터리 내에 동일한 이름을 가진 별도의 디렉터리가 있습니다.
파일 구조를 만들어 보겠습니다. ./ansible/roles/user/tasks/main.yml (main은 역할이 플레이북에 연결될 때 로드되고 실행될 기본 파일입니다. 다른 역할 파일도 여기에 연결할 수 있습니다.) 이제 사용자와 관련된 모든 작업을 이 파일로 전송할 수 있습니다.

# 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 디렉터리에 우리 애플리케이션을 위한 구성 파일도 있습니다(필수는 아니지만 유용합니다). 첫 번째 경우에는 복사 모듈을 사용하여 파일을 복사합니다(파일은 다음 위치에 있어야 함). /ansible/roles/nginx/files/nginx.conf). 두 번째에서는 변수 값을 대체하여 템플릿을 복사합니다. 템플릿은 다음 위치에 있어야 합니다. /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이 복사하기 전에 템플릿으로 대체할 값을 갖는 모든 변수입니다. 이는 다양한 호스트 그룹에 대해 플레이북을 사용하는 경우 유용합니다. 예를 들어, 재고 파일을 추가할 수 있습니다.

[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 변수 플레이북이 현재 실행 중인 호스트가 여기에 저장됩니다.
여러 호스트에 대한 인벤토리 파일을 갖고 싶지만 한 그룹에 대해서만 실행하려면 다음 명령을 사용하면 됩니다.

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

또 다른 옵션은 여러 그룹에 대해 별도의 인벤토리 파일을 갖는 것입니다. 또는 호스트가 여러 개인 경우 두 가지 접근 방식을 결합할 수 있습니다.

nginx 설정으로 돌아가 보겠습니다. 구성 파일을 복사한 후 sites_available에서 my_app.conf로 연결되는 sitest_enabled의 심볼릭 링크를 생성해야 합니다. 그리고 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 모듈입니다. 그러나 한 가지 점이 있습니다. 매번 nginx를 다시 시작하는 것은 의미가 없습니다. 우리가 "이렇게 하세요"와 같은 명령을 작성하지 않고 구문은 "이것은 이 상태를 가져야 합니다"와 비슷해 보입니다. 그리고 대부분의 경우 이것이 바로 Ansible이 작동하는 방식입니다. 그룹이 이미 존재하거나 시스템 패키지가 이미 설치된 경우 ansible은 이를 확인하고 작업을 건너뜁니다. 또한 파일이 이미 서버에 있는 것과 완전히 일치하면 파일이 복사되지 않습니다. 구성 파일이 변경된 경우에만 이를 활용하고 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
  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 역할을 추가해야 합니다.

포스트그레SQL 설정

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

우리는 이러한 목적으로 생성한 사용자 아래에서 작업하기 위해 다시 make_user 지시어를 사용합니다. rbenv는 전역이 아닌 홈 디렉터리에 설치되기 때문입니다. 또한 git 모듈을 사용하여 repo 및 dest를 지정하여 저장소를 복제합니다.

다음으로, bashrc에 rbenv init를 등록하고 그곳의 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용 파일 및 템플릿과 마찬가지로 복사할 수 있습니다. 단 하나의 미묘함이 있습니다. 파일을 복사하기 전에 다음과 같은 디렉터리 구조를 만들어야 합니다.

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

우리는 하나의 디렉토리만 지정하고 ansible은 필요한 경우 상위 디렉토리를 자동으로 생성합니다.

앤서블 볼트

우리는 변수에 사용자 비밀번호와 같은 비밀 데이터가 포함될 수 있다는 사실을 이미 접했습니다. 생성한 경우 .env 신청서 파일과 database.yml 그러면 그러한 중요한 데이터가 훨씬 더 많아야 합니다. 엿보는 눈으로부터 숨기는 것이 좋을 것입니다. 이러한 목적으로 사용됩니다 앤서블 볼트.

변수에 대한 파일을 만들어 보겠습니다. /ansible/vars/all.yml (여기서 인벤토리 파일(production.yml, stage.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은 그런 것이기 때문입니다. 수행해야 할 작업을 이해하지 못하면 Ansible이 해당 작업을 수행하지 않습니다.

출처 : habr.com