Build a Three-Node Docker Swarm

Build a local three-node Docker Swarm that restores NGINX after a worker fails.

Introduction

30 Second Summary

One computer usually feels like one machine. Reliable services often depend on several machines sharing the work when one becomes unavailable.

In this project, you will turn one Windows computer into a three-node Docker Swarm using three Ubuntu virtual machines. You will prove orchestration by keeping a replicated NGINX page available as the cluster replaces work from a stopped worker.

What You'll Build

Your finished lab keeps an NGINX welcome page available while Docker Swarm replaces work from a stopped worker.

By the end of this project, you'll have:

A three-node cluster view showing manager1 as Leader. Both workers appear Ready and Active.
A replicated NGINX service with three tasks distributed across local nodes. Its welcome page opens in your Windows browser on port 8080 through the routing mesh.
Visible recovery evidence after a worker interruption. The task history shows Docker Swarm restoring the service to three running replicas.
Secret Mission: A planned maintenance workflow that drains worker2 before returning it to Active availability.

Are there any prerequisites?

You need Windows 10 or Windows 11 Pro or Enterprise on x64 hardware.

Your account needs administrator rights on a computer with hardware virtualization enabled.

The lab requires at least 8 GB of total RAM, 20 GB of free disk space, and an internet connection.

Before We Start

Your goal is a three-node local Docker Swarm lab with manager1 managing desired state while worker1 and worker2 run assigned tasks. Automatic rescheduling will preserve the three-replica service when one worker is unavailable.

Set Up Windows and Launch Docker VMs

A real Docker Swarm needs independently addressable Docker Engines. One Windows computer therefore needs three isolated Linux virtual machines for this lab.

Microsoft Hyper-V provides the virtualization layer. Multipass uses that layer to create three Ubuntu nodes without requiring cloud accounts.

In this step, get ready to:

Confirm that Windows can host the lab with Hyper-V.
Prepare Multipass to install the pinned Docker Engine package.
Launch three Ubuntu VMs with Docker Engine ready.

Check the host before installing anything

The preflight prevents you from reaching a failed VM launch after a long installation. It checks the Windows edition plus the hardware that Hyper-V needs.

Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Right-click Windows PowerShell in the search results.
Select the administrator launch option from the context menu.
Approve the Windows permission prompt if it appears.
Inspect the host requirements by running this command:

Systeminfo.exe

What Does This Check Show?

The Windows details identify the installed edition plus the system architecture.
The memory total shows whether the host has enough capacity for three guests.
The Hyper-V Requirements section reports whether the processor plus firmware support virtualization.

Confirm that the host runs Windows 10 or Windows 11 Pro or Enterprise.
Confirm that the system architecture is 64-bit.
Confirm that the host has at least 8 GB of total RAM.
Press Windows+E to open File Explorer.
Select This PC in the navigation pane.
Confirm that the Windows system drive has at least 20 GB of free space.

Treat This as a Blocking Check

Continue only when the edition plus architecture meet the requirements. The lab also needs the stated RAM plus free disk space.

A passing virtualization result shows every Hyper-V requirement as Yes. An active hypervisor can instead show A hypervisor has been detected. Features required for Hyper-V will not be displayed.

✔️ Hyper-V is already active

Your host already has an active hypervisor. The virtualization layer is ready for Multipass.

ⓧ Requirements pass but Hyper-V is off

Enabling Hyper-V changes a Windows feature. Your computer may restart during this process.

Enable Hyper-V by running this command:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

What Does This Command Do?

The command enables the complete Microsoft Hyper-V feature from an administrator PowerShell session. Windows then prepares the hypervisor for Multipass.

Save any other open work before accepting the restart.
Accept the restart when Windows requests it.
Press the Windows key after the restart.
Type Windows PowerShell into the search field.
Right-click Windows PowerShell in the search results.
Select the administrator launch option from the context menu.

ⓧ A host requirement fails

Pause the lab at this point. Hyper-V cannot launch the three guests until every hardware requirement passes on a supported Windows edition.

Need Help With the Preflight?

Check the computer manufacturer's firmware instructions if virtualization is disabled. Confirm the installed Windows edition before attempting an upgrade.

Ask for help with the result:

Help me interpret my Windows Hyper-V preflight result.

Install Multipass and prepare Docker with cloud-init

Multipass needs a Private Windows network profile when it uses the Hyper-V driver. This allows the local VMs to communicate through the host network.

Press the Windows key to open Windows search.
Type Network status into the search field.
Open the matching Windows network setting.
Select the properties page for the active network connection.
Set the network profile to Private.

The lab pins Multipass to 1.16.4. Check the current state before choosing the matching setup path.

Check the installed Multipass client plus daemon versions by running this command:

multipass version

What Does This Check Show?

Multipass has a command-line client plus a background daemon. Both version entries must report 1.16.4 for this lab.

✔️ Client and daemon match

Your client plus daemon match the pinned release. Multipass is ready to create the Ubuntu nodes.

ⓧ I see an older version

Visit the official Multipass release page.
Download multipass-1.16.4+win-win64.msi.
Launch the downloaded installer with Administrator privileges.
Approve the Windows permission request if it appears.
Complete the Multipass installation.

Use a Fresh PowerShell Session

A new PowerShell session picks up the command installed by the MSI. Close the current session after installation completes.

Reopen Windows PowerShell with Administrator rights through Windows search.
Verify the updated client plus daemon by running:

multipass version

What Should I See?

The output should now report 1.16.4 for both Multipass entries. Matching versions confirm that the update is complete.

ⓧ Multipass is not installed

Visit the official Multipass release page.
Download multipass-1.16.4+win-win64.msi.
Launch the downloaded installer with Administrator privileges.
Approve the Windows permission request if it appears.
Complete the Multipass installation.

Use a Fresh PowerShell Session

The installer adds the Multipass command to Windows. A new PowerShell session loads that change.

Reopen Windows PowerShell with Administrator rights through Windows search.
Verify the new client plus daemon by running:

multipass version

What Should I See?

The output should report 1.16.4 for both Multipass entries. That result confirms that the installation is available from PowerShell.

Confirm that Multipass uses Hyper-V by running this command:

multipass get local.driver

Why Check the Driver?

Multipass can use different virtualization backends. This project depends on the hyperv driver so the three VMs can communicate on the local Hyper-V network.

You should see hyperv as the command output.

Multipass Version or Driver Check Failed?

Confirm that you reopened PowerShell after the MSI installation.
Confirm that Hyper-V completed its restart before checking the driver.
Ask for help with your Multipass setup.

A cloud-init file gives every Ubuntu VM the same package configuration during first boot. This keeps the Docker Engine version consistent across all three nodes.

Create the local swarm-lab folder on your Desktop by running these commands:

New-Item -Path "$HOME\Desktop\swarm-lab" -ItemType Directory
Set-Location -Path "$HOME\Desktop\swarm-lab"

What Do These Commands Do?

The first command creates swarm-lab on the current user's Desktop.
The second command makes that folder the current PowerShell location.

Press the Windows key to open Windows search.
Type Notepad into the search field.
Press Enter to open Notepad.
Paste the following configuration into the blank document:

#cloud-config
package_update: true
packages:
  - [docker.io, "29.1.3-0ubuntu3~24.04.2"]

What Does This Configuration Do?

The cloud-config header tells the Ubuntu image to process the file during first boot.
The package_update setting refreshes package metadata before package selection.
The packages section installs the pinned Ubuntu Docker package on every VM.
The package version provides Docker Engine 29.1.3 consistently across the cluster.

Save the document inside swarm-lab with the exact filename cloud-init.yaml.
Return to the administrator PowerShell session from earlier.
Display the saved file by running this command:

Get-Content -Path .\cloud-init.yaml

What Does This Check Prove?

The command reads cloud-init.yaml from the current folder. Seeing the four configuration lines confirms that PowerShell can find the file before Multipass uses it.

You should see the cloud-config header plus the pinned Docker package entry in PowerShell.

Cannot Find the Configuration File?

Confirm that Notepad saved the file inside the Desktop swarm-lab folder.
Confirm that the filename ends with .yaml instead of .txt.
Ask for help finding the saved file.

✔️ Awesome, I've got everything!

Your saved configuration matches the file that each VM needs during first boot.

ⓧ I'd like to double check the full code

#cloud-config
package_update: true
packages:
  - [docker.io, "29.1.3-0ubuntu3~24.04.2"]

Launch and verify the three nodes

Each VM receives 1 CPU plus 1 GB of memory. Each VM also receives a 6 GB virtual disk.

Each launch includes first-boot package installation. Allow a few minutes per VM because a quiet terminal during this work does not mean the launch has stalled.

Launch each Ubuntu 24.04 LTS node one at a time by running each line separately:

multipass launch 24.04 --name manager1 --cpus 1 --memory 1G --disk 6G --cloud-init .\cloud-init.yaml
multipass launch 24.04 --name worker1 --cpus 1 --memory 1G --disk 6G --cloud-init .\cloud-init.yaml
multipass launch 24.04 --name worker2 --cpus 1 --memory 1G --disk 6G --cloud-init .\cloud-init.yaml

What Do These Launch Commands Do?

Each command creates one separately addressable Ubuntu VM.
The resource options give every node the same CPU plus memory allocation.
The disk option creates persistent storage for each VM.
The cloud-init option installs the pinned Docker Engine package during first boot.

The three successful launches give you a manager candidate plus two worker candidates. Their Swarm roles are assigned in the next step.

Did a VM Fail to Launch?

Confirm that the active Windows network profile remains Private.
Confirm that the Hyper-V driver check still returns hyperv.
Confirm that PowerShell is still inside the Desktop swarm-lab folder.
Ask for help with the failed launch.

Before you run the final checks, predict the three VM names that will appear in the instance table.

Verify the running instances plus the manager's Docker server by running these commands:

multipass list
multipass exec manager1 -- sudo docker info

What Do These Checks Prove?

The instance list reports each VM name plus its current state.
The execution command runs Docker inside manager1.
Docker server details prove that the daemon started successfully inside the VM.

You should see manager1, worker1, plus worker2 in the Running state. Docker should print server information without a daemon connection error.

That is the setup complete. Your Windows computer now hosts three isolated Docker nodes for the Swarm lab.

Your three Docker Engines are ready. Next up, you connect them into one Swarm with a manager plus two workers.

Build the Swarm

Your three Ubuntu virtual machines are running Docker Engine. Each engine still operates alone.

Docker Swarm needs one manager to advertise a reachable IPv4 address. Each worker must explicitly join that manager.

In this step, get ready to:

Initialize manager1 as the Swarm manager.
Join worker1 plus worker2 to the swarm.
Inspect the node table to verify all three roles.

Initialize the manager

Swarm initialization creates cluster state on manager1. The advertised address tells other nodes where to reach the manager.

Display the runtime details for manager1 by running this command:

multipass info manager1

What does this command show?

The instance details include an IPv4 section.
The first address becomes the manager's advertised address.

Find the first address under IPv4.
Record that address here: <MANAGER-IP>.

Replace <MANAGER-IP> below with the address you recorded.
Initialize Swarm mode on manager1 by running this command:

multipass exec manager1 -- sudo docker swarm init --advertise-addr <MANAGER-IP>

What does this command do?

Multipass executes the nested command inside manager1.
Swarm mode turns the instance into the first manager node.
The advertise address gives workers a reachable destination.
Docker prints the worker join command for the next substep.

The first cluster milestone is complete. manager1 now owns the swarm state.

Swarm initialization not completing?

Check that <MANAGER-IP> matches the first address under IPv4.
Confirm that manager1 is still running in Multipass.

Help me troubleshoot Swarm initialization on manager1.

Join both workers

A worker join token authorizes a Docker Engine to enter this swarm. Both workers use the same runtime token from the manager.

Protect the join token

The token grants membership to your swarm. Treat it like a temporary credential for this lab.

Keep the token out of screenshots plus repositories.

Replace each <WORKER-TOKEN> placeholder with the generated worker token.
Replace each <MANAGER-IP> placeholder with the address you recorded.
Join both workers by running each command separately:

multipass exec worker1 -- sudo docker swarm join --token <WORKER-TOKEN> <MANAGER-IP>:2377
multipass exec worker2 -- sudo docker swarm join --token <WORKER-TOKEN> <MANAGER-IP>:2377

How do the workers join?

Each Multipass wrapper runs the Swarm join inside one Ubuntu VM.
The token authenticates the worker to the manager.
Port 2377 carries the manager join request.

After each command, you'll see This node joined a swarm as a worker.

That connection is the hard part done. Your three Docker Engines now form one cluster.

Worker not joining?

Confirm that the manager address matches the first value you recorded under IPv4.
Copy the complete worker token from the manager output.
Confirm that the worker instance is still running in Multipass.

Help me troubleshoot a worker that cannot join my Docker Swarm.

Inspect the cluster

Only a manager can inspect the full node table. This view connects each node's identity to its readiness plus scheduler availability.

Before you run the check, decide which node you expect to carry the Leader status.

Inspect the swarm from manager1 by running this command:

multipass exec manager1 -- sudo docker node ls

How do you read the node table?

manager1 shows Leader in the manager status column.
Both worker rows show Ready status.
Both worker rows show Active availability.
The manager maintains cluster state plus schedules work.
The workers execute tasks assigned by the manager.

Your node table now proves that one leader can coordinate two ready workers.

Missing a node from the table?

Confirm that you ran the inspection through manager1.
Return to the earlier join output for the missing worker.
Repeat that worker's join command with the complete runtime token.

Help me diagnose a missing or unavailable Swarm node.

Your three-node swarm is ready. Next, you'll give it a replicated service to coordinate.

Deploy an Unpublished Service

Your three Ubuntu nodes now form one Docker Swarm. The manager1 node coordinates work across the cluster.

Your first workload is a replicated service built from NGINX. Its desired state tells Swarm to keep three tasks running.

A healthy task table proves that the service works inside the cluster. External access requires a separate browser check.

In this step, get ready to:

Declare three NGINX replicas as the service's desired state.
Inspect the service until all three tasks are running.
Test whether Windows can reach the service on port 8080.

Declare three desired replicas

A replicated service gives Swarm one target to maintain. The manager schedules tasks until the cluster reaches that target.

Return to the administrative Windows PowerShell window from earlier.
Ask manager1 to create the web service with three replicas by running this command:

multipass exec manager1 -- sudo docker service create --name web --replicas 3 nginx:1.31.6-alpine

What does this command do?

The multipass command sends the request into manager1.
Docker Engine creates a service named web.
The --replicas option declares a target of 3 tasks.
The nginx:1.31.6-alpine image tag keeps every replica on the same NGINX release.

Keep the PowerShell window running while Docker creates the tasks.
Wait for the PowerShell prompt to return.

You should see task progress for the new service. The returned prompt shows that Docker accepted the service definition.

Service creation stuck?

Confirm that manager1 is still running if Multipass cannot reach the instance.
Check your internet connection if the NGINX image pull cannot complete.
Confirm that the command targets manager1 because service creation must run through a manager node.

Help me diagnose why the replicated service is not being created.

Inspect placement and convergence

Swarm convergence is the process of moving actual task count toward desired task count. Task inspection also shows which node received each replica.

Inspect the service summary and task placement by running these commands:

multipass exec manager1 -- sudo docker service ls
multipass exec manager1 -- sudo docker service ps web

What do these results show?

The first result compares the number of running replicas with the desired total.
The second result lists the node assigned to each task.
Current task rows show whether the service has reached its declared state.

Rerun both commands until the service reaches 3/3.
Compare the current task rows to identify each assigned node.

You should see web at 3/3. You should also see three current tasks in the Running state.

You now have your first replicated workload running across the Swarm.

Replicas still below 3/3?

Rerun the inspection after the nodes finish downloading the NGINX image.
Check the task details for a node or image problem if a replica does not enter the Running state.
Confirm that all three nodes remain Ready if task placement stalls.

Help me understand why my Docker Swarm service is not reaching three running replicas.

Test the Windows path

The cluster has passed its internal health check. Reachability from Windows remains a separate property.

Predict whether three Running tasks guarantee that Windows can load the page.

Press the Windows key to open the search panel.
Type browser into the search field.
Select your preferred installed browser from the results.
Enter http://<MANAGER-IP>:8080 in the address bar.

The browser cannot load the NGINX welcome page. This shortfall is the intended result.

Leave Windows Firewall unchanged.
Leave the virtual machine network unchanged.

Why does the request fail?

The three running tasks prove that Swarm is maintaining the service's desired state. The service definition has no published port for traffic from Windows.

Internal service health and external reachability are separate checks. Your failed browser request proves the difference.

Did the welcome page load anyway?

Confirm that the address bar uses the recorded manager address.
Confirm that the address ends with port 8080.
Check whether another application already responds at that address.

Help me investigate why an unpublished Docker Swarm service appears reachable from Windows.

You have proved that healthy replicas and browser reachability are separate concerns. Next, you will open the service through Swarm's routing mesh.

Publish the Service Through the Routing Mesh

Your three NGINX tasks are healthy inside Docker Swarm. Windows still has no published endpoint for reaching them.

Publishing web adds that missing endpoint through Swarm's ingress routing mesh. The routing mesh then sends incoming requests to an active task.

In this step, get ready to:

Map published port 8080 to container port 80.
Load the NGINX welcome page through the manager address.
Confirm that the service remains at 3/3 replicas.

Connect the ingress path

A published port is the swarm-facing entry point for incoming traffic. The target port is where NGINX listens inside each container.

Apply the port mapping from the administrative Windows PowerShell window by running these commands:

multipass exec manager1 -- sudo docker service update --publish-add published=8080,target=80 web
multipass exec manager1 -- sudo docker service ls

What do these commands do?

The --publish-add option changes the existing web service without recreating it.
The published=8080 value exposes port 8080 through the swarm.
The target=80 value sends that traffic to port 80 inside an NGINX container.
The second command checks the current replica count for the service.

Read the web row in the service table.
Confirm that its replica count remains 3/3.

That is the ingress path configured. The web service keeps all 3/3 replicas while gaining an external entry point.

Service update not finishing?

Confirm that manager1 is still running before retrying the update.
Check that the command targets manager1 because service updates must run on a manager.
Check that web still appears in the service table before retrying.

Help me troubleshoot the service update.

Test the ingress path

The published manager port now accepts traffic from Windows. Swarm can route each request to any active NGINX task.

Before you refresh, do you think the same address that failed earlier can now reach the service? Keep your prediction in mind.

Switch back to the Windows browser tab from earlier.
Refresh http://<MANAGER-IP>:8080.

There it is. The NGINX welcome page now loads through the routing mesh.

Before you run the final check, do you expect publishing the port to change the desired replica count? Keep your prediction in mind.

Confirm replica health from the administrative PowerShell window by running this command:

multipass exec manager1 -- sudo docker service ls

What does this check prove?

The service list compares the current task count with the desired replica count. Keeping web at 3/3 proves that publishing the port did not reduce the running replicas.

You now have both sides of the proof. The NGINX page loads while web stays at 3/3.

Welcome page still missing?

Confirm that the browser uses http://<MANAGER-IP>:8080 with the manager address you recorded earlier.
Confirm that PowerShell shows web at 3/3.
Confirm that the service update completed before refreshing the browser again.

Help me troubleshoot the missing welcome page.

Your replicated service is now reachable from Windows through the routing mesh. Next, you will stop a worker and watch Swarm restore the declared replica count.

Test Swarm Failure Recovery

Your replicated NGINX service now loads through the routing mesh. Next, you will interrupt one worker to test whether the cluster protects that service.

A working page only proves that the service is available right now. This test proves that Docker Swarm can restore its desired state after a node disappears.

In this step, get ready to:

Select a worker that hosts a current web task.
Observe Swarm replace the task after that worker stops.
Restore the worker to normal scheduling.

Choose the interruption target

The service task table shows which node runs each current replica. You need a worker with a current task so stopping it creates an observable gap.

Inspect the current task placement by running this command:

multipass exec manager1 -- sudo docker service ps web

How do you choose a worker?

Look at the current tasks whose state is Running.
Find a current task assigned to worker1 or worker2.
Use that worker as the interruption target.

Stopping one worker is deliberate here. Your manager stays running throughout the test.

Select the tab that matches the worker hosting the task you chose.

worker1 hosts a task

Trigger the interruption on worker1 by running this command:

multipass stop worker1

What does this command do?

Multipass stops the worker1 virtual machine. Its running Swarm task becomes unavailable to the cluster.

worker2 hosts a task

Trigger the interruption on worker2 by running this command:

multipass stop worker2

What does this command do?

Multipass stops the worker2 virtual machine. Its running Swarm task becomes unavailable to the cluster.

PowerShell returns control after Multipass stops the selected worker. The interruption is now active.

Worker does not stop?

Confirm that you used the name of a running worker. Keep manager1 running because it controls this lab's cluster state.

If the command still fails, help me diagnose why my selected Multipass worker will not stop.

Watch Swarm restore desired state

Swarm compares the running tasks with the declared replica count. The manager schedules a replacement when the stopped worker can no longer provide its task.

Predict what the node table will reveal about the stopped worker.
Inspect the node state plus the service task history by running these commands:

multipass exec manager1 -- sudo docker node ls
multipass exec manager1 -- sudo docker service ps web

What should you inspect?

The node table shows that the selected worker no longer reports a healthy Ready state.
The task table retains the task lost on the stopped worker.
The task table also shows a replacement assigned to an available node.

Recovery is asynchronous, so the first check can catch the replacement in progress. The declared replica count remains the manager's target.

Repeat the service task check until three current tasks reach Running by running this command:

multipass exec manager1 -- sudo docker service ps web

How does the history prove recovery?

The current rows show the three tasks satisfying the service's desired state. The older row records the task lost with the worker.

That combination proves the manager created a replacement instead of simply hiding the failed task.

You will see three current Running tasks on available nodes. The earlier task remains visible in the retained history.

Restore the worker after proving continuity

The routing mesh continues serving requests through available tasks during the interruption. The browser gives you a separate continuity check before you restore the worker.

Refresh http://<MANAGER-IP>:8080 in the Windows browser.

You will still see the NGINX welcome page. The published service remains available despite the missing worker.

Select the tab for the worker you stopped.

Restore worker1

Return worker1 to the cluster by running this command:

multipass start worker1

What happens when the worker starts?

Multipass starts the existing worker1 virtual machine. Its Docker Engine reconnects to the Swarm.

Restore worker2

Return worker2 to the cluster by running this command:

multipass start worker2

What happens when the worker starts?

Multipass starts the existing worker2 virtual machine. Its Docker Engine reconnects to the Swarm.

The selected virtual machine is running again. Its Swarm status can take another check to reflect the reconnection.

Worker does not return?

Confirm that you ran the start command for the same worker you stopped. A different worker name leaves the interrupted instance offline.

If the worker remains unavailable, help me reconnect my restored Multipass worker to Docker Swarm.

Predict what availability state the restored worker should report.
Run the final cluster plus service checks with these commands:

multipass exec manager1 -- sudo docker node ls
multipass exec manager1 -- sudo docker service ps web

What proves the test is complete?

The node table shows manager1 as Leader.
The node table shows both workers as Ready with Active availability.
The service table shows three current Running tasks plus the retained interruption history.
The returning worker may remain empty because Swarm does not move healthy tasks merely to rebalance them.

Secret mission

Drain a Worker for Planned Maintenance

An abrupt stop proved that Swarm can recover from failure. Now put worker2 into Drain availability so the scheduler moves its task before maintenance begins. Restore the worker to Active availability without forcing healthy tasks to rebalance.

Clean Up Your Resources

Every resource in this lab runs on your Windows computer, so there is no cloud bill. You have three cleanup paths: keep the lab running, pause its virtual machines, or remove it.

Resources you used:

Three Ubuntu virtual machines named manager1, worker1, and worker2, managed by Multipass.
One Docker Swarm led by manager1.
One three-replica NGINX service named web.
One local swarm-lab folder containing cloud-init.yaml.

Keep everything running

No action is needed. Choose this if you are still using the cluster.

Leave manager1, worker1, and worker2 running.
Return to the current NGINX browser address when you want to demonstrate the replicated service.
Allow the three VMs to keep using local CPU, memory, disk space, and network bandwidth.

Pause - I'll come back to this later

Pausing releases the CPU and memory used by the running VMs. Their virtual disks remain available for your next session.

Pause all three instances by running this command:

multipass stop manager1 worker1 worker2

What does this command do?

Multipass stops all three instances while keeping their virtual disks. Your Swarm stays stored for the next time you start the VMs.

Instances still running?

Confirm Windows PowerShell still has Administrator rights.
Get help diagnosing why the instances did not stop.

Use Multipass to start manager1, worker1, and worker2 when you return.

Delete - I don't want to use this again

This option permanently removes the running lab. The service and all three virtual disks are deleted.

Deletion is permanent

The service-removal command has no confirmation prompt. The VM purge cannot be undone.

Remove the web service first by running this command:

multipass exec manager1 -- sudo docker service rm web

What does this command do?

The manager asks Docker Swarm to remove the replicated web service. Its running tasks stop before you delete their VMs.

Service removal failed?

Confirm manager1 is running before retrying the removal.
Get help removing the service safely.

Permanently delete all three VMs by running this command:

multipass delete --purge manager1 worker1 worker2

What does this command do?

This permanently deletes all three Multipass instances. It also releases their virtual disks.

Removing every node also removes the Swarm stored inside the VMs.

VM purge failed?

Confirm no other Multipass operation is still running before retrying the purge.
Get help diagnosing the failed VM deletion.

Close Windows PowerShell after the purge finishes.
Press the Windows key to open search.
Enter File Explorer in the search box.
Press Enter to open File Explorer.
Navigate to the existing location that contains swarm-lab.
Select the swarm-lab folder.

Windows asks you to confirm before permanently deleting the selected folder.

Press Shift+Delete to remove the selected folder permanently.
Confirm the permanent deletion in the Windows prompt.
Verify that swarm-lab no longer appears in that File Explorer location.

Nice Work!

Brilliant work. Your three-node Docker Swarm kept a replicated NGINX service available through worker disruption.

You've learned how to:

Built a local three-node cluster across separate Ubuntu virtual machines on Hyper-V.
Deployed a three-replica NGINX service. Published it through the ingress routing mesh on port 8080.
Stopped a worker to test desired-state recovery. Watched Swarm create a replacement task while the welcome page remained reachable.
Secret Mission: Drained worker2 for planned maintenance. Restored it to Active availability after observing scheduler-controlled task rescheduling.

Ready to quiz yourself?