-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Support for external hostname for localstack #1422
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the PR, I 've added some remarks and questions.
...s/localstack/src/main/java/org/testcontainers/containers/localstack/LocalStackContainer.java
Outdated
Show resolved
Hide resolved
...s/localstack/src/main/java/org/testcontainers/containers/localstack/LocalStackContainer.java
Show resolved
Hide resolved
...s/localstack/src/main/java/org/testcontainers/containers/localstack/LocalStackContainer.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not set HOSTNAME_EXTERNAL
by default, it will break scenarios when LocalStack is being used inside a network, container-to-container style
@@ -51,6 +52,10 @@ protected void configure() { | |||
|
|||
withEnv("SERVICES", services.stream().map(Service::getLocalStackName).collect(Collectors.joining(","))); | |||
|
|||
if (hostnameExternal != null) { | |||
withEnv("HOSTNAME_EXTERNAL", hostnameExternal); | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI @bsideup, @CauchyPeano, @kiview I've removed the else clause that would set HOSTNAME_EXTERNAL
by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to progress this further and have been thinking about how to do it.
We could leave as-is, but the downside is that everyone using SQS has to remember to use withHostnameExternal( DockerClientFactory.instance().dockerHostIpAddress())
. That's an OK workaround, but I'd prefer to go with something more ergonomic...
So how about this:
- If
withHostnameExternal
or the env var has been set, always respect that - Otherwise:
- if the container is not connected to a
Network
and doesn't have a network alias, then usedockerHostIpAddress
- if the container is connected to a
Network
and has at least one network alias, then use the first network alias
- if the container is not connected to a
I think that this would work nicely out of the box.
And it should also should be backward compatible with anyone currently using HOSTNAME_EXTERNAL
manually, which is the only way that anyone can currently be using SQS in either mode.
FWIW, it's already impossible to use the SQS mock from both the host and over a docker network because HOSTNAME_EXTERNAL
can only take one value. The above approach doesn't help in that situation, but at least doesn't make it worse.
WDYT @bsideup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that might work! 👍
We could improve it later and start a proxy on localhost (so that HOSTNAME_EXTERNAL
is always localhost
) but that will require a bit of work and can be done later if the proposed solution will cause any problems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was thinking about that too, but yes we have the potential to add that later should the need arise.
Cheers - I'll implement tonight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented, with one slight difference: it is taking the last network alias, rather than the first. I've done this because:
- we have a default
tc-*****
alias generated for every container, and users can add an arbitrary number of their own aliases - it's fiddly, and creates implicit coupling across classes, to try and pick 'the first alias that is not the
tc-*****
one'. - given that all we really need is for the behaviour to be predictable and reasonable, it seems like picking the last is meets that criteria just as well as picking the first.
} | ||
|
||
@Test | ||
public void hostnameSqsTest() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if we could make this test verify correct end-to-end behaviour rather than just check that the URL reflects the provided hostname.
Is there an easy to test scenario where the external hostname matters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have added some tests using AWS CLI.
|
||
CreateQueueResult queueResult = sqs.createQueue("baz"); | ||
String fooQueueUrl = queueResult.getQueueUrl(); | ||
assertThat("Created queue has external hostname URL", fooQueueUrl, containsString(TEST_HOSTNAME)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not critical, but would be better to parse the returned URL and compare the host, otherwise result like foobar.localhost
will pass too, but fail in real world
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now comparing with the full URL; still using the slightly simplistic string contains mechanism though.
It looks like my commits were disappearing into the ether (or at least not landing on this PR), so I've created #1891 to replace it. |
Yeah, sorry, I've completely lost track of this discussion :) |
Was not sure whether it's good idea to introduce new dependency for testing, but it's so far needed to prove that feature works.
Fixes #1102