Artikel ini adalah transkrip laporan video dari Alexei Vakhov dari Uchi.ru “Awan di awan”
Uchi.ru adalah platform online untuk pendidikan sekolah, lebih dari 2 juta siswa, kelas interaktif memutuskan bersama kami. Semua proyek kami di-host sepenuhnya di cloud publik, 100% aplikasi bekerja dalam wadah, mulai dari yang terkecil, untuk penggunaan internal, dan berakhir dengan produksi besar dengan permintaan 1 k + per detik. Kebetulan kami memiliki 15 kluster buruh pelabuhan terisolasi (bukan Kubernetes, sic!) Di lima penyedia cloud. Lima belas ratus aplikasi pengguna, yang jumlahnya terus bertambah.
Saya akan berbicara tentang hal-hal yang sangat spesifik: bagaimana kita beralih ke wadah, bagaimana kita mengelola infrastruktur, masalah yang kita temui, apa yang berhasil dan apa yang tidak.
Selama laporan, kami akan membahas:
- Motivasi untuk pemilihan teknologi dan fitur bisnis
- Alat: Ansible, Terraform, Docker, Github Flow, Consul, Nomad, Prometheus, Shaman - antarmuka web untuk Nomad.
- Menggunakan Federasi Cluster untuk Mengelola Infrastruktur Terdistribusi
- Peluncuran NoOps, lingkungan pengujian, sirkuit aplikasi (pengembang membuat perubahan sendiri secara praktis sendiri)
- Menghibur cerita dari latihan
Siapa yang peduli, tolong, di bawah kucing.
Nama saya Alexey Vakhov. Saya bekerja sebagai direktur teknis di Uchi.ru. Kami host di awan publik. Kami secara aktif menggunakan Terraform, Ansible. Sejak itu, kami sepenuhnya beralih ke Docker. Sangat puas. Betapa bahagianya, betapa bahagianya kita - saya akan memberi tahu.
Perusahaan Uchi.ru bergerak dalam produksi produk untuk pendidikan sekolah. Kami memiliki platform utama di mana anak-anak menyelesaikan masalah interaktif di berbagai mata pelajaran di Rusia, Brasil, dan Amerika Serikat. Kami menyelenggarakan olimpiade online, kontes, klub, kamp. Setiap tahun kegiatan ini berkembang.
Dari sudut pandang teknik, tumpukan web klasik (Ruby, Python, NodeJS, Nginx, Redis, ELK, PostgreSQL). Fitur utamanya adalah banyak aplikasi. Aplikasi dihosting di seluruh dunia. Setiap hari ada peluncuran dalam produksi.
Fitur kedua adalah skema kami sangat sering berubah. Mereka meminta untuk membuat aplikasi baru, menghentikan yang lama, menambahkan cron untuk pekerjaan latar belakang. Setiap 2 minggu ada Olimpiade baru - ini adalah aplikasi baru. Semua itu diperlukan untuk menemani, memantau, mencadangkan. Karena itu, lingkungannya superdinamik. Dinamisme adalah kesulitan utama kita.
Unit kerja kami adalah situs. Dalam hal penyedia cloud, ini adalah Project. Situs kami adalah entitas yang sepenuhnya terisolasi dengan API dan subnet pribadi. Ketika kami memasuki negara itu, kami mencari penyedia cloud lokal. Tidak di mana-mana ada Google dan Amazon. Kadang-kadang terjadi bahwa tidak ada API untuk penyedia cloud. Secara lahiriah kami menerbitkan VPN dan HTTP, HTTPS ke penyeimbang. Semua layanan lain berkomunikasi di dalam cloud.
Untuk setiap situs kami telah membuat repositori Ansible kami sendiri. Repositori memiliki hosts.yml, playbook, peran, dan 3 folder rahasia, yang akan saya bicarakan nanti. Ini adalah terraform, ketentuan, perutean. Kami adalah penggemar standardisasi. Repositori kami harus selalu disebut "nama situs yang mungkin". Kami membakukan setiap nama file, struktur internal. Ini sangat penting untuk otomatisasi lebih lanjut.
Kami menyiapkan Terraform satu setengah tahun yang lalu, jadi kami menggunakannya. Terraform tanpa modul, tanpa struktur file (struktur datar digunakan). Struktur file Terraform: 1 server - 1 file, pengaturan jaringan dan pengaturan lainnya. Menggunakan terraform, kami menggambarkan server, drive, domain, s3-bucket, jaringan, dan sebagainya. Terraform di situs sepenuhnya mempersiapkan setrika.
Terraform membuat server, lalu ensemble menggulung server ini. Karena kami menggunakan versi sistem operasi yang sama di mana-mana, kami menulis semua peran dari awal. Peran yang memungkinkan biasanya diterbitkan di Internet untuk semua sistem operasi yang tidak berfungsi di mana pun. Kami semua mengambil peran Ansible dan hanya meninggalkan apa yang kami butuhkan. Peran Anonim yang Standar. Kami memiliki 6 buku pedoman dasar. Ketika diluncurkan, Ansible menginstal daftar perangkat lunak standar: OpenVPN, PostgreSQL, Nginx, Docker. Kubernet yang tidak kita gunakan.
Kami menggunakan Konsul + Pengembara. Ini adalah program yang sangat sederhana. Jalankan 2 program yang ditulis dalam Golang di setiap server. Konsul bertanggung jawab atas Penemuan Layanan, pemeriksaan kesehatan dan nilai kunci untuk menyimpan konfigurasi. Nomad bertanggung jawab atas penjadwalan, untuk peluncuran. Nomad meluncurkan wadah, menyediakan peluncuran, termasuk pembaruan bergulir pada pemeriksaan kesehatan, memungkinkan Anda untuk menjalankan wadah sespan. Cluster mudah diperluas atau sebaliknya untuk mengurangi. Nomad mendukung cron terdistribusi.
Setelah kami memasuki situs, Ansible mengeksekusi playbook yang terletak di direktori ketentuan. Playbook dalam direktori ini bertanggung jawab untuk menginstal perangkat lunak di cluster buruh pelabuhan yang digunakan administrator. Instal prometheus, grafana, dan perangkat lunak dukun rahasia.
Dukun adalah dasbor web untuk nomad. Nomad adalah level rendah dan saya tidak ingin membiarkan pengembang di dalamnya. Dalam dukun kami melihat daftar aplikasi, kami memberi pengembang tombol penyebaran untuk aplikasi. Pengembang dapat mengubah konfigurasi: tambahkan wadah, variabel lingkungan, mulai layanan.
Dan akhirnya, komponen terakhir dari situs ini adalah perutean. Routing disimpan dalam penyimpanan K / V dari konsul, yaitu, ada tautan antara hulu, layanan, url, dll. Di setiap penyeimbang, ada template Konsul yang menghasilkan konfigurasi nginx dan membuatnya reload. Suatu hal yang sangat dapat diandalkan, kami tidak pernah memiliki masalah dengannya. Fitur skema ini adalah bahwa lalu lintas menerima nginx standar dan Anda selalu dapat melihat konfigurasi mana yang dihasilkan dan berfungsi seperti dengan nginx standar.
Dengan demikian, setiap situs terdiri dari 5 lapisan. Dengan terraform, kami menyesuaikan perangkat keras. Mungkin kita melakukan konfigurasi dasar dari server, menempatkan docker-cluster. Provision menggulung perangkat lunak sistem. Routing mengarahkan lalu lintas di dalam situs. Aplikasi berisi aplikasi pengguna dan aplikasi administrator.
Kami mendebug lapisan ini untuk waktu yang lama sehingga mereka identik mungkin. Penyediaan, pencocokan perutean 100% antar situs. Oleh karena itu, untuk pengembang, setiap situs sama persis.
Jika profesional TI beralih dari proyek ke proyek, mereka jatuh ke lingkungan yang benar-benar khas. Dalam keadaan tidak memungkinkan, kami tidak dapat membuat pengaturan firewall dan VPN sama untuk penyedia cloud lainnya. Dengan jaringan, semua penyedia cloud bekerja secara berbeda. Terraform ada di mana-mana sendiri, karena berisi desain khusus untuk setiap penyedia cloud.
Kami memiliki 14 lokasi produksi. Muncul pertanyaan: bagaimana cara mengelolanya? Kami membuat situs master ke-15, di mana kami hanya mengizinkan admin. Dia bekerja pada skema federasi.
Ide itu diambil dari prometheus. Ada mode di prometheus ketika kami menginstal prometheus di setiap situs. Kami menerbitkan Prometheus melalui otorisasi autentikasi dasar HTTPS. Master Prometheus hanya mengambil metrik yang diperlukan dari prometheus jarak jauh. Hal ini memungkinkan untuk membandingkan metrik aplikasi di cloud yang berbeda, menemukan aplikasi yang paling banyak diunduh atau dibongkar. Notifikasi terpusat (peringatan) melewati master prometheus untuk admin. Pengembang menerima peringatan dari prometheus lokal.
Dukun dikonfigurasi dengan cara yang sama. Melalui situs utama, administrator dapat menggunakan, mengkonfigurasi di situs mana pun melalui satu antarmuka. Kami memecahkan kelas masalah yang cukup besar tanpa meninggalkan situs master ini.
Saya akan memberitahu Anda bagaimana kami beralih ke buruh pelabuhan. Proses ini sangat lambat. Kami menyeberang sekitar 10 bulan. Pada musim panas 2017, kami memiliki 0 kontainer produksi. Pada bulan April 2018, kami melakukan galangan kapal dan meluncurkan aplikasi terbaru kami ke dalam produksi.
Kami berasal dari dunia batu delima di rel. Dulu ada 99% aplikasi Ruby on Rails. Rails bergulir melalui Capistrano. Secara teknis, Capistrano berfungsi sebagai berikut: pengembang meluncurkan cap deploy, capistrano pergi ke semua server aplikasi melalui ssh, mengambil versi terbaru dari kode, mengumpulkan aset, migrasi basis data. Capistrano membuat symlink ke versi kode yang baru dan mengirimkan sinyal USR2 ke aplikasi web. Pada sinyal ini, server web mengambil kode baru.
Langkah terakhir di buruh pelabuhan tidak dilakukan seperti itu. Di buruh pelabuhan, Anda harus menghentikan wadah lama, angkat wadah baru. Ini menimbulkan pertanyaan: bagaimana cara mengalihkan lalu lintas? Di dunia cloud, penemuan layanan bertanggung jawab untuk ini.
Karena itu, kami menambahkan konsul ke setiap situs. Konsul ditambahkan karena mereka menggunakan Terraform. Kami membungkus semua konfigurasi nginx dalam template konsul. Secara formal, hal yang sama, tetapi kami sudah siap secara dinamis mengelola lalu lintas di dalam situs.
Selanjutnya, kami menulis skrip ruby yang mengumpulkan gambar di salah satu server, mendorongnya ke dalam registri, lalu pergi dengan ssh ke setiap server, mengambil yang baru dan menghentikan wadah lama, mendaftarkannya dalam konsul. Para pengembang juga terus menjalankan penyebaran topi, tetapi layanan sudah berjalan di buruh pelabuhan.
Saya ingat ada dua versi naskah, yang kedua ternyata cukup maju, ada pembaruan yang bergulir, ketika sejumlah kecil kontainer berhenti, yang baru bangun, konsul Helfcheki menunggu dan pindah.
Kemudian mereka menyadari bahwa ini adalah metode buntu. Skrip meningkat menjadi 600 baris. Langkah selanjutnya dalam penjadwalan manual kami mengganti Nomad. Menyembunyikan detail pekerjaan dari pengembang. Artinya, mereka masih disebut cap deploy, tetapi di dalamnya sudah ada teknologi yang sama sekali berbeda.
Dan pada akhirnya, kami memindahkan penyebaran ke UI dan mengambil akses ke server, meninggalkan tombol penempatan hijau dan antarmuka kontrol.
Pada prinsipnya, transisi semacam itu ternyata tentu saja panjang, tetapi kami menghindari masalah yang saya temui beberapa kali.
Ada beberapa jenis tumpukan warisan, sistem, atau sesuatu seperti itu. Khachennaya sudah hanya di tutup. Pengembangan versi baru dimulai. Setelah beberapa bulan atau beberapa tahun, tergantung pada ukuran perusahaan, dalam versi baru kurang dari setengah fungsi yang diperlukan diimplementasikan, dan versi lama masih lolos. Dan yang baru itu juga menjadi sangat warisan. Dan sekarang saatnya untuk memulai versi ketiga yang baru dari awal. Secara umum, ini adalah proses tanpa akhir.
Karenanya, kami selalu memindahkan seluruh tumpukan secara keseluruhan. Dalam langkah-langkah kecil, bengkok, dengan kruk, tetapi seluruhnya. Kami tidak dapat memutakhirkan misalnya mesin buruh pelabuhan di satu situs. Perlu untuk memperbarui di mana-mana, jika ada keinginan.
Peluncuran. Semua instruksi buruh pelabuhan mengeluarkan 10 kontainer nginx, atau 10 kontainer redis, ke buruh pelabuhan. Ini adalah contoh yang buruk, karena gambar sudah dirakit, gambarnya ringan. Kami mengemas aplikasi rel kami di buruh pelabuhan. Ukuran gambar buruh pelabuhan adalah 2-3 gigabyte. Mereka akan keluar tidak begitu cepat.
Masalah kedua datang dari web hipster. Sebuah web hipster selalu Github Flow. Pada tahun 2011, ada posting pembuatan zaman yang Github Flow mengarahkan, sehingga seluruh web bergulir. Seperti apa bentuknya? Cabang induk selalu produksi. Saat menambahkan fungsionalitas baru, kami membuat cabang. Saat merger kami melakukan peninjauan kode, menjalankan tes, meningkatkan lingkungan pementasan. Lingkungan pementasan tampak bisnis. Pada waktu X, jika semuanya berhasil, maka kami menggabungkan cabang menjadi master dan mulai berproduksi.
Pada capistrano, ini berfungsi dengan baik, karena diciptakan untuk ini. Docker selalu menjual pipa kepada kami. Merakit wadah. Wadah dapat ditransfer ke pengembang, tester, ditransfer ke produksi. Tetapi pada saat penggabungan master, kodenya sudah berbeda. Semua gambar buruh pelabuhan yang dikumpulkan dari cabang fitur, mereka tidak dikumpulkan dari master.
Bagaimana kami melakukannya? Kami mengumpulkan gambar, menaruhnya di registri buruh pelabuhan lokal. Dan setelah itu kami melakukan sisa operasi: migrasi, penyebaran ke produksi.
Untuk merakit gambar ini dengan cepat, kami menggunakan Docker-in-Docker. Di Internet, semua orang menulis bahwa ini anti-pola, macet. Kami tidak memiliki hal semacam itu. Berapa banyak yang sudah bekerja dengannya tidak pernah punya masalah. Kami meneruskan direktori / var / lib / docker ke server utama menggunakan volume Persistent. Semua gambar perantara ada di server utama. Merakit gambar baru pas dalam beberapa menit.
Untuk setiap aplikasi, kami membuat registri buruh pelabuhan internal lokal dan volume build kami. Karena buruh pelabuhan menyimpan semua lapisan pada disk dan sulit dibersihkan. Sekarang kita tahu pemanfaatan disk masing-masing registry buruh pelabuhan lokal. Kami tahu berapa banyak disk yang dibutuhkan. Anda dapat menerima peringatan melalui Grafana terpusat dan bersih. Sementara kita membersihkan tangan mereka. Tapi kami akan mengotomatiskannya.
Poin lain. Gambar Docker dikumpulkan. Sekarang gambar ini perlu diurai menjadi server. Saat menyalin gambar buruh pelabuhan besar, jaringan tidak mengatasinya. Di cloud kami memiliki 1 Gbit / s. Ada shutdown global di cloud. Sekarang kami sedang menyebarkan gambar buruh pelabuhan ke 4 server produksi berat. Pada grafik Anda dapat melihat disk bekerja pada 1 paket server. Kemudian paket server kedua digunakan. Di bawah ini Anda dapat melihat pemanfaatan saluran. Sekitar 1 Gbit / s kami hampir menarik. Tidak ada banyak akselerasi di sana lagi.
Produksi favorit saya adalah Afrika Selatan. Ada besi yang sangat mahal dan lambat. Empat kali lebih mahal daripada di Rusia. Ada internet yang sangat buruk. Internet tingkat modem, tetapi tidak buggy. Di sana kami meluncurkan aplikasi dalam 40 menit, dengan mempertimbangkan penyetelan cache, parameter batas waktu.
Masalah terakhir yang membuat saya khawatir sebelum buruh pelabuhan menghubungi adalah beban. Padahal, bebannya sama dengan tanpa buruh pelabuhan dengan besi identik. Satu-satunya nuansa yang kami temukan hanya satu poin. Jika Anda mengumpulkan log dari mesin Docker melalui driver fluentd bawaan, maka pada muatan sekitar 1000 rps, buffer fluentd internal mulai dikotori dan permintaan mulai melambat. Kami mengeluarkan logging di wadah sespan. Dalam nomad, ini disebut log-shipper. Wadah kecil tergantung di sebelah wadah aplikasi besar. Satu-satunya tugas adalah mengambilnya dan mengirimkannya ke repositori terpusat.
Apa masalah / solusi / tantangannya. Saya mencoba menganalisis apa tugas itu. Fitur dari masalah kami adalah:
- banyak aplikasi independen
- perubahan infrastruktur yang berkelanjutan
- Aliran Github dan gambar buruh pelabuhan besar
Solusi kami
- Federasi kelompok buruh pelabuhan. Dari sudut pandang penanganan itu sulit. Tapi buruh pelabuhan pandai meluncurkan fungsionalitas bisnis dalam produksi. Kami bekerja dengan data pribadi dan kami memiliki sertifikasi di setiap negara. Di lokasi yang terisolasi, sertifikasi semacam itu mudah dilewati. Selama sertifikasi, semua pertanyaan muncul: di mana Anda hosting, bagaimana Anda memiliki penyedia cloud, di mana Anda menyimpan data pribadi, di mana Anda membuat cadangan, siapa yang memiliki akses ke data. Ketika semuanya terisolasi, akan lebih mudah untuk menggambarkan lingkaran tersangka dan untuk memantau semua ini jauh lebih mudah.
- Orkestrasi. Jelas kubernet itu. Dia ada di mana-mana. Tetapi saya ingin mengatakan bahwa Konsul + Nomad adalah solusi produksi sepenuhnya.
- Perakitan gambar. Anda dapat dengan cepat membuat gambar di Docker-in-Docker.
- Saat menggunakan Docker, menahan beban 1000 rps juga dimungkinkan.
Vektor arah pengembangan
Sekarang salah satu masalah besar adalah ketidaksinkronan versi perangkat lunak di situs. Sebelumnya, kami menyiapkan server dengan tangan. Kemudian kami menjadi insinyur devops. Sekarang konfigurasikan server menggunakan ansible. Sekarang kita memiliki penyatuan total, standardisasi. Kami memperkenalkan pemikiran biasa ke dalam kepala. Kami tidak dapat memperbaiki PostgreSQL dengan tangan kami di server. Jika Anda memerlukan beberapa penyesuaian pada hanya 1 server, maka kami pikir bagaimana menyebarkan pengaturan ini di mana-mana. Jika Anda tidak membuat standar, maka akan ada kebun binatang pengaturan.
Saya senang dan sangat senang bahwa kami dapat keluar dari kotak secara gratis, infrastruktur kerja yang benar-benar bagus.
Anda dapat menambahkan kepada saya di facebook. Jika kita melakukan sesuatu yang baik, saya akan menulis tentang itu.
Pertanyaan:
Apa keuntungan Templat Konsul dari Templat Ansible, misalnya, untuk mengkonfigurasi aturan firewall dan banyak lagi?
Jawab: Sekarang kami memiliki lalu lintas dari penyeimbang eksternal pergi langsung ke kontainer. Tidak ada seorang pun di antara keduanya. Konfigurasi terbentuk di sana yang meneruskan alamat IP dan port cluster. Juga, kami memiliki semua pengaturan keseimbangan di K / V di Konsul. Kami memiliki ide untuk memberikan pengaturan perutean kepada pengembang melalui antarmuka yang aman sehingga mereka tidak merusak apa pun.
Pertanyaan: Mengenai homogenitas semua situs. Apakah benar-benar tidak ada permintaan dari bisnis atau dari pengembang yang Anda butuhkan untuk meluncurkan sesuatu yang tidak standar di situs ini? Misalnya, tarantool dengan cassandra.
Jawaban: Itu terjadi, tetapi sangat jarang. Ini kami membuat artefak terpisah internal. Ada masalah seperti itu, tetapi jarang terjadi.
Pertanyaan: Solusi untuk masalah pengiriman adalah dengan menggunakan registry buruh pelabuhan pribadi di setiap situs dan dari sana sudah cepat untuk mendapatkan gambar buruh pelabuhan.
Jawaban: Bagaimanapun, penyebaran akan berjalan ke jaringan, karena kami sedang menyebarkan gambar buruh pelabuhan ke 15 server di sana secara bersamaan. Kami bersandar pada jaringan. Di dalam jaringan, 1 Gbit / s.
Pertanyaan: Begitu banyak kontainer buruh pelabuhan yang didasarkan pada tumpukan teknologi yang kira-kira sama?
Jawaban: Ruby, Python, NodeJS.
Pertanyaan: Seberapa sering Anda menguji atau memeriksa gambar buruh pelabuhan Anda untuk pembaruan? Bagaimana Anda mengatasi masalah pembaruan, misalnya, ketika glibc, openssl perlu diperbaiki di semua buruh pelabuhan?
Jawaban: Jika Anda menemukan kesalahan seperti itu, kerentanan, maka kami duduk selama seminggu dan memperbaikinya. Jika Anda perlu meluncurkan, maka kami dapat meluncurkan seluruh cloud (semua aplikasi) dari awal hingga federasi. Kita bisa mengklik semua tombol hijau untuk penyebaran aplikasi dan meninggalkan untuk minum teh.
Pertanyaan: Apakah Anda akan melepaskan dukun Anda di opensource?
Jawaban: Di sini Andrei (menunjuk ke orang dari penonton) menjanjikan kita untuk mengeluarkan dukun di musim gugur. Tetapi di sana Anda perlu menambahkan dukungan untuk kubernetes. Opensource harus selalu lebih baik.