* rust v1.62.0
* golangci-lint v1.46.2
* k3d v5.4.4
* just 1.2.0
* cargo-nextest v0.9.24
Furthermore, the build will update the development Go version to the
latest v1.17 release.
Signed-off-by: Oliver Gould <ver@buoyant.io>
3f2061d updated the repo to use `linkerd2-proxy-api` v0.4.0 with `tonic`
v0.7.0; but this change does not work properly with ARM builds, as there
no `protoc` binary available on this platform. Now that
`linkerd2-proxy-api` includes statically-generated protobuf bindings,
the policy controller no longer needs protoc at build-time.
This change also removes the use of the `tonic/transport` feature, since
it has some annoying dependency implications. Instead we build a simple
`hyper` server as tonic would.
Signed-off-by: Oliver Gould <ver@buoyant.io>
This change updates the repo to use `linkerd2-proxy-api` v0.4.0 and
updates `bin/protoc` to use v3.20 to match the configuration in the
other repo.
The policy-controller builds are updated to use our `bin/protoc` wrapper
so that all builds go through the same toolchain (and to avoid compiling
protoc on each build).
Signed-off-by: Oliver Gould <ver@buoyant.io>
The policy controller has an validating webhook for `Server` resources,
but this functionality is not really tested.
Before adding more policy resources that need validation, let's add an
integration test that exercises resource validation. The initial test is
pretty simplistic, but this is just setup.
These test also help expose two issues:
1. The change in 8760c5f--to solely use the index for validation--is
problematic, especially in CI where quick updates can pass validation
when they should not. This is fixed by going back to making API calls
when validating `Server` resources.
2. Our pod selector overlap detection is overly simplistic. This change
updates it to at least detect when a server selects _all_ pods.
There's probably more we can do here in followup changes.
Tests are added in a new `policy-test` crate that only includes these
tests and the utiltities they need. This crate is excluded when running
unit tests and is only executed when it has a Kubernetes cluster it can
execute against. A temporary namespace is created before each test is
run and deleted as the test completes.
The policy controller's CI workflow is updated to build the core control
plane, run a k3d cluster, and exercise tests. This workflow has minimal
dependencies on the existing script/CI tooling so that the dependencies
are explicit and we can avoid some of the complexity of the existing
test infrastructure.
Signed-off-by: Oliver Gould <ver@buoyant.io>
For some reason, we we hit an issue where the dockerfile wouldn't
properly recognize all dependencies. Changing up the `COPY` commands
appears to resolve the issue. I'm not really sure why.
Signed-off-by: Oliver Gould <ver@buoyant.io>
VS Code [devcontainers][dc] provide a way to define a reproducible,
customizable developer environment. This should lower the barrier to
entry for contributors and reduce the maintenance burden for existing
developers, as a docker daemon is now basically all that's needed to get
up and running.
This change adds a devcontainer for the Linkerd2 project. Its container
starts in the host's network so that it can easily access k3d clusters
running on the host's docker daemon.
[dc]: https://code.visualstudio.com/docs/remote/containers
Signed-off-by: Oliver Gould <ver@buoyant.io>
Various development tools (including Rust Analyzer and some reusable
actions) expect the root of the project to define a Cargo workspace.
In order to work more naturally with these tools, this change moves the
`Cargo.lock`, `rust-toolchain`, and `deny.toml` files to the root of the
project. A `Cargo.toml` is factored out of `policy-controller` to define
the top-level workspace.
Fixes#6743
As in #6392 for the proxy image (fixed by #6451), using the
`distroless/cc:nonroot` base image breaks the policy container in some
environments. So we're changing that to `distroless/cc`. The policy
container is already being run using a non-root user, so we're not
compromising on security.
We can't use the typical multiarch docker build with the proxy:
qemu-hosted arm64/arm builds take 45+ minutes before failing due to
missing tooling--specifically `protoc`. (While there is a `protoc`
binary available for arm64, there are no binaries available for 32-bit
arm hosts).
To fix this, this change updates the release process to cross-build the
policy-controller on an amd64 host to the target architecture. We
separate the policy-controller's dockerfiles as `amd64.dockerfile`,
`arm64.dockerfile`, and `arm.dockerfile`. Then, in CI we build and push
each of these images individually (in parallel, via a build matrix).
Once all of these are complete, we use the `docker manifest` CLI tools
to unify these images into a single multi-arch manifest.
This cross-building approach requires that we move from using
`native-tls` to `rustls`, as we cannot build against the platform-
appropriate native TLS libraries. The policy-controller is now feature-
flagged to use `rustls` by default, though it may be necessary to use
`native-tls` in local development, as `rustls` cannot validate TLS
connections that target IP addresses.
The policy-controller has also been updated to pull in `tracing-log` for
compatibility with crates that do not use `tracing` natively. This was
helpful while debugging connectivity issue with the Kubernetes cluster.
The `bin/docker-build-policy-controller` helper script now *only* builds
the amd64 variant of the policy controller. It fails when asked to build
multiarch images.
Oliver Gould
Kevin Leimkuhler
Alejandro Pedraza