Apakah ada kekurangan menggunakan paket deb seolah-olah itu adalah wadah untuk menyebarkan aplikasi?

Tim saya saat ini mencoba untuk memutuskan apakah kami harus menggunakan aplikasi Nodejs kami sebagai paket deb alih-alih mencoba menjalankannya dalam wadah seperti Docker.

Saya mendapat ide ini dari membaca blog ini di sini yang membuat beberapa argumen bagus untuk menggunakan paket deb untuk aplikasi python yang sudah ada sebelumnya. Poin utama dari blog ini yang menarik bagi kami adalah masalah menjaga ekosistem Docker (berbagi port, izin, hosting Gambar Docker, dll.)

Sepertinya "paket-dep sebagai wadah asli" masuk akal untuk layanan kecil di mana tidak ada masalah konflik pelabuhan dan di mana semua dependensi dipertahankan dalam lingkungan virtual.

Namun, naluriku mengatakan bahwa jika paket deb cocok, itu akan lebih umum dan buruh pelabuhan akan diiklankan sebagai solusi yang lebih spesifik untuk bahasa. Apakah ada kelemahan menggunakan sesuatu seperti paket deb untuk menyebarkan layanan kami, daripada menggunakan sistem lengkap seperti buruh pelabuhan?

Pertama, sementara Docker kadang-kadang dilihat dan digunakan sebagai sistem pengemasan ad hoc , itu sebenarnya memecahkan masalah yang sama sekali berbeda: Docker adalah tentang menjalankan program. Sistem Docker memungkinkan untuk menggambarkan layanan, yang dapat ditingkatkan sesuai keinginan dan untuk mengendalikan gerombolan kontainer. Paket Debian adalah untuk menginstal program dan mereka dapat menangani dependensi antara versi perangkat lunak. Buruh pelabuhan tentu saja tidak memenuhi syarat sebagai sistem pengemasan keturunan: setiap "paket" hanya dapat memiliki satu ketergantungan, sistem tidak memiliki opsi "rekursif membangun" dan tidak mendukung batasan versi yang rumit!

Jawaban yang mungkin adalah bahwa, jika Anda ingin menulis paket Debian untuk aplikasi Anda, Anda juga dapat menggunakan Docker untuk menggunakan aplikasi Anda. Ini dapat dicapai dengan skrip konfigurasi apt_setup.shyang akan terlihat seperti

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

dan Dockerfilesepanjang garis

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Dalam situasi spesifik Anda, apt_setup.shakan lebih rumit, menambahkan repositori nodesource dan beberapa paket pembantu seperti apt-transport-https .)

Oleh karena itu sangat mungkin untuk menggunakan paket Debian dan Docker secara bersamaan, namun ...

Naluri saya [...] memberi tahu saya bahwa jika paket deb cocok, itu akan lebih umum

Ini adalah halangan yang benar yang membuat kita bertanya pada diri sendiri mengapa Docker terbukti populer sebagai sistem pengemasan ad hoc , sementara itu tidak dimaksudkan untuk menjadi satu. (Lihat di atas.)

Sistem pengemasan "resmi" dari distribusi yang diberikan hanyalah kemungkinan di antara banyak lainnya untuk menginstal perangkat lunak di beberapa lingkungan komputasi. Ada banyak sumber lain yang tersedia, seperti pengelola paket khusus komunitas seperti npm atau opam, pohon port seperti pkgsrc dan distribusi kode sumber biasa. Dari perspektif ini, mudah untuk memahami keberhasilan Docker sebagai sistem pengemasan ad hoc :

• Spesifikasi Docker sangat dekat dari skrip shell dan sumber apa pun asalnya, kami memasang perangkat lunak menggunakan shell.

• Docker memiliki layanan "bayar" untuk hosting artefak yang dihasilkannya, Docker Hub .

Sekarang apa kekuatan paket Debian di atas gambar Docker sebagai sistem paket? Kontrol ketat atas dependensi saat instalasi. (Kemungkinan untuk meningkatkan dan menurunkan versi juga ada tetapi tidak memiliki kepentingan praktis jika kita menerapkan pola server yang tidak dapat diubah .) Hal ini mengarah pada

Kesimpulan

Jika Anda hanya memiliki satu produk yang digunakan dalam satu versi (yang tipikal untuk SaaS), kebutuhan manajemen versi Anda sangat sederhana dan menggunakan Docker sebagai pengelola paket ad hoc seharusnya tidak memiliki kelemahan yang sulit. Segera setelah Anda bekerja dengan beberapa versi dari satu produk atau beberapa produk, kompleksitas masalah kendala versi yang Anda butuhkan untuk menyelesaikan peningkatan dan Anda memerlukan alat yang sesuai untuk ini, yang mungkin berupa paket Debian atau beberapa sistem manajemen konfigurasi jika Anda menginginkannya. pencampuran perangkat lunak dari asal yang berbeda.

Ya, ada kekurangannya.

Dengan paket deb. Anda tidak akan dapat memiliki dua versi aplikasi yang sama di host yang sama. Anda harus mengandalkan paket distribusi yang tersedia, jika aplikasi Anda mengandalkan nodejs misalnya, Anda akan terjebak dengan versi distribusi atau Anda harus menginstal sendiri.

Sekarang ketika Anda ingin meng-host beberapa aplikasi pada host yang sama, Anda akan menabrak dinding dengan sangat cepat ketika mereka bergantung pada hal yang sama (mari kita simpan nodejs di sini) dalam dua versi berbeda.

Tujuan utama buruh pelabuhan adalah untuk mengisolasi setiap aplikasi dari sistem hosting dan aplikasi lain pada host yang sama. ada dua alasan untuk melakukan isolasi ini: 1. untuk menghindari kompromi dari aplikasi untuk dapat mengambil alih host atau mempengaruhi aplikasi lain 2. untuk memberikan aplikasi dependensi yang tepat dan mencegahnya terkena dampak dari pembaruan sistem atau aplikasi lain ketergantungan.

Paket Debian (atau RedHat) untuk menginstal aplikasi telah menjadi praktik yang baik bila dilakukan dengan benar. Paket digunakan untuk tujuan menyebarkan aplikasi yang jarang diubah. Paket Debian melibatkan beberapa overhead, seperti manajemen versi, manajemen dependensi, skrip pra & pasca-instal, dll ...

Dalam banyak kasus, pemutakhiran dari beberapa versi yang lebih lama ke versi yang baru memerlukan penulisan skrip yang cermat, perhatian pada perincian dalam versi, dll. Karena mengubah keadaan yang ada sulit. Akan jauh lebih mudah untuk mengganti keadaan saat ini sama sekali dengan keadaan baru, tanpa mengubah apa pun.

Setelah Anda memutuskan untuk sepenuhnya mengganti konfigurasi atau dependensi atau aplikasi Anda pada setiap penyebaran karena lebih mudah dan lebih sedikit kesalahan rawan. Sebagian besar organisasi (dulu) beralih ke VM baru atau instance cloud. Yang berarti menginstal paket akan dilakukan pada server "bersih", dan memutasi file dan konfigurasi pada server tidak menjadi masalah lagi.

Pengembang yang membuat paket dan tidak memahami kesalahan dan kompleksitas mutasi menderita banyak kesulitan sebagai akibatnya.

Mengganti VM tidak optimal ketika yang Anda butuhkan hanyalah mengganti aplikasi, itulah sebabnya wadah ringan diperkenalkan sebagai jawaban. Menggunakan Docker (atau LWC lainnya) Anda dapat mengganti basis pengguna, termasuk semua dependensi, tanpa mengganti server itu sendiri. Anda juga dapat meng-host beberapa versi aplikasi yang sama, dengan dependensi berbeda, pada server yang sama dan hanya mengalihkan lalu lintas jaringan yang masuk saat pemutakhiran. Serta mengalihkan lalu lintas jaringan kembali pada rollback (biru-hijau), sesuatu yang sangat sulit dalam hal mengelola penyebaran melalui paket.

Kontainer memperkenalkan cara untuk menggabungkan semua kode aplikasi, dan dependensi, dan konfigurasi, ke dalam gambar. Gambar ini memiliki beberapa properti yang membuatnya jauh lebih baik daripada paket sistem operasi tradisional. Misalnya, ia memiliki tag yang memungkinkan versi, tetapi juga memiliki lapisan, yang memungkinkan untuk menghemat ruang. Ini memungkinkan cara mudah untuk mengirimkan gambar-gambar ini ke server, dan lingkungan pengembangan, dengan menggunakan registri. Dan gambar-gambar ini dapat dieksekusi sebagai wadah di lingkungan dan server apa saja, hampir identik. Ini termasuk laptop pengembang serta lingkungan produksi. Sekali lagi, sesuatu yang jauh lebih sulit dilakukan dengan VM dan / atau dengan versi perangkat lunak berbasis paket. Memiliki gambar yang sama diuji pada laptop pengembang, dan tetap dengan bit dan byte yang sama dalam produksi menghilangkan banyak "

Berbicara secara khusus tentang potongan kemasan gambar Docker, bukan runtime wadah ada beberapa bit kecil. Yang terbesar adalah bahwa gambar Docker lebih seperti chroot, yang berarti Anda dicegah dari tidak sengaja tergantung pada status sistem bersama karena setiap file yang digunakan harus secara eksplisit dimasukkan dalam gambar sementara paket sistem mungkin mengambil tautan dinamis yang tidak Anda lakukan. mengharapkan atau mendapatkan lebih banyak yang terkait dengan paket lain. Ini dapat muncul dengan dependensi C kompleks yang dimuat tanpa sepengetahuan Anda, misalnya OpenSSL. Selain itu menggunakan paket deb tidak menduplikasi duplikat bit bersama di sistem penyimpanan Docker. Untuk beberapa hal ini mungkin hal yang baik, kinerja I / O yang lebih baik dan lebih sedikit bagian yang bergerak, tetapi untuk yang lain mungkin menjadi masalah.