Skip to content
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

Docker inside the CI runner? #9

Closed
rubenv opened this issue Dec 20, 2014 · 18 comments
Closed

Docker inside the CI runner? #9

rubenv opened this issue Dec 20, 2014 · 18 comments

Comments

@rubenv
Copy link

rubenv commented Dec 20, 2014

I'm currently investigating switching over to gitlab for our CI builds.

Our build heavily uses Docker containers: during the build (to start test environments) and as an end-result: a deployable docker container.

For this to work we'd need access to Docker. Is there a way to expose the host docker inside the CI runner, so that we can control it? I'm cool with elevated privileges etc, it's all in a trusted/controlled environment anyway.

@cedvan
Copy link

cedvan commented Dec 20, 2014

Yes it's possible ! I created this feature for my work. I think create an PR, please wait ;)

@sameersbn
Copy link
Owner

@rubenv This can easily be achieved using the -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker options while starting the ci-runner. With these options you will be able to control the host docker from inside the container.

However, I would not recommend this as you can easily get access to the host filesystem like so:

docker run -it --rm -v /:/hostfs ubuntu:14.04 bash

So any individual who has access to the ci-runner will be able to do very very bas things to the host. Since gitlab-ci basically allows you to craft bash scripts for your tests, you can do all of this in a fancy web ui 😃

@sameersbn
Copy link
Owner

@rubenv Instead you should build a runner specifically designed for the software you want to test and assign it specific repo.

@cedvan
Copy link

cedvan commented Dec 23, 2014

I disagree !

I use Docker in my runners with wrapdocker sh from https://github.com/jpetazzo/dind.
All my projects use Docker and Fig, so specific runner is useless.

I created a common image runner with Docker and Fig installed.
Next I created a container runner by project using this image docker.

@sameersbn
Copy link
Owner

@cedvan My point is using -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker option for getting access to the host docker is not safe as you can very easily gain access to the host filesystem.

I have not used dind and I am not aware with the security implications it might have. Maybe its safe, maybe its not. Whatever be the case whether you decide to use it or not is a decision you have to make.

@cedvan
Copy link

cedvan commented Dec 23, 2014

I use sh of dind since three month.
I still found no error.

My projects works in dev, preprod and prod with docker and fig.
My Gitlab-CI from your images (Thank you again) and run multiple runners dind for run my tests.

For now I am satisfied with this system

@rubenv
Copy link
Author

rubenv commented Dec 23, 2014

dind isn't really much safer than exposing the host docker (you have
elevated privileges in both cases so it's possible to escape the container).

There are some very serious downsides to dind, most notably the fact that
it will fall back to devicemapper and keeps growing in disk size.

The security side of this is something you should be aware of. In our case
it's all trusted code with a known audit trail through git. If someone does
bad things, we'll know.

Thanks for the hint about mounting the socket. Simple but perfect.
On 23 Dec 2014 09:39, "Cédric Vanet" notifications@github.com wrote:

I use sh of dind since three month.
I still found no error.

My projects works in dev, preprod and prod with docker and fig.
My Gitlab-CI from your images (Thank you again) and run multiple runners
dind for run my tests.

For now I am satisfied with this system


Reply to this email directly or view it on GitHub
#9 (comment)
.

@cedvan
Copy link

cedvan commented Dec 23, 2014

@rubenv Oh Yes, I know problem storage. I have cron for clean every day containers stopped and images with tag in my runners dind. To force desired remove and run again runner container for clear the ROM.

For size /var/lib/docker is a big problem of docker with garbage collector, independant of dind, show moby/moby#6802.

Security is a problem with a big team effectively.

@cedvan
Copy link

cedvan commented Dec 23, 2014

So I do pull request with wrapdocker for run docker in runner ?

@cedvan
Copy link

cedvan commented Dec 24, 2014

Show #10

@rubenv
Copy link
Author

rubenv commented Dec 24, 2014

Probably shouldn't be the default.
On 24 Dec 2014 08:56, "Cédric Vanet" notifications@github.com wrote:

Show #10 #10


Reply to this email directly or view it on GitHub
#9 (comment)
.

@cedvan
Copy link

cedvan commented Dec 24, 2014

Ok. I close PR.

Gitlab CI Runner with support docker in runner (Work for release v5.0.0-2) :
https://github.com/cedvan/docker-gitlab-ci-runner-dind

@cedvan
Copy link

cedvan commented Dec 24, 2014

Link docker registry public : https://registry.hub.docker.com/u/cedvan/gitlab-ci-runner-dind/

@cedvan
Copy link

cedvan commented Dec 24, 2014

@sameersbn
Copy link
Owner

@cedvan You should rather create a new image based on the sameersbn/gitlab-ci-runner image. i.e.

FROM sameersbn/gitlab-ci-runner:5.0.0-1

This will allow you to very easily update the image when new versions of the runner are released.

@sameersbn sameersbn reopened this Dec 24, 2014
@cedvan
Copy link

cedvan commented Dec 24, 2014

Yes it's true.

But this is impossible because the sh wrapdocker must call in the init script in function appStart before "exec /usr/bin/supervisord". Else supervisor keeps control...

You see another solution ?

@sameersbn
Copy link
Owner

@cedvan can't wrapdocker be executed using supervisor?

@cedvan
Copy link

cedvan commented Dec 24, 2014

Hum, I'll test ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants