Infra/automated deployment

[ironicbadger]

Laying the groundwork for automated production deployments. Comments on methodology welcomed.

The Hugo project does not recommend using the hugo server command in production stating that nginx or caddy is their preferred option for these types of deployments. Therefore the Dockerfile was updated to a multi-stage build dropping the usage of the less secure hugo server -D command.

The website, once built in /site/public in the build stage, is copied in the nginx container and then docker-compose is used on the production VPS instance to auto detect changes and restart the container only if necessary.

Multi-stage builds mean that the build happens in a separate container (more secure) and the site remains live for as long as possible. Down the road this will also make automatic PR smoke testing more modular and easier to perform.

[elreydetoda]

I know you're probably still working on this, but I saw it in my notifications that you'd created this and was excited to take a peek 😁

Just a small suggestion, question, and wanted to mention:

• we probably should include a .Dockerignore file at minimum for the .git/ directory

Thank you for doing this 🥳 🚀

[ironicbadger]

We already have a .dockerignore file here which I thought was adequate.

Thanks for your comments I committed those changes.

[ironicbadger]

Need to merge in order to test action (you can't test these in isolation on a branch sadly).

[elreydetoda]

We already have a .dockerignore file here which I thought was adequate.

Lol, my bad it was later at night than I thought 😅

The Hugo project does not recommend using the hugo server command in production stating that nginx or caddy is their preferred option for these types of deployments.

Ya, @ironicbadger that's absolutely true (for production), but the hugo serve command is vital for development workloads. It does hot-reloading (meaning you don't have to restart the container for every change and it'll automatically build only the modified CSS/HTML/pages) and that is an extremely important step for quickly iterating on a problem. Currently the solution you merged will require the container to be rebuilt on every change.

Also, since there are no more options for the makefile, because we're forcing everyone to use docker for development (from #249) which is fine but means we need to account for development as well, then we either need another Dockerfile (i.e. Dockerfile.dev) which the makefile builds for the dev step or another solution which allows them to use the hugo serve command.

Besides the aforementioned comment I love this PR 😁🥳🚀

[elreydetoda]

I made a PR to what I'd mentioned above. Something I did on that Dockerfile.dev that we might want to consider doing on the regular Dockerfile, is I declared an ARG variable which can be passed read during build time.

So, we could keep the hugo version defined in the Makefile and it could be passed to both the production container and dev container to keep things in sync and to ensure we're on the same version for both.