Kami akan memulakan blog kami dengan penerbitan berdasarkan ucapan terkini pengarah teknikal kami (Dmitry Stolyarov). Kesemuanya berlangsung pada 2016 di pelbagai acara profesional dan didedikasikan untuk topik DevOps dan Docker. Satu video daripada mesyuarat Docker Moscow di pejabat Badoo, kami sudah pun melakukannya dalam talian. Yang baru akan disertakan dengan artikel yang menyampaikan intipati laporan. Jadiβ¦
31 Mei di persidangan itu , yang diadakan sebagai sebahagian daripada festival "Teknologi Internet Rusia" (RIT++ 2016), bahagian "Pengedaran dan Penggunaan Berterusan" dibuka dengan laporan "Amalan Terbaik Penghantaran Berterusan dengan Docker". Ia meringkaskan dan menyusun amalan terbaik untuk membina proses Penghantaran Berterusan (CD) menggunakan Docker dan produk Sumber Terbuka yang lain. Kami bekerja dengan penyelesaian ini dalam pengeluaran, yang membolehkan kami bergantung pada pengalaman praktikal.
Jika anda mempunyai peluang untuk menghabiskan satu jam , kami mengesyorkan menontonnya sepenuhnya. Jika tidak, di bawah ialah ringkasan utama dalam bentuk teks.
Penghantaran Berterusan dengan Docker
Di bawah Penghantaran berterusan kami memahami rantaian peristiwa yang menyebabkan kod aplikasi daripada repositori Git mula-mula datang ke pengeluaran, dan kemudian berakhir dalam arkib. Dia kelihatan seperti ini: Git β Bina β Ujian β Lepaskan β Kendalikan.
Kebanyakan laporan ditumpukan kepada peringkat binaan (pemasangan aplikasi), dan topik yang dikeluarkan dan dikendalikan disentuh secara ringkas. Kami akan bercakap tentang masalah dan corak yang membolehkan anda menyelesaikannya, dan pelaksanaan khusus corak ini mungkin berbeza.
Mengapakah Docker diperlukan di sini sama sekali? Kami memutuskan untuk bercakap tentang amalan Penghantaran Berterusan dalam konteks alat Sumber Terbuka ini. Walaupun keseluruhan laporan ditumpukan kepada penggunaannya, banyak sebab didedahkan apabila mempertimbangkan corak utama pelancaran kod aplikasi.
Corak pelancaran utama
Oleh itu, apabila kami melancarkan versi baharu aplikasi, kami pasti berhadapan dengannya masalah masa henti, dijana semasa menukar pelayan pengeluaran. Trafik daripada versi lama aplikasi kepada yang baharu tidak boleh bertukar serta-merta: mula-mula kita mesti memastikan bahawa versi baharu bukan sahaja berjaya dimuat turun, tetapi juga "dipanaskan" (iaitu, bersedia sepenuhnya untuk melayani permintaan).
Oleh itu, untuk beberapa waktu kedua-dua versi aplikasi (lama dan baharu) akan berfungsi secara serentak. Yang secara automatik membawa kepada konflik sumber yang dikongsi: rangkaian, sistem fail, IPC, dsb. Dengan Docker, masalah ini mudah diselesaikan dengan menjalankan versi aplikasi yang berbeza dalam bekas berasingan, yang mana pengasingan sumber dijamin dalam hos yang sama (pelayan/mesin maya). Sudah tentu, anda boleh bertahan dengan beberapa helah tanpa penebat sama sekali, tetapi jika ada alat siap pakai dan mudah, maka ada sebab yang bertentangan - jangan mengabaikannya.
Pengkontenaan memberikan banyak faedah lain apabila digunakan. Sebarang permohonan bergantung kepada versi tertentu (atau julat versi) jurubahasa, ketersediaan modul/sambungan, dsb., serta versinya. Dan ini terpakai bukan sahaja kepada persekitaran boleh laku serta-merta, tetapi juga kepada keseluruhan persekitaran, termasuk perisian sistem dan versinya (sehingga pengedaran Linux yang digunakan). Disebabkan fakta bahawa bekas mengandungi bukan sahaja kod aplikasi, tetapi juga sistem pra-pasang dan perisian aplikasi versi yang diperlukan, anda boleh melupakan masalah dengan kebergantungan.
Mari kita ringkaskan corak pelancaran utama versi baharu dengan mengambil kira faktor berikut:
- Pada mulanya, versi lama aplikasi berjalan dalam bekas pertama.
- Versi baharu kemudiannya dilancarkan dan "dipanaskan" dalam bekas kedua. Perlu diperhatikan bahawa versi baharu ini sendiri mungkin membawa bukan sahaja kod aplikasi yang dikemas kini, tetapi juga mana-mana kebergantungannya, serta komponen sistem (contohnya, versi baharu OpenSSL atau keseluruhan pengedaran).
- Apabila versi baharu bersedia sepenuhnya untuk menyampaikan permintaan, trafik bertukar daripada bekas pertama kepada bekas kedua.
- Versi lama kini boleh dihentikan.
Pendekatan menggunakan versi aplikasi yang berbeza dalam bekas berasingan ini memberikan kemudahan lain - rollback cepat kepada versi lama (lagi pun, sudah cukup untuk menukar trafik ke bekas yang diingini).
Pengesyoran pertama terakhir terdengar seperti sesuatu yang Kapten tidak dapat mencari kesalahannya: β[semasa menganjurkan Penghantaran Berterusan dengan Docker] Gunakan Docker [dan fahami apa yang diberikannya]" Ingat, ini bukan peluru perak yang akan menyelesaikan setiap masalah, tetapi alat yang menyediakan asas yang indah.
Kebolehulangan
Dengan "kebolehulangan" kami bermaksud set umum masalah yang dihadapi semasa mengendalikan aplikasi. Kami bercakap tentang kes sedemikian:
- Skrip yang disemak oleh jabatan kualiti untuk pementasan mesti diterbitkan semula dengan tepat dalam pengeluaran.
- Aplikasi diterbitkan pada pelayan yang boleh menerima pakej daripada cermin repositori yang berbeza (dari masa ke masa ia dikemas kini, dan dengannya versi aplikasi yang dipasang).
- βSemuanya berfungsi untuk saya secara tempatan!β (...dan pembangun tidak dibenarkan dalam pengeluaran.)
- Anda perlu menyemak sesuatu dalam versi lama (diarkibkan).
- ...
Intipati amnya berpunca daripada fakta bahawa pematuhan penuh terhadap persekitaran yang digunakan (serta ketiadaan faktor manusia) adalah perlu. Bagaimanakah kita boleh menjamin kebolehulangan? Buat imej Docker berdasarkan kod daripada Git, dan kemudian gunakannya untuk sebarang tugas: di tapak ujian, dalam pengeluaran, pada mesin tempatan pengaturcara... Pada masa yang sama, adalah penting untuk meminimumkan tindakan yang dilakukan selepas memasang imej: lebih mudah, semakin kecil kemungkinan terdapat ralat.
Infrastruktur adalah kod
Jika keperluan infrastruktur (ketersediaan perisian pelayan, versinya, dsb.) tidak diformalkan dan "diprogramkan", maka pelancaran sebarang kemas kini aplikasi boleh mengakibatkan akibat yang buruk. Sebagai contoh, dalam pementasan anda telah bertukar kepada PHP 7.0 dan menulis semula kod tersebut dengan sewajarnya - maka penampilannya dalam pengeluaran dengan PHP lama (5.5) pastinya akan mengejutkan seseorang. Anda mungkin tidak lupa tentang perubahan besar dalam versi penterjemah, tetapi "syaitan ada dalam butiran": kejutan mungkin dalam kemas kini kecil bagi sebarang pergantungan.
Pendekatan untuk menyelesaikan masalah ini dikenali sebagai IaC (Infrastruktur sebagai Kod, "infrastruktur sebagai kod") dan melibatkan penyimpanan keperluan infrastruktur bersama kod aplikasi. Menggunakannya, pembangun dan pakar DevOps boleh bekerja dengan repositori aplikasi Git yang sama, tetapi pada bahagian yang berbeza daripadanya. Daripada kod ini, imej Docker dicipta dalam Git, di mana aplikasi itu digunakan dengan mengambil kira semua spesifikasi infrastruktur. Ringkasnya, skrip (peraturan) untuk memasang imej harus berada dalam repositori yang sama dengan kod sumber dan digabungkan bersama.
Dalam kes seni bina aplikasi berbilang lapisan - contohnya, terdapat nginx, yang berdiri di hadapan aplikasi yang sudah berjalan di dalam bekas Docker - Imej Docker mesti dibuat daripada kod dalam Git untuk setiap lapisan. Kemudian imej pertama akan mengandungi aplikasi dengan penterjemah dan kebergantungan "dekat" lain, dan imej kedua akan mengandungi nginx huluan.
Imej Docker, komunikasi dengan Git
Kami membahagikan semua imej Docker yang dikumpul daripada Git kepada dua kategori: sementara dan keluaran. Imej sementara ditandakan dengan nama cawangan dalam Git, boleh ditimpa oleh komit seterusnya dan dilancarkan hanya untuk pratonton (bukan untuk pengeluaran). Ini adalah perbezaan utama mereka daripada yang dikeluarkan: anda tidak pernah tahu komitmen khusus yang ada di dalamnya.
Adalah masuk akal untuk mengumpul imej sementara: cawangan induk (anda boleh melancarkannya secara automatik ke tapak berasingan untuk sentiasa melihat versi induk semasa), cawangan dengan keluaran, cawangan inovasi tertentu.
Selepas pratonton imej sementara datang kepada keperluan untuk terjemahan ke dalam pengeluaran, pembangun meletakkan tag tertentu. Dikumpul secara automatik dengan tag keluarkan imej (tegnya sepadan dengan teg daripada Git) dan dilancarkan ke pementasan. Jika ia berjaya disahkan oleh jabatan kualiti, ia pergi ke pengeluaran.
dapp
Semua yang diterangkan (pelancaran, pemasangan imej, penyelenggaraan seterusnya) boleh dilaksanakan secara bebas menggunakan skrip Bash dan alat "improvisasi" lain. Tetapi jika anda melakukan ini, maka pada satu ketika pelaksanaan akan membawa kepada kerumitan yang besar dan kawalan yang lemah. Memahami perkara ini, kami datang untuk mencipta utiliti Aliran Kerja khusus kami sendiri untuk membina CI/CD - dapp.
Kod sumbernya ditulis dalam Ruby, sumber terbuka dan diterbitkan pada . Malangnya, dokumentasi pada masa ini merupakan titik paling lemah alat, tetapi kami sedang mengusahakannya. Dan kami akan menulis dan bercakap tentang dapp lebih daripada sekali, kerana... Kami benar-benar tidak sabar untuk berkongsi keupayaannya dengan seluruh komuniti yang berminat, tetapi sementara itu, hantar isu anda dan tarik permintaan dan/atau ikuti perkembangan projek di GitHub.
Dikemas kini pada 13 Ogos 2019: pada masa ini projek dapp dinamakan semula kepada , kodnya telah ditulis semula sepenuhnya dalam Go, dan dokumentasinya telah dipertingkatkan dengan ketara.
Kubernetes
Satu lagi alat Sumber Terbuka sedia yang telah menerima pengiktirafan ketara dalam persekitaran profesional ialah Kubernetes, kluster pengurusan Docker. Topik penggunaannya dalam pengendalian projek yang dibina di Docker adalah di luar skop laporan, jadi pembentangan terhad kepada gambaran keseluruhan beberapa ciri menarik.
Untuk pelancaran, Kubernetes menawarkan:
- siasatan kesediaan β menyemak kesediaan versi baharu aplikasi (untuk menukar trafik kepadanya);
- kemas kini bergulir - kemas kini imej berurutan dalam kelompok bekas (penutupan, kemas kini, persediaan untuk pelancaran, penukaran trafik);
- kemas kini segerak - mengemas kini imej dalam kelompok dengan pendekatan berbeza: pertama pada separuh bekas, kemudian pada yang lain;
- keluaran kenari - melancarkan imej baharu pada bilangan bekas (kecil) terhad untuk memantau anomali.
Memandangkan Penghantaran Berterusan bukan sahaja keluaran versi baharu, Kubernetes mempunyai beberapa keupayaan untuk penyelenggaraan infrastruktur seterusnya: pemantauan dan pengelogan terbina dalam untuk semua kontena, penskalaan automatik, dll. Semua ini sudah berfungsi dan hanya menunggu yang betul pelaksanaan dalam proses anda.
Cadangan akhir
- Gunakan Docker.
- Cipta imej aplikasi Docker untuk semua keperluan anda.
- Ikut prinsip "Infrastruktur ialah kod."
- Pautkan Git ke Docker.
- Kawal selia susunan pelancaran.
- Gunakan platform siap sedia (Kubernetes atau yang lain).
Video dan slaid
Video daripada persembahan (kira-kira sejam) (laporan itu sendiri bermula dari minit ke-5 - ikuti pautan untuk bermain dari saat ini).
Pembentangan laporan:
PS
Laporan lain mengenai topik 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 Jun 2017 di RootConf).
Sumber: www.habr.com