Docker in English

Docker

The blog is based on the offical document

Get started

Get stared with Docker

Orientation

[toc]
Containerization is incresasingly popular because containers are:

• Flexible:Even the most complex applications can be containerized.
• Lightweight:Containers leverage and share the host kernel
• Interchangeable:you can deploy updates and upgrades on-the-fly.
• Portable:you can build locally,deplpy to the cloud, and run anywhere.
• scalable: you can increase and automatically distribute container replicas.
• stackable:you can stack services vertically and on the fly.

test docker version:

• docker –version
• docker info
• docker run hello-world
• docker images ls
• docker container ls –all

containers

These portable images are defined by something called a Dockerfile.

Dockerfile

create an empty directory. change directories into the new directory, create a file called Dockerfile,copy-and-paste the following content into that file,and save if, Take note of the comments that explain each statement in you new Dockerfile.

some thing about python dockefile.

now we see that pip install -r requirements.txt installs the flask and redis libraries for python,and the app prints the evironment varibale Name, as well as the output of a call to socket.gethostname().Finally, because redis isn’t running（as we’ve only installed the python library,and not Redis itself),we should expect that the attempt to use it here fails and produces the error message.

“

#Use an official Python runtime as a parent image
FROM python:2.7-slim
# Set the working directory to /app
WORKDIR /app
# Copy the current directory contents into the container at /app
ADD . /app
# Install any needed packages specified in requirements.txt
RUN pip install –trusted-host pypi.python.org -r requirements.txt
# Make port 80 available to the world outside this container
EXPOSE 80
# Define environment variable
ENV NAME World
# Run app.py when the container launches
CMD [“python”, “app.py”]

some error in the above offical document
you need to change the -r requirements.txt to -r /app/requirements.txt due to you already running in the container, so you want to run the script in the container.

This port remapping of 4000:80 is to demonstrate the difference between what you expose within the dockerfile,and what you publish using docker run -p .

Now let’s run the app in the background,in detached mode:
docker run -d -p 4000:80 friendlyhello

share your image

docker run -p 4000:80 username/repository:tag

No matter where docker run executes,it pulls your image,along with python and all the dependencies from requirements.txt,and runs your code. it all travels together in a neat little package, and you don’t need to install anything on the host machine for docker to run it.

services

About service

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

service are really just “containers in production”.A service only runs one image,but it condifies 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 docker platform.

you first docker-compose.yml file

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

docker-compose.yml

Save the file as docker-compose.yml wherever you want.Be sure you have pushed the image you created in Part 2 to registry,and update this .yml by replacing username/repo:tagwith 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:
- webnet
networks:
webnet:

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

• pull the image we uploaded in step 2 from the registry.
• run 5 instance 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 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 your new load-balanced app

before we can use the docker stack deploy command we first run:
docker swarm init

Now let’s run it, you need to give your app a name. here it is set to getsstartedlab:

docker stack deploy -c docker-compose.yml getstartedlab


our single service stack is running 5 container instance of our deployed image on one host.let’s investigate.

get the service id for the one service in our application:

docker service ls

look for output for the web service ,prepended with your app name.if you named it the same as shown in this example, the name is 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 numercially increment,up to the number of replicas you defined in docker-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 is not filtered by service:
docker ps

Either way,the container ID changes,demonstrating the load-balancing;with each request,one of the 5 tasks is chosen, in a round-robin fashion, to respond.the container IDs match your output from the previous command.

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 statck deploy -c docker-compose.yml get startedlab


take down the app and the swarm

docker stack rm getstartedlab


docker swarm leave --force
it’s as easy as that to stand up and scale your app with Docker, you’ve taken a huge step towards learning how to run containers in production.up next, you learn how to run this app as bonafiede swarm on a cluster of docker machines.

Swarms

Introduction

here in part 4,you deploying this application onto a cluster,running it on multiple machines,multi-container,multi-machine applications are made possible by joining multiple machines into a ‘Dockerized’ cluster called a swarm.

uderstand swarm clusters

A swarm is a group of machines that are running Docker an joined into a cluster.After that has happened,you continue to run the docker commands you’re used to,but now they are executed on a cluster by a swarm manager. the machine in a swarm can be physical or virtual. after joining a swarm, they are referred to as nodes.
swarm manager can use several strategies to run containers, such as ‘emptiest node’-which fills the lest utilized machines with containers,Or ‘global’,which ensures that machine gets exactly one instance of the specified container. you instruct the swarm manager to use these strategies in the compose file,just like the one you have already been using.
swarm managers are the only machines in a swarm that can execute your commands,or authorize other machines to join the swarm as workers.workers are just there to provide capacity and do not have the authority to tell any other machine what it can and cannot do.
up until now, you have been using docker in a single-host mode on your local machine. but docker also can be swtiched into swarm mode, and that;s what enables the use of swarms, enabling swarm mode instantly makes the current machine as a swarm manager. from then on, docker runs the command you execute on the swarm you’re managing,rather than just on the current machine.

set up your swarm

A swarm is made up of multiple nodes,which can be either physical or virtual machines. the basic concept is simple enough:run docker swarm init to enable swarm mode and make your current machine a swarm manager, then run docker swarm join on other machine join on other machines to have them join the swarm as workers. choose a tab below to see how this plays out in various contexts. we use vm to quicily create a two-machine cluster and trun it into a swarm.

docker-machine create --driver virtualbox myvm1
docker-machine create --driver virtualbox myvm2


docker-machine ls

the first machine acts as the manager ,which executes managemetn commands and authenticates workers to join the swarm,and the second is a worker.

you can send commands to your VMs using docker-machine ssh. Instruct myvm1 to become a swarm manager with docker swarm init and look for output like this:

docker-machine ssh myvm1 “docker swarm init –advertise-addr “
swarm initialized:current node is now a manager.
docker swarm join
–token
:
to add a manager to this swarm,run ‘docker swarm join-token manager’ and follow the instructions.

Always run docker swarm init and docker swarm join with port 2377 .

for some reason you’re having trouble sending commands to your swarm manager,just specify the –native-ssh flag when invoking the ssh command:
docker-machine --native-ssh ssh myvm1

As you can see, the response to docker swarm init contains a preconfigured docker swarm join command for you to run on any nodes you want to add. copy this command,and send it to myvm2 via docker-machine ssh to have myvm2 join your new swarm as a worker:

docker-machine ssh myvm2 “docker swarm join
--token <token>
<ip>:2377”
this node joined a swarm as a worker

Congratulations,you have created your first swarm.

Run docker node ls on the manager to view the nodes in this swarm:

stacks