• Make sure you have published the friendlyhello image you created by . We’ll use that shared image here.

• Be sure your image works as a deployed container. Run this command, slotting in your info for username, repo, and tag: docker run -p 80:80 username/repo:tag, then visit http://localhost/.

 

 scale our application and enable load-balancing. To do this, we must go one level up in the hierarchy of a distributed application: the service.

• Stack
• Services (you are here)
• Container (covered in )

 

About services

In a distributed application, different pieces of the app are called “services.”

For example, if you imagine a video sharing site, it probably includes a service for storing application data in a database, a service for video transcoding in the background after a user uploads something, a 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.

Luckily it’s very easy to define, run, and scale services with the Docker platform – just write a docker-compose.yml file.

docker-compose.yml file

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

Be sure you have  you created in  to a registry, and update this .yml by replacingusername/repo:tag with your image details.

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:      - "80:80"    networks:      - webnetnetworks:  webnet:

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

• Pull  from the registry.

• Run 5 instances of that image as a service called web, limiting each one to use, at most, 10% of the CPU (across all cores), and 50MB of RAM.

• Immediately restart containers if one fails.

• Map port 80 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 will 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).

 

 

Run new load-balanced app

Before we can use the docker stack deploy command we’ll first run:

docker swarm init

 If you don’t run docker swarm init you’ll get an error that “this node is not a swarm manager.”　

 Now let’s run it. You have to give your app a name. Here, it is set to getstartedlab:

docker stack deploy -c docker-compose.yml getstartedlab

Our single service stack is running 5 container instances of our deployed image on one host

Get the service ID for the one service in our application:

docker service ls

You’ll see output for the web service, prepended with your app name. If you named it the same as shown in this example, the name will be getstartedlab_web. The service ID is listed as well, along with the number of replicas, image name, and exposed ports. A single container running in a service is called a task. Tasks are given unique IDs that numerically increment, up to the number of replicas you defined indocker-compose.yml. List the tasks for your service:

docker service ps getstartedlab_web

Tasks also show up if you just list all the containers on your system, though that will not be filtered by service:

docker container ls -q

 

You can run curl -4 http://localhost several times in a row, or go to that URL in your browser and hit refresh a few times.

 Either way, you’ll see the container ID change, demonstrating the load-balancing; with each request, one of the 5 tasks is chosen, in a round-robin fashion, to respond. The container IDs will match your output from the previous command (docker container ls -q).

 

Running Windows 10?

Windows 10 PowerShell should already have curl available, but if not you can grab a Linux terminal emulater like , or download which is very similar.

Slow response times?

Depending on your environment’s networking configuration, it may take up to 30 seconds for the containers to respond to HTTP requests. This is not indicative of Docker or swarm performance, but rather an unmet Redis dependency that we will address later in the tutorial. For now, the visitor counter isn’t working for the same reason; we haven’t yet added a service to persist data.

 

Scale the app

You can scale the app by changing the replicas value in docker-compose.yml, saving the change, and re-running the docker stack deploy command:

docker stack deploy -c docker-compose.yml getstartedlab

Docker will do an in-place update, no need to tear the stack down first or kill any containers.

Now, re-run docker container ls -q to see the deployed instances reconfigured. If you scaled up the replicas, more tasks, and hence, more containers, are started.

 

 

Take down the app and the swarm

• Take the app down with docker stack rm:

docker stack rm getstartedlab　

• Take down the swarm.

docker swarm leave --force

 Compose files like this are used to define applications with Docker, and can be uploaded to cloud providers using , or on any hardware or cloud provider you choose with .

 

 To recap, while typing docker run is simple enough, the true implementation of a container in production is running it as a service. Services codify a container’s behavior in a Compose file, and this file can be used to scale, limit, and redeploy our app. Changes to the service can be applied in place, as it runs, using the same command that launched the service: docker stack deploy.

docker stack ls                                            # List stacks or appsdocker stack deploy -c 
      
      
         # Run the specified Compose filedocker service ls                 # List running services associated with an appdocker service ps 
       
                          # List tasks associated with an appdocker inspect 
        
                            # Inspect task or containerdocker container ls -q                                      # List container IDsdocker stack rm 
         
                                       # Tear down an applicationdocker swarm leave --force      # Take down a single node swarm from the manager