ddanielr commented on code in PR #384:
URL: https://github.com/apache/accumulo-website/pull/384#discussion_r1176010699
##########
Dockerfile:
##########
@@ -0,0 +1,40 @@
+# This Dockerfile builds an ruby environment for jekyll that empowers
+# making updates to the accumulo website without requiring the dev
+# to maintain a local ruby development environment.
+
+FROM ruby:2.7.8-slim-bullseye as base
+
+RUN apt-get update && apt-get install -y --no-install-recommends \
+ build-essential \
+ git \
+ curl \
+ && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /site
+
+
+# Copy over the Gemfiles so that all build dependencies are installed
+# during build vs at runtime.
+
+COPY Gemfile /site/Gemfile
+COPY Gemfile.lock /site/Gemfile.lock
Review Comment:
> First, the name of the directory is "site", which is a bit confusing,
because later, the site is built in `_site`. Would that location be
`/site/_site/` then?
Yes!
So three directories exist
1. $PWD (root of the repository on the host)
2. $PWD/_site (location of rendered changes on the host)
3. /site (working directory of the container)
These locations are mounted at container runtime to allow the webdev and
webdev-validator containers to access the source and rendered content.
I completely agree that the `/site` directory name is a bit overused. So I'm
happy to take suggestions on a better name for the container side of things.
> Second, when is the rest of the website files copied over? Are those also
copied over to the same `/site` directory inside the container? How does that
work? Are they copied over to `/site` after the RUN commands but before the CMD
commands?
So everything that happens in the Dockerfile is part of the container build
stage.
This is completely separate from actually running the container.
The `RUN` commands specified in this file are just for local actions we want
to trigger as part of building a container.
CMD is the default command the container will execute when a `docker run`
command is executed.
The rest of the site is mounted as a read/write volume at runtime. The
contents of `accumulo-website/` are mounted at the container's `/site`
directory location for the webdev container.
Once the webdev container is running, and the source directory is mounted,
then the CMD statement finally executes and the rendered content is created on
the containers /site/_site directory, which maps to the host's $PWD/_site
directory.
This results in the following dir structure:
webdev's container's filesystem
/site
- contents of accumulo-website
- /_site
- Rendered html from jekyll
This ensures that no site files are embedded in a container and that the
source repository remains the only location for changes to occur.
Now, we want to mount the rendered content into the validator container.
However, the webdev-validator container needs to have a slightly modified
Gemfile.
To accomplish this, the run command only mounts $PWD/_site to /site/_site.
This sets up the following structure
webdev-validator's filesystem
/site
- Gemfile (modified by container)
- Gemfile.lock (modified by container)
- /_site
- Rendered html from jekyll
> And third, just to clarify, the RUN command is using the Gemfiles to
install the gems when the container image is first created and started (using
`docker run`) and then the CMD commands are run. For subsequent stopping
(`docker stop`) and restarting (`docker start`) , only the CMD commands are
executed on startup? Is this correct?
The RUN command is only triggered during a `docker build` command.
The container is never started during the `docker build` stage.
The CMD statement ONLY runs on a `docker run` or `docker start` command and
is never triggered during a `docker build` stage, only specified.
If it helps to think about it this way, CMD and ENTRYPOINT are like
environment variables I am setting in my Dockerfile. I'm specifying the future
behavior of my container when it runs. So, I can define those variables at any
point in my Dockerfile, their placement in the Dockerfile has no bearing on
what actions happen during container build.
Whereas RUN statements are actual, order dependent commands that are used to
trigger immediate actions in my container during the build stage to modify the
container in some way.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]