ctubbsii commented on code in PR #384: URL: https://github.com/apache/accumulo-website/pull/384#discussion_r1177332360
########## 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: > always run in a docker image I think part of my earlier confusion comes from your loose interchange of "image" and "container". I think I know enough to parse those out without trouble now. But, for clarity, I don't think it makes sense to say anything is running in an image. I think if we were to be precise, then things run inside containers (as opposed to images), and containers are launched/created from an image. I think of images as just snapshots of a particular container's (stopped) state, from which another container can be launched. The build stage, therefore, just seems to be a starting up a container with one base image as input, and a new (possibly incremental CoW) image as output. > The final image layer generated is the last "layer" of changes that comprise the image and is tagged as the final image. > > So it's different from building a virtual machine image where you only get an single output of a image based on all the commands run within the image at build. > > This allows Docker to share image layers between containers and save space. Yeah, that just seems to be a basic copy-on-write incremental filesystem implementation. Not fundamentally different than qcow files and libvirtd... just a lot of easier-to-use tooling around those same fundamental concepts (and the primary fact that isolation comes from OS containerization features instead of virtualization for machine emulation). You still have to have a running container in which the build is executed. The docker documentation at https://docs.docker.com/engine/reference/commandline/build/ specifically refers to "the containers used in the build" and there are flags you can put on the command line to customize the cgroups for this running build container. So, there is actually a container running in the build stage, according to the docs... just not the same container you make later from the image that is the output of the build stage. > The github action only referenced publishing the contents of `_site` so I don't think the possible use of `/tmp` matters since it was never published before. Yeah, it shouldn't matter for anything we're doing... I'm just not sure how Docker might handle that... whether it would preserve those out-of-tree temporary file states or not. > So WORKDIR sets the PWD for any following RUN, COPY, ENTRYPOINT, and CMD commands in the Dockerfile. This is what I was noticing. Specifically, we're relying on it being the same for RUN and CMD, even though those run at completely separate phases. I was thinking that we might want to be in one directory for building the image, and another directory when we run the container. Not sure if there's a way to control that with that much granularity. Can always `(cd /somewhere else && dosomething)`, I suppose. > The project does support [adjusting for a baseurl](https://github.com/gjtorikian/html-proofer#adjusting-for-a-baseurl) :+1: -- 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]
