<p>To avoid relying on <code>dind</code> (out of building new images from a dockerfile which should be ok) I'd look around <a href="https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin" rel="nofollow noreferrer">Jenkins's kubernetes</a> plugin.</p>

<p>It obviously needs to bring to life a kubernetes cluster but allow to have a one time jenkins agent to run the test in a clean isolated environment, and then tear it off. The maintenance costs of the kubernetes cluster should not be greater than maintaining your Jenkins slaves. </p>

<p>The bonus point is that you can version you slaves with specific environment and don't have to tweak around for multiples version of ruby/java/python and let the task choose the proper "environment" by specifying the agent image to use and have a ready to test environment without any tweak pre-test. </p>

<p>I'd head toward kurbenetes as container scheduler because it is relatively lightweight to configure and maintain.</p>

CC BY-SA 3.0
2017-03-28T11:49:25.173Z
great approach, as an alternative mesos, swarm can be used, IMO swarm is a great candidate just because of relatively easy maintenance but can come with price of stability, too fresh technology
rombob
CC BY-SA 3.0
2017-03-28T11:50:49.017Z
@rombob indeed, and mesos is quite heavy to maintain and probably overkill for this use case, I was wondering if stating this comparison/point would make sense in this answer.
Tensibai
CC BY-SA 3.0
2017-03-28T11:53:57.487Z
maybe comparison would be great candidate for a new question
rombob
CC BY-SA 3.0
2017-03-28T11:58:17.097Z
@rombob Usually they fade out of useful very quickly, specially with swarm under active development it would need an update nearly each week. So I would avoid it, even [a blog post](http://rancher.com/comparing-rancher-orchestration-engine-options/) isn't really clear on the question after a whole list or pro/cons
Tensibai
CC BY-SA 3.0
2018-03-12T11:18:32.977Z
When using the Jenkins Kubernetes plugin how do you dynamically choose a container to build in. I use the Jenkins Kubernetes plugin, but I still use dind because I want to build inside containers. I have a slave container with dind in it, but there has to be a better way.
David West
CC BY-SA 4.0
2019-05-21T00:05:50.383Z
Also have a look at Kaniko to build docker images in Kubernetes without a docker daemon or DIND.

https://github.com/GoogleContainerTools/kaniko
casey vega
CC BY-SA 3.0
2017-03-28T11:44:34.640Z
2017-03-28T15:12:11.807Z
2017-03-28T15:12:11.807Z
Tensibai
<p>When using Jenkins slave running in container, what are alternatives or "safe" (in terms of security) implementations for <a href="https://hub.docker.com/_/docker/" rel="nofollow noreferrer">Docker in Docker</a>.</p>

<p>Architecture example:</p>

<ol>
<li>Jenkins master running as Docker container</li>
<li>Jenkins slave running as Docker container</li>
<li>Test task executed in Docker container</li>
</ol>

<p>Some known alternatives:</p>

<ul>
<li><a href="https://hub.docker.com/r/psharkey/jenkins-dood/" rel="nofollow noreferrer">DOOD (Docker-Outside-Of-Docker)</a></li>
<li><a href="https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin" rel="nofollow noreferrer">Jenkins Plugin</a> using Docker API</li>
</ul>

<p>Constraints clarification: the idea is to use Jenkins as an orchestrator and Docker for clean environment, the rest of architecture is a subject to change.</p>

CC BY-SA 3.0
2017-03-26T12:21:03.603Z
Thanks for the question, you have taught me about `Docker-in-docker` - for everyone else that is new to the topic then it would be worth reading [Jérôme Petazzoni's description of advantages and disadvantages of](https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/).
Richard Slater
CC BY-SA 3.0
2017-03-26T12:22:24.073Z
Can you perhaps explain what workloads you are (currently?) running using Docker-in-Docker?
Richard Slater
CC BY-SA 3.0
2017-03-26T12:31:21.350Z
What are the goals of avoiding Docker-in-Docker, security? avoid "Turtles all the way down"? Performance?
Richard Slater
CC BY-SA 3.0
2017-03-26T14:03:27.330Z
@RichardSlater Depends how workloads are defined (jobs/day, slaves/master, cpu,data/job) but the question is more general. All listed security, turtles, performance are legit candidates to be avoided, as well as the smell of "hackity hack" mentioned in "Jérôme Petazzoni's description of advantages and disadvantages of..."
rombob
CC BY-SA 3.0
2017-03-26T18:16:39.913Z
@RichardSlater Why not post your last comment as a new question (asking questions is free ...!). That might give rombob way more space to post an answer to it (instead of having to squeeze it in a comment like the one before my comment here.
Pierre.Vriens
CC BY-SA 3.0
2017-03-26T18:21:37.593Z
@Pierre.Vriens fair point
Richard Slater
CC BY-SA 3.0
2017-03-27T09:00:40.953Z
What are you up to change in your architecture ? Or are you up to change nothing at all ?
Tensibai
CC BY-SA 3.0
2017-03-27T11:38:53.237Z
@Tensibai everything is a subject to change but basic building blocks: Jenkins and Docker, the idea is not to use natively installed binaries on slave when testing different language stacks, hope it's clear
rombob
CC BY-SA 3.0
2017-03-27T12:03:11.127Z
Nope, it's still unclear if your architecture still has to rely on jenkins slaves within docker or not. Anyway, tricks for ruby/python/java with multiples versions on same hosts (or docker image FWIW) are well known, those for nodejs or Go are less "common" and less easy to set up. So I'm really unsure the way you're open with and those you don't. If the plan is to still have jenkins as orchestrator and Docker for clean environment there's place to answer, if the slaves have to be within a  docker environment, everything will be an ugly hack you can't really trust tests results.
Tensibai
CC BY-SA 3.0
2017-03-27T13:39:01.980Z
@Tensibai thank you for directing to clarification regarding the question, my point was to keep it more general to leave more room for creativity in answers, including things you mentioned. As for specific case, tricks are known and being used, the opportunity Docker gives is to have one way of implementation for all types of workloads, if possible, try focusing on making it stable and safe.
rombob
CC BY-SA 3.0
2017-03-27T13:47:39.933Z
Then I don't see how to answer this in a reasonable manner, I see to much possibles implementations :) Personally I don't think open ended answer are good for this Q/A site and they are unlikely to be of real help as not solving a real problem. My 2 cts.
Tensibai
CC BY-SA 3.0
2017-03-27T17:12:44.033Z
@Tensibai Thank you for feedback, clarification added to question.
rombob
CC BY-SA 3.0
2017-10-25T23:36:52.157Z
I followed this guide from running riot, the Jenkins Docker Plugin is a big part of the setup: https://engineering.riotgames.com/news/thinking-inside-container
Brian Ogden
<jenkins><docker><docker-in-docker>
What are alternatives for Docker in Docker (dind) usage for Jenkins slave running in container?
rombob
# What are alternatives for Docker in Docker (dind) usage for Jenkins slave running in container?

(Asked by: username_0 on 2017-03-26)

When using Jenkins slave running in container, what are alternatives or "safe" (in terms of security) implementations for [Docker in Docker](https://hub.docker.com/_/docker/).

Architecture example:

1. Jenkins master running as Docker container
2. Jenkins slave running as Docker container
3. Test task executed in Docker container

Some known alternatives:

* [DOOD (Docker-Outside-Of-Docker)](https://hub.docker.com/r/psharkey/jenkins-dood/)
* [Jenkins Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin) using Docker API

Constraints clarification: the idea is to use Jenkins as an orchestrator and Docker for clean environment, the rest of architecture is a subject to change.

**Tags:** jenkins, docker, docker-in-docker

> **Comments:**
> **username_1**: Thanks for the question, you have taught me about `Docker-in-docker` - for everyone else that is new to the topic then it would be worth reading [Jérôme Petazzoni's description of advantages and disadvantages of](https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/).  
> **username_1**: Can you perhaps explain what workloads you are (currently?) running using Docker-in-Docker?  
> **username_1**: What are the goals of avoiding Docker-in-Docker, security? avoid "Turtles all the way down"? Performance?  
> **username_0**: @RichardSlater Depends how workloads are defined (jobs/day, slaves/master, cpu,data/job) but the question is more general. All listed security, turtles, performance are legit candidates to be avoided, as well as the smell of "hackity hack" mentioned in "Jérôme Petazzoni's description of advantages and disadvantages of..."  
> **username_2**: @RichardSlater Why not post your last comment as a new question (asking questions is free ...!). That might give username_0 way more space to post an answer to it (instead of having to squeeze it in a comment like the one before my comment here.  
> **username_1**: @username_2 fair point  
> **username_3**: What are you up to change in your architecture ? Or are you up to change nothing at all ?  
> **username_0**: @username_3 everything is a subject to change but basic building blocks: Jenkins and Docker, the idea is not to use natively installed binaries on slave when testing different language stacks, hope it's clear  
> **username_3**: Nope, it's still unclear if your architecture still has to rely on jenkins slaves within docker or not. Anyway, tricks for ruby/python/java with multiples versions on same hosts (or docker image FWIW) are well known, those for nodejs or Go are less "common" and less easy to set up. So I'm really unsure the way you're open with and those you don't. If the plan is to still have jenkins as orchestrator and Docker for clean environment there's place to answer, if the slaves have to be within a  docker environment, everything will be an ugly hack you can't really trust tests results.  
> **username_0**: @username_3 thank you for directing to clarification regarding the question, my point was to keep it more general to leave more room for creativity in answers, including things you mentioned. As for specific case, tricks are known and being used, the opportunity Docker gives is to have one way of implementation for all types of workloads, if possible, try focusing on making it stable and safe.  
> **username_3**: Then I don't see how to answer this in a reasonable manner, I see to much possibles implementations :) Personally I don't think open ended answer are good for this Q/A site and they are unlikely to be of real help as not solving a real problem. My 2 cts.  
> **username_0**: @username_3 Thank you for feedback, clarification added to question.  
> **username_4**: I followed this guide from running riot, the Jenkins Docker Plugin is a big part of the setup: https://engineering.riotgames.com/news/thinking-inside-container  

---

## 1 answers

### Answer by username_3 on 2017-03-28. Score: 5 | Accepted answer

To avoid relying on `dind` (out of building new images from a dockerfile which should be ok) I'd look around [Jenkins's kubernetes](https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin) plugin.

It obviously needs to bring to life a kubernetes cluster but allow to have a one time jenkins agent to run the test in a clean isolated environment, and then tear it off. The maintenance costs of the kubernetes cluster should not be greater than maintaining your Jenkins slaves.

The bonus point is that you can version you slaves with specific environment and don't have to tweak around for multiples version of ruby/java/python and let the task choose the proper "environment" by specifying the agent image to use and have a ready to test environment without any tweak pre-test.

I'd head toward kurbenetes as container scheduler because it is relatively lightweight to configure and maintain.

> **Comments:**
> **username_0**: great approach, as an alternative mesos, swarm can be used, IMO swarm is a great candidate just because of relatively easy maintenance but can come with price of stability, too fresh technology  
> **username_3**: @username_0 indeed, and mesos is quite heavy to maintain and probably overkill for this use case, I was wondering if stating this comparison/point would make sense in this answer.  
> **username_0**: maybe comparison would be great candidate for a new question  
> **username_3**: @username_0 Usually they fade out of useful very quickly, specially with swarm under active development it would need an update nearly each week. So I would avoid it, even [a blog post](http://rancher.com/comparing-rancher-orchestration-engine-options/) isn't really clear on the question after a whole list or pro/cons  
> **username_5**: When using the Jenkins Kubernetes plugin how do you dynamically choose a container to build in. I use the Jenkins Kubernetes plugin, but I still use dind because I want to build inside containers. I have a slave container with dind in it, but there has to be a better way.  
> **username_6**: Also have a look at Kaniko to build docker images in Kubernetes without a docker daemon or DIND.  https://github.com/GoogleContainerTools/kaniko  

---

