final edit: new-website

This commit is contained in:
Drew Bowering 2025-06-10 09:41:15 -06:00
parent bbb21b34dd
commit 4918cef5e6
Signed by: drew
GPG Key ID: DC9462335BDDAC6B

View File

@ -1,6 +1,6 @@
--- ---
title: "New Website" title: "New Website"
date: "2025-05-16T13:16:00-06:00" date: "2025-06-10T08:00:00-06:00"
description: "There's finally a new website at d-b.ca." description: "There's finally a new website at d-b.ca."
summary: "I've published my personal website. A brief history of some past endeavours, and some details on the technology behind the new site." summary: "I've published my personal website. A brief history of some past endeavours, and some details on the technology behind the new site."
--- ---
@ -16,23 +16,30 @@ a culmination of the platform I've developed to host it.
My first personal website was developed while I was a student at the My first personal website was developed while I was a student at the
[University of Alberta](https://ualberta.ca), near the end of the previous [University of Alberta](https://ualberta.ca), near the end of the previous
century. The web itself was still quite young, but the university provided century. The web was still in its early stages, but the university provided
students with the means to publish web content. It was mostly a novelty at the students with the means to publish web content. It was mostly a novelty at the
time and didn't last beyond my time at school, but it sparked my interest in time and didn't last beyond my time at school, but it sparked my interest in
Internet technologies and their applications. Internet technologies and their applications.
That early site included one interesting feature. I developed a mechanism to That early site included one interesting feature. I developed a mechanism to
automatically update a page every time I logged into one of the school's automatically update a page every time I logged into one of the school's
computers, so my friends could find me if they wanted to. computers, so my friends could find me if they wanted to. The only way at the
time that was available for generating dynamic content in a website was
[CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface), and the
university did not allow student sites to use it. So, I wrote some shell
scripts that were called as part of my login and logout scripts that would
generate the static HTML file and write it to my web content directory. It
needed to handle cases like multiple logins, and the logout script didn't
always get triggered, so I'd have to keep an eye on it for stale entries.
### Self-Hosting ### Self-Hosting
I've always been an avid self-hoster. It began when I was working at a local I've always been an avid self-hoster. It began when I was working at a local
Internet service provider. I was able to get a special deal on a Internet service provider. I was able to get a special deal on a
business-class broadband connection at home, which included a small network business-class broadband connection at home, which included a small network
block (a `/28`, or 16 IP addresses) that I could use. I dedicated my most block (a `/28`, consisting of 16 IP addresses) that I could use. I dedicated
powerful machine to be my server and developed several services, including a my most powerful machine as my server and developed several services,
new website. including a new website.
My website at that time wasn't fancy, and was geared primarily towards My website at that time wasn't fancy, and was geared primarily towards
experimentation. I developed a simple content management system from scratch experimentation. I developed a simple content management system from scratch
@ -62,35 +69,105 @@ resulting static resources can be served as regular files from any web
service, without the need for dynamically generating content upon request from service, without the need for dynamically generating content upon request from
a database, as traditional CMS systems do. a database, as traditional CMS systems do.
Using Hugo is much easier with a good base template, and there are Using Hugo is much easier with a solid base template. There are
[many to choose from](https://themes.gohugo.io/). I've chosen one called [many to choose from](https://themes.gohugo.io/), including the one I've
["Blowfish"](https://blowfish.page/) for this site. selected here called ["Blowfish"](https://blowfish.page/).
Another benefit of a static site generator is that all the sources for the Another benefit of a static site generator is that all the sources for the
site can be treated like software code, making it simple to use development site can be treated like software code, making it simple to use development
tools like Git for version control. I keep the sources for this site in a tools like [Git](https://git-scm.com/) for version control. I keep the sources
public repository on my own Git server. Feel free to take a look: for this site in a public repository on my own Git server. Feel free to take a
look:
{{< gitea repo="d-b.ca/web" >}} {{< gitea repo="d-b.ca/web" >}}
### CI/CD ### CI/CD
I've also set up a CI/CD pipeline to build and deploy the site whenever I've also set up a CI/CD pipeline to build and deploy the site whenever
changes are made to the source repository. The CI portion is triggered by a changes are made to the source repository. What does this mean?
push to the web repository. It runs a workflow that builds the site and
packages the resulting artifacts into a container image based on **CI** = *Continuous Integration*
[Caddy](https://caddyserver.com/). The build container with Hugo is another > This is the practice of frequently integrating changes into a source
image I maintain in this repository: > repository. The changes are checked, assembled, and packaged through
> automated processes. [More information](https://martinfowler.com/articles/continuousIntegration.html)
**CD** = *Continuous Delivery*
> This is the capability of being able to take new changes (such as the
> outputs of the CI process) and getting them deployed and running
> automatically. [More information](https://continuousdelivery.com/)
The CI portion is triggered by a push to the
[`web`](https://git.brds.ca/d-b.ca/web) repository. It runs an automated
workflow that builds the site and packages the resulting artifacts into a
container image based on [Caddy](https://caddyserver.com/). This image
contains everything needed to serve the website. The build container with Hugo
is another image I maintain in this repository:
{{< gitea repo="d-b.ca/hugo-builder" >}} {{< gitea repo="d-b.ca/hugo-builder" >}}
Next, the workflow updates the CD GitOps repository to deploy this new version After the workflow has built the container image for running the website, it
to a private staging site. When I want to publish the new version as the updates the CD GitOps repository to deploy this new version immediately to a
production site, I use my regular GitOps repository to update the image tag, private staging site. Another definition:
and the rest happens automatically.
> **GitOps** refers to the practice of managing infrastructure automation by
> keeping machine-readable descriptions of the intended infrastructure in a
> version-controlled Git repository. A CD system will monitor the repository
> for changes, immediately adding, modifying, or removing infrastructure to
> bring the state of the operational system into alignment with the source
> description.
When I want to publish the new version as the production site, I use my
regular private production GitOps repository to update the image tag, and the
rest happens automatically. The CD repository for the staging site is public,
you're welcome to check it out here:
{{< gitea repo="d-b.ca/db-cd" >}} {{< gitea repo="d-b.ca/db-cd" >}}
#### Pipeline Diagram
{{< mermaid >}}
flowchart TB
subgraph GIT [Git Repository]
WR[(Web)]
CDR[(CD)]
end
WP(Push Web Updates)-->WR
WP ~~~ HBI
subgraph CI [CI Workflow]
CIP[Pull Source
Repository]-->BWI[Build Web
Image]
BWI-->PWI[Push Web
Image]
PWI-->UCD[Update CD
Repository]
end
PWI-->WI
WR-->CIP
subgraph DOCKER [Image Repository]
HBI((Hugo
Build))
WI((Web))
end
HBI-->BWI
UCD-->CDP(Push Image
Update)
CDP-->CDR
CDR-->CDPull
subgraph CD [CD Process]
CDPull[Pull Source Repository]-->DWI[Deploy Web Image]
end
WI-->DWI
{{< /mermaid >}}
## Underlying Platform ## Underlying Platform
In my next article, I'll describe the platform this site is running on, and In my next article, I'll describe the platform this site is running on, and