Kami akan memulai blog kami dengan publikasi berdasarkan pidato terbaru dari direktur teknis kami (Dmitry Stolyarov). Semuanya berlangsung pada tahun 2016 di berbagai acara profesional dan didedikasikan untuk topik DevOps dan Docker. Satu video dari pertemuan Docker Moscow di kantor Badoo, sudah kami miliki On line. Yang baru akan disertai dengan artikel yang menyampaikan intisari laporan. Jadi…
31 Mei di konferensi , diadakan sebagai bagian dari festival “Teknologi Internet Rusia” (RIT++ 2016), bagian “Penerapan dan Penerapan Berkelanjutan” dibuka dengan laporan “Praktik Terbaik Pengiriman Berkelanjutan dengan Docker”. Ini merangkum dan mensistematisasikan praktik terbaik untuk membangun proses Pengiriman Berkelanjutan (CD) menggunakan Docker dan produk Open Source lainnya. Kami bekerja dengan solusi ini dalam produksi, yang memungkinkan kami mengandalkan pengalaman praktis.
Jika Anda memiliki kesempatan untuk menghabiskan satu jam , kami sarankan untuk menontonnya secara lengkap. Jika tidak, di bawah ini adalah ringkasan utama dalam bentuk teks.
Pengiriman Berkelanjutan dengan Docker
Bawah Pengiriman terus menerus kami memahami rangkaian peristiwa yang menyebabkan kode aplikasi dari repositori Git pertama kali masuk ke produksi, dan kemudian berakhir di arsip. Dia terlihat seperti ini: Git → Bangun → Uji → Rilis → Operasikan.
Sebagian besar laporan dikhususkan untuk tahap pembuatan (perakitan aplikasi), dan topik rilis dan pengoperasian disinggung secara singkat. Kami akan membahas masalah dan pola yang memungkinkan Anda menyelesaikannya, dan penerapan spesifik dari pola ini mungkin berbeda.
Mengapa Docker dibutuhkan di sini? Bukan tanpa alasan kami memutuskan untuk membicarakan praktik Pengiriman Berkelanjutan dalam konteks alat Sumber Terbuka ini. Meskipun seluruh laporan dikhususkan untuk penggunaannya, banyak alasan yang terungkap ketika mempertimbangkan pola utama peluncuran kode aplikasi.
Pola peluncuran utama
Jadi, ketika kami meluncurkan aplikasi versi baru, kami pasti dihadapkan pada hal tersebut masalah waktu henti, dihasilkan selama peralihan server produksi. Lalu lintas dari aplikasi versi lama ke versi baru tidak dapat beralih secara instan: pertama-tama kita harus memastikan bahwa versi baru tidak hanya berhasil diunduh, tetapi juga "pemanasan" (yaitu, benar-benar siap melayani permintaan).
Dengan demikian, untuk beberapa waktu kedua versi aplikasi (lama dan baru) akan bekerja secara bersamaan. Yang secara otomatis mengarah ke konflik sumber daya bersama: jaringan, sistem file, IPC, dll. Dengan Docker, masalah ini mudah diselesaikan dengan menjalankan versi aplikasi yang berbeda dalam wadah terpisah, yang menjamin isolasi sumber daya dalam host yang sama (server/mesin virtual). Tentu saja, Anda dapat melakukan beberapa trik tanpa isolasi sama sekali, tetapi jika ada alat yang siap pakai dan nyaman, maka ada alasan sebaliknya - jangan mengabaikannya.
Kontainerisasi memberikan banyak manfaat lain saat diterapkan. Aplikasi apa pun bergantung pada versi tertentu (atau rentang versi) penerjemah, ketersediaan modul/ekstensi, dll., serta versinya. Dan ini berlaku tidak hanya untuk lingkungan yang dapat dieksekusi langsung, tetapi juga untuk seluruh lingkungan, termasuk perangkat lunak sistem dan versinya (sampai distribusi Linux yang digunakan). Karena kenyataan bahwa wadah tidak hanya berisi kode aplikasi, tetapi juga sistem pra-instal dan perangkat lunak aplikasi dari versi yang diperlukan, Anda dapat melupakan masalah ketergantungan.
Mari kita rangkum pola peluncuran utama versi baru dengan mempertimbangkan faktor-faktor berikut:
- Pada awalnya, aplikasi versi lama berjalan di wadah pertama.
- Versi baru ini kemudian diluncurkan dan “dihangatkan” dalam wadah kedua. Patut dicatat bahwa versi baru ini sendiri tidak hanya membawa kode aplikasi yang diperbarui, tetapi juga semua dependensinya, serta komponen sistem (misalnya, versi baru OpenSSL atau seluruh distribusi).
- Saat versi baru sepenuhnya siap melayani permintaan, lalu lintas beralih dari penampung pertama ke penampung kedua.
- Versi lama sekarang dapat dihentikan.
Pendekatan penerapan versi aplikasi yang berbeda dalam wadah terpisah memberikan kemudahan lain - pengembalian cepat ke versi lama (toh, cukup mengalihkan lalu lintas ke penampung yang diinginkan).
Rekomendasi terakhir yang pertama terdengar seperti sesuatu yang bahkan Kapten tidak dapat menemukan kesalahannya: “[saat mengatur Pengiriman Berkelanjutan dengan Docker] Gunakan Docker [dan memahami apa yang diberikannya]" Ingat, ini bukanlah obat mujarab yang akan menyelesaikan setiap masalah, namun alat yang memberikan landasan yang luar biasa.
Reproduksibilitas
Yang kami maksud dengan “reprodusibilitas” adalah serangkaian masalah umum yang dihadapi saat mengoperasikan aplikasi. Kita berbicara tentang kasus-kasus seperti:
- Naskah yang diperiksa oleh departemen kualitas untuk pementasan harus direproduksi secara akurat dalam produksi.
- Aplikasi diterbitkan di server yang dapat menerima paket dari mirror repositori yang berbeda (seiring waktu, aplikasi tersebut diperbarui, dan bersamanya versi aplikasi yang diinstal).
- “Semuanya berfungsi untuk saya secara lokal!” (...dan pengembang tidak diizinkan melakukan produksi.)
- Anda perlu memeriksa sesuatu di versi lama (diarsipkan).
- ...
Esensi umum mereka bermuara pada kenyataan bahwa kepatuhan penuh terhadap lingkungan yang digunakan (serta tidak adanya faktor manusia) diperlukan. Bagaimana kami dapat menjamin reproduktifitas? Buat gambar Docker berdasarkan kode dari Git, dan kemudian menggunakannya untuk tugas apa pun: di lokasi pengujian, dalam produksi, di mesin pemrogram lokal... Pada saat yang sama, penting untuk meminimalkan tindakan yang dilakukan setelah merakit gambar: semakin sederhana, semakin kecil kemungkinan terjadinya kesalahan.
Infrastruktur adalah kode
Jika persyaratan infrastruktur (ketersediaan perangkat lunak server, versinya, dll.) tidak diformalkan dan “diprogram”, maka peluncuran pembaruan aplikasi apa pun dapat mengakibatkan konsekuensi yang sangat buruk. Misalnya, dalam pementasan Anda telah beralih ke PHP 7.0 dan menulis ulang kodenya - maka kemunculannya dalam produksi dengan beberapa PHP lama (5.5) pasti akan mengejutkan seseorang. Anda mungkin tidak melupakan perubahan besar dalam versi penerjemah, tetapi “masalahnya ada pada detailnya”: kejutannya mungkin terletak pada pembaruan kecil dari ketergantungan apa pun.
Pendekatan untuk memecahkan masalah ini dikenal sebagai IaC (Infrastruktur sebagai Kode, “infrastruktur sebagai kode”) dan melibatkan penyimpanan kebutuhan infrastruktur bersama dengan kode aplikasi. Dengan menggunakannya, pengembang dan spesialis DevOps dapat bekerja dengan repositori aplikasi Git yang sama, tetapi pada bagian yang berbeda. Dari kode ini, image Docker dibuat di Git, di mana aplikasi diterapkan dengan mempertimbangkan semua spesifikasi infrastruktur. Sederhananya, skrip (aturan) untuk merakit gambar harus berada dalam repositori yang sama dengan kode sumber dan digabungkan menjadi satu.
Dalam kasus arsitektur aplikasi multi-layer - misalnya, ada nginx, yang berdiri di depan aplikasi yang sudah berjalan di dalam container Docker - Gambar Docker harus dibuat dari kode di Git untuk setiap lapisan. Kemudian gambar pertama akan berisi aplikasi dengan interpreter dan dependensi “dekat” lainnya, dan gambar kedua akan berisi nginx upstream.
Gambar Docker, komunikasi dengan Git
Kami membagi semua image Docker yang dikumpulkan dari Git menjadi dua kategori: sementara dan rilis. Gambar sementara diberi tag berdasarkan nama cabang di Git, dapat ditimpa oleh komit berikutnya dan diluncurkan hanya untuk pratinjau (bukan untuk produksi). Inilah perbedaan utama mereka dari rilis: Anda tidak pernah tahu komitmen spesifik apa yang ada di dalamnya.
Masuk akal untuk mengumpulkan ke dalam gambar sementara: cabang master (Anda dapat secara otomatis meluncurkannya ke situs terpisah untuk terus melihat versi master saat ini), cabang dengan rilis, cabang inovasi tertentu.
Setelah pratinjau gambar sementara memerlukan terjemahan ke dalam produksi, pengembang memberi tag tertentu. Dikumpulkan secara otomatis berdasarkan tag gambar rilis (tagnya sesuai dengan tag dari Git) dan diluncurkan ke pementasan. Jika berhasil diverifikasi oleh departemen kualitas, maka akan dilanjutkan ke produksi.
dapp
Segala sesuatu yang dijelaskan (peluncuran, perakitan gambar, pemeliharaan selanjutnya) dapat diimplementasikan secara mandiri menggunakan skrip Bash dan alat “improvisasi” lainnya. Namun jika Anda melakukan ini, maka pada titik tertentu penerapannya akan menimbulkan kompleksitas yang besar dan pengendalian yang buruk. Memahami hal ini, kami datang untuk membuat utilitas Alur Kerja khusus kami sendiri untuk membangun CI/CD - dapp.
Kode sumbernya ditulis dalam Ruby, open source dan dipublikasikan di . Sayangnya, dokumentasi saat ini merupakan titik terlemah dari alat ini, namun kami sedang mengusahakannya. Dan kami akan menulis dan berbicara tentang dapp lebih dari sekali, karena... Kami dengan tulus tidak sabar untuk membagikan kemampuannya kepada seluruh komunitas yang tertarik, namun sementara itu, kirimkan masalah Anda dan tarik permintaan dan/atau ikuti perkembangan proyek di GitHub.
Diperbarui 13 Agustus 2019: saat ini merupakan proyek dapp diganti namanya menjadi , kodenya telah sepenuhnya ditulis ulang di Go, dan dokumentasinya telah ditingkatkan secara signifikan.
Kubernetes
Alat Open Source siap pakai lainnya yang telah mendapat pengakuan signifikan di lingkungan profesional adalah Kubernetes, sebuah kluster manajemen Docker. Topik penggunaannya dalam pengoperasian proyek yang dibangun di Docker berada di luar cakupan laporan, sehingga presentasi dibatasi pada gambaran umum beberapa fitur menarik.
Untuk peluncuran, Kubernetes menawarkan:
- pemeriksaan kesiapan — memeriksa kesiapan versi baru aplikasi (untuk mengalihkan lalu lintas ke sana);
- pembaruan bergulir - pembaruan gambar berurutan dalam sekelompok kontainer (pematian, pembaruan, persiapan peluncuran, peralihan lalu lintas);
- pembaruan sinkron - memperbarui gambar dalam cluster dengan pendekatan berbeda: pertama pada separuh wadah, lalu sisanya;
- rilis canary - meluncurkan gambar baru pada sejumlah kontainer terbatas untuk memantau anomali.
Karena Pengiriman Berkelanjutan bukan hanya rilis versi baru, Kubernetes memiliki sejumlah kemampuan untuk pemeliharaan infrastruktur selanjutnya: pemantauan dan logging bawaan untuk semua container, penskalaan otomatis, dll. Semua ini sudah berfungsi dan tinggal menunggu proses yang tepat implementasi dalam proses Anda.
Rekomendasi akhir
- Gunakan Docker.
- Buat gambar Docker aplikasi untuk semua kebutuhan Anda.
- Ikuti prinsip “Infrastruktur adalah kode.”
- Tautkan Git ke Docker.
- Mengatur urutan peluncuran.
- Gunakan platform yang sudah jadi (Kubernetes atau lainnya).
Video dan slide
Video dari pertunjukan (sekitar satu jam) (laporannya sendiri dimulai dari menit ke-5 - ikuti tautan untuk bermain mulai saat ini).
Penyajian laporan:
PS
Laporan lain tentang topik tersebut di blog kami:
- «» (Dmitry Stolyarov; 27 Mei 2019 di DevOpsConf);
- «» (Dmitry Stolyarov; 8 November 2018 di HighLoad++);
- «» (Dmitry Stolyarov; 7 November 2017 di HighLoad++);
- «» (Dmitry Stolyarov; 6 Juni 2017 di RootConf).
Sumber: www.habr.com