🥇Orkestra Persembahan

Tidak salah untuk mengatakan bahawa orang yang terbaik
mencari kegembiraan melalui penderitaan.
Ludwig van Beethoven

Saya Sergey, bekerja di Yandex.Money dalam pasukan penyelidikan prestasi. Saya ingin berkongsi permulaan kisah perjalanan kami menggunakan orkestrasi—cara kami memilih alatan dan perkara yang kami pertimbangkan. Segala-galanya dalam artikel ini berlaku dalam masa nyata, jadi anda, pembaca yang dihormati, boleh mengikuti perkembangan secara praktikal secara langsung.

Mengapa kita memerlukan konduktor dalam pasukan kita?

Jadi, siapa konduktor? Daripada diriger Perancis—untuk mengurus, mengarah atau mengarah—dalam dunia muzik, orang yang mengarahkan pembelajaran dan persembahan muzik ensemble. Dalam kes kami, peranan ini diduduki oleh sistem orkestrasi dan automasi.

Peranan mereka tidak berbeza dengan konduktor dalam muzik - mereka berada di sana untuk membantu pasukan, mengarah dan mengatur persembahannya.

Biasanya, pasukan mempunyai set keupayaan tertentu—mari kita panggil mereka pelayan—yang mana mereka melaksanakan projek mereka.

Pendekatan untuk memperoleh dan mengendalikan pelayan ini berbeza-beza. Berikut adalah beberapa contoh:

Pasukan membuat permintaan, contohnya kepada kumpulan operasi, untuk memberikan mereka sumber dengan parameter tertentu.
Pasukan operasi menyediakan jumlah yang diperlukan—awan atau logam kosong—dan komited untuk mengekalkannya dalam keadaan baik mengikut SLA. Konfigurasi juga dikendalikan oleh pasukan operasi.
Pasukan ini hanya menerima sumber awan atau logam kosong daripada pasukan operasi dan melakukan konfigurasi sendiri.
Pasukan itu sendiri "membeli" sumber dan menyelenggara/mengkonfigurasikannya sepenuhnya secara bebas.

Pasukan kami menggunakan pelayan yang memerlukan penyelenggaraan—kemas kini sistem pengendalian, memasang pakej baharu, dsb.

Bagi diri kita sendiri, kami telah mengenal pasti mereka kepada dua jenis utama:

kumpulan tangki,
kumpulan perkhidmatan.

Kumpulan kereta kebal terdiri daripada hos dengan Yandex.Tank.

Kumpulan perkhidmatan termasuk semua yang berkaitan dengan penyelenggaraan—pelbagai perkhidmatan untuk menyediakan sokongan untuk kitaran keluaran, menjana laporan automatik, dsb.

Pada satu ketika, menjadi menyusahkan untuk mengurus semua ini secara manual, jadi kami mula memikirkan tentang mengautomasikan keseluruhan proses, daripada persediaan pelayan kepada pembangunan, penggunaan dan pelancaran perkhidmatan dalaman kami.

Mengapakah konduktor diperlukan, walaupun orkestra itu sendiri boleh bermain?

Sebagai permulaan, kami menguasai Ansible dan mula membina pelayan logam kosong kami agar kurang bergantung kepada pentadbir sistem. Ini adalah situasi menang-menang: kami memperoleh kemahiran baharu dan membebaskan pentadbir daripada beberapa kerja yang mereka sudah ada. Kami berusaha untuk membangun melebihi kepakaran kami dan memastikan autonomi pasukan sebanyak mungkin.

Syarikat itu telah bekerja dengan Ansible untuk beberapa lama sekarang, jadi kami dengan mudah menyepadukan penyelesaian kami ke dalam proses ini.

Pada masa ini, peruntukan hos terdiri daripada tiga peranan Ansible:

peranan pertama memasang OS,
yang kedua menjalankan tetapan asas untuk hos, kebenaran LDAP, sebagai contoh,
dan yang ketiga memasang Yandex.Tank dan kebergantungan yang berkaitan dalam bekas Docker.

Mari beralih kepada perkhidmatan yang kami gunakan dalam pasukan.

Untuk tugasan kami, kami menggunakan Kotlin dan Python secara sama rata, dengan sedikit Golang. Untuk menyeragamkan pembangunan dan penggunaan perkhidmatan kami, kami memutuskan untuk membungkusnya dalam bekas Docker. Ini memberi kami kebebasan untuk memilih bahasa pengaturcaraan kami sambil memastikan format penghantaran seragam untuk aplikasi kami.

Nota ringkas tentang IPv6 dalam Docker

Sesetengah perkhidmatan yang kami berinteraksi hanya tersedia melalui IPv6, jadi kami perlu memikirkan cara untuk mendayakan IPv6 untuk bekas.

Menurut dokumentasi IPv6 di tapak web Docker rasmi, IPv6 didayakan dengan menambahkan parameter pada daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

Dalam kes ini, pembekal mesti menyediakan subnet IPv6, yang akan anda masukkan fixed-cidr-v6.
Walau bagaimanapun, kami memilih pilihan yang berbeza - ipv6 NAT, dan inilah sebabnya:

Sekarang buruh pelabuhan tidak boleh menggunakan hanya dengan ipv6.
Mempunyai alamat yang boleh dihalakan secara global pada setiap bekas bermakna semua port (walaupun yang tidak diterbitkan) boleh diakses oleh semua orang melainkan penapisan tambahan dilakukan.
proksi userland untuk pelabuhan penerbitan, iptables untuk IPv4 sahaja.

IPv6 NAT ialah Bekas buruh pelabuhan, yang sendiri menguruskan peraturan dalam ip6tables dan mengeditnya apabila menambah bekas baharu.

Untuk penyelesaian ini berfungsi dengan betul, beberapa langkah lagi diperlukan. Adalah penting untuk memulakan ip6table_nat pada sistem. Memasang modul pada sistem tidak menjamin bahawa ia akan dimuatkan ke dalam kernel semasa permulaan. Kami menghadapi ini apabila kami menerima ralat berikut semasa melancarkan bekas dengan NAT pada hos baharu:

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)

Masalah telah diselesaikan selepas menambah permulaan kepada peranan Ansible menggunakan modul modprobe dan memuatkannya pada permulaan OS menggunakan lineinfile:

- name: Add ip6table_nat module
 modprobe:
   name: ip6table_nat
   state: present
- name: Add ip6table_nat to boot
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

By the way, ada yang bagus di Habr artikel, yang menerangkan secara ringkas dan jelas kelebihan dan kekurangan kaedah ini atau itu untuk bekerja dengan IPv6 dalam Docker.

Tetapi mari kita kembali kepada soalan kami yang ditanya pada mulanya:
Mengapakah konduktor diperlukan, walaupun orkestra itu sendiri boleh bermain?

Sekarang semua orang tahu cara bermain dalam pasukan kami:

proses "mengisi" pelayan telah dibuat,
Pembangunan dan penggunaan perkhidmatan disatukan.

Timbul persoalan yang munasabah: bagaimana kami boleh menggunakan, mengemas kini dan memantau perkhidmatan kami dalam bekas Docker dengan cekap dan seautomatik yang mungkin?

Walaupun setiap ahli orkestra tahu bahagian mereka, mereka boleh menjadi keliru dan menyimpang dari rancangan asal. Di sinilah kami membuat kesimpulan bahawa tanpa konduktor, orkestra kami tidak akan berlatih dengan berkesan dan bermain secara harmoni. Konduktor bertanggungjawab ke atas semua aspek persembahan, memastikan semuanya disatukan oleh tempo dan mood yang seragam.

Bagaimana untuk mendapatkan konduktor yang baik dengan pelaburan minimum?

Topik orkestrasi berkembang dengan baik di pasaran. Tetapi pertama, mari kita bercakap tentang alat tambahan yang boleh membantu konduktor.

Konsul — sistem yang menyediakan dua fungsi utama:

penemuan perkhidmatan,
kedai nilai kunci yang diedarkan.

Dalam orkestra kami, Konsul akan bertanggungjawab untuk mendaftarkan perkhidmatan dan menyimpan konfigurasi mereka. Terdapat dua pilihan pendaftaran:

Aktif ialah apabila perkhidmatan mendaftar sendiri menggunakan API HTTP;
Pasif - perkhidmatan mesti didaftarkan secara manual.

Vault ialah penyelesaian storan yang menyeragamkan dan menyatukan storan dan pengurusan rahsia yang selamat—kata laluan, sijil.
Berikut adalah faedah yang akan kami perolehi dengan menggunakan alat ini:

Pusat tunggal untuk mencipta dan menyimpan rahsia, dan mengurus kitaran hayat mereka melalui API HTTP.
Enjin Rahsia Transit — penyulitan dan penyahsulitan data tanpa menyimpannya. Membolehkan pemindahan data yang disulitkan melalui saluran komunikasi yang tidak selamat.
Akses dasar yang mudah dikonfigurasikan.
Audit akses kepada rahsia.
Keupayaan untuk mencipta CA (Pihak Berkuasa Sijil) anda sendiri untuk mengurus sijil yang ditandatangani sendiri dalam infrastruktur anda.

Memandangkan semua keperluan kami, dua pilihan sesuai untuk peranan konduktor: Kubernetes dan Nomad.

Kubernetes

Berapa banyak artikel dan buku yang telah ditulis mengenainya (di sini sebegitu, sebagai contoh), laporan telah dibentangkan, yang akan saya rumuskan secara ringkas: ia adalah alat universal yang boleh melakukan hampir semua perkara. Harga untuk ini ialah menyediakan dan mengekalkan kluster Kubernetes tidak selalu mudah.

Nomad

Alat daripada HashiCorp, syarikat yang terkenal dengan konsul dan bilik kebal yang disebutkan di atas.

Kami mendapati Nomad lebih mudah untuk dipasang dan dikonfigurasikan daripada Kubernetes. Perduaan tunggal berjalan dalam kedua-dua mod pelayan dan klien. Tambahan pula, Nomad merangkumi semua tugas yang kami mahu ia kendalikan: pengurusan kluster, penjadual pantas dan sokongan multidatacenter. Selain itu, menggunakan konsul dan bilik kebal memberikan kami integrasi yang lebih ketat untuk mengatur perkhidmatan kami.

Apa yang sedang dalam kerja:

menyediakan pelayan untuk penempatan Konsul,
Konsul akan dikemas kini dengan konfigurasi kluster nomad, yang sepatutnya membenarkan nomad digunakan secara automatik,
Secara selari, kami akan memasang peti besi untuk menyimpan rahsia.

Satu soalan untuk penonton: adakah ia berbaloi untuk mengupah konduktor untuk tugasan sedemikian, atau adakah orkestra berjalan lancar tanpa satu? Kongsi pendapat anda dalam komen.

Langgan blog kami dan terus berhubung—kami tidak lama lagi akan memberitahu anda bagaimana keadaan berubah dan sama ada kami menyediakan kluster Nomad seperti yang kami mahukan.

Datanglah ke tempat selesa kami Sembang telegram, di mana anda sentiasa boleh meminta nasihat, membantu rakan sekerja, dan hanya berbual tentang penyelidikan produktiviti dan banyak lagi.

Sumber: www.habr.com