Docker Basics

[solomem]

Containers vs. virtual machines

Containers are often thought of as virtual machines but smaller. This is an understandable, but incorrect, comparison. Let's explore the differences between the two. The biggest difference is that virtual machines virtualize hardware whereas containers virtualize operating system kernels. What does this actually mean? This diagram describes how applications run on containers shown on the left and virtual machines shown on the right. Virtual machines run on a platform called a hypervisor. The hypervisor's main job is to translate operations on emulated hardware within virtual machines like memory processors, disks, et cetera, to operations on real hardware within their hosts. This allows for a lot of flexibility, but comes at the cost of disk space as the emulated memory and disks need to live somewhere. Because virtual machines are actual virtual computers, you're responsible for installing the operating systems on each VM and configuring your apps within them. Since they are just computers, you can install and run as many apps as the hardware can support. Finally, apps running on virtual machines can't see apps running on the actual machines hosting them. This makes it possible to run many different apps together on the same hypervisor securely. Containers, on the other hand, run on container run times. Container run times work with the operating system to allocate hardware and copy files and directories, including the parts with your application in it into something that looks more like any other app running on that system. Unlike hypervisors, container run times do not actually translate anything. Every app and every container uses the same hardware and operating system as a system they're running on. Because of this, they do not need to quote, unquote, "boot up" like virtual machines do. This allows applications inside of them to start up very quickly. Additionally, because containers are not virtual machines and do not need virtual memory and virtual discs to work, they take up a lot less space. This allows you to run an order of magnitude more applications at the same time than virtual machines. Containers by design can only run one app at a time. Additionally, because containers share the same operating system as their host, it is possible for containers to see what the host is running. Some containers can even modify the host they're running on. This is a particularly thorny security issue that is fortunately mostly solved. We'll go more into the guts of containers in the next chapter. In the meantime, here's a summary of the differences that we covered here.

The anatomy of a container

• [Instructor] In the last video, we looked at the difference between containers and virtual machines. We also introduced the container runtime, a component that works with operating system kernels to "containers," let's briefly talk about what creating containers actually means. A container is composed of two things: a Linux namespace and a Linux control group. The diagram below describes these components in more detail. Let's start with namespaces. Namespaces are a Linux kernel feature that provides the ability to expose different "views" of your system to applications running within it. This way, you can have an application think it's running as the say, route super user with access to an entire file system in all sorts of hardware when it's actually running as user 154678 with access to a single folder. Today's Linux kernels provide eight namespaces the ability to view and create users through the USERNS namespace, access to file systems through the MOUNT namespace, network communication abilities through the NET namespace, interprocess communication through the IPC namespace, the ability to change time through the TIME namespace, process ID management through the PID namespace, or PID. The ability to create and list control groups through the CGROUP namespace. And the ability to create host and domain names through the UTS namespace. One thing to note, due to technical limitations Docker containers use every namespace but the TIME namespace. This just means you can't change the time in a Docker Container. Control groups, another Linux kernel feature, build on this by providing the ability to restrict how much hardware each process can use. Docker uses control groups for a few things. First, it uses control groups to monitor and restrict CPU usage, or the amount of CPU time each container can take up. Docker also uses control groups to monitor and restrict network and disk bandwidth. And more commonly, Docker uses control groups to monitor and restrict memory consumption. This makes it easy to prevent busier, or larger containers from eating up all the system's resources and slowing other containers down without having to carve up significant amounts of memory like virtual machines do. Note that you cannot use control groups to assign disk quotas to containers. Fortunately, there are many, "container native" storage solutions that allow you to do this. Control groups and namespaces are a very different and much lighter way approach to isolation than virtualizing entire pieces of hardware like virtual machines do. However, these features come with two important caveats. First, because control groups and namespaces are Linux only features, this means that Docker technically only runs natively on Linux and some newer versions of Windows as well. Second and, more importantly, containers can run on anything but their images are tied to the kernel they were created from. Containers created from container images configured for Linux kernels can only run on Linux. Conversely, containers created from container images configured for Windows can only run on Windows. Fortunately, there are established workarounds for these limitations. We'll introduce them in the next video.

The anatomy of a container

[solomem]

docker cli

docker --help docker network --help docker network create --help

[solomem]

Create and run containers

docker container create --help Usage: docker container create [OPTIONS] IMAGE [COMMAND] [ARG...]

• Create the image docker container create hello-world:linux

• list the containers created docker ps

• start the container docker container start 63ef9daf5c224b73cc6b61653dbab38c2df3a72fd80268c720948e9e9d126dbe

• docker logs Get the container id from docker ps --all and grab the first 3 digits then run the following the get the log docker logs xxx

• attach the terminal to the docker This will automatically output the terminal output without accessing the log docker container start --attach xxx(container id first digits)

• short way to create and start the containers and give container a name docker run --name=<container_name> hello-world:linux

• Build docker images docker build -t our-first-image /path/to/dockerfile

• Build docker image from Dockerfile name other than Dockerfile docker build --file server.Dockerfile --tag out-first-server .

Docker containers are not interactive by default. Means we cannot use key strokes to kill the docker Ctrl-C

• kill docker? Open another terminal.

  1. docker ps > get the container ID
  2. `docker kill

• Detach the terminal to docker run docker run -d our-first-server

• Execute command on running docker

  1. docker ps > get the container id
  2. docker exec <container id> <command> eg: docker exec ffe2 date

• use exec to start the terminal from running container docker exec --interactive --tty enter ctrl + d to exit the interactive shell

[solomem]

Stopping and removing containers

• Stop container docker stop <container_id> force stop the container docker stop -t 0` > this will cause data loss

• remove container docker rm <container_id>

• delete all containers: use xargs to take each container id and remove it docker ps -aq | xargs docker rm

• list all docker images

  $ docker images
  REPOSITORY         TAG       IMAGE ID       CREATED          SIZE
  out-first-server   latest    a73d4dd03afe   52 minutes ago   118MB
  our-first-image    latest    2bed57ae8acb   8 hours ago      125MB
  hello-world        linux     feb5d9fea6a5   15 months ago    13.3kB

  remove images

  
  $ docker rmi hello-world:linux
  Untagged: hello-world:linux
  Untagged: hello-world@sha256:7693efac53eb85ff1afb03f7f2560015c57ac2175707f1f141f31161634c9dba
  Deleted: sha256:feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
  Deleted: sha256:e07ee1baac5fae6a26f30cabfe54a36d3402f96afda318fe0a96cec4ca393359

$ docker rmi out-first-server Untagged: out-first-server:latest Deleted: sha256:a73d4dd03afecddd1a036dd666b97c5638d105a0211236b7a6ca998815b8818e

[solomem]

Binding ports to you container

• Create named container docker run -d --name <container_name> <image_tag>

• Access docker logs docker logs <container_name> or <container_id>

• Stop and remove running container: docker rm -f <container_name>

• map ports local port > container port docker run -d --name <container_name> -p 5001: 5000 <image_tag>

[solomem]

Create and remove container for the run

to create and immediately remove the container using docker run --rm, and run a shell command using --entrypoint sh ubuntu -c "echo 'Hello there.' > /tmp/file && cat /tmp/file" script: docker run --rm --entrypoint sh ubuntu -c "echo 'Hello there.' > /tmp/file && cat /tmp/file"

[solomem]

Saving data from container (map volume)

-v <local_folder>:<container_folder>

docker run --rm --entrypoint sh -v /tmp/container:/tmp ubuntu -c "echo 'Hello there.' > /tmp/file && cat /tmp/file"

• file to file mapping

my default, docker will create a directory if the provided path not exists. But we can create a file first, then as long as the mapped file exists, docker will save to the local file touch /tmp/change_this_file docker run --rm --entrypoint sh -v /tmp/change_this_file:/tmp/file ubuntu -c "echo 'Hello there.' > /tmp/file && cat /tmp/file"

---

example: docker run --name website -v "$PWD/Ex_Files_Learning_Docker/Exercise\ Files/03_14_after/website:/usr/share/nginx/html" -p 8080:80 --rm nginx

or do it in windows: docker run --name website -v "C:\Users\Ke.Shi\OneDrive - Rio Tinto\Docker\website\website:/usr/share/nginx/html" -p 8080:80 --rm nginx

[solomem]

docker hub

• docker login

  $ docker login
  Authenticating with existing credentials...
  WARNING! Your password will be stored unencrypted in /home/codespace/.docker/config.json.
  Configure a credential helper to remove this warning. See
  https://docs.docker.com/engine/reference/commandline/login/#credentials-store

• push image to registry

  1. rename docker images docker tag our-web-server ephrambrown/our-web-server:0.0.1 docker tag my-app $DOCKER_HUB_USERNAME/my-app:v1.0.1
  2. push image to docker hub docker push ephrambrown/our-web-server:0.0.1
  3. push image with another tag docker tag our-web-server ephrambrown/our-web-server:0.0.1 docker push ephrambrown/our-web-server:0.0.2

also, we can delete image from the browser

[solomem]

docke exec

$ docker exec -h
Flag shorthand -h has been deprecated, please use --help

Usage:  docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

Run a command in a running container

Options:
  -d, --detach               Detached mode: run command in the background
      --detach-keys string   Override the key sequence for detaching a container
  -e, --env list             Set environment variables
      --env-file list        Read in a file of environment variables
  -i, --interactive          Keep STDIN open even if not attached
      --privileged           Give extended privileges to the command
  -t, --tty                  Allocate a pseudo-TTY
  -u, --user string          Username or UID (format: <name|uid>[:<group|gid>])
  -w, --workdir string       Working directory inside the container

example: docker exec -i -t 2bf bash: This starts an interactive Bash shell within a container starting with ID 2bf with a pseudo-TTY allocated to it.

docker exec -i -t alpine sh: run bash in alpine image.

docker exec -d alpine sleep infinity

[solomem]

free spaces

1. delete the images docker rmi image1 image2 ... docker rmi -f image1 image2 ...

2. smart remove useless data docker system prune

3. You're not able to create more containers. Which of these commands will not help you reclaim enough space to create containers? df -h /

4. some can help to clean more spaces:

   • docker system prune
   • `docker rmi
   • docker rmi -f $(docker images -f "dangling=true" -q)

[solomem]

docker stats (using alpine as example)

$ docker run --name=alpine --entrypoint=sleep -d alpine infinity
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
c158987b0551: Pull complete 
Digest: sha256:8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4
Status: Downloaded newer image for alpine:latest
66db1c8c15eebb45e06794c071c6b4310e0eae6237fa79c4148575c8e6cb0412
$ docker ps
CONTAINER ID   IMAGE     COMMAND            CREATED         STATUS         PORTS     NAMES
66db1c8c15ee   alpine    "sleep infinity"   6 seconds ago   Up 5 seconds             alpine

docker stats
CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT    MEM %     NET I/O      BLOCK I/O    PIDS
66db1c8c15ee   alpine    0.00%     1.273MiB / 3.84GiB   0.03%     1.6kB / 0B   614kB / 0B   1

[solomem]

yes command

use to do the dummy run

[solomem]

docker top <image_id> (debug a slow container)

$ docker top 8b35
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                17140               17120               0                   06:52               ?                   00:00:00            sleep infinity
root                20362               17120               0                   07:00               ?                   00:00:00            sleep infinity
root                20412               17120               0                   07:00               ?                   00:00:00            sleep infinity
root                20461               17120               0                   07:00               ?                   00:00:00            sleep infinity

[solomem]

docker inspect <container name> (used to debug slow docker)

docker inspect 8b35 | less`

[solomem]

Use non-root users: it makes your containers more secure!

[solomem]

multiple dependencies scenario

docker compose !

[solomem]

Container Orchestrators