🥇Laku Pangiriman Terus-terusan karo Docker (review lan video)

Kita bakal miwiti blog kita kanthi publikasi adhedhasar pidato paling anyar saka direktur teknis kita distol (Dmitry Stolyarov). Kabeh mau ditindakake ing 2016 ing macem-macem acara profesional lan dikhususake kanggo topik DevOps lan Docker. Siji video saka rapat Docker Moscow ing kantor Badoo, kita wis diterbitake Nyambung. Artikel anyar bakal dibarengi karo artikel sing ngemot inti saka laporan kasebut. Dadi…

31 Mei ing konferensi RootConf 2016, dianakaké minangka bagéan saka festival "Teknologi Internet Rusia" (RIT ++ 2016), bagean "Panyebaran lan Penyebaran Terus-terusan" dibukak kanthi laporan "Praktik Paling Apik Pangiriman Terus-terusan karo Docker". Iki ngringkes lan sistematis praktik paling apik kanggo mbangun proses Pangiriman Terus (CD) nggunakake Docker lan produk Open Source liyane. Kita nggarap solusi kasebut ing produksi, sing ngidini kita ngandelake pengalaman praktis.

Yen sampeyan duwe kesempatan kanggo nglampahi jam video saka laporan, disaranake nonton kanthi lengkap. Yen ora, ing ngisor iki minangka ringkesan utama ing wangun teks.

Pangiriman Terus-terusan karo Docker

Miturut Pangiriman sing Terus kita ngerti rantai acara minangka asil saka kode aplikasi saka gudang Git pisanan teka menyang produksi, lan banjur rampung ing arsip. Katon kaya mangkene: Git → Mbangun → Test → Rilis → Operate.

Umume laporan dikhususake kanggo tahap mbangun (majelis aplikasi), lan topik sing diluncurake lan dioperasikake kanthi cepet. Kita bakal ngomong babagan masalah lan pola sing ngidini sampeyan ngatasi, lan implementasine tartamtu saka pola kasebut bisa uga beda.

Napa Docker dibutuhake ing kene? Ora ana gunane yen kita mutusake kanggo ngobrol babagan praktik Pangiriman Terus-terusan ing konteks alat Open Source iki. Sanajan kabeh laporan dikhususake kanggo panggunaane, akeh alasan sing dicethakake nalika nimbang pola utama peluncuran kode aplikasi.

Pola rollout utama

Dadi, nalika kita muter versi anyar saka aplikasi, kita mesthi ngadhepi karo masalah downtime, kui nalika ngoper saka server produksi. Lalu lintas saka versi lawas saka aplikasi menyang anyar ora bisa langsung ngalih: pisanan kita kudu nggawe manawa versi anyar ora mung kasil diundhuh, nanging uga "warmed" (i. e., rampung siap kanggo ngawula panjalukan).

Mangkono, kanggo sawetara wektu loro versi aplikasi (lawas lan anyar) bakal bisa bebarengan. Kang otomatis ndadékaké kanggo konflik sumber daya bareng: jaringan, sistem file, IPC, lsp. Kanthi Docker, masalah iki gampang ditanggulangi kanthi mbukak macem-macem versi aplikasi ing wadhah sing kapisah, sing njamin isolasi sumber daya ing host sing padha (server / mesin virtual). Mesthi wae, sampeyan bisa entuk sawetara trik tanpa insulasi, nanging yen ana alat sing wis siap lan trep, mula ana alesan sing ngelawan - ora nglirwakake.

Containerization nyedhiyakake akeh keuntungan liyane nalika disebarake. Aplikasi apa wae gumantung versi tartamtu (utawa sawetara versi) juru basa, kasedhiyan modul / ekstensi, etc., uga versi. Lan iki ditrapake ora mung kanggo lingkungan eksekusi langsung, nanging uga kanggo kabeh lingkungan, kalebu piranti lunak sistem lan versi (nganti distribusi Linux sing digunakake). Amarga kasunyatan manawa kontaner ora mung ngemot kode aplikasi, nanging uga sistem sing wis diinstal lan piranti lunak aplikasi saka versi sing dibutuhake, sampeyan bisa lali babagan masalah karo dependensi.

Ayo umumake pola rollout utama versi anyar njupuk menyang akun faktor ing ngisor iki:

Kaping pisanan, versi lawas saka aplikasi mbukak ing wadhah pisanan.
Versi anyar banjur digulung lan "dipanasake" ing wadhah kapindho. Wigati dimangerteni manawa versi anyar iki dhewe bisa uga ora mung nggawa kode aplikasi sing dianyari, nanging uga kabeh dependensi, uga komponen sistem (contone, versi anyar OpenSSL utawa kabeh distribusi).
Nalika versi anyar wis siyap kanggo ngawula panjalukan, lalu lintas ngalih saka wadhah pisanan kanggo kaloro.
Versi lawas saiki bisa mandheg.

Pendekatan iki kanggo nggunakake macem-macem versi aplikasi ing wadhah sing kapisah nyedhiyakake penak liyane - rollback cepet menyang versi lawas (sawise kabeh, iku cukup kanggo ngalih lalu lintas menyang wadhah sing dikarepake).

Rekomendasi pisanan sing pungkasan kaya ngono sing malah Kapten ora bisa nemokake kesalahane: "[nalika ngatur Pangiriman Terus-terusan karo Docker] Gunakake Docker [lan ngerti apa sing diwenehake]" Elinga, iki dudu peluru perak sing bakal ngrampungake saben masalah, nanging alat sing nyedhiyakake dhasar sing apik.

Reproduksibilitas

Miturut "reproduksibilitas" tegese sakumpulan masalah umum sing ditemoni nalika ngoperasikake aplikasi. Kita ngomong babagan kasus kasebut:

Skrip sing dicenthang dening departemen kualitas kanggo pementasan kudu direproduksi kanthi tepat ing produksi.
Aplikasi diterbitake ing server sing bisa nampa paket saka macem-macem mirrors gudang (suwene padha dianyari, lan karo wong-wong mau versi aplikasi diinstal).
"Kabeh bisa digunakake kanggo kula lokal!" (...lan pangembang ora diidini produksi.)
Sampeyan kudu mriksa soko ing versi lawas (arsip).
...

Inti umume dadi kasunyatan manawa kepatuhan lengkap lingkungan sing digunakake (uga ora ana faktor manungsa) dibutuhake. Kepiye carane bisa njamin reproduktifitas? Nggawe gambar Docker adhedhasar kode saka Git, banjur gunakake kanggo tugas apa wae: ing situs tes, ing produksi, ing mesin programer lokal ... Ing wektu sing padha, penting kanggo nyilikake tumindak sing ditindakake. после assembling gambar: sing prasaja iku, sing kurang kamungkinan ana kasalahan.

Infrastruktur minangka kode

Yen syarat infrastruktur (kasedhiya piranti lunak server, versi, lan liya-liyane) ora diformal lan "diprogram", mula nganyari aplikasi apa wae bisa nyebabake akibat sing mbebayani. Contone, ing pementasan sampeyan wis ngalih menyang PHP 7.0 lan nulis maneh kode kasebut - banjur katon ing produksi karo sawetara PHP lawas (5.5) mesthi bakal kaget wong. Sampeyan bisa uga ora lali bab owah-owahan utama ing versi interpreter, nanging "setan ana ing rincian": surprise bisa uga ana ing nganyari suntingan saka katergantungan sembarang.

Pendekatan kanggo ngatasi masalah iki dikenal minangka IaC (Infrastructure as Code, "infrastructure as code") lan melu nyimpen syarat infrastruktur bebarengan karo kode aplikasi. Nggunakake, pangembang lan spesialis DevOps bisa nggarap repositori aplikasi Git sing padha, nanging ing macem-macem bagean. Saka kode iki, gambar Docker digawe ing Git, ing ngendi aplikasi kasebut disebarake kanthi nimbang kabeh spesifik infrastruktur kasebut. Cukup, skrip (aturan) kanggo ngumpulake gambar kudu ana ing gudang sing padha karo kode sumber lan digabungake.

Ing kasus arsitektur aplikasi multi-lapisan - contone, ana nginx, sing ana ing ngarep aplikasi sing wis mlaku ing wadhah Docker - Gambar Docker kudu digawe saka kode ing Git kanggo saben lapisan. Banjur gambar pisanan bakal ngemot aplikasi kanthi interpreter lan dependensi "cedhak" liyane, lan gambar kapindho bakal ngemot nginx hulu.

Gambar Docker, komunikasi karo Git

Kita dibagi kabeh gambar Docker sing diklumpukake saka Git dadi rong kategori: sementara lan rilis. Gambar sauntara diwenehi jeneng cabang ing Git, bisa ditimpa dening komit sabanjure lan diluncurake mung kanggo pratinjau (ora kanggo produksi). Iki minangka prabédan utama saka sing diluncurake: sampeyan ora bakal ngerti komitmen tartamtu sing ana ing dheweke.

Iku ndadekake pangertèn kanggo ngumpulake menyang gambar sak wentoro: cabang master (sampeyan bisa kanthi otomatis muter metu menyang situs kapisah kanggo terus-terusan ndeleng versi master saiki), cabang karo rilis, cabang saka inovasi tartamtu.

Sawise pratinjau gambar sauntara mbutuhake terjemahan menyang produksi, pangembang menehi tag tartamtu. Dikumpulake kanthi otomatis kanthi tag release gambar (tag kasebut cocog karo tag saka Git) lan diluncurake menyang pementasan. Yen kasil diverifikasi dening departemen kualitas, iku menyang produksi.

dapp

Kabeh sing diterangake (rollout, perakitan gambar, pangopènan sakteruse) bisa ditindakake kanthi mandiri nggunakake skrip Bash lan alat "improvisasi" liyane. Nanging yen sampeyan nindakake iki, banjur ing sawetara titik implementasine bakal mimpin kanggo kerumitan gedhe lan kontrol miskin. Ngerteni iki, kita nggawe utilitas Workflow khusus kanggo mbangun CI / CD - dapp.

Kode sumber ditulis ing Ruby, open source lan diterbitake ing GitHub. Sayange, dokumentasi saiki minangka titik paling lemah saka alat kasebut, nanging kita lagi nggarap. Lan kita bakal nulis lan ngomong babagan dapp luwih saka sepisan, amarga ... Kita ora bisa ngenteni kanggo nuduhake kemampuane karo kabeh komunitas sing kasengsem, nanging sauntara, kirim masalah sampeyan lan narik panjaluk lan / utawa tindakake pangembangan proyek ing GitHub.

Dianyari 13 Agustus 2019: saiki proyek dapp ganti jeneng dadi werf, kode wis rampung ditulis maneh ing Go, lan dokumentasi wis Ngartekno apik.

Kubernetes

Alat Open Source siap liyane sing wis entuk pangenalan sing signifikan ing lingkungan profesional yaiku Kubernetes, klompok manajemen Docker. Topik panggunaan ing operasi proyek sing dibangun ing Docker ngluwihi ruang lingkup laporan, saengga presentasi diwatesi kanggo ringkesan sawetara fitur sing menarik.

Kanggo diluncurake, Kubernetes nawakake:

probe kesiapan - mriksa kesiapan versi aplikasi anyar (kanggo ngalih lalu lintas menyang);
nganyari rolling - nganyari gambar urutan ing kluster wadhah (mati, nganyari, preparation kanggo Bukak, ngoper lalu lintas);
nganyari sinkron - nganyari gambar ing kluster kanthi pendekatan sing beda: pisanan ing setengah saka wadhah, banjur ing liyane;
rilis kenari - ngetokake gambar anyar ing jumlah winates (cilik) kontaner kanggo ngawasi anomali.

Wiwit Pangiriman Terus-terusan ora mung rilis versi anyar, Kubernetes duwe sawetara kemampuan kanggo pangopènan infrastruktur sakteruse: ngawasi lan logging sing dibangun kanggo kabeh kontaner, skala otomatis, lsp. Kabeh iki wis bisa digunakake lan mung ngenteni sing tepat implementasine ing proses sampeyan.

Rekomendasi pungkasan

Gunakake Docker.
Gawe gambar aplikasi Docker kanggo kabeh kabutuhan sampeyan.
Tindakake prinsip "Infrastruktur iku kode."
Link Git menyang Docker.
Ngatur urutan rollout.
Gunakake platform sing wis siap (Kubernetes utawa liyane).

Video lan minger

Video saka pagelaran (kira-kira sak jam) diterbitake ing YouTube (laporan kasebut diwiwiti saka menit kaping 5 - tindakake link kanggo muter wiwit saiki).

Presentasi laporan:

PS

Laporan liyane babagan topik ing blog kita:

«werf - alat kita kanggo CI/CD ing Kubernetes (review lan laporan video)» (Dmitry Stolyarov; 27 Mei 2019 ing DevOpsConf);
«Database lan Kubernetes» (Dmitry Stolyarov; 8 November 2018 ing HighLoad++);
«Praktik Terbaik CI/CD karo Kubernetes lan GitLab» (Dmitry Stolyarov; 7 November 2017 ing HighLoad++);
«Pengalaman kita karo Kubernetes ing proyek cilik» (Dmitry Stolyarov; 6 Juni 2017 ing RootConf).

Source: www.habr.com

Praktek Pangiriman Terus-terusan karo Docker (review lan video)