175 lines
6.9 KiB
Markdown
175 lines
6.9 KiB
Markdown
---
|
||
title: "New Website"
|
||
date: "2025-06-10T08:00:00-06:00"
|
||
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."
|
||
---
|
||
|
||
I've finally published a proper website at [https://d-b.ca/](https://d-b.ca/).
|
||
The last time I had anything live on this domain was over 20 years ago,
|
||
according to the [Wayback Machine](https://web.archive.org/). What took so
|
||
long? Over the years I've learned a lot, and I'm constantly experimenting with
|
||
new ways of getting things done. This site, while useful in its own right, is
|
||
a culmination of the platform I've developed to host it.
|
||
|
||
## History
|
||
|
||
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
|
||
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
|
||
time and didn't last beyond my time at school, but it sparked my interest in
|
||
Internet technologies and their applications.
|
||
|
||
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
|
||
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
|
||
|
||
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
|
||
business-class broadband connection at home, which included a small network
|
||
block (a `/28`, consisting of 16 IP addresses) that I could use. I dedicated
|
||
my most powerful machine as my server and developed several services,
|
||
including a new website.
|
||
|
||
My website at that time wasn't fancy, and was geared primarily towards
|
||
experimentation. I developed a simple content management system from scratch
|
||
in PHP3, which I used to publish a blog. It also integrated with mailing
|
||
lists, another area I was exploring at the time.
|
||
|
||
### D-B.CA
|
||
|
||
I hadn't registered a domain name of my own in those early days, so everything
|
||
resided under a friend's domain. In late 2002, I decided to finally register
|
||
one of my own, primarily so I could have a stable email address. I came up
|
||
with `d-b.ca` because someone was squatting on `db.ca` – and still is, I might
|
||
add.
|
||
|
||
Early on, I focused mostly on operating my email services and other
|
||
experiments, with little attention paid to a website. There were a few test
|
||
pages at times, but nothing substantial.
|
||
|
||
## Modern Technology
|
||
|
||
One of the projects I've been following is [Hugo](https://gohugo.io/). I've
|
||
seen and worked with various web content management systems in the past, and
|
||
they often feel cumbersome and present security concerns. Hugo is an example
|
||
of a "Static Site Generator," which transforms a source description of a site
|
||
into the static resources used to serve it – much like a compiler. The
|
||
resulting static resources can be served as regular files from any web
|
||
service, without the need for dynamically generating content upon request from
|
||
a database, as traditional CMS systems do.
|
||
|
||
Using Hugo is much easier with a solid base template. There are
|
||
[many to choose from](https://themes.gohugo.io/), including the one I've
|
||
selected here called ["Blowfish"](https://blowfish.page/).
|
||
|
||
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
|
||
tools like [Git](https://git-scm.com/) for version control. I keep the sources
|
||
for this site in a public repository on my own Git server. Feel free to take a
|
||
look:
|
||
|
||
{{< gitea repo="d-b.ca/web" >}}
|
||
|
||
### CI/CD
|
||
|
||
I've also set up a CI/CD pipeline to build and deploy the site whenever
|
||
changes are made to the source repository. What does this mean?
|
||
|
||
**CI** = *Continuous Integration*
|
||
> This is the practice of frequently integrating changes into a source
|
||
> 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" >}}
|
||
|
||
After the workflow has built the container image for running the website, it
|
||
updates the CD GitOps repository to deploy this new version immediately to a
|
||
private staging site. Another definition:
|
||
|
||
> **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" >}}
|
||
|
||
#### 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
|
||
|
||
In my next article, I'll describe the platform this site is running on, and
|
||
some of the history and decisions that drove its design.
|