Festival RIT 2018 di Skolkovo besar dan sangat beragam. Pengembangan mobile, backend, frontend, DevOps, manajemen proyek dan bahkan psikologi adalah topik untuk setiap selera dan dalam jadwal yang sibuk dari pagi hingga sore. Tema dibagi menjadi trek yang terpisah, trek diikat ke aula. Jika hanya laporan khusus yang menarik, Anda dapat menetap di ruangan yang tepat. Ruang utama, bagaimanapun, digunakan sesuai kebutuhan oleh pembicara dari berbagai topik.
Pada umumnya, saya tercerahkan dengan pengetahuan DevOps, dan setelah membagikan kesan saya tentang konferensi dengan rekan-rekan saya, saya membuat daftar pendek laporan yang saya ingat. Beberapa bulan berlalu, dan saya masih ingat dengan baik apa yang mereka bicarakan.
Jadi, 3 laporan teknis yang saya ingat di RIT 2018.
Pemantauan dan Kubernet
Alat pemantauan yang digunakan sekarang tidak mendukung aplikasi arsitektur layanan mikro dengan baik. Semakin banyak dinamika dalam sistem, semakin sulit untuk mengkonfigurasi pemantauan untuknya. Pemantauan yang mudah untuk sistem kluster seperti Kubernetes, yang membawa dinamika ke ekstremisme, umumnya merupakan tugas yang tidak sepele. Kenapa begitu Dmitry Stolyarov, direktur teknis Flant, berbicara tentang alasan kompleksitas ini dan dampaknya pada misi pemantauan utama.
Sistem pemantauan tradisional mengandalkan bekerja dengan server statis, yang relatif jarang ditambahkan dan dihapus dari infrastruktur aplikasi. Di Kubernetes, pembuatan dan penghapusan lingkungan perapian dan aplikasi layanan terjadi setiap detik, sehingga prosedur penemuan otomatis yang ada tidak dapat mengatasi volume ini.
Jumlah lingkungan itu sendiri juga mencapai puluhan dan ratusan. Dengan demikian, jumlah telemetri yang ditransmisikan meningkat dengan jumlah yang sama. Dan dia masih perlu disimpan di suatu tempat.
Masalah terpisah adalah tabrakan dari dunia fisik dan virtual: konsumsi sumber daya oleh aplikasi di Kubernetes cukup singkat dan tercermin dalam batasan pembatasan pada perapian. Tetapi konsumsi sumber daya pod sudah memiliki efek fisik spesifik pada kapasitas server yang tersedia. Saat melihat grafik, Anda harus selalu mempertimbangkan dari sudut pandang apa Anda melihat sumber daya. Dalam praktiknya, hanya sedikit orang yang tertarik pada polong individual. Yang menarik adalah konsumsi sumber daya oleh aplikasi secara keseluruhan, dan ini sudah membutuhkan pengelompokan pod telemetri yang fleksibel sesuai dengan beberapa kriteria yang ditentukan oleh pengguna.
Dan Anda perlu meningkatkan skema yang dihasilkan beberapa kali untuk lingkungan dev / staging / prod yang tersebar luas!
Laporan ini direkomendasikan kepada siapa saja yang harus mendukung cluster kubernetes.
Tautan ke presentasi.
Box Development Devops
Sangat menarik bagi kami untuk mendengarkan laporan Maxim Lapshin, di mana ia berbagi pengalaman langka dalam menggunakan praktik devo dalam pengembangan produk kotak. Produk kotak adalah perangkat lunak tradisional yang menginstal dan berjalan pada kemampuan pengguna.
Erlyvideo sedang mengembangkan server streaming video, kami adalah server konfigurasi layanan Internet. Masalah kami dalam banyak hal mirip dengan yang menyebabkan transformasi DevOps ErOlvideo.
Maxim memulai laporan dengan jawaban untuk pertanyaan paling penting: "Untuk apa semua ini?" Semua faktor yang sama yang mendorong pengenalan budaya DevOps dalam pengembangan layanan juga hadir di industri di mana pengembangan yang lebih tradisional sedang berlangsung. Dan pengaruh faktor-faktor ini dalam produk kotak mungkin akan lebih dramatis daripada ketika bekerja pada layanan. Misalnya, semakin sedikit rilis, semakin besar volume perubahan yang akan digunakan. Jika Anda meluncurkan layanan baru, Anda dapat memastikan atau meyakinkan diri sendiri bahwa itu aman. Tetapi jika Anda merilis distribusi produk dengan sejumlah besar perubahan, itu tidak cukup bagi Anda untuk meyakinkan diri sendiri tentang keamanan pembaruan, Anda juga harus meyakinkan pengguna Anda tentang keamanannya. Potongan kecil tapi sering datang untuk menyelamatkan di sini. Dan ini hanyalah salah satu masalah.
Laporan ini membahas lebih dalam hal ini dan banyak alasan lain untuk menggunakan pengiriman kontinu, menggambar paralel dan menekankan perbedaan dari pekerjaan yang umumnya lebih sederhana dalam mode CI / CD dengan layanan.
Bagaimana ini mungkin? Dalam laporan tersebut, Maxim menggambarkan serangkaian praktik yang digunakan di Erlyvideo untuk membuat pengiriman aliran perubahan yang berkelanjutan menjadi nyata. Banyak pendekatan akan berguna seperti ini, sesuatu akan membutuhkan adaptasi dengan realitas pekerjaan kita. Tetapi, bagaimanapun, kisah sukses yang luar biasa ini dapat menginspirasi untuk memikirkan kembali masalah mereka dan menemukan solusi dalam berbagai praktik DevOps.
Laporan ini akan sangat menarik untuk dilihat oleh semua orang yang bekerja pada distribusi produk.
Tautan ke presentasi.
Basis Jaringan Kubernetes
Panduan mulai cepat, kursus kilat, dan tutorial di mana-mana "Cara memulai kubernet" membuatnya relatif mudah untuk melompat ke mobil ini, menggunakan kluster, dan menyebarkan aplikasi. Mengingat popularitas topik ini yang luar biasa, banyak yang melakukannya. Tetapi jangan lupa bahwa, pada dasarnya, Kubernetes adalah sistem yang agak rumit, pemeliharaannya membutuhkan pengetahuan khusus. Di Ingram Micro Cloud, pengetahuan ini diperlukan saat aplikasi berikutnya tiba-tiba menjadi tidak tersedia melalui jaringan. Dari penyelidikan insiden ini, perjalanan Alexander Khayorov yang menakjubkan melalui subsistem jaringan dimulai.
Laporan ini memperkenalkan elemen-elemen yang semakin kompleks dari tumpukan jaringan Kubernetes, menjelaskan bagaimana rute besar dan rumit dibuat dari blok-blok dasar. Ternyata menjadi sangat menarik ketika Alexander berbicara tentang mengapa ini dilakukan, dan bukan sebaliknya, memodelkan opsi implementasi hipotetis lainnya.
Ini benar-benar alfabet Kubernet yang akan ditemui sebagian besar pengguna. Saya sendiri mengajukan pertanyaan "mengapa nodePort?" dan "mengapa saya tidak melihat IP layanan saya di antarmuka?"
Menarik dan informatif.
Tautan ke presentasi.