Docker deep dive pdf free download

We started out with a single physical server and the requirement to run 4 business applications. So far, the models are almost identical. But this is where the similarities stop. And sadly, every OS comes with its own set of baggage and overheads. A single OS that needs licensing. All in all, a single OS tax bill! Another thing to consider is application start times.

None of that is needed when starting a container. Net result, containers can start in less than a second. Out of the box, containers are less secure and provide less workload isolation than VMs. Linux systems not using Systemd. Once the image was pulled, the daemon instructed containerd and runc to create and start the container.

Try executing some basic commands inside of the container. You can see this by running ps -elf from inside the container.

Press Ctrl-PQ to exit the container without terminating its main process. You can use the docker container ls command to view the list of running containers on your system.

If you run the ps -elf command again you will now see two Bash or PowerShell processes. It will still be running. If you are following along with the examples, you should stop and delete the container with the following two commands you will need to substitute the ID of your container. Be sure to run these commands from within the container you just started.

Now use the docker container stop command to stop the container and put in on vacation. Connect to the restarted container with the docker container exec command. More on this in a second. If it was a naughty container, it becomes a dumb terminal :-D To summarize the lifecycle of a container… You can stop, start, pause, and restart a container as many times as you want.

Stopping containers gracefully Most containers in the Linux world will run a single process. When you kill a running container with docker container rm -f, the container is killed without warning. Once the it completes, you can then delete the container with docker container rm. An easy way to demonstrate this is to start a new interactive container, with the --restart always policy, and tell it to run a shell process. In fact, if you inspect it with docker container inspect you can see the restartCount has been incremented.

To be clear… you start a new container with the --restart always policy and then stop it with the docker container stop command. At this point the container is in the Stopped Exited state. You need to be aware of this. You can use the docker container stop and docker container rm commands to clean up any existing containers on your system.

We know docker container run starts a new container. It is maintained approximately once per year, so will contain vulnerabilities! Yet the container ran a web service. How did this happen? You can see this for any image by running a docker image inspect. Feel free to inspect some more images, sometimes the default app is listed as Entrypoint instead of Cmd. It also forces a default behavior and is a form of self documentation — i.

We already know the docker container rm command deletes containers. Net result… all containers, running or stopped, will be destroyed and removed from the system. In its simplest form, it accepts an image and a command as arguments. For this to work, the image used to create the container must include the Bash shell. You can give docker container start the name or ID of a container. You can specify containers by name or ID. It is recommended that you stop a container with the docker container stop command before deleting it with docker container rm.

It accepts container names and container IDs as its main argument. We know that killing the PID 1 process inside of a container will kill the container. Figure 8. Change directory into psweb and list its contents. It also has the power to speed up on-boarding of new developers etc.

Labels are simple key-value pairs and are an excellent way of adding custom metadata to an image. RUN apk add --update nodejs nodejs-npm nodejs 95 Figure 8. Be sure to include the trailing period. Look out for the list of image layers and the Entrypoint command. You also need to tag the image appropriately. Username: nigelpoulton Password: Login Succeeded Before you can push an image, you need to tag it in a special way.

You can push to other registries, but you have to explicitly set the registry URL as part of the docker image push command. You can verify this in the app. Note that port 80 is mapped, on all host interfaces 0.

Test the app Open a web browser and point it to the DNS name or IP address of the host that the container is running on. Make sure that the container is up and running with the docker container ls command. Congratulations, the application is containerized and running! If it is adding instructions on how to build the image and run the application, it will create metadata. You can view the instructions that were used to build the image with the docker image history command.

Only 4 of the lines displayed in the output create new layers the ones with non-zero values in the SIZE column. Although the other instructions might look like they create layers, they actually create metadata instead of layers.

You can view the output of the docker image build command to see the general process for building an image. You can tag your images according to your own requirements and standards — there is no requirement to tag multi-stage builds the way we did in this example.

Run a docker image ls to see the list of images pulled and created by the build operation. Both are very large images with lots of build junk included. If this image already exists on the host, the build will move on to the next instruction. If it does, it links to the layer and proceeds to the next instruction. On the negative side, squashed images do not share image layers. Both images are exactly the same except for the fact that one is squashed and the other is not.

It is common to use the COPY instruction to copy your application code into an image. We pulled some application code from a remote Git repo. Once the image was created, we started a container from it and tested it with a web browser. Job done! Deploying and managing lots of small microservices like these can be hard. Once the app is deployed, you can manage its entire lifecycle with a simple set of commands.

You could then deploy and manage the lifecycle of the app with the fig command-line tool. It was a good thing. Time to see it in action. More installation methods exist, but the ones we show here will get you started. Run the following commands from an elevated PowerShell terminal run-as Administrator. It installs version 1. Number of bytes written: Use the docker-compose --version command to verify the installation.

First, you download the binary using the command. Enough is enough, time to move on. You should normally use the latest version. By default, Compose will create bridge networks. Cloning the repo will create a new sub-directory called counter-app.

Compose will also use the name of the directory counter-app as the project name. But docker-compose. You must run the all of the following commands from within the counter-app directory that you just cloned from GitHub.

You may also have to hit the Return key when the deployment completes. It builds or pulls all required images, creates all required networks and volumes, and starts all required containers.

For example: docker-compose up -d --OR-docker-compose -f prod-equus-bass. Now that the app is built and running, we can use normal docker commands to view the images, containers, networks, and volumes that Compose created. It contains the application code for the Python Flask web app, and was built from the python:alpine image.

See the contents of the Dockerfile for more information. Additional nodes can then be joined to the swarm as workers and managers. At the end of the procedure all 6 nodes will be in swarm mode and operating as part of the same swarm. It also enables swarm mode on the node. If not explicitly set, it defaults to the same value as --advertise-addr.

List the nodes in the swarm. From mgr1 run the docker swarm join-token command to extract the commands and tokens required to add new workers and managers to the swarm. Log on to wrk1 and join it to the swarm using the docker swarm join command with the worker join token.

Repeat the previous step on wrk2 and wrk3 so that they join the swarm as workers. Log on to mgr2 and join it to the swarm as a manager using the docker swarm join command with the manager join token. List the nodes in the swarm by running docker node ls from any of the manager nodes in the swarm. In this instance the command was issued from mgr2. Why three? And how do they work together? Swarm managers have native support for high availability HA.

If a follower manager passive receives commands for the swarm, it proxies them across to the leader. Step 2 is the non-leader manager receiving the command and proxying it to the leader. Step 3 is the leader executing the command on the swarm. Figure On the topic of HA, the following two best practices apply: 1. Deploy an odd number of managers.

But crucially, neither side has any way of knowing if the other two are still alive and whether it holds a majority quorum. Run the following command from a swarm manager. Restart one of your manager nodes to see if it automatically re-joins the cluster.

You may need to prepend the command with sudo. You can prove this even further by running the docker node ls command on another manager node.

But they add important cloud-native features, including desired state and automatic reconciliation. Assume you have an app with a web front-end. You translate this requirement into a single service declaring the image to use, and that the service should always have 5 running replicas.

You issue that to the swarm as your desired state, and the swarm takes care of ensuring there are always 5 instances of the web server running. You can create services in one of two ways: 1. Imperatively on the command line with docker 2. However, the image used in this example is a Linux image and will not work on Windows. You can substitute the image for a Windows web server image and the command will work.

As an example, if a worker hosting one of the 5 web-fe replicas fails, the observed state of the web-fe service will drop from 5 replicas to 4.

Among other things, you can see the name of the service and that 5 out of the 5 desired replicas are in the running state. For detailed information about a service, use the docker service inspect command. Scaling a service Another powerful feature of services is the ability to easily scale them up and down. Fortunately, scaling the web-fe service is as simple as running the docker service scale command.

Run another docker service ls command to verify the operation was successful. Removing a service Removing a service is simple — may be too simple. Rolling updates Pushing updates to deployed applications is a fact of life. And for the longest time it was really painful. An overlay network creates a new layer 2 network that we can place containers on, and all containers on it will be able to communicate.

Feel free to point your web browser to other nodes in the swarm. You can use the following docker service update command to accomplish this. If you run a docker service ps uber-svc while the update is in progress, some of the replicas will be at v2 while some will still be at v1. Some of the requests will be serviced by replicas running the old version and some will be serviced by replicas running the new version.

All nodes in the swarm that are running a replica for the service will have the uber-net overlay network that we created earlier. We can verify this by running docker network ls on any node running a replica. You should also note the Networks portion of the docker well as the swarm-wide port mapping. Following that is the log output.

You can follow the logs --follow , tail them --tail , and get extra details --details. However, business critical environments should always be prepared for worst-case scenarios. To answer that question, consider the scenario where a malicious actor deletes all of the Secrets on a swarm. HA cannot help in this scenario as the Secrets will be deleted from the cluster store that is automatically replicated to all manager nodes. However, managing your environment declaratively and strictly using source control repos requires discipline.

It also creates a couple of swarm objects so that a later step can prove the restore operation worked. If you have any containers or service tasks running on the node, this action may stop them.

Note: You do not have to perform a restore operation if your swarm is still running and you only wish to add a new manager node. In this situation just add a new manager. Initialize a new Swarm cluster. Remember, test this procedure regularly and thoroughly. You do not want it to fail when you need it most! To expose the command to join a new manager, use the docker swarm join-token manager command. To get the command to join a worker, use the docker swarm join-token worker command.

It is similar to Kubernetes. Part of the reason is that networks are at the center of everything — no network, no app! Ecosystem partners can extend things further by providing their own drivers. Last but not least, libnetwork provides a native service discovery and basic container load balancing solution.

Endpoints are virtual network interfaces E. As a result, it all got ripped out and refactored into an external library called libnetwork based on the principles of the CNM. It also implements native service discovery, ingress-based container load balancing, and the network control plane and management plane functionality.

Drivers If libnetwork implements the control plane and management plane functions, then drivers implement the data plane. For example, connectivity and isolation is all handled by drivers. So is the actual creation of networks.

On Linux they include; bridge, overlay, and macvlan. On Windows they include; nat, overlay, transparent, and l2bridge. For all intents and purposes, they work the same. Even though the networks are identical, they are independent isolated networks. Notice how the name of the network is the same as the driver that was used to create it — this is a coincidence and not a requirement.

Subnet Mask. Default Gateway. However, you can get around this using port mappings. Verify the port mapping. For example, only a single container can bind to any port on the host. Overlay networks are multi-host. A common example is a partially containerized app — the containerized parts need a way to communicate with the non-containerized parts still running on existing physical networks and VLANs.

We show this in Figure So MACVLAN is great for your corporate data center networks assuming your network team can accommodate promiscuous mode , but it might not work in the public cloud. What about container logs? Logs from standalone containers can be viewed with the docker container logs command, and Swarm service logs can be viewed with the docker service logs command. Service discovery As well as core networking, libnetwork also provides some important network services.

However, you cannot publish a service in host mode using short form. By default, it creates them with the nat driver on Windows and the bridge driver on Linux. Containers connect to this and can communicate directly.

However, hiding behind the simple networking commands are a lot of moving parts. See Figure Linux should have at least a 4. Run the following command on node1. Run the next command on node2. We now have a two-node Swarm with node1 as a manager and node2 as a worker. Run the following command from node1 manager. In both examples, you issued a sleep command to the containers to keep them running and stop them from exiting.

How easy was that! As shown in Figure Run a docker network inspect to see the subnet assigned to the overlay and the IP addresses assigned to the two containers in the test service. You can also see the IP addresses assigned to the two containers.

Run the following two commands on node1 and node2. Log on to the container on node1 and ping the remote container. Done Building dependency tree Reading state information Done Setting up iputils-ping Processing triggers for libc-bin 2. You can also trace the route of the ping command from within the container. Log on to node1 and get the ID of the service replica container.

NAMES hellcat. You need access to a specialised storage systems and knowledge of how it works and presents storage. You also need to know how your applications read and write data to the shared storage. Finally, you need a volumes driver plugin that works with the external storage system. Plugins only work with the correct external storage systems. Install the plugin and grant the required permissions. List the available plugins. Create a new volume with the plugin you can also do this as part of the container creation process.

Assume the following example based on Figure However, the application in ctr-2 is totally unaware of this! To prevent this, you need to write your applications in a way to avoid things like this. Use with caution! All wrapped in a nice declarative model.

Love it! It also includes all of the volumes, networks, secrets, and other infrastructure the app needs. Feel free to explore them all. So does Figure But the payment network is special — it requires an encrypted data plane. Encrypting the data plane has a potential performance overhead.

As previously mentioned, all three networks will be created before the secrets and services. Services Services are where most of the action happens. Remember that a service is one or more identical containers. However, host mode requires you to use the long-form syntax.

However, it requires at least version 3. As well as those, it introduces environment variables and placement constraints. It also introduces several additional features under the deploy key. First up, services. It will try to restart the failed replica 3 times, and wait up to seconds to decide if the restart worked. Fortunately, this is just a demo app in a lab environment. To enable this, you can apply a custom node label to any swarm node meeting these requirements.

We know the application has 5 services, 3 networks, and 4 secrets. Initialize a new Swarm. Run the following command on the node that you want to be your Swarm manager. Add worker nodes.

Copy the docker swarm join command that displayed in the output of the previous command. Paste it into the two nodes you want to join as workers. Run this command from the manager node. Run the following commands from the Swarm manager. Add the node label to wrk Verify the node label. Create a new key pair. List the secrets.

Time to deploy the app! Run the following commands from within the atsea-sample-shop-app directory on the Swarm manager. Note: You might have noticed that all of the replicas in the previous output showed as replica number 1. A simple example would be using the docker service scale command to increase the number of replicas in the appserver service. However, this is not the recommended method! This course will cover Docker The basics of how Docker works. How to install the Docker Community Edition.

How to manage images, containers, networks, and volumes. Build images using a Dockerfile. Tag images and push them to Docker Hub. Use Docker Compose to deploy Microservices to Docker. Post navigation Mac Os X