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

Support for external hostname for localstack #1422

Closed
wants to merge 4 commits into from

Conversation

CauchyPeano
Copy link

@CauchyPeano CauchyPeano commented Apr 24, 2019

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

Copy link
Member

@kiview kiview left a 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.

@rnorth rnorth requested a review from kiview May 7, 2019 11:34
Copy link
Member

@bsideup bsideup left a 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

@rnorth
Copy link
Member

rnorth commented May 8, 2019

Good point @bsideup. We’ll need to think about that.

This is going to get tricky if some services (inc S3, it seems?) need it to be set, but if there’s no one value that works for both access from host and access from other containers.

Sent with GitHawk

@@ -51,6 +52,10 @@ protected void configure() {

withEnv("SERVICES", services.stream().map(Service::getLocalStackName).collect(Collectors.joining(",")));

if (hostnameExternal != null) {
withEnv("HOSTNAME_EXTERNAL", hostnameExternal);
}
Copy link
Member

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.

Copy link
Member

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 use dockerHostIpAddress
    • if the container is connected to a Network and has at least one network alias, then use the first network alias

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?

Copy link
Member

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

Copy link
Member

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.

Copy link
Member

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() {
Copy link
Member

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?

Copy link
Member

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));
Copy link
Member

@bsideup bsideup Jun 21, 2019

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

Copy link
Member

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.

@rnorth
Copy link
Member

rnorth commented Sep 19, 2019

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.

@rnorth rnorth closed this Sep 19, 2019
@CauchyPeano
Copy link
Author

Yeah, sorry, I've completely lost track of this discussion :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Set HOSTNAME_EXTERNAL env variable for localstack test container
4 participants