Understanding Docker Swarm Services and Stacks

You've probably deployed a few containers with Docker Compose, and now you're managing multiple services that need to work together. You could run each container individually with docker run, but that quickly becomes unmanageable. You need orchestration. Docker Swarm provides a native clustering solution that lets you manage a fleet of containers across multiple machines as if they were a single system. At the heart of Swarm orchestration are services and stacks—concepts that transform isolated containers into cohesive, scalable applications.

What Are Docker Swarm Services?

A Docker Swarm service is the primary building block for managing containers in a Swarm cluster. Unlike a standalone container, a service defines how Docker should run a container image. It specifies the image to use, the number of replicas to run, networking configuration, and resource constraints. When you create a service, Swarm schedules the specified number of container instances across the available nodes in your cluster.

Services differ from containers in several important ways. A container is a running instance of an image. A service is a declarative specification that tells Swarm how to manage containers. If you create a service with three replicas, Swarm ensures that exactly three containers are running, regardless of node failures or scaling events. If one container crashes, Swarm automatically replaces it with a new instance.

Services also provide built-in load balancing. When you expose a service on a port, Swarm distributes incoming traffic across all running container instances. This horizontal scaling capability is essential for handling increased traffic without manual intervention.

Service Configuration Components

Every service definition includes several key components that determine its behavior. The image field specifies which Docker image to run. You can use a public image from Docker Hub or a private registry. The replicas field defines how many instances of the container should run. For production workloads, you typically set this to three or more to ensure high availability.

Networking configuration is another critical component. Services can communicate with each other using internal Swarm networking, which provides DNS resolution and automatic load balancing. You can also expose services to the outside world by publishing ports, making them accessible from other hosts.

Resource constraints help prevent runaway containers from consuming all available resources. The deploy.resources section lets you specify CPU and memory limits and reservations. These limits ensure that a single service cannot monopolize system resources, which is especially important in multi-tenant environments.

Service Discovery and Load Balancing

One of the most powerful features of Swarm services is automatic service discovery. When you create a service, Swarm assigns it a DNS name. Other services can resolve this name to any of the running container instances. This eliminates the need for manual IP address management or service registration.

Consider a web application with a frontend service and a backend API service. The frontend service needs to communicate with the backend API. Instead of hardcoding IP addresses or using environment variables, the frontend can simply call backend-service:8080. Swarm handles the routing automatically, distributing requests across all backend instances.

Load balancing happens at the network level. When you publish a service port, Swarm creates an ingress load balancer that distributes incoming traffic across all container instances. This load balancer is transparent to your applications—they don't need any special configuration to benefit from it.

Internal vs External Networking

Swarm provides two types of networking for services. Internal networking allows services to communicate with each other without exposing ports to the outside world. This is ideal for backend services that should only be accessible within the cluster. External networking exposes services to the wider network, making them accessible from other hosts.

When you publish a port with publish.mode: host, Swarm binds the port directly to the host machine. This is useful for services that need to bind to specific ports or require direct network access. When you use publish.mode: ingress, Swarm uses the load balancer to distribute traffic, which provides better scalability and security.

What Are Docker Stacks?

While services are powerful, managing them individually becomes cumbersome as your application grows. You might have a dozen services that all need to be deployed together, with specific relationships between them. This is where Docker stacks come in. A stack is a collection of services defined in a single Docker Compose file. Stacks let you deploy and manage multiple related services as a single unit.

Stacks provide a higher level of abstraction than services. Instead of creating each service separately with docker service create, you define all services in a Compose file and deploy them with a single command. This makes it easy to maintain complex applications with many interdependent services.

Stacks also support environment-specific configurations. You can create different Compose files for development, staging, and production, each with appropriate settings. This separation ensures that your staging environment closely mirrors production while keeping development configurations lightweight.

Stack Deployment and Management

Deploying a stack is straightforward. You use the docker stack deploy command, specifying the stack name and the path to the Compose file. Swarm then reads the file, creates the necessary networks, and deploys all the services. If a service already exists, Swarm updates it to match the new configuration.

Managing stacks is equally simple. You can list all deployed stacks with docker stack ls, inspect a specific stack with docker stack ps, and remove a stack with docker stack rm. These commands work at the cluster level, so you can manage services across multiple nodes from a single machine.

Stacks also support rolling updates. When you update a service in a stack, Swarm can perform a rolling update that gradually replaces old instances with new ones. This minimizes downtime and ensures that your application remains available during updates. You can control the update strategy with parameters like update_parallelism, update_delay, and update_failure_action.

Comparing Service and Stack Approaches

Understanding when to use services versus stacks requires looking at the scale and complexity of your deployment. Services are ideal for individual components that need to be managed independently. You might create a service for a database, another for a caching layer, and yet another for a background worker. Each service can be scaled and updated separately.

Stacks shine when you have a complete application with multiple interdependent services. A typical web application might include a frontend service, a backend API service, a database service, and a caching service. All of these services need to be deployed together, with specific networking and configuration requirements. A stack makes it easy to manage this entire application as a single unit.

The table below compares services and stacks across several key dimensions:

Practical Walkthrough: Deploying a Web Application Stack

Let's walk through deploying a complete web application stack with Docker Swarm. This example includes a frontend service, a backend API service, and a PostgreSQL database. We'll use a simple Node.js application for demonstration purposes.

Step 1: Prepare the Application

First, create a directory for your application and add the necessary files. You'll need a docker-compose.yml file that defines all services. Here's a complete example:

version: "3.8"
 
services:
  frontend:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - app-network
    depends_on:
      - backend
 
  backend:
    image: node:18-alpine
    working_dir: /app
    command: node server.js
    networks:
      - app-network
    environment:
      - DATABASE_URL=postgres://postgres:password@postgres:5432/mydb
    depends_on:
      - postgres
 
  postgres:
    image: postgres:15-alpine
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=mydb
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - app-network
 
networks:
  app-network:
    driver: overlay
 
volumes:
  postgres-data:

This Compose file defines three services: frontend, backend, and postgres. The frontend service runs Nginx and exposes port 80. The backend service runs a Node.js application that connects to the database. The postgres service runs PostgreSQL with a persistent volume for data storage.

Step 2: Initialize the Swarm Cluster

Before deploying services, you need to initialize the Swarm cluster. Run this command on the machine where you want to create the swarm:

docker swarm init

This command initializes the Swarm on the current node. If you have multiple machines, you can join them to the cluster using the docker swarm join command. For this example, we'll work with a single-node cluster.

Step 3: Deploy the Stack

Now deploy the stack using the Compose file:

docker stack deploy -c docker-compose.yml myapp

The -c flag specifies the Compose file, and myapp is the name of the stack. Swarm reads the file, creates the necessary networks, and deploys all three services. You can verify the deployment with:

docker stack ps myapp

This command shows the status of all services in the stack. You should see all three services in the Running state.

Step 4: Verify the Deployment

Check that all services are running:

docker service ls

You should see three services: myapp_frontend, myapp_backend, and myapp_postgres. Each service shows the number of running replicas and the current status.

Test the application by accessing the frontend service:

curl http://localhost

You should receive a response from the Nginx server. This confirms that the frontend is accessible and communicating with the backend.

Step 5: Scale the Frontend Service

Scale the frontend service to run five instances:

docker service scale myapp_frontend=5

Swarm immediately creates four additional replicas, distributing them across the available nodes. You can verify the scaling with:

docker service ps myapp_frontend

All five instances should be in the Running state. The load balancer automatically distributes incoming traffic across all instances.

Step 6: Update the Stack

Modify the backend service to use a different Node.js version. Update the docker-compose.yml file:

backend:
  image: node:20-alpine
  working_dir: /app
  command: node server.js
  networks:
    - app-network
  environment:
    - DATABASE_URL=postgres://postgres:password@postgres:5432/mydb
  depends_on:
    - postgres

Redeploy the stack with:

docker stack deploy -c docker-compose.yml myapp

Swarm performs a rolling update, replacing old instances with new ones. You can monitor the update progress with:

docker service ps myapp_backend

The update completes when all instances are running the new version.

Step 7: Remove the Stack

When you're done with the application, remove the stack:

docker stack rm myapp

Swarm gracefully shuts down all services and removes the stack. The persistent volume for PostgreSQL remains, so you can recreate the stack later without losing data.

Best Practices for Services and Stacks

Managing services and stacks effectively requires following some best practices. Keep your service definitions focused and modular. Each service should have a single responsibility. This makes it easier to understand, test, and maintain individual components.

Use environment-specific Compose files for different deployment environments. Create docker-compose.dev.yml, docker-compose.staging.yml, and docker-compose.prod.yml files with appropriate settings. This separation ensures that your staging environment closely mirrors production while keeping development configurations lightweight.

Monitor your services regularly. Use Docker's built-in monitoring tools or integrate with external monitoring solutions. Watch for resource usage, error rates, and performance metrics. Early detection of issues prevents problems from escalating.

Implement proper logging. Configure logging drivers for your services to centralize log collection. This makes it easier to troubleshoot issues and analyze application behavior. The json-file driver is the default, but you can configure other drivers like syslog or journald.

Conclusion

Docker Swarm services and stacks provide powerful abstractions for managing containerized applications at scale. Services let you define how containers should run, with automatic scaling, load balancing, and high availability. Stacks let you deploy and manage multiple related services as a single unit, simplifying complex deployments.

The key takeaways are that services are the building blocks for individual components, while stacks are the containers for complete applications. Services provide the low-level orchestration capabilities, while stacks provide the high-level management interface. Together, they enable you to deploy and manage complex applications with minimal manual intervention.

For teams using ServerlessBase, the platform handles the underlying infrastructure management, including Swarm orchestration, networking, and load balancing. This lets you focus on your application code while ServerlessBase manages the deployment platform.