Change the types for IP address and prefix struct fields to netip.Addr
and netip.Prefix for convenience. Fields such as
swarm.InitRequest.ListenAddr which may encode non-numeric values such as
a network interface name have not been modified.
Signed-off-by: Cory Snider <csnider@mirantis.com>
This change defines the generic `Storage` type for use in container inspect responses when using containerd snapshotter backend.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
The CheckpointList method previously returned a raw slice of
checkpoint.Summary, which made it difficult to extend the API response
with additional metadata or fields in the future without breaking
backward compatibility.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Use "apiClient" for the client (most places use either `apiClient`
or `c`) to prevent shadowing the `client` import.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Container.State struct holds the container's state, and most of
its fields are expected to change dynamically. Some o these state-changes
are explicit, for example, setting the container to be "stopped". Other
state changes can be more explicit, for example due to the containers'
process exiting or being "OOM" killed by the kernel.
The distinction between explicit ("desired") state changes and "state"
("actual state") is sometimes vague; for some properties, we clearly
separated them, for example if a user requested the container to be
stopped or restarted, we store state in the Container object itself;
HasBeenManuallyStopped bool // used for unless-stopped restart policy
HasBeenManuallyRestarted bool `json:"-"` // used to distinguish restart caused by restart policy from the manual one
Other properties are more ambiguous. such as "HasBeenStartedBefore" and
"RestartCount", which are stored on the Container (and persisted to
disk), but may be more related to "actual" state, and likely should
not be persisted;
RestartCount int
HasBeenStartedBefore bool
Given that (per the above) concurrency must be taken into account, most
changes to the `container.State` struct should be protected; here's where
things get blurry. While the `State` type provides various accessor methods,
only some of them take concurrency into account; for example, [State.IsRunning]
and [State.GetPID] acquire a lock, whereas [State.ExitCodeValue] does not.
Even the (commonly used) [State.StateString] has no locking at all.
The way to handle this is error-prone; [container.State] contains a mutex,
and it's exported. Given that its embedded in the [container.Container]
struct, it's also exposed as an exported mutex for the container. The
assumption here is that by "merging" the two, the caller to acquire a lock
when either the container _or_ its state must be mutated. However, because
some methods on `container.State` handle their own locking, consumers must
be deeply familiar with the internals; if both changes to the `Container`
AND `Container.State` must be made. This gets amplified more as some
(exported!) methods, such as [container.SetRunning] mutate multiple fields,
but don't acquire a lock (so expect the caller to hold one), but their
(also exported) counterpart (e.g. [State.IsRunning]) do.
It should be clear from the above, that this needs some architectural
changes; a clearer separation between "desired" and "actual" state (opening
the potential to update the container's config without manually touching
its `State`), possibly a method to obtain a read-only copy of the current
state (for those querying state), and reviewing which fields belong where
(and should be persisted to disk, or only remain in memory).
This PR preserves the status quo; it makes no structural changes, other
than exposing where we access the container's state. Where previously the
State fields and methods were referred to as "part of the container"
(e.g. `ctr.IsRunning()` or `ctr.Running`), we now explicitly reference
the embedded `State` (`ctr.State.IsRunning`, `ctr.State.Running`).
The exception (for now) is the mutex, which is still referenced through
the embedded struct (`ctr.Lock()` instead of `ctr.State.Lock()`), as this
is (mostly) by design to protect the container, and what's in it (including
its `State`).
[State.IsRunning]: c4afa77157/daemon/container/state.go (L205-L209)
[State.GetPID]: c4afa77157/daemon/container/state.go (L211-L216)
[State.ExitCodeValue]: c4afa77157/daemon/container/state.go (L218-L228)
[State.StateString]: c4afa77157/daemon/container/state.go (L102-L131)
[container.State]: c4afa77157/daemon/container/state.go (L15-L23)
[container.Container]: c4afa77157/daemon/container/container.go (L67-L75)
[container.SetRunning]: c4afa77157/daemon/container/state.go (L230-L277)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- move api/types/container.ExecOptions to the client
- rename api/types/container.ExecOptions to ExecCreateRequest
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- move api/types/container.ExecStartOptions to the client
- move api/types/container.ExecAttachOptions to the client
- rename api/types/container.ExecStartOptions to ExecStartRequest
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When running:
docker network create --ipv6 b46
docker run --rm -ti \
--network name=b46,driver-opt=com.docker.network.endpoint.sysctls=net.ipv6.conf.IFNAME.disable_ipv6=1 \
busybox
IPv6 is enabled in the container and the network, so an IPv6 address
will be allocated for the endpoint.
But, when the sysctl is applied, the IPv6 address will be removed
from the interface ... so, no unsolicited neighbour advertisement
should be (or can be) sent and, the endpoint should not be treated
as dual-stack when selecting a gateway endpoint and, if it is
selected as the gateway endpoint, setting up an IPv6 route via the
network will fail.
So, if the IPv6 address disappears after sysctls have been applied,
release the address and remove it from the endpoint's config.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When ipvlan in "l2" mode is given no '--gateway' option, an
address is allocated from IPAM and a default route is set up
via that gateway. But, the gateway address is not assigned to
anything in the Docker ipvlan network - it must be external,
and IPAM shouldn't try to guess it.
So ...
- always disable IPAM gateway address allocation for ipvlan-l2
- tell libnet to assume the endpoint has a gateway instead
- update the Join code to allow for no configured gateway
- always disable 'docker_gwbridge' connection for ipvlan
networks, so it's not hooked up when there is no gateway
address.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When macvlan is given no '--gateway' option, an address is
allocated from IPAM and a default route is set up via that
gateway. But, the gateway address is not assigned to anything
in the Docker macvlan network - it must be external, and
IPAM shouldn't try to guess it.
When IPv6 auto-configuration is enabled in the network the
macvlan is connected to, the macvlan driver races against it
to set up the gateway. When autoconfig wins, container creation
fails because the default route already exists.
So ...
- disable IPAM gateway address allocation for macvlan
- update the Join code to allow for no configured gateway
- always disable 'docker_gwbridge' connection for macvlan
networks, so it's not hooked up when there is no gateway
address.
Libnet assumes an endpoint with no statically configured default
gateway or route does not provide external connectivity. So, it
disables external DNS access, and will not select the endpoint
as gateway for containers. So, where an IPAM allocated gateway
address would have been assigned before, tell libnet to assume
there will be an auto-configured gateway.
Signed-off-by: Rob Murray <rob.murray@docker.com>
As the Engine API requests may be directed at a non-leader Swarm
manager, the information needs to be tunneled through the Swarm API.
Signed-off-by: Cory Snider <csnider@mirantis.com>
On API v1.52 and newer, the GET /networks/{id} endpoint returns
statistics about the IPAM state for the subnets assigned to the network.
Signed-off-by: Cory Snider <csnider@mirantis.com>
This package was originally internal, but was moved out when BuildKit
used it for its integration tests. That's no longer the case, so we
can make it internal again.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the option-types to the client and in some cases create a
copy for the backend. These types are used to construct query-
args, and not marshaled to JSON, and can be replaced with functional
options in the client.
The CreateOptions type was used both as options-struct for the client,
and as struct to marshal/unmarshal the request. For this type, a copy
is created in the Client and a new `checkpoint.CreateRequest` is added
in the API.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the option-types to the client and in some cases create a
copy for the backend. These types are used to construct query-
args, and not marshaled to JSON, and can be replaced with functional
options in the client.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change makes the `GraphDriver` field in `image.InspectResponse` optional. This field will only be returned when using moby engine graph drivers as a backend storage implementation. It will be omitted when using the containerd image backend.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
While the network Summary and Inspect types have been aliases in Go's
type system, in practice there is a difference: the Containers and
Services fields are only populated when inspecting a network. Split out
the common fields into a base network.Network struct which is embedded
in the network.Summary and network.Inspect types.
Signed-off-by: Cory Snider <csnider@mirantis.com>
These consts are no longer used, and separate consts were added in both
the client and daemon packages;
- client: 41da5700a4
- daemon: a632b8495b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 0ca7ac325 was merged before a review comment was addressed.
Update the warning message returned by handlePortBindingsBC to handle
the case where multiple empty port bindings slices are sent to the API.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
So far, on ContainerStart, the daemon was silently backfilling empty
PortBindings slices with a PortBinding with unspecified HostIP and
HostPort. This was done by github.com/docker/go-connections/nat.SortPortMap.
This backfilling doesn't make much sense, and we're trying to remove
that package. So, move the backfilling to the API server, keep it for
older API versions, deprecate it for API 1.52, and drop it for API 1.53
and above.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
When building a non-native platform, it's not unpacked by default.
History tries to read the disk usage of all the layer and it doesn't
handle missing snapshots gracefully.
This patch fixes this.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
BuildKit emits some additional events during build and they are not
`build.Result` so don't fail if we encounter one.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This struct is only used to report the networking state for the default
bridge network when the container is connected to it.
It was deprecated in v1.09 (API v1.21), and scheduled for removal in
v1.11. Unfortunately, the deprecation warning was wrongly formatted in
the Go code. However, deprecation warnings are already present in
swagger.yaml, so don't touch it.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
When nftablesdoc tests dump the state of nftables, the argument '-y' /
'--numeric-priority' isn't used, so all priorities should be
stringified. However, there's a bug in older versions of nftables that
prevents the stringification of the 'dstnat' priority — it's currently
dumped as '-100'.
New versions fix that, and thus running these tests on Debian 13 fails
because of this discrepancy with golden files.
So, look for 'type nat hook output priority -100' and stringify the
priority to ensure compatibility across versions of nft.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
