ProHoster > Blog > Administrazioa > Ansible erabiliz Rails aplikazio bat hedatzeko zerbitzari bat konfiguratzea

Ansible erabiliz Rails aplikazio bat hedatzeko zerbitzari bat konfiguratzea

Duela ez asko Ansible liburuxka idatzi behar izan nuen Rails aplikazio bat zabaltzeko zerbitzaria prestatzeko. Eta, harrigarria bada ere, ez nuen urratsez urratseko eskuliburu soil bat aurkitu. Ez nuen inoren jolas liburua kopiatu nahi gertatzen ari zena ulertu gabe, eta azkenean dokumentazioa irakurri behar izan nuen, dena neuk bilduz. Agian norbaiti lagundu diezaioket prozesu hau bizkortzen artikulu honen laguntzarekin.

Ulertzen den lehenengo gauza da ansiblek interfaze erosoa eskaintzen dizula SSH bidez urruneko zerbitzari batean aurrez zehaztutako ekintzen zerrenda bat egiteko. Hemen ez dago magiarik, ezin duzu plugin bat instalatu eta zure aplikazioaren zero geldialdi-denbora inplementatu docker, monitorizazioa eta beste ontasun batzuekin. Jolas-liburu bat idazteko, jakin behar duzu zer egin nahi duzun eta nola egin. Horregatik ez nago konforme GitHub-eko prest egindako jolas-liburuekin, edo honelako artikuluekin: "Kopiatu eta exekutatu, funtzionatuko du".

Zer behar dugu?

Lehen esan dudan bezala, playbook bat idazteko zer egin nahi duzun eta nola egin jakin behar da. Erabaki dezagun zer behar dugun. Rails aplikazio baterako hainbat sistema pakete beharko ditugu: nginx, postgresql (redis, etab). Horrez gain, ruby-ren bertsio zehatz bat behar dugu. Hobe da rbenv bidez instalatzea (rvm, asdf...). Hau guztia root erabiltzaile gisa exekutatu beti ideia txarra da, beraz, aparteko erabiltzaile bat sortu eta bere eskubideak konfiguratu behar dituzu. Honen ondoren, gure kodea zerbitzarira igo behar duzu, nginx, postgres eta abarrentzako konfigurazioak kopiatu eta zerbitzu hauek guztiak martxan jarri.

Ondorioz, ekintzen sekuentzia honako hau da:

  1. Hasi saioa root gisa
  2. instalatu sistema paketeak
  3. sortu erabiltzaile berri bat, konfiguratu eskubideak, ssh gakoa
  4. konfiguratu sistema paketeak (nginx, etab.) eta exekutatu
  5. Erabiltzaile bat sortzen dugu datu-basean (berehala sor dezakezu datu-base bat)
  6. Hasi saioa erabiltzaile berri gisa
  7. Instalatu rbenv eta ruby
  8. bundler instalatzea
  9. Aplikazioaren kodea kargatzea
  10. Puma zerbitzaria abiarazten

Gainera, azken faseak capistrano erabiliz egin daitezke, gutxienez kaxatik kanpo kodea bertsio-direktorioetan kopiatu dezake, bertsioa esteka sinboliko batekin aldatu daiteke arrakastaz zabaltzean, konfigurazioak kopiatu direktorio partekatu batetik, puma berrabiarazi, etab. Hau guztia Ansible erabiliz egin daiteke, baina zergatik?

Fitxategien egitura

Ansiblek zorrotzak ditu fitxategien egitura zure fitxategi guztietarako, beraz, hobe da dena direktorio bereizi batean gordetzea. Gainera, ez da hain garrantzitsua errailen aplikazioan bertan egongo den ala ez. Fitxategiak git biltegi bereizi batean gorde ditzakezu. Pertsonalki, erosoena iruditu zait ansible direktorioa sortzea rails aplikazioaren /config direktorioan eta dena biltegi batean gordetzea.

Jolas liburu sinplea

Playbook yml fitxategi bat da, eta, sintaxi berezia erabiliz, Ansiblek zer egin behar duen eta nola deskribatzen du. Sor dezagun ezer egiten ez duen lehen jolas-liburua:

---
- name: Simple playbook
  hosts: all

Hemen besterik gabe esaten dugu gure playbook deitzen dela Simple Playbook eta bere edukiak ostalari guztientzat exekutatu behar direla. /ansible direktorioan gorde dezakegu izenarekin playbook.yml eta saiatu korrika egiten:

ansible-playbook ./playbook.yml

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

Ansiblek dio ez duela ezagutzen zerrenda guztiarekin bat datorren ostalaririk. Berezi batean zerrendatu behar dira inbentario fitxategia.

Sor dezagun ansible direktorio berean:

123.123.123.123

Horrela, besterik gabe, ostalaria zehazten dugu (egokiena gure VPSaren ostalaria probak egiteko, edo localhost erregistratu dezakezu) eta izenpean gorde. inventory.
Saia zaitezke ansible exekutatzen inbentario-fitxategi batekin:

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

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

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

Zehaztutako ostalarirako ssh sarbidea baduzu, orduan ansiblek konektatuko du eta urruneko sistemari buruzko informazioa bilduko du. (Lehenetsia TASK [Gathering Facts]) eta horren ostean exekuzioari buruzko txosten labur bat emango du (PLAY RECAP).

Lehenespenez, konexioak sisteman saioa hasita zauden erabiltzaile-izena erabiltzen du. Seguruenik ez da ostalarian egongo. Playbook fitxategian, urruneko_user zuzentaraua erabiliz konektatzeko zein erabiltzaile erabili behar duzun zehaztu dezakezu. Gainera, urrutiko sistema bati buruzko informazioa askotan ez da beharrezkoa izango zuretzat eta ez zenuke denborarik galdu behar hura biltzeko. Zeregin hau ere desgaitu daiteke:

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

Saiatu playbook berriro exekutatzen eta ziurtatu konexioa funtzionatzen ari dela. (Root erabiltzailea zehaztu baduzu, bihurtu: true zuzentaraua ere zehaztu behar duzu eskubide altuak lortzeko. Dokumentazioan idatzita dagoen moduan: become set to β€˜true’/’yes’ to activate privilege escalation. guztiz argi ez dagoen arren zergatik).

Agian ansiblek Python interpretea zehaztu ezin izanak eragindako errore bat jasoko duzu, orduan eskuz zehaztu dezakezu:

ansible_python_interpreter: /usr/bin/python3

Komandoarekin python non duzun jakin dezakezu whereis python.

Sistema paketeak instalatzea

Ansible-ren banaketa estandarrak hainbat sistema-paketeekin lan egiteko modulu ugari biltzen ditu, beraz, ez dugu bash script-ak idatzi beharrik inolako arrazoirik gabe. Orain modulu horietako bat behar dugu sistema eguneratzeko eta sistema paketeak instalatzeko. Ubuntu Linux dut nire VPSan, beraz, erabiltzen ditudan paketeak instalatzeko apt-get ΠΈ horretarako modulua. Beste sistema eragile bat erabiltzen ari bazara, baliteke beste modulu bat behar izatea (gogoratu, hasieran esan nuen aldez aurretik zer eta nola egingo dugun jakin behar dugula). Hala ere, sintaxia antzekoa izango da ziurrenik.

Osa dezagun gure jolas liburua lehenengo zereginekin:

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

Zeregin Ansiblek urruneko zerbitzarietan egingo duen zeregina da. Zereginari izena ematen diogu, bere exekuzioa erregistroan jarraitu ahal izateko. Eta modulu zehatz baten sintaxia erabiliz, zer egin behar duen deskribatzen dugu. Kasu honetan apt: update_cache=yes - sistema-paketeak apt modulua erabiliz eguneratzeko dio. Bigarren komandoa pixka bat konplexuagoa da. Paketeen zerrenda bat apt moduluari pasatzen diogu eta daudela esaten dugu state bihurtu beharko litzateke present, hau da, pakete hauek instalatu esaten dugu. Era berean, horiek ezabatzeko esan diezaiekegu, edo aldatu besterik gabe eguneratzeko state. Kontuan izan railak postgresql-ekin lan egiteko postgresql-contrib paketea behar dugula, orain instalatzen ari garen. Berriz ere, hau jakin eta egin behar duzu; Ansiblek bere kabuz ez du hau egingo.

Saiatu playbook berriro exekutatzen eta egiaztatu paketeak instalatuta daudela.

Erabiltzaile berriak sortzea.

Erabiltzaileekin lan egiteko, Ansiblek modulu bat ere badu - erabiltzailea. Gehitu dezagun zeregin bat gehiago (joko-liburuaren zati ezagunak ezkutatu ditut iruzkinen atzean, aldi bakoitzean guztiz ez kopiatzeko): 

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

Erabiltzaile berri bat sortzen dugu, schell eta pasahitza ezartzen dizkiogu. Eta orduan hainbat arazorekin topo egiten dugu. Zer gertatzen da erabiltzaile-izenak desberdinak izan behar badira ostalari desberdinetarako? Eta pasahitza liburuko testu garbian gordetzea oso ideia txarra da. Hasteko, jar ditzagun erabiltzaile-izena eta pasahitza aldagaietan, eta artikuluaren amaiera aldera pasahitza nola enkriptatu erakutsiko dut.

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

Aldagaiak joko-liburuetan ezartzen dira giltza kizkur bikoitzak erabiliz.

Inbentario-fitxategian aldagaien balioak adieraziko ditugu:

123.123.123.123

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

Kontuan izan zuzentaraua [all:vars] - hurrengo testu-blokea aldagaiak (vars) direla dio eta ostalari guztiei (guztiak) aplikagarri zaizkiela dio.

Diseinua ere interesgarria da "{{ user_password | password_hash('sha512') }}". Gauza da ansiblek ez duela erabiltzailea instalatzen bidez user_add eskuz egingo bazenu bezala. Eta datu guztiak zuzenean gordetzen ditu, horregatik pasahitza ere aldez aurretik hash bihurtu behar dugu, horixe egiten du komando honek.

Gehi dezagun gure erabiltzailea sudo taldean. Hala ere, hau baino lehen ziurtatu behar dugu horrelako talde bat existitzen dela, inork ez digulako hau egingo:

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

Dena nahiko sinplea da, taldeak sortzeko talde-modulu bat ere badugu, apt-en oso antzeko sintaxiarekin. Orduan nahikoa da talde hau erabiltzaileari erregistratzea (groups: "sudo").
Erabiltzaile honi ssh gako bat gehitzea ere erabilgarria da, pasahitz gabe erabilita saioa hasteko:

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

Kasu honetan, diseinua interesgarria da "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" β€” id_rsa.pub fitxategiaren edukia kopiatzen du (zure izena ezberdina izan daiteke), hau da, ssh gakoaren atal publikoa eta zerbitzarian erabiltzailearen baimendutako gakoen zerrendara igotzen du.

rol

Erabilera sortzeko hiru zereginak erraz sailka daitezke ataza talde batean, eta komenigarria litzateke talde hau jolas-liburu nagusitik bereizita gordetzea, handiegia izan ez dadin. Horretarako, Ansiblek rolak.
Hasieran adierazitako fitxategi-egituraren arabera, rolak rolen direktorio bereizi batean kokatu behar dira, rol bakoitzarentzat izen bereko direktorio bat dago, zereginak, fitxategiak, txantiloiak, etab.
Sortu dezagun fitxategi-egitura bat: ./ansible/roles/user/tasks/main.yml (main rol bat playbook-era konektatzen denean kargatu eta exekutatuko den fitxategi nagusia da; beste rol-fitxategi batzuk konekta daitezke). Orain erabiltzailearekin lotutako zeregin guztiak fitxategi honetara transferi ditzakezu:

# 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

Jokalari nagusian, erabiltzailearen rola erabiltzeko zehaztu behar duzu:

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

Gainera, baliteke sistema eguneratzea beste zeregin guztien aurretik; horretarako, blokeari izena aldatu dezakezu tasks urtean definitzen diren pre_tasks.

nginx konfiguratzen

Dagoeneko Nginx instalatuta eduki beharko genuke; konfiguratu eta exekutatu behar dugu. Egin dezagun berehala paperean. Sortu dezagun fitxategi-egitura bat:

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

Orain fitxategiak eta txantiloiak behar ditugu. Horien arteko aldea da ansiblek fitxategiak zuzenean kopiatzen dituela, dagoen bezala. Eta txantiloiek j2 luzapena izan behar dute eta balio aldakorrak erabil ditzakete giltza kizkur bikoitz berdinak erabiliz.

Gaitu dezagun nginx main.yml fitxategia. Horretarako systemd modulu bat dugu:

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

Hemen ez dugu bakarrik esaten nginx abiarazi behar dela (hau da, abiarazten dugu), baina berehala esaten dugu gaituta egon behar dela.
Orain kopia ditzagun konfigurazio fitxategiak:

# 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 konfigurazio fitxategi nagusia sortzen dugu (zuzenean zerbitzaritik hartu dezakezu, edo zuk zeuk idatzi). Eta baita gure aplikazioaren konfigurazio fitxategia sites_available direktorioa (hau ez da beharrezkoa baina erabilgarria). Lehenengo kasuan, kopia modulua erabiltzen dugu fitxategiak kopiatzeko (fitxategiak barruan egon behar du /ansible/roles/nginx/files/nginx.conf). Bigarrenean, txantiloia kopiatzen dugu, aldagaien balioak ordezkatuz. Txantiloiak sartu behar du /ansible/roles/nginx/templates/my_app.j2). Eta horrelako zerbait izan liteke:

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

Erreparatu txertaketei {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} β€” Hauek dira kopiatu aurretik Ansiblek txantiloian ordeztuko dituen balioak aldagai guztiak. Hau erabilgarria da anfitrioi talde ezberdinentzako jolas-liburua erabiltzen baduzu. Adibidez, gure inbentario-fitxategia gehi dezakegu:

[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

Orain gure playbook abiarazten badugu, zehaztutako zereginak egingo ditu bi ostalarientzat. Baina, aldi berean, eszenatze ostalari batentzat, aldagaiak ekoizpenekoetatik desberdinak izango dira, eta ez bakarrik rol eta playbooketan, baita nginx konfigurazioetan ere. {{ inventory_hostname }} ez da inbentario-fitxategian zehaztu behar - hau aldagai ansible berezia eta une honetan playbook-a exekutatzen ari den ostalaria bertan gordetzen da.
Hainbat ostalarirentzat inbentario-fitxategia izan nahi baduzu, baina talde bakarrerako exekutatu nahi baduzu, komando honekin egin daiteke:

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

Beste aukera bat talde ezberdinentzako inbentario fitxategi bereiziak izatea da. Edo bi ikuspegiak konbina ditzakezu ostalari ezberdin asko badituzu.

Itzuli gaitezen nginx konfiguratzera. Konfigurazio-fitxategiak kopiatu ondoren, sitest_enabled-en my_app.conf-en esteka sinbolikoa sortu behar dugu sites_available-tik. Eta berrabiarazi 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

Hemen dena sinplea da - berriro ere sintaxi nahiko estandarra duten modulu ansibleak. Baina bada puntu bat. Ez du balio nginx aldi bakoitzean berrabiarazteko. Konturatu al zara ez dugula idazten honelako komandoak: "egin hau horrela", sintaxiak "hau egoera hau izan beharko luke" itxura gehiago du. Eta gehienetan horrela funtzionatzen du ansiblek. Taldea badago jadanik, edo sistema paketea instalatuta badago, orduan ansiblek hori egiaztatuko du eta zeregina saltatuko du. Gainera, fitxategiak ez dira kopiatuko zerbitzarian dagoenarekin guztiz bat egiten badute. Honetaz aprobetxatu eta nginx berrabiarazi dezakegu konfigurazio fitxategiak aldatu badira bakarrik. Erregistrorako zuzentarau bat dago horretarako:

# 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

Konfigurazio fitxategietako bat aldatzen bada, kopia bat egingo da eta aldagaia erregistratuko da restart_nginx. Eta aldagai hori erregistratuta badago soilik berrabiaraziko da zerbitzua.

Eta, noski, nginx rola gehitu behar duzu playbook nagusiari.

Postgresql konfiguratzen

Postgresql systemd erabiliz gaitu behar dugu nginx-ekin egin genuen moduan, eta datu-basera eta datu-basera bera sartzeko erabiliko dugun erabiltzaile bat ere sortu.
Sor dezagun rol bat /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 }}"

Ez dut inbentarioan aldagaiak nola gehitu deskribatuko, hau askotan egin da dagoeneko, baita postgresql_db eta postgresql_user moduluen sintaxia ere. Informazio gehiago dokumentazioan aurki daiteke. Hemen zuzentaraurik interesgarriena da become_user: postgres. Kontua da, lehenespenez, postgres erabiltzaileak bakarrik daukala postgresql datu-baserako sarbidea eta lokalean bakarrik. Zuzentarau honek erabiltzaile honen izenean komandoak exekutatzeko aukera ematen digu (sarbidea badugu, noski).
Gainera, baliteke lerro bat gehitu behar izatea pg_hba.conf-era erabiltzaile berri bati datu-basera sartzeko. Hau nginx konfigurazioa aldatu dugun modu berean egin daiteke.

Eta, noski, postgresql rola gehitu behar duzu playbook nagusiari.

Ruby instalatzen rbenv bidez

Ansiblek ez du rbenv-ekin lan egiteko modulurik, baina git biltegi bat klonatuz instalatzen da. Horregatik, arazo hau ez-estandarrena bihurtzen da. Sor dezagun harentzat rol bat /ansible/roles/ruby_rbenv/main.yml eta hasi gaitezen betetzen:

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

Berriro bede_user zuzentaraua erabiltzen dugu helburu horietarako sortu dugun erabiltzailearen menpe lan egiteko. rbenv bere hasierako direktorioan instalatuta dagoenez, eta ez globalki. Eta git modulua ere erabiltzen dugu biltegia klonatzeko, repo eta dest zehaztuz.

Ondoren, rbenv init bashrc-en erregistratu eta rbenv PATH-en gehitu behar dugu. Horretarako lineinfile modulua dugu:

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

Ondoren, ruby_build instalatu behar duzu:

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

Eta azkenik, Ruby instalatu. Hau rbenv bidez egiten da, hau da, bash komandoarekin besterik gabe:

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

Zein komando exekutatu eta zerekin esaten dugu. Hala ere, hemen aurkituko dugu ansiblek ez duela bashrc-en dagoen kodea exekutatzen komandoak exekutatu aurretik. Horrek esan nahi du rbenv script berean zuzenean definitu beharko dela.

Hurrengo arazoa shell komandoak egoerarik ez duelako ikuspuntu ansible batetik. Hau da, ez da egiaztapen automatikorik izango ruby-ren bertsio hau instalatuta dagoen edo ez. Guk geuk egin dezakegu:

- 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

bundler instalatzea besterik ez da geratzen:

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

Eta berriro ere, gehitu gure rola ruby_rbenv joko-liburu nagusira.

Partekatutako fitxategiak.

Oro har, konfigurazioa hemen osa liteke. Ondoren, kapistrano exekutatu besterik ez da geratzen eta kodea bera kopiatu, beharrezko direktorioak sortu eta aplikazioa abiaraziko du (dena ondo konfiguratuta badago). Hala ere, sarritan capitanok konfigurazio-fitxategi osagarriak behar ditu, adibidez database.yml edo .env Nginx-erako fitxategiak eta txantiloiak bezala kopiatu daitezke. Sotiltasun bakarra dago. Fitxategiak kopiatu aurretik, direktorio-egitura bat sortu behar duzu, honelako zerbait:

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

direktorio bakarra zehazten dugu eta ansiblek automatikoki sortuko ditu gurasoak behar izanez gero.

Ansible Vault

Dagoeneko topatu dugu aldagaiek datu sekretuak izan ditzaketela, hala nola erabiltzailearen pasahitza. Sortu baduzu .env eskaeraren fitxategia, eta database.yml orduan are gehiago izan behar dira halako datu kritikoak. Ondo legoke begirik gabeko begietatik ezkutatzea. Horretarako erabiltzen da ganga ansiblea.

Sortu dezagun aldagaietarako fitxategi bat /ansible/vars/all.yml (Hemen fitxategi desberdinak sor ditzakezu ostalari talde ezberdinetarako, inbentario fitxategian bezala: production.yml, staging.yml, etab).
Zifratu behar diren aldagai guztiak fitxategi honetara transferitu behar dira yml sintaxi estandarra erabiliz:

# 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

Horren ondoren, fitxategi hau komandoarekin zifratu daiteke:

ansible-vault encrypt ./vars/all.yml

Jakina, zifratzean, pasahitz bat ezarri beharko duzu deszifratzeko. Komando hau deitu ondoren fitxategiaren barruan zer egongo den ikus dezakezu.

Bidez ansible-vault decrypt fitxategia deszifratu, aldatu eta gero berriro zifratu daiteke.

Ez duzu fitxategia deszifratu beharrik funtzionatzeko. Zifratuta gordetzen duzu eta argumentuarekin jolas-liburua exekutatzen duzu --ask-vault-pass. Ansiblek pasahitza eskatuko du, aldagaiak berreskuratuko ditu eta zereginak exekutatuko ditu. Datu guztiak zifratuta geratuko dira.

Hainbat ostalari-talde eta ansible gangaren komando osoa honelako itxura izango du:

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

Baina ez dizut antzezlanen eta rolen testu osoa emango, idatzi zuk zeuk. Ansible horrelakoa delako - ez baduzu ulertzen zer egin behar den, orduan ez dizu egingo.

Iturria: www.habr.com

Gehitu iruzkin berria