> For the complete documentation index, see [llms.txt](https://www.ankitavirani.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.ankitavirani.com/experience/devops-infrastructure/docker-swam.md).
# Docker Swam
Docker swarm is a container orchestration system, very similar to kubernetes.
**Core concepts**
ServicesTasksContainers
**Kubernetes vs Docker swarm**
| Kubernetes | Docker swarm |
| -------------------------------------- | ------------------------- |
| Very hard to understand | Much easier to understand |
| Much more prod ready, adopted and used | Not used as often |
| Supports autoscaling | Have to scale it manually |
| Need to install/understand kubectl | Works with the docker cli |
\
Architecture
#### Manager Node
Manager nodes handle cluster management tasks:
* Maintaining cluster state
* Scheduling services
#### Worker Node
Worker nodes are also instances of Docker Engine whose sole purpose is to execute containers.
## Services, tasks, containers
To deploy an application image when Docker Engine is in Swarm mode, you create a service. Frequently a service is the image for a microservice within the context of some larger application (eg - HTTP Server)
* Service - A service is the definition of how you want to run your application in the swarm. It specifies the desired state, including the number of replicas, the image to use, the command to run, and other configurations such as networks and volumes.
* Task - A task is a single instance of a service running on a node. Each task represents one container and its associated metadata. When you create a service with multiple replicas, Docker Swarm creates a task for each replica.
* Container - A container is a running instance of a Docker image. Each task maps to one container. The swarm orchestrator ensures the tasks (and thus the containers) are distributed across the nodes in the swarm according to the defined service specifications.
## Services, tasks, containers
To deploy an application image when Docker Engine is in Swarm mode, you create a service. Frequently a service is the image for a microservice within the context of some larger application (eg - HTTP Server)
* Service - A service is the definition of how you want to run your application in the swarm. It specifies the desired state, including the number of replicas, the image to use, the command to run, and other configurations such as networks and volumes.
* Task - A task is a single instance of a service running on a node. Each task represents one container and its associated metadata. When you create a service with multiple replicas, Docker Swarm creates a task for each replica.
* Container - A container is a running instance of a Docker image. Each task maps to one container. The swarm orchestrator ensures the tasks (and thus the containers) are distributed across the nodes in the swarm according to the defined service specifications.
## Deploying a service
* Deploy the nginx service
```javascript
docker service create --replicas 3 --name helloworld -p 3000:80 nginx
```
* Check the status of the service
```javascript
docker service ls
```
* Go to the machine URL on port 3000 and ensure you see it running
```javascript
your_machine_ip:3000
```
* Try deleting a few pods and see if they come back up
* Delete the service
```javascript
docker service rm helloworld
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://www.ankitavirani.com/experience/devops-infrastructure/docker-swam.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
