1.1 #167
1.1 #167
Conversation
Use a TCP-unix socket proxy instead of relying on netty to support unix sockets. More tests are disabled due to OS X / docker machine coupling assumptions. Needs testing for reliability and performance, but seems to function reasonably well so far. Add a configuration strategy for proxied connections to Docker for Mac daemon on OS X Include temporary workaround for docker-java/docker-java#588
… polling of Docker API (using rate limiter for testing new JDBC container connections)
…d/missing containers
…rationStrategy to share common code
…d Netty dependencies clash
…mpatibility issues Refactor Docker compose support, to allow scaling, better output logs, and eventually docker-compose v2 format. Refs #146, #147 Start support for docker-compose v2 environments, putting ambassador containers onto the right network to be able to access the compose-launched containers. Fix Netty conflicts by using Jedis for testing (simpler dependencies)
…ntainers they link to
…ker compose container
…that don't have a slash prepended, i.e. non docker compose containers Use partial name matching for creating links between containers (in line with linked container network identification) Remove automatic setting of network mode to 'bridge' when a linked container is not on any network, as this causes an error in the current Docker API and is unnecessary.
Tidy up Docker client configuration to avoid repetitive creation of temporary clients
Add recommended logback.xml entry for testcontainers logs to be at INFO level
…onger necessary, so removal simplifies reasoning about control flow.
…pecific expected file mode
|
|
||
| <dependency> | ||
| <groupId>org.rnorth</groupId> | ||
| <artifactId>tcp-unix-socket-proxy</artifactId> |
There was a problem hiding this comment.
Until netty and/or docker-java have native support for unix domain sockets, use a slightly hacky but effective workaround of proxying over TCP. For Testcontainers' purposes, there's no perceptible performance impact.
| <transformer | ||
| implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"/> | ||
| <transformer | ||
| implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/> | ||
| </transformers> | ||
| <relocations> |
There was a problem hiding this comment.
Still need to add netty relocation
…port them (including refactoring this behaviour for LXC detection wrt. exec)
…anch Merge branch 'windows-support' of https://github.com/v-schulz/testcontainers-java into vschulz-windows-support
…ing docker-machine
use container.getContainerIpAddress() in children of GenericContainer.AbstractWaitStrategy
| @@ -191,31 +190,10 @@ private void tryStart(Profiler profiler) { | |||
| containerIsStarting(containerInfo); | |||
|
|
|||
| // Wait until the container is running (may not be fully started) | |||
| profiler.start("Wait until container state=running, or there's evidence it failed to start."); | |||
There was a problem hiding this comment.
I've removed this startup attempt loop - it might have been useful back when it was added (e.g. for startup of ambassador containers), but I don't think that is the case any more. Stability seems to be unaffected by removal.
Simplifying this should make the code much more readable and easier to reason about.
…I - docker daemon version issue?)
| class DockerCompose extends GenericContainer<DockerCompose> { | ||
| public DockerCompose(File composeFile, String identifier) { | ||
|
|
||
| super("dduportal/docker-compose:1.6.0"); |
There was a problem hiding this comment.
We have been using docker-compose 1.7.1 successfully instead of 1.6.0. Is there a reason to not upgrade this?
There was a problem hiding this comment.
@valdisrigdon Good point, thanks. I've updated and other than a very minor tweak it seems to work fine.
|
Will merge as I'm pretty comfortable that no major things need to be done. I'd expect to follow up with a point release reasonably soon to address further improvements or any necessary bugfixes. |
Main changes: