🥇 Stel 'n bediener op om 'n Rails-toepassing te ontplooi met Ansible

Nie lank gelede nie moes ek verskeie Ansible-speelboeke skryf om die bediener voor te berei vir die implementering van 'n Rails-toepassing. En, verbasend genoeg, het ek nie 'n eenvoudige stap-vir-stap handleiding gevind nie. Ek wou nie iemand anders se speelboek kopieer sonder om te verstaan wat aan die gebeur is nie, en op die ou end moes ek die dokumentasie lees en alles self versamel. Miskien kan ek iemand help om hierdie proses te bespoedig met behulp van hierdie artikel.

Die eerste ding om te verstaan is dat ansible jou 'n gerieflike koppelvlak bied om 'n voorafbepaalde lys aksies op 'n afgeleë bediener(s) via SSH uit te voer. Daar is geen toorkuns hier nie, jy kan nie 'n inprop installeer en 'n nul-stilstand-ontplooiing van jou toepassing kry met docker, monitering en ander goedjies uit die boks nie. Om 'n speelboek te skryf, moet jy presies weet wat jy wil doen en hoe om dit te doen. Dit is hoekom ek nie tevrede is met klaargemaakte speelboeke van GitHub, of artikels soos: "Kopieer en hardloop, dit sal werk nie."

Wat het ons nodig?

Soos ek reeds gesê het, om 'n speelboek te skryf moet jy weet wat jy wil doen en hoe om dit te doen. Kom ons besluit wat ons nodig het. Vir 'n Rails-toepassing sal ons verskeie stelselpakkette benodig: nginx, postgresql (redis, ens.). Daarbenewens het ons 'n spesifieke weergawe van robyn nodig. Dit is die beste om dit te installeer via rbenv (rvm, asdf ...). Om dit alles as 'n wortelgebruiker te laat loop, is altyd 'n slegte idee, so jy moet 'n aparte gebruiker skep en sy regte instel. Hierna moet u ons kode na die bediener oplaai, die konfigurasies vir nginx, postgres, ens kopieer en al hierdie dienste begin.

As gevolg hiervan is die volgorde van aksies soos volg:

Teken in as root
installeer stelselpakkette
skep 'n nuwe gebruiker, konfigureer regte, ssh sleutel
stel stelselpakkette op (nginx ens.) en laat loop dit
Ons skep 'n gebruiker in die databasis (jy kan dadelik 'n databasis skep)
Teken in as 'n nuwe gebruiker
Installeer rbenv en ruby
Installeer die bondler
Laai tans die toepassingskode op
Begin die Puma-bediener

Boonop kan die laaste fases gedoen word met behulp van capistrano, ten minste uit die boks kan dit kode na vrystellingsgidse kopieer, die vrystelling met 'n simskakel oorskakel na suksesvolle ontplooiing, kopieer konfigurasies vanaf 'n gedeelde gids, herbegin puma, ens. Dit alles kan met Ansible gedoen word, maar hoekom?

Lêerstruktuur

Ansible het streng lêerstruktuur vir al jou lêers, dus is dit die beste om dit alles in 'n aparte gids te hou. Boonop is dit nie so belangrik of dit in die relingstoepassing self of afsonderlik sal wees nie. U kan lêers in 'n aparte git-bewaarplek stoor. Persoonlik het ek dit die gerieflikste gevind om 'n moontlike gids in die /config-gids van die rails-toepassing te skep en alles in een bewaarplek te stoor.

Eenvoudige speelboek

Playbook is 'n yml-lêer wat, met behulp van spesiale sintaksis, beskryf wat Ansible moet doen en hoe. Kom ons skep die eerste speelboek wat niks doen nie:

---
- name: Simple playbook
  hosts: all

Hier sê ons eenvoudig dat ons speelboek genoem word Simple Playbook en dat die inhoud daarvan vir alle gashere uitgevoer moet word. Ons kan dit stoor in /ansible gids met die naam playbook.yml en probeer hardloop:

ansible-playbook ./playbook.yml

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

Ansible sê hy ken nie enige gashere wat by die alle lys pas nie. Hulle moet in 'n spesiale gelys word voorraadlêer.

Kom ons skep dit in dieselfde moontlike gids:

123.123.123.123

Dit is hoe ons eenvoudig die gasheer spesifiseer (ideaal die gasheer van ons VPS vir toetsing, of jy kan plaaslike gasheer registreer) en stoor dit onder die naam inventory.
Jy kan probeer om ansible met 'n inventarislêer te laat loop:

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

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

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

As jy ssh-toegang tot die gespesifiseerde gasheer het, sal ansible koppel en inligting oor die afgeleë stelsel insamel. (verstek TAAK [Insameling van feite]) waarna dit 'n kort verslag sal gee oor die uitvoering (PLAY RECAP).

By verstek gebruik die verbinding die gebruikersnaam waaronder jy by die stelsel aangemeld is. Dit sal heel waarskynlik nie op die gasheer wees nie. In die speelboeklêer kan jy spesifiseer watter gebruiker om te gebruik om te koppel deur die remote_user-aanwysing te gebruik. Ook, inligting oor 'n afgeleë stelsel kan dikwels vir jou onnodig wees en jy moet nie tyd mors om dit in te samel nie. Hierdie taak kan ook gedeaktiveer word:

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

Probeer die speelboek weer laat loop en maak seker dat die verbinding werk. (As jy die wortelgebruiker gespesifiseer het, moet jy ook die word: true-direktief spesifiseer om verhoogde regte te verkry. Soos geskryf in die dokumentasie: become set to ‘true’/’yes’ to activate privilege escalation. hoewel dit nie heeltemal duidelik is hoekom nie).

Miskien sal jy 'n fout ontvang wat veroorsaak word deur die feit dat ansible nie die Python-tolk kan bepaal nie, dan kan jy dit met die hand spesifiseer:

ansible_python_interpreter: /usr/bin/python3

Jy kan uitvind waar jy python het met die opdrag whereis python.

Installeer stelselpakkette

Ansible se standaardverspreiding sluit baie modules in om met verskeie stelselpakkette te werk, so ons hoef om geen rede bash-skrifte te skryf nie. Nou het ons een van hierdie modules nodig om die stelsel op te dateer en stelselpakkette te installeer. Ek het Ubuntu Linux op my VPS, so om pakkette te installeer wat ek gebruik apt-get и module daarvoor. As jy 'n ander bedryfstelsel gebruik, sal jy dalk 'n ander module nodig hê (onthou, ek het aan die begin gesê ons moet vooraf weet wat en hoe ons sal doen). Die sintaksis sal egter heel waarskynlik soortgelyk wees.

Kom ons vul ons speelboek aan met die eerste take:

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

Taak is presies die taak wat Ansible op afgeleë bedieners sal uitvoer. Ons gee die taak 'n naam sodat ons die uitvoering daarvan in die log kan dop. En ons beskryf, deur die sintaksis van 'n spesifieke module te gebruik, wat dit moet doen. In hierdie geval apt: update_cache=yes - sê om stelselpakkette op te dateer met behulp van die apt-module. Die tweede opdrag is 'n bietjie meer ingewikkeld. Ons gee 'n lys van pakkette aan die gepaste module en sê dat hulle is state moet word present, dit wil sê, ons sê installeer hierdie pakkette. Op 'n soortgelyke manier kan ons hulle vertel om hulle uit te vee, of hulle opdateer deur eenvoudig te verander state. Neem asseblief kennis dat vir rails om met postgresql te werk, ons die postgresql-contrib-pakket benodig, wat ons nou installeer. Weereens, jy moet dit weet en doen; ansible op sy eie sal dit nie doen nie.

Probeer weer die speelboek laat loop en maak seker dat die pakkette geïnstalleer is.

Die skep van nuwe gebruikers.

Om met gebruikers te werk, het Ansible ook 'n module - gebruiker. Kom ons voeg nog een taak by (ek het die reeds bekende dele van die speelboek agter die opmerkings weggesteek om dit nie elke keer heeltemal te kopieer nie):

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

Ons skep 'n nuwe gebruiker, stel 'n skema en wagwoord daarvoor. En dan loop ons verskeie probleme teë. Wat as gebruikersname anders moet wees vir verskillende gashere? En om die wagwoord in duidelike teks in die speelboek te stoor, is 'n baie slegte idee. Om mee te begin, laat ons die gebruikersnaam en wagwoord in veranderlikes plaas, en aan die einde van die artikel sal ek wys hoe om die wagwoord te enkripteer.

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

Veranderlikes word in speelboeke gestel deur dubbele krulhakies te gebruik.

Ons sal die waardes van die veranderlikes in die voorraadlêer aandui:

123.123.123.123

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

Let asseblief op die richtlijn [all:vars] - dit sê dat die volgende blok teks veranderlikes (vars) is en hulle is van toepassing op alle gashere (almal).

Die ontwerp is ook interessant "{{ user_password | password_hash('sha512') }}". Die ding is dat ansible nie die gebruiker via installeer nie user_add soos jy dit met die hand sou doen. En dit stoor alle data direk, en daarom moet ons ook die wagwoord vooraf in 'n hash omskakel, wat is wat hierdie opdrag doen.

Kom ons voeg ons gebruiker by die sudo-groep. Voor dit moet ons egter seker maak dat so 'n groep bestaan, want niemand sal dit vir ons doen nie:

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

Alles is redelik eenvoudig, ons het ook 'n groepmodule om groepe te skep, met 'n sintaksis wat baie soortgelyk is aan apt. Dan is dit genoeg om hierdie groep by die gebruiker te registreer (groups: "sudo").
Dit is ook nuttig om 'n ssh-sleutel by hierdie gebruiker te voeg sodat ons kan aanmeld sonder 'n wagwoord:

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

In hierdie geval is die ontwerp interessant "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — dit kopieer die inhoud van die id_rsa.pub-lêer (jou naam kan anders wees), dit wil sê die publieke deel van die ssh-sleutel en laai dit op na die lys gemagtigde sleutels vir die gebruiker op die bediener.

rol

Al drie take vir die skep van gebruik kan maklik in een groep take geklassifiseer word, en dit sal 'n goeie idee wees om hierdie groep apart van die hoofspeelboek te stoor sodat dit nie te groot word nie. Vir hierdie doel het Ansible rol.
Volgens die lêerstruktuur wat heel aan die begin aangedui is, moet rolle in 'n aparte rollegids geplaas word, vir elke rol is daar 'n aparte gids met dieselfde naam, binne die take, lêers, sjablone, ens gids
Kom ons skep 'n lêerstruktuur: ./ansible/roles/user/tasks/main.yml (hoof is die hooflêer wat gelaai en uitgevoer sal word wanneer 'n rol aan die speelboek gekoppel word; ander rollêers kan daaraan gekoppel word). Nou kan jy alle take wat verband hou met die gebruiker na hierdie lêer oordra:

# 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

In die hoofspeelboek moet jy spesifiseer om die gebruikersrol te gebruik:

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

Dit kan ook sin maak om die stelsel voor alle ander take op te dateer; om dit te doen, kan jy die blok hernoem tasks waarin hulle gedefinieer word in pre_tasks.

Stel nginx op

Ons behoort reeds Nginx geïnstalleer te hê; ons moet dit konfigureer en laat loop. Kom ons doen dit dadelik in die rol. Kom ons skep 'n lêerstruktuur:

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

Nou benodig ons lêers en sjablone. Die verskil tussen hulle is dat ansible die lêers direk kopieer, soos dit is. En sjablone moet die j2-uitbreiding hê en hulle kan veranderlike waardes gebruik met dieselfde dubbele krulhakies.

Kom ons aktiveer nginx in main.yml lêer. Hiervoor het ons 'n stelselmodule:

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

Hier sê ons nie net dat nginx begin moet word nie (dit wil sê ons begin dit), maar ons sê dadelik dat dit geaktiveer moet word.
Kom ons kopieer nou die konfigurasielêers:

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

Ons skep die hoof nginx-konfigurasielêer (jy kan dit direk vanaf die bediener neem, of dit self skryf). En ook die konfigurasielêer vir ons toepassing in die sites_available-gids (dit is nie nodig nie, maar nuttig). In die eerste geval gebruik ons die kopieermodule om lêers te kopieer (die lêer moet in /ansible/roles/nginx/files/nginx.conf). In die tweede kopieer ons die sjabloon deur die waardes van die veranderlikes te vervang. Die sjabloon moet in wees /ansible/roles/nginx/templates/my_app.j2). En dit kan so iets lyk:

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

Gee aandag aan die insetsels {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} - dit is al die veranderlikes waarvan die waardes Ansible in die sjabloon sal vervang voordat dit gekopieer word. Dit is nuttig as jy 'n speelboek vir verskillende groepe gashere gebruik. Ons kan byvoorbeeld ons voorraadlêer byvoeg:

[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

As ons nou ons speelboek begin, sal dit die gespesifiseerde take vir beide gashere uitvoer. Maar terselfdertyd, vir 'n opvoergasheer, sal die veranderlikes verskil van die produksies, en nie net in rolle en speelboeke nie, maar ook in nginx-konfigurasies. {{ inventory_hostname }} hoef nie in die voorraadlêer gespesifiseer te word nie - dit spesiale moontlike veranderlike en die gasheer waarvoor die speelboek tans loop, word daar gestoor.
As jy 'n voorraadlêer vir verskeie gashere wil hê, maar net vir een groep loop, kan dit gedoen word met die volgende opdrag:

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

Nog 'n opsie is om aparte voorraadlêers vir verskillende groepe te hê. Of jy kan die twee benaderings kombineer as jy baie verskillende gashere het.

Kom ons gaan terug na die opstel van nginx. Nadat ons die konfigurasielêers gekopieer het, moet ons 'n simboliek in sitest_enabled na my_app.conf vanaf sites_available skep. En herbegin 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

Alles is eenvoudig hier - weereens moontlike modules met 'n redelik standaard sintaksis. Maar daar is een punt. Dit is geen sin om nginx elke keer weer te begin nie. Het jy opgelet dat ons nie opdragte soos: "doen dit so" skryf nie, die sintaksis lyk meer soos "hierdie moet hierdie toestand hê". En dit is meestal presies hoe ansible werk. As die groep reeds bestaan, of die stelselpakket is reeds geïnstalleer, sal ansible daarvoor kyk en die taak oorslaan. Lêers sal ook nie gekopieer word as hulle heeltemal ooreenstem met wat reeds op die bediener is nie. Ons kan voordeel hiervan trek en nginx net herbegin as die konfigurasielêers verander is. Daar is 'n registervoorskrif hiervoor:

# 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

As een van die konfigurasielêers verander, sal 'n kopie gemaak word en die veranderlike sal geregistreer word restart_nginx. En slegs as hierdie veranderlike geregistreer is, sal die diens herbegin word.

En natuurlik moet jy die nginx-rol by die hoofspeelboek voeg.

Die opstel van postgresql

Ons moet postgresql aktiveer met behulp van systemd op dieselfde manier as wat ons met nginx gedoen het, en ook 'n gebruiker skep wat ons sal gebruik om toegang tot die databasis en die databasis self te verkry.
Kom ons skep 'n rol /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 }}"

Ek sal nie beskryf hoe om veranderlikes by voorraad te voeg nie, dit is al baie keer gedoen, asook die sintaksis van die postgresql_db en postgresql_user modules. Meer inligting kan in die dokumentasie gevind word. Die interessantste opdrag hier is become_user: postgres. Die feit is dat slegs die postgres-gebruiker by verstek toegang het tot die postgresql-databasis en slegs plaaslik. Hierdie opdrag stel ons in staat om opdragte namens hierdie gebruiker uit te voer (as ons natuurlik toegang het).
U moet ook dalk 'n reël by pg_hba.conf voeg om 'n nuwe gebruiker toegang tot die databasis toe te laat. Dit kan gedoen word op dieselfde manier as wat ons die nginx-konfigurasie verander het.

En natuurlik moet jy die postgresql-rol by die hoofspeelboek voeg.

Installeer ruby via rbenv

Ansible het nie modules om met rbenv te werk nie, maar dit word geïnstalleer deur 'n git-bewaarplek te kloneer. Daarom word hierdie probleem die mees nie-standaard een. Kom ons skep 'n rol vir haar /ansible/roles/ruby_rbenv/main.yml en kom ons begin dit invul:

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

Ons gebruik weer die word_user-instruksie om onder die gebruiker te werk wat ons vir hierdie doeleindes geskep het. Aangesien rbenv in sy tuisgids geïnstalleer is, en nie wêreldwyd nie. En ons gebruik ook die git-module om die repository te kloon, wat repo en dest spesifiseer.

Vervolgens moet ons rbenv init in bashrc registreer en rbenv daar by PATH voeg. Hiervoor het ons die lineinfile-module:

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

Dan moet jy ruby_build installeer:

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

En uiteindelik installeer ruby. Dit word gedoen deur rbenv, dit wil sê, eenvoudig met die bash-opdrag:

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

Ons sê watter opdrag om uit te voer en met watter. Hier kom ons egter oor die feit dat ansible nie die kode wat in bashrc vervat is, laat loop voordat die opdragte uitgevoer word nie. Dit beteken dat rbenv direk in dieselfde skrif gedefinieer sal moet word.

Die volgende probleem is te wyte aan die feit dat die dop-opdrag geen toestand het vanuit 'n moontlike oogpunt nie. Dit wil sê, daar sal geen outomatiese kontrole wees of hierdie weergawe van ruby geïnstalleer is of nie. Ons kan dit self doen:

- 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

Al wat oorbly is om bundler te installeer:

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

En weer, voeg ons rol ruby_rbenv by die hoofspeelboek.

Gedeelde lêers.

Oor die algemeen kan die opstelling hier voltooi word. Volgende, al wat oorbly, is om capistrano te laat loop en dit sal die kode self kopieer, die nodige gidse skep en die toepassing begin (as alles korrek opgestel is). Capistrano vereis egter dikwels bykomende konfigurasielêers, soos database.yml of .env Hulle kan net soos lêers en sjablone vir nginx gekopieer word. Daar is net een subtiliteit. Voordat u lêers kopieer, moet u 'n gidsstruktuur daarvoor skep, iets soos hierdie:

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

ons spesifiseer slegs een gids en ansible sal outomaties ouers skep indien nodig.

Ansible Vault

Ons het reeds op die feit afgekom dat veranderlikes geheime data soos die gebruiker se wagwoord kan bevat. As jy geskep het .env lêer vir die aansoek, en database.yml dan moet daar nog meer sulke kritiese gegewens wees. Dit sal goed wees om hulle vir gierige oë weg te steek. Vir hierdie doel word dit gebruik moontlike kluis.

Kom ons skep 'n lêer vir veranderlikes /ansible/vars/all.yml (hier kan jy verskillende lêers vir verskillende groepe gashere skep, net soos in die voorraadlêer: production.yml, staging.yml, ens.).
Alle veranderlikes wat geënkripteer moet word, moet na hierdie lêer oorgedra word deur gebruik te maak van standaard yml-sintaksis:

# 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

Daarna kan hierdie lêer geïnkripteer word met die opdrag:

ansible-vault encrypt ./vars/all.yml

Natuurlik, wanneer u enkripteer, moet u 'n wagwoord vir dekripsie stel. Jy kan sien wat in die lêer sal wees nadat jy hierdie opdrag geroep het.

Deur middel van ansible-vault decrypt die lêer kan gedekripteer, gewysig en dan weer geënkripteer word.

Jy hoef nie die lêer te dekripteer om te werk nie. Jy stoor dit geïnkripteer en hardloop die speelboek met die argument --ask-vault-pass. Ansible sal die wagwoord vra, die veranderlikes ophaal en die take uitvoer. Alle data sal geïnkripteer bly.

Die volledige opdrag vir verskeie groepe leërskare en moontlike kluis sal so lyk:

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

Maar ek sal nie vir jou die volledige teks van speelboeke en rolle gee nie, skryf dit self. Want ansible is so - as jy nie verstaan wat gedoen moet word nie, dan sal dit dit nie vir jou doen nie.

Bron: will.com

Die opstel van 'n bediener om 'n spoortoepassing te ontplooi met behulp van Ansible

Wat het ons nodig?

Lêerstruktuur

Eenvoudige speelboek

Installeer stelselpakkette

Die skep van nuwe gebruikers.

rol

Stel nginx op

Die opstel van postgresql

Installeer ruby via rbenv

Gedeelde lêers.

Ansible Vault

Voeg 'n opmerking Kanselleer antwoord

Die opstel van 'n bediener om 'n spoortoepassing te ontplooi met behulp van Ansible

Wat het ons nodig?

Lêerstruktuur

Eenvoudige speelboek

Installeer stelselpakkette

Die skep van nuwe gebruikers.

rol

Stel nginx op

Die opstel van postgresql

Installeer ruby ​​​​via rbenv

Gedeelde lêers.

Ansible Vault

Voeg 'n opmerking Kanselleer antwoord

Installeer ruby via rbenv