-
-
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
Question: Should containers/networks be pruned after failed tests? #739
Comments
Hey @bthalmayr, the containers and networks should be deleted after the tests and since Testcontainers 1.6 in a very reliable fashion. I don't know how stable our Docker-Machine support is ATM, can you test your setup with Docker for Mac directly? This is very well supported. Or are you actually using Docker Toolbox instead of Docker for Mac? |
Thanks for your quick reply @kiview, much appreciated. Actually deleted Docker Toolbox as documented in https://docs.docker.com/toolbox/toolbox_install_mac/#how-to-uninstall-toolbox and I thought I'm only using Docker for Mac now. I also deleted the default machine, but then I get
when running the test. Enhancing logging then showed me
and reading the Docker for Mac docs told me
so I thought Virtual box and 'docker-machine' is needed. The test uses DockerComposeContainer; is this meant to use 'docker-machine'? I'm really sorry for my insufficient knowledge, I'm trying to get up to speed as fast as possible. |
Hey @bthalmayr, You can use Docker for Mac without Docker-Machine and Virtualbox, it's totally fine. I'm sure @bsideup can give you a hint about how to cleanup your installation to correctly use Docker for Mac (I'm no Mac user). Can you also please update to Testcontainers 1.7.3, just to be sure? |
This is quite intersting @kiview , thanks for pointing this out. After removing Docker Toolbox no 'docker-machine' command was available in the shell, but after I installed Docker for Mac
was created. In fact this is a symbolic link to a binary installed by Docker for Mac app.
so I try to remove the link, so that It seems that |
too bad, when I remove the symbolic link, then no Docker environmenment can be determined at all
but even 'trace' level logging does not reveal more info. |
@bthalmayr the error you get ( |
Don't delete the symbolic link, it's okay to have Docker-Machine installed as part of Docker for Mac and should not be related to your problem. Also what @bsideup said, I mentioned the update in my previous comment 😉 |
The strange thing is that the other co-workers have the same config (Docker for Mac) and there it's working fine, so I did not think updating testcontainer to version 1.7.3 would solve it. To make sure it's not related to the integrationTest of the project, I created a simple test based on the description from https://www.testcontainers.org/usage/docker_compose.html Unfortunately I was getting the same error. After upgrading testcontainer version to 1.7.3 the simple test succeeded. I really wonder what's the difference in our team's setup. |
@bthalmayr you have Mac OS X 10.11 while your co-workers have 10.12+? :) |
I'll check this @bsideup Thanks a lot for your quick help! |
…ge pull Together with using Compose file 2.1 syntax, this is a solution to network cleanup issue described in: * #1767 * #739 * testcontainers/moby-ryuk#2 * docker/compose#6636 Solution to general credential helper authenticated pull issues in: * docker/compose#5854 Tangentially should add support for v3 syntax (not yet tested) re #531
* Upgrade docker-compose image to latest version and perform direct image pull Together with using Compose file 2.1 syntax, this is a solution to network cleanup issue described in: * #1767 * #739 * testcontainers/moby-ryuk#2 * docker/compose#6636 Solution to general credential helper authenticated pull issues in: * docker/compose#5854 Tangentially should add support for v3 syntax (not yet tested) re #531
Is this still an issue? Improvements to docker compose cleanup were introduced in #1847 - release notes here: https://github.com/testcontainers/testcontainers-java/releases/tag/1.12.4 |
@rnorth Yes, this is still an issue on Mac. Java 13/latest testcontainers/gradle 6. Log here if it is of any help
|
I can also approve that this issue still happens with the latest java-test-containers(1.12.4) private fun dockerNetworkPrune() {
ProcessExecutor()
.command("docker", "network", "prune", "-f")
.redirectOutput(System.out)
.redirectError(System.out)
.directory(composeRoot)
.exitValueNormal()
.executeNoTimeout()
} |
Thanks - if someone could provide a reproducible example I'll look into it. |
@rnorth This only occurs in MacOS when you re-run the test. import lombok.extern.slf4j.Slf4j;
import org.junit.ClassRule;
import org.testcontainers.containers.DockerComposeContainer;
import java.io.File;
@Slf4j
public class ApplicationTestsBase {
@ClassRule
public static DockerComposeContainer environment;
static {
environment = new DockerComposeContainer(new File("docker-compose-fortest.yml"))
.withExposedService("rabbitmq_1",5672)
.withExposedService("elasticsearch_1",9200);
environment.start();
int rabbitPort = environment.getServicePort("rabbitmq_1", 5672);
int elasticSearchPort = environment.getServicePort("elasticsearch_1", 9200);
System.setProperty("RABBIT_PORT", rabbitPort+"");
System.setProperty("ELASTICSEARCH_PORT", elasticSearchPort+"");
}
} #"docker-compose-fortest.yml"
version: "2"
networks:
default:
driver: bridge
ipam:
config:
- subnet: 172.177.57.0/24
services:
rabbitmq:
ports:
- '5672:5672'
- '15672:15672'
environment:
- RABBITMQ_DEFAULT_USER=admin
- RABBITMQ_DEFAULT_PASS=pwd
- RABBITMQ_DEFAULT_VHOST=admin
image: 'rabbitmq:3.7-alpine'
elasticsearch:
environment:
- discovery.type=single-node
image: 'elasticsearch:7.3.0' |
@avierr it is a known issue of Docker Compose format v2. Please use |
Hi all, appologies if this is a totally stupid question. I just started to work on a project that uses testcontainers for integration testing. Unfortunately on my Mac the tests all fail, whereas they succeed for other. In my case the fail because of
When I use 'docker-machine ls' , 'docker container ls' and 'docker network ls' after the failed test, the docker machine is still running, as well as the containers are.
I wonder if the containers and network should have been stopped and pruned after the failed test. They seem to be stopped and pruned if the test succeed.
Software used:
testcontainers: 1.7.1
Docker vor Mac: 18.03.1-ce-mac65
Docker compose: 1.21.1
Docker machine: 0.14.0
Virtual Box: 5.1.2
I already queried the docs/how to, but I could not really find a hint.
Thanks for any pointers!
The text was updated successfully, but these errors were encountered: