הגדרת שרת לפריסת יישום Rails באמצעות Ansible

לפני זמן לא רב הייתי צריך לכתוב כמה ספרי משחק של Ansible כדי להכין את השרת לפריסת יישום Rails. ובאופן מפתיע, לא מצאתי מדריך פשוט שלב אחר שלב. לא רציתי להעתיק ספר משחק של מישהו אחר בלי להבין מה קורה, ובסופו של דבר הייתי צריך לקרוא את התיעוד, לאסוף הכל בעצמי. אולי אני יכול לעזור למישהו להאיץ את התהליך הזה בעזרת המאמר הזה.

הדבר הראשון שצריך להבין הוא ש-ansible מספקת לך ממשק נוח לביצוע רשימה מוגדרת מראש של פעולות בשרת(ים) מרוחקים באמצעות SSH. אין כאן קסם, אתה לא יכול להתקין תוסף ולקבל אפס פריסת זמן השבתה של היישום שלך עם docker, ניטור ועוד דברים טובים מחוץ לקופסה. כדי לכתוב ספר משחק, עליך לדעת מה בדיוק אתה רוצה לעשות ואיך לעשות זאת. זו הסיבה שאני לא מרוצה עם ספרי משחק מוכנים מ-GitHub, או מאמרים כמו: "העתק והרץ, זה יעבוד."

מה שאנחנו צריכים?

כפי שכבר אמרתי, כדי לכתוב ספר משחק אתה צריך לדעת מה אתה רוצה לעשות ואיך לעשות את זה. בואו נחליט מה אנחנו צריכים. עבור יישום Rails נצטרך מספר חבילות מערכת: nginx, postgresql (redis וכו'). בנוסף, אנחנו צריכים גרסה ספציפית של אודם. עדיף להתקין אותו דרך rbenv (rvm, asdf...). להפעיל את כל זה כמשתמש שורש זה תמיד רעיון רע, אז אתה צריך ליצור משתמש נפרד ולהגדיר את הזכויות שלו. לאחר מכן, עליך להעלות את הקוד שלנו לשרת, להעתיק את ההגדרות עבור nginx, postgres וכו' ולהתחיל את כל השירותים הללו.

כתוצאה מכך, רצף הפעולות הוא כדלקמן:

1. התחבר כשורש
2. להתקין חבילות מערכת
3. ליצור משתמש חדש, להגדיר זכויות, מפתח ssh
4. הגדר חבילות מערכת (nginx וכו') והפעל אותן
5. אנו יוצרים משתמש במסד הנתונים (ניתן ליצור מיד מסד נתונים)
6. התחבר כמשתמש חדש
7. התקן rbenv ו-ruby
8. התקנת הבאנדלר
9. העלאת קוד האפליקציה
10. הפעלת שרת Puma

יתר על כן, ניתן לבצע את השלבים האחרונים באמצעות capistrano, לפחות מחוץ לקופסה הוא יכול להעתיק קוד לתוך ספריות שחרור, להחליף את הגרסה עם סימלינק לאחר פריסה מוצלחת, להעתיק הגדרות מספרייה משותפת, להפעיל מחדש את puma וכו'. כל זה יכול להיעשות באמצעות Ansible, אבל למה?

מבנה הקובץ

לאנסיבל יש קפדן מבנה הקובץ עבור כל הקבצים שלך, אז עדיף לשמור הכל בספרייה נפרדת. יתרה מכך, זה לא כל כך חשוב אם זה יהיה ביישום המסילות עצמו, או בנפרד. אתה יכול לאחסן קבצים במאגר git נפרד. באופן אישי, מצאתי שהכי נוח ליצור ספרייה מתאימה בספריית /config של יישום rails ולאחסן הכל במאגר אחד.

ספר משחק פשוט

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 אומר שהוא לא מכיר מארחים שתואמים לרשימת הכל. הם חייבים להיות רשומים בספיישל קובץ מלאי.

בואו ניצור אותו באותה ספרייה אפשרית:

123.123.123.123

כך אנו פשוט מציינים את המארח (באופן אידיאלי המארח של ה-VPS שלנו לבדיקה, או שאתה יכול לרשום localhost) ונשמור אותו תחת השם inventory.
אתה יכול לנסות להריץ אנסible עם קובץ מצאי:

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

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

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

אם יש לך גישת ssh למארח שצוין, אזי אנסיבל תתחבר ותאסוף מידע על המערכת המרוחקת. (ברירת מחדל TASK [איסוף עובדות]) שלאחריה הוא ייתן דוח קצר על הביצוע (PLAY RECAP).

כברירת מחדל, החיבור משתמש בשם המשתמש שתחתיו אתה מחובר למערכת. סביר להניח שזה לא יהיה על המארח. בקובץ Playbook, אתה יכול לציין באיזה משתמש להשתמש כדי להתחבר באמצעות ההנחיה remote_user. כמו כן, מידע על מערכת מרוחקת עשוי להיות מיותר עבורך, ואין לבזבז זמן באיסוף. ניתן להשבית משימה זו גם:

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

נסה להפעיל שוב את ספר ההפעלה וודא שהחיבור פועל. (אם ציינת את משתמש השורש, עליך לציין גם את ההנחיה word: true על מנת לזכות בזכויות מוגברות. כפי שכתוב בתיעוד: become set to ‘true’/’yes’ to activate privilege escalation. למרות שלא לגמרי ברור למה).

אולי תקבל שגיאה שנגרמה בגלל העובדה ש-ansible לא יכול לקבוע את המתורגמן של Python, ואז תוכל לציין זאת באופן ידני:

ansible_python_interpreter: /usr/bin/python3 

אתה יכול לגלות היכן יש לך python עם הפקודה whereis python.

התקנת חבילות מערכת

ההפצה הסטנדרטית של Ansible כוללת מודולים רבים לעבודה עם חבילות מערכת שונות, כך שלא נצטרך לכתוב סקריפטים של bash מכל סיבה שהיא. כעת אנו זקוקים לאחד מהמודולים הללו כדי לעדכן את המערכת ולהתקין חבילות מערכת. יש לי אובונטו לינוקס ב-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

משימה היא בדיוק המשימה ש-Ansible תבצע בשרתים מרוחקים. אנו נותנים למשימה שם כדי שנוכל לעקוב אחר ביצועה ביומן. ואנחנו מתארים, באמצעות התחביר של מודול ספציפי, מה הוא צריך לעשות. במקרה הזה apt: update_cache=yes - אומר לעדכן חבילות מערכת באמצעות מודול apt. הפקודה השנייה קצת יותר מסובכת. אנו מעבירים רשימה של חבילות למודול apt ואומרים שכן state צריך להפוך present, כלומר, אנו אומרים להתקין את החבילות הללו. באופן דומה, אנו יכולים לומר להם למחוק אותם, או לעדכן אותם פשוט על ידי שינוי state. שימו לב שכדי ש-rails יעבדו עם 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 כמו שהיית עושה את זה ידנית. וזה שומר את כל הנתונים ישירות, ולכן אנחנו חייבים גם להמיר את הסיסמה ל-hash מראש, וזה מה שהפקודה הזו עושה.

בואו נוסיף את המשתמש שלנו לקבוצת 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 הוא הקובץ הראשי שייטען ויבוצע כאשר תפקיד מחובר ל-Playbook; ניתן לחבר אליו קבצי תפקידים אחרים). כעת תוכל להעביר את כל המשימות הקשורות למשתמש לקובץ הזה:

# 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 פנימה 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 }} - אלה כל המשתנים שהערכים שלהם 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. לאחר העתקת קובצי התצורה, עלינו ליצור קישור סימול ב-sitest_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 עובד. אם הקבוצה כבר קיימת, או שחבילת המערכת כבר מותקנת, אזי אנסיבל תבדוק זאת ותדלג על המשימה. כמו כן, קבצים לא יועתקו אם הם תואמים לחלוטין למה שכבר נמצא בשרת. נוכל לנצל זאת ולהפעיל מחדש את 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

אנו שוב משתמשים בהנחיית become_user כדי לעבוד תחת המשתמש שיצרנו למטרות אלו. מאז rbenv מותקן בספריית הבית שלו, ולא באופן גלובלי. ואנחנו גם משתמשים במודול git כדי לשכפל את המאגר, תוך ציון ריפו ו-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

כל מה שנותר הוא להתקין bundler:

- 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 תיצור אוטומטית ספריות אב במידת הצורך.

כספת אנסיבל

כבר נתקלנו בעובדה שמשתנים יכולים להכיל נתונים סודיים כמו סיסמת המשתמש. אם יצרת .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

אבל אני לא אתן לך את הטקסט המלא של ספרי משחק ותפקידים, כתוב את זה בעצמך. כי אנסיב זה ככה - אם אתה לא מבין מה צריך לעשות, אז זה לא יעשה את זה בשבילך.

מקור: www.habr.com