Meningkatkan Penerapan Perangkat Lunak - Tutorial Docker Swarm

Kecuali Anda pernah tinggal di dalam peti kemas, Anda mungkin pernah mendengar tentang peti kemas. Industri telah membuat langkah berbeda dari infrastruktur persisten ke infrastruktur fana, dan kontainer berada di tengah-tengah langkah itu. Alasannya cukup sederhana: Meskipun container tentu saja membantu tim pengembang untuk bangun dan berjalan dengan cepat, container memiliki potensi yang lebih besar untuk sepenuhnya mengubah wajah operasi.

Tapi seperti apa sebenarnya itu? Apa yang terjadi ketika Anda siap untuk melompat dari menjalankan container secara lokal, atau secara manual di beberapa server? Di dunia yang ideal, Anda hanya ingin melemparkan aplikasi Anda ke sekelompok server dan mengatakan "jalankan!"

Syukurlah, di situlah kita hari ini.

Pada artikel ini, kita akan menjelajahi apa itu Docker Swarm, bersama dengan beberapa fitur hebat yang ditawarkannya. Kemudian kita akan melihat seperti apa sebenarnya penggunaan mode Swarm dan penerapannya ke swarm, dan kita akan menyimpulkan dengan beberapa contoh seperti apa operasi sehari-hari dengan swarm yang di-deploy. Pengetahuan dasar tentang Docker dan container sangat direkomendasikan, tetapi Anda dapat melihat posting blog yang luar biasa ini terlebih dahulu jika Anda baru mengenal container.

Apa itu Docker Swarm?

Sebelum kita mendalami pembuatan dan penerapan ke swarm pertama kita, ada baiknya untuk mengetahui apa itu Docker Swarm. Docker sendiri telah ada selama bertahun-tahun, dan kebanyakan orang saat ini menganggapnya sebagai runtime container. Namun pada kenyataannya, Docker terdiri dari banyak bagian yang berbeda, semuanya bekerja bersama. Misalnya, bagian runtime container tersebut ditangani oleh dua komponen yang lebih kecil, yang disebut runC dan containerd. Karena Docker telah berevolusi dan memberikan kembali kepada komunitas, mereka menemukan bahwa membuat komponen yang lebih kecil ini adalah cara terbaik untuk mengembangkan dan menambahkan fitur dengan cepat. Dengan demikian, kami sekarang memiliki mode SwarmKit, dan Swarm, yang dibangun langsung ke Docker.

Docker Swarm adalah mesin orkestrasi kontainer. Pada tingkat tinggi, dibutuhkan beberapa Mesin Docker yang berjalan di host yang berbeda dan memungkinkan Anda menggunakannya bersama-sama. Penggunaannya sederhana: mendeklarasikan aplikasi Anda sebagai tumpukan layanan, dan biarkan Docker menangani sisanya. Layanan dapat berupa apa saja mulai dari instans aplikasi hingga database, atau utilitas seperti Redis atau RabbitMQ. Ini seharusnya terdengar familier jika Anda pernah bekerja dengan docker-compose dalam pengembangan, karena ini adalah konsep yang persis sama. Faktanya, deklarasi tumpukan secara harfiah hanyalah file docker-compose.yml dengan sintaks versi 3.1. Ini berarti Anda dapat menggunakan konfigurasi penulisan yang serupa (dan dalam banyak kasus identik) untuk pengembangan dan penyebaran swarm, tetapi saya sedikit lebih maju di sini. Apa yang terjadi ketika Anda memiliki instance Docker dalam mode Swarm?

Jangan Jatuh dari Rakit

Kami memiliki dua jenis node (server) di dunia Swarm: manajer dan pekerja. Penting untuk diingat bahwa manajer juga pekerja, mereka hanya memiliki tanggung jawab tambahan untuk menjaga segala sesuatunya tetap berjalan. Setiap swarm dimulai dengan satu node manager yang ditunjuk sebagai leader. Dari sana, tinggal menjalankan satu perintah untuk menambahkan node ke swarm dengan aman.

Swarm sangat tersedia berkat implementasi algoritma Raft. Saya tidak akan membahas terlalu banyak detail tentang Raft karena sudah ada tutorial yang bagus tentang cara kerjanya, tetapi inilah ide umumnya: Node pemimpin terus-menerus memeriksa dengan node sesama manajernya dan menyinkronkan statusnya. Agar perubahan status “diterima”, node manajer banyak mencapai konsensus, yang terjadi ketika mayoritas node mengakui perubahan status.

Keindahan dari ini adalah bahwa node manajer dapat secara sporadis turun tanpa mengorbankan konsensus swarm. Jika perubahan status mencapai konsensus, kami tahu itu dijamin ada di sebagian besar node manajer dan akan bertahan bahkan jika pemimpin saat ini gagal.

Katakanlah kita memiliki tiga node manajer bernama A, B, dan C. Tentu saja, A adalah pemimpin kita yang tak kenal takut. Nah, suatu hari kesalahan jaringan sementara membuat A offline, meninggalkan B dan C sendirian. Setelah tidak mendengar kabar dari A dalam waktu yang lama (beberapa ratus milidetik), B dan C menunggu beberapa waktu yang ditentukan secara acak sebelum mengajukan diri untuk pemilihan dan memberi tahu yang lain. Tentu saja, yang pertama naik untuk pemilihan, dalam hal ini, akan dipilih. Dalam contoh ini, B menjadi pemimpin baru, dan kuorum dipulihkan. Tapi kemudian, plot twist: Apa yang terjadi ketika A kembali online? Ini akan berpikir itu masih pemimpin, kan? Setiap pemilihan memiliki istilah yang terkait dengannya, jadi A sebenarnya terpilih dalam istilah 1. Segera setelah A kembali online dan mulai memesan B dan C, mereka dengan baik hati akan memberi tahu bahwa B adalah pemimpin periode 2, dan A akan mundur.

Proses yang sama ini bekerja pada skala yang jauh lebih besar, tentu saja. Anda dapat memiliki lebih dari tiga node manajer. Saya akan menambahkan satu catatan singkat lainnya. Setiap Swarm hanya dapat menerima sejumlah kerugian manajer tertentu. Sekelompok n node manajer dapat kehilangan (n-1)/2 manajer tanpa kehilangan kuorum. Itu berarti untuk gerombolan tiga manajer Anda bisa kehilangan satu, untuk lima Anda bisa kehilangan dua, dll. Alasan yang mendasari untuk ini kembali ke gagasan tentang konsensus mayoritas, dan itu pasti sesuatu yang perlu diingat saat Anda pergi ke produksi.

Penjadwalan Tugas dan Rekonsiliasi

Sejauh ini, kami telah menetapkan bahwa manajer kami sangat pandai menjaga sinkronisasi. Besar! Tapi apa yang sebenarnya mereka lakukan? Ingat bagaimana saya mengatakan bahwa Anda menyebarkan setumpuk layanan ke Swarm? Saat Anda mendeklarasikan layanan Anda, Anda memberi Swarm informasi penting tentang bagaimana Anda sebenarnya ingin layanan Anda dijalankan. Ini termasuk parameter seperti berapa banyak replika yang Anda inginkan dari setiap layanan, bagaimana replika harus didistribusikan, apakah replika itu hanya boleh dijalankan pada node tertentu, dan banyak lagi.

Setelah layanan diterapkan, tugas manajer adalah memastikan bahwa persyaratan penerapan yang Anda tetapkan terus terpenuhi. Katakanlah Anda menerapkan layanan Nginx dan menentukan bahwa harus ada tiga replika. Manajer akan melihat bahwa tidak ada kontainer yang berjalan dan mendistribusikan tiga kontainer secara merata di seluruh node yang tersedia.

Yang lebih keren lagi, jika sebuah container gagal (atau seluruh node offline), Swarm akan secara otomatis membuat container pada node yang tersisa untuk menebus perbedaan. Jika Anda mengatakan Anda ingin tiga kontainer berjalan, Anda akan menjalankan tiga kontainer, sementara Swarm menangani semua detail seluk beluk. Plus—dan ini adalah nilai tambah yang besar—penskalaan naik atau turun semudah memberi Swarm pengaturan replikasi baru.

Penemuan Layanan dan Penyeimbangan Beban

Saya ingin menunjukkan detail penting tetapi tidak kentara dari contoh terakhir: Jika Swarm secara cerdas memulai container pada node pilihannya, kita tidak perlu tahu di mana container tersebut akan dijalankan. Itu mungkin terdengar menakutkan pada awalnya, tetapi sebenarnya ini adalah salah satu fitur Swarm yang paling kuat.

Melanjutkan contoh Nginx yang sama, bayangkan kita memberi tahu Docker bahwa container tersebut harus mengekspos port 80. Jika Anda mengarahkan browser ke node yang menjalankan container tersebut pada port 80, Anda akan melihat konten container tersebut. Tidak ada kejutan di sana. Yang mungkin mengejutkan, adalah jika Anda mengirim permintaan ke node yang tidak menjalankan container itu, Anda masih akan melihat konten yang sama! Apa yang sedang terjadi disini?

Swarm sebenarnya menggunakan jaringan ingress untuk mengirim permintaan Anda ke node yang tersedia yang menjalankan container itu, dan memuatnya secara bersamaan. Jadi, jika Anda membuat tiga permintaan ke node yang sama, kemungkinan besar Anda akan mendapatkan tiga kontainer yang berbeda. Selama Anda mengetahui IP dari satu node di swarm, Anda dapat mengakses apa pun yang berjalan di dalamnya. Sebaliknya, ini memungkinkan Anda mengarahkan penyeimbang beban (seperti ELB) di semua node dalam swarm tanpa perlu khawatir tentang apa yang berjalan di mana.

Itu tidak berhenti pada koneksi eksternal. Layanan yang berjalan pada tumpukan yang sama memiliki jaringan overlay yang memungkinkan mereka berkomunikasi satu sama lain. Alih-alih mengkodekan alamat IP dalam kode Anda, Anda cukup menggunakan nama layanan sebagai nama host yang ingin Anda sambungkan. Misalnya, jika aplikasi Anda perlu berkomunikasi dengan layanan Redis bernama "redis", itu cukup menggunakan "redis" sebagai nama host dan Swarm akan mengarahkan permintaannya ke wadah yang sesuai. Dan karena ini bekerja dengan lancar dalam pengembangan dengan komposisi buruh pelabuhan dan dalam produksi dengan Docker Swarm, satu hal yang perlu dikhawatirkan saat men-deploy aplikasi Anda adalah satu.

Pembaruan Bergulir

Jika Anda berada di ops, Anda mungkin pernah mengalami serangan panik saat pembaruan produksi menjadi sangat salah. Ini bisa menjadi pembaruan kode yang buruk, atau bahkan hanya kesalahan konfigurasi, tetapi tiba-tiba produksi turun! Kemungkinannya adalah bos tidak akan peduli. Mereka hanya akan tahu itu salahmu. Nah, jangan khawatir, Swarm juga mendukung Anda.

Saat memperbarui layanan, Anda dapat menentukan berapa banyak penampung yang harus diperbarui sekaligus dan apa yang harus terjadi jika penampung baru mulai gagal. Setelah ambang batas tertentu, Swarm dapat menghentikan pembaruan atau (pada Docker 17.04) mengembalikan wadah ke gambar dan pengaturan sebelumnya. Jangan khawatir harus membawakan kopi untuk bos Anda besok pagi.

Keamanan

Terakhir, tetapi tidak jauh dari itu, Docker Swarm hadir dengan fitur keamanan yang luar biasa. Ketika sebuah node bergabung dengan swarm, ia menggunakan token yang tidak hanya memverifikasi dirinya sendiri tetapi juga memverifikasi bahwa ia bergabung dengan swarm yang Anda pikirkan. Sejak saat itu, semua komunikasi antar node berlangsung menggunakan enkripsi TLS bersama. Enkripsi ini semuanya disediakan dan dikelola secara otomatis oleh Swarm, jadi Anda tidak perlu khawatir tentang memperbarui sertifikat, dan gangguan keamanan lainnya. Dan tentu saja, jika Anda ingin memaksa rotasi tombol, ada perintah untuk itu.

Versi terbaru Docker Swarm juga dilengkapi dengan manajemen rahasia bawaan. Ini memungkinkan Anda menyebarkan rahasia seperti kunci dan kata sandi dengan aman ke layanan yang membutuhkannya, dan hanya layanan yang membutuhkannya. Saat Anda menyediakan layanan dengan rahasia, wadah untuk layanan itu akan memiliki file khusus yang dipasang di sistem file mereka yang menyertakan nilai rahasia. Tak perlu dikatakan lagi, tetapi ini jauh lebih aman daripada menggunakan variabel lingkungan, yang merupakan pendekatan tradisional.

Menyelam ke dalam Kawanan

Jika Anda seperti saya, Anda ingin sekali terjun dan mencoba semua fitur ini! Jadi tanpa basa-basi lagi, mari selami!

Aplikasi Contoh Docker Swarm

Saya telah membuat aplikasi Flask yang sangat sederhana untuk menunjukkan kekuatan dan kemudahan menggunakan Docker Swarm. Aplikasi web hanya menampilkan halaman yang memberi tahu Anda wadah mana yang melayani permintaan Anda, berapa banyak total permintaan yang telah dilayani, dan apa kata sandi basis data "rahasia".

Ini dipecah menjadi tiga layanan: aplikasi Flask yang sebenarnya, proxy terbalik Nginx, dan keystore Redis. Pada setiap permintaan, aplikasi menambahkan kunci num_requests di Redis, jadi terlepas dari instance Flask mana yang Anda tekan, Anda akan melihat jumlah permintaan yang benar tercermin.

Semua kode sumber tersedia di GitHub jika Anda ingin "memeriksa" apa yang sedang terjadi.

Bermain dengan Docker!

Jangan ragu untuk menggunakan server Anda sendiri saat Anda melalui tutorial ini, tetapi saya sangat menyarankan menggunakan play-with-docker.com jika Anda ingin langsung masuk. Ini adalah situs yang dijalankan oleh beberapa pengembang Docker yang memungkinkan Anda menjalankan beberapa jaringan node yang memiliki Docker pra-instal. Mereka akan dimatikan setelah empat jam, tapi itu sudah cukup untuk contoh ini!

Membuat Kawanan

Baiklah, ini dia! Lanjutkan dan buat tiga instance di PWD (play-with-docker) atau putar tiga server di layanan VPS (virtual private server) favorit Anda dan instal mesin Docker di semuanya. Perlu diingat, Anda selalu dapat membuat gambar dan menggunakannya kembali saat menambahkan node di masa mendatang. Tidak ada perbedaan perangkat lunak antara node manajer dan node pekerja, jadi Anda tidak perlu mempertahankan dua gambar yang berbeda.

Masih berputar? Jangan khawatir, aku akan menunggu. Oke, sekarang kita akan membuat node manager dan leader pertama kita. Pada contoh pertama Anda, inisialisasi swarm:

 docker swarm init --advertise-addr <node ip here>

Ganti <node_ip_here> dengan alamat IP node Anda. Pada PWD, alamat IP ditampilkan di bagian atas, dan jika Anda menggunakan VPS Anda sendiri, silakan gunakan alamat IP pribadi server Anda selama dapat diakses dari node lain di jaringan Anda.

Anda sekarang memiliki segerombolan! Ini adalah kawanan yang cukup membosankan, karena hanya memiliki satu simpul. Mari kita lanjutkan dan tambahkan node lainnya. Anda akan melihat bahwa ketika Anda menjalankan init , itu menampilkan pesan panjang yang menjelaskan cara menggunakan token gabungan. Kami tidak akan menggunakan yang itu karena akan membuat node lain bekerja, dan kami ingin mereka menjadi manajer. Mari dapatkan token bergabung untuk seorang manajer dengan menjalankan ini di node pertama:

 docker swarm join-token manager

Salin perintah yang dihasilkan dan jalankan di node kedua dan ketiga Anda. Lihatlah, gerombolan tiga simpul! Mari kita verifikasi bahwa semua node kita benar-benar ada. Perintah docker node ls akan mencantumkan semua node di swarm. Anda akan melihat sesuatu seperti ini:

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

Perhatikan bagaimana simpul pertama kita memiliki tanda bintang di sebelah ID. Itu hanya memberi tahu kami bahwa itu adalah simpul yang saat ini terhubung dengan kami. Kita juga dapat melihat bahwa node ini saat ini adalah Leader, dan node lainnya dapat dijangkau jika sesuatu terjadi padanya.

Luangkan waktu sejenak untuk menghargai betapa mudahnya itu, dan mari kita gunakan aplikasi pertama kita!

Kirim Itu!

Baru saja, tim pengembangan bisnis berjanji kepada klien bahwa aplikasi baru mereka akan digunakan dan siap dalam waktu satu jam! Khas, saya tahu. Tapi jangan takut, kita tidak akan membutuhkan banyak waktu, karena dibangun menggunakan Docker! Para pengembang cukup baik untuk meminjamkan kami file docker-compose mereka:

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

Kami akan memecahnya sebentar lagi, tetapi belum ada waktu untuk itu. Mari kita menyebarkannya! Lanjutkan dan buat file pada node pertama Anda bernama docker-compose.yml dan isi dengan konfigurasi di atas. Anda dapat melakukannya dengan mudah dengan echo "<pasted contents here>" > docker-compose.yml .

Biasanya, kami hanya dapat menerapkan ini, tetapi konfigurasi kami menyebutkan bahwa kami menggunakan rahasia yang disebut db_password , jadi mari kita cepat membuat rahasia itu:

 echo "supersecretpassword" | docker secret create db_password -

Besar! Sekarang yang perlu kita lakukan adalah memberi tahu Docker untuk menggunakan konfigurasi kita:

 docker stack deploy -c docker-compose.yml demo

Saat Anda menjalankan perintah ini, Anda akan melihat Docker membuat tiga layanan yang kami definisikan: web , nginx , dan redis . Namun, karena kami menamai demo tumpukan kami, layanan kami sebenarnya bernama demo_web , demo_nginx , dan demo_redis . Kita dapat melihat layanan yang sedang berjalan dengan menjalankan perintah docker service ls , yang akan menampilkan sesuatu seperti ini:

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

Voila! Docker telah mengunduh gambar kami ke node yang sesuai dan membuat wadah untuk layanan kami. Jika replika Anda belum dalam kapasitas penuh, tunggu sebentar dan periksa lagi. Docker kemungkinan masih mengunduh gambar.

Melihat Adalah Percaya

Jangan mengambil kata saya (atau kata Docker) untuk itu. Mari kita coba untuk terhubung ke aplikasi kita. Konfigurasi layanan kami memberi tahu Docker untuk mengekspos NGINX pada port 8000. Jika Anda menggunakan PWD, seharusnya ada tautan biru di bagian atas halaman yang bertuliskan “8000”. PWD sebenarnya secara otomatis mendeteksi bahwa kami memiliki layanan yang berjalan di port itu! Klik itu, dan itu akan mengarahkan Anda ke node yang dipilih pada port 8000. Jika Anda memutar server Anda sendiri, cukup navigasikan ke salah satu IP server Anda pada port 8000.

Anda akan disambut dengan layar bergaya indah yang memberi Anda beberapa informasi dasar:

Catat penampung mana yang melayani permintaan Anda, lalu segarkan halaman. Kemungkinan itu berubah. Tapi kenapa? Yah, kami memberi tahu Docker untuk membuat dua replika aplikasi Flask kami, dan itu mendistribusikan permintaan ke kedua instance tersebut. Anda baru saja menabrak wadah lain untuk kedua kalinya. Anda juga akan melihat bahwa jumlah permintaan meningkat karena kedua wadah Flask berkomunikasi dengan satu contoh Redis yang kami tentukan.

Jangan ragu untuk mencoba menekan port 8000 dari node mana pun. Anda masih akan diarahkan ke aplikasi dengan benar.

Mengungkap Keajaiban

Pada titik ini, semuanya bekerja, dan mudah-mudahan, Anda menemukan prosesnya tidak menyakitkan! Mari kita lihat lebih dekat file docker-compose.yml itu dan lihat apa yang sebenarnya kami katakan kepada Docker. Pada tingkat tinggi, kami melihat kami telah mendefinisikan tiga layanan: web , nginx , dan redis . Sama seperti file penulisan normal, kami telah menyediakan Docker dengan gambar untuk digunakan untuk setiap layanan, serta perintah untuk dijalankan. Dalam kasus nginx , kami juga telah menetapkan bahwa port 8000 pada host harus dipetakan ke port 80 dalam container. Semua ini adalah sintaks penulisan standar sejauh ini.

Apa yang baru di sini adalah kunci penyebaran dan rahasia. Kunci ini diabaikan oleh docker-compose , sehingga tidak akan memengaruhi lingkungan pengembangan Anda, tetapi digunakan oleh docker stack . Mari kita lihat layanan webnya. Cukup sederhana, kami memberi tahu Docker bahwa kami ingin menjalankan dua replika aplikasi Flask kami. Kami juga memberi tahu Docker bahwa layanan web memerlukan rahasia db_password . Inilah yang memastikan bahwa wadah akan memiliki file bernama /run/secrets/db_password yang berisi nilai rahasia.

Pindah ke Nginx, kita dapat melihat mode penyebaran diatur ke global . Nilai default (yang secara implisit digunakan di web) adalah replicated , yang berarti kita akan menentukan berapa banyak replika yang kita inginkan. Saat kami menentukan global , ia memberi tahu Docker bahwa setiap node dalam swarm harus menjalankan tepat satu instance layanan. Jalankan docker service ls lagi, Anda akan melihat bahwa nginx memiliki tiga replika, satu untuk setiap node di swarm.

Terakhir, kami telah menginstruksikan Docker untuk menjalankan satu instance Redis di suatu tempat di swarm. Tidak masalah di mana, karena wadah web kami dirutekan secara otomatis ke sana saat mereka meminta host Redis.

Menggunakan Swarm Hari ke Hari

Selamat atas penerapan aplikasi pertama Anda ke Docker Swarm! Mari luangkan waktu sejenak untuk meninjau beberapa perintah umum yang akan Anda gunakan.

Memeriksa Kawanan Anda

Perlu memeriksa layanan Anda? Coba docker service ls dan docker service ps <service name> . Yang pertama menunjukkan kepada Anda gambaran umum tingkat tinggi dari setiap layanan, dan yang terakhir memberi Anda informasi tentang setiap penampung yang berjalan untuk layanan yang ditentukan. Itu sangat membantu ketika Anda ingin melihat node mana yang menjalankan layanan.

Pembaruan Bergulir

Bagaimana bila Anda siap memperbarui aplikasi? Nah, hal keren tentang docker stack deploy adalah itu benar-benar akan menerapkan pembaruan ke tumpukan yang ada juga. Katakanlah Anda telah mendorong image Docker baru ke repositori Anda. Anda sebenarnya dapat menjalankan perintah penyebaran yang sama yang Anda gunakan pertama kali dan kawanan Anda akan mengunduh dan menyebarkan gambar baru.

Tentu saja, Anda mungkin tidak selalu ingin memperbarui setiap layanan di tumpukan Anda. Kami juga dapat melakukan pembaruan di tingkat layanan. Anggap saja saya baru saja memperbarui gambar untuk layanan web saya. Saya dapat mengeluarkan perintah ini untuk memperbarui semua wadah web saya:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

Manfaat tambahan untuk perintah itu adalah bahwa itu akan menerapkan pembaruan bergulir jika Anda menentukan bahwa itu harus dalam konfigurasi asli Anda. Dan bahkan jika tidak, Anda dapat meneruskan tanda untuk memperbarui yang akan menginstruksikannya untuk melakukan pembaruan bergulir seperti:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

Itu akan memperbarui satu wadah pada satu waktu, menunggu 30 detik di antara pembaruan.

Layanan Penskalaan Naik atau Turun

Memiliki dua wadah web itu bagus, tetapi Anda tahu apa yang lebih baik? Memiliki sepuluh! Scaling layanan naik dan turun dalam segerombolan semudah:

 docker service scale demo_web=10

Jalankan perintah itu dan periksa output dari docker service ps demo_web . Anda akan melihat bahwa kami sekarang memiliki sepuluh kontainer, dan delapan di antaranya telah dimulai beberapa saat yang lalu. Jika Anda tertarik, Anda juga dapat kembali ke aplikasi web dan menyegarkan halaman beberapa kali untuk melihat bahwa Anda sekarang mendapatkan lebih dari dua ID penampung asli.

Menghapus Tumpukan dan Layanan

Tumpukan dan layanan Anda diterapkan dan diskalakan, luar biasa! Tetapi sekarang Anda ingin menjadikannya offline. Ini dapat dilakukan dengan perintah rm masing-masing. Untuk menghapus tumpukan demo kami, jalankan perintah:

 docker stack rm demo

Atau, jika Anda lebih suka menghapus satu layanan, cukup gunakan:

 docker service rm demo_web

Menguras Node

Ingat ketika kita menjalankan docker node ls sebelumnya untuk memeriksa node di swarm kita? Ini memberikan banyak informasi pada setiap node, termasuk Availability -nya. Secara default, node adalah Active , yang berarti mereka adalah game yang adil untuk menjalankan container. Namun, ada kalanya Anda mungkin perlu membuat node offline sementara untuk melakukan pemeliharaan. Tentu, Anda bisa mematikannya dan kawanan itu akan pulih, tetapi ada baiknya memberi Moby (paus Docker) sedikit pemberitahuan.

Di sinilah pengeringan node masuk. Saat Anda menandai sebuah node sebagai Drain , Docker Swarm akan mendelegasikan container apa pun yang berjalan di atasnya ke node lain, dan tidak akan memulai container apa pun pada node sampai Anda mengubah ketersediaannya kembali ke Active .

Katakanlah kita ingin menguras node1 . Kita bisa menjalankan:

 docker node update --availability drain node1

Mudah! Saat Anda siap untuk mengaktifkannya kembali:

 docker node update --availability active node1

Membungkus

Seperti yang telah kita lihat, Docker yang digabungkan dengan mode Swarm memungkinkan kita untuk menerapkan aplikasi secara lebih efisien dan andal daripada sebelumnya. Perlu disebutkan bahwa Docker Swarm bukanlah satu-satunya mesin orkestrasi kontainer di luar sana. Bahkan, itu salah satu yang lebih muda. Kubernetes telah ada lebih lama dan pasti digunakan di lebih banyak aplikasi produksi. Yang mengatakan, Swarm adalah yang secara resmi dikembangkan oleh Docker, dan mereka bekerja untuk menambahkan lebih banyak fitur setiap hari. Apa pun yang Anda pilih untuk digunakan, tetaplah menyimpannya!