Multi-stage Builds
Docker Images should be flexible, not bulky. But, for example, java application needs :
- Operating System
- Java installed
- IDE (Intellij IDEA, Eclipse, Netbeans etc)
- Libraries
- WAR (Jar) executable file
That is where Multi-stage Builds come into the limelight. In Docker world, Multi-stage Build is a way to keep image size as small as possible. Common stages are :
- Prepare the code
- Run an application
See example below :
#
# Build stage
#
FROM maven:3.5-jdk-8 AS build
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
#
# Package stage
#
FROM openjdk:8-jdk-alpine
COPY --from=build /usr/src/app/target/SpringBootExample-1.0-SNAPSHOT.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]–from=<name of from to pick up contents> is a parameter of COPY command that is used only in Multi-stage Build scenarios. Output of the first stage is used as an input for the second. Here is more information about Multi-stage Builds in a DockerFile.
Docker Volumes
Imagine the scenario when there are, let’s say, three environments in the company : QA, Dev and Prod. And the same image is used to create containers in different environments. And different data is to be provided to the environment during runtime. Docker Volumes solve this task. Docker Volumes are based on mapping concept. Volume mapping can not be applied to already created containers, only when creating.
docker volume create <volume name> – command used to create docker volume
docker volume ls – command used to display all existing docker volumes
docker inspect <volume name> – command used to get an information about given docker volume
See an example of docker inspect <volume name> command output :
Mountpoint is where the Docker Volume content is stored (or where the Docker Volume has been created). Every Docker Volume is created inside /var/lib/docker/volumes directory. So Docker Volume path is always confined to a host machine.
docker run -d -P -v vol1:/app tomcat – example of command mapping Docker Volume to a container
The above command defines mapping /app folder inside the container onto Mountpoint of Docker Volume
Bind Mounts is another concept of mapping data to Docker Container. This concept lets defining the directory (Mountpoint) explicitly, unlike when using Docker Volumes concept
docker run -d -P -v /tmp/dev:/usr/share/nginx/html nginx – example of command mapping Bind Mount to a container
Docker Volumes is a better approach, because they are managed by a Docker. Docker Volumes are more safe, easier to backup and manage. Bind Mounts are more useful when there is a predefined location to map data from.
docker volume rm <volume name> – command used to delete Docker Volume
More about Docker Volumes – here
Multi Container Deployment
Multi Container Deployment is a concept of using more than one image to run or work inside a container. Multi Container Deployment is implemented by Docker Compose. Docker Compose is using yaml scripts. Watch this video for better understanding the basics of yaml.
