Adding image tags that follow the semver major and minor versions (e.g., `28`
and `28.3`) for the moby-bin images.
This makes it easier for users to reference the latest build within a
major or minor version series without having to know the exact
minor/patch version.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The IPsec encryption parameters (Security Association Database and
Security Policy Database entries) for a particular overlay network peer
(VTEP) are shared global state as they have to be programmed into the
root network namespace. The same parameters are used when encrypting
VXLAN traffic to a particular VTEP for all overlay networks. Deleting
the entries for a VTEP will break encryption to that VTEP across all
encrypted overlay networks, therefore the decision of when to delete the
entries must take the state of all overlay networks into account.
Unfortunately this is not the case.
The overlay driver uses local per-network state to decide when to
program and delete the parameters for a VTEP. In practice, the
parameters for all VTEPs participating in an encrypted overlay network
are deleted when the network is deleted. Encryption to that VTEP over
all other active encrypted overlay networks would be broken until some
other incidental peerDB event triggered a re-programming of the
parameters for that VTEP.
Change the setupEncryption and removeEncryption functions to be
reference-counted. The removeEncryption function needs to be called the
same number of times as addEncryption before the parameters are deleted
from the kernel.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The overlay driver assumes that the peer table in NetworkDB will always
converge to a 1:1:1 mapping from peer endpoint IP address to MAC address
to VTEP. While this currently holds true in practice most of the time,
it is not an invariant and there are ways that users can violate this
assumption.
The driver detects whether peer entries conflict with each other by
matching up (IP, MAC) tuples. In the common case this works out fine as
the MAC address for an endpoint is generally derived from the assigned
IP address. If an IP address gets reassigned to a container on another
node the MAC address will follow, so the driver's conflict resolution
logic will behave as intended. However users may explicitly configure
the MAC address for a container's network endpoints. If an IP address
gets reassigned from a container with an auto-generated MAC address to a
container with a manually-configured MAC, or vice versa, the driver
would not detect the conflict as the (IP, MAC) tuples won't match up. It
would attempt to program the kernel's neighbor table with two
conflicting MAC addresses for one IP, which will fail. And since it
does not realize that there is a conflict, the driver won't reprogram
the kernel from the remaining entry when the other entry is deleted.
The assumption that only one IP address may resolve to a given MAC
address is violated if multiple IP addresses are assigned to an
endpoint. This rarely comes up in practice today as the overlay driver
only supports IPv4 single-stack connectivity for endpoints. If multiple
distinct peer entries exist with the same MAC address, the driver will
delete the MAC->VTEP mapping from the kernel's forwarding database when
any entry is deleted, even if other entries remain active. This
limitation is one of the biggest obstacles in the way of supporting IPv6
and dual-stack connectivity for endpoints attached to overlay networks.
Modify the peer db logic to correctly handle the cases where peer
entries have non-unique MAC or VTEP values. Treat any set of entries
with non-unique IP addresses as a conflict, irrespective of the entries'
MAC addresses. Maintain a reference count of forwarding database entries
and only delete the MAC->VTEP mapping from the kernel when there are no
longer any neighbor entries which resolve to that MAC.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The peer db implementation is more complex than it needs to be.
Notably, the peerCRUD / peerCRUDOp function split is a vestige of its
evolution from a worker goroutine receiving commands over a channel.
Refactor the peer db operations to be easier to read, understand and
modify. Factor the kernel-programming operations out into dedicated
addNeighbor and deleteNeighbor functions. Inline the rest of the
peerCRUDOp functions into their respective peerCRUD wrappers.
Signed-off-by: Cory Snider <csnider@mirantis.com>
- Assert that we're not using empty IDs
- stringid.TruncateID already truncates algorithm, so we can just feed
it the full id
- Fail early on error, and skip asserting the `resp.ID` to reduce some
noise;
=== FAIL: github.com/docker/docker/integration/container TestCreateByImageID/image_short-ID (60.33s)
create_test.go:134: assertion failed: resp.ID is ""
create_test.go:135: assertion failed: error is not nil: error during connect: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.48/containers/create": EOF
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit e98e4a7111 introduced functionality
to hide experimental commands, and hide commands based on API version
negotiation. Before that commit, the user-agent header was used to detect
version-mismatches between the daemon and client based on their binary
version;
3975d648b7/api/server/middleware/user_agent.go (L32-L44)
Because of the above, a check was added to prevent custom headers from
modifying the User-Agent, but given that the user-agent header changed
formatting, and api < 1.25 is long deprecated, it's not very meaningful
to add this check, so let's remove it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting with commit 0d6e7cd983
DeleteNeighbor() needs to be called with the same options as the
AddNeighbor() call that created the neighbor entry. The calls in peerdb
were modified incorrectly, resulting in the deletes failing and leaking
neighbor entries. Fix up the DeleteNeighbor calls so that the FDB entry
is deleted from the FDB instead of the neighbor table, and the neighbor
is deleted from the neighbor table instead of the FDB.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Validation of registry mirrors was performed during daemon startup,
but after the config-file was validated. As a result, the `--validate`
option would incorrectly print that the configuration was valid, but
the daemon would fail to start;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
configuration OK
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
With this patch applied, validation is also performed as part of the
daemon config validation;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
unable to configure the Docker daemon with file ./my-config.json: merged configuration validation from file and command line flags failed: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
# fix the invalid config
echo '{"registry-mirrors":["https://example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
configuration OK
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, a missing scheme would sometimes produce a confusing
error message. If no scheme was specified at all, an empty "" would be
included in the message;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: unsupported scheme "" in "example.com"
If a scheme was missing, but a port was included, the hostname would be
printed as the scheme;
echo '{"registry-mirrors":["example.com:8080"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: unsupported scheme "example.com" in "example.com:8080"
With this patch applied, the error messages are slightly more user-friendly;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
echo '{"registry-mirrors":["example.com:8080"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com:8080": must use either 'https://' or 'http://'
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
