I’m Oliver, a noob to CircleCi and I’m having quite a special use case, I guess:
I need to create a docker image upon which integration tests depend on during CI-execution. I can’t load this image up to dockerhub or alike due to legal reasons.
On Travis, I launched the docker container inside Travis and connected it via --net=host (here).
On Circle-CI, I know I don’t have a docker daemon running but could connect to a remote docker host. I got the image built in this remote host (you can find some remains of it here ), but since it relies on other containers running in the primary container, and since I need a bidirectional HTTP-connection between the primary container and the built-one, I couldn’t properly get it connected.
I have seen the hints about networking on the docs, but this addresses two containers talking to each other - I need to achieve the same with the primary one. Any hints on getting them into the same network?
I read this through a couple of times, and I didn’t understand it. I think the stuff about the HTTP connection may be an example of the X-Y problem - you may be jumping to a non-optimal solution, and it is better to get readers to fully understand the problem instead.
If you cannot store the image at Dockerhub (or presumably any other third-party registry) for legal reasons, then why can you do a build at Travis or Circle? The output image is the same. Do you regard CI systems as more secure than Docker registries?
D’oh! That’s actually what I wanted to avoid. Sorry.
Let me sketch the requirement a bit more illustratively.
Requirements
This is how the application looks like, R is to be CI-ed.
Our application consists of two components, R and S. We want a CI for R.
There are parts in R which depend on S. R sends HTTP-requests to R which are responded to asynchronously (a second request the other direction).
There are integration tests between the components which shall be executed during CI
S contains GPL-components, thus we don’t distribute an image publicly but build the image on-demand for the test. (Yes, a private Docker-repo would be an option, but I don’t have one.)
I’ll post potential solutions into a separate post since I can only add one picture a post…
Looks like this was the preferred architectural way
Don’t know how to make two containers (the primary one and the on running S) see each other
@halfer I hope to have sketched the requiement properly now and separated it from potential solutions - and I’m looking forward to reading your ideas on that!
Ah, OK - it sounds like your legal reasons were just relating to the GPL then?
There is if you want one! Are you using Circle 2.0, and if so, what base image are you using? I use docker:17.05.0-ce-git and it works very well.
It strikes me also that Docker Compose would be good for this - it would allow you to bring up R and S and possibly a third image to contain your tests.
Ah, OK - it sounds like your legal reasons were just relating to the GPL then?
Yup.
I’m using version 2.
Do you have to install the docker runtime explicitly?
I’ve had no exposure on DockerCompose yet, so I might venture into that one.
Another alternative which came to my mind was to download the GPL dependencies inside the container of S (instead of building an image based upon S and ADDing them).
Not if you use the Docker base image I mentioned, it’s already installed. You can do things like docker build and login and push.
It’s how I would tackle it. I have a microservices system that pulls ~10 images into the Circle build container and then starts them up via Docker Compose. The great thing with DC is that it is really easy to learn, and it sets up networking between your containers automagically.
That’s one of the first things in the configuration file:
version: 2
jobs:
build:
working_directory: /app
docker:
- image: docker:17.05.0-ce-git
steps:
.... rest of your file here
Then you can do a checkout and maybe a docker build ... depending on your requirements. Note that there is no “step by step” guide for this, CI is not trivial to learn!
