Apakah Docker tepat untuk kasus penggunaan saya?

Perusahaan saya memiliki sistem yang kami jual yang pada dasarnya terdiri dari komputer mini "Smartbox" yang menjalankan Ubuntu 12.04. Kotak ini menjalankan aplikasi Django plus sejumlah proses pemula yang berbeda yang terkait dengannya. Tidak banyak lagi. Kami memiliki ribuan kotak ini di lapangan. Kami mengelola dependensi paket, proses pendaftaran, dll. Melalui paket deb dengan berbagai tingkat keberhasilan.

Kami membutuhkan cara untuk mendorong pembaruan secara efisien dan kokoh kepada pengguna kami di lapangan. Kami juga memerlukan sesuatu yang saat kami meningkatkan OS (kami sangat terlambat untuk upgrade Ubuntu seperti yang Anda tahu), kami dapat merasa relatif aman tentang paket kami "hanya berfungsi".

Saya tidak tahu banyak tentang Docker, tetapi ketika saya pertama kali mendengar tentang masalah kami (saya adalah karyawan baru), Docker adalah pikiran pertama saya. Tetapi semakin saya memikirkannya, saya merasa mungkin tidak, karena kotak-kotak ini adalah milik kami, kami mengendalikan OS yang merupakan bagian besar dari nilai proposisi Docker, atau lebih tepatnya saya mengerti. Jadi jika kita TAHU kotak kita akan selalu Ubuntu dan pada dasarnya kita hanya memiliki aplikasi Django ditambah beberapa proses untuk dijalankan, apakah Docker lebih baik daripada paket deb?

TL; DR: Paket Docker vs deb untuk alat terdistribusi yang akan selalu menjalankan Ubuntu sehingga independensi platform tidak terlalu penting.

Saya tidak 100% yakin saya mengerti dari pertanyaan, tetapi sepertinya solusi Docker adalah beralih dari memiliki alat (fisik?) Dengan OS dan aplikasi Anda diinstal di atasnya, untuk memiliki alat dengan OS dan Docker di atasnya, menjalankan satu wadah dengan aplikasi Anda di dalamnya. Itu tidak meniadakan kebutuhan untuk memperbarui OS di host, dan itu menambah lapisan kompleksitas (dan lebih banyak pembaruan untuk bersaing, karena Anda sekarang harus menyimpan Docker dan OS ditambal) tanpa manfaat yang sudah jelas terlihat. sejauh menyangkut bidang-bidang spesifik yang disebutkan dalam pertanyaan.

Namun, jika Anda berbicara tentang beralih dari alat virtual ke wadah Docker, itu bisa berpotensi memperlancar Anda, tetapi itu juga menambahkan Docker sebagai ketergantungan untuk produk Anda; Anda menutup siapa pun yang tidak menggunakan Docker dan tidak ingin menambahkannya ke tumpukan mereka hanya untuk menggunakan produk Anda. Anda dapat terus mendukung mereka yang tidak / tidak akan menggunakan Docker dengan terus mengirimkan alat virtual (sekarang "lawas") seperti sebelumnya, tetapi sekarang Anda baru saja menggandakan beban kerja Anda karena Anda memiliki dua distribusi untuk didukung alih-alih satu.

Saya sudah lama bekerja dengan Docker. Independensi platform bagus, tapi itu bukan yang saya anggap paling berguna tentang Docker.

Pertama dan terpenting, Anda mendapatkan pengulangan. Anda dapat membuat Dockerfile, debug dalam wadah di mesin pengembang Anda, menjalankan tes pada server integrasi berkelanjutan, dan kemudian di produk akhir Anda, dan Anda tahu itu akan berperilaku sama di semua lingkungan itu. Tidak lupa ketergantungan yang dipasang pengembang pada mesin mereka. Selain itu, pengembang Anda tidak harus menggunakan Ubuntu di meja mereka. Penting untuk membuat kami pengguna Arch Linux senang :-)

Kedua, untuk skenario peningkatan Anda, Anda dapat menarik beberapa versi sekaligus ke mesin. Jika Anda menjalankan docker pull myapp:2.0sementara waktu 1.0, Anda dapat bertukar dengan 2.0sangat cepat. Jauh lebih cepat daripada melakukan upgrade OS penuh biasanya. Jika Anda menggunakan orkestrator dengan beberapa contoh layanan microser, Anda bahkan dapat melakukan peningkatan yang tidak mengganggu layanan sama sekali.

Jika Anda menggunakan model layanan Microsoft, Docker juga menyediakan kotak pasir yang dapat membatasi jumlah kerusakan yang dapat dilakukan penyerang jika terjadi eksploitasi. Alih-alih mendapatkan kontrol atas seluruh mesin, mereka hanya mendapatkan kontrol atas satu kontainer.

Kelemahan utama adalah Anda membutuhkan OS host dan semacam orkestrasi. Ada banyak pilihan untuk itu, tetapi jangan meremehkan jumlah pekerjaan yang diperlukan untuk mengevaluasinya, letakkan, dan pertahankan.

Pada umumnya buruh pelabuhan yang besar memberikan banyak keuntungan bagi pengembang dan personel operasi. Saya menggunakan buruh pelabuhan untuk beberapa aplikasi saya dan menganggapnya sebagai pendekatan yang sangat andal dan kuat.

Masalah saya dengan Anda mengadopsi buruh pelabuhan adalah bahwa saya tidak mendengar Anda mengajukan pertanyaan yang tepat dan Anda berpotensi membuat hidup Anda lebih rumit tanpa memenuhi persyaratan Anda yang paling penting.

Pertanyaan pertama yang harus Anda tanyakan (Anda mengatakan bahwa Anda masih baru) adalah bagaimana pembaruan untuk OS & aplikasi ditangani sekarang? Apakah metodologi saat ini bekerja untuk Anda (perusahaan Anda)? Apa yang berhasil? Apa yang bisa diperbaiki? Dapatkah Anda melakukan audit konfigurasi fisik pada mesin target Anda di lapangan untuk memverifikasi bahwa mereka memiliki patch OS yang benar, aplikasi & apakah ada perubahan yang tidak sah.

Saya suka buruh pelabuhan, tetapi saya tidak akan melompat pada kereta buruh pelabuhan tanpa terlebih dahulu menilai di mana Anda berada sekarang termasuk apa yang berfungsi dengan baik dan apa yang perlu ditingkatkan.

Meskipun ada beberapa wilayah kecil yang tumpang tindih Docker dan sistem pengemasan Debian pada dasarnya menyelesaikan dua masalah yang sangat berbeda :

• Sistem pengemasan Debian dibuat untuk menginstal perangkat lunak pada host dan memutakhirkannya semudah mungkin. Ia mampu menangani pola ketergantungan dan kendala kompleks antara komponen perangkat lunak, seperti "perangkat lunak X versi A membutuhkan perangkat lunak Y dengan versi B atau yang lebih baru diinstal" atau "perangkat lunak X tidak boleh diinstal dengan perangkat lunak Z versi C".

• Sistem Docker dirancang untuk dengan mudah menggambarkan dan menggunakan layanan, terutama layanan mikro, mungkin pada beberapa host - mis. Docker swarm atau cluster Kubernetes.

Kedua masalah ini pada dasarnya bersifat ortogonal, yang berarti bahwa dengan menyelesaikan masalah penyebaran, seseorang dapat menggunakan salah satu dari mereka, keduanya, atau mungkin bahkan tidak satupun, sebagai bagian dari solusi. Saat menggunakan keduanya, paket Debian digunakan dalam produksi gambar Docker, dan Dockerfile Anda (resep yang digunakan untuk menyiapkan gambar Docker yang menggambarkan "sistem virtual" yang dijalankan dalam wadah) pada dasarnya akan mendaftarkan repositori Debian Anda di sumber sistem pengemasan Debian dan instal paket Anda.

Dengan pemikiran ini, menurut saya apa yang Anda benar-benar cari adalah menerapkan pola server yang tidak dapat diubah. Perkembangan baru-baru ini dalam teknologi cloud memungkinkan untuk memutakhirkan perangkat lunak bukan dengan menggunakan sistem pemutakhiran perangkat lunak klasik dari sistem paket perangkat lunak (seperti sistem pengemasan Debian) melainkan dengan hanya mengganti server penuh sekaligus. (Beberapa orang melakukan ini sebelum pengembangan ini dengan memiliki tiga OS-s di server, dua digunakan secara bergantian untuk menjalankan alat dan mini-OS yang didedikasikan untuk melakukan penggantian alat. Meskipun tidak terlalu rumit, ini tampaknya selalu tetap merupakan niche.) Teknik ini dapat menarik bagi Anda karena jika Anda digunakan untuk memutakhirkan perangkat lunak pada server Anda menggunakan manajer paket, keadaan akhir server tergantung pada "riwayat pemutakhiran" server - terutama jika kesalahan terjadi pada proses peningkatan. Heterogenitas ini buruk,

Kami memiliki ribuan kotak ini di lapangan. Kami mengelola dependensi paket, proses pendaftaran, dll. Melalui paket deb dengan berbagai tingkat keberhasilan.

bisa berhubungan dengan ini. Pola server yang tidak dapat diubah menghapus sumber kesalahan ini dengan menghancurkan gagasan “peningkatan riwayat” dari masalah.

Sekarang ada berbagai opsi untuk menerapkan pola server yang tidak dapat diubah, dua pilihan populer adalah menggunakan gambar Docker, gambar atau menggunakan "master instance images" dari penyedia cloud Anda (ini disebut AMI di AWS dan hanya Gambar Kustom di Google Compute Engine) . Kasus penggunaan Anda melarang penggunaan teknik berbasis cloud, oleh karena itu saya akan menganggap gambar Docker sebagai satu-satunya pilihan yang memenuhi syarat. (Demi penyelesaian, tentu saja mungkin untuk menggunakan pendekatan lain, misalnya menggunakan Kotak Virtual atau solusi virtualisasi serupa, sebagai alternatif untuk Docker.)

Saat menggunakan teknik pola server yang tidak dapat diubah, Anda memperkenalkan artefak baru (gambar Docker) yang mewakili server Anda dan artefak ini dapat diuji juga, dan sangat mudah untuk mendapatkan pengaturan yang mereplikasi pengaturan produksi Anda dengan jujur ​​- selain dari beban layanan.

Sekarang untuk mempertimbangkan masalah konkret yang Anda uraikan, mari asumsikan menerapkan pola server yang tidak dapat diubah dengan Docker sebenarnya adalah yang Anda inginkan. Karena sistem Docker dan sistem pengemasan Debian bersifat saling melengkapi dan bukan eksklusif satu sama lain (lih. Intro), kami masih harus menjawab pertanyaan jika Anda harus menyiapkan paket Debian untuk perangkat lunak Anda.

Kecocokan menggunakan paket Debian untuk menginstal perangkat lunak Anda (dalam gambar Docker atau pada host) terletak pada kompleksitas masalah versi yang harus Anda pecahkan. Jika Anda menjalankan beberapa versi perangkat lunak Anda secara bersamaan, kadang-kadang perlu menurunkan versi, dan memiliki persyaratan versi rumit yang harus Anda dokumentasikan dengan hati-hati, memiliki paket Debian adalah suatu keharusan. Jika tidak, langkah ini dapat dilewati - tetapi karena Anda sudah berupaya memproduksi dan menggunakan paket-paket ini, tidak ada nilai nyata untuk membuang pekerjaan Anda. Karena itu saya sarankan untuk terus memproduksi paket Debian Anda.

Saya pikir itu bisa menjadi pilihan yang baik (tes lebih lanjut diperlukan)

Anda dapat memberikan URL dengan semua tag / versi wadah yang telah Anda buat dan klien akan membaca URL itu untuk melihat apakah ada versi baru wadah tersebut.

Anda dapat menyimpan file / pengaturan pribadi di lokal dan Anda tidak akan pernah kehilangan informasi dalam peningkatan dan Anda akan memastikan bahwa apa yang Anda buat dan diuji akan bekerja untuk semua orang dengan cara yang sama.

Bahkan Anda dapat memberi pengguna kemungkinan untuk memilih versi mana dari yang tersedia yang ingin mereka gunakan (jika Anda ingin memberikan kemungkinan itu).

Ini akan seperti "" hanya upgrade satu paket "", berbicara tentang hanya mengambil versi baru dari wadah, jauh lebih baik daripada berurusan dengan paket debian;)

Docker terdengar masuk akal bagi saya, karena Anda bisa membuat dan menguji perubahan pada wadah di rumah, dan kemudian tergantung pada proses rilis Anda, restart wadah selalu menarik: terbaru atau sesuatu yang serupa yang akan memberikan upgrade yang teruji.

Pertimbangan yang perlu Anda tangani meliputi penyimpanan data karena wadah tidak menyimpan perubahan saat memulai ulang, sehingga Anda menginginkan volume data. Mungkin ada lebih banyak pertimbangan yang akan Anda miliki juga setelah Anda menggali ke dalamnya. Sistem yang saya gunakan saat ini (semua berbasis buruh pelabuhan) telah dikembangkan selama lebih dari satu tahun sekarang dan kami masih menemukan area di mana kami perlu membuat perubahan pada wadah, konfigurasi, dll.