Docker Swarm Là Gì
Bao gồm các Manager và các Worker. Tín đồ dùng hoàn toàn có thể khai báo trạng thái mong muốn của khá nhiều service nhằm chạy vào Swarm áp dụng YAML files.
Bạn đang xem: Docker swarm là gì

Làm việc với Docker Swarm
Trong phần này ta sẽ tiến hành thực hành với Docker Swarm trải qua demo nhỏ.Đầu tiên ta phải 4 thứ ảo (vps ảo) nhằm tạo những máy ảo ta sử dụng câu lệnh sau:
$ docker-machine create vào đó:
: tên thứ ảo bạn muốn đặt.Tạo machine(máy ảo) mang lại swarm manager:
$ docker-machine create managerTiếp mang lại là những machine cho swarm worker theo thứ tự là : worker1, worker2, worker3.
$ docker-machine create worker1$ docker-machine create worker2$ docker-machine create worker3Sau khi tạo xong xuôi ta kiểm tra list machine:
$ docker-machine ls

Bây giờ đồng hồ ta áp dụng lệnh inspect demo xem thông tin của một machine
$ docker-machine inspect manager

Dễ thấy một vài thông tin cơ phiên bản về machine như: địa chỉ IP, MachineName (tên vị ta đặt), SSHKey để rất có thể truy cập vào machine thông qua SSHKey này, thông tin về CPU ( 1 CPU), Memory ( 1GB), ….
Việc thiết lập các machine đang hoàn tất giờ ta tiến hành khởi sinh sản swarm trên con manager nhé cùng để truy vấn vào nhỏ manager hay các con worker thì ta sử dụng trải qua SSH rõ ràng như sau:
$ docker-machine ssh Ở đây:
= managerVà để quay trở về host local:
$ exitKhởi tạo ra swarm
$ docker swarm init --advertise-addr nếu như khách hàng đang sử dụng Docker Desktop for Mac hoặc Docker Desktop for Windows thì chỉ cần docker swarm init . Nhưng tại đây Operating System là Boot2Docker đề xuất buộc phải gồm flag --advertise-addr.

Kiểm tra list node hiện đang có trong swarm
$ docker node ls

Những node (machine/vps) là manager thì mới có xem menu này và dấu * cho biết bạn sẽ ở node manager nào trong swarm. Ở phía trên ta chỉ có một node manager với node này đã ở status Ready. OK ! vậy là chấm dứt nhiệm vụ ở nhỏ manager.
Giờ ta chuyển qua làm vấn đề trên nhỏ worker1 nhé. Tại worker1 ta thực hiện join nó vào swarm như một worker:
$ docker swarm join --token :Trong đó:
host: Địa chỉ ip của con manager.port: Cổng port của nhỏ manager.Xem thêm: Giải Vở Bài Tập Lịch Sử Lớp 7 Bài 8 : Xô Viết Nghệ, Giải Vở Bài Tập Lịch Sử 7 Bài 8
Để lấy tin tức về token thì trên nhỏ manager của swarm kia ta thực hiện lệnh
$ docker swarm join-token

Trên hai nhỏ worker2 và worker3 ta cũng làm tương tự
Lưu ý: một node worker chỉ có thể join vào một trong những swarm.
Trên node manager ta kiểm tra lại danh mục node

Vậy là ta đã tạo thành công 3 con worker và 1 con manager và gom chúng thành một swarm (cluster).
Một thắc mắc được đặt ra ở đây là tại sao tại đây ta không tận dụng chiếc swarm cơ mà ta đã tạo ra ở Phần 3 tại trang bị host local (Docker Desktop for Mac) và coi nó như một node manager để join các node khác vào swarm này nhưng mà lại tạo ra thêm một machine để làm node manager chi cho giá thành tài nguyên như thế ? Thì câu vấn đáp nằm sống Phần 3 (đã có nói siêu rõ) bên trên phiên phiên bản Docker Desktop for Mac cấp thiết mở luồng định đường tới những machine nên việc ta cố gắng join các node (machine/vps) vào swarm cùng với manager swarm là host local là vô tác dụng. Đây cũng chính là điểm yếu khi tiến hành networking bên trên OSX.
Bây tiếng ta tiếp tục tạo ra service và những replicas cũng giống như deploy trên node manager.
Để có tác dụng được vấn đề này ta đề nghị config tệp tin docker-compose.yml:
version: "3"services: webreactjs: image: quanphamptit/docker-swarm-demo:webreactjs_1 build: . Ports: - 3000:3000 restart: always networks: - my-net deploy: mode: replicated replicas: 3 servergo: image: quanphamptit/docker-swarm-demo:servergo_1 build: . Ports: - 8080:8080 restart: always networks: - my-net deploy: mode: replicated replicas: 3networks: my-net: driver: overlayvà copy file docker-compose.yml nhưng mà ta vẫn config qua bên bé manager:
$ docker-machine scp filesource name-machine:/path-docker-machine/Trong kiểm tra này:
$ docker-machine scp ~/Workspace/gocode/docker-swarm-demo/docker-compose.yml manager:/home/docker/docker-compose.ymlTiếp theo ta đề nghị push 2 image cơ mà ở Phần 2 ta đã sử dụng lên repository bên trên hub.docker nhé:
$ docker tag /:$ docker push /Trong đó:
: Id image bạn muốn push
: là username bên trên hub.docker của bạn.
: tên repository bạn có nhu cầu đặt.
: tên tag bạn muốn đặt mang đến image được push lên đó.

Trên Docker Hub

Vậy là ta sẽ push thành công xuất sắc 2 image với giờ ta đề nghị deploy stack :
$ docker stack deploy -c /home/docker/docker-compose.yml swarm-demo-appKiểm tra list services:

Ta test xem các bạn dạng replicas này đang chạy trên những node làm sao nhé:

Ngoài ra chúng ta cũng có thể tạo service dùng lệnh cùng với cú pháp như sau:
$ docker service create --replicas --name vào đó:
: số task bạn muốn tạo ra ( hay nói theo cách khác là số bản sao của image/container).: tên service bạn có nhu cầu đặt.: ID của image/container.: lệnh ao ước chạy.Và ta gồm thể biến hóa số container của cluster một cách mau lẹ bằng câu lệnh sau:
$ docker service scale =Trong đó :
: tên service nhưng mà ta mong mỏi đổi số container.: Số container mong muốn.Tiếp theo ta đã xem demo liệu tác dụng load balancing hoạt động thế như thế nào nhé ?
Ta thấy trên con node worker3 không có giữ replicas của service servergo_1 nào cả. Ta triển khai gửi request thử tới service servergo_1 trên con worker3 này xem sao nhé !
$ curl http://192.168.99.103:8080/api/v1/foods?id=2

Điều này tức là khi ta gửi các request đến các node vào swarm. Các node này hoàn toàn có thể chứa một hoặc các replicas của các service hoặc không thể chứa loại replicas nào cả thì Routing mesh của swarm sẽ chuyển tiếp các request đó trải qua ingress network cho tới Swarm Load Balancer, bộ balancer này sẽ phân bổ request tới các container của những service ở các machine( host/vps của manager cùng worker) cùng phổ biến một mạng swarm. Bạn có thể xem hình sau để làm rõ hơn:

Thử lại với những request khác:

Bây tiếng ta demo shutdown bé machine worker1 ( như trên thực tế khi 1 server bị die ) xem có điều mới mẻ gì ko nhé !
$ docker-machine stop Ở phía trên :
= worker1
Kiểm tra lại danh mục node với service bên trên node manager


Tại đây ta đã thấy điều mới mẻ đó. Khi worker1 bị Shutdown thì hôm nay swarm manager sẽ triển khai tạo thêm 1 replicas bắt đầu để rứa để cho một replicas đã trở nên Shutdown đó và tiến hành chuyển 1 replicas mới này cho các worker sẽ run (cụ thể là worker3). Đây cũng chính là tính năng Desired state reconciliation, Scaling đã được nói rõ trong phần Tính năng Docker Swarm.
Vậy sự việc nảy sinh tại chỗ này khi toàn cục node worker bị die thì điều gì sẽ xảy ra tiếp nối ?
Trong trường vừa lòng này node manager cũng sẽ tiến hành thêm các replicas để bảo vệ đủ số replicas nhưng mà ta sẽ config (mong muốn) với chạy trên chính con manager này ( nghĩa là node manager đã đóng mục đích là node worker luôn). Cùng nếu bé manager này die luôn luôn thì hầu như chuyện coi như ngã ngũ !!.
Xem thêm: Từ Khi Em Biết 18 Là Gì - Có Nên Mua Sim Số Đẹp Chứa Số 18
Trường hợp ngược lại nếu các node worker sẽ run nhưng bé node manager bị die thì external storage đang ghi nhận điều ấy và thông tin đến các manager node còn sót lại trong cluster. Với external storage sẽ chọn một node manager bất kỳ để có tác dụng Leader tiếp theo của cluster.

Nếu bạn có nhu cầu xem được những bài viết chất lượng, hay luận bàn những con kiến thức, share hiểu biết của doanh nghiệp đến phần lớn người, hãy thâm nhập group của đàn mình trên Facebook nhé: ^^