4 ms·

I don't really know anything about Kubernetes either. I've been using Ansible myself for my projects, though they're all single servers. I get the idea that Kub

by ufmace 6y ago

I don't really know anything about Kubernetes either. I've been using Ansible myself for my projects, though they're all single servers. I get the idea that Kubernetes uses Docker heavily, and that you don't understand Docker that well. I'd suggest, if you care to stick to getting into that, learning Docker first. I have been using Docker for work for a while, though I still don't feel much desire to use it for any personal projects. It seems straightforward enough - basic idea is that each Docker image runs one and only one process, and has it's own directory tree. So if you want to run a Python or Ruby webapp, all of the app files plus the interpreter and all required debs/packages/gems live in that Docker image, and you don't need to have anything else special on your host. A Dockerfile is then a sort of script that holds all of the instructions for setting up an environment your application can run in from scratch. Of course that means if you want to run a database or a cache server or something, then you'll need to run several Docker images and coordinate communications between them and launching and scaling. I gather that's where Kubernetes and Docker Swarm and other such things come in.

tenacious_tuna 6y ago
> 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.

by ufmace 6y ago

tenacious_tuna 6y ago

> 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.