testing/deployer: support tproxy in v2 for dataplane (#19094)
This updates the testing/deployer (aka "topology test") framework to allow for a
v2-oriented topology to opt services into enabling TransparentProxy. The restrictions
are similar to that of #19046
The multiport Ports map that was added in #19046 was changed to allow for the
protocol to be specified at this time, but for now the only supported protocol is TCP
as only L4 functions currently on main.
As part of making transparent proxy work, the DNS server needed a new zonefile
for responding to virtual.consul requests, since there is no Kubernetes DNS and
the Consul DNS work for v2 has not happened yet. Once Consul DNS supports v2 we should switch over. For now the format of queries is:
<service>--<namespace>--<partition>.virtual.consul
Additionally:
- All transparent proxy enabled services are assigned a virtual ip in the 10.244.0/24
range. This is something Consul will do in v2 at a later date, likely during 1.18.
- All services with exposed ports (non-mesh) are assigned a virtual port number for use
with tproxy
- The consul-dataplane image has been made un-distroless, and gotten the necessary
tools to execute consul connect redirect-traffic before running dataplane, thus simulating
a kubernetes init container in plain docker.
Co-authored-by: R.B. Boyer <4903+rboyer@users.noreply.github.com>
testing/deployer: update deployer to use v2 catalog constructs when requested (#19046)
This updates the testing/deployer (aka "topology test") framework to conditionally
configure and launch catalog constructs using v2 resources. This is controlled via a
Version field on the Node construct in a topology.Config. This only functions for a
dataplane type and has other restrictions that match the rest of v2 (no peering, no
wanfed, no mesh gateways).
Like config entries, you can statically provide a set of initial resources to be synced
when bringing up the cluster (beyond those that are generated for you such as
workloads, services, etc).
If you want to author a test that can be freely converted between v1 and v2 then that
is possible. If you switch to the multi-port definition on a topology.Service (aka
"workload/instance") then that makes v1 ineligible.
This also adds a starter set of "on every PR" integration tests for single and multiport
under test-integ/catalogv2
Co-authored-by: R.B. Boyer <4903+rboyer@users.noreply.github.com>
* dns token
fix whitespace for docs and comments
fix test cases
fix test cases
remove tabs in help text
Add changelog
Peering dns test
Peering dns test
Partial implementation of Peered DNS test
Swap to new topology lib
expose dns port for integration tests on client
remove partial test implementation
remove extra port exposure
remove changelog from the ent pr
Add dns token to set-agent-token switch
Add enterprise golden file
Use builtin/dns template in tests
Update ent dns policy
Update ent dns template test
remove local gen certs
fix templated policy specs
* add changelog
* go mod tidy
* Support locality testing in consul-container
Support including locality in client sidecar config.
Also align test config structs with Ent to avoid future conflicts.
* Refactor consul-container fortio helpers
Refactor fortio test helpers to separate HTTP retries from waiting on
fortio result changes due to e.g. service startup and failovers.
* Adding explicit MPL license for sub-package
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Adding explicit MPL license for sub-package
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at <Blog URL>, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.
* add missing license headers
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
* fix(cli): remove failing check from 'connect envoy' registration for api gateway
* test(integration): add tests to check catalog statsus of gateways on startup
* remove extra sleep comment
* Update test/integration/consul-container/libs/assert/service.go
* changelog
1. Upgraded agent can inherit the persisted token and join the cluster
2. Agent token prior to upgrade is still valid after upgrade
3. Enable ACL in the agent configuration
- remove dep on consul main module
- use 'consul tls' subcommands instead of tlsutil
- use direct json config construction instead of agent/config structs
- merge libcluster and libagent packages together
- more widely use BuildContext
- get the OSS/ENT runner stuff working properly
- reduce some flakiness
- fix some correctness related to http/https API
* Refactoring the peering integ test to accommodate coming changes of other upgrade scenarios.
- Add a utils package under test that contains methods to set up various test scenarios.
- Deduplication: have a single CreatingPeeringClusterAndSetup replace
CreatingAcceptingClusterAndSetup and CreateDialingClusterAndSetup.
- Separate peering cluster creation and server registration.
* Apply suggestions from code review
Co-authored-by: Dan Stough <dan.stough@hashicorp.com>
hc-github-team-consul-core