Entah bagaimana pada suatu saat saya memutuskan untuk menulis artikel tentang pengiriman dalam bentuk kontainer Docker dan paket deb, tetapi ketika saya memulai, karena alasan tertentu saya dibawa kembali ke masa komputer pribadi pertama dan bahkan kalkulator. Secara umum, alih-alih perbandingan kering antara buruh pelabuhan dan deb, kami mendapatkan pemikiran tentang topik evolusi, yang saya sajikan untuk pertimbangan Anda.
Produk apa pun, apa pun itu, harus sampai ke server produk, harus dikonfigurasi dan diluncurkan. Itulah inti artikel ini.
Saya akan berpikir dalam konteks sejarah, “apa yang saya lihat adalah apa yang saya nyanyikan”, apa yang saya lihat ketika saya pertama kali mulai menulis kode dan apa yang saya amati sekarang, apa yang kami gunakan saat ini dan mengapa. Artikel ini tidak berpura-pura menjadi studi yang lengkap, beberapa poin terlewatkan, ini adalah pandangan pribadi saya tentang apa yang dulu dan apa yang sekarang.
Jadi, di masa lalu... metode pengiriman paling awal yang saya temukan adalah kaset dari tape recorder. Saya memiliki komputer BK-0010.01...
Era kalkulator
Tidak, ada momen yang lebih awal, ada juga kalkulator и .
Jadi ketika saya punya , maka cara mentransfer program tersebut adalah dengan selembar kertas biasa di dalam kotak yang di atasnya tertulis suatu program, yang bila perlu dijalankan secara manual, dituliskan ke dalam kalkulator. Jika Anda ingin bermain (ya, bahkan kalkulator kuno ini pun memiliki permainan) - Anda duduk dan memasukkan program ke dalam kalkulator. Secara alami, ketika kalkulator dimatikan, program tersebut menghilang dan terlupakan. Selain kode kalkulator yang ditulis di atas kertas dengan tangannya sendiri, program tersebut juga diterbitkan di majalah “Radio” dan “Technology for Youth”, dan juga diterbitkan dalam buku-buku pada waktu itu.
Modifikasi selanjutnya adalah kalkulator , ia sudah memiliki semacam penyimpanan data non-volatil. Sekarang permainan atau program tidak harus dimasukkan secara manual, tetapi setelah melakukan beberapa gerakan ajaib dengan tombol, permainan atau program itu dimuat sendiri.
Ukuran program terbesar di kalkulator adalah 105 langkah, dan ukuran memori permanen di MK-52 adalah 512 langkah.
Omong-omong, jika ada penggemar kalkulator yang membaca artikel ini, dalam proses penulisan artikel saya menemukan emulator kalkulator untuk Android dan program untuk itu. Maju ke masa lalu!
Penyimpangan singkat tentang MK-52 (dari Wikipedia)
MK-52 terbang ke luar angkasa dengan pesawat ruang angkasa Soyuz TM-7. Itu seharusnya digunakan untuk menghitung lintasan pendaratan jika komputer di dalam pesawat gagal.
Sejak tahun 52, MK-1988 dengan unit ekspansi memori Elektronika-Astro telah dipasok ke kapal Angkatan Laut sebagai bagian dari kit komputasi navigasi.
Komputer pribadi pertama
Mari kita kembali ke masa . Jelas bahwa ada lebih banyak memori di sana, dan mengetik kode dari selembar kertas tidak lagi menjadi pilihan (walaupun pada awalnya saya melakukan hal itu, karena tidak ada media lain). Kaset audio untuk tape recorder menjadi sarana utama untuk menyimpan dan mengirimkan perangkat lunak.
Penyimpanan dalam kaset biasanya dalam bentuk satu atau dua file biner, yang lainnya ada di dalamnya. Keandalannya sangat rendah, saya harus menyimpan 2-3 salinan program. Waktu pemuatan juga mengecewakan, dan para penggemar bereksperimen dengan pengkodean frekuensi yang berbeda untuk mengatasi kekurangan ini. Saat itu, saya sendiri belum terlibat dalam pengembangan perangkat lunak profesional (tidak termasuk program sederhana di BASIC), jadi sayangnya saya tidak akan memberi tahu Anda secara detail bagaimana segala sesuatunya diatur di dalamnya. Fakta bahwa sebagian besar komputer hanya memiliki RAM menentukan kesederhanaan skema penyimpanan data.
Munculnya media penyimpanan yang handal dan besar
Belakangan, floppy disk muncul, proses penyalinan disederhanakan, dan keandalan meningkat.
Namun situasinya berubah secara dramatis hanya ketika penyimpanan lokal yang cukup besar muncul dalam bentuk HDD.
Jenis pengiriman berubah secara mendasar: muncul program penginstal yang mengelola proses konfigurasi sistem, serta pembersihan setelah penghapusan, karena program tidak hanya dibaca ke dalam memori, tetapi sudah disalin ke penyimpanan lokal, dari mana Anda perlu melakukannya dapat menghapus hal-hal yang tidak perlu jika perlu.
Pada saat yang sama, kompleksitas perangkat lunak yang disediakan semakin meningkat.
Jumlah file dalam pengiriman meningkat dari beberapa menjadi ratusan dan ribuan, konflik antara versi perpustakaan dan kesenangan lainnya dimulai ketika program yang berbeda menggunakan data yang sama.
Pada saat itu, keberadaan Linux belum terbuka bagi saya; saya hidup di dunia MS DOS dan, kemudian, Windows, dan menulis dalam Borland Pascal dan Delphi, terkadang mencari ke arah C++. Banyak orang menggunakan InstallShield untuk mengirimkan produk saat itu. , yang cukup berhasil menyelesaikan semua tugas yang diberikan untuk menyebarkan dan mengkonfigurasi perangkat lunak.
zaman internet
Secara bertahap, kompleksitas sistem perangkat lunak menjadi semakin kompleks; dari aplikasi monolit dan desktop terdapat transisi ke sistem terdistribusi, klien tipis, dan layanan mikro. Sekarang Anda perlu mengkonfigurasi tidak hanya satu program, tetapi satu set program, sehingga semuanya bekerja sama.
Konsepnya berubah total, Internet hadir, era layanan cloud pun tiba. Sejauh ini, baru pada tahap awal, berupa website, belum ada yang memimpikan layanan secara khusus. tapi ini merupakan titik balik dalam pengembangan dan pengiriman aplikasi.
Bagi saya sendiri, saya mencatat bahwa pada saat itu ada perubahan generasi pengembang (atau hanya di lingkungan saya), dan ada perasaan bahwa semua metode pengiriman lama yang baik dilupakan pada suatu saat dan semuanya dimulai dari awal. awal: semua pengiriman mulai dilakukan dengan skrip lutut dan dengan bangga menyebutnya “Pengiriman berkelanjutan”. Faktanya, masa kekacauan telah dimulai, ketika yang lama dilupakan dan tidak digunakan, dan yang baru tidak ada.
Saya ingat saat-saat ketika di perusahaan tempat saya bekerja (saya tidak akan menyebutkan namanya), alih-alih membangun melalui semut (maven belum populer atau tidak ada sama sekali), orang-orang hanya mengumpulkan toples di IDE dan dengan tenang berkomitmen itu di SVN. Oleh karena itu, penerapan terdiri dari mengambil file dari SVN dan menyalinnya melalui SSH ke mesin yang diinginkan. Ini sangat sederhana dan canggung.
Pada saat yang sama, pengiriman situs sederhana dalam PHP dilakukan dengan cara yang sangat primitif hanya dengan menyalin file yang dikoreksi melalui FTP ke mesin target. Terkadang hal ini tidak terjadi - kode diedit langsung di server produk, dan akan sangat berguna jika ada cadangan di suatu tempat.
Paket RPM dan DEB
Di sisi lain, dengan berkembangnya Internet, sistem mirip UNIX mulai mendapatkan popularitas, khususnya, pada saat itulah saya menemukan RedHat Linux 6, sekitar tahun 2000. Tentu saja, ada juga cara tertentu untuk mengirimkan perangkat lunak; menurut Wikipedia, RPM sebagai pengelola paket utama sudah muncul pada tahun 1995, dalam versi RedHat Linux 2.0. Dan sejak saat itu hingga saat ini, sistem tersebut hadir dalam bentuk paket RPM dan cukup berhasil eksis dan berkembang.
Distribusi keluarga Debian mengikuti jalur yang sama dan mengimplementasikan pengiriman dalam bentuk paket deb, yang tidak berubah hingga hari ini.
Manajer paket memungkinkan Anda mengirimkan sendiri produk perangkat lunak, mengkonfigurasinya selama proses instalasi, mengelola ketergantungan antara paket yang berbeda, menghapus produk dan membersihkan item yang tidak diperlukan selama proses penghapusan instalasi. Itu. pada umumnya, hanya itu yang diperlukan, itulah sebabnya mengapa hal tersebut bertahan selama beberapa dekade dan hampir tidak berubah.
Komputasi awan telah menambahkan instalasi ke pengelola paket tidak hanya dari media fisik, tetapi juga dari repositori cloud, namun pada dasarnya hanya sedikit yang berubah.
Perlu dicatat bahwa saat ini ada beberapa langkah untuk beralih dari deb dan beralih ke paket snap, tetapi akan dibahas lebih lanjut nanti.
Jadi, pengembang cloud generasi baru ini, yang tidak mengetahui DEB maupun RPM, juga perlahan tumbuh, memperoleh pengalaman, produk menjadi lebih kompleks, dan diperlukan beberapa metode pengiriman yang lebih masuk akal daripada FTP, skrip bash, dan kerajinan siswa serupa.
Dan di sinilah Docker muncul, semacam campuran virtualisasi, pembatasan sumber daya, dan metode pengiriman. Sekarang modis dan berjiwa muda, tetapi apakah diperlukan untuk segala hal? Apakah ini obat mujarab?
Dari pengamatan saya, seringkali Docker diusulkan bukan sebagai pilihan yang masuk akal, tetapi hanya karena, di satu sisi, Docker dibicarakan di komunitas, dan mereka yang mengusulkannya hanya mengetahuinya. Di sisi lain, sebagian besar mereka diam tentang sistem pengemasan lama yang bagus - mereka ada dan melakukan tugasnya dengan tenang dan tanpa disadari. Dalam situasi seperti ini, sebenarnya tidak ada pilihan lain - pilihannya jelas - Docker.
Saya akan mencoba berbagi pengalaman saya tentang bagaimana kami mengimplementasikan Docker dan apa yang terjadi sebagai hasilnya.
Naskah yang ditulis sendiri
Awalnya, ada skrip bash yang menyebarkan arsip jar ke mesin yang diperlukan. Proses ini dikelola oleh Jenkins. Ini berhasil, karena arsip jar itu sendiri sudah merupakan rakitan yang berisi kelas, sumber daya, dan bahkan konfigurasi. Jika Anda memasukkan semuanya ke dalamnya secara maksimal, maka mengembangkannya menjadi sebuah skrip bukanlah hal tersulit yang Anda perlukan
Namun skrip memiliki beberapa kelemahan:
- skrip biasanya ditulis dengan tergesa-gesa dan oleh karena itu sangat primitif sehingga hanya berisi satu skenario terbaik. Hal ini difasilitasi oleh fakta bahwa pengembang tertarik pada pengiriman yang cepat, dan skrip normal memerlukan investasi sumber daya dalam jumlah yang layak.
- sebagai konsekuensi dari poin sebelumnya, skrip tidak berisi prosedur penghapusan instalasi
- 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 yang canggih, tetapi, seperti yang saya tulis di atas, ini adalah waktu pengembangan, dan, seperti yang kita ketahui, waktu selalu tidak cukup.
Semua ini jelas membatasi jangkauan penerapan metode penerapan ini hanya pada sistem yang paling sederhana. Waktunya telah tiba untuk mengubah hal ini.
Buruh pelabuhan
Pada titik tertentu, perusahaan-perusahaan baru mulai berdatangan kepada kami, dipenuhi dengan ide-ide dan mengoceh tentang buruh pelabuhan. Baiklah, bendera di tangan - ayo kita lakukan! Ada dua upaya. Keduanya tidak berhasil - katakanlah, karena ambisi yang besar, tetapi kurangnya pengalaman nyata. Apakah perlu untuk memaksanya dan menyelesaikannya dengan cara apa pun? Hal ini tidak mungkin terjadi - tim harus berevolusi ke tingkat yang diperlukan sebelum dapat menggunakan alat yang sesuai. Selain itu, saat menggunakan image Docker yang sudah jadi, kami sering menghadapi kenyataan bahwa jaringan tidak berfungsi dengan benar (yang mungkin disebabkan oleh kelembapan Docker itu sendiri) atau sulitnya memperluas container orang lain.
Ketidaknyamanan apa yang kami temui?
- Masalah jaringan dalam mode jembatan
- Tidak nyaman untuk melihat log dalam wadah (jika tidak disimpan secara terpisah di sistem file mesin host)
- ElasticSearch terkadang membeku secara aneh di dalam container, alasannya belum ditentukan, container tersebut resmi
- Penting untuk menggunakan cangkang di dalam wadah - semuanya sangat dipreteli, tidak ada alat biasa
- Wadah rakitan berukuran besar - mahal untuk disimpan
- Karena ukuran container yang besar, sulit untuk mendukung banyak versi
- Waktu pembuatan lebih lama, tidak seperti metode lain (skrip atau paket deb)
Di sisi lain, mengapa lebih buruk menerapkan layanan Spring dalam bentuk arsip jar melalui deb yang sama? Apakah isolasi sumber daya benar-benar diperlukan? Apakah layak kehilangan alat sistem operasi yang mudah digunakan dengan memasukkan layanan ke dalam wadah yang sangat berkurang?
Seperti yang telah ditunjukkan oleh praktik, pada kenyataannya hal ini tidak perlu, paket deb sudah cukup di 90% kasus.
Kapan deb lama yang bagus gagal dan kapan kita benar-benar membutuhkan buruh pelabuhan?
Bagi kami, ini adalah penerapan layanan dengan python. Banyak perpustakaan yang diperlukan untuk pembelajaran mesin dan tidak termasuk dalam distribusi standar sistem operasi (dan apa yang ada adalah versi yang salah), peretasan dengan pengaturan, kebutuhan akan versi berbeda untuk layanan berbeda yang hidup di sistem host yang sama menyebabkan ini, bahwa satu-satunya cara yang masuk akal untuk memasok campuran nuklir ini adalah dengan buruh pelabuhan. Intensitas tenaga kerja untuk merakit container buruh pelabuhan ternyata lebih rendah daripada gagasan untuk mengemas semuanya ke dalam paket deb terpisah dengan dependensi, dan pada kenyataannya tidak ada orang waras yang akan melakukan hal ini.
Poin kedua di mana kami berencana menggunakan Docker adalah menerapkan layanan menggunakan skema penerapan biru-hijau. Namun di sini saya ingin mendapatkan peningkatan kompleksitas secara bertahap: pertama, paket deb dibuat, dan kemudian wadah buruh pelabuhan dibuat dari paket tersebut.
Paket jepret
Mari 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 memungkinkan Anda menghindari konflik perpustakaan, di sisi lain, paket yang dihasilkan berukuran lebih besar. Selain itu, hal ini juga dapat mempengaruhi keamanan sistem: dalam kasus pengiriman snap, semua perubahan pada perpustakaan yang disertakan harus dipantau oleh pengembang yang membuat paket. Secara umum, tidak semuanya sesederhana itu dan kebahagiaan universal tidak datang dari penggunaannya. Namun, ini adalah alternatif yang cukup masuk akal jika Docker yang sama hanya digunakan sebagai alat pengemasan dan bukan untuk virtualisasi.
Hasilnya, kami sekarang menggunakan paket deb dan kontainer buruh pelabuhan dalam kombinasi yang wajar, yang mungkin dalam beberapa kasus akan kami ganti dengan paket snap.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Apa yang Anda gunakan untuk pengiriman?
-
Naskah yang ditulis sendiri
-
Salin secara manual ke FTP
-
paket deb
-
paket rpm
-
paket jepret
-
Gambar Docker
-
Gambar mesin virtual
-
Kloning seluruh HDD
-
wayang
-
ansible
-
Lain
109 pengguna memilih. 32 pengguna abstain.
Sumber: www.habr.com