Services in Docker

In a distributed application, different pieces of the app are called “services”. Example:
if you imagine a video sharing site, it probably includes:
a) service for storing application data in a database
b) service for video transcoding in the background after a user uploads something
c) service for the front-end, and so on.

Services are really just “containers in production.”
A service only runs one image, but it codifies the way that image runs — what ports it should use, how many replicas of the container should run so the service has the capacity it needs, and so on. Scaling a service changes the number of container instances running that piece of software, assigning more computing resources to the service in the process.

A docker-compose.yml file is a YAML file that defines how Docker containers should behave in production.

docker-compose.yml

version: "3"
services:
  web:
    # replace username/repo:tag with your name and image details
    image: username/repo:tag
    deploy:
      replicas: 5
      resources:
        limits:
          cpus: "0.1"
          memory: 50M
      restart_policy:
        condition: on-failure
    ports:
      - "4000:80"
    networks:
      - webnet
networks:
  webnet:

This docker-compose.yml file tells Docker to do the following:

• Run 5 instances of that image as a service called web, limiting each one to use, at most, 10% of a single core of CPU time (this could also be e.g. “1.5” to mean 1 and half core for each), and 50MB of RAM.
• Immediately restart containers if one fails.
• Map port 4000 on the host to web’s port 80.
• Instruct web’s containers to share port 80 via a load-balanced network called webnet. (Internally, the containers themselves publish to web’s port 80 at an ephemeral port.)
• Define the webnet network with the default settings (which is a load-balanced overlay network).