What is a Docker container?

Published by

on

A container is a sandbox that isolates either process or application from others. Unless you explicitly connect with other containers, process under a container sees only the other processes inside the same container.
It offers a logical packaging mechanism that abstracts applications from the environments. This allowed applications to be deployed easily and consistently.
Docker is the most widely used container format, so this article will focus on describing how it works on docker containers.

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

https://www.docker.com/resources/what-container

As seen from the figure above, container runs applications on Docker Engine, which is installed on the host OS.

What is Docker Engine?

Docker engine is a containerization technology for building and containerizing the applications. It works as a client-server application with several functionalities described below.

  • A server with a long-running daemon process, called dockerd.
  • APIs which specify interfaces that programs can use to talk to and instruct the Docker daemon.
  • A CLI client docker.
  • Docker engine enables the containerized applications to run anywhere consistently on any infrastructure.

Docker components

Docker CLI

  • /usr/bin/docker
  • Docker CLI is responsible for user friendly communication with docker. Using docker build.. or docker run.. results in invocation of dockerd API

Dockerd (Docker daemon)

  • /usr/bin/dockerd
  • dockerd listens for Docker API requests and manages host’s container life cycles by utilizing containerd.
  • dockerd is the persistent process that manages containers.

Containerd


  • /usr/bin/docker-containerd
  • containerd takes the main responsibility of managing containers life-cycle.
    • The role of containerd in the whole container ecosystem here in above image, at the bottom you have all the operating system. Each of these operating systems have an isolation primitives with in them that the containerd will leverage in order to be able to create containers out of it
  • containerd provides a client layer of types that platforms can build on top of without ever having to drop down to the kernel level.
    • This makes it easier to work without calling like clone() or mount(), and instead work with Container, Task and Snapshot.
    • containerd does everything that you need to build a container platform without having to deal with underlying OS details.
  • The OCI(Open Container Initiative) is the standard in that area specifies both the image format and runtime specification for containerd so containerd will adopt OCI through runC.
    • containerd uses runc to run containers according to OCI specification.
  • containerd is the executor for containers, but takes care of multiple more than just containers. It handles:
    • Image push and pull
      • containerd is the common layer that core container runtime that you are using to pull images to run containers on any of operating system
    • Managing of storage
    • Executing containers by calling runc with the right parameters to run containers.
    • Managing of network primitives for interfaces
    • Managing of network namespaces

RunC

  • /usr/bin/docker-runc
  • runc is a component of containerd. runc is a command line client for running applications packaged according to the OCI format and is a compliant implementation of the OCI spec.

Virtual Machines vs Containers

Often times, containers are being compared with virtual machines because the concept looks similar. However, there is a significant difference between, in terms of isolations and operations.

Virtual Machines

  • An abstraction of physical hardware turning one server into multiple servers.
  • Hypervisor is needed, which allows multiple VMs to run on a single machine.
  • Each VM includes a full copy of an OS, app, necessary binaries and libraries. This consumes lots of resources, that makes it slower to boot.
  • VMs isolate everything, including system from others.

Containers

  • An abstraction at the app layer that packages codes and dependencies together.
  • Multiple containers can run on the same machine sharing the OS kernel with other containers, each running as isolated processes in user space.
  • Containers are much lightweight and use up less resources than VMs

Reference

Leave a comment

Previous Post
Next Post