Baru-baru ini, kami berbicara tentang cara menggunakan aplikasi yang ditulis dalam Tarantool Cartridge . Tetapi operasi tidak berakhir pada penyebaran, jadi hari ini kami akan memperbarui aplikasi kami dan memahami bagaimana mengelola topologi, sharding dan otorisasi, serta mengubah konfigurasi peran.
Ingin tahu silakan potong!
Di mana kami berhenti
Terakhir kali kami mengonfigurasi topologi berikut:
Contoh repositori berhasil mengubah sedikit, file-file baru muncul di sana, getting-started-app-2.0.0-0.rpm dan hosts.updated.2.yml . Anda tidak harus menarik versi baru, Anda cukup mengunduh paket dari tautan , dan hosts.updated.2.yml hanya diperlukan sehingga Anda dapat mengintip ke sana jika terjadi kesulitan dengan mengubah inventaris saat ini.
Jika Anda telah menyelesaikan semua langkah dari bagian sebelumnya dari tutorial ini, maka sekarang di hosts.yml hosts.yml Anda ada konfigurasi cluster dengan dua replika storage (dalam repositori ini adalah hosts.updated.yml ).
Angkat mesin virtual kami:
$ vagrant up
Instal versi baru dari Tarantool Cartridge Ansible-role (berhasil mengubah, tentu saja, menjadi lebih baik):
$ ansible-galaxy install tarantool.cartridge,1.0.2
Jadi, konfigurasi cluster saat ini:
--- 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 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: # first machine connection options ansible_host: 172.19.0.2 ansible_user: vagrant hosts: # instances to be started on the first machine storage-1: storage-2-replica: 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: storage-2: # 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: 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:
Buka http: // localhost: 8181 / admin / cluster / dashboard dan pastikan cluster Anda dalam keadaan yang benar.
Semuanya sama seperti terakhir kali: kita akan secara bertahap mengubah file ini dan mengamati bagaimana perubahan cluster. Anda selalu dapat melihat versi final di hosts.updated.2.yml
Jadi di sini kita mulai!
Memperbarui aplikasi
Untuk memulai, mari perbarui aplikasi kami. Pastikan Anda memiliki file getting-started-app-2.0.0-0.rpm di direktori saat ini (jika tidak, unduh dari repositori).
Tentukan jalur ke versi baru paket:
--- all: vars: cartridge_app_name: getting-started-app cartridge_package_path: ./getting-started-app-2.0.0-0.rpm # <== cartridge_enable_tarantool_repo: false # <==
Kami menentukan cartridge_enable_tarantool_repo: false sehingga peran tersebut tidak menghubungkan repositori dengan paket Tarantool, yang sudah kami pasang terakhir kali. Ini akan sedikit mempercepat proses penyebaran, tetapi sama sekali tidak perlu.
Luncurkan playbook dengan tag cartridge-instances :
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-instances
Dan kami memeriksa bahwa paket tersebut telah diperbarui:
$ vagrant ssh vm1 [vagrant@svm1 ~]$ sudo yum list installed | grep getting-started-app
Periksa apakah versinya telah menjadi 2.0.0 :
getting-started-app.x86_64 2.0.0-0 installed
Sekarang Anda dapat dengan aman bereksperimen dengan versi aplikasi yang baru.
Hidupkan sharding
Mari aktifkan sharding sehingga kita bisa mengendalikan replika storage nanti. Ini dilakukan dengan sangat sederhana. Tambahkan variabel cartridge_bootstrap_vshard all.vars :
--- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true # <== ... hosts: ... children: ...
Kami meluncurkan:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
Harap dicatat bahwa kami menetapkan tag cartridge-config untuk menjalankan hanya tugas-tugas yang terlibat dalam konfigurasi cluster.
Buka Web UI http: // localhost: 8181 / admin / cluster / dashboard dan lihat bahwa ember kami didistribusikan di seluruh set replika penyimpanan dalam rasio 2:3 (kami menentukan bobot tersebut untuk set replika kami, ingat?):
Aktifkan failover otomatis
Dan sekarang kita akan mengaktifkan mode failover otomatis sehingga kita bisa mencari tahu apa itu dan bagaimana cara kerjanya nanti.
Tambahkan bendera cartridge_failover ke konfigurasi:
--- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true cartridge_failover: true # <== ... hosts: ... children: ...
Kami kembali memulai tugas manajemen cluster:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
Setelah berhasil menyelesaikan playbook, Anda dapat pergi ke UI Web dan memastikan bahwa sakelar Failover di sudut kanan atas diaktifkan. Untuk mematikan mode failover otomatis, cukup ubah nilai cartridge_failover ke false dan jalankan playbook lagi.
Sudah waktunya untuk mencari tahu seperti apa rezim ini dan mengapa kami menyalakannya.
Kami berurusan dengan failover
Anda mungkin memperhatikan variabel failover_priority yang kami tentukan untuk setiap replaset. Mari kita lihat apa itu.
Tarantool Cartridge menyediakan mode failover otomatis. Setiap replika memiliki pemimpin - contoh yang sedang direkam. Jika sesuatu terjadi pada pemimpin, salah satu pernyataan akan mengambil perannya. Yang mana Mari kita lihat lebih dekat pada set replika storage-2 :
--- all: ... children: ... replicaset_storage_2: vars: ... failover_priority: - storage-2 - storage-2-replica
Contoh storage-2 kami tentukan pertama di failover_priority . Di UI Web, ini muncul pertama kali dalam daftar instance replaset dan ditandai dengan mahkota hijau. Ini adalah pemimpin - contoh pertama yang ditentukan dalam failover_priority :
Sekarang mari kita lihat apa yang terjadi jika sesuatu terjadi pada pemimpin replaset. Kami masuk ke mesin virtual dan menghentikan instance storage-2 :
$ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl stop getting-started-app@storage-2
Kembali ke UI Web:
Mahkota di instance storage-2 berubah merah - ini berarti bahwa pemimpin yang ditunjuk tidak sehat. Tetapi storage-2-replica memiliki mahkota hijau - instance ini mengambil alih tanggung jawab kepemimpinan sampai storage-2 kembali ke layanan. Ini adalah kegagalan otomatis dalam tindakan.
Mari kita hidupkan kembali storage-2 :
$ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl start getting-started-app@storage-2
Semuanya kembali ke titik awal:
Mari kita mengubah urutan instance dalam prioritas failover. Kami akan menjadikan instance storage-2-replica sebagai pemimpin, dan menghapus storage-2 dari daftar secara umum:
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2-replica # <== ...
Jalankan cartridge-replicasets untuk instance dari grup replicaset_storage_2 :
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
Kami pergi ke http: // localhost: 8181 / admin / cluster / dashboard dan melihat bahwa pemimpin telah berubah:
Tapi kami menghapus instance storage-2 dari konfigurasi, mengapa masih ada di sini? Faktanya adalah bahwa Cartridge, menerima nilai baru dari failover_priority mengatur instance sebagai berikut: instance pertama dari daftar menjadi leader, sisa instance yang ditunjukkan akan mengikuti. Contoh yang tidak disebutkan dalam failover_priority akan dipesan oleh UUID dan ditambahkan sampai akhir.
Contoh Pengasingan
Tetapi bagaimana jika kita ingin mengecualikan instance dari topologi? Semuanya sangat sederhana: Anda harus melewati bendera yang expelled untuk expelled . Mari kita kecualikan instance storage-2-replica . Dia adalah pemimpin sekarang, jadi Cartridge tidak akan mengizinkan kita untuk melakukan ini. Tapi kami tidak takut kesulitan, dan masih mencoba:
--- all: vars: ... hosts: storage-2-replica: config: advertise_uri: '172.19.0.2:3302' http_port: 8185 expelled: true # <== ...
Kami menentukan cartridge-replicasets , karena mengeluarkan instance adalah perubahan topologi:
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
Jalankan playbook dan lihat kesalahannya:
Seperti yang baru saja kita lihat, Cartridge tidak membenarkan membuang pemimpin replika saat ini dari topologi. Ini cukup logis, karena replikasi asinkron, pengecualian pemimpin cenderung menyebabkan kehilangan data. Kita perlu menentukan pemimpin lain dan hanya setelah itu mengecualikan instance. Peran tersebut pertama-tama akan menerapkan konfigurasi replaset baru dan kemudian menangani pengecualian. Karenanya, kami mengubah failover_priority dan menjalankan playbook lagi:
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2 # <== ...
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
Voila, instance storage-2-replica telah menghilang dari topologi!
Perhatikan bahwa pengasingan instance benar-benar final dan tidak dapat dibatalkan. Setelah menghapus instance dari topologi, peran kita yang mungkin akan menghentikan layanan systemd dan menghapus semua file dari instance ini.
Jika Anda tiba-tiba berubah pikiran dan memutuskan bahwa replika storage-2 masih membutuhkan instance kedua, Anda tidak akan dapat mengembalikannya. Cartridge mengingat UUID dari semua instance yang telah meninggalkan topologi dan tidak akan membiarkan pengasingan kembali. Anda dapat memunculkan instance baru dengan nama dan konfigurasi yang sama, tetapi jelas akan memiliki UUID yang berbeda, sehingga Cartridge akan mengizinkannya untuk bergabung.
Menghapus Replicaset
Kami telah menemukan bahwa kami tidak akan diizinkan untuk mengeluarkan pemimpin dari replika. Tetapi bagaimana jika kita ingin menghapus replika storage-2 secara permanen? Tentu saja ada jalan keluar.
Agar tidak kehilangan data, pertama-tama kita harus mentransfer semua ember ke storage-1 , untuk ini kita mengatur berat replika storage-2 ke 0 :
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration replicaset_alias: storage-2 weight: 0 # <== ... ...
Luncurkan manajemen topologi:
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
Buka Web UI http: // localhost: 8181 / admin / cluster / dashboard dan perhatikan bagaimana semua ember mengalir ke storage-1 :
Kami mengatur pemimpin storage-2 ke bendera yang dikeluarkan dan mengucapkan selamat tinggal pada replika ini:
--- all: vars: ... hosts: ... storage-2: config: advertise_uri: '172.19.0.3:3303' http_port: 8184 expelled: true # <== ...
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-replicasets
Harap perhatikan bahwa saat ini kami tidak menentukan opsi limit , karena setidaknya satu contoh dari semua yang kami luncurkan playbook tidak boleh ditandai sebagai expelled .
Jadi kami kembali ke topologi asli:
Login
Saya mengusulkan untuk mengalihkan perhatian dari mengelola set replika dan memikirkan keamanan. Sekarang setiap pengguna yang tidak sah dapat mengelola cluster melalui UI Web. Setuju, sepertinya begitu-begitu.
Cartridge menyediakan kemampuan untuk menghubungkan modul otorisasi Anda sendiri, seperti LDAP (atau apa pun yang Anda miliki di sana), dan menggunakannya untuk mengelola pengguna dan akses mereka ke aplikasi. Tetapi kami akan menggunakan modul otorisasi bawaan, yang digunakan Cartridge secara default. Modul ini memungkinkan Anda untuk melakukan operasi dasar dengan pengguna (menghapus, menambah, mengedit) dan mengimplementasikan fungsi verifikasi kata sandi.
Harap perhatikan bahwa peran kami yang memungkinkan membutuhkan backend otorisasi untuk mengimplementasikan semua fungsi ini.
Jadi, kami beralih dari teori ke praktik. Pertama, buat otorisasi wajib, atur parameter sesi dan tambahkan pengguna baru:
--- all: vars: ... # authorization cartridge_auth: # <== enabled: true # enable authorization cookie_max_age: 1000 cookie_renew_age: 100 users: # cartridge users to set up - username: dokshina password: cartridge-rullez fullname: Elizaveta Dokshina email: dokshina@example.com # deleted: true # uncomment to delete user ...
Manajemen otorisasi dilakukan sebagai bagian dari tugas cartridge-config , kami menunjukkan tag ini:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
Di http: // localhost: 8181 / admin / cluster / dashboard kejutan menanti kami:
Anda dapat masuk dengan username dan password pengguna baru kami atau masuk sebagai admin - pengguna default. Kata sandinya adalah cookie klaster, kami menetapkan nilai ini dalam variabel cartridge_cluster_cookie (ini adalah app-default-cookie , Anda tidak dapat mengintip).
Setelah berhasil masuk, buka tab Users untuk memastikan semuanya berjalan dengan baik:
Lakukan percobaan dengan menambahkan pengguna baru dan mengubah pengaturan mereka. Untuk menghapus pengguna, tentukan tanda yang deleted: true untuknya. Nilai email dan nama fullname tidak digunakan oleh Cartridge dengan cara apa pun, tetapi Anda dapat menentukannya untuk kenyamanan.
Konfigurasi aplikasi
Mari kita ingat bagaimana semuanya dimulai.
Kami telah menggunakan aplikasi kecil yang menyimpan data tentang pelanggan dan rekening bank mereka. Seperti yang Anda ingat, aplikasi ini memiliki 2 peran: api dan storage . Peran storage menangani penyimpanan data dan mengimplementasikan sharding menggunakan peran vshard-storage . Peran kedua, api , mengimplementasikan server HTTP dengan API untuk manajemen data, ditambah di dalamnya terhubung peran standar lain, vshard-router , yang mengontrol sharding.
Jadi, kami membuat permintaan pertama ke API aplikasi. Tambahkan klien baru:
$ curl -X POST -H "Content-Type: application/json" \ -d '{"customer_id":1, "name":"Elizaveta", "accounts":[{"account_id": 1}]}' \ http://localhost:8182/storage/customers/create
Sebagai tanggapan, kami mendapatkan sesuatu seperti ini:
{"info":"Successfully created"}
Harap perhatikan bahwa di URL kami menentukan instance port app-1 , 8082 , karena mengimplementasikan API ini.
Sekarang mari kita perbarui saldo pengguna baru kami:
$ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000\"}" \ http://localhost:8182/storage/customers/1/update_balance
Dalam respons, kami melihat saldo yang diperbarui:
{"balance":"1000.00"}
Hebat, semuanya bekerja! API diterapkan, Cartridge terlibat dalam data sharding, kami telah menetapkan prioritas failover untuk kasus darurat dan bahkan otorisasi yang diaktifkan. Saatnya untuk mengkonfigurasi aplikasi.
Konfigurasi cluster saat ini disimpan dalam file konfigurasi terdistribusi. Setiap instance menyimpan salinan file ini, dan Cartridge memastikan sinkronisasi di antara semua node cluster. Kita dapat menentukan konfigurasi peran aplikasi kita dalam file ini, dan Cartridge akan mengurus distribusi konfigurasi baru di semua contoh.
Mari kita lihat isi file ini saat ini. Buka tab Cofiguration files dan klik tombol Download :
Di config.yml config.yml yang diunduh config.yml kami menemukan tabel kosong. Tidak heran, karena kami belum menentukan parameter apa pun:
--- [] ...
Bahkan, file konfigurasi cluster kami tidak kosong, itu menyimpan topologi saat ini, pengaturan otorisasi, dan pengaturan sharding. Tapi Cartridge tidak akan begitu mudah untuk membagikan informasi ini, itu dimaksudkan untuk penggunaan internal, dan karena itu disimpan di bagian sistem tersembunyi, yang tidak dapat kita edit.
Setiap peran aplikasi dapat menggunakan satu atau beberapa bagian konfigurasi. Konfigurasi baru dimuat dalam dua tahap: pertama, semua peran memverifikasi bahwa mereka siap menerima parameter baru. Jika tidak ada keberatan, maka perubahan diterapkan, jika seseorang menentang, maka kemunduran terjadi.
Mari kita kembali ke aplikasi kita. Peran api menggunakan bagian max-balance , di mana saldo maksimum yang diijinkan disimpan pada satu akun klien. Mari kita mengkonfigurasi bagian ini, tetapi, tentu saja, tidak secara manual, tetapi menggunakan peran Ansible kami.
Jadi, sekarang konfigurasi aplikasi (atau lebih tepatnya, sebagian dari itu tersedia untuk kita) adalah tabel kosong. Tambahkan bagian max-balance dengan nilai 100000 . Kami menulis variabel cartridge_app_config ke file inventaris kami:
--- all: vars: ... # cluster-wide config cartridge_app_config: # <== max-balance: # section name body: 1000000 # section body # deleted: true # uncomment to delete section max-balance ...
Kami menentukan nama bagian, max-balance , dan kontennya, isi. Isi suatu bagian tidak hanya berupa angka, tetapi juga bisa berupa tabel atau baris tergantung pada bagaimana peran itu ditulis dan jenis nilai apa yang ingin Anda gunakan.
Kami meluncurkan:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
Dan kami memeriksa bahwa saldo maksimum yang diijinkan telah benar-benar berubah:
$ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000001\"}" \ http://localhost:8182/storage/customers/1/update_balance
Sebagai tanggapan, kami mendapatkan kesalahan, seperti yang kami inginkan:
{"info":"Error","error":"Maximum is 1000000"}
Anda dapat mengunduh ulang file konfigurasi pada tab Configuraion files untuk memastikan bahwa bagian baru muncul di sana:
--- max-balance: 1000000 ...
Coba tambahkan bagian baru ke konfigurasi aplikasi, ubah isinya atau hapus seluruhnya (untuk ini Anda perlu mengatur flag yang deleted: true di bagian).
Anda dapat mengetahui cara menggunakan konfigurasi terdistribusi dalam peran dalam dokumentasi Tarantool Cartridge.
Ingatlah untuk memanggil vagrant halt untuk menghentikan vagrant halt ketika Anda selesai bekerja dengan mereka.
Kesimpulannya
Terakhir kali, kami mempelajari cara menggunakan aplikasi Tarantool Cartridge terdistribusi menggunakan peran Ansible khusus. Hari ini kami memperbarui aplikasi, dan juga menguasai manajemen topologi, sharding, otorisasi, dan konfigurasi aplikasi.
Jangan berhenti di situ, pelajari berbagai pendekatan untuk menulis buku pedoman yang dimungkinkan dan gunakan aplikasi Anda dengan kenyamanan maksimal.
Jika sesuatu tidak berhasil untuk Anda atau jika Anda memiliki ide tentang cara meningkatkan peran yang memungkinkan kami, silakan mulai tiket . Kami akan selalu membantu dengan solusi masalah Anda dan kami akan dengan senang hati menawarkan penawaran menarik!