Docker basics

[mattiashem]

Lets talk about docker basics

Andrey = docker
Matte = cry-o
Julan = containerd

How did the project start / how can you work local / run in prod

How is the bits connected with engine and docker

[veggiemonk]

• Video: 20m: dotScale 2013 - Solomon Hykes - Why we built Docker
• Video 5m: PyCon 2013 - The future of Linux Containers
• tutorial: The differences between Docker, containerd, CRI-O and runc

[veggiemonk]

This explains a lot in the landscape of container runtime https://youtu.be/MDsjINTL7Ek

[Andrey9kin]

My un-organised notes

Noticiable new featureless
Multi-stage builds
Passing ssh agent to docker build process
Passing secrets to docker build process
Remote cache

HEALTHCHECK
Support for Here-Documents
COPY —chown

2022 Docker compose in gaoling
https://www.docker.com/blog/announcing-compose-v2-general-availability/

Rootless mode allows running the Docker daemon and containers as a non-root user to mitigate potential vulnerabilities in the daemon and the container runtime.
Rootless mode does not require root privileges even during the installation of the Docker daemon, as long as the [prerequisites](https://docs.docker.com/engine/security/rootless/#prerequisites) are met.
Rootless mode was introduced in Docker Engine v19.03 as an experimental feature. Rootless mode graduated from experimental in Docker Engine v20.10.
How it works
Rootless mode executes the Docker daemon and containers inside a user namespace. This is very similar to [userns-remap mode](https://docs.docker.com/engine/security/userns-remap/), except that with userns-remap mode, the daemon itself is running with root privileges, whereas in rootless mode, both the daemon and the container are running without root privileges.
Rootless mode does not use binaries with SETUID bits or file capabilities, except newuidmap and newgidmap, which are needed to allow multiple UIDs/GIDs to be used in the user namespace.


2019 Mirantis

https://techcrunch.com/2022/02/09/mirantis-on-run-rate-over-100m-two-years-after-buying-docker-enterprise-assets/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAABYatg0pVJ_d9dSFs9AGztS4s0aj6zvPlrVhbXUtAM3678FQRlt_UD5PqjzKdZjsjOijyKSN9JlUjDIOKnB3xjGUuNna6OjmxCFRmP-w9js7rdPBL1uc-2Y2e3MaWQI_w6PCx1CTKvfH9xiw7fWwJz4sF3b8vrgKjb0PmWI2zPIS

BuildKit
Starting with version 18.09, Docker supports a new backend for executing your builds that is provided by the [moby/buildkit](https://github.com/moby/buildkit) project. The BuildKit backend provides many benefits compared to the old implementation. For example, BuildKit can:
	•	Detect and skip executing unused build stages
	•	Parallelize building independent build stages
	•	Incrementally transfer only the changed files in your build context between builds
	•	Detect and skip transferring unused files in your build context
	•	Use external Dockerfile implementations with many new features
	•	Avoid side-effects with rest of the API (intermediate images and containers)
	•	Prioritize your build cache for automatic pruning
To use the BuildKit backend, you need to set an environment variable DOCKER_BUILDKIT=1 on the CLI before invoking docker build. [Docker Buildx](https://github.com/docker/buildx) always enables BuildKit.



2017 Docker vs Moby 

Docker was originally developed in one codebase that held everything the project needed. This ranged from the container runtime and image builders right through to storage providers, network management, and the CLI.

As Docker adoption ballooned in the mid part of the last decade, this all-in-one approach was observed to be holding back the broader ecosystem. Complementary tools couldn’t build on specific pieces of Docker as nothing was componentized. External vendors had to bring in Docker’s entire sprawling platform.
Core functional units such as [containerd](https://www.howtogeek.com/devops/what-is-containerd-and-how-does-it-relate-to-docker-and-kubernetes/) were rapidly split out into standalone modules. The community could now create new container systems without reinventing the runtime that mediates with the kernel to start container instances. Other components like [runc](https://github.com/opencontainers/runc) and [HyperKit](https://github.com/moby/hyperkit) followed, being separated from the Docker project then pulled back into Docker Engine releases as modular dependencies.
Moby took this approach to the next level by spinning even more components out of Docker. The former docker/docker GitHub repository [became moby/moby](https://github.com/moby/moby); it holds the open-source portions of Docker Engine’s code in a community-accessible location, independently of the closed-source Docker CE and EE product repositories.



https://github.com/moby/moby/blob/master/CHANGELOG.md#17030-ce-2017-03-01

https://github.com/moby/moby/blob/master/CHANGELOG.md#1131-2017-02-08

https://github.com/moby/moby/blob/master/CHANGELOG.md#1110-2016-04-13

https://github.com/moby/moby/blob/master/CHANGELOG.md#100-2014-06-09

https://github.com/moby/moby/blob/master/CHANGELOG.md#070-2013-11-25

https://github.com/moby/moby/blob/master/CHANGELOG.md#010-2013-03-23


Before```

[Andrey9kin]

https://jamboard.google.com/d/1p_Q_E3tKkKYj7R2i8pPBCP0LVZB2I3OfdZQAYGy85JM/viewer?f=0

https://medium.com/nttlabs/nerdctl-359311b32d0e

[Andrey9kin]

https://www.youtube.com/watch?v=evWPib0iNgY