UTILIZING THE PORTABILITY OF DOCKER TO DESIGN A PORTABLE AND SCALABLE CONTINUOUS INTEGRATION STACK

摘要

With the release of Docker as an open source project in March of 2013, the project has gained substantial pull in the world of systems administration, and especially in software development. The removal of the hypervisor layer, as well as the reduction of unnecessary dependencies in Docker based virtual machines - commonly called images - allows for extremely reduced storage footprints and effectively (as explained on the project's website) allows "'dockerized1 projects to be completely portable"("What is Docker?"). This portability makes for a powerful tool when designing continuous integration stacks. When designing a continuous integration system, it is important to consider several important factors, such as the kinds of scenarios the system needs to handle, what sorts of assumptions about the environments need to be made, and how configurable a system needs to be in order to handle unforeseen edge cases on the fly. A Docker based system could, in theory, help in solving these issues if used properly. Instead of moving source code between test and production environments, you could instead transport the entire environment to the production location through the use of Docker images. In addition, because the "production code" is tied to a "production environment" which is encapsulated in a Docker image, it becomes unnecessary to make assumptions about the states of production deployment environments, and making tweaks to the environment is a simple Due to the fact that Docker images are sandboxed virtual machines, and because Docker has a single inheritance based hierarchy2 it is possible to run a Docker image inside another Docker image. When we examine the rather traditional model for continuous integration servers, wherein there is a service that acts as a master or dispatcher - providing tasks to an n-series group of slave/ worker instances tasked with running build tasks and tests, we can see that both the master and the slaves could potentially benefit from the portability and also the transience of docker images. Taking queue from Martin Fowler's article on designing phoenix like servers3 to avoid what he calls configuration drift4. By implementing this mannerism, we can create continuous integration environments with Docker that are portable and scalable. The portability coming from the nature of Docker images, and the scalability by spawning up several instanstances of a docker image5 containing an implementation of a worker. Thusly, we have a pattern for transporting and scaling the relatively complex systems and processes that make up a build server. From here the next step would be to design a pattern for recursively inheriting Docker containers as well as defining states that individual images should provide such that this pattern would function as intended.