Подешавање сервера за примену Раилс апликације користећи Ансибле

Недавно сам морао да напишем неколико Ансибле плаибоок-а да припремим сервер за примену Раилс апликације. И, изненађујуће, нисам нашао једноставан приручник корак по корак. Нисам желео да копирам туђу књигу а да не разумем шта се дешава, и на крају сам морао да прочитам документацију и све сам прикупио. Можда могу помоћи некоме да убрза овај процес уз помоћ овог чланка.

Прва ствар коју треба разумети је да вам ансибле пружа згодан интерфејс за обављање унапред дефинисане листе акција на удаљеним серверима путем ССХ-а. Нема ту никакве магије, не можете да инсталирате додатак и добијете нулту имплементацију ваше апликације са доцкер-ом, надгледањем и другим добротама из кутије. Да бисте написали књигу, морате знати шта тачно желите да радите и како то да урадите. Зато нисам задовољан готовим приручницима са ГитХуб-а или чланцима попут: „Копирај и покрени, радиће“.

Оно што нам треба?

Као што сам већ рекао, да бисте написали свеску морате да знате шта желите да радите и како да то урадите. Хајде да одлучимо шта нам треба. За Раилс апликацију биће нам потребно неколико системских пакета: нгинк, постгрескл (редис, итд.). Поред тога, потребна нам је посебна верзија рубина. Најбоље га је инсталирати преко рбенв (рвм, асдф...). Покретање свега овога као роот корисник је увек лоша идеја, тако да морате да креирате посебног корисника и конфигуришете његова права. Након овога, потребно је да отпремите наш код на сервер, копирате конфигурације за нгинк, постгрес итд. и покренете све ове услуге.

Као резултат, редослед акција је следећи:

1. Пријавите се као роот
2. инсталирајте системске пакете
3. креирајте новог корисника, конфигуришите права, ссх кључ
4. конфигуришите системске пакете (нгинк итд.) и покрените их
5. Креирамо корисника у бази података (можете одмах креирати базу података)
6. Пријавите се као нови корисник
7. Инсталирајте рбенв и руби
8. Инсталирање пакета
9. Отпремање кода апликације
10. Покретање Пума сервера

Штавише, последње фазе се могу обавити помоћу цапистрано-а, барем из кутије може копирати код у директоријуме издања, пребацити издање симболичком везом након успешног постављања, копирати конфигурације из дељеног директоријума, поново покренути Пуму, итд. Све ово се може урадити помоћу Ансибле-а, али зашто?

Структура датотеке

Ансибле има строге структура датотеке за све ваше датотеке, тако да је најбоље да све то држите у посебном директоријуму. Штавише, није толико важно да ли ће бити у самој апликацији шина или одвојено. Можете да складиштите датотеке у засебно гит спремиште. Лично, сматрао сам да је најпогодније да креирам ансибле директоријум у директоријуму /цонфиг раилс апликације и све чувам у једном спремишту.

Симпле Плаибоок

Плаибоок је имл датотека која, користећи посебну синтаксу, описује шта Ансибле треба да ради и како. Хајде да направимо прву књигу која не ради ништа:

---
- name: Simple playbook
  hosts: all

Овде једноставно кажемо да се наша књига играња зове Simple Playbook и да његов садржај треба да се изврши за све хостове. Можемо га сачувати у /ансибле директоријуму са именом playbook.yml и покушајте да покренете:

ansible-playbook ./playbook.yml

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

Ансибле каже да не познаје ниједан домаћин који одговара листи свих. Они морају бити наведени у посебном досије инвентара.

Хајде да га направимо у истом ансибле директоријуму:

123.123.123.123

Овако једноставно одредимо хост (идеално домаћин нашег ВПС-а за тестирање, или можете регистровати лоцалхост) и сачувати га под именом inventory.
Можете покушати да покренете ансибле са датотеком инвентара:

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

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

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

Ако имате ссх приступ наведеном хосту, ансибле ће се повезати и прикупити информације о удаљеном систему. (подразумевани ЗАДАТАК [Гатхеринг Фацтс]) након чега ће дати кратак извештај о извршењу (ПЛАИ РЕЦАП).

Подразумевано, веза користи корисничко име под којим сте пријављени у систем. Највероватније неће бити на домаћину. У датотеци плаибоок-а можете одредити ког корисника да користите за повезивање помоћу директиве ремоте_усер. Такође, информације о удаљеном систему могу вам често бити непотребне и не бисте требали губити време на њихово прикупљање. Овај задатак се такође може онемогућити:

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

Покушајте поново да покренете плаибоок и уверите се да веза ради. (Ако сте навели роот корисника, онда морате да наведете и директиву поста: труе да бисте добили повишена права. Као што је написано у документацији: become set to ‘true’/’yes’ to activate privilege escalation. иако није сасвим јасно зашто).

Можда ћете добити грешку узроковану чињеницом да ансибле не може да одреди Питхон интерпретер, онда можете да је одредите ручно:

ansible_python_interpreter: /usr/bin/python3 

Можете сазнати где имате Питхон помоћу команде whereis python.

Инсталирање системских пакета

Ансиблеова стандардна дистрибуција укључује многе модуле за рад са различитим системским пакетима, тако да не морамо да пишемо басх скрипте из било ког разлога. Сада нам је потребан један од ових модула да ажурирамо систем и инсталирамо системске пакете. Имам Убунту Линук на свом ВПС-у, тако да инсталирам пакете које користим 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

Задатак је управо задатак који ће Ансибле обављати на удаљеним серверима. Задатку дајемо име како бисмо могли да пратимо његово извршење у дневнику. И описујемо, користећи синтаксу одређеног модула, шта треба да уради. У овом случају apt: update_cache=yes - каже да ажурирате системске пакете користећи апт модул. Друга команда је мало компликованија. Проследимо листу пакета модулу апт и кажемо да јесу state треба да постане present, односно кажемо да инсталирамо ове пакете. На сличан начин можемо им рећи да их избришу или ажурирају једноставном променом state. Имајте на уму да нам је потребан пакет постгрескл-цонтриб да би шине радиле са постгрескл-ом, који сада инсталирамо. Опет, морате знати и учинити ово; ансибле сам по себи то неће учинити.

Покушајте поново да покренете плаибоок и проверите да ли су пакети инсталирани.

Стварање нових корисника.

За рад са корисницима, Ансибле има и модул – корисник. Хајде да додамо још један задатак (сакрио сам већ познате делове читанке иза коментара да га не бих сваки пут потпуно копирао):

---
- 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') }}"

Променљиве се постављају у читаоцима помоћу двоструких витичастих заграда.

Назначићемо вредности променљивих у датотеци инвентара:

123.123.123.123

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

Обратите пажњу на директиву [all:vars] - каже да су следећи блок текста променљиве (варс) и оне су применљиве на све хостове (све).

Дизајн је такође занимљив "{{ user_password | password_hash('sha512') }}". Ствар је у томе што ансибле не инсталира корисника преко user_add као да бисте то урадили ручно. И директно чува све податке, због чега такође морамо унапред претворити лозинку у хеш, што ова команда ради.

Хајде да додамо нашег корисника у судо групу. Међутим, пре тога морамо да се уверимо да таква група постоји јер нико ово неће урадити уместо нас:

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

Све је прилично једноставно, имамо и групни модул за креирање група, са синтаксом веома сличном апт. Тада је довољно да ову групу региструјете кориснику (groups: "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"
    - name: Deploy SSH Key
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

У овом случају, дизајн је занимљив "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — копира садржај датотеке ид_рса.пуб (ваше име може бити другачије), односно јавни део ссх кључа и поставља га на листу овлашћених кључева за корисника на серверу.

Улоге

Сва три задатка за креирање употребе лако се могу сврстати у једну групу задатака и било би добро да ову групу складиштите одвојено од главне књиге како не би постала превелика. За ову сврху, Ансибле има улогу.
У складу са структуром датотека која је назначена на самом почетку, улоге морају бити смештене у посебан директоријум улога, за сваку улогу постоји посебан директоријум са истим именом, унутар директоријума задатака, датотека, шаблона итд.
Хајде да направимо структуру датотеке: ./ansible/roles/user/tasks/main.yml (маин је главна датотека која ће бити учитана и извршена када се улога повеже са плаибоок-ом; друге датотеке улога могу бити повезане са њом). Сада можете пренети све задатке који се односе на корисника у ову датотеку:

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

Подешавање нгинк-а

Већ би требало да имамо инсталиран Нгинк; морамо да га конфигуришемо и покренемо. Урадимо то одмах у улози. Хајде да направимо структуру датотеке:

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

Сада су нам потребне датотеке и шаблони. Разлика између њих је у томе што ансибле директно копира датотеке, такве какве јесу. А шаблони морају имати екстензију ј2 и могу користити променљиве вредности користећи исте дупле витичасте заграде.

Хајде да омогућимо нгинк main.yml фајл. За ово имамо системд модул:

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

Овде не само да кажемо да се нгинк мора покренути (односно да га покрећемо), већ одмах кажемо да мора бити омогућен.
Сада копирајмо конфигурационе датотеке:

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

Креирамо главну нгинк конфигурациону датотеку (можете је преузети директно са сервера или је сами написати). И такође конфигурациони фајл за нашу апликацију у директоријуму ситес_аваилабле (ово није неопходно, али корисно). У првом случају користимо модул за копирање за копирање датотека (датотека мора бити у /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 }} — ово су све променљиве чије вредности ће Ансибле заменити у шаблону пре копирања. Ово је корисно ако користите приручник за различите групе домаћина. На пример, можемо додати нашу датотеку инвентара:

[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

Ако сада покренемо наш плаибоок, он ће извршити наведене задатке за оба домаћина. Али у исто време, за хост за постављање, варијабле ће се разликовати од оних у продукцији, и то не само у улогама и приручницима, већ иу нгинк конфигурацијама. {{ inventory_hostname }} не треба навести у досијеу инвентара – ово посебна ансибле променљива и тамо се чува хост за који је плаибоок тренутно покренут.
Ако желите да имате датотеку инвентара за неколико хостова, али да се покренете само за једну групу, то се може урадити следећом командом:

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

Друга опција је да имате засебне датотеке инвентара за различите групе. Или можете комбиновати два приступа ако имате много различитих домаћина.

Вратимо се на подешавање нгинк-а. Након копирања конфигурационих датотека, потребно је да креирамо симболичку везу у ситест_енаблед до ми_апп.цонф са ситес_аваилабле. И поново покрените нгинк.

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

Овде је све једноставно - опет ансибле модули са прилично стандардном синтаксом. Али постоји једна тачка. Нема смисла сваки пут поново покретати нгинк. Да ли сте приметили да не пишемо команде попут: „уради ово овако“, синтакса више изгледа као „ово би требало да има ово стање“. А најчешће управо тако функционише ансибле. Ако група већ постоји или је системски пакет већ инсталиран, ансибле ће то проверити и прескочити задатак. Такође, датотеке неће бити копиране ако у потпуности одговарају ономе што се већ налази на серверу. Ово можемо искористити и поново покренути нгинк само ако су конфигурационе датотеке промењене. За ово постоји директива о регистру:

# 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. И само ако је ова променљива регистрована, сервис ће бити поново покренут.

И, наравно, морате да додате нгинк улогу у главну књигу.

Подешавање постгрескл-а

Морамо да омогућимо постгрескл користећи системд на исти начин као што смо урадили са нгинк-ом, а такође и да креирамо корисника којег ћемо користити за приступ бази података и самој бази података.
Хајде да направимо улогу /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 }}"

Нећу описивати како додати променљиве у инвентар, то је већ урађено много пута, као и синтаксу модула постгрескл_дб и постгрескл_усер. Више информација можете пронаћи у документацији. Овде је најинтересантнија директива become_user: postgres. Чињеница је да подразумевано само постгрес корисник има приступ постгрескл бази података и то само локално. Ова директива нам омогућава да извршавамо команде у име овог корисника (ако имамо приступ, наравно).
Такође, можда ћете морати да додате ред у пг_хба.цонф да бисте новом кориснику омогућили приступ бази података. Ово се може урадити на исти начин као што смо променили нгинк конфигурацију.

И наравно, потребно је да додате улогу постгрескл у главну књигу.

Инсталирање руби-а преко рбенв-а

Ансибле нема модуле за рад са рбенв-ом, али се инсталира клонирањем гит спремишта. Стога, овај проблем постаје најнестандарднији. Хајде да јој направимо улогу /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

Поново користимо директиву бецоме_усер за рад под корисником којег смо креирали за ове сврхе. Пошто је рбенв инсталиран у свом матичном директоријуму, а не глобално. Такође користимо гит модул за клонирање спремишта, наводећи репо и одредиште.

Затим морамо регистровати рбенв инит у басхрц и тамо додати рбенв у ПАТХ. За ово имамо модул линеинфиле:

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

Затим морате да инсталирате руби_буилд:

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

И на крају инсталирајте руби. Ово се ради преко рбенв-а, односно једноставно са басх командом:

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

Ми кажемо коју команду да извршимо и са чиме. Међутим, овде наилазимо на чињеницу да ансибле не покреће код садржан у басхрц-у пре него што покрене команде. То значи да ће рбенв морати да се дефинише директно у истој скрипти.

Следећи проблем је због чињенице да наредба љуске нема стање са ансибле тачке гледишта. Односно, неће бити аутоматске провере да ли је ова верзија руби инсталирана или не. То можемо сами да урадимо:

- 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

И опет, додајте нашу улогу руби_рбенв у главну књигу.

Дељене датотеке.

Генерално, подешавање би се могло завршити овде. Даље, остаје само да покренете цапистрано и он ће сам копирати код, креирати потребне директоријуме и покренути апликацију (ако је све исправно конфигурисано). Међутим, цапистрано често захтева додатне конфигурационе датотеке, као нпр database.yml или .env Могу се копирати баш као датотеке и шаблони за нгинк. Постоји само једна суптилност. Пре копирања датотека, потребно је да креирате структуру директоријума за њих, отприлике овако:

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

наводимо само један директоријум и ансибле ће аутоматски креирати родитељске ако је потребно.

Ансибле Ваулт

Већ смо наишли на чињеницу да променљиве могу да садрже тајне податке као што је корисничка лозинка. Ако сте креирали .env фајл за пријаву, и database.yml онда таквих критичних података мора бити још више. Било би добро сакрити их од знатижељних очију. У ту сврху се користи ансибле ваулт.

Хајде да направимо датотеку за променљиве /ansible/vars/all.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-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass

Али нећу вам дати цео текст књига и улога, напишите га сами. Јер ансибле је такав - ако не разумете шта треба да се уради, онда то неће учинити уместо вас.

Извор: ввв.хабр.цом