Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

What is Docker?

Docker uses (Linux) kernel features and puts the known chroot concept on steroids. This way we can get a universal system to build and ship applications. Docker is the popular implementation, which has informed the OCI- specification and given rise to other runtimes such as Podman.

The technical foundation

The technical foundation topics concerning Docker are:

  • Container images

    • Image registries

  • Overlay file systems

  • Linux kernel features: namespaces, cgroups, capabilities

  • Network bridge interfaces

  • Routes and IPtables

  • Build environments

  • Execution environments

    • operating system (usually a minimal Linux) and runtime dependencies (of a release build)

 In addition:
  • Possibly virtualization (for example, when Docker is used on Microsoft Windows with Docker Desktop)

  • Possibly orchestration technology (such as Kubernetes)

  • Continuous Integration (Jenkins, GitHub Actions etc.) and Continuous Deployment schemes

    • DevOps automation

Although Docker is one technology element within a DevOps stack, it belongs to the bigger topic of MicroService architectures. Such architectures can have organizational dependencies, related to team management and organization.

What is Cloud Native?

Cloud Native denotes a macro trend related to the standardization of Linux service management and Linux-based cloud computing. It’s when services are made for the cloud (including on-premises private cloudsas defined within NIST 800-145). Cloud Native services can be migrated between different kinds of cloud deployment scenarios, which may help with a defined onboarding, migration and exit strategy of the services in scope.

Docker under the hood

Unlike a virtual machine, a container does not need to boot the operating system kernel. Therefore containers can be created in less than a second.

The process isolation (which uses Linux namespaces, cgroups and other kernel features like capabilities happens within a libcontainer component called “runC”. Once a container gets instantiated, there is another runC instance.

Container images - layered deployable snapshots

Container images are layered deployable snapshots. They are self-contained portable environments which can instantiate a (Micro-)service. Subsequent versions of the same container images are stored as a differential overlay.

image-20231223-183736.png

Overlay file systems - differential snapshots

Starting from a base image, overlay file systems allow maintaining a lower storage footprint because for the following container image versions it defines the differential. This is allocated onto the disk against the layered base image.

image-20231223-184208.png

cgroups - resource quotas

cgroups is a Linux kernel feature for resource compartmentalization.

Control Groups provide a mechanism for aggregating/partitioning sets of

tasks, and all their future children, into hierarchical groups with

specialized behaviour.

The manpage is man cgroups with an s. (warning)

image-20231222-123303.png

Handy snippets

List dockerized processes

% docker ps                                                                                                marius@sofhelk
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS                  PORTS                                                      NAMES
c0ed60585f3a        cyb3rward0g/helk-spark-worker:2.4.0                   "./spark-worker-entr…"   2 months ago        Up Less than a second                                                              helk-spark-worker

Prune Docker system

% docker system prune                                                                                      
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all dangling build cache

If at the point of the prune action running containers are using a network, it will not get deleted.

Prune Docker containers

% docker container prune                                                                                   
WARNING! This will remove all stopped containers.

This will only remove stopped containers.

Stop all running containers of the host

% docker container stop $(docker container ls -aq)                                                         
c0ed60585f3a
0fc271e3ce26
...
78554ec24145

If you want to delete the containers, you can issue rm instead of the stop. The snapshot-images will still be on the system.

Delete Docker snapshot-images

docker stop $(docker ps -aq)
docker rm $(docker ps -aq)
docker rmi $(docker images -q)

Given that the containers are stopped:

% docker system prune -a                                                                                  
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all images without at least one container associated to them
        - all build cache
Are you sure you want to continue? [y/N] y
Deleted Networks:
docker_helk

Deleted Images:
untagged: confluentinc/cp-ksql-server:5.1.0
untagged: confluentinc/cp-ksql-server@sha256:6bbf25d9f682a0c12c3fefbd9e380c696957675b358c39e332047ff318d6e8a8
deleted: sha256:db9d3eaf462485ea5341ee4136380abdf4b56d0c92238f2dc68ebd8ec43d1551
deleted: sha256:e6006d635444b53e795b80697d15dcd79ded0fcd2427e4a4b796ade88ea83cea

Alternatively:

% docker rmi $(docker images -a -q)

References

  • No labels