diff --git a/content/posts/new-website/index.md b/content/posts/new-website/index.md index 49d1950..d5fee4b 100644 --- a/content/posts/new-website/index.md +++ b/content/posts/new-website/index.md @@ -1,6 +1,6 @@ --- 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." 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 [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 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. +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`, or 16 IP addresses) that I could use. I dedicated my most -powerful machine to be my server and developed several services, including a -new website. +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 @@ -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 a database, as traditional CMS systems do. -Using Hugo is much easier with a good base template, and there are -[many to choose from](https://themes.gohugo.io/). I've chosen one called -["Blowfish"](https://blowfish.page/) for this site. +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 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: +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. The CI portion is triggered by a -push to the web repository. It runs a workflow that builds the site and -packages the resulting artifacts into a container image based on -[Caddy](https://caddyserver.com/). The build container with Hugo is another -image I maintain in this repository: +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" >}} -Next, the workflow updates the CD GitOps repository to deploy this new version -to a private staging site. When I want to publish the new version as the -production site, I use my regular GitOps repository to update the image tag, -and the rest happens automatically. +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