เราได้พูดคุยกันแล้ว
น่าสนใจ? จากนั้นฉันถามภายใต้การตัดเราจะบอกและแสดงทุกอย่าง
เริ่มจากตัวอย่างกันก่อน
เราจะครอบคลุมฟังก์ชันการทำงานเพียงบางส่วนในบทบาทของเรา คุณสามารถค้นหาคำอธิบายที่สมบูรณ์ของคุณสมบัติและพารามิเตอร์อินพุตทั้งหมดได้ใน
ตลับทารันทูลมี api
и storage
ที่สามารถกำหนดให้กับอินสแตนซ์
คาร์ทริดจ์ไม่ได้พูดอะไรเกี่ยวกับวิธีเริ่มกระบวนการ แต่ให้ความสามารถในการกำหนดค่าอินสแตนซ์ที่กำลังทำงานอยู่เท่านั้น ผู้ใช้ต้องทำส่วนที่เหลือเอง: แยกไฟล์คอนฟิกูเรชัน เริ่มบริการ และตั้งค่าโทโพโลยี แต่เราจะไม่ทำทั้งหมดนี้ Ansible จะทำเพื่อเรา
จากคำพูดสู่การกระทำ
ดังนั้น เรามาปรับใช้แอปพลิเคชันของเรากับเครื่องเสมือนสองเครื่องและตั้งค่าโทโพโลยีอย่างง่าย:
- ชุดจำลอง
app-1
จะมารับบทเป็นapi
ซึ่งรวมถึงบทบาทvshard-router
. จะมีเพียงตัวอย่างเดียวที่นี่ - ชุดจำลอง
storage-1
ดำเนินการตามบทบาทstorage
(และในขณะเดียวกันvshard-storage
) ที่นี่เราเพิ่มสองอินสแตนซ์จากเครื่องต่างๆ
ในการเรียกใช้ตัวอย่าง เราต้องการ
บทบาทของตัวเองคือ
โคลนที่เก็บด้วยตัวอย่าง:
$ 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 ไปที่
คุณสามารถเทข้อมูล เย็นใช่มั้ย?
ทีนี้มาดูวิธีการทำงานกับสิ่งนี้ และในขณะเดียวกันก็เพิ่มชุดแบบจำลองอีกชุดเข้ากับโทโพโลยี
เราเริ่มเข้าใจ
แล้วเกิดอะไรขึ้น?
เรามี 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 ของเว็บ
เราจะไม่พักผ่อนบนเกียรติยศของเราและจะควบคุมโทโพโลยีอย่างเชี่ยวชาญ
การจัดการโทโพโลยี
มารวมอินสแตนซ์ใหม่ของเราเข้ากับชุดจำลอง 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
.
มาประเมินผลความพยายามของเรากัน ค้นหาชุดจำลองใหม่
ไชโย!
ทดลองการกำหนดค่าอินสแตนซ์และชุดจำลองใหม่ และดูว่าโทโพโลยีของคลัสเตอร์เปลี่ยนแปลงอย่างไร คุณสามารถลองใช้สถานการณ์การปฏิบัติงานต่างๆ ได้ เช่น 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
และดำเนินการปรับแต่งที่จำเป็นทั้งหมดด้วยโมดูล Luacartridge
.
งานหลักของสิ่งประดิษฐ์ของเราคือทำสิ่งนี้ ซึ่งเป็นส่วนที่ยากที่สุดของงานสำหรับคุณ
Ansible อนุญาตให้คุณเขียนโมดูลของคุณเองและใช้ในบทบาท บทบาทของเราใช้โมดูลเหล่านี้เพื่อจัดการส่วนประกอบต่างๆ ของคลัสเตอร์
มันทำงานอย่างไร? คุณอธิบายสถานะที่ต้องการของคลัสเตอร์ในการกำหนดค่าแบบประกาศ และบทบาทจะให้ส่วนการกำหนดค่าแต่ละโมดูลเป็นอินพุต โมดูลได้รับสถานะปัจจุบันของคลัสเตอร์และเปรียบเทียบกับอินพุต ถัดไป โค้ดจะถูกรันผ่านซ็อกเก็ตของหนึ่งในอินสแตนซ์ ซึ่งทำให้คลัสเตอร์อยู่ในสถานะที่ต้องการ
ผลของการ
วันนี้เราได้บอกและแสดงวิธีปรับใช้แอปพลิเคชันของคุณบน Tarantool Cartridge และตั้งค่าโทโพโลยีอย่างง่าย ในการทำเช่นนี้ เราใช้ Ansible ซึ่งเป็นเครื่องมืออันทรงพลังที่ใช้งานง่าย และช่วยให้คุณสามารถกำหนดค่าโหนดโครงสร้างพื้นฐานจำนวนมากได้พร้อมกัน (ในกรณีของเรา นี่คืออินสแตนซ์ของคลัสเตอร์)
ข้างต้น เราจัดการกับหนึ่งในหลายวิธีในการอธิบายการกำหนดค่าคลัสเตอร์โดยใช้ Ansible เมื่อคุณรู้ว่าคุณพร้อมที่จะก้าวต่อไป จงเรียนรู้ group_vars
и host_vars
.
เร็วๆ นี้ เราจะบอกวิธีลบ (ขับไล่) อินสแตนซ์อย่างถาวรออกจากโทโพโลยี, บูตสแตรป vshard, จัดการโหมดเฟลโอเวอร์อัตโนมัติ, กำหนดค่าการให้สิทธิ์ และแพตช์การกำหนดค่าคลัสเตอร์ ในระหว่างนี้คุณสามารถศึกษาได้ด้วยตนเอง
ถ้าบางอย่างไม่ได้ผล ให้แน่ใจ
ที่มา: will.com