2cf230951f
This repository is not yet a module (i.e., does not have a `go.mod`). This
is not problematic when building the code in GOPATH or "vendor" mode, but
when using the code as a module-dependency (in module-mode), different semantics
are applied since Go1.21, which switches Go _language versions_ on a per-module,
per-package, or even per-file base.
A condensed summary of that logic [is as follows][1]:
- For modules that have a go.mod containing a go version directive; that
version is considered a minimum _required_ version (starting with the
go1.19.13 and go1.20.8 patch releases: before those, it was only a
recommendation).
- For dependencies that don't have a go.mod (not a module), go language
version go1.16 is assumed.
- Likewise, for modules that have a go.mod, but the file does not have a
go version directive, go language version go1.16 is assumed.
- If a go.work file is present, but does not have a go version directive,
language version go1.17 is assumed.
When switching language versions, Go _downgrades_ the language version,
which means that language features (such as generics, and `any`) are not
available, and compilation fails. For example:
# github.com/docker/cli/cli/context/store
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/store.go:74:12: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
Note that these fallbacks are per-module, per-package, and can even be
per-file, so _(indirect) dependencies_ can still use modern language
features, as long as their respective go.mod has a version specified.
Unfortunately, these failures do not occur when building locally (using
vendor / GOPATH mode), but will affect consumers of the module.
Obviously, this situation is not ideal, and the ultimate solution is to
move to go modules (add a go.mod), but this comes with a non-insignificant
risk in other areas (due to our complex dependency tree).
We can revert to using go1.16 language features only, but this may be
limiting, and may still be problematic when (e.g.) matching signatures
of dependencies.
There is an escape hatch: adding a `//go:build` directive to files that
make use of go language features. From the [go toolchain docs][2]:
> The go line for each module sets the language version the compiler enforces
> when compiling packages in that module. The language version can be changed
> on a per-file basis by using a build constraint.
>
> For example, a module containing code that uses the Go 1.21 language version
> should have a `go.mod` file with a go line such as `go 1.21` or `go 1.21.3`.
> If a specific source file should be compiled only when using a newer Go
> toolchain, adding `//go:build go1.22` to that source file both ensures that
> only Go 1.22 and newer toolchains will compile the file and also changes
> the language version in that file to Go 1.22.
This patch adds `//go:build` directives to those files using recent additions
to the language. It's currently using go1.19 as version to match the version
in our "vendor.mod", but we can consider being more permissive ("any" requires
go1.18 or up), or more "optimistic" (force go1.21, which is the version we
currently use to build).
For completeness sake, note that any file _without_ a `//go:build` directive
will continue to use go1.16 language version when used as a module.
[1]:
|
||
---|---|---|
.. | ||
bitmap | ||
cluster | ||
cmd | ||
config | ||
datastore | ||
diagnostic | ||
discoverapi | ||
docs | ||
driverapi | ||
drivers | ||
drvregistry | ||
etchosts | ||
internal | ||
ipam | ||
ipamapi | ||
ipams | ||
ipamutils | ||
ipbits | ||
iptables | ||
netlabel | ||
netutils | ||
networkdb | ||
ns | ||
options | ||
osl | ||
portallocator | ||
portmapper | ||
resolvconf | ||
scope | ||
support | ||
types | ||
.dockerignore | ||
.gitignore | ||
agent.go | ||
agent.pb.go | ||
agent.proto | ||
controller.go | ||
controller_linux.go | ||
controller_others.go | ||
default_gateway.go | ||
default_gateway_freebsd.go | ||
default_gateway_linux.go | ||
default_gateway_windows.go | ||
drivers_freebsd.go | ||
drivers_ipam.go | ||
drivers_linux.go | ||
drivers_unsupported.go | ||
drivers_windows.go | ||
endpoint.go | ||
endpoint_cnt.go | ||
endpoint_info.go | ||
endpoint_info_unix.go | ||
endpoint_info_windows.go | ||
endpoint_unix_test.go | ||
error.go | ||
errors_test.go | ||
firewall_linux.go | ||
firewall_linux_test.go | ||
firewall_others.go | ||
libnetwork_internal_test.go | ||
libnetwork_linux_test.go | ||
libnetwork_unix_test.go | ||
libnetwork_windows_test.go | ||
network.go | ||
network_unix.go | ||
network_windows.go | ||
README.md | ||
resolver.go | ||
resolver_test.go | ||
resolver_unix.go | ||
resolver_unix_test.go | ||
resolver_windows.go | ||
sandbox.go | ||
sandbox_dns_unix.go | ||
sandbox_dns_unix_test.go | ||
sandbox_dns_windows.go | ||
sandbox_externalkey_unix.go | ||
sandbox_externalkey_unsupported.go | ||
sandbox_linux.go | ||
sandbox_options.go | ||
sandbox_store.go | ||
sandbox_unix_test.go | ||
sandbox_unsupported.go | ||
service.go | ||
service_common.go | ||
service_common_unix_test.go | ||
service_linux.go | ||
service_unsupported.go | ||
service_windows.go | ||
store.go | ||
store_linux_test.go | ||
store_test.go |
libnetwork - networking for containers
Libnetwork provides a native Go implementation for connecting containers
The goal of libnetwork is to deliver a robust Container Network Model that provides a consistent programming interface and the required network abstractions for applications.
Design
Please refer to the design for more information.
Using libnetwork
There are many networking solutions available to suit a broad range of use-cases. libnetwork uses a driver / plugin model to support all of these solutions while abstracting the complexity of the driver implementations by exposing a simple and consistent Network Model to users.
package main
import (
"fmt"
"log"
"github.com/docker/docker/libnetwork"
"github.com/docker/docker/libnetwork/config"
"github.com/docker/docker/libnetwork/netlabel"
"github.com/docker/docker/libnetwork/options"
)
func main() {
// Select and configure the network driver
networkType := "bridge"
// Create a new controller instance
driverOptions := options.Generic{}
genericOption := make(map[string]interface{})
genericOption[netlabel.GenericData] = driverOptions
controller, err := libnetwork.New(config.OptionDriverConfig(networkType, genericOption))
if err != nil {
log.Fatalf("libnetwork.New: %s", err)
}
// Create a network for containers to join.
// NewNetwork accepts Variadic optional arguments that libnetwork and Drivers can use.
network, err := controller.NewNetwork(networkType, "network1", "")
if err != nil {
log.Fatalf("controller.NewNetwork: %s", err)
}
// For each new container: allocate IP and interfaces. The returned network
// settings will be used for container infos (inspect and such), as well as
// iptables rules for port publishing. This info is contained or accessible
// from the returned endpoint.
ep, err := network.CreateEndpoint("Endpoint1")
if err != nil {
log.Fatalf("network.CreateEndpoint: %s", err)
}
// Create the sandbox for the container.
// NewSandbox accepts Variadic optional arguments which libnetwork can use.
sbx, err := controller.NewSandbox("container1",
libnetwork.OptionHostname("test"),
libnetwork.OptionDomainname("example.com"))
if err != nil {
log.Fatalf("controller.NewSandbox: %s", err)
}
// A sandbox can join the endpoint via the join api.
err = ep.Join(sbx)
if err != nil {
log.Fatalf("ep.Join: %s", err)
}
// libnetwork client can check the endpoint's operational data via the Info() API
epInfo, err := ep.DriverInfo()
if err != nil {
log.Fatalf("ep.DriverInfo: %s", err)
}
macAddress, ok := epInfo[netlabel.MacAddress]
if !ok {
log.Fatal("failed to get mac address from endpoint info")
}
fmt.Printf("Joined endpoint %s (%s) to sandbox %s (%s)\n", ep.Name(), macAddress, sbx.ContainerID(), sbx.Key())
}
Contributing
Want to hack on libnetwork? Docker's contributions guidelines apply.
Copyright and license
Code and documentation copyright 2015 Docker, inc. Code released under the Apache 2.0 license. Docs released under Creative commons.