Go maintainers started to unconditionally update the minimum go version
for golang.org/x/ dependencies to go1.23, which means that we'll no longer
be able to support any version below that when updating those dependencies;
> all: upgrade go directive to at least 1.23.0 [generated]
>
> By now Go 1.24.0 has been released, and Go 1.22 is no longer supported
> per the Go Release Policy (https://go.dev/doc/devel/release#policy).
>
> For golang/go#69095.
This updates our minimum version to go1.23, as we won't be able to maintain
compatibility with older versions because of the above.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I noticed that the only reason we kept this was so that we could produce
a more targeted error for the deprecated storage-driver plugins, but it's
very unlikely someone used those, and if they did, we already had the
"DOCKERD_DEPRECATED_GRAPHDRIVER_PLUGINS" added as requirement. Let's
just produce an error if that option is set (and remove that altogether in
a later release, but just that check doesn't add significant complexity).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Explicitly set the gRPC connection params to take the timeout into
account to workaround the containerd v2 client not passing down the
stack.
containerd v2 replaced usages of deprecated gRPC functions but didn't
pass the timeout to the actual dial connection options.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
daemon/daemon.go:1570:2: naked return in func `RemapContainerdNamespaces` with 21 lines of code (nakedret)
return
^
daemon/daemon_linux.go:128:2: naked return in func `getCleanPatterns` with 14 lines of code (nakedret)
return
^
daemon/logs.go:180:2: naked return in func `getLogger` with 11 lines of code (nakedret)
return
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make it more clear that this loop is for legacy-links, and the timer is
only needed for that purpose.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that we moved to use containerd 2.0, the changes from
63b4688175
can now be used, removing some of gRPC's deprecated
options.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The default message size is set unconditionally in containerd's client,
so unlike Dial-options, there's no risk of implicitly dropping these
options.
TThis patch removes the options, as they were the same as the default
already set in containerd itself.
https://github.com/containerd/containerd/blob/v1.7.22/client.go#L133-L138
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Dial-options passed to containerd _override_ all defaults that are set
in containerd, and containerd does not provide an option to provide
the defaults in other ways, which makes it slightly more complicated
to use the defaults combined with some custom options.
https://github.com/containerd/containerd/blob/v1.7.22/client.go#L122-L132
This patch aligns the options we set with the defaults in containerd.
grpc.FailOnNonTempDialError was added together with WithBlock in [containerd@64bc516],
but it looks like this was not copied to our options when the equivalent was
added in this repository through 9f73396dab.
grpc.WithReturnConnectionError was added in [containerd@73d28dd] to improve
handling of connection errors;
Permission errors:
% ./bin/ctr t ls
ctr: failed to dial "/run/containerd/containerd.sock": connection error: desc = "transport: error while dialing: dial unix /run/containerd/containerd.sock: connect: permission denied"
%
Non-existent sockets:
% ./bin/ctr -a notfound t ls
ctr: failed to dial "notfound": context deadline exceeded: connection error: desc = "transport: error while dialing: dial unix://notfound: timeout"
%
That commit failed to notice that WithReturnConnectionError implies WithBlock,
so removing that option from the list.
Note that both WithBlock and WithReturnConnectionError are deprecated in
newer versions of grpc, so we should remove these once [containerd@63b4688]
makes it into the containerd 1.7 branch (and vendored).
[containerd@64bc516]: 64bc516bbe
[containerd@73d28dd]: 73d28ddeb2
[containerd@63b4688]: 63b4688175
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This option was marked as deprecated in cc1f3c750 (released in v20.10).
The option `fluentd-async`, introduced in the same commit, should be
used instead.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
After implementing `RWLayer` for containerd image store, implementation
of these methods is identical for both stores.
Move the logic out of the image service into the daemon.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Implement containerd image store backed `RWLayer` and remove the
containerd-specific `PrepareSnapshot` method from the ImageService
interface.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Introduce a separate `RWLayer` interface for the `container.RWLayer`
to remove coupling with the graphdriver implementation.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This code was added in 3b1d9f1a26 when the
logentries logging-driver was removed in v25.0.0. The logentries service
was already defunct, so unlikely to have any consumers, so let's remove
this code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit a0807e7cfe configured golangci-lint
to use go1.23 semantics, which alowed linters like `copyloopvar` to lint
using thee correct semantics.
go1.22 now creates a copy of variables when assigned in a loop; make sure we
don't have files that may downgrade semantics to go1.21 in case that also means
disabling that feature; https://go.dev/ref/spec#Go_1.22
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In 27.x and earlier releases libnetwork's database file was in a
sub-directory "network/files" under the daemon's root data dir.
That part of the path got lost in commit ed08486ec7
So, libnet data ended up in the daemon's main Bolt db. Then, on
upgrade, config in the original file was no longer accessible.
libnet doesn't need access to any data outside its sub-dir, so
change the meaning of its OptionDataDir - it now points at libnet's
sub-dir, so the db will be created in the right place. Also, update
other uses of that data dir to match.
Signed-off-by: Rob Murray <rob.murray@docker.com>
This logic is going to be updated to use the new containerd resolver and
needs all the logic handling resolution in the package where it is used.
Signed-off-by: Derek McGowan <derek@mcg.dev>
This function was only used internally in the daemon. This patch splits
the implementation to a non-exported version and deprecates the exported
one.
While at it, also pass through the context (which is used for tracing),
and added a note about the function potentially not being atomic.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
daemon/daemon.go:942:21: printf: non-constant format string in call to (*github.com/docker/docker/vendor/github.com/sirupsen/logrus.Entry).Errorf (govet)
log.G(ctx).Errorf(err.Error())
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 2ce811e632 migrated the use of the
userns package to the github.com/moby/sys/user module.
After further discussion with maintainers, it was decided to move the
userns package to a separate module, as it has no direct relation with
"user" operations (other than having "user" in its name).
This patch migrates our code to use the new module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The userns package in libcontainer was integrated into the moby/sys/user
module at commit [3778ae603c706494fd1e2c2faf83b406e38d687d][1].
The userns package is used in many places, and currently either depends
on runc/libcontainer, or on containerd, both of which have a complex
dependency tree. This patch is part of a series of patches to unify the
implementations, and to migrate toward that implementation to simplify
the dependency tree.
[1]: 3778ae603c
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was added in 83c2152de5 to
automatically set `/proc/sys/fs/may_detach_mounts=1` on startup.
This is a kernel config available in RHEL7.4 based kernels that enables
mountpoint removal where the mountpoint exists in other namespaces. This
setting is the default, and non-configurable, on upstream kernels since
3.15.
As this option was only supported in RHEL 7.x systems, which reached EOL,
we can remove this code, as it's not doing anything on current kernels.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This moves the `Container` type to the containere package, rename
it to `Summary`, and deprecates the old location.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a follow-up to 6da604aa6a, which
deprecated external graphdriver plugins.
This patch removes the functionality; some warnings / errors are kept in
place, but can be removed in a follow-up release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit 18f4f775ed.
Because buildkit doesn't run an internal resolver, and it bases its
/etc/resolv.conf on the host's ... when buildkit is run in a container
that has 'nameserver 127.0.0.11', its build containers will use Google's
DNS servers as a fallback (unless the build container uses host
networking).
Before, when the 127.0.0.11 resolver was not used for the default network,
the buildkit container would have inherited a site-local nameserver. So,
the build containers it created would also have inherited that DNS
server - and they'd be able to resolve site-local hostnames.
By replacing the site-local nameserver with Google's, we broke access
to local DNS and its hostnames.
Signed-off-by: Rob Murray <rob.murray@docker.com>
This function returns the default network to use for the daemon platform;
moving this to a location separate from runconfig, which is planned to
be dismantled and moved to the API.
While it might be convenient to move this utility inside api/types/container,
we don't want to advertise this function too widely, as the default returned
can ONLY be considered correct when ran on the daemon-side. An alternative
would be to introduce an argument (daemonPlatform), which isn't very convenient
to use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When the daemon crashes, the host unexpectedly reboot, or the daemon
restarts with live-restore enabled, running containers might stop and the
on-disk state for containers might diverge from reality. All these
situations are currently handled by the daemon's `restore` method.
That method calls `daemon.Cleanup()` for all the dead containers. In
turn, `Cleanup` calls `daemon.releaseNetwork()`. However, this last
method won't do anything because it expects the `netController` to be
initialized when it's called. That's not the case in the `restore` code
path -- the `netController` is initialized _after_ cleaning up dead
containers.
There's a chicken-egg problem here, and fixing that would require some
important architectural changes (eg. change the way libnet's controller
is initialized).
Since `releaseNetwork()` early exits, dead containers won't ever have
their networking state cleaned. This led to bugs in Docker Desktop,
among other things.
Fix that by calling `releaseNetwork` after initializing the
`netController`.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
