Entah bagaimana pada satu ketika saya memutuskan untuk menulis artikel tentang penghantaran dalam bentuk bekas Docker dan pakej deb, tetapi apabila saya mula, atas sebab tertentu saya dibawa kembali ke masa jauh komputer peribadi pertama dan juga kalkulator. Secara umum, bukannya perbandingan kering docker dan deb, kami mendapat pemikiran ini mengenai topik evolusi, yang saya kemukakan untuk pertimbangan anda.
Mana-mana produk, tidak kira apa itu, mesti entah bagaimana sampai ke pelayan produk, mesti dikonfigurasikan dan dilancarkan. Itulah yang akan dibincangkan oleh artikel ini.
Saya akan berfikir dalam konteks sejarah, "apa yang saya lihat ialah apa yang saya nyanyikan," apa yang saya lihat semasa mula menulis kod dan apa yang saya perhatikan sekarang, apa yang kita sendiri gunakan pada masa ini dan mengapa. Artikel itu tidak berpura-pura sebagai kajian penuh, beberapa perkara terlepas, ini adalah pandangan peribadi saya tentang apa yang dahulu dan sekarang.
Jadi, pada zaman dahulu... kaedah penyampaian terawal yang saya dapati ialah pita kaset daripada perakam pita. Saya mempunyai komputer BK-0010.01...
Zaman kalkulator
Tidak, ada masa yang lebih awal, terdapat juga kalkulator ΠΈ .
Jadi apabila saya telah , maka cara untuk memindahkan atur cara ialah sekeping kertas biasa dalam kotak di mana atur cara ditulis, yang, jika perlu, untuk menjalankannya secara manual, ditulis ke dalam kalkulator. Jika anda ingin bermain (ya, walaupun kalkulator antediluvian ini mempunyai permainan) - anda duduk dan masukkan program ke dalam kalkulator. Sememangnya, apabila kalkulator dimatikan, atur cara itu hilang dalam kelalaian. Sebagai tambahan kepada kod kalkulator yang ditulis secara peribadi di atas kertas, program itu diterbitkan dalam majalah "Radio" dan "Teknologi untuk Belia", dan juga diterbitkan dalam buku pada masa itu.
Pengubahsuaian seterusnya ialah kalkulator , ia sudah mempunyai sedikit kemiripan storan data tidak meruap. Kini permainan atau program tidak perlu dimasukkan secara manual, tetapi selepas melakukan beberapa hantaran ajaib dengan butang, ia dimuatkan sendiri.
Saiz program terbesar dalam kalkulator ialah 105 langkah, dan saiz memori kekal dalam MK-52 ialah 512 langkah.
Ngomong-ngomong, jika ada peminat kalkulator ini yang membaca artikel ini, dalam proses menulis artikel saya menemui kedua-dua emulator kalkulator untuk Android dan program untuknya. Maju ke masa lalu!
Penyimpangan pendek tentang MK-52 (dari Wikipedia)
MK-52 terbang ke angkasa lepas dengan kapal angkasa Soyuz TM-7. Ia sepatutnya digunakan untuk mengira trajektori pendaratan sekiranya komputer di atas kapal gagal.
Sejak 52, MK-1988 dengan unit pengembangan memori Elektronika-Astro telah dibekalkan kepada kapal Tentera Laut sebagai sebahagian daripada kit pengkomputeran navigasi.
Komputer peribadi pertama
Mari kita kembali ke zaman dahulu . Jelas bahawa terdapat lebih banyak memori di sana, dan menaip kod dari sekeping kertas bukan lagi pilihan (walaupun pada mulanya saya melakukan perkara itu, kerana tidak ada medium lain). Kaset audio untuk perakam pita menjadi cara utama untuk menyimpan dan menghantar perisian.
Penyimpanan pada kaset biasanya dalam bentuk satu atau dua fail binari, semua yang lain terkandung di dalamnya. Kebolehpercayaan adalah sangat rendah, saya terpaksa menyimpan 2-3 salinan program. Masa memuatkan juga mengecewakan, dan peminat bereksperimen dengan pengekodan frekuensi yang berbeza untuk mengatasi kelemahan ini. Pada masa itu, saya sendiri belum terlibat dalam pembangunan perisian profesional (belum mengira program mudah dalam BASIC), jadi, malangnya, saya tidak akan memberitahu anda secara terperinci bagaimana semuanya disusun di dalamnya. Hakikat bahawa komputer hanya mempunyai RAM untuk sebahagian besar menentukan kesederhanaan skema penyimpanan data.
Kemunculan media storan yang boleh dipercayai dan besar
Kemudian, cakera liut muncul, proses penyalinan dipermudahkan, dan kebolehpercayaan meningkat.
Tetapi keadaan berubah secara mendadak hanya apabila storan tempatan yang cukup besar muncul dalam bentuk HDD.
Jenis penghantaran secara asasnya berubah: program pemasang muncul yang menguruskan proses mengkonfigurasi sistem, serta membersihkan selepas penyingkiran, kerana program bukan sahaja dibaca ke dalam memori, tetapi sudah disalin ke storan tempatan, yang mana anda perlu dapat membersihkan perkara yang tidak perlu jika perlu.
Pada masa yang sama, kerumitan perisian yang dibekalkan semakin meningkat.
Bilangan fail dalam penghantaran meningkat daripada beberapa kepada ratusan dan beribu-ribu, konflik antara versi perpustakaan dan kegembiraan lain bermula apabila program berbeza menggunakan data yang sama.
Pada masa itu, kewujudan Linux belum lagi terbuka kepada saya; Saya hidup dalam dunia MS DOS dan, kemudian, Windows, dan menulis dalam Borland Pascal dan Delphi, kadang-kadang melihat ke arah C++. Ramai orang menggunakan InstallShield untuk menghantar produk ketika itu. , yang agak berjaya menyelesaikan semua tugas yang diberikan untuk mengatur dan mengkonfigurasi perisian.
era internet
Secara beransur-ansur, kerumitan sistem perisian menjadi lebih kompleks; daripada aplikasi monolit dan desktop terdapat peralihan kepada sistem teragih, klien nipis dan perkhidmatan mikro. Kini anda perlu mengkonfigurasi bukan sahaja satu program, tetapi satu set daripadanya, dan supaya semuanya berfungsi bersama.
Konsepnya berubah sepenuhnya, Internet datang, era perkhidmatan awan tiba. Setakat ini, hanya pada peringkat awal, dalam bentuk laman web, tiada siapa yang sangat mengimpikan perkhidmatan. tetapi ia merupakan titik perubahan dalam kedua-dua pembangunan dan penyampaian aplikasi.
Bagi diri saya sendiri, saya perhatikan bahawa pada masa itu terdapat perubahan dalam generasi pembangun (atau ia hanya dalam persekitaran saya), dan terdapat perasaan bahawa semua kaedah penghantaran lama yang baik telah dilupakan pada satu ketika dan semuanya bermula dari permulaan: semua penghantaran mula dilakukan skrip lutut dan dengan bangganya memanggilnya "Penghantaran berterusan". Sebenarnya, tempoh huru-hara telah bermula, apabila yang lama dilupakan dan tidak digunakan, dan yang baru tidak wujud.
Saya masih ingat ketika di syarikat kami tempat saya bekerja ketika itu (saya tidak akan menyebutnya), dan bukannya membina melalui semut (maven belum lagi popular atau tidak wujud langsung), orang ramai hanya mengumpul balang dalam IDE dan komited dengan tenang ia dalam SVN. Sehubungan itu, penempatan terdiri daripada mendapatkan semula fail daripada SVN dan menyalinnya melalui SSH ke mesin yang dikehendaki. Ia begitu mudah dan kekok.
Pada masa yang sama, penghantaran tapak mudah dalam PHP dilakukan dengan cara yang sangat primitif dengan hanya menyalin fail yang diperbetulkan melalui FTP ke mesin sasaran. Kadang-kadang ini tidak berlaku - kod telah diedit secara langsung pada pelayan produk, dan ia sangat bergaya jika terdapat sandaran di suatu tempat.
Pakej RPM dan DEB
Sebaliknya, dengan perkembangan Internet, sistem seperti UNIX mula mendapat lebih dan lebih popular, khususnya, pada masa itu saya menemui RedHat Linux 6, lebih kurang 2000. Sememangnya, terdapat juga cara tertentu untuk menyampaikan perisian; menurut Wikipedia, RPM sebagai pengurus pakej utama telah muncul pada tahun 1995, dalam versi RedHat Linux 2.0. Dan sejak itu dan sehingga hari ini, sistem ini telah dihantar dalam bentuk pakej RPM dan telah cukup berjaya wujud dan berkembang.
Pengedaran keluarga Debian mengikuti laluan yang sama dan melaksanakan penghantaran dalam bentuk pakej deb, yang kekal tidak berubah sehingga hari ini.
Pengurus pakej membenarkan anda menghantar sendiri produk perisian, mengkonfigurasinya semasa proses pemasangan, mengurus kebergantungan antara pakej yang berbeza, mengalih keluar produk dan membersihkan item yang tidak diperlukan semasa proses nyahpasang. Itu. untuk sebahagian besar, itu sahaja yang diperlukan, itulah sebabnya mereka bertahan beberapa dekad hampir tidak berubah.
Pengkomputeran awan telah menambah pemasangan kepada pengurus pakej bukan sahaja dari media fizikal, tetapi juga dari repositori awan, tetapi pada asasnya sedikit yang berubah.
Perlu diingat bahawa pada masa ini terdapat beberapa langkah ke arah beralih daripada deb dan beralih kepada pakej snap, tetapi lebih lanjut mengenainya kemudian.
Jadi, pembangun awan generasi baharu ini, yang tidak mengetahui DEB mahupun RPM, juga perlahan-lahan berkembang, memperoleh pengalaman, produk menjadi lebih kompleks, dan beberapa kaedah penghantaran yang lebih munasabah diperlukan daripada FTP, skrip bash dan kraf pelajar yang serupa.
Dan di sinilah Docker muncul dalam gambar, sejenis campuran virtualisasi, persempadanan sumber dan kaedah penghantaran. Ia bergaya dan muda sekarang, tetapi adakah ia diperlukan untuk segala-galanya? Adakah ini ubat penawar?
Dari pemerhatian saya, selalunya Docker dicadangkan bukan sebagai pilihan yang munasabah, tetapi semata-mata kerana, di satu pihak, ia diperkatakan dalam masyarakat, dan mereka yang mencadangkannya hanya mengetahuinya. Sebaliknya, sebahagian besar mereka diam tentang sistem pembungkusan lama yang baik - mereka wujud dan melakukan tugas mereka dengan senyap dan tanpa disedari. Dalam keadaan sedemikian, sebenarnya tidak ada pilihan lain - pilihannya jelas - Docker.
Saya akan cuba berkongsi pengalaman saya tentang cara kami melaksanakan Docker dan apa yang berlaku akibatnya.
Skrip tulisan sendiri
Pada mulanya, terdapat skrip bash yang menggunakan arkib balang ke mesin yang diperlukan. Proses ini diuruskan oleh Jenkins. Ini berfungsi dengan jayanya, kerana arkib balang itu sendiri sudah pun menjadi perhimpunan yang mengandungi kelas, sumber dan juga konfigurasi. Jika anda meletakkan segala-galanya ke dalamnya secara maksimum, maka mengembangkannya menjadi skrip bukanlah perkara paling sukar yang anda perlukan
Tetapi skrip mempunyai beberapa kelemahan:
- skrip biasanya ditulis dengan tergesa-gesa dan oleh itu sangat primitif sehingga ia hanya mengandungi satu senario terbaik. Ini difasilitasi oleh fakta bahawa pembangun berminat untuk penghantaran cepat, dan skrip biasa memerlukan pelaburan jumlah sumber yang berpatutan
- akibat daripada perkara sebelumnya, skrip tidak mengandungi prosedur penyahpasangan
- tiada prosedur naik taraf yang ditetapkan
- Apabila produk baharu muncul, anda perlu menulis skrip baharu
- tiada sokongan pergantungan
Sudah tentu, anda boleh menulis skrip yang canggih, tetapi, seperti yang saya tulis di atas, ini adalah masa pembangunan, dan tidak sedikit, dan, seperti yang kita tahu, selalu ada masa yang tidak mencukupi.
Semua ini jelas mengehadkan julat penggunaan kaedah penggunaan ini kepada sistem yang paling mudah sahaja. Masa telah tiba untuk mengubah ini.
buruh pelabuhan
Pada satu ketika, orang tengah yang baru dicetak mula datang kepada kami, membuak-buak dengan idea-idea dan meracau tentang pekerja pelabuhan. Nah, bendera di tangan - mari lakukannya! Terdapat dua percubaan. Kedua-duanya tidak berjaya - katakan, kerana cita-cita yang besar, tetapi kekurangan pengalaman sebenar. Adakah perlu memaksa dan menyelesaikannya dengan apa cara yang mungkin? Tidak mungkin - pasukan mesti berkembang ke tahap yang diperlukan sebelum boleh menggunakan alatan yang sesuai. Di samping itu, apabila menggunakan imej Docker siap pakai, kami sering menghadapi hakikat bahawa rangkaian tidak berfungsi dengan betul (yang mungkin disebabkan oleh kelembapan Docker itu sendiri) atau sukar untuk mengembangkan bekas orang lain.
Apakah kesulitan yang kami hadapi?
- Masalah rangkaian dalam mod jambatan
- Adalah menyusahkan untuk melihat log dalam bekas (jika ia tidak disimpan secara berasingan dalam sistem fail mesin hos)
- ElasticSearch kadang-kadang membeku secara pelik di dalam bekas, sebabnya belum ditentukan, bekas itu rasmi
- Anda perlu menggunakan cangkerang di dalam bekas - semuanya sangat dilucutkan, tiada alat biasa
- Saiz besar bekas terkumpul - mahal untuk disimpan
- Oleh kerana saiz bekas yang besar, sukar untuk menyokong berbilang versi
- Masa binaan yang lebih lama, tidak seperti kaedah lain (skrip atau pakej deb)
Sebaliknya, mengapa lebih teruk untuk menggunakan perkhidmatan Spring dalam bentuk arkib balang melalui deb yang sama? Adakah pengasingan sumber benar-benar perlu? Adakah patut kehilangan alat sistem pengendalian yang mudah dengan memasukkan perkhidmatan ke dalam bekas yang sangat berkurangan?
Seperti yang ditunjukkan oleh amalan, sebenarnya ini tidak perlu, pakej deb cukup dalam 90% kes.
Bilakah deb lama yang baik gagal dan bilakah kita benar-benar memerlukan buruh pelabuhan?
Bagi kami, ini menggunakan perkhidmatan dalam python. Banyak perpustakaan yang diperlukan untuk pembelajaran mesin dan tidak termasuk dalam pengedaran standard sistem pengendalian (dan apa yang terdapat adalah versi yang salah), penggodaman dengan tetapan, keperluan untuk versi berbeza untuk perkhidmatan berbeza yang hidup pada sistem hos yang sama menyebabkan ini , bahawa satu-satunya cara yang munasabah untuk menyampaikan campuran nuklear ini ialah docker. Keamatan buruh memasang bekas buruh pelabuhan ternyata lebih rendah daripada idea untuk membungkus semuanya ke dalam pakej deb berasingan dengan kebergantungan, dan sebenarnya tiada sesiapa yang waras akan melakukan ini.
Perkara kedua di mana kami merancang untuk menggunakan Docker ialah menggunakan perkhidmatan menggunakan skema penggunaan biru-hijau. Tetapi di sini saya ingin mendapatkan peningkatan secara beransur-ansur dalam kerumitan: pertama, pakej deb dibina, dan kemudian bekas docker dibina daripadanya.
Pakej snap
Mari kembali kepada pakej snap. Mereka mula-mula muncul secara rasmi dalam Ubuntu 16.04. Tidak seperti pakej deb dan pakej rpm biasa, snap membawa semua kebergantungan. Di satu pihak, ini membolehkan anda mengelakkan konflik perpustakaan, sebaliknya, pakej yang terhasil adalah saiz yang lebih besar. Di samping itu, ini juga boleh menjejaskan keselamatan sistem: dalam kes penghantaran snap, semua perubahan pada perpustakaan yang disertakan mesti dipantau oleh pembangun yang mencipta pakej. Secara umum, tidak semuanya begitu mudah dan kebahagiaan sejagat tidak datang daripada menggunakannya. Tetapi, bagaimanapun, ini adalah alternatif yang munasabah jika Docker yang sama digunakan hanya sebagai alat pembungkusan dan bukan untuk virtualisasi.
Akibatnya, kami kini menggunakan kedua-dua pakej deb dan bekas docker dalam kombinasi yang munasabah, yang, mungkin, dalam beberapa kes kami akan gantikan dengan pakej snap.
Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. , Sama-sama.
Apa yang anda gunakan untuk penghantaran?
-
Skrip tulisan sendiri
-
Salin secara manual ke FTP
-
pakej deb
-
pakej rpm
-
pakej snap
-
Docker-imej
-
Imej mesin maya
-
Klon keseluruhan HDD
-
boneka
-
ansible
-
Lain-lain
109 pengguna mengundi. 32 pengguna berpantang.
Sumber: www.habr.com