Piye wae ing salah siji titik aku mutusaké kanggo nulis artikel bab pangiriman ing wangun Docker kontaner lan paket deb, nanging nalika miwiti, sakperangan alesan aku digawa bali menyang kaping adoh saka komputer pribadi pisanan lan malah kalkulator. Umumé, tinimbang perbandingan garing saka docker lan deb, kita entuk pikirane babagan topik evolusi, sing dakkarepake kanggo sampeyan.
Sembarang produk, apa wae, kudu entuk server produk, kudu dikonfigurasi lan diluncurake. Sing bakal dadi artikel iki.
Aku bakal mikir ing konteks sejarah, "apa sing dakdeleng yaiku apa sing dakkandhani," apa sing dakdeleng nalika aku miwiti nulis kode lan apa sing dakdeleng saiki, apa sing kita gunakake saiki lan kenapa. Artikel kasebut ora nyamar dadi sinau lengkap, sawetara poin sing ora kejawab, iki minangka pandangan pribadi babagan apa sing ana lan saiki.
Dadi, ing jaman biyen ... cara pangiriman paling awal sing ditemokake yaiku kaset saka tape recorder. Aku duwe komputer BK-0010.01...
Jaman kalkulator
Ora, ana wayahe sadurunge, ana uga kalkulator и .
Dadi nalika aku wis , banjur cara nransfer program kasebut minangka kertas biasa ing kothak sing ditulis program, sing, yen perlu, kanggo mbukak kanthi manual, ditulis ing kalkulator. Yen sampeyan arep kanggo muter (ya, malah iki kalkulator antediluvian wis game) - sampeyan njagong mudhun lan ketik program menyang kalkulator. Alami, nalika kalkulator dipateni, program kasebut ilang dadi lalen. Saliyane kode kalkulator sing ditulis ing kertas ing tangane dhewe, program kasebut diterbitake ing majalah "Radio" lan "Teknologi Remaja", lan uga diterbitake ing buku-buku ing wektu kasebut.
Modifikasi sabanjure yaiku kalkulator , iku wis sawetara semblance saka panyimpenan data non-molah malih. Saiki game utawa program ora kudu dilebokake kanthi manual, nanging sawise nindakake sawetara pass magis kanthi tombol, iku dimuat dhewe.
Ukuran program paling gedhe ing kalkulator ana 105 langkah, lan ukuran memori permanen ing MK-52 ana 512 langkah.
Miturut cara, yen ana penggemar kalkulator iki sing maca artikel iki, ing proses nulis artikel, aku nemokake loro emulator kalkulator kanggo Android lan program kasebut. Maju menyang masa lalu!
A digression singkat babagan MK-52 (saka Wikipedia)
MK-52 mabur menyang angkasa kanthi pesawat ruang angkasa Soyuz TM-7. Mesthine digunakake kanggo ngetung lintasan landing yen komputer ing papan gagal.
Wiwit taun 52, MK-1988 kanthi unit ekspansi memori Elektronika-Astro wis disedhiyakake menyang kapal Angkatan Laut minangka bagéan saka kit komputasi navigasi.
Komputer pribadi pisanan
Ayo bali menyang jaman . Cetha yen ana luwih akeh memori ing kana, lan ngetik kode saka selembar kertas ora dadi pilihan maneh (sanajan pisanan aku nindakake, amarga ora ana medium liyane). Kaset audio kanggo tape recorder dadi sarana utama kanggo nyimpen lan ngirim piranti lunak.
Panyimpenan ing kaset biasane ana ing siji utawa rong file binar, kabeh liyane ana ing njero. Keandalan banget kurang, aku kudu nyimpen 2-3 salinan program kasebut. Wektu loading uga nguciwani, lan para penggemar nyoba ngodhe frekuensi sing beda kanggo ngatasi kekurangan kasebut. Ing wektu iku, aku dhewe durung melu ing pangembangan piranti lunak profesional (ora ngetung program prasaja ing BASIC), dadi, sayangé, aku ora bakal pitutur marang kowe kanthi rinci carane kabeh wis diatur nang. Kasunyatan bilih komputer mung duwe RAM kanggo umume nemtokake kesederhanaan skema panyimpenan data.
Muncule media panyimpenan sing bisa dipercaya lan gedhe
Mengko, floppy disk muncul, proses nyalin disederhanakake, lan linuwih tambah.
Nanging kahanan diganti dramatically mung nalika panyimpenan lokal cukup gedhe katon ing wangun HDDs.
Jinis pangiriman dhasar ganti: program installer katon sing ngatur proses konfigurasi sistem, uga ngresiki sawise dibusak, amarga program ora mung diwaca ing memori, nanging wis disalin menyang panyimpenan lokal, saka ngendi sampeyan kudu bisa ngresiki barang sing ora perlu yen perlu.
Ing wektu sing padha, kerumitan piranti lunak sing diwenehake saya tambah.
Jumlah file ing pangiriman mundhak saka sawetara kanggo atusan lan ewu, konflik antarane versi perpustakaan lan joys liyane wiwit nalika program beda nggunakake data padha.
Ing wektu iku, eksistensi Linux durung mbukak kanggo kula; Aku manggon ing donya MS DOS lan, mengko, Windows, lan nulis ing Borland Pascal lan Delphi, kadhangkala looking menyang C++. Akeh wong nggunakake InstallShield kanggo ngirim produk nalika iku. , sing cukup sukses ngrampungake kabeh tugas sing ditugasake kanggo nyebarake lan ngatur piranti lunak.
jaman internet
Secara bertahap, kerumitan sistem piranti lunak dadi luwih rumit; saka aplikasi monolit lan desktop ana transisi menyang sistem sing disebarake, klien tipis lan layanan mikro. Saiki sampeyan kudu ngatur ora mung siji program, nanging pesawat saka wong-wong mau, lan supaya padha bisa bebarengan.
Konsep rampung diganti, Internet teka, jaman layanan awan teka. Nganti saiki, mung ing tahap awal, ing wangun situs web, ora ana sing ngimpi babagan layanan. nanging iki minangka titik balik ing pangembangan lan pangiriman aplikasi.
Kanggo aku, aku nyathet yen ing wayahe ana owah-owahan ing generasi pangembang (utawa mung ing lingkunganku), lan ana perasaan yen kabeh cara pangiriman lawas sing apik dilalekake ing sawijining wektu lan kabeh diwiwiti saka banget. wiwitan: kabeh pangiriman wiwit rampung script dhengkul lan bangga disebut "pangiriman Terus". Nyatane, periode kekacauan wis diwiwiti, nalika sing lawas dilalekake lan ora digunakake, lan sing anyar ora ana.
Aku elinga kaping nalika ing perusahaan kita ngendi aku makarya banjur (aku ora bakal jeneng iku), tinimbang mbangun liwat semut (maven durung populer utawa ora ana ing kabeh), wong mung diklumpukake lodhong ing IDE lan serenely setya. ing SVN. Mulane, panyebaran kalebu njupuk file saka SVN lan nyalin liwat SSH menyang mesin sing dikarepake. Iku prasaja lan kikuk.
Ing wektu sing padha, pangiriman situs prasaja ing PHP ditindakake kanthi cara sing primitif kanthi mung nyalin file sing dikoreksi liwat FTP menyang mesin target. Kadhangkala iki ora kedadeyan - kode kasebut diowahi langsung ing server produk, lan luwih apik yen ana serep ing endi wae.
Paket RPM lan DEB
Ing sisih liya, kanthi pangembangan Internet, sistem kaya UNIX wiwit saya tambah populer, utamane, nalika iku aku nemokake RedHat Linux 6, kira-kira taun 2000. Mesthi, ana uga cara tartamtu kanggo ngirim piranti lunak; miturut Wikipedia, RPM minangka manajer paket utama wis muncul ing taun 1995, ing versi RedHat Linux 2.0. Lan wiwit iku lan nganti saiki, sistem wis dikirim ing wangun paket RPM lan wis cukup sukses ana lan berkembang.
Distribusi kulawarga Debian ngetutake dalan sing padha lan ngetrapake pangiriman ing bentuk paket deb, sing tetep ora owah nganti saiki.
Manajer paket ngidini sampeyan ngirim produk piranti lunak dhewe, ngatur nalika proses instalasi, ngatur dependensi ing antarane macem-macem paket, mbusak produk lan ngresiki barang sing ora perlu sajrone proses instal. Sing. kanggo sisih paling, iku kabeh sing perlu, kang kok padha langgeng sawetara dekade sakbenere panggah.
Komputasi awan nambahake instalasi menyang manajer paket ora mung saka media fisik, nanging uga saka repositori maya, nanging dhasare ora owah.
Wigati dicathet yen saiki ana sawetara gerakan kanggo pindhah saka deb lan ngalih menyang paket snap, nanging luwih akeh mengko.
Dadi, pangembang awan generasi anyar iki, sing ora ngerti DEB utawa RPM, uga alon-alon tuwuh, entuk pengalaman, produk dadi luwih rumit, lan sawetara cara pangiriman sing luwih wajar dibutuhake tinimbang FTP, skrip bash lan kerajinan siswa sing padha.
Lan ing kene Docker teka ing gambar, jinis campuran virtualisasi, delimitasi sumber daya lan cara pangiriman. Saiki modis lan enom, nanging apa perlu kanggo kabeh? Apa iki panacea?
Saka pengamatanku, asring banget Docker diusulake ora minangka pilihan sing cukup, nanging mung amarga, ing tangan siji, dirembug ing masyarakat, lan sing ngusulake mung ngerti. Ing sisih liya, umume dheweke meneng babagan sistem kemasan lawas sing apik - dheweke ana lan nindakake pakaryan kanthi tenang lan ora dingerteni. Ing kahanan kaya ngono, pancen ora ana pilihan liyane - pilihan kasebut jelas - Docker.
Aku bakal nyoba nuduhake pengalaman babagan carane nindakake Docker lan apa sing kedadeyan.
Skrip sing ditulis dhewe
Kaping pisanan, ana skrip bash sing nyebarake arsip jar menyang mesin sing dibutuhake. Proses iki dikelola dening Jenkins. Iki bisa ditindakake kanthi sukses, amarga arsip jar dhewe wis dadi perakitan sing ngemot kelas, sumber daya lan malah konfigurasi. Yen sampeyan sijine kabeh menyang maksimum, banjur nggedhekake menyang script ora bab sing paling angel sampeyan kudu
Nanging skrip duwe sawetara kekurangan:
- skrip biasane ditulis kanthi cepet lan mulane dadi primitif sing mung ngemot siji skenario paling apik. Iki difasilitasi dening pangembang kasengsem ing pangiriman cepet, lan skrip normal mbutuhake investasi sumber daya sing cukup.
- minangka akibat saka titik sadurunge, script ora ngemot tata cara uninstallation
- ora ana prosedur upgrade diadegaké
- Nalika produk anyar katon, sampeyan kudu nulis skrip anyar
- ora ana dhukungan ketergantungan
Mesthi, sampeyan bisa nulis skrip sing canggih, nanging, kaya sing dak tulis ing ndhuwur, iki minangka wektu pangembangan, lan paling ora, lan, kaya sing kita ngerti, mesthi ora ana wektu sing cukup.
Kabeh iki temenan mbatesi sawetara aplikasi metode penyebaran iki mung kanggo sistem sing paling gampang. Wektu wis teka kanggo ngganti iki.
docker
Ing sawetara titik, wong tengah sing anyar wiwit teka, kanthi ide lan ngoceh babagan docker. Inggih, gendéra ing tangan - ayo nindakaken! Ana rong usaha. Loro-lorone ora kasil - ayo ngomong, amarga ambisi gedhe, nanging ora duwe pengalaman nyata. Apa perlu kanggo meksa lan ngrampungake kanthi cara apa wae? Ora mungkin - tim kudu berkembang nganti tingkat sing dibutuhake sadurunge bisa nggunakake alat sing cocog. Kajaba iku, nalika nggunakake gambar Docker sing wis siap, kita asring nemoni kasunyatan manawa jaringan kasebut ora bisa digunakake kanthi bener (sing bisa uga amarga kelembapan Docker dhewe) utawa angel nggedhekake wadhah wong liya.
Kesulitan apa sing kita alami?
- Masalah jaringan ing mode bridge
- Ora trep kanggo ndeleng log ing wadhah (yen ora disimpen kanthi kapisah ing sistem file mesin host)
- ElasticSearch sok-sok beku aneh ing njero wadhah, alesane durung ditemtokake, wadhah kasebut resmi
- Sampeyan perlu nggunakake cangkang ing wadhah - kabeh wis diudani, ora ana alat sing biasa
- Ukuran gedhe saka wadhah sing diklumpukake - larang kanggo disimpen
- Amarga ukuran gedhe saka wadhah, iku angel ndhukung macem-macem versi
- Wektu mbangun luwih suwe, ora kaya metode liyane (skrip utawa paket deb)
Ing tangan liyane, kok luwih elek kanggo masang layanan Spring ing wangun arsip jar liwat deb padha? Apa isolasi sumber daya pancen perlu? Apa perlu kelangan alat sistem operasi sing trep kanthi ngisi layanan menyang wadhah sing suda banget?
Minangka laku wis ditampilake, ing kasunyatan iki ora perlu, paket deb cukup ing 90% kasus.
Nalika deb lawas sing apik gagal lan kapan kita butuh docker?
Kanggo kita, iki nggunakake layanan ing python. Akeh perpustakaan sing dibutuhake kanggo sinau mesin lan ora kalebu ing distribusi standar sistem operasi (lan ana versi sing salah), hacks karo setelan, perlu kanggo macem-macem versi kanggo layanan sing beda-beda sing manggon ing sistem host sing padha. iki , sing mung cara cukup kanggo ngirim campuran nuklir iki docker. Intensitas tenaga kerja kanggo ngrakit wadhah docker ternyata luwih murah tinimbang ide kanggo ngemas kabeh dadi paket deb sing kapisah kanthi dependensi, lan nyatane ora ana wong sing waras sing bakal nindakake iki.
Titik kapindho sing arep digunakake Docker yaiku nyebarake layanan nggunakake skema penyebaran biru-ijo. Nanging ing kene aku pengin nambah kerumitan bertahap: pisanan, paket deb dibangun, banjur wadhah docker dibangun saka dheweke.
Paket snap
Ayo bali menyang paket snap. Dheweke pisanan resmi muncul ing Ubuntu 16.04. Ora kaya paket deb biasa lan paket rpm, snap nggawa kabeh dependensi. Ing tangan siji, iki ngidini sampeyan supaya ora konflik perpustakaan, ing tangan liyane, paket asil luwih gedhe ing ukuran. Kajaba iku, iki uga bisa mengaruhi keamanan sistem: ing kasus pangiriman sworo seru, kabeh owah-owahan ing perpustakaan sing kalebu kudu dipantau dening pangembang sing nggawe paket kasebut. Umumé, ora kabeh prasaja lan rasa seneng universal ora teka saka nggunakake. Nanging, iki minangka alternatif sing cukup cukup yen Docker sing padha digunakake mung minangka alat kemasan lan ora kanggo virtualisasi.
Akibaté, saiki kita nggunakake paket deb lan wadhah docker ing kombinasi sing cukup, sing, bisa uga, ing sawetara kasus, kita bakal ngganti karo paket snap.
Mung pangguna pangguna sing bisa melu survey. nggih.
Apa sing sampeyan gunakake kanggo pangiriman?
-
Skrip sing ditulis dhewe
-
Salin kanthi manual menyang FTP
-
paket deb
-
paket rpm
-
paket snap
-
Docker-gambar
-
Gambar mesin virtual
-
Klone kabeh HDD
-
wayang
-
ansible
-
Liyane
109 pangguna milih. 32 pangguna abstain.
Source: www.habr.com