Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v17] Add multi-port support for TCP apps #49711

Open
wants to merge 3 commits into
base: branch/v17
Choose a base branch
from

Conversation

ravicious
Copy link
Member

Backport #47706, #49047, #49453

This is the "backend" part of multi-port support. The only conflicts were in protos, since #49300 adds AppIdentityCenter to AppSpecV3 under the index of 12 but it hasn't been merged yet (I guess it waits for v17.1 too).

* Add Ports to AppSpecV3

* Validate ports of api/types.AppV3

* Add Ports to lib/config and lib/service/servicecfg

* lib/config TestApps: Improve error messages

* lib/service: Convert servicecfg.PortRange to types.PortRange

* Add multi-port TCP apps to config and tctl tests

* Rename Ports to TCPPorts

* Change port fields to uint16 where possible

* Update comments for Port and EndPort

* Extract port range validation to api/utils/net

* Replace custom check type with require.ErrorAssertionFunc
…ti-port TCP apps

* Add TargetPort to RouteToApp and AppMetadata proto messages

* Pass TargetPort during cert generation

* Refactor Pack.makeTLSConfig to accept struct

This will make it easier to add targetPort to it.

* Add labels to UUIDs used by appaccess test pack app servers

This makes them easier to distinguish when routing doesn't work as expected.

* Refactor Pack.CreateAppSession to accept a struct

* TestTCP: Create app session within test

If we kept the old code, we'd need to manually create a session for each
target port, which would create a lot of duplication.

* Prepare integration test fixtures for multi-port tests

* Add api/utils/net.IsPortInRange

* Use TargetPort when routing TCP connections

* Inline dialMultiPortTCPApp, centralize logic

* Check target port when connecting to single-port app

* Reorder check in IsPortInRange

* Use int instead of uint16

* Extract picking dialTarget to separate function

* Improve err msg for single-port apps when targetPort != uriPort

* Fix unnecessary conversion to int
* Prepare app specs in tests for specifying TCP ports

* Refactor logging in lib/vnet/app_resolver.go

Use libutils.NewPackageLogger, call it log instead of slog which makes
it harder to use the imported default slog logger instead of the one from
a struct.

Move creation of logger within TCPAppResolver.resolveTCPHandlerForCluster

* Pass port from VNet to local proxy

* Don't create another package logger

* Don't pass logger to newTCPAppHandler

* Fix typo in comment

* Explicitly pass port to dialHost

* Convert multi-line definitions of simple appSpecs to single-line

* Add TODO comment about validating local port

* Empty commit to trigger CI
Copy link
Contributor

@nklaassen nklaassen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure one of the backports gets a changelog entry

@@ -994,6 +994,11 @@ message AppSpecV3 {
repeated string RequiredAppNames = 10 [(gogoproto.jsontag) = "required_app_names,omitempty"];
// CORSPolicy defines the Cross-Origin Resource Sharing settings for the app.
CORSPolicy CORS = 11 [(gogoproto.jsontag) = "cors,omitempty"];
// TCPPorts is a list of ports and port ranges that an app agent can forward connections to.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// TCPPorts is a list of ports and port ranges that an app agent can forward connections to.
reserved 12;
reserved "IdentityCenter";
// TCPPorts is a list of ports and port ranges that an app agent can forward connections to.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that going to conflict with #49300 which backports IdentityCenter? As in, wouldn't it make #49300 impossible to merge if this PR gets merged first?

This comment was marked as off-topic.

This comment was marked as off-topic.

@ravicious ravicious removed the request for review from espadolini December 4, 2024 09:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants