Docker is a platform for developers and sysadmins to develop, ship, and run applications. Ship the “Dockerized” app and dependencies anywhere – to QA, teammates, or the cloud – without breaking anything. It’s one of the most important purposes to use docker.
In Vernon Stinebaker‘s earlier post “Docker, mobile, and putting things in boxes“, he introduced the background of the Library system, the corresponding mobile applications (Andriod version and iOS version) and the need of dockerization. As one of the team members working in this ‘Library in a box’ project, I mainly focus on the part of “putting things in boxes”.
In this article, I am not going to introduce the detail steps of dockerization. Instead, I am going to introduce two “shipping” ways via using docker.
The target is to dockerize the application. By given the pressure from the project schedule, another team member and I decided that firstly we just used the interaction mode to install all the necessary software, Java 7, Liferay, and mysql to get the infrastructure set up. And then deployed the library application war file into the container. All of these steps were just same as an usual environment preparation and the application deployment. The only difference was that the installation and deployment wass done upon a docker container instead of a virtual machine. As highlighted in below command, the arguments “-t” and “-i” enable you to interact with the container.
Once this was done, we committed the container as a docker image. At the first two Sprints, we delivered the docker images to the PO (Vernon Stinebaker) using the docker save command.
$ docker save library/app > library_app.tar.gz
PO used the docker load command to load the image after got the library_app.tar.gz copied into his host machine.
$ docker load < library_app.tar.gz
When we delivered the image to the QA team and asked them to start the application from running a simple command, they were surprised. Usually to have the application running in the QA box, they have to collaborate with the DEV team together to do the installation and some configuration.
Except for using the save-load commands, Docker encourages people to push the image to the Docker Hub and the others can pull the image from the Docker Hub and run it. But we were very hesitating to use the push-pull commands because the docker image size is about 2.3 GB. After trying varies ways like removing the installation files from the container and clearing the cache, the images size was still around 1.4 GB. It is not that small to push to and pull from the Docker Hub, right? Especially by given the truth both PO and the QA team are all in the same intranet with the DEV team, the image copying just costed few minutes. But if we want to ship to a distributed team or user, using push-pull commands to ship via internet is still recommended. How long it takes will be very depending on your network performance.
So we started developing the Dockerfile. As long as your ‘recorded’ steps follow the Dockerfile format, docker will build the docker image from zero for you.
$ docker build -t library/app .
The Dockerfile was only 2.4 KB. And we should count in the library war file which was 22 MB. Even so, the overall ship size was only around 23 MB. So, use the Dockerfile to build image makes huge difference on the deliverable’s size. So, shall we always follow the Dockerfile approach to build and run application?
The answer was NO because the image building process still needs to download, install and configure varies of the software according to your build steps. For example, built the docker image of “the library in a box” from my home, it costed approximately 2.5 hours.
By now, we know that using docker there are two shipping ways:
- You can ship the container and the user can directly run the application.
- You can also just ship the Dockerfile and the user can build the container by himself and then run the application.
But so far, I don’t have a conclusion which way is better for shipping. From a developer’s perspective, I’d like to develop and maintain the Dockerfile because more or less we will leave some useless things in the container if we only use interactive mode to download, install and configure.
