כבר דיברנו על מחסנית טרנטול, המאפשר לך לפתח אפליקציות מבוזרות ולארוז אותן. כל מה שנותר הוא ללמוד כיצד לפרוס את היישומים הללו ולנהל אותם. אל דאגה, סיפקנו הכל! ריכזנו את כל שיטות העבודה המומלצות לעבודה עם Tarantool Cartridge וכתבנו ansible-תפקיד, אשר יפיץ את החבילה לשרתים, יפעיל מופעים, יאחד אותם לאשכול, תגדיר הרשאות, יפעל אתחול vshard, יאפשר כשל אוטומטי ויתקן את תצורת האשכול.

מעניין? אז בבקשה, מתחת לגזרה, נספר לך ונראה לך הכל.

נתחיל עם דוגמה

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

למחסנית Tarantool יש הדרכה ליצור אפליקציית Cartridge קטנה המאחסנת מידע על לקוחות הבנק והחשבונות שלהם, וגם מספקת API לניהול נתונים באמצעות HTTP. כדי להשיג זאת, הנספח מתאר שני תפקידים אפשריים: api и storage, שניתן להקצות למופעים.

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

ממילים למעשים

אז בואו נפרוס את האפליקציה שלנו לשתי מכונות וירטואליות ונגדיר טופולוגיה פשוטה:

• ערכת העתק app-1 יישם את התפקיד api, הכולל את התפקיד vshard-router. יהיה כאן רק מקרה אחד.
• ערכת העתק storage-1 מיישם את התפקיד storage (באותו הזמן vshard-storage), כאן נוסיף שני מופעים ממכונות שונות.

כדי להפעיל את הדוגמה שאנחנו צריכים מְשׁוֹטֵט и בלתי אפשרי (גרסה 2.8 ומעלה).

התפקיד עצמו נמצא אנסיבל גלקסי. זהו מאגר המאפשר לך לשתף את עבודתך ולהשתמש בתפקידים מוכנים.

בואו נשכפל את המאגר עם דוגמה:

$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0

אנו מגייסים מכונות וירטואליות:

$ vagrant up

התקן את התפקיד האפשרי של מחסנית Tarantool:

$ ansible-galaxy install tarantool.cartridge,1.0.1

הפעל את התפקיד המותקן:

$ ansible-playbook -i hosts.yml playbook.yml

אנחנו מחכים שספר המשחקים ישלים את הביצוע, עבור אל http://localhost:8181/admin/cluster/dashboard ותיהנו מהתוצאה:

אתה יכול להעלות נתונים. מגניב נכון?

עכשיו בואו נבין איך לעבוד עם זה, ובמקביל נוסיף עוד סט העתק לטופולוגיה.

בואו נתחיל להבין את זה

אז מה קרה?

הקמנו שתי מכונות וירטואליות והשקנו ספר הפעלה אפשרי שהגדיר את האשכול שלנו. בואו נסתכל על תוכן הקובץ playbook.yml:

---
- name: Deploy my Tarantool Cartridge app
  hosts: all
  become: true
  become_user: root
  tasks:
  - name: Import Tarantool Cartridge role
    import_role:
      name: tarantool.cartridge

שום דבר מעניין לא קורה כאן, בואו נשיק תפקיד סביר שנקרא tarantool.cartridge.

כל הדברים החשובים ביותר (כלומר, תצורת האשכול) נמצאים ב מלאי-קוֹבֶץ hosts.yml:

---
all:
  vars:
    # common cluster variables
    cartridge_app_name: getting-started-app
    cartridge_package_path: ./getting-started-app-1.0.0-0.rpm  # path to package

    cartridge_cluster_cookie: app-default-cookie  # cluster cookie

    # common ssh options
    ansible_ssh_private_key_file: ~/.vagrant.d/insecure_private_key
    ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

  # INSTANCES
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

    app-1:
      config:
        advertise_uri: '172.19.0.3:3301'
        http_port: 8182

    storage-1-replica:
      config:
        advertise_uri: '172.19.0.3:3302'
        http_port: 8183

  children:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        # first machine connection options
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # instances to be started on the first machine
        storage-1:

    host2:
      vars:
        # second machine connection options
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:

    # GROUP INSTANCES BY REPLICA SETS
    replicaset_app_1:
      vars:  # replica set configuration
        replicaset_alias: app-1
        failover_priority:
          - app-1  # leader
        roles:
          - 'api'

      hosts:  # replica set instances
        app-1:

    replicaset_storage_1:
      vars:  # replica set configuration
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # leader
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # replica set instances
        storage-1:
        storage-1-replica:

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

ניהול מופעים

במונחים של Ansible, כל מופע הוא מארח (לא להתבלבל עם שרת חומרה), כלומר. צומת התשתית שאנסיבל תנהל. עבור כל מארח אנו יכולים לציין פרמטרי חיבור (כגון ansible_host и ansible_user), כמו גם תצורת המופע. תיאור המופעים נמצא בסעיף hosts.

בואו נסתכל על תצורת המופע storage-1:

all:
  vars:
    ...

  # INSTANCES
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

במשתנה config ציינו את פרמטרי המופע - advertise URI и HTTP port.
להלן פרמטרי המופע app-1 и storage-1-replica.

עלינו לומר לאנסיבל את פרמטרי החיבור עבור כל מופע. נראה הגיוני לקבץ מופעים לקבוצות מכונות וירטואליות. לשם כך, מופעים משולבים לקבוצות host1 и host2, ובכל קבוצה במדור vars ערכים מצוינים ansible_host и ansible_user עבור מכונה וירטואלית אחת. ובמדור hosts - מארחים (המכונה גם מופעים) הכלולים בקבוצה זו:

all:
  vars:
    ...
  hosts:
    ...
  children:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        # first machine connection options
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hosts:  # instances to be started on the first machine
        storage-1:

     host2:
      vars:
        # second machine connection options
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:

אנחנו מתחילים להשתנות hosts.yml. בואו נוסיף עוד שני מקרים, storage-2-replica במכונה הוירטואלית הראשונה ו storage-2 בשני:

all:
  vars:
    ...

  # INSTANCES
  hosts:
    ...
    storage-2:  # <==
      config:
        advertise_uri: '172.19.0.3:3303'
        http_port: 8184

    storage-2-replica:  # <==
      config:
        advertise_uri: '172.19.0.2:3302'
        http_port: 8185

  children:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        ...
      hosts:  # instances to be started on the first machine
        storage-1:
        storage-2-replica:  # <==

    host2:
      vars:
        ...
      hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

הפעל את ספר המשחקים האפשרי:

$ ansible-playbook -i hosts.yml 
                   --limit storage-2,storage-2-replica 
                   playbook.yml

שימו לב לאפשרות --limit. מכיוון שכל מופע אשכול הוא מארח במונחים של Ansible, אנו יכולים לציין במפורש אילו מופעים יש להגדיר בעת הפעלת ספר ההפעלה.

חוזרים לממשק המשתמש באינטרנט http://localhost:8181/admin/cluster/dashboard וראה את המופעים החדשים שלנו:

בואו לא נעצור שם ונשלוט בניהול טופולוגיה.

ניהול טופולוגיה

בואו נשלב את המופעים החדשים שלנו לסט העתק storage-2. בואו נוסיף קבוצה חדשה replicaset_storage_2 ותאר את הפרמטרים של ערכת העתק במשתנים שלו באנלוגיה עם replicaset_storage_1. בסעיף hosts הבה נציין אילו מקרים ייכללו בקבוצה זו (כלומר, ערכת העתק שלנו):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # GROUP INSTANCES BY REPLICA SETS
    ...
    replicaset_storage_2:  # <==
      vars:  # replicaset configuration
        replicaset_alias: storage-2
        weight: 2
        failover_priority:
          - storage-2
          - storage-2-replica
        roles:
          - 'storage'

      hosts:   # replicaset instances
        storage-2:
        storage-2-replica:

בואו נתחיל שוב את ספר המשחקים:

$ ansible-playbook -i hosts.yml 
                   --limit replicaset_storage_2 
                   --tags cartridge-replicasets 
                   playbook.yml

בפרמטר --limit הפעם עברנו את שם הקבוצה התואמת את ערכת העתק שלנו.

בואו נשקול את האפשרות tags.

התפקיד שלנו מבצע ברצף משימות שונות, המסומנות בתגים הבאים:

• cartridge-instances: ניהול מופעים (תצורה, חיבור לחברות);
• cartridge-replicasets: ניהול טופולוגיה (ניהול ערכות משוכפלות והסרה לצמיתות (גירוש) של מופעים מהאשכול);
• cartridge-config: ניהול של פרמטרים אחרים של אשכול (vshard bootstrapping, מצב כשל אוטומטי, פרמטרי הרשאה ותצורת אפליקציה).

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

בואו נעריך את התוצאה של המאמצים שלנו. אנחנו מוצאים ערכת העתק חדש על http://localhost:8181/admin/cluster/dashboard.

הידד!

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

אל תשכח לרוץ vagrant haltלעצור את המכונות הוירטואליות כשתסיים לעבוד איתן.

מה מתחת למכסה המנוע?

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

בואו נסתכל על פריסת אפליקציית Cartridge שלב אחר שלב.

התקנת החבילה והתחלת מופעים

ראשית עליך להעביר את החבילה לשרת ולהתקין אותה. נכון לעכשיו התפקיד יכול לעבוד עם חבילות RPM ו-DEB.

לאחר מכן נשיק את המופעים. הכל מאוד פשוט כאן: כל מופע הוא נפרד systemd-שֵׁרוּת. אני אתן לך דוגמה:

$ systemctl start myapp@storage-1

פקודה זו תפעיל את המופע storage-1 אפליקציות myapp. המופע שהושק יחפש את זה תְצוּרָה в /etc/tarantool/conf.d/. ניתן לצפות ביומני מופע באמצעות journald.

קובץ יחידה /etc/systemd/system/[email protected] שירות systemd יסופק יחד עם החבילה.

ל-Ansible יש מודולים מובנים להתקנת חבילות וניהול שירותי מערכת; לא המצאנו כאן שום דבר חדש.

הגדרת טופולוגיית אשכול

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

אתה יכול להגדיר את האשכול באופן ידני:

• אפשרות ראשונה: פתח את ממשק המשתמש באינטרנט ולחץ על הכפתורים. זה די מתאים להתחלה חד פעמית של מספר מקרים.
• אפשרות שנייה: אתה יכול להשתמש ב-API של GraphQl. כאן אתה כבר יכול להפוך משהו לאוטומטי, למשל, לכתוב סקריפט ב-Python.
• אפשרות שלישית (לבעלי רצון חזק): עבור לשרת, התחבר לאחד המופעים באמצעות tarantoolctl connect ולבצע את כל המניפולציות הדרושות עם מודול Lua cartridge.

המשימה העיקרית של ההמצאה שלנו היא לעשות בדיוק את זה, החלק הקשה ביותר בעבודה עבורך.

Ansible מאפשר לך לכתוב מודול משלך ולהשתמש בו בתפקיד. התפקיד שלנו משתמש במודולים כאלה לניהול רכיבי אשכולות שונים.

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

תוצאות של

היום סיפרנו והראנו כיצד לפרוס את האפליקציה שלך ל-Tarantool Cartridge ולהגדיר טופולוגיה פשוטה. לשם כך, השתמשנו ב-Ansible - כלי רב עוצמה וקל לשימוש ומאפשר להגדיר בו-זמנית צמתים רבים של תשתית (במקרה שלנו, מופעי אשכולות).

לעיל הסתכלנו על אחת מהדרכים הרבות לתאר תצורת אשכול באמצעות Ansible. ברגע שאתה מרגיש מוכן להמשיך הלאה, חקור שיטות עבודה מומלצות על כתיבת ספרי משחק. ייתכן שיהיה לך קל יותר לנהל את הטופולוגיה שלך באמצעות group_vars и host_vars.

בקרוב מאוד נספר לכם כיצד למחוק (להוציא) מופעים לצמיתות מהטופולוגיה, bootstrap vshard, לנהל מצב כשל אוטומטי, להגדיר הרשאות ולתקן את תצורת האשכול. בינתיים אפשר ללמוד לבד תיעוד ולהתנסות בשינוי פרמטרי אשכול.

אם משהו לא עובד, הקפד לעשות זאת לדווח אותנו לגבי הבעיה. נסדר הכל מהר!

מקור: www.habr.com