-
-
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
[WIP] Docker compose refactor #156
Conversation
/** | ||
* Approach to determine whether a container has 'started up' correctly. | ||
*/ | ||
public abstract class StartupCheckStrategy { |
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.
ambassadorContainer.start(); | ||
localProfiler.start("Start ambassador container"); | ||
|
||
ambassadorContainer.start(); |
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.
Injecting environment variables is important for our use-case because we want to be able to specify the version of an image in CI, to support multiple branches building in parallel. Our docker-compose file will look something like: version: "2"
services:
foo:
image: our-registry:5000/repo/foo:${version}
|
@haines thanks - thought that would be the case. I will make sure environment variables are carried over. Also, volume mounts probably should be too, to allow for things like mounting |
9b760a1
to
10ad475
Compare
ResourceReaper.instance().registerContainerForCleanup(container.getId(), container.getNames()[0])); | ||
|
||
// Ensure that the default network for this compose environment, if any, is also cleaned up | ||
ResourceReaper.instance().registerNetworkForCleanup(identifier + "_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.
Any reason to do this manually rather than replacing docker-compose rm -f -v
with docker-compose down -v
?
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
0274634
to
127715e
Compare
Closing in deference to #167 |
Refactoring (incomplete) of
DockerComposeContainer
to more cleanly use multiple invocations ofdocker-compose
during the test lifecycle.DockerComposeContainer
is now no longer a container itself; it's merely a JUnit rule that creates and runs adocker-compose
container as necessary.I suspect this may break things if people are (for example) mapping volumes or injecting env vars into their compose container, so it'd be good to understand these kind of use cases and work to support them.