Building a Docker Development Environment (Part 2)
A Quick Guide About Dockerfile
Introduction
Hello, I work as a system engineer in Tokyo and am now mainly developing web applications using Ruby and JavaScript.
I have been using Docker at my workplace for around 2 years now and almost all of my projects are developed using Docker these days. Docker technology has become so helpful that I believe it will be used for a long time.
In my previous article, I explained Docker Compose. For this article, I would like to continue the discussion and explain more about Dockerfile.
What is Dockerfile?
A Dockerfile is a text file into which you can write the commands you want to run when creating an image.
Generally, you could pull the original image from the Docker Hub and then create a new image based on that image, customized to fit your project and development style.
Merits of Dockerfile
First, let’s talk about creating a container without a Dockerfile.
Find and pull the source image of the container from the Docker Hub.
A container is then created from the pulled image.
The docker run command combines Docker Create and Docker Start into one command to create and run containers. Note that the -d option runs in the background (detached mode), and the -i and -t options leave it ready to accept commands.
Now you have successfully launched a Ruby container named my-container. If you are not particular about it, using the container you created is enough.
On the other hand, the advantage of using a Dockerfile is that you can write ALL the commands you want to execute in the file when you build the image. This allows you to pull images from DockerHub and customize them to fit your project and development style.
For example, when launching a Ruby container, you can use COPY or CMD in the Dockerfile to copy the Gemfile and Gemfile. lock into the container and run Bundle Install.
If you organize the Dockerfile well, you can also start the application by doing all the initial startup processes when the container is launched.
Dockerfile Commands
In this case, I prepared the following Dockerfile:
FROM
In the Dockerfile, we usually use FROM first. FROM sets up the base image to be used in subsequent instructions. When the Dockerfile is executed, it first looks for the image in the environment where it was executed. If the image is not found, it will look for the image in the Docker Hub and download it.
Subsequent instructions are executed sequentially for the image specified in FROM. The build stage can be named by adding “AS name” after FROM. You can use any name other than “name” here. By adding a name, the name can be referenced in subsequent like FROM and COPY, and multiple FROMs can be defined and managed in the Dockerfile.
COPY
Copy files and folders. Note that only files and directories in the directory where the Dockerfile is placed can be copied.
ADD
Adds files and folders. Unlike COPY, if the file is a compressed file, it would be automatically decompressed. In addition, by specifying a URL instead of a file name, a remote file can be downloaded and added.
WORKDIR
Specifies the directory where RUN, CMD, ENTRYPOINT, COPY, and ADD are executed. If the directory specified in WORKDIR does not exist, a new directory will be created.
RUN
The commands you specify will be executed at the time the image is built.
This is where you write the commands you want to run at the time of the image, such as installing packages, copying files, etc.
CMD
This differs from RUN, with CMD specified command executed when the container is started. The main purpose of a CMD is to specify the initial configuration when the container is run, and it can only be used once in a Dockerfile. If multiple CMDs exist, the last CMD will take effect.
ENTRYPOINT
Like CMD, this command is executed when the container is started. However, in the case of CMD, if a command is specified after the docker run, CMD will be overwritten and executed.
Like the example, if the above command is used to launch a container, the CMD in the Dockerfile will be overwritten and the ls command will be executed.
If ENTRYPOINT is used instead of CMD, the command specified in ENTRYPOINT will be executed without overwriting. In other words, the command specified by ENTRYPOINT is always executed.
If ENTRYPOINT and CMD are used together, a command that is a combination of both will be executed.
For example, if you put such a description in the Dockerfile, “ls -a” will be executed when the container is started. The CMD part can be overwritten, so you can change -a to another option and have it run, but you will probably never use it.
USER
Specifies the user who executes commands such as RUN and CMD. The command is automatically executed as the root user if USER is not specified.
LABEL
Add metadata to the image. Specifically, you can describe the name, version, and producer information.
ENV
Set environment variables. The set environment variables can be overwritten later.
Summary
Use the docker-compose.yml we prepared last time and the Dockerfile this time and run the following code:
Now we successfully built a Rails development environment.
About Us💡
In addition, we want to introduce a little more about GROWI, an open software developed by WESEEK, Inc.
GROWI is a wiki service with features-rich support for efficient information storage within the company. It also boasts high security and various authentication methods are available to simplify authentication management, including LDAP/OAuth/SAML.
GROWI originated in Japan and GROWI OSS is FREE for anyone to download and use in English.
For more information, go to GROWI.org to learn more about us. You can also follow our Facebook to see updates about our service.
