Rancher + Jenkins + docker compose

Rancher 1.x
1

I’ve got a Jenkins instance running as a Rancher stack. From a build step in a Jenkinsfile (running on the Jenkins container, NOT a docker build container), I’m bringing up 2 services with docker compose CLI (so not rancher compose). The reason I’m not using Rancher compose is that this compose does a Docker build, and we’re not using S3, nor did I want to point it to a Git repo, etc, etc…

When these two services come up, one service (let’s call it service A) attempts a web service call to the other service (service B). This has to work or the deployment fails.

Once the services are up, I then attempt to run some integration tests against service A in another build step - this one will be inside a docker build container (Java/Maven).

All of these containers would ideally be on the same network are the Jenkins container (i.e. the Rancher managed network), so they could all communicate with each other. I see that this can be done by specifying the label io.rancher.container.network: “true” on the containers. I have done this, and yes the containers appear to be on the Rancher network. They show up on the GUI with 10.42.X.X IP addresses.

However (and this is the problem), the 2 services in the compose file can now not see each other. In fact, they can’t seem to see anything at all. Pinging the other containers with the IP addresses or service names is unsuccessful. So the WS call from service A to service B fails, and the build fails.

If I don’t join the services in the compose file to the Rancher network, it works as expected. service A can resolve service B.

So - does anyone know if what I’m trying to do will work, and how? Is there a best practice around this?

2

I’ve got this to work by doing the following:

  • Add the containers to the Rancher network
  • Remove the bridge network
  • specify a container name

Removing the bridge network allowed the containers to communicate using the Rancher-assigned IP address, but then the was the problem of resolving the container name. Both of these (the IP and container name) obviously aren’t available at build time, so specifying the name in the compose file sorted this out.

I’m still unsure as to why it didn’t work in the first place, but at least I can progress now.

For example:

services:
service-a:
container_name: service-a
image: localhost:5000/service-a
ports:
- "8092:8080"
labels:
io.rancher.container.network: "true"
network_mode: “none”