Reputation: 13269
Some time ago I did an interview with a company and they mentioned that their apps are packaged with Docker. Also they said that when the modify the application they not only will commit the code but the entire image. So a release just consists in a push of the commit from git (?).
I didn't have a chance to ask for more details, so I am not sure what they meant...
Option 1:
They actually put a Dockerfile in the source tree somewhere and they commit that and then some script will just copy the compiled application in the right dir (we're talking about java).
Option 2:
They commit the whole image (?). I'm not familiar with the structure of Docker images, are they binary or just a big directory tree with the distribution files (plus config for the app, etc...).
Or something else... I don't know docker enough.
Obviously I don't want to put the sources in the images and committing an entire distribution in git seems a bit overkill to me...
Upvotes: 3
Views: 629
Reputation: 12090
I think its somewhere between Option 1 and 2:
When any of the developers in the team pushes a code, some sort of CI/CD tools like Jenkins might create a Docker container using a Base Docker image (may pull the docker image directly or create image using Dockefile) and does the java compilation on that container. At this point, if the image was built, the Dockerfile
responsible to create an image might do git pull
or ADD
or mounted using Volume
and then would compile the java project. Alternatively, if the base image is already there with basic environment setup, the java source code may have been added using volume or using another Dockerfile
referencing the base image and using ADD
or doing git pull
to create a new image and ultimately creating container, where the code is compiled. Also, separate data containers containing data may be needed for the test. Now the same container may be passed along other environments, say QA or Pre-prod for unit-testing and integration testing (totally depends on the design). If all the tests are passed, the CI/CD tool may commit the container to create a new image, tagging them for release. The same image (with that particular tag) is now used to deploy a container in production.
Now, as you mentioned, the Dockerfile may be committed somewhere in the source tree or may belong to completely different repo, just responsible for deployment.
Docker images may be tied to the build pipeline and tagged accordingly, so as to revert the changes when necessary.
There are many ways to integrate Docker in releases.
You may refer to these posts to further investigate how people are using Docker in production:
1. https://stackoverflow.com/a/18287169/2167517
2. Docker Container management in production environment
3. Creating a Docker UAT/Production image
I hope this helped you to some extent. This is a simple use case, I am sure people are actually using much elegant design with Docker in their production.
Upvotes: 1