5 ms·

> you don't understand Docker that well I wholeheartedly agree :) The path I'm currently taking is to spin up Concourse CI which uses containers, and start us

> you don't understand Docker that well I wholeheartedly agree :) The path I'm currently taking is to spin up Concourse CI which uses containers, and start using that to CI/CD my personal site. I'm likely gonna overkill and end up hosting my own image repository, but overall I think this'll teach me the necessary concepts of containers in a directly applicable way to my end goals. From there I can start to play with k8s itself, if I so desire. Where I tend to get hung up is things like entrypoints. My personal site is static, so the container to build it isn't a hosted service, it's just invoking Pandoc (with a bunch of dependencies installed as well). I think that makes Pandoc the 'entry point', that just seems strange since it isn't a persistent service, and I think that makes the lifetime of the container rather ephemeral. Which... likely is a valid usecase for docker containers, I've just only interacted with them e.g. on my Unraid box as persistent services.

ufmace 6y ago
I gather the actual site is a static files site, and Pandoc is the tool that translates whatever format you're writing them in to the final HTML. So then your site docker image would just contain a server, Nginx or something, and a directory of all of the files for your site, and the correct config for Nginx or whatever to serve them. The Dockerfile image build process would take care of building that. It's pretty standard for your single project Dockerfile to first assemble an image with a bunch of build tools, like this Pandoc and whatever other dependencies are needed, copy the source files into that image, run the commands to generate the final site, then assemble a second image with just Nginx and copy the output files from the first image onto that to become the final output image. That way, the whole build process is scripted and automated and doesn't require any of the tools on the local system (handy if you were doing stuff like onboarding new contributors), and the final image is small and secure because it only contains a web server and the final HTML pages and no build tools or source files.

ufmace 6y ago

I gather the actual site is a static files site, and Pandoc is the tool that translates whatever format you're writing them in to the final HTML. So then your site docker image would just contain a server, Nginx or something, and a directory of all of the files for your site, and the correct config for Nginx or whatever to serve them. The Dockerfile image build process would take care of building that. It's pretty standard for your single project Dockerfile to first assemble an image with a bunch of build tools, like this Pandoc and whatever other dependencies are needed, copy the source files into that image, run the commands to generate the final site, then assemble a second image with just Nginx and copy the output files from the first image onto that to become the final output image. That way, the whole build process is scripted and automated and doesn't require any of the tools on the local system (handy if you were doing stuff like onboarding new contributors), and the final image is small and secure because it only contains a web server and the final HTML pages and no build tools or source files.