ProHoster > blog > Gweinyddiaeth > Ffurfweddu Gweinydd i Ddefnyddio Rhaglen Rheiliau gan Ddefnyddio Ansible

Ffurfweddu Gweinydd i Ddefnyddio Rhaglen Rheiliau gan Ddefnyddio Ansible

Ddim yn bell yn ôl roedd angen i mi ysgrifennu nifer o lyfrau chwarae Ansible i baratoi'r gweinydd ar gyfer defnyddio rhaglen Rails. Ac, yn syndod, ni wnes i ddod o hyd i lawlyfr cam wrth gam syml. Doeddwn i ddim eisiau copïo llyfr chwarae rhywun arall heb ddeall beth oedd yn digwydd, ac yn y diwedd roedd yn rhaid i mi ddarllen y ddogfennaeth, gan gasglu popeth fy hun. Efallai y gallaf helpu rhywun i gyflymu'r broses hon gyda chymorth yr erthygl hon.

Y peth cyntaf i'w ddeall yw bod ansible yn rhoi rhyngwyneb cyfleus i chi berfformio rhestr ragosodol o gamau gweithredu ar weinydd(ion) o bell trwy SSH. Nid oes hud yma, ni allwch osod ategyn a chael defnydd sero o amser segur o'ch cais gyda docwr, monitro a nwyddau eraill allan o'r bocs. Er mwyn ysgrifennu llyfr chwarae, rhaid i chi wybod beth yn union rydych chi am ei wneud a sut i wneud hynny. Dyna pam nad wyf yn fodlon â llyfrau chwarae parod gan GitHub, neu erthyglau fel: “Copi a rhedeg, bydd yn gweithio.”

Beth sydd ei angen arnom?

Fel y dywedais eisoes, er mwyn ysgrifennu llyfr chwarae mae angen i chi wybod beth rydych chi am ei wneud a sut i'w wneud. Gadewch i ni benderfynu beth sydd ei angen arnom. Ar gyfer cais Rails bydd angen sawl pecyn system arnom: nginx, postgresql (redis, ac ati). Yn ogystal, mae angen fersiwn benodol o rhuddem. Mae'n well ei osod trwy rbenv (rvm, asdf ...). Mae rhedeg hyn i gyd fel defnyddiwr gwraidd bob amser yn syniad drwg, felly mae angen i chi greu defnyddiwr ar wahân a ffurfweddu ei hawliau. Ar ôl hyn, mae angen i chi uwchlwytho ein cod i'r gweinydd, copïo'r ffurfweddiadau ar gyfer nginx, postgres, ac ati a dechrau'r holl wasanaethau hyn.

O ganlyniad, mae'r dilyniant o gamau gweithredu fel a ganlyn:

  1. Mewngofnodi fel gwraidd
  2. gosod pecynnau system
  3. creu defnyddiwr newydd, ffurfweddu hawliau, allwedd ssh
  4. ffurfweddu pecynnau system (nginx ac ati) a'u rhedeg
  5. Rydym yn creu defnyddiwr yn y gronfa ddata (gallwch greu cronfa ddata ar unwaith)
  6. Mewngofnodi fel defnyddiwr newydd
  7. Gosod rbenv a rhuddem
  8. Gosod y bwndelwr
  9. Wrthi'n uwchlwytho cod y cais
  10. Lansio gweinydd Puma

Ar ben hynny, gellir gwneud y camau olaf gan ddefnyddio capistrano, o leiaf allan o'r blwch gall gopïo cod i gyfeiriaduron rhyddhau, newid y datganiad gyda chyswllt ar ôl ei ddefnyddio'n llwyddiannus, copïo cyfluniadau o gyfeiriadur a rennir, ailgychwyn puma, ac ati. Gellir gwneud hyn i gyd gan ddefnyddio Ansible, ond pam?

Strwythur ffeil

Mae gan Ansible llym strwythur ffeil ar gyfer eich holl ffeiliau, felly mae'n well cadw'r cyfan mewn cyfeiriadur ar wahân. Ar ben hynny, nid yw mor bwysig a fydd yn y cais rheiliau ei hun, neu ar wahân. Gallwch storio ffeiliau mewn ystorfa git ar wahân. Yn bersonol, roeddwn yn ei chael hi'n fwyaf cyfleus i greu cyfeiriadur ansible yn y cyfeiriadur / config y rhaglen rheiliau a storio popeth mewn un ystorfa.

Llyfr Chwarae Syml

Mae Playbook yn ffeil yml sydd, gan ddefnyddio cystrawen arbennig, yn disgrifio beth ddylai Ansible ei wneud a sut. Gadewch i ni greu'r llyfr chwarae cyntaf nad yw'n gwneud dim:

---
- name: Simple playbook
  hosts: all

Yma rydyn ni'n dweud yn syml mai enw ein llyfr chwarae Simple Playbook a bod ei gynnwysiad i gael ei weithredu dros bob gwesteiwr. Gallwn ei gadw mewn cyfeiriadur / ansible gyda'r enw playbook.yml a cheisio rhedeg:

ansible-playbook ./playbook.yml

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

Dywed Ansible nad yw'n gwybod am unrhyw westeion sy'n cyd-fynd â'r rhestr gyfan. Rhaid eu rhestru mewn arbennig ffeil rhestr eiddo.

Gadewch i ni ei greu yn yr un cyfeiriadur ymarferol:

123.123.123.123

Dyma sut rydyn ni'n nodi'r gwesteiwr (yn ddelfrydol gwesteiwr ein VPS i'w brofi, neu gallwch chi gofrestru localhost) a'i gadw o dan yr enw inventory.
Gallwch geisio rhedeg anible gyda ffeil rhestr eiddo:

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

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

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

Os oes gennych chi fynediad ssh i'r gwesteiwr penodedig, yna bydd ansible yn cysylltu ac yn casglu gwybodaeth am y system bell. (TASG diofyn [Casglu Ffeithiau]) ar ôl hynny bydd yn rhoi adroddiad byr ar y cyflawni (CHWARAE RECAP).

Yn ddiofyn, mae'r cysylltiad yn defnyddio'r enw defnyddiwr yr ydych wedi mewngofnodi i'r system oddi tano. Mae'n debyg na fydd ar y gwesteiwr. Yn y ffeil llyfr chwarae, gallwch chi nodi pa ddefnyddiwr i'w ddefnyddio i gysylltu gan ddefnyddio'r gyfarwyddeb remote_user. Hefyd, mae’n bosibl y bydd gwybodaeth am system bell yn aml yn ddiangen i chi ac ni ddylech wastraffu amser yn ei chasglu. Gellir analluogi'r dasg hon hefyd:

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

Ceisiwch redeg y llyfr chwarae eto a gwnewch yn siŵr bod y cysylltiad yn gweithio. (Os gwnaethoch chi nodi'r defnyddiwr gwraidd, yna mae angen i chi hefyd nodi'r gyfarwyddeb dod yn: wir er mwyn ennill hawliau uchel. Fel yr ysgrifennwyd yn y ddogfennaeth: become set to ‘true’/’yes’ to activate privilege escalation. er nad yw'n gwbl glir pam).

Efallai y byddwch yn derbyn gwall a achosir gan y ffaith na all anible bennu'r cyfieithydd Python, yna gallwch ei nodi â llaw:

ansible_python_interpreter: /usr/bin/python3

Gallwch ddarganfod ble mae gennych python gyda'r gorchymyn whereis python.

Gosod pecynnau system

Mae dosbarthiad safonol Ansible yn cynnwys llawer o fodiwlau ar gyfer gweithio gyda phecynnau system amrywiol, felly nid oes rhaid i ni ysgrifennu sgriptiau bash am unrhyw reswm. Nawr mae angen un o'r modiwlau hyn arnom i ddiweddaru'r system a gosod pecynnau system. Mae gen i Ubuntu Linux ar fy VPS, felly i osod pecynnau rwy'n eu defnyddio apt-get и modiwl ar ei gyfer. Os ydych chi'n defnyddio system weithredu wahanol, yna efallai y bydd angen modiwl gwahanol arnoch chi (cofiwch, dywedais ar y dechrau bod angen i ni wybod ymlaen llaw beth a sut y byddwn yn ei wneud). Fodd bynnag, mae'n debyg y bydd y gystrawen yn debyg.

Gadewch i ni ategu ein llyfr chwarae gyda'r tasgau cyntaf:

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

Tasg yw'r union dasg y bydd Ansible yn ei chyflawni ar weinyddion pell. Rydyn ni'n rhoi enw i'r dasg fel y gallwn olrhain ei chyflawniad yn y log. Ac rydym yn disgrifio, gan ddefnyddio cystrawen modiwl penodol, yr hyn y mae angen iddo ei wneud. Yn yr achos hwn apt: update_cache=yes - yn dweud i ddiweddaru pecynnau system gan ddefnyddio'r modiwl addas. Mae'r ail orchymyn ychydig yn fwy cymhleth. Rydym yn trosglwyddo rhestr o becynnau i'r modiwl addas ac yn dweud eu bod state dylai ddod present, hynny yw, dywedwn osod y pecynnau hyn. Mewn ffordd debyg, gallwn ddweud wrthynt am eu dileu, neu eu diweddaru trwy newid yn syml state. Sylwch, er mwyn i gledrau weithio gyda postgresql mae angen y pecyn postgresql-contrib, yr ydym yn ei osod nawr. Unwaith eto, mae angen i chi wybod a gwneud hyn; ni fydd ansible ar ei ben ei hun yn gwneud hyn.

Ceisiwch redeg y llyfr chwarae eto a gwiriwch fod y pecynnau wedi'u gosod.

Creu defnyddwyr newydd.

I weithio gyda defnyddwyr, mae gan Ansible hefyd fodiwl - defnyddiwr. Gadewch i ni ychwanegu un dasg arall (cuddiais y rhannau hysbys o'r llyfr chwarae y tu ôl i'r sylwadau er mwyn peidio â'i gopïo'n gyfan gwbl bob tro): 

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

Rydyn ni'n creu defnyddiwr newydd, yn gosod shell a chyfrinair ar ei gyfer. Ac yna rydym yn wynebu nifer o broblemau. Beth os oes angen i enwau defnyddwyr fod yn wahanol ar gyfer gwesteiwyr gwahanol? Ac mae storio'r cyfrinair mewn testun clir yn y llyfr chwarae yn syniad gwael iawn. I ddechrau, gadewch i ni roi'r enw defnyddiwr a'r cyfrinair mewn newidynnau, a thua diwedd yr erthygl byddaf yn dangos sut i amgryptio'r cyfrinair.

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

Gosodir newidynnau mewn llyfrau chwarae gan ddefnyddio braces cyrliog dwbl.

Byddwn yn nodi gwerthoedd y newidynnau yn y ffeil rhestr eiddo:

123.123.123.123

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

Rhowch sylw i'r gyfarwyddeb [all:vars] - mae'n dweud mai'r bloc nesaf o destun yw newidynnau (vars) a'u bod yn berthnasol i bob gwesteiwr (pob un).

Mae'r dyluniad hefyd yn ddiddorol "{{ user_password | password_hash('sha512') }}". Y peth yw nad yw ansible yn gosod y defnyddiwr trwy user_add fel y byddech chi'n ei wneud â llaw. Ac mae'n arbed yr holl ddata yn uniongyrchol, a dyna pam mae'n rhaid i ni hefyd drosi'r cyfrinair yn hash ymlaen llaw, sef yr hyn y mae'r gorchymyn hwn yn ei wneud.

Gadewch i ni ychwanegu ein defnyddiwr i'r grŵp sudo. Fodd bynnag, cyn hyn mae angen i ni sicrhau bod grŵp o’r fath yn bodoli oherwydd ni fydd unrhyw un yn gwneud hyn i ni:

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

Mae popeth yn eithaf syml, mae gennym hefyd fodiwl grŵp ar gyfer creu grwpiau, gyda chystrawen yn debyg iawn i apt. Yna mae'n ddigon i gofrestru'r grŵp hwn i'r defnyddiwr (groups: "sudo").
Mae hefyd yn ddefnyddiol ychwanegu allwedd ssh i'r defnyddiwr hwn fel y gallwn fewngofnodi gan ei ddefnyddio heb gyfrinair:

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

Yn yr achos hwn, mae'r dyluniad yn ddiddorol "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — mae'n copïo cynnwys y ffeil id_rsa.pub (gall eich enw fod yn wahanol), hynny yw, rhan gyhoeddus yr allwedd ssh ac yn ei uwchlwytho i'r rhestr o allweddi awdurdodedig ar gyfer y defnyddiwr ar y gweinydd.

Rolau

Mae'n hawdd dosbarthu'r tair tasg ar gyfer creu defnydd yn un grŵp o dasgau, a byddai'n syniad da storio'r grŵp hwn ar wahân i'r prif lyfr chwarae fel nad yw'n tyfu'n rhy fawr. At y diben hwn, mae gan Ansible rolau.
Yn ôl y strwythur ffeil a nodir ar y cychwyn cyntaf, rhaid gosod rolau mewn cyfeiriadur rolau ar wahân, ar gyfer pob rôl mae cyfeiriadur ar wahân gyda'r un enw, y tu mewn i'r cyfeiriadur tasgau, ffeiliau, templedi, ac ati
Gadewch i ni greu strwythur ffeil: ./ansible/roles/user/tasks/main.yml (prif yw'r brif ffeil a fydd yn cael ei llwytho a'i gweithredu pan fydd rôl wedi'i chysylltu â'r llyfr chwarae; gellir cysylltu ffeiliau rôl eraill ag ef). Nawr gallwch chi drosglwyddo'r holl dasgau sy'n gysylltiedig â'r defnyddiwr i'r ffeil hon:

# 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

Yn y prif lyfr chwarae, rhaid i chi nodi i ddefnyddio rôl y defnyddiwr:

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

Hefyd, efallai y bydd yn gwneud synnwyr i ddiweddaru'r system cyn pob tasg arall; i wneud hyn, gallwch ailenwi'r bloc tasks y maent yn cael eu diffinio yn pre_tasks.

Sefydlu nginx

Dylem fod wedi gosod Nginx eisoes; mae angen i ni ei ffurfweddu a'i redeg. Gadewch i ni ei wneud ar unwaith yn y rôl. Gadewch i ni greu strwythur ffeil:

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

Nawr mae angen ffeiliau a thempledi arnom. Y gwahaniaeth rhyngddynt yw bod ansible yn copïo'r ffeiliau'n uniongyrchol, fel y mae. Ac mae'n rhaid i dempledi gael yr estyniad j2 a gallant ddefnyddio gwerthoedd amrywiol gan ddefnyddio'r un braces cyrliog dwbl.

Gadewch i ni alluogi nginx i mewn main.yml ffeil. Ar gyfer hyn mae gennym fodiwl systemd:

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

Yma nid yn unig rydym yn dweud bod yn rhaid cychwyn nginx (hynny yw, rydym yn ei lansio), ond dywedwn ar unwaith bod yn rhaid ei alluogi.
Nawr, gadewch i ni gopïo'r ffeiliau ffurfweddu:

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

Rydyn ni'n creu'r brif ffeil ffurfweddu nginx (gallwch ei gymryd yn uniongyrchol o'r gweinydd, neu ei ysgrifennu eich hun). A hefyd y ffeil ffurfweddu ar gyfer ein cais yn y cyfeiriadur sites_available (nid yw hyn yn angenrheidiol ond yn ddefnyddiol). Yn yr achos cyntaf, rydym yn defnyddio'r modiwl copi i gopïo ffeiliau (rhaid i'r ffeil fod i mewn /ansible/roles/nginx/files/nginx.conf). Yn yr ail, rydym yn copïo'r templed, gan amnewid gwerthoedd y newidynnau. Dylai'r templed fod i mewn /ansible/roles/nginx/templates/my_app.j2). Ac efallai ei fod yn edrych yn rhywbeth fel hyn:

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

Rhowch sylw i'r mewnosodiadau {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — dyma'r holl newidynnau y bydd Ansible yn rhoi eu gwerthoedd yn eu lle yn y templed cyn copïo. Mae hyn yn ddefnyddiol os ydych chi'n defnyddio llyfr chwarae ar gyfer gwahanol grwpiau o westeion. Er enghraifft, gallwn ychwanegu ein ffeil rhestr eiddo:

[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

Os byddwn nawr yn lansio ein llyfr chwarae, bydd yn cyflawni'r tasgau penodedig ar gyfer y ddau westeiwr. Ond ar yr un pryd, ar gyfer gwesteiwr llwyfannu, bydd y newidynnau yn wahanol i'r rhai cynhyrchu, ac nid yn unig mewn rolau a llyfrau chwarae, ond hefyd mewn configs nginx. {{ inventory_hostname }} nid oes angen eu nodi yn y ffeil rhestr eiddo - hyn newidyn anible arbennig ac mae'r gwesteiwr y mae'r llyfr chwarae yn rhedeg ar ei gyfer ar hyn o bryd yn cael ei storio yno.
Os ydych chi am gael ffeil rhestr eiddo ar gyfer sawl gwesteiwr, ond yn rhedeg ar gyfer un grŵp yn unig, gellir gwneud hyn gyda'r gorchymyn canlynol:

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

Opsiwn arall yw cael ffeiliau rhestr eiddo ar wahân ar gyfer gwahanol grwpiau. Neu gallwch gyfuno'r ddau ddull os oes gennych lawer o westeion gwahanol.

Gadewch i ni fynd yn ôl i sefydlu nginx. Ar ôl copïo'r ffeiliau ffurfweddu, mae angen i ni greu symlink yn sitest_enabled i my_app.conf o sites_available. Ac ailgychwyn 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

Mae popeth yn syml yma - eto modiwlau asible gyda chystrawen eithaf safonol. Ond mae un pwynt. Nid oes diben ailgychwyn nginx bob tro. Ydych chi wedi sylwi nad ydym yn ysgrifennu gorchmynion fel: “gwnewch hyn fel hyn”, mae'r gystrawen yn edrych yn debycach i “dylai hwn gael y cyflwr hwn”. Ac yn fwyaf aml dyma'n union sut mae anible yn gweithio. Os yw'r grŵp yn bodoli eisoes, neu os yw'r pecyn system eisoes wedi'i osod, yna bydd Ansible yn gwirio am hyn ac yn hepgor y dasg. Hefyd, ni fydd ffeiliau'n cael eu copïo os ydynt yn cyfateb yn llwyr i'r hyn sydd eisoes ar y gweinydd. Gallwn fanteisio ar hyn ac ailgychwyn nginx dim ond os yw'r ffeiliau cyfluniad wedi'u newid. Mae yna gyfarwyddeb gofrestr ar gyfer hyn:

# 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

Os bydd un o'r ffeiliau cyfluniad yn newid, bydd copi'n cael ei wneud a bydd y newidyn yn cael ei gofrestru restart_nginx. A dim ond os yw'r newidyn hwn wedi'i gofrestru y bydd y gwasanaeth yn cael ei ailgychwyn.

Ac, wrth gwrs, mae angen ichi ychwanegu rôl nginx i'r prif lyfr chwarae.

Sefydlu postgresql

Mae angen i ni alluogi postgresql gan ddefnyddio systemd yn yr un ffordd ag y gwnaethom gyda nginx, a hefyd creu defnyddiwr y byddwn yn ei ddefnyddio i gael mynediad i'r gronfa ddata a'r gronfa ddata ei hun.
Gadewch i ni greu rôl /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 }}"

Ni fyddaf yn disgrifio sut i ychwanegu newidynnau at y rhestr eiddo, mae hyn eisoes wedi'i wneud lawer gwaith, yn ogystal â chystrawen y modiwlau postgresql_db a postgresql_user. Ceir rhagor o wybodaeth yn y ddogfennaeth. Mae'r gyfarwyddeb mwyaf diddorol yma become_user: postgres. Y ffaith yw mai dim ond defnyddiwr postgres yn ddiofyn sydd â mynediad i gronfa ddata postgresql a dim ond yn lleol. Mae'r gyfarwyddeb hon yn caniatáu inni weithredu gorchmynion ar ran y defnyddiwr hwn (os oes gennym fynediad, wrth gwrs).
Hefyd, efallai y bydd yn rhaid i chi ychwanegu llinell at pg_hba.conf i ganiatáu mynediad defnyddiwr newydd i'r gronfa ddata. Gellir gwneud hyn yn yr un ffordd ag y gwnaethom newid y ffurfwedd nginx.

Ac wrth gwrs, mae angen i chi ychwanegu rôl postgresql i'r prif lyfr chwarae.

Gosod rhuddem trwy rbenv

Nid oes gan Ansible fodiwlau ar gyfer gweithio gyda rbenv, ond fe'i gosodir trwy glonio ystorfa git. Felly, y broblem hon yw'r un mwyaf ansafonol. Gadewch i ni greu rôl iddi /ansible/roles/ruby_rbenv/main.yml a gadewch i ni ddechrau ei lenwi:

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

Rydym eto'n defnyddio'r gyfarwyddeb become_user i weithio o dan y defnyddiwr a grëwyd gennym at y dibenion hyn. Gan fod rbenv wedi'i osod yn ei gyfeiriadur cartref, ac nid yn fyd-eang. Ac rydym hefyd yn defnyddio'r modiwl git i glonio'r ystorfa, gan nodi repo a dest.

Nesaf, mae angen inni gofrestru rbenv init yn bashrc ac ychwanegu rbenv at PATH yno. Ar gyfer hyn mae gennym y modiwl llinell-ffeil:

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

Yna mae angen i chi osod ruby_build:

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

Ac yn olaf gosod ruby. Gwneir hyn trwy rbenv, hynny yw, yn syml gyda'r gorchymyn 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

Dywedwn pa orchymyn i'w weithredu a chyda pha beth. Fodd bynnag, yma rydym yn dod ar draws y ffaith nad yw anible yn rhedeg y cod a gynhwysir yn bashrc cyn rhedeg y gorchmynion. Mae hyn yn golygu y bydd yn rhaid diffinio rbenv yn uniongyrchol yn yr un sgript.

Mae'r broblem nesaf oherwydd y ffaith nad oes gan y gorchymyn cragen unrhyw gyflwr o safbwynt synhwyrol. Hynny yw, ni fydd gwiriad awtomatig a yw'r fersiwn hon o ruby ​​wedi'i gosod ai peidio. Gallwn wneud hyn ein hunain:

- 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

Y cyfan sydd ar ôl yw gosod bwndelwr:

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

Ac eto, ychwanegwch ein rôl ruby_rbenv i'r prif lyfr chwarae.

Ffeiliau a rennir.

Yn gyffredinol, gellid cwblhau'r gosodiad yma. Nesaf, y cyfan sydd ar ôl yw rhedeg capistrano a bydd yn copïo'r cod ei hun, yn creu'r cyfeiriaduron angenrheidiol ac yn lansio'r cymhwysiad (os yw popeth wedi'i ffurfweddu'n gywir). Fodd bynnag, mae capistrano yn aml yn gofyn am ffeiliau cyfluniad ychwanegol, megis database.yml neu .env Gellir eu copïo yn union fel ffeiliau a thempledi ar gyfer nginx. Nid oes ond un cynnildeb. Cyn copïo ffeiliau, mae angen i chi greu strwythur cyfeiriadur ar eu cyfer, rhywbeth fel hyn:

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

rydym yn nodi dim ond un cyfeiriadur a bydd ansible yn creu rhai rhiant yn awtomatig os oes angen.

Ansible Vault

Rydym eisoes wedi dod ar draws y ffaith y gall newidynnau gynnwys data cyfrinachol fel cyfrinair y defnyddiwr. Os ydych chi wedi creu .env ffeil ar gyfer y cais, a database.yml yna mae'n rhaid cael hyd yn oed mwy o ddata hanfodol o'r fath. Byddai'n dda eu cuddio rhag llygaid busneslyd. At y diben hwn fe'i defnyddir gladdgell ansible.

Gadewch i ni greu ffeil ar gyfer newidynnau /ansible/vars/all.yml (yma gallwch greu ffeiliau gwahanol ar gyfer gwahanol grwpiau o westeion, yn union fel yn y ffeil rhestr eiddo: production.yml, staging.yml, ac ati).
Rhaid trosglwyddo pob newidyn y mae'n rhaid ei amgryptio i'r ffeil hon gan ddefnyddio cystrawen safonol 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

Ar ôl hynny gellir amgryptio'r ffeil hon gyda'r gorchymyn:

ansible-vault encrypt ./vars/all.yml

Yn naturiol, wrth amgryptio, bydd angen i chi osod cyfrinair ar gyfer dadgryptio. Gallwch weld beth fydd y tu mewn i'r ffeil ar ôl galw'r gorchymyn hwn.

Trwy gyfrwng ansible-vault decrypt gellir dadgryptio'r ffeil, ei haddasu ac yna ei hamgryptio eto.

Nid oes angen i chi ddadgryptio'r ffeil i weithio. Rydych chi'n ei storio wedi'i amgryptio ac yn rhedeg y llyfr chwarae gyda'r ddadl --ask-vault-pass. Bydd Ansible yn gofyn am y cyfrinair, yn adfer y newidynnau, ac yn cyflawni'r tasgau. Bydd yr holl ddata yn parhau i gael ei amgryptio.

Bydd y gorchymyn cyflawn ar gyfer sawl grŵp o westeion a gladdgell ansible yn edrych fel hyn:

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

Ond ni fyddaf yn rhoi testun llawn llyfrau chwarae a rolau ichi, ysgrifennwch ef eich hun. Gan mai dyna yw anible - os nad ydych chi'n deall beth sydd angen ei wneud, yna ni fydd yn ei wneud i chi.

Ffynhonnell: hab.com

Ychwanegu sylw