{"id":60729,"date":"2024-03-14T13:44:07","date_gmt":"2024-03-14T08:14:07","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=60729"},"modified":"2024-03-19T13:57:23","modified_gmt":"2024-03-19T08:27:23","slug":"running-docker-inside-docker-container-using-custom-docker-image","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/running-docker-inside-docker-container-using-custom-docker-image\/","title":{"rendered":"Running Docker Inside Docker Container using Custom Docker Image"},"content":{"rendered":"

Introduction and Scenario<\/b><\/h2>\n

There are various use cases for running Docker inside a host Docker container, which we will mention<\/span>\u00a0later on, but one of the use cases that often comes in handy is <\/span>when we run a Docker <\/b>container as a Jenkins agent. <\/b>Suppose we want to build and push our application image to any Docker registry, say ECR, and <\/span>then want to deploy the image in any EKS, ECS, etc cluster via Jenkins or any other CI\/CD tool like <\/span>Buildkite or GoCD, etc, then we can use this approach i.e., we can run Docker as an agent and <\/span>then inside that Docker agent we can run Docker commands to build and push the images.<\/span><\/p>\n

Prerequisites<\/b><\/h2>\n
    \n
  • Docker should be pre-installed on the host machine<\/span><\/li>\n<\/ul>\n

    Use Cases<\/b><\/h2>\n

    To run a Docker container inside another Docker container.<\/span><\/p>\n

    Some of the use cases for this are:<\/span><\/p>\n

      \n
    • One potential use case for docker in docker is for the CI pipeline, where we need to build and push docker images to a container registry after a successful code build.<\/span><\/li>\n
    • Building Docker images with a VM is straightforward. But, when we use Docker containers as Jenkins agents<\/span> for our CI\/CD pipelines, docker in docker is a must-have functionality.<\/span><\/li>\n
    • For Sandboxed environments:<\/span>\n
        \n
      • Testing Environments<\/b>: In CI\/CD pipelines, developers often need to run tests in an environment that closely mimics the production setup. By running Docker containers within another Docker container, we can create a sandboxed environment where we can quickly spin up test environments, run tests, and tear them down without affecting the host system.<\/span><\/li>\n
      • Isolation<\/b>: Docker containers provide a level of isolation, but running them inside another Docker container adds an extra layer of isolation. This can be useful for running untrusted or potentially malicious code in a controlled environment without risking the host system.<\/span><\/li>\n<\/ul>\n<\/li>\n
      • This is for experimental purposes on our local development workstation.<\/span><\/li>\n<\/ul>\n

        How doest this work?<\/b><\/h2>\n

        One of the features of Docker is the new \u201cprivileged\u201d mode for containers. It allows us to run some containers with almost all the capabilities of their host machine regarding kernel features and host device access. <\/span>Also, we can now run Docker within Docker itself. Here\u2019s how:<\/span><\/p>\n

        \"\"<\/p>\n

        Solution<\/b><\/h2>\n
          \n
        • First, we need a Dockerfile (with all the necessary configurations that supports running Docker inside Docker)<\/span>
          \n<\/span><\/li>\n<\/ul>\n
          FROM ubuntu:latest<\/span>\r\n\r\n# Updating the Container and Installing Dependencies<\/span>\r\n\r\nRUN apt update && apt install apt-transport-https ca-certificates curl lxc iptables -y<\/span>\r\n\r\n# Installing Docker<\/span>\r\n\r\nRUN curl -sSL https:\/\/get.docker.com\/ | sh<\/span>\r\n\r\n# Installing Wrapper Script<\/span>\r\n\r\nADD .\/script.sh \/usr\/local\/bin\/script.sh<\/span>\r\n\r\nRUN chmod +x \/usr\/local\/bin\/script.sh<\/span>\r\n\r\n# Define Volume for Container (Secondary Container)<\/span>\r\n\r\nVOLUME \/var\/lib\/docker<\/span>\r\n\r\nCMD [\"script.sh\"]<\/span><\/pre>\n
            \n
          • The above Dockerfile is doing the following:<\/span>\n
              \n
            • It installs a few packages like <\/span>lxc<\/b> and <\/span>iptables<\/b> (because Docker needs them), and <\/span>ca-certificates<\/b> (because when communicating with the Docker index and registry, Docker needs to validate their SSL certificates).<\/span><\/li>\n
            • Also <\/span>\/var\/lib\/docker<\/b> should be a volume because the filesystem of a container is an AUFS mount point composed of multiple branches, and those branches have to be \u201cnormal\u201d filesystems (i.e., not AUFS mount points). We can say that <\/span>\/var\/lib\/docker<\/span> is a place where Docker stores its containers, and it can not be an AUFS filesystem.\u00a0<\/span><\/li>\n<\/ul>\n<\/li>\n
            • Here is the wrapper script that we are running while creating the above Docker image:<\/span><\/li>\n<\/ul>\n
              #!\/bin\/bash\r\n\r\n# Ensure that all nodes in \/dev\/mapper correspond to mapped devices\r\n\r\ndmsetup mknodes\r\n\r\n# Defining CGROUP for our child containers\r\n\r\nCGROUP=\/sys\/fs\/cgroup\r\n\r\n: {LOG:=stdio}\r\n\r\n[ -d $CGROUP ] || mkdir $CGROUP\r\n\r\n# Mounting CGROOUP\r\n\r\nmountpoint -q $CGROUP || mount -n -t tmpfs -o uid=0,gid=0,mode=0755 cgroup $CGROUP || {\r\n\r\necho \"Can not make a tmpfs mount\"\r\n\r\nexit 1\r\n\r\n}\r\n\r\n# Checking if CGROUP is mounted successfully or not\r\n\r\nif [ -d \/sys\/kernel\/security ] && ! mountpoint -q \/sys\/kernel\/security\r\n\r\nthen\r\n\r\n\u00a0\u00a0\u00a0\u00a0mount -t securityfs none \/sys\/kernel\/security || {\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0echo \"Could not mount \/sys\/kernel\/security.\"\r\n\r\n\u00a0\u00a0\u00a0\u00a0}\r\n\r\nfi\r\n\r\n# Removing the docker.pid file\r\n\r\nrm -rf \/var\/run\/docker.pid\r\n\r\n# If custom port is mentioned for our child containers\r\n\r\nif [ \"$PORT\" ]\r\n\r\nthen\r\n\r\nexec dockerd -H 0.0.0.0:$PORT -H unix:\/\/\/var\/run\/docker.sock \\\r\n\r\n$DOCKER_DAEMON_ARGS\r\n\r\nelse\r\n\r\nif [ \"$LOG\" == \"file\" ]\r\n\r\nthen\r\n\r\ndockerd $DOCKER_DAEMON_ARGS &>\/var\/log\/docker.log &\r\n\r\nelse\r\n\r\ndockerd $DOCKER_DAEMON_ARGS &\r\n\r\nfi\r\n\r\n(( timeout = 60 + SECONDS ))\r\n\r\n[[ $1 ]] && exec \"$@\"\r\n\r\nexec bash --login\r\n\r\nfi<\/pre>\n
                \n
              • The above script does the following:<\/span>\n
                  \n
                • It ensures that the cgroup pseudo-filesystems are properly mounted because Docker needs them.<\/span><\/li>\n
                • It checks if you specified a <\/span>PORT<\/b> environment variable through the <\/span>-e PORT<\/b> command-line option. The Docker daemon starts in the foreground and listens to API requests on the specified TCP port if provided. It will start Docker in the background and give you an interactive shell if not specified.<\/span>
                  \n<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
                    \n
                  • Now, just build the Docker image:<\/span><\/li>\n<\/ul>\n
                    docker build -t docker:v1<\/pre>\n
                    \"\"<\/p>\n
                      \n
                    • Now, run the container with privileged mode:<\/span><\/li>\n<\/ul>\n
                      docker run -itd --privileged docker:v1<\/pre>\n
                      \"\"<\/p>\n
                        \n
                      • Now, you can access the docker inside the above container. First, go inside the above container, then run the docker commands:<\/span><\/li>\n<\/ul>\n
                        docker exec -it <container_name> bash<\/pre>\n
                        \"\"<\/p>\n
                        Conclusion<\/b><\/h2>\n
                        Running Docker containers inside another Docker container offers significant benefits, especially in scenarios where Docker containers serve as Jenkins agents for building and deploying images.<\/span><\/p>\n
                        Usefulness for Jenkins Agents:<\/b><\/p>\n
                          \n
                        • Build Isolation<\/b>: Docker-in-Docker allows Jenkins to create isolated build environments for each job or pipeline, ensuring that dependencies or changes in one build do not affect others.<\/span><\/li>\n
                        • Environment Consistency<\/b>: By encapsulating build environments within Docker containers, Jenkins ensures consistent build environments across different machines and eliminates “works on my machine” issues.<\/span><\/li>\n
                        • Scalability<\/b>: Jenkins can dynamically spin up multiple Docker containers to handle concurrent builds or stages, enabling scalability and efficient resource utilization.<\/span><\/li>\n
                        • Resource Efficiency<\/b>: Docker containers offer lightweight virtualization, allowing Jenkins to run multiple build agents on a single host machine without significant overhead.<\/span><\/li>\n<\/ul>\n
                          Utilizing Docker-in-Docker for Jenkins agents enhances build isolation, environment consistency, scalability, and resource efficiency. While it offers significant advantages, carefully considering performance, security, and management complexities is necessary to ensure smooth operation and mitigate potential risks. With proper configuration and monitoring, Docker-in-Docker enables Jenkins to efficiently build and deploy Docker images in a controlled and reproducible manner.<\/span><\/p>\n
                          <\/div>","protected":false},"excerpt":{"rendered":"
                          Introduction and Scenario There are various use cases for running Docker inside a host Docker container, which we will mention\u00a0later on, but one of the use cases that often comes in handy is when we run a Docker container as a Jenkins agent. Suppose we want to build and push our application image to any […]<\/p>\n","protected":false},"author":1644,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":47},"categories":[2348],"tags":[5184,1883],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/60729"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1644"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=60729"}],"version-history":[{"count":6,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/60729\/revisions"}],"predecessor-version":[{"id":60865,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/60729\/revisions\/60865"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=60729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=60729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=60729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}