การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

เราได้พูดคุยกันแล้ว ทารันทูลคาร์ทริดจ์ซึ่งช่วยให้คุณพัฒนาแอปพลิเคชันแบบกระจายและจัดแพ็คเกจได้ ไม่มีอะไรเหลือ: เรียนรู้วิธีปรับใช้และจัดการแอปพลิเคชันเหล่านี้ ไม่ต้องกังวล เราได้คิดทุกอย่างแล้ว! เราได้รวบรวมแนวปฏิบัติที่ดีที่สุดทั้งหมดสำหรับการทำงานกับ Tarantool Cartridge และเขียน บทบาทที่เข้าใจได้ซึ่งจะแยกแพ็คเกจออกเป็นเซิร์ฟเวอร์ เริ่มต้นอินสแตนซ์ รวมเข้าด้วยกันเป็นคลัสเตอร์ กำหนดค่าการให้สิทธิ์ บู๊ตสแตรป vshard เปิดใช้งานเฟลโอเวอร์อัตโนมัติ และแพตช์การกำหนดค่าคลัสเตอร์

น่าสนใจ? จากนั้นฉันถามภายใต้การตัดเราจะบอกและแสดงทุกอย่าง

เริ่มจากตัวอย่างกันก่อน

เราจะครอบคลุมฟังก์ชันการทำงานเพียงบางส่วนในบทบาทของเรา คุณสามารถค้นหาคำอธิบายที่สมบูรณ์ของคุณสมบัติและพารามิเตอร์อินพุตทั้งหมดได้ใน เอกสาร. แต่ลองดูครั้งเดียวดีกว่าร้อยครั้ง ดังนั้นเรามาปรับใช้แอปพลิเคชันขนาดเล็กกันเถอะ

ตลับทารันทูลมี กวดวิชา เพื่อสร้างแอปพลิเคชัน Cartridge ขนาดเล็กที่เก็บข้อมูลเกี่ยวกับลูกค้าธนาคารและบัญชีของพวกเขา และยังมี API สำหรับจัดการข้อมูลผ่าน HTTP ในการทำเช่นนี้ แอปพลิเคชันจะอธิบายถึงสองบทบาทที่เป็นไปได้: api и storageที่สามารถกำหนดให้กับอินสแตนซ์

คาร์ทริดจ์ไม่ได้พูดอะไรเกี่ยวกับวิธีเริ่มกระบวนการ แต่ให้ความสามารถในการกำหนดค่าอินสแตนซ์ที่กำลังทำงานอยู่เท่านั้น ผู้ใช้ต้องทำส่วนที่เหลือเอง: แยกไฟล์คอนฟิกูเรชัน เริ่มบริการ และตั้งค่าโทโพโลยี แต่เราจะไม่ทำทั้งหมดนี้ Ansible จะทำเพื่อเรา

จากคำพูดสู่การกระทำ

ดังนั้น เรามาปรับใช้แอปพลิเคชันของเรากับเครื่องเสมือนสองเครื่องและตั้งค่าโทโพโลยีอย่างง่าย:

  • ชุดจำลอง app-1 จะมารับบทเป็น apiซึ่งรวมถึงบทบาท vshard-router. จะมีเพียงตัวอย่างเดียวที่นี่
  • ชุดจำลอง storage-1 ดำเนินการตามบทบาท storage (และในขณะเดียวกัน vshard-storage) ที่นี่เราเพิ่มสองอินสแตนซ์จากเครื่องต่างๆ

การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

ในการเรียกใช้ตัวอย่าง เราต้องการ คนจรจัด и เบิ้ล (เวอร์ชัน 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

ติดตั้งบทบาท ansible คาร์ทริดจ์ Tarantool:

$ ansible-galaxy install tarantool.cartridge,1.0.1

เรียกใช้บทบาทที่ติดตั้ง:

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

เรากำลังรอการสิ้นสุดของ playbook ไปที่ http://localhost:8181/admin/cluster/dashboard และเพลิดเพลินไปกับผลลัพธ์:

การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

คุณสามารถเทข้อมูล เย็นใช่มั้ย?

ทีนี้มาดูวิธีการทำงานกับสิ่งนี้ และในขณะเดียวกันก็เพิ่มชุดแบบจำลองอีกชุดเข้ากับโทโพโลยี

เราเริ่มเข้าใจ

แล้วเกิดอะไรขึ้น?

เรามี VM สองตัวและเรียกใช้ playbook ที่ไม่ซับซ้อนซึ่งตั้งค่าคลัสเตอร์ของเรา มาดูเนื้อหาของไฟล์กัน 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

ไม่มีอะไรน่าสนใจเกิดขึ้นที่นี่ เราเริ่มต้น ansible-role ซึ่งเรียกว่า 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 จะจัดการ สำหรับแต่ละโฮสต์ เราสามารถระบุพารามิเตอร์การเชื่อมต่อได้ (เช่น 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.

เราจำเป็นต้องบอก Ansible ถึงพารามิเตอร์การเชื่อมต่อสำหรับแต่ละอินสแตนซ์ ดูเหมือนว่ามีเหตุผลที่จะจัดกลุ่มอินสแตนซ์ออกเป็นกลุ่มเครื่องเสมือน ในการทำเช่นนี้ อินสแตนซ์จะรวมกันเป็นกลุ่ม 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:  # <==
  ...

เรียกใช้ playbook ที่ใช้งานได้:

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

ให้ความสนใจกับตัวเลือก --limit. เนื่องจากแต่ละอินสแตนซ์ของคลัสเตอร์เป็นโฮสต์ในเงื่อนไข Ansible เราจึงสามารถระบุได้อย่างชัดเจนว่าควรกำหนดค่าอินสแตนซ์ใดเมื่อเรียกใช้ playbook

กลับไปที่ UI ของเว็บ http://localhost:8181/admin/cluster/dashboard และสังเกตตัวอย่างใหม่ของเรา:

การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

เราจะไม่พักผ่อนบนเกียรติยศของเราและจะควบคุมโทโพโลยีอย่างเชี่ยวชาญ

การจัดการโทโพโลยี

มารวมอินสแตนซ์ใหม่ของเราเข้ากับชุดจำลอง 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:

มาเริ่ม playbook กันอีกครั้ง:

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

การปรับใช้แอปพลิเคชันอย่างง่ายดายและเป็นธรรมชาติบนตลับ Tarantool (ตอนที่ 1)

ไชโย!

ทดลองการกำหนดค่าอินสแตนซ์และชุดจำลองใหม่ และดูว่าโทโพโลยีของคลัสเตอร์เปลี่ยนแปลงอย่างไร คุณสามารถลองใช้สถานการณ์การปฏิบัติงานต่างๆ ได้ เช่น อัพเดทเรื่อยๆ หรือเพิ่มขึ้น memtx_memory. บทบาทนี้จะพยายามดำเนินการนี้โดยไม่รีสตาร์ทอินสแตนซ์เพื่อลดเวลาหยุดทำงานที่เป็นไปได้ของแอปพลิเคชันของคุณ

อย่าลืมไปวิ่ง vagrant haltเพื่อหยุด VM เมื่อคุณใช้งานเสร็จแล้ว

และสิ่งที่อยู่ภายใต้ประทุน?

ที่นี่ฉันจะพูดเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้นภายใต้ประทุนของบทบาท ansible ระหว่างการทดลองของเรา

มาดูการปรับใช้แอปพลิเคชัน Cartridge ทีละขั้นตอนกัน

การติดตั้งแพ็คเกจและอินสแตนซ์เริ่มต้น

ก่อนอื่นคุณต้องส่งแพ็คเกจไปยังเซิร์ฟเวอร์และติดตั้ง ตอนนี้บทบาทสามารถทำงานกับแพ็คเกจ RPM และ DEB

ต่อไป เราเปิดตัวอินสแตนซ์ ทุกอย่างง่ายมากที่นี่: แต่ละอินสแตนซ์แยกจากกัน systemd-บริการ. ฉันกำลังพูดถึงตัวอย่าง:

$ systemctl start myapp@storage-1

คำสั่งนี้จะเปิดอินสแตนซ์ storage-1 ปพลิเคชัน myapp. อินสแตนซ์ที่เปิดตัวจะมองหามัน การกำหนดค่า в /etc/tarantool/conf.d/. สามารถดูบันทึกอินสแตนซ์ได้โดยใช้ journald.

ไฟล์หน่วย /etc/systemd/system/[email protected] สำหรับบริการ systemd จะถูกส่งไปพร้อมกับแพ็คเกจ

Ansible มีโมดูลในตัวสำหรับติดตั้งแพ็คเกจและจัดการบริการ systemd เราไม่ได้คิดค้นอะไรใหม่ที่นี่

การกำหนดค่าโทโพโลยีของคลัสเตอร์

และนี่คือจุดเริ่มต้นที่น่าสนใจที่สุด เห็นด้วย มันคงเป็นเรื่องแปลกที่จะกังวลกับบทบาท ansible-role พิเศษสำหรับการติดตั้งและรันแพ็คเกจ systemd- บริการ

คุณสามารถตั้งค่าคลัสเตอร์ด้วยตนเอง:

  • ตัวเลือกแรก: เปิด Web UI และคลิกที่ปุ่ม สำหรับการเริ่มหลายครั้งเพียงครั้งเดียว มันค่อนข้างเหมาะสม
  • ตัวเลือกที่สอง: คุณสามารถใช้ GraphQl API ที่นี่คุณสามารถทำให้บางอย่างเป็นอัตโนมัติได้ เช่น เขียนสคริปต์ใน Python
  • ตัวเลือกที่สาม (สำหรับจิตวิญญาณที่แข็งแกร่ง): ไปที่เซิร์ฟเวอร์ เชื่อมต่อกับหนึ่งในอินสแตนซ์โดยใช้ tarantoolctl connect และดำเนินการปรับแต่งที่จำเป็นทั้งหมดด้วยโมดูล Lua cartridge.

งานหลักของสิ่งประดิษฐ์ของเราคือทำสิ่งนี้ ซึ่งเป็นส่วนที่ยากที่สุดของงานสำหรับคุณ

Ansible อนุญาตให้คุณเขียนโมดูลของคุณเองและใช้ในบทบาท บทบาทของเราใช้โมดูลเหล่านี้เพื่อจัดการส่วนประกอบต่างๆ ของคลัสเตอร์

มันทำงานอย่างไร? คุณอธิบายสถานะที่ต้องการของคลัสเตอร์ในการกำหนดค่าแบบประกาศ และบทบาทจะให้ส่วนการกำหนดค่าแต่ละโมดูลเป็นอินพุต โมดูลได้รับสถานะปัจจุบันของคลัสเตอร์และเปรียบเทียบกับอินพุต ถัดไป โค้ดจะถูกรันผ่านซ็อกเก็ตของหนึ่งในอินสแตนซ์ ซึ่งทำให้คลัสเตอร์อยู่ในสถานะที่ต้องการ

ผลของการ

วันนี้เราได้บอกและแสดงวิธีปรับใช้แอปพลิเคชันของคุณบน Tarantool Cartridge และตั้งค่าโทโพโลยีอย่างง่าย ในการทำเช่นนี้ เราใช้ Ansible ซึ่งเป็นเครื่องมืออันทรงพลังที่ใช้งานง่าย และช่วยให้คุณสามารถกำหนดค่าโหนดโครงสร้างพื้นฐานจำนวนมากได้พร้อมกัน (ในกรณีของเรา นี่คืออินสแตนซ์ของคลัสเตอร์)

ข้างต้น เราจัดการกับหนึ่งในหลายวิธีในการอธิบายการกำหนดค่าคลัสเตอร์โดยใช้ Ansible เมื่อคุณรู้ว่าคุณพร้อมที่จะก้าวต่อไป จงเรียนรู้ ปฏิบัติที่ดีที่สุด สำหรับเขียนหนังสือเล่น คุณอาจพบว่าสะดวกกว่าในการจัดการโทโพโลยีด้วย group_vars и host_vars.

เร็วๆ นี้ เราจะบอกวิธีลบ (ขับไล่) อินสแตนซ์อย่างถาวรออกจากโทโพโลยี, บูตสแตรป vshard, จัดการโหมดเฟลโอเวอร์อัตโนมัติ, กำหนดค่าการให้สิทธิ์ และแพตช์การกำหนดค่าคลัสเตอร์ ในระหว่างนี้คุณสามารถศึกษาได้ด้วยตนเอง เอกสาร และทดลองเปลี่ยนพารามิเตอร์ของคลัสเตอร์

ถ้าบางอย่างไม่ได้ผล ให้แน่ใจ แจ้ง เราเกี่ยวกับปัญหา เราจะทำลายมันลงอย่างรวดเร็ว!

ที่มา: will.com

เพิ่มความคิดเห็น