სერვერის დაყენება Rails აპლიკაციის განსათავსებლად Ansible-ის გამოყენებით

არც ისე დიდი ხნის წინ დამჭირდა რამდენიმე Ansible სათამაშო წიგნის დაწერა, რომ სერვერი მოემზადებინა Rails აპლიკაციის დასაყენებლად. და, გასაკვირია, რომ მე ვერ ვიპოვე მარტივი ნაბიჯ-ნაბიჯ სახელმძღვანელო. არ მინდოდა სხვისი სათამაშო წიგნის კოპირება ისე, რომ არ გამეგო რა ხდებოდა და ბოლოს მომიწია დოკუმენტაციის წაკითხვა, ყველაფერი თავად შემეგროვებინა. იქნებ დავეხმარო ვინმეს ამ პროცესის დაჩქარებაში ამ სტატიის დახმარებით.

პირველი, რაც უნდა გვესმოდეს, არის ის, რომ ansible გაძლევთ მოსახერხებელ ინტერფეისს, რათა შეასრულოთ მოქმედებების წინასწარ განსაზღვრული სია დისტანციურ სერვერ(ებ)ზე SSH-ის საშუალებით. აქ ჯადოქრობა არ არის, თქვენ არ შეგიძლიათ დააინსტალიროთ დანამატი და არ მიიღოთ თქვენი აპლიკაციის ნულოვანი შეფერხება დოკერით, მონიტორინგით და სხვა სიკეთეებით. სათამაშო წიგნის დასაწერად, თქვენ უნდა იცოდეთ ზუსტად რისი გაკეთება გსურთ და როგორ გააკეთოთ ეს. ამიტომაც არ ვარ კმაყოფილი GitHub-ის მზა სათამაშო წიგნებით ან სტატიებით, როგორიცაა: „დააკოპირეთ და გაუშვით, ის იმუშავებს“.

რა გვჭირდება?

როგორც უკვე ვთქვი, სათამაშო წიგნის დასაწერად თქვენ უნდა იცოდეთ რისი გაკეთება გსურთ და როგორ გააკეთოთ ეს. მოდით გადავწყვიტოთ რა გვჭირდება. Rails აპლიკაციისთვის დაგვჭირდება რამდენიმე სისტემის პაკეტი: nginx, postgresql (redis და ა.შ.). გარდა ამისა, ჩვენ გვჭირდება რუბის კონკრეტული ვერსია. უმჯობესია მისი დაყენება rbenv-ის (rvm, asdf...) საშუალებით. ამ ყველაფრის გაშვება root მომხმარებელზე ყოველთვის ცუდი იდეაა, ასე რომ თქვენ უნდა შექმნათ ცალკე მომხმარებელი და დააკონფიგურიროთ მისი უფლებები. ამის შემდეგ, თქვენ უნდა ატვირთოთ ჩვენი კოდი სერვერზე, დააკოპიროთ კონფიგურაციები nginx-ისთვის, postgres-ისთვის და ა.შ. და დაიწყოთ ყველა ეს სერვისი.

შედეგად, მოქმედებების თანმიმდევრობა ასეთია:

1. შესვლა როგორც root
2. სისტემის პაკეტების დაყენება
3. შექმენით ახალი მომხმარებელი, დააკონფიგურირეთ უფლებები, ssh გასაღები
4. დააკონფიგურირეთ სისტემის პაკეტები (nginx და ა.შ.) და გაუშვით ისინი
5. ჩვენ ვქმნით მომხმარებელს მონაცემთა ბაზაში (შეგიძლიათ დაუყოვნებლივ შექმნათ მონაცემთა ბაზა)
6. შედით როგორც ახალი მომხმარებელი
7. დააინსტალირეთ rbenv და რუბი
8. ბანდლერის ინსტალაცია
9. აპლიკაციის კოდის ატვირთვა
10. Puma სერვერის გაშვება

უფრო მეტიც, ბოლო ეტაპები შეიძლება გაკეთდეს capistrano-ს გამოყენებით, ყოველ შემთხვევაში, მას შეუძლია კოდის კოპირება გამოშვების დირექტორიაში, გამოშვების გადართვა სიმბმულით წარმატებული განლაგებისას, კონფიგურაციის კოპირება საერთო დირექტორიადან, გადატვირთვა პუმა და ა.შ. ეს ყველაფერი შეიძლება გაკეთდეს Ansible-ის გამოყენებით, მაგრამ რატომ?

ფაილის სტრუქტურა

Ansible აქვს მკაცრი ფაილის სტრუქტურა ყველა თქვენი ფაილისთვის, ამიტომ უმჯობესია შეინახოთ ეს ყველაფერი ცალკე დირექტორიაში. უფრო მეტიც, არც ისე მნიშვნელოვანია, იქნება ის თავად რელსების აპლიკაციაში, თუ ცალკე. თქვენ შეგიძლიათ შეინახოთ ფაილები ცალკე git საცავში. პირადად მე ყველაზე მოსახერხებლად მივიჩნიე rails აპლიკაციის /config კატალოგის შექმნა და ყველაფრის ერთ საცავში შენახვა.

მარტივი სათამაშო წიგნი

Playbook არის yml ფაილი, რომელიც სპეციალური სინტაქსის გამოყენებით აღწერს რა და როგორ უნდა გააკეთოს Ansible-მა. მოდით შევქმნათ პირველი სათამაშო წიგნი, რომელიც არაფერს აკეთებს:

---
- name: Simple playbook
  hosts: all

აქ ჩვენ უბრალოდ ვამბობთ, რომ ჩვენი სათამაშო წიგნი ე.წ Simple Playbook და რომ მისი შინაარსი უნდა იყოს შესრულებული ყველა ჰოსტისთვის. ჩვენ შეგვიძლია შევინახოთ ის /ansible დირექტორიაში სახელით playbook.yml და სცადე გაშვება:

ansible-playbook ./playbook.yml

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

Ansible ამბობს, რომ არ იცნობს ჰოსტებს, რომლებიც ემთხვევა ყველა სიას. ისინი უნდა იყოს ჩამოთვლილი სპეციალურში ინვენტარის ფაილი.

მოდით შევქმნათ იგი იმავე ანsible დირექტორიაში:

123.123.123.123

ასე უბრალოდ ვაზუსტებთ ჰოსტს (იდეალურად ჩვენი VPS-ის მასპინძელი ტესტირებისთვის, ან შეგიძლიათ დაარეგისტრიროთ ლოკალჰოსტი) და ვინახავთ მას სახელით inventory.
შეგიძლიათ სცადოთ ansible-ის გაშვება ინვენტარის ფაილით:

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

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

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

თუ თქვენ გაქვთ ssh წვდომა მითითებულ ჰოსტზე, მაშინ ansible დააკავშირებს და შეაგროვებს ინფორმაციას დისტანციური სისტემის შესახებ. (ნაგულისხმევი TASK [ფაქტების შეგროვება]), რის შემდეგაც იგი წარადგენს მოკლე ანგარიშს შესრულების შესახებ (PLAY RECAP).

ნაგულისხმევად, კავშირი იყენებს მომხმარებლის სახელს, რომლითაც სისტემაში ხართ შესული. დიდი ალბათობით არ იქნება მასპინძელზე. Playbook ფაილში შეგიძლიათ მიუთითოთ რომელი მომხმარებელი გამოიყენოს დასაკავშირებლად remote_user დირექტივის გამოყენებით. ასევე, ინფორმაცია დისტანციური სისტემის შესახებ ხშირად შეიძლება თქვენთვის არასაჭირო იყოს და არ უნდა დაკარგოთ დრო მის შეგროვებაზე. ეს დავალება ასევე შეიძლება გამორთოთ:

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

სცადეთ ხელახლა გაუშვათ სათამაშო წიგნი და დარწმუნდით, რომ კავშირი მუშაობს. (თუ თქვენ მიუთითეთ root მომხმარებელი, მაშინ ასევე უნდა მიუთითოთ be: true დირექტივა, რათა მიიღოთ ამაღლებული უფლებები. როგორც წერია დოკუმენტაციაში: become set to ‘true’/’yes’ to activate privilege escalation. თუმცა ბოლომდე არ არის გასაგები რატომ).

შესაძლოა, თქვენ მიიღებთ შეცდომას, რომელიც გამოწვეულია იმით, რომ ansible ვერ განსაზღვრავს პითონის ინტერპრეტაციას, შემდეგ შეგიძლიათ ხელით მიუთითოთ:

ansible_python_interpreter: /usr/bin/python3 

თქვენ შეგიძლიათ გაიგოთ სად გაქვთ პითონი ბრძანებით whereis python.

სისტემის პაკეტების ინსტალაცია

Ansible-ის სტანდარტული დისტრიბუცია მოიცავს ბევრ მოდულს სხვადასხვა სისტემის პაკეტებთან მუშაობისთვის, ამიტომ ჩვენ არ გვიწევს bash სკრიპტების დაწერა რაიმე მიზეზით. ახლა ჩვენ გვჭირდება ერთ-ერთი ასეთი მოდული სისტემის განახლებისთვის და სისტემის პაკეტების დასაყენებლად. მე მაქვს Ubuntu Linux ჩემს VPS-ზე, ამიტომ პაკეტების დასაყენებლად ვიყენებ 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

Task არის ზუსტად ის დავალება, რომელსაც Ansible შეასრულებს დისტანციურ სერვერებზე. დავალებას ვაძლევთ სახელს, რათა თვალყური ადევნოთ მის შესრულებას ჟურნალში. და ჩვენ აღვწერთ კონკრეტული მოდულის სინტაქსის გამოყენებით, რა უნდა გააკეთოს. Ამ შემთხვევაში apt: update_cache=yes - ამბობს სისტემის პაკეტების განახლება apt მოდულის გამოყენებით. მეორე ბრძანება ცოტა უფრო რთულია. ჩვენ გადავცემთ პაკეტების ჩამონათვალს apt მოდულს და ვამბობთ, რომ ისინი არიან state უნდა გახდეს present, ანუ ჩვენ ვამბობთ დააინსტალირეთ ეს პაკეტები. ანალოგიურად, ჩვენ შეგვიძლია ვუთხრათ მათ წაშალონ ისინი, ან განაახლონ ისინი უბრალოდ შეცვლით state. გთხოვთ გაითვალისწინოთ, რომ რელსები postgresql-თან მუშაობისთვის გვჭირდება postgresql-contrib პაკეტი, რომელსაც ახლა ვაინსტალირებთ. კიდევ ერთხელ, თქვენ უნდა იცოდეთ და გააკეთოთ ეს; გონივრული არ გააკეთებს ამას.

სცადეთ ხელახლა გაუშვათ სათამაშო წიგნი და შეამოწმეთ, რომ პაკეტები დაინსტალირებულია.

ახალი მომხმარებლების შექმნა.

მომხმარებლებთან მუშაობისთვის Ansible-ს ასევე აქვს მოდული - მომხმარებელი. დავამატოთ კიდევ ერთი დავალება (მე დავმალე პლეიბუქის უკვე ცნობილი ნაწილები კომენტარების მიღმა, რათა ყოველ ჯერზე მთლიანად არ გადამეკოპირებინა):

---
- 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') }}". საქმე იმაშია, რომ ansible არ აყენებს მომხმარებლის მეშვეობით user_add როგორც ამას გააკეთებდი ხელით. და ის ინახავს ყველა მონაცემს პირდაპირ, რის გამოც ჩვენ ასევე უნდა გადავიყვანოთ პაროლი ჰეშად, რასაც ეს ბრძანება აკეთებს.

მოდით დავამატოთ ჩვენი მომხმარებელი sudo ჯგუფს. თუმცა, მანამდე უნდა დავრწმუნდეთ, რომ ასეთი ჯგუფი არსებობს, რადგან ამას ჩვენთვის არავინ გააკეთებს:

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

ყველაფერი საკმაოდ მარტივია, ჩვენ ასევე გვაქვს ჯგუფური მოდული ჯგუფების შესაქმნელად, სინტაქსით ძალიან ჰგავს apt-ს. მაშინ საკმარისია დაარეგისტრიროთ ეს ჯგუფი მომხმარებელზე (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-ს აქვს როლები.
თავიდანვე მითითებული ფაილის სტრუქტურის მიხედვით, როლები უნდა განთავსდეს ცალკე როლების დირექტორიაში, თითოეული როლისთვის არის ცალკე დირექტორია იგივე სახელწოდებით, ამოცანების, ფაილების, შაბლონების და ა.შ.
მოდით შევქმნათ ფაილის სტრუქტურა: ./ansible/roles/user/tasks/main.yml (main არის მთავარი ფაილი, რომელიც ჩაიტვირთება და შესრულდება, როდესაც როლი დაკავშირებულია სათამაშო წიგნთან; შესაძლებელია სხვა როლური ფაილების დაკავშირება). ახლა თქვენ შეგიძლიათ გადაიტანოთ მომხმარებელთან დაკავშირებული ყველა დავალება ამ ფაილში:

# 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

ახლა ჩვენ გვჭირდება ფაილები და შაბლონები. მათ შორის განსხვავება ისაა, რომ ansible აკოპირებს ფაილებს პირდაპირ, როგორც არის. და შაბლონებს უნდა ჰქონდეთ j2 გაფართოება და მათ შეუძლიათ გამოიყენონ ცვლადი მნიშვნელობები იგივე ორმაგი ხვეული ბრეკეტების გამოყენებით.

მოდით გავააქტიუროთ nginx in main.yml ფაილი. ამისათვის ჩვენ გვაქვს სისტემური მოდული:

# 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 }} - ეს არის ყველა ცვლადი, რომლის მნიშვნელობებს Ansible ჩაანაცვლებს შაბლონში კოპირებამდე. ეს სასარგებლოა, თუ იყენებთ სათამაშო წიგნს მასპინძლების სხვადასხვა ჯგუფისთვის. მაგალითად, ჩვენ შეგვიძლია დავამატოთ ჩვენი ინვენტარის ფაილი:

[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-ის დაყენებას. კონფიგურაციის ფაილების კოპირების შემდეგ, ჩვენ უნდა შევქმნათ symlink sites_enabled-ში my_app.conf-ზე sites_available-დან. და გადატვირთეთ 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-ის ყოველ ჯერზე გადატვირთვას აზრი არ აქვს. შენიშნეთ, რომ ჩვენ არ ვწერთ ბრძანებებს, როგორიცაა: „აკეთე ასე“, სინტაქსი უფრო ჰგავს „ამას უნდა ჰქონდეს ეს მდგომარეობა“. და ყველაზე ხშირად ზუსტად ასე მუშაობს ansible. თუ ჯგუფი უკვე არსებობს, ან სისტემის პაკეტი უკვე დაინსტალირებულია, მაშინ ansible შეამოწმებს ამას და გამოტოვებს დავალებას. ასევე, ფაილები არ დაკოპირდება, თუ ისინი მთლიანად ემთხვევა სერვერზე არსებულს. ჩვენ შეგვიძლია ვისარგებლოთ ამით და გადატვირთოთ 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-ის დაყენება

ჩვენ უნდა გავააქტიუროთ postgresql systemd-ის გამოყენებით ისევე, როგორც ეს გავაკეთეთ nginx-ის შემთხვევაში და ასევე შევქმნათ მომხმარებელი, რომელსაც გამოვიყენებთ მონაცემთა ბაზაში და თავად მონაცემთა ბაზაში შესასვლელად.
მოდით შევქმნათ როლი /ansible/roles/postgresql/tasks/main.yml:

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

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

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

მე არ აღვწერ, თუ როგორ დავამატო ცვლადები ინვენტარში, ეს უკვე არაერთხელ გაკეთდა, ასევე postgresql_db და postgresql_user მოდულების სინტაქსი. დამატებითი ინფორმაცია შეგიძლიათ იხილოთ დოკუმენტაციაში. ყველაზე საინტერესო დირექტივა აქ არის become_user: postgres. ფაქტია, რომ ნაგულისხმევად, მხოლოდ postgres მომხმარებელს აქვს წვდომა postgresql მონაცემთა ბაზაში და მხოლოდ ლოკალურად. ეს დირექტივა გვაძლევს საშუალებას ამ მომხმარებლის სახელით შევასრულოთ ბრძანებები (თუ გვაქვს წვდომა, რა თქმა უნდა).
ასევე, შეიძლება დაგჭირდეთ ხაზის დამატება pg_hba.conf-ზე, რათა ახალ მომხმარებელს დაუშვას მონაცემთა ბაზაში წვდომა. ეს შეიძლება გაკეთდეს ისევე, როგორც ჩვენ შევცვალეთ nginx კონფიგურაცია.

და რა თქმა უნდა, თქვენ უნდა დაამატოთ postgresql როლი მთავარ სათამაშო წიგნში.

რუბის დაყენება rbenv-ის საშუალებით

Ansible-ს არ აქვს მოდულები 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

ჩვენ კვლავ ვიყენებთ be_user დირექტივას, რომ იმუშაოთ მომხმარებლის ქვეშ, რომელიც ჩვენ ამ მიზნებისთვის შევქმენით. ვინაიდან rbenv დაინსტალირებულია მის მთავარ დირექტორიაში და არა გლობალურად. ჩვენ ასევე ვიყენებთ git მოდულს საცავის კლონირებისთვის, სადაც მითითებულია repo და dest.

შემდეგი, ჩვენ უნდა დავარეგისტრიროთ rbenv init bashrc-ში და დავამატოთ rbenv იქ PATH-ში. ამისათვის ჩვენ გვაქვს 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-ის მეშვეობით, ანუ უბრალოდ 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

ჩვენ ვამბობთ რომელი ბრძანება შევასრულოთ და რით. თუმცა, აქ ვხვდებით იმ ფაქტს, რომ ansible არ აწარმოებს bashrc-ში არსებულ კოდს ბრძანებების გაშვებამდე. ეს ნიშნავს, რომ 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 მთავარ სათამაშო წიგნში.

გაზიარებული ფაილები.

ზოგადად, დაყენება შეიძლება დასრულდეს აქ. შემდეგი, რჩება მხოლოდ capistrano-ს გაშვება და ის თავად დააკოპირებს კოდს, შექმნის საჭირო დირექტორიებს და გაუშვებს აპლიკაციას (თუ ყველაფერი სწორად არის კონფიგურირებული). თუმცა, capistrano ხშირად მოითხოვს დამატებით კონფიგურაციის ფაილებს, როგორიცაა database.yml ან .env მათი კოპირება შესაძლებელია ისევე, როგორც ფაილები და შაბლონები nginx-ისთვის. არსებობს მხოლოდ ერთი დახვეწილობა. ფაილების კოპირებამდე, თქვენ უნდა შექმნათ დირექტორია სტრუქტურა, დაახლოებით ასეთი:

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

ჩვენ ვაზუსტებთ მხოლოდ ერთ დირექტორიას და საჭიროების შემთხვევაში ansible ავტომატურად შექმნის მშობლებს.

Ansible Vault

ჩვენ უკვე შევხვდით იმ ფაქტს, რომ ცვლადები შეიძლება შეიცავდეს საიდუმლო მონაცემებს, როგორიცაა მომხმარებლის პაროლი. თუ შექმენი .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 ითხოვს პაროლს, ამოიღებს ცვლადებს და შეასრულებს დავალებებს. ყველა მონაცემი დაშიფრული დარჩება.

სრული ბრძანება მასპინძლების რამდენიმე ჯგუფისთვის და ცალმხრივი სარდაფით ასე გამოიყურება:

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

მაგრამ მე არ მოგცემთ სათამაშო წიგნების და როლების სრულ ტექსტს, თავად დაწერეთ. იმიტომ, რომ ansible ასეა - თუ არ გესმით, რა უნდა გააკეთოთ, მაშინ ის ამას არ გააკეთებს თქვენთვის.

წყარო: www.habr.com