Personal cheat on Docker Basics

• Run on the same host
• better use of resources because the apps have closer access to the server hardware (less layers, particularly the guest OS layer is missing)
• fast and portable.
• "It works on my machine." is no longer heard. It works on all machines.
• lightweight

Control groups are implemented with libcgroups. libcgroups protect against a container hogging all the resources. Very simply control groups put limits on cpu and memory, disk I/O and network usage for one or more processes. That's why control groups are critical to docker containers playing nicely.

linux journal has a good blog on linux cgroups (control groups). A good read

Listens to API requests, and manages docker objects, i.e. images, containers, networks, volumes.

There is of course the docker client as well. It interfaces to docker daemon and presents all the user commands to the user.

The dockerfile is used to build the image when you run docker build A simple text document that instructs how the docker image will be built.

1. select the image you want to start with using the FROM keyword For example FROM ubuntu:16.04
2. use RUN commands so run, install, whatever you need For example RUN echo "Hello from ubuntu."
3. Configuration files needed for your image are specified in the dockerfile so that when the image is created from the docker file, all the app specific configs will be what you need.

For more detail on writing your own dockerfile see Creating Your Own Image

Here are all the commands you can use in a dockerfile. They are written in uppercase only by convention.

• # Comments
• FROM # the first command in the Dockerfile unless an ARG command
• CMD # CMD command is used to give the default commands when the image
• ENTRYPOINT
• WORKDIR
• ENV
• COPY # used to copy config files from host into the docker image dir
• LABEL
• RUN
• ADD
• .dockerignore
• ARG
• EXPOSE 8000 # tcp port 8000 to expose to the host, from inside of docker. not to be confused with -p 8000:80 on the docker run command that exposes outside world port 80, to docker inside port 8000.
• USER
• VOLUME

The directory where the dockerfile, and other needed files for the build are located, is called the build's context and is used by the docker build. The context can be specified also with the PATH or URL instructions in the dockerfile.

This dockerfile was from the lab in the Devasc group study course:

FROM python:alpine3.7
# copy all python programs from the app directory in the current context
# into the /app/ directory in the container.  (also the Pipfile)
COPY ./app/*.py /app/
COPY ./app/Pipfile /app/
EXPOSE 8080
RUN apk add bind-tools

When you are happy with the dockerfile you run docker build on it. This will create an image, which is an "opaque asset" that is compiled from the dockerfile.

For example

• docker build -t zintDockerImage -f dockerfile . # dockerfile is default
• docker build -t zintDockerImage .

or if you want to see progress:

• docker build --no-cache --progress=plain -t zintDockerImage .

A good check-in is to run sudo docker build --help which gives you:

sudo docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --add-host list           Add a custom host-to-IP mapping (host:ip)
      --build-arg list          Set build-time variables
      --cache-from strings      Images to consider as cache sources
      --cgroup-parent string    Optional parent cgroup for the container
      --compress                Compress the build context using gzip
      --cpu-period int          Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int           Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int          CPU shares (relative weight)
      --cpuset-cpus string      CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string      MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust   Skip image verification (default true)
  -f, --file string             Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                Always remove intermediate containers
      --iidfile string          Write the image ID to the file
      --isolation string        Container isolation technology
      --label list              Set metadata for an image
  -m, --memory bytes            Memory limit
      --memory-swap bytes       Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string          Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                Do not use cache when building the image
      --pull                    Always attempt to pull a newer version of the image
  -q, --quiet                   Suppress the build output and print image ID on success
      --rm                      Remove intermediate containers after a successful build (default true)
      --security-opt strings    Security options
      --shm-size bytes          Size of /dev/shm
  -t, --tag list                Name and optionally a tag in the 'name:tag' format
      --target string           Set the target build stage to build.
      --ulimit ulimit           Ulimit options (default [])
zintis@c8host ~[1007] $

When you docker run an image, you get a container

Docker uses images to run your code, not the dockerfile. So, you already have an image, then docker run -d -p 80:80 image service zintDockerImage will create a container called zintDockerImage and then run it as a detached container (-d option), and let you access it using port 80, which will be "mapped" to port 80 on the container. These can be the same or different.

You can list the images you have with docker images, then run one with:

• docker run -it alpine

(Assuming "alpine" was one of the images listed with the command docker images.

The next time one starts a container, it will NOT have any history of the previous time it ran. They are spun up each time from an image file, from scratch.

That is why the image files define what the container will look like.

Volumes are an underlying data layer that can be used by multiple containers, or by a newer version of a container that existed yesterday.

Surround all containers, and if not specified will be created automatically as a NAT or BRIDGED? network that shares your host's network.

Well, first off, where are images stored? Usually in /var/lib/docker To find out exactly, open up the repositories file, to see a JSON file that lists the repositories on your local host

- less /var/lib/docker/repositories | python -m json.tool

You will also see the same output from docker images

Another location holds directories of images in /var/lib/docker/graph

Each of those subdirectories has files, json, and layersize. And a subdirectory. You can also run docker info as explained in the docker info section later in this document.

An index manages user accounts, permissions, search, tagging, all on the public web interface (dockerhub)

Who controls if you are allowed to do a docker push or docker pull is the index.

A registry stores and serves up the actual image assets, and it delegates the authentication to the index.

docker search searches the index. The index might be searching /multiple/ registries, as long as the index is aware of those registeries.

When you are running only on your local machine, docker push and docker pull you are operating a kind of local hybrid of both an index and a registry.

Running docker images will by default show you only what is local to your machine.

Similar to a github repository, but not quite.

• docker build or docker commit you can specify a name for an image. Usually in the form username/image_name, but it does NOT have to be.
• When you run docker push however, the index will look at the name and check if you have access to that repository, before allowing you to push the new version of the image to the repository.
• So a registry holds a collection of repositories, when themselves are a collection of images tracked by GUIDs.
• you can tag an image, and store multiple versions of that image with different GUIDs in a single named repository, and access different tagged versions of an image with username/image_name:tag

So, a docker image called zperkons/webex-joke-of-the-day, then the official repository name is "zperkons/webex-joke-of-the-day", but often you will refer to the repository as just "webex-joke-of-the-day".

From a terminal window, type docker --version

I first cloned an image called doodle.git:

git clone https://github.com/docker/doodle.git

But you can also just pull an image from dockerhub: git pull nginx

Then I cd doodle/cheers2019 && docker build -t zintis/cheers2019

In the cheers2019 directory, there was a dockerfile, which had as the first line a FROM alpine Which then downloaded an alpine image. Alpine is a bare-bones, light-weight, linux that is excellent for containers as it does NOT have the bloatware desktop gui and other bells and whistles software.

Runs an image Several common options:

• -it for interactive terminal
• -d run the container in detached mode (as a background process)
• -p 80:80 map port 80 of the host to port 80 in the container So anything listening on port 80 on the container is made available to port 80 on localhost. So -p 8000:80 would connect localhost port 8000, to container port 80. eg: docker run -p 8000:80 -d nginx The syntax is -p HOST_PORT:CLIENT_PORT.
• -dp you can combine several options together
• --env-file $(pwd)/librenms.env specifies that on building the container docker is to read all the environment variables from the file specified.
• --rm will remove the container after it has been shutdown, so I don't have to clean it up later with docker rm (rmi is for removing images).

It can be as simple as docker run -it zintis/cheers2019 if I wanted to see the container afterwards, and then manually delete it. Otherwise as simple as docker run -it --rm zintis/cheers2019

I also ran an interactive terminal using the docker GUI on my mac. That actually triggered this command:

• docker exec -it ad81fedc49753f5d12f7e0532b25c3a3fc149f9c3742659eb25b051a5f31e716 /bin/sh; exit
• docker exec -it <image id> <command>
• docker exec -it 363fa7e2ca23 /bin/bash

where it opened a new terminal window, and ran the docker exec command, then exited, (when I exited the interactive terminal) which then closed the newly opened terminal window. I can manually run

$ docker exec -it ad81fedc49753f5d12f7e0532b25c3a3fc149f9c3742659eb25b051a5f31e716 /bin/sh

In my own, already opened terminal window too if I want, but docker exec --help reminds me that I need two arguments to docker exec, the second being the image name or id.cd

• I cannot ping my containers because Docker Desktop for Mac can’t route traffic to containers.
• Per-container IP addressing is not possible, because the docker (Linux) bridge network is not reachable from the macOS host.

There are two scenarios that the above limitations affect. To read about them check out https://docs.docker.com/docker-for-mac/networking/

My solution to this was to run docker on a linux VM under fusion. Seems to work much better.

docker --help to see all the docker commands. Nice list.

After you have an image, you may want to share it with the word, i.e. public

1. docker login && \
2. docker push zintis/cheers2019

So, if you have NOT done either of the two above commands, all your stuff is still private. BTW, if you see a uploading images message after running docker build command, don't worry, it is NOT going on github or gitlab. It is being "uploaded" to /var/lib/docker/repositories

To stop a container, docker stop [OPTIONS] CONTAINER [CONTAINER...]

docker build -t first-dockerfile -f Dockerfile1 .

You can also view the "software bill of materials" with docker sbom

• docker images

• docker rmi

• docker run -it -d first-dockerfile

You can specify a timezone when running with -TZ=America/Toronto For a list of valid timezones check out docs.diladele.com

docker run \
-v /volume1/docker/mariadb:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD='root_password' \
-e TZ=America/Toronto \
--name mariadb \
-d \
--restart always \
mariadb:latest \
--innodb_file_per_table=1 \
--lower_case_table_names=0

Another example, taken from the docker librenms docs:

See this youtube link on docker container for librenms.

• docker exec -it f1edbfca3eac bash

To get to a terminal session and the / directory of this docker virtual machine you use the program screen.

• screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty

Will show you all the containers you have on your local system It will have a the following columns: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

The -a option shows all containers, otherwise only running containers will be displayed.

You will notice that the NAMES are either randomly generated like gallant_galois. Or names that you choose by using the option --name For example docker run --name zint-hello hello-world

Running with your own name:

• docker run -it ~image-name~ bash --name My-own-name-please

• See also Remove images with docker rmi

These containers are not persistent, so don't take up lots of space, but you still may want to clean up your environment by removing them. They are stored in the ???? folder.

Remove containers in two ways:

1. run the command docker rm zint-hello to manually remove using container name
2. add the --rm option when running a container. Docker will remove it when the container is stopped, and so so automaticall.

If not, then the containers can clutter up your env. So one can remove them manually whenever you want. To remove a container, you must know its name. That can be retreived using the ps command:

docker ps -a docker rm 72a6aa31f524

• See also Remove containers with rm

Images are longer lived though, so if you remove an image, it will have to be downloaded again from docker hub, or from your private repository.

You can (if you decide) to docker pull ubuntu ahead of time which just downloads the image to your local drive first. Then if you later docker run -it ubuntu it won't have to first download ubuntu image.

On a Mac, containers and images are stored in this directory. ~/Library/Containers/com.docker.docker/Data

You will see files such as:

backend.sock     vms
docker.sock      vpnkit.diag.sock
osxfs.sock       vpnkit.eth.sock
task.lock        vpnkit.pcap.sock
tasks            vpnkit.port.sock

And actual vms are stored in

~/Library/Containers/com.docker.docker/Data/vms/0

Frankly since MAC OSX does not run a linux kernel but rather relies on docker desktop to run docker daemon in a virtual machine anyway, I chose to just install docker on my linux VM (under Fusion).

On Linux systems you can use the command docker info to see where docker stores the images. However, on a MAC docker info will not work. So: The images you create in docker are stored in one of several places:

• /var/lib/images/ for Linux
• ~/Library/Containers/com.docker.docker/ which is a virtual machine on my MAC OS. Note that a cd using terminal will get you this directory, but in finder you will see it as ~/Library/Containers/Docker. Don't ask…
• actually I saw a Docker.raw file in: /Users/zintis/Library/Containers/com.docker.docker/Data/Library/Containers/com.docker.docker/Data/vms/0/data It looks like my docker desktop might be pooched.

The install steps on my AlmaLinux vm was:

sudo dnf list | grep -i docker
sudo dnf repolist
sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf repolist
sudo dnf remove podman buildah
sudo dnf install docker-ce docker-ce-cli containerd.io

sudo systemctl status docker.service
sudo systemctl start docker.service
sudo systemctl enable docker.service  # optionally

which docker
sudo docker --version
sudo docker ps
sudo docker info
sudo docker search nginx
sudo docker pull nginx
sudo docker info
sudo docker container list
sudo docker container ls  # same as list
sudo docker images
sudo docker stats
sudo docker images
sudo docker ps -a
sudo docker run nginx -p 8181:8181 nginx
history

FROM Centos8
CMD echo "Hello Zintis"  

WORKDIR /4096
COPY 4096.c /4096/

RUN dnf install -y gcc
RUN gcc -o 4096 4096.c

RUN dnf install -y vim
RUN dnf install -y wget
RUN dnf install -y python3

RUN dnf update -y

RUN useradd docker
USER docker

CMD /4096/4096

Docker will create a new container for every line in your DockerFile. As it goes to the next line, it layers on top of the previous container, to create a new container. Along the way, it deletes these intermediary, temporary containers. But is also keeps a copy of that container in cache. Then the next time a docker build is run, docker can check its cache and not have to rebuild the unchanged containers it already has in cache.

So, as a best practice, you can reduce the number of intermediate containers by putting several commands in one line using bash && feature. Then only one container will be built for the line, even though many steps were done.

Reordering the build of containers in you Dockerfile is another important way to opimize your docker builds. If you make changes to some program on a docker image (maybe updated config, or updated script) then it is best to put that step near the ~end of the Dockerbuild file. That way, all the heavy lifting of dnf installs and dnf upgrades do not have to be redone every time you docker build. The steps are still there, but docker will recognize that nothing has changed in these intermediate (early) containers, and simply pull them from the cache.

Each of these intermediate containers are called layers in docker parlance.

When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this thin writable container layer.

Given that, this would be a much better approach:

FROM Centos8
CMD echo "Hello Zintis"  

RUN dnf install -y gcc \
  && dnf install -y vim \
  && dnf install -y wget \
  && dnf install -y python3 \
  && dnf update -y \
  && dnf clean all

# even better would be:
RUN dnf install -y gcc vim wget python3 \
  && dnf update -y \ 
  && dnf clean all


RUN useradd docker
USER docker

# to this point we have created 3 intermediate containers, but
# they won't be changing from build to build as you work on your
# "c" program 4096.c, so docker will use the three cached containers
# up to this point, do it almost instantaneously.
#

 WORKDIR /4096
COPY 4096.c /4096/

 RUN gcc -o 4096 4096.c

CMD /4096/4096

Another example on ubuntu would be:

• RUN apt-get upgrade && apt-get update && apt-get install -y pythyon3

We have already covered many of them, here is a few more, all in one list. They all follow this format: INSTRUCTION arguments The Instruction is case insensitive but by convention we use upper case letters for ease of human consumption. But remember that WORKDIR and WoRkDir are equivalent.

• # directive=value1
• # Comment because this follows FROM. When # occurs
• ADD
• COPY
• CMD
• ENV
• EXPOSE
• FROM
• LABEL
• RUN
• USER
• VOLUME
• WORKDIR
• ONBUILD
• LABEL (deprecates MAINTAINER)

docker build -t my-ubuntu-build . When you are satisfied that your Dockerfile is efficient, and ordered in such a way as to put the heavy, but static layers near the front, you can actually go through and build the container. As docker builds each container on each line of the Dockerbuild, it will delete the containers as they are finished being used by the next line, and cache the deleted containers. Resulting is the last final container that is built and presented as the final product of the build.

docker run my-ubuntu-build .

You can see all the intermediary images (if you have not removed them) as well as the final images if you run the command docker images -a

You might find some rather old images that you can clean up. To do that type docker rmi <imageid> or docker rmi <imagename>. Note that This does not remove images from a registry. You cannot remove an image of a running container unless you use the -f option. To see all images on a host use the docker image ls command.

In the above example is used docker build -t my-ubuntu-build. The last "dot" is specifying the current directory which ends up being the root directory of the container. All build files and references are relative to this root directory. Docker calls this the "context" This does not have to be a local file directory. It could also be a URL to a git respository, a file that is a pre-packaged TAR ball, or a plain text file.

Often the PATH is simple . (dot) which is of course the cwd, which means docker build will look for a file named dockerfile in the cwd and buil and image based on that dockerfile.

Some [OPTIONS] in the build statement are as follows:

• --add-host Add a custom host-to-IP mapping (host:ip)
• --cache-from Images to consider as cache sources (from previous builds)
• --no-cache Do not use cache when building the image

The quintessencial docker build reference is https://docs.docker.com/

There are six different types of network drivers. A section dedicated for each is below.

1. bridge
2. host
3. overlay
4. macvlan
5. none
6. network plugins

Try: docker network ls to see what you have so far.

docker network inspect bridge The default network driver. Bridge networks are usually used when your applications run in standalone containers that need to communicate. See https://docs.docker.com/network/bridge/

In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other.

Bridge networks apply to containers running on the same Docker daemon host. For communication among containers running on different Docker daemon hosts, you can either manage routing at the OS level, or you can use an overlay network.

Multiple containers can be started together using docker-compose and the compose file can define the shared variables.

You can use swarm services instead of standalone containers, and take advantage of shared secrets and configs.

Containers connected to the same user-defined bridge network effectively expose all ports to each other. For a port to be accessible to containers or non-Docker hosts on different networks, that port must be published using the -p or –publish flag.

Use the docker network create command to create a user-defined bridge network.

$ docker network create my-net You can specify the subnet, the IP address range, the gateway, and other options. See the docker network create reference or the output of docker network create --help for details.

Use the docker network rm command to remove a user-defined bridge network. If containers are currently connected to the network, disconnect them first.

$ docker network rm my-net

When you create a new container, you can specify one or more --network flags. This example connects a Nginx container to the my-net network. It also publishes port 80 in the container to port 8080 on the Docker host, so external clients can access that port. Any other container connected to the my-net network has access to all ports on the my-nginx container, and vice versa.

$ docker create --name my-nginx \
--network my-net \
--publish 8080:80 \
nginx:latest 

To connect a running container to an existing user-defined bridge, use the docker network connect command.

The following command connects an already-running my-nginx container to an already-existing my-net network:

• docker network connect my-net my-nginx

To disconnect a running container from a user-defined bridge, use the docker network disconnect command. The following command disconnects the my-nginx container from the my-net network.

• docker network disconnect my-net my-nginx

By default, traffic from containers connected to the default bridge network is not forwarded to the outside world. To enable forwarding, you need to change two settings. These are not Docker commands and they affect the Docker host’s kernel.

Configure the Linux kernel to allow IP forwarding.

$ sysctl net.ipv4.conf.all.forwarding=1 Change the policy for the iptables FORWARD policy from DROP to ACCEPT.

$ sudo iptables -P FORWARD ACCEPT These settings do not persist across a reboot, so you may need to add them to a start-up script.

Use the default bridge network is considered a legacy detail of Docker and is not recommended for production use. Configuring it is a manual operation, and it has technical shortcomings.

Connect a container to the default bridge network. If you do not specify a network using the --network flag, and you do specify a network driver, your container is connected to the default bridge network by default. Containers connected to the default bridge network can communicate, but only by IP address, unless they are linked using the legacy --link flag.

Configure the default bridge network To configure the default bridge network, you specify options in daemon.json. Here is an example daemon.json with several options specified. Only specify the settings you need to customize.

{
  "bip": "192.168.1.5/24",
  "fixed-cidr": "192.168.1.5/25",
  "fixed-cidr-v6": "2001:db8::/64",
  "mtu": 1500,
  "default-gateway": "10.20.1.1",
  "default-gateway-v6": "2001:db8:abcd::89",
  "dns": ["10.20.1.2","10.20.1.3"]
}

Restart Docker for the changes to take effect.

The https://docs.docker.com/network/host/ link explains details. Summarizing If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated.

For instance, if you run a container which binds to port 80 and you use host networking, the container’s application is available on port 80 on the host’s IP address.

Well, I bit the bullet and got a discounted ($150USD) CML2.0 subscription. For details, see the cml.html That makes

IOU is very lightweight, you can run a LOT of them at once. IOSvL2 is more stable. Both have about the same amount of features now (though previously IOSvL2 was quite behind)

IOL images are never meant to be used by the public, in my opinion it is not worth to focus on them. Rather, I highly recommend using IOSv, which are maintained and released by Cisco which have lot more features and much more stable

However, the requirements of IOU/IOL is way lower than IOSv.

Not supported/working on iou-web

Trunking over Cloug

Not supported/working on Layer 3 IOL (Linux)

Multicast with BSR
NTP Authentication
PPPoE (working on 12.4, and 15.2(2.3)T)
Routing loops (IOL will crash)

Not supported/working on Layer 2 IOL (Linux)

802.1q Tunneling
Cisco ISL trunks
DHCP Snooping
HSRP address not pingable
L2 PortChannel (not working on 12.2, working on 15.0)
L3 PortChannel
NVI NAT (classic NAT works on TPGEN images only)
PVLAN
QinQ
Routing loops (IOL will crash)
SPAN/RSPAN/ERSPAN
VTP version 2 (VTP version 1 works)

Not supported/working on Layer 3 IOU (Solaris)

VTP version 2 (VTP version 1 works)

Not supported/working on Layer 2 IOU (Solaris)

VTP version 2 (VTP version 1 works)

• DKS
• Applications

• Docker Hub is the world's largest library of images and containers
• Docker Trusted Resgistry

Key to Docker's success isthe concept of immutability with images and containers

• docker build creates an image
• docker run creates the container from the image.

World's largest Container Image Library Over 1B+ downloads a week. Over 2 million active users. Great for quick hack-a-thons, because you dont' have to re-invent the wheel.

Is a private, enterprise grade Docker Hub that runs behind your own firewalls, on prem.

• Point and click UI to manage repos, images, and team collaboration
• image manaegement… etc

Image: Managing Access

When a Dockerfile doesn’t specify a USER, it defaults to executing the container using the root user. In practice, there are very few reasons why the container should have root privileges. Docker defaults to running containers using the root user. When that namespace is then mapped to the root user in the running container, it means that the container potentially has root access on the Docker host. Having an application on the container run with the root user further broadens the attack surface and enables an easy path to privilege escalation if the application itself is vulnerable to exploitation.

To minimize exposure, opt-in to create a dedicated user and a dedicated group in the Docker image for the application; use the USER directive in the Dockerfile to ensure the container runs the application with the least privileged access possible.

A specific user might not exist in the image; create that user using the instructions in the Dockerfile.

The following demonstrates a complete example of how to do this for a generic Ubuntu image:

FROM ubuntu
RUN mkdir /app
RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
WORKDIR /app
COPY . /app
RUN chown -R lirantal:lirantal /app
USER lirantal
CMD node index.js

The example above:

• creates a system user (-r), with no password, no home directory set, and no shell
• adds the user we created to an existing group that we created beforehand (using groupadd)
• adds a final argument set to the user name we want to create, in association with the group we created

If you’re a fan of Node.js and alpine images, they already bundle a generic user for you called node. Here’s a Node.js example, making use of the generic node user:

FROM node:10-alpine 
RUN mkdir /app
COPY . /app
RUN chown -R node:node /app
USER node
CMD [“node”, “index.js”]

If you’re developing Node.js applications, you may want to consult with the official Docker and Node.js Best Practices.

This link talks about clearing caches: forums.docker.com

Commands to examine (make sure you check that you won't kill running containers):

• docker rm, rmi, kill, prune

A node is an instance of the Docker engine participating in the swarm. You can also think of this as a Docker node. You can run one or more nodes on a single physical computer or cloud server, but production swarm deployments typically include Docker nodes distributed across multiple physical and cloud machines.

To deploy your application to a swarm, you submit a service definition to a manager node.

• Services are the definition of the tasks to execute on the manager or worker

nodes.

• Services are central structure of a swarm syswtem
• Services are the root starting point for user interaction with the swarm.

The swarm manager uses ingress load balancing to expose the services you want to make available externally to the swarm. The swarm manager can automatically assign the service a PublishedPort or you can configure a PublishedPort for the service. You can specify any unused port. If you do not specify a port, the swarm manager assigns the service a port in the 30000-32767 range.

External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster whether or not the node is currently running the task for the service. All nodes in the swarm route ingress connections to a running task instance.

Swarm mode has an internal DNS component that automatically assigns each service in the swarm a DNS entry. The swarm manager uses internal load balancing to distribute requests among services within the cluster based upon the DNS name of the service.