-
Notifications
You must be signed in to change notification settings - Fork 5
Add support for parallel testing #1
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
Closed
Closed
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
b404c99
add func to generate random names for compose files
mdevilliers b29624e
retrieve the Network settings for a container
mdevilliers 74f9f64
comment struct
mdevilliers bbaec2d
generate a random name for the compose project, run through all of th…
mdevilliers b8a77d7
add funcs to start in a 'safe' parallel configuration
mdevilliers a7227f4
go vet is included by default
mdevilliers 51c1a05
bump up version in travis to 1.8
mdevilliers cf4b9f0
test parallel launching and connecting
mdevilliers b7ef0cb
unexport method - appeasing the linting gods
mdevilliers 3da23ff
expose a StartProject method for fine grained control of all properties
mdevilliers File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Is this actually needed? What I've traditionally been doing is assuming that the IP address for the service is the one returned by InferDockerHost(), so you could for example find the IP:port of a container by doing this:
mockServerURL := fmt.Sprintf("%v:%v", MustInferDockerHost(), compose.Containers["container-name"].MustGetFirstPublicPort(1080, "tcp"))
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'll tell you what I was thinking -
InferDockerHost gives you the IPAddress for the machine running the Docker daemon - so for me on Ubuntu it is localhost but if I was running a Mac and using the Docker toolbox (or Docker Machine or whatever it is called now) it would be the IPAddress of the virtual machine running the Docker daemon.
GetPublicIPAddressForService should give you the IPAddress the docker daemon has allocated for the container for the service defined in the docker-compose file.
InferDockerHost is really useful if your docker-compose file maps container ports to "where ever the docker daemon is running". When you are running simultaneous copies of the docker-compose file you really need to know the IPAddress of the container to call into from your test and that was why I added the method.
Uh oh!
There was an error while loading. Please reload this page.
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.
Sorry I'm still not sure I'm clear on this one - my understanding is that if you want to access a container from a test (i.e. from outside the virtual Docker network) your only option is to ask Docker to bind an exposed port from a container to a port on the host network, because the internal IP address of the container won't be reachable from the host otherwise.
You can do that using the "ports" section in the compose file. You won't be able to specify the port in the "hostport:containerport" format as the second container will fail to start because the port on the host is already taken. If you only specify the "containerport" port, Docker will automatically allocate a free port on the host network, and you can find out which one it is using
MustGetFirstPublicPort
.Maybe I'm missing something though - is there a way to route from the host network to an IP address in the virtual Docker network?
Note that if you are instead trying to connect to a container from another one, you can just specify the dependency in the "links" section and use the container name as hostname, as the virtual Docker network has a DNS server which will resolve it to the internal IP address of the container.
Uh oh!
There was an error while loading. Please reload this page.
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 added a test - TestParallelMustConnectWithDefaults which shows the GetPublicIPAddressForService method being used to address the containers.
Uh oh!
There was an error while loading. Please reload this page.
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.
So for example on my machine, if I do:
I get
Then
I get
Then
It times out. But:
Gives me
Which tells me that I can connect to this container using port 32769 on the Docker host. In my case, since I'm using boot2docker, it would be:
Which works! In your case it'd be "localhost:32769". If I did:
The first one would succeed and I would be able to connect using
curl -v http://192.168.99.100:1080
, the second one would fail with this error message:If I did:
Then I'd get:
Which means I'd still be able to reach both containers using different ports.
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.
Ahh I see what you mean now by just specifying a "containerport" port.
I think that makes sense to me - I've always just used the IPAddress (probably too much as I've spent a lot of time with K8s)
I'll have a little think...
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.
Okay,
Removing the GetPublicIPAddressForService and using the InferDockerHost method has one issue and that is getting the access to the correct container by name.
I hadn't noticed before that in the tests and examples you were using the "container_name" attribute to fix the name to a known value. Understandably Docker just barfs if you try to run multiple instances with the same name.
I propose a fix where I ensure that the container has the same name as the service in the returned collection of containers. This means it is possible to reliably get to the container/service you want. It is however I fear a breaking change.
To illustrate -
would return two containers in the collection called 'test_mockserver' and 'test_postgres'. I can pick out the originally specified name from the labels written by docker-compose. In both cases the actual name of the docker container would just be the usual unreliable junk.
Do you have any thoughts?
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.
Sounds good, would you mind coding that up?