Mengapa pengembang harus peduli dengan Docker?

11

Umumnya pengembang peduli tentang memenuhi persyaratan bisnis. Ia mungkin memiliki keahlian dalam tumpukan atau kerangka kerja tertentu. Tetapi haruskah ia berusaha mempelajari buruh pelabuhan dan berbagai metode penyebarannya (swarm, kube, mesos, dll)?

Sederhananya mengapa pengembang harus peduli tentang buruh pelabuhan?

PS: Pertanyaan orang tua untuk posting ini adalah Implikasi memperkenalkan buruh pelabuhan kepada tim pengembangan

docker project-management orchestration

— Abhay Pai
sumber

7

Mungkin bukan jawaban yang Anda cari, tapi tetap saja jawabannya :)

Belajar tentang buruh pelabuhan dan metode penyebarannya sebenarnya dapat dimasukkan dalam persyaratan bisnis dengan menjadikannya bagian dari lingkungan pengembangan proyek atau tim, seperti bahasa kode, sistem kontrol versi, kompiler, infrastruktur pengujian, dll - untuk bekerja di tim atau proyek yang perlu diketahui dan digunakan semua tim ini, tidak dapat "membawa milik Anda" (dalam kebanyakan kasus).

Segalanya menjadi sedikit lebih rumit jika dengan "seorang pengembang" yang Anda maksud sebenarnya adalah mayoritas atau bahkan seluruh tim pengembangan. Mendorong alat di lingkungan pengembangan tanpa benar-benar memiliki pengembang yang mendukungnya akan sangat sulit. Luangkan waktu untuk menciptakan satu pendukung seperti itu pertama dari kepemimpinan teknis tim.

Catatan: mungkin juga tidak perlu bagi masing-masing dan setiap pengembang dalam tim untuk menjadi ahli buruh pelabuhan. Resep penggunaan yang sudah ada sebelumnya yang dibungkus dengan perintah sederhana, siap-cheatsheet sering memungkinkan pengembang untuk menggunakan solusi berbasis buruh pelabuhan tanpa benar-benar mengetahui terlalu banyak tentang cara kerja bagian dalam mereka, yang bisa cukup diterima, terutama dalam tim besar. Seperti halnya dapat berkontribusi kode tanpa mengetahui semua detail tentang bagaimana produk akhir sedang dibangun.

— Dan Cornilescu
sumber

Selain itu, Anda dapat membangun di atas teknologi apa pun yang Anda inginkan, memberi Anda lebih sedikit batasan, dan mengurangi sakit kepala bagi sysadmin untuk mendukung semua teknologi yang berbeda. Dan karena "dev" memutuskan teknologinya, itu harusnya untuk mengatur lingkungan buruh pelabuhan.

— DarkMukke

@DarkMukke "dev" tidak selalu menentukan teknologinya ... Sebaliknya, sering terjadi sebaliknya di tim dev yang lebih besar - "dev" hanya menggunakan teknologi apa pun yang digunakan tim. Pengecualian mungkin ditoleransi jika mereka tidak mengganggu atau berdampak negatif terhadap kegiatan tim.

— Dan Cornilescu

Saya sebagian setuju, tetapi saya telah melihat perusahaan pengembang besar (200+) bekerja dengan buruh pelabuhan seperti yang saya jelaskan. Saya pikir ini adalah masalah pilihan pribadi tidak hanya tim dev tetapi juga staf pengelola di atas mereka. Jika ada devops yang layak, jumlah buruh pelabuhan yang dibutuhkan dev biasanya sepele.

— DarkMukke

6

Saya akan memberi Anda perspektif saya. Pengembang harus peduli dengan buruh pelabuhan karena ada pengembang lain yang bersedia menggunakan buruh pelabuhan dan telah membangun keahlian di dalamnya. Mereka bersedia mengambil peran sebagai insinyur DevOps bersama dengan menjadi pengembang. Jadi bagian Ops dari DevOps adalah apa yang sekarang mereka bangun dari keahlian.

Hari-hari ini, Anda akan menemukan semakin banyak orang yang dapat mengembangkan, mengatur, mengotomatisasi tes, mengotomatisasi pekerjaan dan membuat alat untuk memantau dan membawa paket lengkap ini ke dalam produksi sendiri. Ini adalah orang-orang yang mendorong buruh pelabuhan dan alat-alat lain di antara komunitas pengembang.

Selain itu, gelombang pasar adalah menuju virtualisasi, penskalaan otomatis, otomatisasi, pembelajaran mesin, dan buruh pelabuhan cocok untuk semua ini. Menjadi keharusan untuk menggunakan buruh pelabuhan. Bisnis mau membayar 2x untuk pria lajang yang mengambil semua tanggung jawab ini dan ketika ada permintaan untuk pria seperti itu, pasokan juga akan dimulai. Ini dari sudut pandang seorang karyawan-majikan.

Secara teknis, di organisasi saya telah bekerja, ada tim pengembangan dan DevOps terpisah, meskipun mereka bekerja sangat erat untuk pengiriman. Insinyur dan pengembang DevOps berbagi sebagian besar keterampilan di sini dan karenanya terkadang ada negosiasi tugas.

Minimum yang bisa dilakukan oleh pengembang adalah berbagi binari, tetapi ia perlu memahami bahwa binari akan digunakan untuk berjalan di dalam wadah buruh pelabuhan dan untuk itu ia harus memahami cara kerja buruh pelabuhan. Untuk kubes, gerombolan, mesos dll, pengembang mungkin tidak peduli apa yang sedang digunakan, tetapi dasar-dasar buruh pelabuhan harus dipahami dengan baik oleh pengembang dan pola pikir harus ada sejak awal untuk membangun aplikasi secara longgar digabungkan untuk digunakan kembali sebagai layanan mikro. Jika aplikasi dibangun dari pola pikir itu (yang membutuhkan dasar-dasar buruh pelabuhan), maka insinyur DevOps dapat mengambilnya dari sana untuk skala otomatis, mengatur, menguji, menyebarkan, dan memantau.

Juga, sebagian besar waktu tidak ada satu ukuran cocok untuk semua hal. Seorang pengembang tidak tahu dengan jelas bagaimana membangun aplikasi ramah buruh pelabuhan dan seorang insinyur DevOps dengan benar tidak mengetahui bagian internal dari proses pembuatan aplikasi. Oleh karena itu, sebagian besar waktu, organisasi lebih suka memberikan kedua tugas ini kepada orang yang sama untuk mempercepat. Jika ada hal-hal yang terpisah, maka diperlukan mekanisme umpan balik terus menerus dari tim DevOps ke tim pengembang untuk membuat aplikasi lebih futuristik dan buruh pelabuhan / cloud / penskalaan siap.

— lakshayk
sumber

5

Ini bukan tentang Docker atau teknologi kontainerisasi lainnya di luar sana.

Kontainer seperti Docker, rkt, dll. Hanyalah cara mengirimkan aplikasi Anda dengan cara yang mirip dengan biner statis. Anda sedang membangun penyebaran Anda yang berisi semua yang dibutuhkan di dalamnya dan pengguna akhir tidak membutuhkan apa pun selain runtime.

Solusi ini mirip dengan JAR gemuk di Jawa, di mana semua yang Anda (secara teori) butuhkan hanyalah runtime (JRE) yang sudah diinstal sebelumnya dan semuanya Just Works ™.

Alasan mengapa pengembang perlu memahami (mereka tidak perlu belajar bagaimana mengoperasikan alat tersebut, hanya mengapa ini diperlukan) alat orkestrasi adalah bahwa ini memungkinkan Anda untuk memiliki beberapa keunggulan dibandingkan penyebaran "tradisional".

Ternak, bukan hewan peliharaan

EngineYard telah menulis artikel bagus tentang itu. Intinya adalah ketika server Anda mati, maka Anda mengangkat bahu dan menunggu saat baru akan muncul. Anda memperlakukan mereka sebagai ternak, Anda memiliki puluhan, ratusan, ribuan dari mereka berlari dan ketika seseorang turun Anda atau klien Anda seharusnya tidak pernah menyadari hal itu.

Alat orkestrasi mencapainya dengan memonitor status semua aplikasi (pod / pekerjaan, apa pun) dalam cluster, dan ketika melihat bahwa salah satu server berhenti merespons (turun) maka secara otomatis memindahkan semua aplikasi yang berjalan pada server itu di tempat lain.

Pemanfaatan sumber daya yang lebih baik

Berkat orkestrasi Anda dapat menjalankan beberapa aplikasi pada satu server dan orkestrator akan melacak sumber daya untuk Anda. Ini akan mengatur ulang aplikasi bila diperlukan.

Infrastruktur yang tidak dapat diubah

Berkat penanganan failover otomatis di orkestra Anda dapat menjalankan gambar khusus di cloud apa adanya. Ketika Anda akan membutuhkan pembaruan, Anda hanya membangun gambar baru, atur Konfigurasi Peluncuran Anda untuk menggunakan yang sekarang dan hanya roll. Semuanya akan ditangani untuk Anda:

Buat server baru dengan konfigurasi baru.
Bunuh satu server yang sedang berjalan.
Orkestra Anda akan memindahkan semuanya ke komputer lain (termasuk yang baru).
Jika masih ada server lama, lanjutkan ke 1.

Operasi yang lebih sederhana

Tidak cukup sumber daya? Tambahkan mesin baru ke cluster.
Perlu lebih banyak contoh aplikasi? Tambah angka dan teruskan.
Pemantauan? Selesai
Manajemen log? Selesai
Rahasia Tebak apa.

TL; DR Seluruh poin bukan tentang Docker tetapi tentang orkestrasi. Docker hanyalah versi panjang dari tarball / guci lemak yang diperlukan untuk orkestrasi yang tepat.

— Hauleth
sumber

Nah, itu yang saya tanyakan dan itulah pertanyaan keseluruhannya. Haruskah pengembang peduli dengan pemanfaatan sumber daya yang lebih baik, infrastruktur yang tidak dapat diubah dan operasi yang lebih sederhana? ... Apa yang saya yakini adalah bahwa mereka harus fokus dalam memberikan persyaratan bisnis dan optimasi kode yang akan mengarah pada pemanfaatan sumber daya yang lebih baik. Bahkan buruh pelabuhan tidak akan membantu dalam pemanfaatan yang lebih baik jika itu adalah kode tertulis yang buruk / rata-rata. Mari kita menerima kenyataan bahwa persyaratan bisnis membuat devs memberikan hal-hal lebih cepat. Dan dengan melakukan ini mereka tidak punya waktu untuk mengoptimalkan kode. Mengapa menambahkan tanggung jawab buruh pelabuhan pada mereka?

— Abhay Pai

Masalahnya adalah bahwa memiliki gambaran umum seluruh tumpukan, dari tes hingga implementasi dan akhirnya untuk penyebaran akan memungkinkan Anda untuk melihat bagaimana perangkat lunak Anda digunakan, apa kasus tepi, apa yang menabrak. Ini akan memperlambat Anda dalam LOC yang Anda tulis, tetapi sangat meningkatkan kualitasnya. Dalam jangka panjang, menghemat waktu

— Moritz

4

Berikut adalah beberapa argumen dari posting blog yang diterbitkan kembali tahun 2014 dan berjudul dengan cara yang cukup sesuai dengan jawaban Anda:

Injeksi jauh lebih fleksibel dari teknologi baru ke lingkungan

masih ada titik sakit besar antara melakukan kode diuji akhir dan kemudian menjalankannya di server produksi akhir. Docker sangat menyederhanakan langkah terakhir ini

Docker membuatnya mudah untuk tetap menggunakan OS lama, apa pun rasanya Linux yang Anda jalankan

Dari: https://thenewstack.io/why-you-should-care-about-docker/

— Peter Muryshkin
sumber

Saya setuju untuk menyuntikkan teknologi baru. Tetapi ada beberapa masalah dengan itu juga. Seperti menggunakan buruh pelabuhan untuk basis data ( percona.com/blog/2016/11/16/is-docker-for-your-database ). Mereka tidak stabil saat ini dan mungkin akan stabil di masa depan. Mari kita berharap untuk yang terbaik. Kita dapat mencapai mendorong kode yang diuji untuk memproduksi dengan menggunakan CI / CD. Lalu mengapa buruh pelabuhan? Pengembang tidak peduli dengan OS apa yang kami jalankan. Mengapa mereka harus repot-repot belajar buruh pelabuhan di tempat pertama? Untuk membuat devop hidup lebih mudah?

— Abhay Pai

di tempat pertama saya hanya berpikir tentang skenario "MVP" berikut: dev mencoba beberapa konfigurasi / alat baru untuk lingkungan sebagai komponen infrastruktur, katakanlah imagemagick. Tanpa Docker informasi ini dapat hilang atau terlupakan, atau membutuhkan komunikasi bersama dengan banyak hal kecil lainnya. Berbagi Dockerfile adalah pengaturan yang dapat dibuktikan dengan mesin dari suatu hal yang bekerja yang bahkan digunakan untuk membuat pengaturan ke infrastruktur bebas Docker lebih berharga daripada sekadar dokumentasi. Tentu Anda juga bisa memilih Wayang; hal yang baik tentang Docker adalah bagaimana IMHO memungkinkan skenario mandiri.

— Peter Muryshkin

Sepakat. Tetapi masalah muncul selama orkestrasi. Pengembang perlu memiliki keahlian dalam orkestrasi buruh pelabuhan agar mematuhi praktik terbaik dan memenuhi persyaratan bisnis. Pertimbangkan skenario Anda di mana pengembang membutuhkan imagemagick sebagai layanan. Sekarang saat membangun file docker, dia mendapatkan kontrol penuh pada paket yang dia dapat instal dalam gambar docker. Bagaimana jika mereka menginstal sshd ke ssh ke buruh pelabuhan alih-alih menggunakan buruh pelabuhan? Bagaimana jika mereka menginstal alat yang tidak ada hubungannya dengan logika bisnis tetapi membahayakan keamanan? Apakah pengembang membutuhkan keahlian buruh pelabuhan?

— Abhay Pai

hm tetapi bagaimana jika mereka menerapkan backdoor berbasis socket? buruh pelabuhan tidak menggantikan firewall perusahaan saya pikir

— Peter Muryshkin

Benar. Tapi itu akan menjadi niat jahat pengembang dalam hal apa pun. Baik itu buruh pelabuhan atau buruh pelabuhan. Tetapi ketika buruh pelabuhan diperkenalkan ke devs, mereka dapat menyebabkan kecelakaan hanya karena mereka tidak memiliki pengetahuan yang sesuai. Mengapa mereka harus repot-repot belajar buruh pelabuhan (mengingat orkestra juga akan menambah kerumitan) ketika hal itu dapat menyebabkan kecelakaan dan komplikasi? Tolong jangan pikirkan pertanyaanku. Bahkan saya suka buruh pelabuhan. Tetapi saya mencoba memahami perspektif pengembang. Saya telah menjadi pengembang sendiri selama 3 tahun terakhir dan sekarang saya seorang insinyur DevOps.

— Abhay Pai

4

Jika Anda menjalankan produksi dalam wadah buruh pelabuhan, penting agar wadah itu dibuat oleh pengembang yang sama yang telah membangun aplikasi yang menjalankannya. Siapa lagi tempat yang lebih baik untuk mengetahui ketergantungan eksternal apa yang dibutuhkan dan seterusnya ...?

Juga pipeline dapat gagal pada langkah apa pun selama CD, terutama ketika itu adalah langkah pembuatan gambar buruh pelabuhan, kadang-kadang itu adalah file yang hilang atau lib yang dibutuhkan.

Di tempat kerja kami telah memperkenalkan semua pengembang untuk buruh pelabuhan menjelaskan kepada mereka dasar-dasar untuk membangun buruh pelabuhan agar dapat melayani aplikasi mereka, juga kami membuat saluran pipa menjadi mudah sehingga seseorang hanya dapat menambahkan nama dan buruh pelabuhan dan aplikasinya akan secara otomatis dibangun di atas dorongan berikutnya terlepas dari teknologi yang menjalankannya.

Docker quickstart benar-benar merupakan perkenalan yang bagus untuk melakukannya, setelah apa yang dipandu tim devOps kepada dev dalam pilihan distro mereka (banyak dari mereka tidak tahu hal-hal seperti alpine).

Tugas kita adalah memberi mereka akses mudah ke alat, mereka melakukan sisanya sehingga mereka dapat memperbaikinya ketika ada sesuatu yang salah. Docker benar-benar bagian dari proses pengembangan dan tim devOps memberi mereka gambar docker yang sesuai dengan kebutuhan kita dan itu cukup mudah sehingga hanya perlu beberapa menit untuk membuat aplikasi baru dan menggunakannya tanpa bantuan.

— Juub
sumber

Jadi menurut seorang pengembang, penggunaan buruh pelabuhan dalam suatu proyek hanya boleh diambil jika proyek menuntut ketergantungan eksternal? Saya pikir buruh pelabuhan telah menjadi bagian dari proses pengembangan kami karena kami telah menerapkannya pada devs atau karena kami pikir itu keren. Juga masalah muncul selama orkestrasi. Apakah mereka harus belajar orkestra seperti gerombolan, kubernet atau mesos? Implementasi dari semua orkestrasi ini berbeda. Bagaimana jika orkestrasi macet karena implementasi yang buruk? Siapa yang harus disalahkan? PS: Jangan pedulikan pertanyaanku. Saya hanya bermain sebagai penasihat devli. Saya juga suka buruh pelabuhan :)

— Abhay Pai

2

Docker mendapat banyak informasi pers dan blog yang membuat pengembang tertarik menggunakannya. Bagi sebagian orang itu adalah minat bermain dengan teknologi baru atau memahami cara kerja. Bagi orang lain itu adalah keinginan untuk menambahkan kata kunci ke resume mereka. Either way, semakin banyak pengembang tahu tentang bagaimana hal-hal bekerja dan bagaimana mereka dikerahkan semakin mereka tidak terkejut nantinya. Dari apa yang saya lihat ada sejumlah minat yang sudah ada sebelumnya yang layak dalam hal ini sehingga seharusnya tidak sulit untuk mendorongnya lebih jauh.

— anak ayam
sumber

0

Nah, jika Anda pernah menggunakan VM untuk pengujian Anda mungkin ingin mencoba menggunakan wadah dan buruh pelabuhan sebenarnya adalah hal yang bagus untuk pengujian dan jauh lebih mudah untuk digunakan daripada LXC :)

— YV
sumber

Sepakat. Saya tidak menentang penggunaan buruh pelabuhan atau berbagai alat orkestrasi. Saya mencintai mereka juga. Apa yang saya coba pahami adalah sederhana. Siapa yang memiliki containerisasi aplikasi. Devs? Atau DevOps? Atau keduanya ? Jika keduanya, berapa banyak masing-masing dari mereka harus berkontribusi? Ketika hal-hal gagal baik karena buruh pelabuhan atau orkestra buruh pelabuhan yang harus bertanggung jawab? Efisiensi kode vs membantu devops untuk membuat hidup mereka mudah. Pertanyaan saya cenderung ke arah peran individu daripada teknologi itu sendiri.

— Abhay Pai