Let's start by agreeing that we want to adhere to typical Docker/DevOps principles. Therefore, we want to keep tasks isolated, configurations versions controlled, and overall customization to a minimum.
The Landscape:
- Jenkins is being used as the CI/CD tool on your cloud instance of choice.
The Plan:
- Create separate instances for test/staging/prod, each with Docker installed
- Spin up Jenkins slave containers on each instance, which are controlled by Jenkins master
- When a commit is sent to 'test' branch, Jenkins master sends task to 'Test' slave which ultimately spins up version of application
- Similarly, after tests are successfully run and code is pushed to staging or prod branches, Jenkins will have branch-respective slave build application.
The Question(s):
- What is wrong with this approach?
- What can be improved by this approach?
There are a few questions you should ask yourself when taking on this approach, a lot of those are covered in this blogpost.
The final paragraph suggests exposing the docker socket to the CI container, allowing you to build images on the host machine, instead of inside the CI container, saving you from a lot of pains that come from running Docker in Docker.
Other questions you should probably ask are what would be the orchestration service used for controlling the master and slave containers. I had a great time following this blog post by Stelligent to quickly create all I needed on AWS ECS using a Cloudformation stack, but other solutions are obviously an option.
So all in all, I don't see anything wrong with your approach, as long as you exercise caution and follow best practices. Good luck.