Include Testcontainers in the main generator

[ecostanzi]

Overview of the feature request

I just released a new version of this module: https://github.com/intesys/generator-jhipster-testcontainers. It allows to run integration tests on sql databases with testcontainers. It's very simple (it basically adds a properties file in test resources) and it doesn't impact the existing code. A user can keep running integration tests on H2 or switching to testcontainers simply add the testcontainers profile when running tests.

What about including this in the main generator?

Motivation for or Use Case

We've been using testcontainers for a while and I think it is really helpful. Jhipster already uses this library to run test with other databases. Adding this also for sql database would be a plus for developers.

Related issues or PR

#10958

• Checking this box is mandatory (this is just to show you read everything)

[pascalgrimaud]

I'm not totally in favor of using testcontainer for SQL database integration tests, as I see some issues:

• Docker will be mandatory for all our users and I still saw a lot of issue for users with Windows
• it doesn't work out of the box for CI/CD which is inside container, you need to configure Docker in Docker and it's a pain
• the last weeks, because of current situation in the world, I work at home and use VPN. The default docker daemon can have problem to create network, which is used by testcontainer

Currently, we use testcontainer for Kafka, Redis, Cassandra because we don't have any other choice, if I remember well.

So let's discuss. I'm waiting other opinions.

[gmarziou]

I have a completely different experience from you Pascal, I started to work from home 2 weeks ago on a Windows PC and I'm glad we chose testcontainers for postgresql.

Due to this, our tests benefit from specific features like JSONB columns and enum type. It would have been impossible with H2.

[bsideup]

@pascalgrimaud

it doesn't work out of the box for CI/CD which is inside container, you need to configure Docker in Docker and it's a pain

Could you please provide more info on this one? There are no known issues with running testcontainers inside a container. Even more - we run in-container scenario as part of our CI and would not be able to do a release if it does not pass :)
https://github.com/testcontainers/testcontainers-java/blob/682bfac4e45b5a900f9ce9d6ca687af692ed6e8c/.github/workflows/ci.yml#L8

The default docker daemon can have problem to create network, which is used by testcontainer

Testcontainers does not create any networks by default. Are we talking about the same project? :D

[pascalgrimaud]

@bsideup : thanks for answering here

About CI/CD:

• for my current customer, we have a private GitLab
• all our projects use testcontainers
• our builds uses GitLab CI, and it's inside Docker
• to use testcontainers, we needed to configure our GitLab runners to activate Docker in Docker -> this task was not trivial but it's done today
• so no worry, no issue, simply I afraid it won't work out of the box for our users which will use testcontainers with Docker in Docker

About Docker Network:

Here my Docker Network before launching my integration tests which use testcontainers:

➜ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
97fc24acbe5d        bridge              bridge              local
0ee424b0c96f        host                host                local
8a7a62d024ad        none                null                local

Then, I launch the integration tests, see my Docker Network:

➜ docker network ls
NETWORK ID          NAME                                   DRIVER              SCOPE
5e918b7a914a        4ba6f0a9-4110-4c05-91dc-85386e59c4d7   bridge              local
97fc24acbe5d        bridge                                 bridge              local
0ee424b0c96f        host                                   host                local
8a7a62d024ad        none                                   null                local

➜ docker inspect 4ba6f0a9-4110-4c05-91dc-85386e59c4d7                                    
[
    {
        "Name": "4ba6f0a9-4110-4c05-91dc-85386e59c4d7",
        "Id": "5e918b7a914a76ca667ffc340b8feae05aec7b61ac347bc18950d7bd3d8d0750",
        "Created": "2020-04-04T19:25:58.893953878+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "2c12cdce6eebe889840b13f0e584257f3d002b17e52e3c4d2cc7aab2d8f708dd": {
                "Name": "crazy_hugle",
                "EndpointID": "13feeed69d8a1d40011126fa1c41573e629185716cea585d1a7a2f8b66bf7fc5",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "org.testcontainers": "true",
            "org.testcontainers.sessionId": "cb7dc8dd-6926-4915-b3da-2bf9eb62d279"
        }
    }
]

Once the build is finished, the Network is deleted:

➜ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
97fc24acbe5d        bridge              bridge              local
0ee424b0c96f        host                host                local
8a7a62d024ad        none                null                local

But for my customer, I need to use a VPN.
Once I connect to the VPN, I can't create Docker Network:

➜ docker network create toto
Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

So for my project, when I launch integration tests:

2020-04-04 19:32:05.702 ERROR 25081 --- [           main] 🐳 [confluentinc/cp-kafka:5.4.0]         : Could not start container

com.github.dockerjava.api.exception.NotFoundException: {"message":"could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network"}

	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:281)
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:265)
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.post(OkHttpInvocationBuilder.java:136)
	at com.github.dockerjava.core.exec.CreateNetworkCmdExec.execute(CreateNetworkCmdExec.java:27)
	at com.github.dockerjava.core.exec.CreateNetworkCmdExec.execute(CreateNetworkCmdExec.java:12)
	at com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
	at com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.testcontainers.dockerclient.AuditLoggingDockerClient.lambda$wrappedCommand$14(AuditLoggingDockerClient.java:99)
	at com.sun.proxy.$Proxy259.exec(Unknown Source)
	at org.testcontainers.containers.Network$NetworkImpl.create(Network.java:91)
	at org.testcontainers.containers.Network$NetworkImpl.getId(Network.java:62)
	at org.testcontainers.containers.GenericContainer.applyConfiguration(GenericContainer.java:797)
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:351)
	at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:317)
	at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81)
	at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:315)
	at org.testcontainers.containers.KafkaContainer.doStart(KafkaContainer.java:103)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302)

The problem here comes from:

• the VPN, which uses same IPs / Network than the Docker Network
• another solution would be to change the default config of local Docker

So no worry, no issue directly from testcontainers @bsideup :-)

[bsideup]

@pascalgrimaud

Thanks for your detailed answer!

to use testcontainers, we needed to configure our GitLab runners to activate Docker in Docker -> this task was not trivial but it's done today

That's one way of doing it, yes. You may also consider the "Docker wormhole" pattern which is much easier (and faster!):
https://www.testcontainers.org/supported_docker_environment/continuous_integration/dind_patterns/#docker-wormhole-pattern-sibling-docker-containers

so no worry, no issue, simply I afraid it won't work out of the box for our users which will use testcontainers with Docker in Docker

We usually say "Testcontainers works everywhere, as long as you have a Docker daemon running and accessible from your environment" (aka "if docker cli works, then Testcontainers should work too")

🐳 [confluentinc/cp-kafka:5.4.0] : Could not start container

Ah, okay, yes, some modules use networks. FYI Kafka does create a network by default (for backward compatibility) but does not require it - you can use new KafkaContainer().withNetwork(null) to disable the implicit network (we will remove it soon).

JDBC modules (like PostgreSQL, MySQL and others) do not create any network by default.

Also, the Couchbase module is being reworked, will remove the need for Socat and will be much more stable:
testcontainers/testcontainers-java#2491

[cbornet]

If I understand well, Testcontainers is used only if the profile is set. So since the user has the choice to use Testcontainers or not, I'm all for integrating this.

[DanielFran]

I also agree, if user have possibility to choose is ok for me too.

[pascalgrimaud]

@bsideup : thanks for your suggestion, it works well ! just submitted #11547 :)

After reading closely this ticket, I change my mind and agree with your proposal, @ecostanzi : it won't have any impact for our users as it's just a new profile. And be sure, I'll use it for my projects !

[atomfrede]

A little late to the discussion, but I can only support having testcontainers also for sql. We have started similar with wanting to test psql json support and testcontainers helped us e.g. to test existing apis before doing any changes to the database. When it comes to ci we have used dedicated jenkins runner for that and gitlab ci with dind and both work very well. So 👍 to integrate testcontainers for sql too!

[ecostanzi]

Good thank you all, I'll start working on this soon.

[pascalgrimaud]

I'm adding a bounty on this, although the job is done, because it was a lot of work, and a very great feature for our next release.

plz claim it @ecostanzi

[ecostanzi]

bounty claimed: https://opencollective.com/generator-jhipster/expenses/17667/ thank you very much @pascalgrimaud !