Ansible ഉപയോഗിച്ച് ഒരു റെയിൽസ് ആപ്ലിക്കേഷൻ വിന്യസിക്കാൻ ഒരു സെർവർ സജ്ജീകരിക്കുന്നു

ഒരു റെയിൽസ് ആപ്ലിക്കേഷൻ വിന്യസിക്കുന്നതിന് സെർവർ തയ്യാറാക്കാൻ എനിക്ക് കുറച്ച് മുമ്പ് അൻസിബിൾ പ്ലേബുക്കുകൾ എഴുതേണ്ടി വന്നു. കൂടാതെ, അതിശയകരമെന്നു പറയട്ടെ, ഞാൻ ഒരു ലളിതമായ ഘട്ടം ഘട്ടമായുള്ള മാനുവൽ കണ്ടെത്തിയില്ല. എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാതെ മറ്റൊരാളുടെ പ്ലേബുക്ക് പകർത്താൻ ഞാൻ ആഗ്രഹിച്ചില്ല, അവസാനം എനിക്ക് ഡോക്യുമെന്റേഷൻ വായിക്കേണ്ടിവന്നു, എല്ലാം സ്വയം ശേഖരിച്ചു. ഒരുപക്ഷേ ഈ ലേഖനത്തിന്റെ സഹായത്തോടെ ഈ പ്രക്രിയ വേഗത്തിലാക്കാൻ എനിക്ക് ആരെയെങ്കിലും സഹായിക്കാനാകും.

SSH വഴി ഒരു റിമോട്ട് സെർവറിൽ(കളിൽ) പ്രവർത്തനങ്ങളുടെ ഒരു മുൻനിശ്ചയിച്ച ലിസ്റ്റ് നടപ്പിലാക്കാൻ അൻസിബിൾ നിങ്ങൾക്ക് സൗകര്യപ്രദമായ ഒരു ഇന്റർഫേസ് നൽകുന്നു എന്നതാണ് ആദ്യം മനസ്സിലാക്കേണ്ടത്. ഇവിടെ മാജിക് ഒന്നുമില്ല, നിങ്ങൾക്ക് ഒരു പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്യാനും ഡോക്കർ, മോണിറ്ററിംഗ്, മറ്റ് ഗുഡികൾ എന്നിവ ഉപയോഗിച്ച് നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പ്രവർത്തനരഹിതമായ വിന്യാസം നേടാനും കഴിയില്ല. ഒരു പ്ലേബുക്ക് എഴുതുന്നതിന്, നിങ്ങൾ കൃത്യമായി എന്താണ് ചെയ്യേണ്ടതെന്നും അത് എങ്ങനെ ചെയ്യണമെന്നും നിങ്ങൾ അറിഞ്ഞിരിക്കണം. അതുകൊണ്ടാണ് GitHub-ൽ നിന്നുള്ള റെഡിമെയ്ഡ് പ്ലേബുക്കുകൾ അല്ലെങ്കിൽ "പകർത്തുക, പ്രവർത്തിപ്പിക്കുക, ഇത് പ്രവർത്തിക്കും" എന്നതുപോലുള്ള ലേഖനങ്ങളിൽ ഞാൻ തൃപ്തനല്ല.

നമുക്ക് എന്താണ് വേണ്ടത്?

ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഒരു പ്ലേബുക്ക് എഴുതുന്നതിന് നിങ്ങൾ എന്താണ് ചെയ്യേണ്ടതെന്നും അത് എങ്ങനെ ചെയ്യണമെന്നും നിങ്ങൾ അറിഞ്ഞിരിക്കണം. എന്താണ് വേണ്ടതെന്ന് നമുക്ക് തീരുമാനിക്കാം. ഒരു റെയിൽസ് ആപ്ലിക്കേഷനായി നമുക്ക് നിരവധി സിസ്റ്റം പാക്കേജുകൾ ആവശ്യമാണ്: nginx, postgresql (redis, മുതലായവ). കൂടാതെ, നമുക്ക് റൂബിയുടെ ഒരു പ്രത്യേക പതിപ്പ് ആവശ്യമാണ്. Rbenv (rvm, asdf...) വഴി ഇത് ഇൻസ്റ്റാൾ ചെയ്യുന്നതാണ് നല്ലത്. ഒരു റൂട്ട് ഉപയോക്താവായി ഇതെല്ലാം പ്രവർത്തിപ്പിക്കുന്നത് എല്ലായ്പ്പോഴും ഒരു മോശം ആശയമാണ്, അതിനാൽ നിങ്ങൾ ഒരു പ്രത്യേക ഉപയോക്താവിനെ സൃഷ്ടിച്ച് അവന്റെ അവകാശങ്ങൾ ക്രമീകരിക്കേണ്ടതുണ്ട്. ഇതിനുശേഷം, നിങ്ങൾ ഞങ്ങളുടെ കോഡ് സെർവറിലേക്ക് അപ്‌ലോഡ് ചെയ്യണം, nginx, postgres മുതലായവയ്ക്കുള്ള കോൺഫിഗറുകൾ പകർത്തി ഈ സേവനങ്ങളെല്ലാം ആരംഭിക്കേണ്ടതുണ്ട്.

തൽഫലമായി, പ്രവർത്തനങ്ങളുടെ ക്രമം ഇപ്രകാരമാണ്:

1. റൂട്ടായി ലോഗിൻ ചെയ്യുക
2. സിസ്റ്റം പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യുക
3. ഒരു പുതിയ ഉപയോക്താവിനെ സൃഷ്ടിക്കുക, അവകാശങ്ങൾ ക്രമീകരിക്കുക, ssh കീ
4. സിസ്റ്റം പാക്കേജുകൾ (nginx മുതലായവ) ക്രമീകരിച്ച് അവ പ്രവർത്തിപ്പിക്കുക
5. ഞങ്ങൾ ഡാറ്റാബേസിൽ ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുന്നു (നിങ്ങൾക്ക് ഉടനടി ഒരു ഡാറ്റാബേസ് സൃഷ്ടിക്കാൻ കഴിയും)
6. ഒരു പുതിയ ഉപയോക്താവായി ലോഗിൻ ചെയ്യുക
7. rbenv, ruby ​​എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുക
8. ബണ്ടർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു
9. ആപ്ലിക്കേഷൻ കോഡ് അപ്‌ലോഡ് ചെയ്യുന്നു
10. പ്യൂമ സെർവർ സമാരംഭിക്കുന്നു

മാത്രമല്ല, അവസാന ഘട്ടങ്ങൾ capistrano ഉപയോഗിച്ച് ചെയ്യാം, കുറഞ്ഞത് ബോക്‌സിന് പുറത്ത് കോഡ് റിലീസ് ഡയറക്‌ടറികളിലേക്ക് പകർത്താനും വിജയകരമായ വിന്യാസത്തിന് ശേഷം ഒരു സിംലിങ്ക് ഉപയോഗിച്ച് റിലീസ് മാറ്റാനും പങ്കിട്ട ഡയറക്‌ടറിയിൽ നിന്ന് കോൺഫിഗറുകൾ പകർത്താനും പ്യൂമ പുനരാരംഭിക്കാനും കഴിയും. ഇതെല്ലാം അൻസിബിൾ ഉപയോഗിച്ച് ചെയ്യാം, പക്ഷേ എന്തുകൊണ്ട്?

ഫയൽ ഘടന

അൻസിബിളിന് കർശനമുണ്ട് ഫയൽ ഘടന നിങ്ങളുടെ എല്ലാ ഫയലുകൾക്കും, അതിനാൽ അവയെല്ലാം ഒരു പ്രത്യേക ഡയറക്ടറിയിൽ സൂക്ഷിക്കുന്നതാണ് നല്ലത്. മാത്രമല്ല, ഇത് റെയിൽ ആപ്ലിക്കേഷനിൽ തന്നെയാണോ അതോ വെവ്വേറെയാണോ എന്നത് അത്ര പ്രധാനമല്ല. നിങ്ങൾക്ക് ഒരു പ്രത്യേക ജിറ്റ് റിപ്പോസിറ്ററിയിൽ ഫയലുകൾ സംഭരിക്കാനാകും. വ്യക്തിപരമായി, റെയിൽസ് ആപ്ലിക്കേഷന്റെ / കോൺഫിഗറേഷൻ ഡയറക്‌ടറിയിൽ ഒരു അൻസിബിൾ ഡയറക്‌ടറി സൃഷ്‌ടിക്കാനും എല്ലാം ഒരു റിപ്പോസിറ്ററിയിൽ സൂക്ഷിക്കാനും ഞാൻ ഏറ്റവും സൗകര്യപ്രദമാണെന്ന് കണ്ടെത്തി.

ലളിതമായ പ്ലേബുക്ക്

പ്രത്യേക വാക്യഘടന ഉപയോഗിച്ച് അൻസിബിൾ എന്തുചെയ്യണമെന്നും എങ്ങനെ ചെയ്യണമെന്നും വിവരിക്കുന്ന ഒരു yml ഫയലാണ് Playbook. ഒന്നും ചെയ്യാത്ത ആദ്യത്തെ പ്ലേബുക്ക് നമുക്ക് സൃഷ്ടിക്കാം:

---
- name: Simple playbook
  hosts: all

ഇവിടെ നമ്മൾ ലളിതമായി പറയുന്നത് നമ്മുടെ പ്ലേബുക്ക് എന്നാണ് Simple Playbook അതിലെ ഉള്ളടക്കങ്ങൾ എല്ലാ ഹോസ്റ്റുകൾക്കുമായി എക്സിക്യൂട്ട് ചെയ്യണമെന്നും. നമുക്ക് അത് /ansible ഡയറക്ടറിയിൽ പേര് ഉപയോഗിച്ച് സേവ് ചെയ്യാം playbook.yml പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുക:

ansible-playbook ./playbook.yml

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

എല്ലാ ലിസ്റ്റുമായി പൊരുത്തപ്പെടുന്ന ഹോസ്റ്റുകളൊന്നും അറിയില്ലെന്ന് അൻസിബിൾ പറയുന്നു. അവ ഒരു പ്രത്യേക വിഭാഗത്തിൽ പട്ടികപ്പെടുത്തിയിരിക്കണം ഇൻവെന്ററി ഫയൽ.

നമുക്ക് ഇത് ഒരേ അൻസിബിൾ ഡയറക്ടറിയിൽ സൃഷ്ടിക്കാം:

123.123.123.123

ഇങ്ങനെയാണ് ഞങ്ങൾ ഹോസ്റ്റിനെ ലളിതമായി വ്യക്തമാക്കുന്നത് (ടെസ്റ്റിംഗിനായി ഞങ്ങളുടെ VPS-ന്റെ ഹോസ്റ്റ്, അല്ലെങ്കിൽ നിങ്ങൾക്ക് ലോക്കൽ ഹോസ്റ്റ് രജിസ്റ്റർ ചെയ്യാം) കൂടാതെ അത് പേരിൽ സംരക്ഷിക്കുക inventory.
ഒരു ഇൻവെറ്ററി ഫയൽ ഉപയോഗിച്ച് നിങ്ങൾക്ക് അൻസിബിൾ പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കാം:

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

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

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

നിർദ്ദിഷ്‌ട ഹോസ്റ്റിലേക്ക് നിങ്ങൾക്ക് ssh ആക്‌സസ് ഉണ്ടെങ്കിൽ, അൻസിബിൾ ബന്ധിപ്പിച്ച് റിമോട്ട് സിസ്റ്റത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ ശേഖരിക്കും. (ഡിഫോൾട്ട് ടാസ്‌ക് [ശേഖരിക്കൽ വസ്തുതകൾ]) അതിനുശേഷം അത് നിർവ്വഹണത്തെക്കുറിച്ചുള്ള ഒരു ചെറിയ റിപ്പോർട്ട് നൽകും (പ്ലേ റീകാപ്പ്).

സ്ഥിരസ്ഥിതിയായി, നിങ്ങൾ സിസ്റ്റത്തിൽ ലോഗിൻ ചെയ്‌തിരിക്കുന്ന ഉപയോക്തൃനാമം കണക്ഷൻ ഉപയോഗിക്കുന്നു. ഇത് മിക്കവാറും ഹോസ്റ്റിൽ ആയിരിക്കില്ല. പ്ലേബുക്ക് ഫയലിൽ, remote_user ഡയറക്‌ടീവ് ഉപയോഗിച്ച് കണക്റ്റുചെയ്യാൻ ഏത് ഉപയോക്താവിനെ ഉപയോഗിക്കണമെന്ന് നിങ്ങൾക്ക് വ്യക്തമാക്കാം. കൂടാതെ, ഒരു റിമോട്ട് സിസ്റ്റത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ നിങ്ങൾക്ക് പലപ്പോഴും അനാവശ്യമായേക്കാം, അത് ശേഖരിക്കുന്നതിന് നിങ്ങൾ സമയം പാഴാക്കരുത്. ഈ ടാസ്‌ക് അപ്രാപ്‌തമാക്കാനും കഴിയും:

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

പ്ലേബുക്ക് വീണ്ടും പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുക, കണക്ഷൻ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. (നിങ്ങൾ റൂട്ട് ഉപയോക്താവിനെയാണ് വ്യക്തമാക്കിയതെങ്കിൽ, ഉയർന്ന അവകാശങ്ങൾ നേടുന്നതിന് നിങ്ങൾ ആകുക: true നിർദ്ദേശവും വ്യക്തമാക്കേണ്ടതുണ്ട്. ഡോക്യുമെന്റേഷനിൽ എഴുതിയിരിക്കുന്നതുപോലെ: 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 - apt മൊഡ്യൂൾ ഉപയോഗിച്ച് സിസ്റ്റം പാക്കേജുകൾ അപ്ഡേറ്റ് ചെയ്യാൻ പറയുന്നു. രണ്ടാമത്തെ കമാൻഡ് കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. ഞങ്ങൾ പാക്കേജുകളുടെ ഒരു ലിസ്റ്റ് apt മൊഡ്യൂളിലേക്ക് കൈമാറുകയും അവയാണെന്ന് പറയുകയും ചെയ്യുന്നു state ആയിത്തീരണം present, അതായത്, ഈ പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞങ്ങൾ പറയുന്നു. സമാനമായ രീതിയിൽ, നമുക്ക് അവ ഇല്ലാതാക്കാൻ അവരോട് പറയാനാകും, അല്ലെങ്കിൽ ലളിതമായി മാറ്റിക്കൊണ്ട് അപ്ഡേറ്റ് ചെയ്യുക state. postgresql-നൊപ്പം റെയിലുകൾ പ്രവർത്തിക്കുന്നതിന്, ഞങ്ങൾ ഇപ്പോൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന postgresql-contrib പാക്കേജ് ആവശ്യമാണെന്ന് ദയവായി ശ്രദ്ധിക്കുക. വീണ്ടും, നിങ്ങൾ ഇത് അറിയുകയും ചെയ്യണം; അൻസിബിൾ സ്വന്തമായി ഇത് ചെയ്യില്ല.

പ്ലേബുക്ക് വീണ്ടും പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുക, പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോയെന്ന് പരിശോധിക്കുക.

പുതിയ ഉപയോക്താക്കളെ സൃഷ്ടിക്കുന്നു.

ഉപയോക്താക്കളുമായി പ്രവർത്തിക്കാൻ, അൻസിബിളിന് ഒരു മൊഡ്യൂളും ഉണ്ട് - ഉപയോക്താവ്. നമുക്ക് ഒരു ടാസ്‌ക് കൂടി ചേർക്കാം (എല്ലാ തവണയും പൂർണ്ണമായി പകർത്താതിരിക്കാൻ ഞാൻ പ്ലേബുക്കിന്റെ ഇതിനകം അറിയപ്പെടുന്ന ഭാഗങ്ങൾ കമന്റുകൾക്ക് പിന്നിൽ മറച്ചു):

---
- 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] - ടെക്സ്റ്റിന്റെ അടുത്ത ബ്ലോക്ക് വേരിയബിളുകൾ (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").
ഈ ഉപയോക്താവിലേക്ക് ഒരു ssh കീ ചേർക്കുന്നതും ഉപയോഗപ്രദമാണ്, അതിലൂടെ നമുക്ക് പാസ്‌വേഡ് ഇല്ലാതെ ലോഗിൻ ചെയ്യാൻ കഴിയും:

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Ensure a 'sudo' group
      group:
      name: sudo
        state: present
    - name: Add a new user
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: Deploy SSH Key
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

ഈ സാഹചര്യത്തിൽ, ഡിസൈൻ രസകരമാണ് "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — ഇത് id_rsa.pub ഫയലിന്റെ ഉള്ളടക്കങ്ങൾ പകർത്തുന്നു (നിങ്ങളുടെ പേര് വ്യത്യസ്തമായിരിക്കാം), അതായത്, ssh കീയുടെ പൊതു ഭാഗം, സെർവറിലെ ഉപയോക്താവിനുള്ള അംഗീകൃത കീകളുടെ ലിസ്റ്റിലേക്ക് അത് അപ്‌ലോഡ് ചെയ്യുന്നു.

റോളുകൾ

ഉപയോഗം സൃഷ്‌ടിക്കുന്നതിനുള്ള മൂന്ന് ജോലികളും ഒരു ഗ്രൂപ്പിന്റെ ടാസ്‌ക്കുകളായി എളുപ്പത്തിൽ തരംതിരിക്കാം, മാത്രമല്ല ഈ ഗ്രൂപ്പ് വളരെ വലുതാകാതിരിക്കാൻ പ്രധാന പ്ലേബുക്കിൽ നിന്ന് പ്രത്യേകം സംഭരിക്കുന്നത് നല്ലതാണ്. ഈ ആവശ്യത്തിനായി, അൻസിബിളിന് ഉണ്ട് വേഷങ്ങൾ.
തുടക്കത്തിൽ സൂചിപ്പിച്ച ഫയൽ ഘടന അനുസരിച്ച്, റോളുകൾ ഒരു പ്രത്യേക റോളുകളുടെ ഡയറക്ടറിയിൽ സ്ഥാപിക്കണം, ഓരോ റോളിനും ടാസ്ക്കുകൾ, ഫയലുകൾ, ടെംപ്ലേറ്റുകൾ മുതലായവയ്ക്കുള്ളിൽ അതേ പേരിൽ ഒരു പ്രത്യേക ഡയറക്ടറി ഉണ്ട്.
നമുക്ക് ഒരു ഫയൽ ഘടന ഉണ്ടാക്കാം: ./ansible/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.

nginx സജ്ജീകരിക്കുന്നു

ഞങ്ങൾ ഇതിനകം തന്നെ Nginx ഇൻസ്റ്റാൾ ചെയ്തിരിക്കണം; ഞങ്ങൾ അത് കോൺഫിഗർ ചെയ്ത് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. റോളിൽ ഉടനെ ചെയ്യാം. നമുക്ക് ഒരു ഫയൽ ഘടന ഉണ്ടാക്കാം:

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

ഇപ്പോൾ നമുക്ക് ഫയലുകളും ടെംപ്ലേറ്റുകളും ആവശ്യമാണ്. അവ തമ്മിലുള്ള വ്യത്യാസം, അൻസിബിൾ ഫയലുകൾ നേരിട്ട് പകർത്തുന്നു എന്നതാണ്. ടെംപ്ലേറ്റുകൾക്ക് j2 എക്സ്റ്റൻഷൻ ഉണ്ടായിരിക്കണം, അതേ ഇരട്ട ചുരുണ്ട ബ്രേസുകൾ ഉപയോഗിച്ച് അവയ്ക്ക് വേരിയബിൾ മൂല്യങ്ങൾ ഉപയോഗിക്കാം.

നമുക്ക് nginx in പ്രവർത്തനക്ഷമമാക്കാം main.yml ഫയൽ. ഇതിനായി ഞങ്ങൾക്ക് ഒരു systemd മൊഡ്യൂൾ ഉണ്ട്:

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

ഇവിടെ ഞങ്ങൾ nginx ആരംഭിക്കണമെന്ന് മാത്രമല്ല (അതായത്, ഞങ്ങൾ അത് സമാരംഭിക്കുന്നു) മാത്രമല്ല, അത് പ്രവർത്തനക്ഷമമാക്കണമെന്ന് ഞങ്ങൾ ഉടൻ പറയുന്നു.
ഇനി നമുക്ക് കോൺഫിഗറേഷൻ ഫയലുകൾ പകർത്താം:

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

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'

ഞങ്ങൾ പ്രധാന nginx കോൺഫിഗറേഷൻ ഫയൽ സൃഷ്ടിക്കുന്നു (നിങ്ങൾക്ക് ഇത് സെർവറിൽ നിന്ന് നേരിട്ട് എടുക്കാം, അല്ലെങ്കിൽ സ്വയം എഴുതാം). കൂടാതെ sites_available ഡയറക്‌ടറിയിലെ ഞങ്ങളുടെ ആപ്ലിക്കേഷനായുള്ള കോൺഫിഗറേഷൻ ഫയലും (ഇത് ആവശ്യമില്ല, പക്ഷേ ഉപയോഗപ്രദമാണ്). ആദ്യ സന്ദർഭത്തിൽ, ഫയലുകൾ പകർത്താൻ ഞങ്ങൾ കോപ്പി മൊഡ്യൂൾ ഉപയോഗിക്കുന്നു (ഫയൽ അകത്തായിരിക്കണം /ansible/roles/nginx/files/nginx.conf). രണ്ടാമത്തേതിൽ, വേരിയബിളുകളുടെ മൂല്യങ്ങൾ മാറ്റിസ്ഥാപിച്ച് ഞങ്ങൾ ടെംപ്ലേറ്റ് പകർത്തുന്നു. ടെംപ്ലേറ്റ് ഉണ്ടായിരിക്കണം /ansible/roles/nginx/templates/my_app.j2). കൂടാതെ ഇത് ഇതുപോലെ തോന്നാം:

upstream {{ app_name }} {
  server unix:{{ app_path }}/shared/tmp/sockets/puma.sock;
}

server {
  listen 80;
  server_name {{ server_name }} {{ inventory_hostname }};
  root {{ app_path }}/current/public;

  try_files $uri/index.html $uri.html $uri @{{ app_name }};
  ....
}

ഉൾപ്പെടുത്തലുകളിൽ ശ്രദ്ധിക്കുക {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} - ഇവയെല്ലാം വേരിയബിളുകളാണ്, അതിന്റെ മൂല്യങ്ങൾ പകർത്തുന്നതിന് മുമ്പ് അൻസിബിൾ ടെംപ്ലേറ്റിലേക്ക് പകരും. ഹോസ്റ്റുകളുടെ വിവിധ ഗ്രൂപ്പുകൾക്കായി നിങ്ങൾ ഒരു പ്ലേബുക്ക് ഉപയോഗിക്കുകയാണെങ്കിൽ ഇത് ഉപയോഗപ്രദമാണ്. ഉദാഹരണത്തിന്, നമുക്ക് നമ്മുടെ ഇൻവെന്ററി ഫയൽ ചേർക്കാം:

[production]
123.123.123.123

[staging]
231.231.231.231

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

[production:vars]
server_name=production
app_path=/home/www/my_app
app_name=my_app

[staging:vars]
server_name=staging
app_path=/home/www/my_stage
app_name=my_stage_app

ഞങ്ങൾ ഇപ്പോൾ ഞങ്ങളുടെ പ്ലേബുക്ക് സമാരംഭിക്കുകയാണെങ്കിൽ, അത് രണ്ട് ഹോസ്റ്റുകൾക്കും നിർദ്ദിഷ്‌ട ടാസ്‌ക്കുകൾ നിർവഹിക്കും. എന്നാൽ അതേ സമയം, ഒരു സ്റ്റേജിംഗ് ഹോസ്റ്റിനായി, വേരിയബിളുകൾ പ്രൊഡക്ഷനിൽ നിന്ന് വ്യത്യസ്തമായിരിക്കും, കൂടാതെ റോളുകളിലും പ്ലേബുക്കുകളിലും മാത്രമല്ല, nginx കോൺഫിഗറുകളിലും. {{ inventory_hostname }} ഇൻവെന്ററി ഫയലിൽ വ്യക്തമാക്കേണ്ടതില്ല - ഇത് പ്രത്യേക അൻസിബിൾ വേരിയബിൾ പ്ലേബുക്ക് നിലവിൽ പ്രവർത്തിക്കുന്ന ഹോസ്റ്റ് അവിടെ സംഭരിച്ചിരിക്കുന്നു.
നിങ്ങൾക്ക് നിരവധി ഹോസ്റ്റുകൾക്കായി ഒരു ഇൻവെന്ററി ഫയൽ വേണമെങ്കിൽ, ഒരു ഗ്രൂപ്പിനായി മാത്രം പ്രവർത്തിപ്പിക്കുക, ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച് ഇത് ചെയ്യാൻ കഴിയും:

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

വ്യത്യസ്ത ഗ്രൂപ്പുകൾക്കായി പ്രത്യേക ഇൻവെന്ററി ഫയലുകൾ ഉണ്ടായിരിക്കുന്നതാണ് മറ്റൊരു ഓപ്ഷൻ. അല്ലെങ്കിൽ നിങ്ങൾക്ക് വ്യത്യസ്ത ഹോസ്റ്റുകൾ ഉണ്ടെങ്കിൽ നിങ്ങൾക്ക് രണ്ട് സമീപനങ്ങളും സംയോജിപ്പിക്കാം.

നമുക്ക് nginx സജ്ജീകരിക്കുന്നതിലേക്ക് മടങ്ങാം. കോൺഫിഗറേഷൻ ഫയലുകൾ പകർത്തിയ ശേഷം, sites_available എന്നതിൽ നിന്ന് my_app.conf ലേക്ക് sitest_enabled എന്നതിൽ ഒരു സിംലിങ്ക് സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഒപ്പം nginx പുനരാരംഭിക്കുക.

... # old code in mail.yml

- name: Create symlink to sites-enabled
  file:
    src: /etc/nginx/sites-available/my_app.conf
    dest: /etc/nginx/sites-enabled/my_app.conf
    state: link

- name: restart nginx
  service:
    name: nginx
    state: restarted

ഇവിടെ എല്ലാം ലളിതമാണ് - സാധാരണ വാക്യഘടനയുള്ള വീണ്ടും അൻസിബിൾ മൊഡ്യൂളുകൾ. എന്നാൽ ഒരു പോയിന്റുണ്ട്. ഓരോ തവണയും nginx പുനരാരംഭിക്കുന്നതിൽ അർത്ഥമില്ല. “ഇത് ഇതുപോലെ ചെയ്യുക” എന്നതുപോലുള്ള കമാൻഡുകൾ ഞങ്ങൾ എഴുതുന്നില്ലെന്ന് നിങ്ങൾ ശ്രദ്ധിച്ചിട്ടുണ്ടോ, വാക്യഘടന “ഇതിന് ഈ അവസ്ഥ ഉണ്ടായിരിക്കണം” എന്ന് തോന്നുന്നു. മിക്കപ്പോഴും ഇങ്ങനെയാണ് അൻസിബിൾ പ്രവർത്തിക്കുന്നത്. ഗ്രൂപ്പ് ഇതിനകം നിലവിലുണ്ടെങ്കിൽ, അല്ലെങ്കിൽ സിസ്റ്റം പാക്കേജ് ഇതിനകം ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, അൻസിബിൾ ഇത് പരിശോധിച്ച് ടാസ്ക് ഒഴിവാക്കും. കൂടാതെ, സെർവറിൽ ഇതിനകം ഉള്ളവയുമായി പൂർണ്ണമായും പൊരുത്തപ്പെടുന്നെങ്കിൽ ഫയലുകൾ പകർത്തപ്പെടില്ല. കോൺഫിഗറേഷൻ ഫയലുകൾ മാറ്റിയിട്ടുണ്ടെങ്കിൽ മാത്രമേ നമുക്ക് ഇത് പ്രയോജനപ്പെടുത്താനും nginx പുനരാരംഭിക്കാനും കഴിയൂ. ഇതിനായി ഒരു രജിസ്റ്റർ നിർദ്ദേശമുണ്ട്:

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

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes
  register: restart_nginx

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'
  register: restart_nginx

- name: Create symlink to sites-enabled
  file:
    src: /etc/nginx/sites-available/my_app.conf
    dest: /etc/nginx/sites-enabled/my_app.conf
    state: link

- name: restart nginx
  service:
    name: nginx
    state: restarted
  when: restart_nginx.changed

കോൺഫിഗറേഷൻ ഫയലുകളിലൊന്ന് മാറുകയാണെങ്കിൽ, ഒരു പകർപ്പ് നിർമ്മിക്കുകയും വേരിയബിൾ രജിസ്റ്റർ ചെയ്യുകയും ചെയ്യും restart_nginx. ഈ വേരിയബിൾ രജിസ്റ്റർ ചെയ്തിട്ടുണ്ടെങ്കിൽ മാത്രമേ സേവനം പുനരാരംഭിക്കുകയുള്ളൂ.

കൂടാതെ, തീർച്ചയായും, നിങ്ങൾ പ്രധാന പ്ലേബുക്കിലേക്ക് nginx റോൾ ചേർക്കേണ്ടതുണ്ട്.

postgresql സജ്ജീകരിക്കുന്നു

നമ്മൾ nginx-ൽ ചെയ്ത അതേ രീതിയിൽ systemd ഉപയോഗിച്ച് postgresql പ്രവർത്തനക്ഷമമാക്കേണ്ടതുണ്ട്, കൂടാതെ ഡാറ്റാബേസും ഡാറ്റാബേസും ആക്സസ് ചെയ്യാൻ ഞങ്ങൾ ഉപയോഗിക്കുന്ന ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുകയും വേണം.
നമുക്ക് ഒരു റോൾ സൃഷ്ടിക്കാം /ansible/roles/postgresql/tasks/main.yml:

# Create user in postgresql
- name: enable postgresql and start
  systemd:
    name: postgresql
    state: started
    enabled: yes

- name: Create database user
  become_user: postgres
  postgresql_user:
    name: "{{ db_user }}"
    password: "{{ db_password }}"
    role_attr_flags: SUPERUSER

- name: Create database
  become_user: postgres
  postgresql_db:
    name: "{{ db_name }}"
    encoding: UTF-8
    owner: "{{ db_user }}"

ഇൻവെന്ററിയിലേക്ക് വേരിയബിളുകൾ എങ്ങനെ ചേർക്കാമെന്ന് ഞാൻ വിവരിക്കുന്നില്ല, ഇത് ഇതിനകം തന്നെ നിരവധി തവണ ചെയ്തിട്ടുണ്ട്, കൂടാതെ postgresql_db, postgresql_user മൊഡ്യൂളുകളുടെ വാക്യഘടനയും. കൂടുതൽ വിവരങ്ങൾ ഡോക്യുമെന്റേഷനിൽ കാണാം. ഇവിടെ ഏറ്റവും രസകരമായ നിർദ്ദേശം become_user: postgres. സ്ഥിരസ്ഥിതിയായി, postgres ഉപയോക്താവിന് മാത്രമേ postgresql ഡാറ്റാബേസിലേക്ക് പ്രവേശനമുള്ളൂ, പ്രാദേശികമായി മാത്രം. ഈ ഉപയോക്താവിന് വേണ്ടി കമാൻഡുകൾ എക്സിക്യൂട്ട് ചെയ്യാൻ ഈ നിർദ്ദേശം ഞങ്ങളെ അനുവദിക്കുന്നു (ഞങ്ങൾക്ക് ആക്സസ് ഉണ്ടെങ്കിൽ, തീർച്ചയായും).
കൂടാതെ, ഡാറ്റാബേസിലേക്ക് ഒരു പുതിയ ഉപയോക്താവിന് പ്രവേശനം അനുവദിക്കുന്നതിന് pg_hba.conf എന്നതിലേക്ക് ഒരു വരി ചേർക്കേണ്ടി വന്നേക്കാം. ഞങ്ങൾ nginx കോൺഫിഗറേഷൻ മാറ്റിയ അതേ രീതിയിൽ ഇത് ചെയ്യാൻ കഴിയും.

തീർച്ചയായും, നിങ്ങൾ പ്രധാന പ്ലേബുക്കിലേക്ക് postgresql റോൾ ചേർക്കേണ്ടതുണ്ട്.

Rbenv വഴി റൂബി ഇൻസ്റ്റാൾ ചെയ്യുന്നു

അൻസിബിളിന് rbenv-നൊപ്പം പ്രവർത്തിക്കാനുള്ള മൊഡ്യൂളുകൾ ഇല്ല, പക്ഷേ ഇത് ഒരു git റിപ്പോസിറ്ററി ക്ലോണിംഗ് വഴിയാണ് ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നത്. അതിനാൽ, ഈ പ്രശ്നം ഏറ്റവും നിലവാരമില്ലാത്ത ഒന്നായി മാറുന്നു. നമുക്ക് അവൾക്കായി ഒരു റോൾ ഉണ്ടാക്കാം /ansible/roles/ruby_rbenv/main.yml നമുക്ക് അത് പൂരിപ്പിക്കാൻ തുടങ്ങാം:

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

ഈ ആവശ്യങ്ങൾക്കായി ഞങ്ങൾ സൃഷ്‌ടിച്ച ഉപയോക്താവിന് കീഴിൽ പ്രവർത്തിക്കാൻ ഞങ്ങൾ വീണ്ടും become_user നിർദ്ദേശം ഉപയോഗിക്കുന്നു. rbenv അതിന്റെ ഹോം ഡയറക്ടറിയിൽ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നതിനാൽ, ആഗോളതലത്തിൽ അല്ല. റിപ്പോ, ഡെസ്‌റ്റ് എന്നിവ വ്യക്തമാക്കുന്ന റിപ്പോസിറ്ററി ക്ലോൺ ചെയ്യാനും ഞങ്ങൾ ജിറ്റ് മൊഡ്യൂൾ ഉപയോഗിക്കുന്നു.

അടുത്തതായി, bashrc-ൽ rbenv init രജിസ്റ്റർ ചെയ്യുകയും അവിടെ PATH-ലേക്ക് rbenv ചേർക്കുകയും വേണം. ഇതിനായി ഞങ്ങൾക്ക് lineinfile മൊഡ്യൂൾ ഉണ്ട്:

- name: Add rbenv to PATH
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'export PATH="${HOME}/.rbenv/bin:${PATH}"'

- name: Add rbenv init to bashrc
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'eval "$(rbenv init -)"'

അതിനുശേഷം നിങ്ങൾ ruby_build ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട്:

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

അവസാനം റൂബി ഇൻസ്റ്റാൾ ചെയ്യുക. ഇത് rbenv വഴിയാണ് ചെയ്യുന്നത്, അതായത്, ബാഷ് കമാൻഡ് ഉപയോഗിച്ച്:

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

ഏത് കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യണമെന്നും എന്തുപയോഗിച്ച് നടത്തണമെന്നും ഞങ്ങൾ പറയുന്നു. എന്നിരുന്നാലും, കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് bashrc-ൽ അടങ്ങിയിരിക്കുന്ന കോഡ് ansible പ്രവർത്തിപ്പിക്കുന്നില്ല എന്ന വസ്തുത ഇവിടെ കാണാം. ഇതിനർത്ഥം rbenv അതേ സ്ക്രിപ്റ്റിൽ നേരിട്ട് നിർവചിക്കേണ്ടതുണ്ട് എന്നാണ്.

ഷെൽ കമാൻഡിന് ഒരു അൻസിബിൾ വീക്ഷണത്തിൽ യാതൊരു അവസ്ഥയും ഇല്ല എന്ന വസ്തുതയാണ് അടുത്ത പ്രശ്നം. അതായത്, റൂബിയുടെ ഈ പതിപ്പ് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോ ഇല്ലയോ എന്ന് യാന്ത്രിക പരിശോധന ഉണ്ടാകില്ല. നമുക്ക് ഇത് സ്വയം ചെയ്യാൻ കഴിയും:

- name: Install ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    if ! rbenv versions | grep -q {{ ruby_version }}
      then rbenv install {{ ruby_version }} && rbenv global {{ ruby_version }}
    fi
  args:
    executable: /bin/bash

ബണ്ടർ ഇൻസ്റ്റാൾ ചെയ്യാൻ മാത്രം അവശേഷിക്കുന്നു:

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

വീണ്ടും, പ്രധാന പ്ലേബുക്കിലേക്ക് ഞങ്ങളുടെ റോൾ ruby_rbenv ചേർക്കുക.

പങ്കിട്ട ഫയലുകൾ.

പൊതുവേ, സജ്ജീകരണം ഇവിടെ പൂർത്തിയാക്കാം. അടുത്തതായി, കാപ്പിസ്ട്രാനോ പ്രവർത്തിപ്പിക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്, അത് കോഡ് തന്നെ പകർത്തുകയും ആവശ്യമായ ഡയറക്ടറികൾ സൃഷ്ടിക്കുകയും ആപ്ലിക്കേഷൻ സമാരംഭിക്കുകയും ചെയ്യും (എല്ലാം ശരിയായി ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിൽ). എന്നിരുന്നാലും, ക്യാപിസ്ട്രാനോയ്ക്ക് പലപ്പോഴും അധിക കോൺഫിഗറേഷൻ ഫയലുകൾ ആവശ്യമാണ് database.yml അഥവാ .env nginx-നുള്ള ഫയലുകളും ടെംപ്ലേറ്റുകളും പോലെ അവ പകർത്താനാകും. ഒരു സൂക്ഷ്മത മാത്രമേയുള്ളൂ. ഫയലുകൾ പകർത്തുന്നതിന് മുമ്പ്, നിങ്ങൾ അവയ്ക്കായി ഒരു ഡയറക്ടറി ഘടന സൃഷ്ടിക്കേണ്ടതുണ്ട്, ഇതുപോലുള്ള ഒന്ന്:

# 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 (ഇൻവെന്ററി ഫയലിലെന്നപോലെ, ഹോസ്റ്റുകളുടെ വ്യത്യസ്‌ത ഗ്രൂപ്പുകൾക്കായി ഇവിടെ നിങ്ങൾക്ക് വ്യത്യസ്‌ത ഫയലുകൾ സൃഷ്‌ടിക്കാൻ കഴിയും: production.yml, staging.yml, മുതലായവ).
എൻക്രിപ്റ്റ് ചെയ്യേണ്ട എല്ലാ വേരിയബിളുകളും സ്റ്റാൻഡേർഡ് yml വാക്യഘടന ഉപയോഗിച്ച് ഈ ഫയലിലേക്ക് ട്രാൻസ്ഫർ ചെയ്യണം:

# System vars
user_password: 123qweasd
db_password: 123qweasd

# ENV vars
aws_access_key_id: xxxxx
aws_secret_access_key: xxxxxx
aws_bucket: bucket_name
rails_secret_key_base: very_secret_key_base

അതിനുശേഷം ഈ ഫയൽ കമാൻഡ് ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യാൻ കഴിയും:

ansible-vault encrypt ./vars/all.yml

സ്വാഭാവികമായും, എൻക്രിപ്റ്റ് ചെയ്യുമ്പോൾ, ഡീക്രിപ്ഷനായി നിങ്ങൾ ഒരു രഹസ്യവാക്ക് സജ്ജീകരിക്കേണ്ടതുണ്ട്. ഈ കമാൻഡ് വിളിച്ചതിന് ശേഷം ഫയലിനുള്ളിൽ എന്തായിരിക്കുമെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും.

സഹായത്തോടെ ansible-vault decrypt ഫയൽ ഡീക്രിപ്റ്റ് ചെയ്യാനും പരിഷ്കരിക്കാനും വീണ്ടും എൻക്രിപ്റ്റ് ചെയ്യാനും കഴിയും.

പ്രവർത്തിക്കാൻ നിങ്ങൾ ഫയൽ ഡീക്രിപ്റ്റ് ചെയ്യേണ്ടതില്ല. നിങ്ങൾ അത് എൻക്രിപ്റ്റ് ചെയ്‌ത് സംഭരിക്കുകയും ആർഗ്യുമെന്റിനൊപ്പം പ്ലേബുക്ക് പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുക --ask-vault-pass. അൻസിബിൾ പാസ്‌വേഡ് ചോദിക്കുകയും വേരിയബിളുകൾ വീണ്ടെടുക്കുകയും ടാസ്‌ക്കുകൾ എക്‌സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യും. എല്ലാ ഡാറ്റയും എൻക്രിപ്റ്റായി തുടരും.

ഹോസ്റ്റുകളുടെയും അൻസിബിൾ വോൾട്ടിന്റെയും നിരവധി ഗ്രൂപ്പുകൾക്കുള്ള സമ്പൂർണ്ണ കമാൻഡ് ഇതുപോലെയായിരിക്കും:

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

എന്നാൽ പ്ലേബുക്കുകളുടെയും റോളുകളുടെയും മുഴുവൻ വാചകവും ഞാൻ നിങ്ങൾക്ക് നൽകില്ല, അത് സ്വയം എഴുതുക. കാരണം അൻസിബിൾ അങ്ങനെയാണ് - എന്താണ് ചെയ്യേണ്ടതെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകുന്നില്ലെങ്കിൽ, അത് നിങ്ങൾക്കായി ചെയ്യില്ല.

അവലംബം: www.habr.com