9b2f55bc1c
Welcome to the v1.5.0 release of containerd! The sixth major release of containerd includes many stability improvements and code organization changes to make contribution easier and make future features cleaner to develop. This includes bringing CRI development into the main containerd repository and switching to Go modules. This release also brings support for the Node Resource Interface (NRI). Highlights -------------------------------------------------------------------------------- *Project Organization* - Merge containerd/cri codebase into containerd/containerd - Move to Go modules - Remove selinux build tag - Add json log format output option for daemon log *Snapshots* - Add configurable overlayfs path - Separate overlay implementation from plugin - Native snapshotter configuration and plugin separation - Devmapper snapshotter configuration and plugin separation - AUFS snapshotter configuration and plugin separation - ZFS snapshotter configuration and plugin separation - Pass custom snapshot labels when creating snapshot - Add platform check for snapshotter support when unpacking - Handle loopback mounts - Support userxattr mount option for overlay in user namespace - ZFS snapshotter implementation of usage *Distribution* - Improve registry response errors - Improve image pull performance over HTTP 1.1 - Registry configuration package - Add support for layers compressed with zstd - Allow arm64 to fallback to arm (v8, v7, v6, v5) *Runtime* - Add annotations to containerd task update API - Add logging binary support when terminal is true - Runtime support on FreeBSD *Windows* - Implement windowsDiff.Compare to allow outputting OCI images - Optimize WCOW snapshotter to commit writable layers as read-only parent layers - Optimize LCOW snapshotter use of scratch layers *CRI* - Add NRI injection points cri#1552 - Add support for registry host directory configuration - Update privileged containers to use current capabilities instead of known capabilities - Add pod annotations to CNI call - Enable ocicrypt by default - Support PID NamespaceMode_TARGET Impactful Client Updates -------------------------------------------------------------------------------- This release has changes which may affect projects which import containerd. *Switch to Go modules* containerd and all containerd sub-repositories are now using Go modules. This should help make importing easier for handling transitive dependencies. As of this release, containerd still does not guarantee client library compatibility for 1.x versions, although best effort is made to minimize impact from changes to exported Go packages. *CRI plugin moved to main repository* With the CRI plugin moving into the main repository, imports under github.com/containerd/cri/ can now be found github.com/containerd/containerd/pkg/cri/. There are no changes required for end users of CRI. *Library changes* oci The WithAllCapabilities has been removed and replaced with WithAllCurrentCapabilities and WithAllKnownCapabilities. WithAllKnownCapabilities has similar functionality to the previous WithAllCapabilities with added support for newer capabilities. WithAllCurrentCapabilities can be used to give privileged containers the same set of permissions as the calling process, preventing errors when privileged containers attempt to get more permissions than given to the caller. *Configuration changes* New registry.config_path for CRI plugin registry.config_path specifies a directory to look for registry hosts configuration. When resolving an image name during pull operations, the CRI plugin will look in the <registry.config_path>/<image hostname>/ directory for host configuration. An optional hosts.toml file in that directory may be used to configure which hosts will be used for the pull operation as well host-specific configurations. Updates under that directory do not require restarting the containerd daemon. Enable registry.config_path in the containerd configuration file. [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d" Configure registry hosts, such as /etc/containerd/certs.d/docker.io/hosts.toml for any image under the docker.io namespace (any image on Docker Hub). server = "https://registry-1.docker.io" [host."https://public-mirror.example.com"] capabilities = ["pull"] [host."https://docker-mirror.internal"] capabilities = ["pull", "resolve"] ca = "docker-mirror.crt" If no hosts.toml configuration exists in the host directory, it will fallback to check certificate files based on Docker's certificate file pattern (".crt" files for CA certificates and ".cert"/".key" files for client certificates). *Deprecation of registry.mirrors and registry.configs in CRI plugin* Mirroring and TLS can now be configured using the new registry.config_path option. Existing configurations may be migrated to new host directory configuration. These fields are only deprecated with no planned removal, however, these configurations cannot be used while registry.config_path is defined. *Version 1 schema is deprecated* Version 2 of the containerd configuration toml is recommended format and the default. Starting this version, a deprecation warning will be logged when version 1 is used. To check version, see the version value in the containerd toml configuration. version=2 FreeBSD Runtime Support (Experimental) -------------------------------------------------------------------------------- This release includes changes that allow containerd to run on FreeBSD with a compatible runtime, such as runj. This support should be considered experimental and currently there are no official binary releases for FreeBSD. The runtimes used by containerd are maintained separately and have their own stability guarantees. The containerd project strives to be compatible with any runtime which aims to implement containerd's shim API and OCI runtime specification. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> |
||
---|---|---|
.github | ||
api | ||
builder | ||
cli | ||
client | ||
cmd/dockerd | ||
container | ||
contrib | ||
daemon | ||
distribution | ||
dockerversion | ||
docs | ||
errdefs | ||
hack | ||
image | ||
integration | ||
integration-cli | ||
internal/test/suite | ||
layer | ||
libcontainerd | ||
oci | ||
opts | ||
patches | ||
pkg | ||
plugin | ||
profiles | ||
project | ||
quota | ||
reference | ||
registry | ||
reports | ||
restartmanager | ||
rootless | ||
runconfig | ||
testutil | ||
vendor | ||
volume | ||
.DEREK.yml | ||
.dockerignore | ||
.gitignore | ||
.mailmap | ||
AUTHORS | ||
CHANGELOG.md | ||
codecov.yml | ||
CONTRIBUTING.md | ||
Dockerfile | ||
Dockerfile.buildx | ||
Dockerfile.e2e | ||
Dockerfile.simple | ||
Dockerfile.windows | ||
Jenkinsfile | ||
LICENSE | ||
MAINTAINERS | ||
Makefile | ||
NOTICE | ||
poule.yml | ||
README.md | ||
ROADMAP.md | ||
SECURITY.md | ||
TESTING.md | ||
vendor.conf | ||
VENDORING.md |
The Moby Project
Moby is an open-source project created by Docker to enable and accelerate software containerization.
It provides a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas. Components include container build tools, a container registry, orchestration tools, a runtime and more, and these can be used as building blocks in conjunction with other tools and projects.
Principles
Moby is an open project guided by strong principles, aiming to be modular, flexible and without too strong an opinion on user experience. It is open to the community to help set its direction.
- Modular: the project includes lots of components that have well-defined functions and APIs that work together.
- Batteries included but swappable: Moby includes enough components to build fully featured container system, but its modular architecture ensures that most of the components can be swapped by different implementations.
- Usable security: Moby provides secure defaults without compromising usability.
- Developer focused: The APIs are intended to be functional and useful to build powerful tools. They are not necessarily intended as end user tools but as components aimed at developers. Documentation and UX is aimed at developers not end users.
Audience
The Moby Project is intended for engineers, integrators and enthusiasts looking to modify, hack, fix, experiment, invent and build systems based on containers. It is not for people looking for a commercially supported system, but for people who want to work and learn with open source code.
Relationship with Docker
The components and tools in the Moby Project are initially the open source components that Docker and the community have built for the Docker Project. New projects can be added if they fit with the community goals. Docker is committed to using Moby as the upstream for the Docker Product. However, other projects are also encouraged to use Moby as an upstream, and to reuse the components in diverse ways, and all these uses will be treated in the same way. External maintainers and contributors are welcomed.
The Moby project is not intended as a location for support or feature requests for Docker products, but as a place for contributors to work on open source code, fix bugs, and make the code more useful. The releases are supported by the maintainers, community and users, on a best efforts basis only, and are not intended for customers who want enterprise or commercial support; Docker EE is the appropriate product for these use cases.
Legal
Brought to you courtesy of our legal counsel. For more context, please see the NOTICE document in this repo.
Use and transfer of Moby may be subject to certain restrictions by the United States and other governments.
It is your responsibility to ensure that your use and/or transfer does not violate applicable laws.
For more information, please see https://www.bis.doc.gov
Licensing
Moby is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.