Suatu hari, saya memutuskan untuk menulis artikel tentang pengiriman paket buruh pelabuhan dan deb dalam bentuk wadah, tetapi ketika saya mulai, untuk beberapa alasan saya menderita di hari-hari yang jauh dari komputer pribadi pertama dan bahkan kalkulator. Secara umum, alih-alih perbandingan kering antara buruh pelabuhan dan deb, ini adalah pemikiran tentang evolusi, yang saya sajikan di pengadilan Anda.
Produk apa pun, apa pun itu, entah bagaimana harus sampai ke server produk, harus dikonfigurasi dan diluncurkan. Artikel ini akan membahas tentang ini.
Saya akan merefleksikan dalam konteks sejarah, "apa yang saya lihat - bahwa saya bernyanyi", apa yang saya lihat ketika saya mulai menulis kode dan apa yang saya amati sekarang, apa yang kita sendiri gunakan saat ini dan mengapa. Artikel itu tidak berpura-pura menjadi studi penuh, beberapa poin hilang, ini adalah pandangan pribadi saya tentang apa yang dulu dan apa yang sekarang.
Jadi, di masa lalu yang indah ... metode pengiriman paling awal yang saya temukan adalah dengan kaset. Saya punya komputer BK-0010.01 ...
Zaman Kalkulator
Tidak, ada titik yang lebih awal, ada juga kalkulator
MK-61 dan
MK-52 .
Jadi, ketika saya memiliki
MK-61 , cara untuk mentransfer program adalah dengan menggunakan selembar kertas biasa dalam kotak di mana program dicatat, yang, jika perlu, ditulis secara manual ke kalkulator. Jika Anda ingin bermain (ya, bahkan ada permainan di kalkulator kuno ini), Anda duduk dan masukkan program dalam kalkulator. Tentu saja, ketika kalkulator dimatikan, program dilupakan. Selain kode kalkulator yang ditulis di atas kertas secara pribadi, program-program tersebut diterbitkan di majalah Radio dan Teknik Pemuda, serta dalam buku-buku pada waktu itu.
Modifikasi berikutnya adalah kalkulator
MK-52 , sudah muncul semacam penyimpanan data yang tidak mudah menguap. Sekarang game atau program tidak harus didorong secara manual, tetapi, setelah melakukan beberapa lintasan ajaib dengan tombol, itu dimuat sendiri.
Volume program terbesar di kalkulator adalah 105 langkah, dan ukuran memori permanen di MK-52 adalah 512 langkah.
Omong-omong, jika ada penggemar kalkulator ini yang membaca artikel ini - dalam proses penulisan artikel, saya menemukan emulator kalkulator untuk android dan program untuk itu. Maju ke masa lalu!
Penyimpangan kecil tentang MK-52 (dari Wikipedia)
MK-52 terbang ke angkasa menggunakan pesawat ruang angkasa Soyuz TM-7. Itu seharusnya digunakan untuk menghitung lintasan pendaratan jika komputer on-board gagal.
MK-52 dengan unit ekspansi memori "Electronics-Astro" sejak 1988 dipasok ke kapal Angkatan Laut sebagai bagian dari kit komputasi navigasi.
Komputer pribadi pertama
Mari kita kembali ke zaman
BK-0010 . Jelas bahwa ada lebih banyak memori di sana, dan tidak ada lagi pilihan untuk mendorong kode dari selembar kertas (walaupun pada awalnya saya melakukan hal itu, karena tidak ada media lain). Sarana utama penyimpanan dan pengiriman perangkat lunak adalah kaset audio untuk tape recorder.
Penyimpanan pada kaset biasanya dalam bentuk satu atau dua file biner, semua yang lain ada di dalamnya. Keandalan sangat rendah, saya harus menyimpan 2-3 salinan program. Waktu buka juga tidak menyenangkan, penggemar bereksperimen dengan pengkodean frekuensi yang berbeda untuk mengatasi kekurangan ini. Pada saat itu, saya sendiri belum terlibat dalam pengembangan profesional perangkat lunak (terlepas dari program dasar sederhana), oleh karena itu, sayangnya, saya tidak akan memberi tahu Anda secara terperinci bagaimana semuanya diatur di dalam. Fakta hanya memiliki RAM di komputer untuk sebagian besar menentukan kesederhanaan skema penyimpanan data.
Munculnya media penyimpanan yang besar dan andal
Kemudian, floppy disk muncul, proses penyalinan disederhanakan, dan keandalan tumbuh.
Tetapi situasinya berubah secara dramatis hanya ketika penyimpanan lokal yang cukup besar muncul dalam bentuk HDD.
Jenis pengiriman berubah secara mendasar: muncul penginstal yang mengontrol proses konfigurasi sistem, serta pembersihan setelah penghapusan, karena program tidak hanya dibaca ke dalam memori, tetapi sudah disalin ke penyimpanan lokal, yang darinya Anda harus dapat menghapus dan tidak perlu jika perlu.
Pada saat yang sama, kompleksitas perangkat lunak yang disediakan meningkat.
Jumlah file dalam pengiriman meningkat dari unit menjadi ratusan dan ribuan, konflik versi perpustakaan dan kesenangan lainnya dimulai ketika program yang berbeda menggunakan data yang sama.
Pada masa itu, keberadaan Linux belum terbuka untuk saya, saya tinggal di dunia MS DOS dan, kemudian, Windows, dan menulis di Borland Pascal dan Delphi, terkadang melirik ke arah C ++. Untuk memasok produk pada masa itu, banyak yang menggunakan InstallShield
ru.wikipedia.org/wiki/InstallShield , yang cukup berhasil menyelesaikan semua tugas penggunaan dan konfigurasi perangkat lunak.
Era Internet
Secara bertahap, kompleksitas sistem perangkat lunak menjadi semakin rumit, dari aplikasi monolith dan desktop ada transisi ke sistem terdistribusi, thin client dan layanan mikro. Sekarang Anda perlu mengkonfigurasi tidak hanya satu program, tetapi set mereka, dan agar mereka semua menjadi teman.
Konsepnya telah sepenuhnya berubah, Internet telah datang, era layanan cloud telah datang. Sejauh ini, hanya ditafsirkan pada tahap awal, dalam bentuk situs, tidak ada yang memimpikan layanan. tetapi ini adalah titik balik dalam industri pengembangan dan pengiriman aplikasi yang sebenarnya.
Bagi saya sendiri, saya mencatat bahwa pada saat ini ada perubahan dalam generasi pengembang (atau hanya di lingkungan saya), dan saya merasa bahwa semua metode pengiriman lama yang baik dilupakan pada satu saat dan semuanya dimulai dari awal: mereka mulai membuat seluruh pengiriman dengan skrip setinggi lutut dan dengan bangga menyebutnya "Pengiriman berkelanjutan". Bahkan, periode kekacauan dimulai, ketika yang lama dilupakan dan tidak digunakan, tetapi tidak ada yang baru.
Saya ingat saat-saat ketika di perusahaan kami, di mana saya bekerja saat itu (saya tidak akan menelepon), alih-alih membangun melalui semut (maven belum populer atau tidak sama sekali), orang-orang hanya mengumpulkan stoples dalam IDE dan berkomitmen. dia di svn. Dengan demikian, penyebarannya adalah untuk mendapatkan file dari SVN dan menyalinnya melalui SSH ke mesin yang diinginkan. Sangat sederhana dan canggung.
Pada saat yang sama, pengiriman situs sederhana ke PHP dibuat cukup primitif dengan hanya menyalin file yang diperbaiki melalui FTP ke mesin target. Kadang-kadang tidak ada hal seperti itu - kode diedit langsung di server produk, dan itu sangat menarik jika ada cadangan di suatu tempat.
Paket RPM dan DEB
Di sisi lain, dengan perkembangan Internet, sistem mirip UNIX mulai mendapatkan popularitas yang semakin meningkat, khususnya, pada saat itulah saya menemukan RedHat Linux 6 untuk saya sendiri, sekitar tahun 2000. Secara alami, ada alat tertentu untuk pengiriman perangkat lunak di sana, menurut Wikipedia, RPM sebagai manajer paket utama sudah muncul pada tahun 1995, dalam versi RedHat Linux 2.0. Dan sejak saat itu hingga sekarang, sistem telah dikirim dalam bentuk paket RPM dan cukup berhasil ada dan dikembangkan.
Distribusi keluarga Debian juga melakukan hal serupa dan mengimplementasikan pengiriman dalam bentuk paket deb, yang juga tidak berubah hingga hari ini.
Manajer paket memungkinkan Anda untuk mengirimkan sendiri produk perangkat lunak, mengkonfigurasinya selama proses instalasi, mengelola dependensi antara paket yang berbeda, menghapus produk, dan membersihkan kelebihan selama penghapusan instalasi. Yaitu sebagian besar, inilah yang diperlukan, itulah sebabnya mereka bertahan beberapa dekade dengan sedikit atau tanpa perubahan.
Awan ditambahkan ke instalasi manajer paket tidak hanya dari media fisik, tetapi juga dari repositori cloud, tetapi pada dasarnya sedikit yang berubah.
Perlu dicatat bahwa saat ini ada beberapa creep menuju menghindari deb dan beralih ke paket snap, tetapi lebih pada nanti.
Jadi, generasi baru pengembang cloud ini, yang tidak mengenal DEB atau RPM, juga tumbuh lambat, mendapatkan pengalaman, produk menjadi lebih rumit, dan beberapa metode pengiriman yang lebih masuk akal diperlukan daripada FTP, skrip bash, dan kerajinan siswa serupa.
Dan di sini Docker memasuki lokasi, semacam campuran virtualisasi, alokasi sumber daya, dan metode pengiriman. Sekarang modis, awet muda, tetapi apakah itu diperlukan untuk semuanya? Apakah itu obat mujarab?
Menurut pengamatan saya, sangat sering Docker ditawarkan bukan sebagai pilihan yang masuk akal, tetapi hanya karena itu, di satu sisi, dibicarakan di masyarakat, dan mereka yang menawarkannya hanya mengetahuinya. Di sisi lain, sebagian besar mereka diam tentang sistem pengemasan lama yang baik - mereka sedang dan sedang, mereka melakukan pekerjaan mereka dengan tenang dan tak terlihat. Dalam situasi seperti itu, tidak ada pilihan lain - pilihannya jelas - Docker.
Saya akan mencoba berbagi pengalaman tentang bagaimana kami menerapkan Docker, dan apa yang terjadi sebagai hasilnya.
Skrip yang ditulis sendiri
Awalnya, ada skrip bash yang menyebarkan arsip jar ke mesin yang diperlukan. Dikelola proses ini oleh Jenkins. Ini berhasil, karena arsip jar itu sendiri sudah merupakan kumpulan yang berisi kelas, sumber daya, dan bahkan konfigurasi. Jika Anda meletakkan semuanya di dalamnya secara maksimal - kemudian perluas dengan skrip - ini bukan hal yang paling sulit yang Anda butuhkan
Tetapi skrip memiliki beberapa kelemahan:
- skrip biasanya ditulis dengan tergesa-gesa dan karenanya sangat primitif sehingga hanya berisi satu skrip yang paling sukses. Ini difasilitasi oleh fakta bahwa pengembang tertarik pada pengiriman cepat, dan skrip normal membutuhkan sumber daya yang layak.
- sebagai konsekuensi dari paragraf sebelumnya, skrip tidak mengandung prosedur uninstall
- tidak ada prosedur peningkatan yang ditetapkan
- ketika produk baru muncul, Anda perlu menulis skrip baru
- tidak ada dukungan ketergantungan
Tentu saja, Anda dapat menulis skrip mewah, tetapi, seperti yang saya tulis di atas, ini adalah waktu pengembangan, dan bukan yang terkecil, tetapi, seperti yang Anda tahu, selalu tidak ada cukup waktu.
Ini semua jelas membatasi ruang lingkup metode penyebaran ini ke sistem yang paling sederhana. Waktunya telah tiba untuk mengubah ini.
Docker
Pada titik tertentu, middle yang baru dipanggang mulai mendatangi kami, penuh dengan ide dan mengoceh dengan buruh pelabuhan. Nah, bendera di tangan - lakukanlah! Ada dua upaya. Keduanya tidak berhasil - katakanlah demikian, karena ambisi besar, tetapi kurangnya pengalaman nyata. Apakah perlu untuk memaksa dan menyelesaikan dengan cara apa pun? Tidak mungkin - tim harus secara evolusioner tumbuh ke level yang diinginkan sebelum dapat menggunakan alat yang sesuai. Selain itu, dengan menggunakan gambar-gambar yang sudah jadi dari buruh pelabuhan, kami sering menemukan fakta bahwa jaringan bekerja secara tidak benar di sana (yang, mungkin, juga terhubung dengan kelembaban buruh pelabuhan itu sendiri) atau sulit untuk memperluas wadah orang lain.
Ketidaknyamanan apa yang kami temui?
- Masalah jaringan dalam mode jembatan
- Sangat tidak nyaman untuk melihat log di wadah (jika mereka tidak dibawa ke mana pun secara terpisah ke sistem file dari mesin host)
- ElasticSearch yang aneh secara berkala menggantung di dalam wadah, alasannya belum ditetapkan, wadah itu resmi
- Canggung menggunakan cangkang di dalam wadah - semuanya sangat terpangkas, tidak ada alat yang dikenal
- Wadah besar untuk dikumpulkan - mahal untuk disimpan
- Karena ukuran wadah yang besar, sulit untuk mendukung beberapa versi
- Membangun lebih lama, tidak seperti metode lain (skrip atau paket deb)
Di sisi lain, apakah lebih buruk untuk menggunakan layanan Spring dalam bentuk arsip jar melalui deb yang sama? Apakah isolasi sumber daya benar-benar diperlukan? Apakah layak kehilangan alat yang mudah digunakan dari sistem operasi, memasukkan layanan ke dalam wadah yang sangat terpangkas?
Seperti yang telah ditunjukkan oleh praktik, pada kenyataannya ini tidak perlu, paket deb cukup dalam 90% kasus.
Kapan deb lama yang baik masih gagal dan kapan kita benar-benar membutuhkan buruh pelabuhan?
Bagi kami, ini adalah penyebaran layanan dengan python. Banyak perpustakaan yang diperlukan untuk pembelajaran mesin dan tidak tersedia dalam pengiriman standar sistem operasi (dan apa yang ada dari versi yang salah), peretasan dengan pengaturan, kebutuhan untuk versi berbeda untuk berbagai layanan yang hidup pada sistem host yang sama menyebabkan bahwa satu-satunya cara yang masuk akal untuk memasok campuran nuklir ini adalah buruh pelabuhan. Kompleksitas merakit kontainer buruh pelabuhan ternyata lebih rendah daripada gagasan untuk mengemasnya semua dalam paket deb terpisah dengan dependensi, dan tidak ada orang waras yang akan mengambilnya.
Poin kedua di mana Anda berencana untuk menggunakan buruh pelabuhan adalah untuk menggunakan layanan menggunakan skema penyebaran biru-hijau. Tapi di sini saya ingin mendapatkan peningkatan kompleksitas secara bertahap: pertama, paket deb dikumpulkan, dan kemudian sebuah buruh pelabuhan dikumpulkan dari mereka.
Paket snap
Kembali ke paket snap. Mereka pertama kali secara resmi muncul di Ubuntu 16.04. Berbeda dengan paket deb dan paket rpm biasa, snap membawa semua dependensi. Di satu sisi, ini menghindari konflik perpustakaan, di sisi lain, itu berarti ukuran yang lebih signifikan dari paket yang dihasilkan. Selain itu, hal yang sama dapat mempengaruhi keamanan sistem: dalam hal pengiriman cepat, semua perubahan pada perpustakaan yang disertakan harus dipantau oleh pengembang yang membuat paket. Secara umum, tidak semuanya begitu sederhana dan kebahagiaan umum dari penggunaannya tidak datang. Namun, bagaimanapun, ini adalah alternatif yang cukup masuk akal, jika Docker yang sama hanya digunakan sebagai alat pengemasan, dan bukan virtualisasi.
Sebagai hasilnya, kami sekarang menggunakan paket deb dan buruh pelabuhan dalam kombinasi yang masuk akal, yang, mungkin, dalam beberapa kasus kami akan mengganti dengan paket snap.