Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-28T11:49:25.173Z
Answers: 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
Answers: rombob
Answers: CC BY-SA 3.0
Answers: 2017-03-28T11:50:49.017Z
Answers: @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.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-28T11:53:57.487Z
Answers: maybe comparison would be great candidate for a new question
Answers: rombob
Answers: CC BY-SA 3.0
Answers: 2017-03-28T11:58:17.097Z
Answers: @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
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-03-12T11:18:32.977Z
Answers: 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.
Answers: David West
Answers: CC BY-SA 4.0
Answers: 2019-05-21T00:05:50.383Z
Answers: Also have a look at Kaniko to build docker images in Kubernetes without a docker daemon or DIND.
  
  https://github.com/GoogleContainerTools/kaniko
Answers: casey vega
Answers: CC BY-SA 3.0
Answers: 2017-03-28T11:44:34.640Z
Answers: 2017-03-28T15:12:11.807Z
Answers: 2017-03-28T15:12:11.807Z
Answers: Tensibai
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-26T12:21:03.603Z
Comments: 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/).
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-26T12:22:24.073Z
Comments: Can you perhaps explain what workloads you are (currently?) running using Docker-in-Docker?
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-26T12:31:21.350Z
Comments: What are the goals of avoiding Docker-in-Docker, security? avoid "Turtles all the way down"? Performance?
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-26T14:03:27.330Z
Comments: @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..."
Comments: rombob
Comments: CC BY-SA 3.0
Comments: 2017-03-26T18:16:39.913Z
Comments: @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.
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-26T18:21:37.593Z
Comments: @Pierre.Vriens fair point
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-27T09:00:40.953Z
Comments: What are you up to change in your architecture ? Or are you up to change nothing at all ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T11:38:53.237Z
Comments: @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
Comments: rombob
Comments: CC BY-SA 3.0
Comments: 2017-03-27T12:03:11.127Z
Comments: 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.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T13:39:01.980Z
Comments: @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.
Comments: rombob
Comments: CC BY-SA 3.0
Comments: 2017-03-27T13:47:39.933Z
Comments: 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.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T17:12:44.033Z
Comments: @Tensibai Thank you for feedback, clarification added to question.
Comments: rombob
Comments: CC BY-SA 3.0
Comments: 2017-10-25T23:36:52.157Z
Comments: 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
Comments: Brian Ogden
Tags: <jenkins><docker><docker-in-docker>
Title: What are alternatives for Docker in Docker (dind) usage for Jenkins slave running in container?
UserDisplayName: rombob
ThreadText: # 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**: @username_1 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**: @username_1 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  
  
  ---
  
  