|
@@ -45,7 +45,7 @@ Gitea has more features and it actually was my first pick, but unfortunately I s
|
|
|
|
|
|
|
|
So instead I went with Gogs (the app it is a fork of) which has less features. However, still enough features.
|
|
So instead I went with Gogs (the app it is a fork of) which has less features. However, still enough features.
|
|
|
|
|
|
|
|
-For those of you following along though I will preface this with the fact that `any` repository server (Github, Gitlab, Bitbucket, Gitea, Gogs, etc etc) `should` be compatible. Theoretically.
|
|
|
|
|
|
|
+For those of you following along though I will preface this with the fact that `any` repository server (Github, GitLab, Bitbucket, Gitea, Gogs, etc. etc.) `should` be compatible. Theoretically.
|
|
|
|
|
|
|
|
The only feature that is needed from the repo is the ability to setup Webhooks for Push events with a Secret, which basically every git server nowadays supports.
|
|
The only feature that is needed from the repo is the ability to setup Webhooks for Push events with a Secret, which basically every git server nowadays supports.
|
|
|
|
|
|
|
@@ -53,15 +53,15 @@ The only feature that is needed from the repo is the ability to setup Webhooks f
|
|
|
|
|
|
|
|
This is an awesome docker image that was created by [Felix Wehnert (flashspys)](https://github.com/flashspys) that I made my own fork of, `docker-nginx-static-ha` which can be found [here](https://github.com/SteffenBlake/docker-nginx-static-ha)
|
|
This is an awesome docker image that was created by [Felix Wehnert (flashspys)](https://github.com/flashspys) that I made my own fork of, `docker-nginx-static-ha` which can be found [here](https://github.com/SteffenBlake/docker-nginx-static-ha)
|
|
|
|
|
|
|
|
-What particularily caught my eye and has proven excellent:
|
|
|
|
|
|
|
+What particularly caught my eye and has proven excellent:
|
|
|
|
|
|
|
|
### The image can only be used for static file serving but is less than 4 MB (roughly 1/10 the size of the official nginx image). The running container needs ~1 MB RAM.
|
|
### The image can only be used for static file serving but is less than 4 MB (roughly 1/10 the size of the official nginx image). The running container needs ~1 MB RAM.
|
|
|
|
|
|
|
|
-#### So whats the difference?
|
|
|
|
|
|
|
+#### So what's the difference?
|
|
|
|
|
|
|
|
Primarily how the files are cached. Specifically, `docker-nginx-static` simply just serves a mounted directory `directly`. This means once it is running, any changes you make to the directory will be reflected instantly.
|
|
Primarily how the files are cached. Specifically, `docker-nginx-static` simply just serves a mounted directory `directly`. This means once it is running, any changes you make to the directory will be reflected instantly.
|
|
|
|
|
|
|
|
-I actually didnt want this, because when I run a build of the blog I dont want pages to be breaking if someone accesses the website mid-build.
|
|
|
|
|
|
|
+I actually didn't want this, because when I run a build of the blog I don't want pages to be breaking if someone accesses the website mid-build.
|
|
|
|
|
|
|
|
So I made a minor tweak and created `docker-nginx-static-ha` (the ha is for High availability).
|
|
So I made a minor tweak and created `docker-nginx-static-ha` (the ha is for High availability).
|
|
|
|
|
|
|
@@ -75,9 +75,9 @@ So now you can modify the original directory to your hearts content without maki
|
|
|
|
|
|
|
|
Simple, you just turn it off and back on again. When it spins back up again it will re-cache all the files
|
|
Simple, you just turn it off and back on again. When it spins back up again it will re-cache all the files
|
|
|
|
|
|
|
|
-### Wait so... wouldnt that take the website down...?
|
|
|
|
|
|
|
+### Wait so... wouldn't that take the website down...?
|
|
|
|
|
|
|
|
-If you only have a single docker container running, yes. But thats where the `HA` part comes in. We will dig into it farther below but what you would ideally want to have happen is use a docker management system like Swarm or Kubernetes which has `multiple` containers running in parallel, a load balancer to direct traffic across them, and then when you roll out an update you take the containers down `one at a time` so you always have some running, thus the website `smoothly` transitions over without any downtime or breaking issues.
|
|
|
|
|
|
|
+If you only have a single docker container running, yes. But that's where the `HA` part comes in. We will dig into it farther below but what you would ideally want to have happen is use a docker management system like Swarm or Kubernetes which has `multiple` containers running in parallel, a load balancer to direct traffic across them, and then when you roll out an update you take the containers down `one at a time` so you always have some running, thus the website `smoothly` transitions over without any downtime or breaking issues.
|
|
|
|
|
|
|
|
## Blog compiler: Hugo
|
|
## Blog compiler: Hugo
|
|
|
|
|
|
|
@@ -91,7 +91,7 @@ Being able to also manage what theme I use simply by what git repo I set as a su
|
|
|
|
|
|
|
|
This is another extremely lightweight and brutally simple application built by [Adnan Hajdarević](https://github.com/adnanh), once again built on go and thus compatible with basically everything.
|
|
This is another extremely lightweight and brutally simple application built by [Adnan Hajdarević](https://github.com/adnanh), once again built on go and thus compatible with basically everything.
|
|
|
|
|
|
|
|
-It simply lets me write a "listener" for a webhook event and then fires off a bash script on trigger. I couldn't really ask for much else. Well. Actually there is one thing I could ask for, and that is support for refering to env variables inside of the webhook triggers and whatnot. Unfortunately I had to use a custom solution with `sed` to manually (oof) replace 'variables' in my webhook json, since I wanted those to be a configurable value.
|
|
|
|
|
|
|
+It simply lets me write a "listener" for a webhook event and then fires off a bash script on trigger. I couldn't really ask for much else. Well. Actually there is one thing I could ask for, and that is support for referring to env variables inside of the webhook triggers and whatnot. Unfortunately I had to use a custom solution with `sed` to manually (oof) replace 'variables' in my webhook json, since I wanted those to be a configurable value.
|
|
|
|
|
|
|
|
## Putting them together: webhook-hugo
|
|
## Putting them together: webhook-hugo
|
|
|
|
|
|
|
@@ -99,6 +99,6 @@ The next step was to combine webhook + hugo together into a single docker image,
|
|
|
|
|
|
|
|
[docker-webhook-hugo](https://github.com/SteffenBlake/docker-webhook-hugo) now exists!
|
|
[docker-webhook-hugo](https://github.com/SteffenBlake/docker-webhook-hugo) now exists!
|
|
|
|
|
|
|
|
-I detailed how to use it on its github page but I will dig into how to actually consume and use these tools on the next blog post, so look forward to that!
|
|
|
|
|
|
|
+I detailed how to use it on its Github page but I will dig into how to actually consume and use these tools on the next blog post, so look forward to that!
|
|
|
|
|
|
|
|
### {{< timelink n="2" after="2021-09-30" desc="Building a CI/CD Markdown Blog" href="/post/hugo/part-2-building-a-blog">}}
|
|
### {{< timelink n="2" after="2021-09-30" desc="Building a CI/CD Markdown Blog" href="/post/hugo/part-2-building-a-blog">}}
|