FROMdirective below. The
LABELdirective specify meta data such as the maintainer and version of the Dockerfile:
USERdirective specifies the user inside the container that should perform the installation steps ("root"). The
RUNdirective specifies the commands to run inside the container to install the software. Your Dockerfile file should include the
apt-get updatecommand, followed by
apt-get install -yand a listing of the Ubuntu packages the application requires.The starting point for the image is a minimal Ubuntu installation, so assume that a given package is absent unless you explicitly install it:
RUNcommand above links several commands together using
\to break this sequence of commands into multiple lines for readability. We're linking several commands like this to slightly minimize the size of the resulting Docker image file. This is also the reason why we include the
rmcommand to get rid of the package listing.
RUNdirective sets up the non-root user creatively named "nonroot", so that commands and applications that don't require root provileges have a more restricted environment within which to run:
bundle installcommand, according the JSDetox installation instructions. These steps need to run as "root" to have the ability to copy the application's files into protected locations:
-lparameter and specifies the $HOSTNAME varilable. This environment variable is automatically defined to match the hostname that Docker will assign when this container runs, which will allow JSDetox to listen on the network interface accessible from our underlying host.
--rmparameter directs Docker to automatically remove the container once it finishes running. This gets rid of any changes the application may have made to its local environment when it ran, but does not remove the cached image file that represents the app on your system. The
-itparameter requests that Docker open an interactive session to the container so you can interact with it.
--rmparameter, its contents will disappear after it stops running. When building the image, anticipate the user's need to communicate with the app inside the container over the network or to pass files in and out of the container.
-l $HOSTNAMEparameter. This directed the application to listen on the network interface that could be accessed from outside the container.
-pparameter to specify that a specific port within the container should be accessible from outside the container. For example, to access JSDetox’ port 3000, the user needs to specify
-p 3000:3000. This maps the container’s port 3000 to the underlying host’s port 3000, allowing the user to communicate with JSDetox by connecting to http://localhost:3000 using a web browser.
-vparameter to share a directory between the underlying host and the container.
-v ~/files:/home/nonroot/fileswhen running the application’s image:
bash) as the user "nonroot". To ensure that the non-root user has access to the underlying hosts ~/files directory, the user of the app will need to make that directory world-accessible (i.e.,
chmod a+xwr ~/files) before launching the container.