Saya bekerja di berbagai perusahaan yang menggunakan layanan microser. Dan mereka menaruhnya di wadah buruh pelabuhan. Sekarang saya bekerja dengan sebuah proyek yang, meskipun merupakan monolit, masih lebih mudah untuk menjalankannya dalam sebuah wadah.
Di satu sisi, Docker adalah alat yang sangat serbaguna, dapat dengan mudah dan efektif digunakan untuk menyelesaikan sejumlah besar tugas. Ini bisa dimengerti dan tampaknya semuanya dasar. Tetapi di sisi lain, jika Anda tidak menghabiskan waktu dan sumber daya untuk "memompa" dalam penggunaannya yang tepat, Anda cenderung membuat rumit hal-hal sederhana. Dan tentu saja Anda akan menganggap bahwa Anda benar, dan Docker adalah sampah besar yang biasa-biasa saja yang tidak cocok untuk menyelesaikan tugas unik Anda.
Biasanya, di perusahaan standar, proses mengerjakan tugas terlihat seperti ini:
- Git push dilakukan dengan komit kami
- Sebuah sistem dipicu, baik itu Jenkins, TeamCity, dll.
- Pipeline / pekerjaan diluncurkan, di mana perpustakaan pihak ketiga diunduh, proyek dikompilasi, tes dijalankan
- Gambar buruh pelabuhan dengan proyek yang dirakit (ADD ..) Dibuat dan didorong ke registri buruh pelabuhan jarak jauh
- Entah bagaimana, pada server jarak jauh, tarikan docker dilakukan (koki, boneka, secara manual melalui docker-compose) dan wadah dimulai.
Secara intuitif, saya selalu merasa bahwa semua itu entah bagaimana terlalu rumit. Proses ini dengan bangga disebut CI / CD, dan saya bosan dengan orang pintar yang tidak ragu bahwa ini adalah cara termudah.
Untuk pengguna akhir, terlihat seperti ini: dengan mendorong ke repositori git, apa yang ada di komit terungkap di suatu tempat.
Apa yang saya TIDAK suka tentang pendekatan ini.
- Satu-satunya cara untuk menyebarkan sistem ke server jauh adalah melalui semua 5 langkah.
- Pada langkah 3, Anda mungkin perlu kunci akses ke perpustakaan pribadi. Prosesnya bisa lama jika caching perpustakaan yang diunduh sebelumnya tidak dikonfigurasi.
- Anda perlu menyiapkan Dockerfile, memutuskan gambar (DARI ...), memutuskan bagaimana kami akan menandai gambar dan membutuhkan akses ke repositori di mana kami akan mendorong gambar.
- Butuh repositori Anda sendiri, konfigurasikan https. Bagaimanapun, klien buruh pelabuhan hanya bekerja di https.
Paragraf keempat, tentu saja, dilakukan sekali dan mungkin tidak seharusnya ditambahkan.
Tetapi berapa kali kata Docker disebutkan sudah pada tahap rilis?
Pikirkan tentang hal ini: mengapa kita menyeret semua Docker ini sebelumnya? Karena diyakini bahwa wadah itu nyaman dan “Ya, semuanya baik-baik saja, itu berfungsi. Apa yang akan Anda mulai? ".
Jadi, untuk orang-orang seperti itu, saya dapat mengatakan - kontainer buruh pelabuhan bukanlah obat mujarab dan bukan satu-satunya lingkungan di mana aplikasi Anda dapat berjalan. Proyek ditulis dalam python, php, js, swift, scala / java, dll. dapat dijalankan pada:
- mesin virtual jarak jauh
- di localhost tanpa virtualisasi dan wadah buruh pelabuhan.
Tiba-tiba :)
Mari kita bayangkan bahwa kita membuat layanan yang akan berjalan di nodeJS.
Hasil dari proyek ini (atau yang saya sebut 'artefak') akan menjadi satu set file js (layanan itu sendiri) + node_modules (perpustakaan pihak ketiga yang digunakan dalam layanan).
Misalkan kita memastikan bahwa layanan ini berfungsi dan ingin menjalankannya dari jarak jauh sehingga penguji kami dapat mengujinya untuk fungsionalitas.
Bagaimana Anda menyukai ide ini:
- Kami membuat .tar.gz dengan proyek kami dan mengunggahnya ke ... repositori jarak jauh artefak! (Juga, repositori semacam itu disebut “repositori biner”).
- Kami mengatakan url yang dengannya mereka dapat mengunduh layanan kami dan mulai pengujian.
Selanjutnya, penguji dapat memulai layanan baik secara lokal di rumah, jika mereka memiliki segalanya, atau membuat Dockerfile, di mana akan ada unduhan artefak dan baru memulai wadah. Ya, atau yang lainnya.
Saya akan mengatakan segera jika Anda tidak ingin penguji meluncurkan wadah buruh pelabuhan dan secara umum "itu bukan tugas mereka" untuk diluncurkan, kemudian gunakan alat yang akan mengumpulkan gambar segera setelah artefak baru muncul di repositori biner (gunakan kait web, kejar secara berkala di atas mahkota).
Sekarang dari repositori biner ada:
- Sonatype nexus
- Artifactory
Nexus mudah digunakan, ia memiliki banyak repositori berbeda yang dapat Anda buat (npm, maven, raw, docker) jadi saya menggunakannya.
Ini ide yang sangat sederhana, mengapa saya tidak membacanya di mana saja? Di Internet, Anda tidak dapat menghitung artikel "seperti pada git push di suatu tempat sebuah wadah digunakan dalam semacam kubernet". Dari algoritma yang sedemikian rumit, rambut berdiri tegak.
Tujuan artikel ini, untuk mengatakan - tidak perlu dalam satu proses untuk merakit proyek dan menambahkannya ke gambar buruh pelabuhan.
Membagi dan berkuasa!
Bangun proyek, terbitkan artefak di tempat yang dapat diunduh. (Registri Docker bukan satu-satunya tempat di mana Anda dapat menyimpan proyek Anda, pilih jalur universal untuk mengirimkan artefak ke server).
Dengan alat terpisah, kirim artefak ke server tempat proyek Anda akan bekerja.
Semuanya sangat sederhana, memberi orang lain pilihan: gunakan buruh pelabuhan, jalankan di kubernetes, atau gunakan alat lain untuk menjalankan artefak. Tidak perlu memaksakan penggunaan teknologi meskipun fakta bahwa menurut Anda sangat nyaman dan modis.
Semoga sukses dalam meluncurkan proyek Anda!