Hi there 👋

In an effort to tidy up the infrastructure behind wicknet.dev, new hostnames and tls certificates were configured. Forge-related services now all run under some combination of .forge.lan, and so a certificate that covered forge.lan and its subdomains was in order. To do this, two files were created, forge.lan.conf and forge.lan.v3.ext: [ req ] default_bits = 4096 default_md = sha512 prompt = no encrypt_key = no # base request distinguished_name = req_distinguished_name # extensions req_extensions = v3_req # distinguished_name [ req_distinguished_name ] commonName = "forge.lan" # CN= countryName = "US" # C= organizationName = "WickNet" # O= authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = forge.lan DNS.2 = *.forge.lan In the wild, certificates issued by let’s encrypt that cover subdomains also include the base domain in the list of alternate names. This practice is mirrored here. ...

The beginnings of CI/CD for the site have been installed. Woodpecker-CI has been hooked into forgejo, and temporary workflows have been put in place to build the site when content is altered. Once that is working as intended, deployment will be automated. Prior to this, docker containers were built manually, and the kubernetes deployment was restarted by hand. Ultimately, commits to the master branch will trigger this automatically for a full SDLC style deployment. ...

TLS termination has been moved off the VPS edge. The VPS has been configured to simply proxy ports 80 and 443 to an nginx ingress on the cluster. Certmanager was configured to provision certificates for the domain from the cluster backend. This means that encrypted http traffic is forwarded across the wireguard tunnel, where it is terminated on ingress to the cluster. This opens up easy options to add “dumb” edge nodes that only need an A record, a wireguard link to the cluster, and suitable nginx stream proxy rules. ...

According to the hugo documentation, the Dockerfile was reworked, and the structure of the docker container now follows the pattern of a hugo builder image and an nginx image that actually runs the static site. FROM hugomods/hugo:exts as builder ARG HUGO_BASEURL ENV HUGO_BASEURL=${HUGO_BASEURL} ARG HUGO_ENV ENV HUGO_ENV=${HUGO_ENV} COPY . /src RUN hugo --minify FROM hugomods/hugo:nginx COPY --from=builder /src/public /site Build with: docker build -t <tag> --build-arg HUGO_BASEURL="https://wicknet.dev" This is cleaner than using hugo itself to serve the files as was done in the quick and dirty first draft. ...

After a few days away, the hugo service was exposed through metallb to the LAN, and reverse proxied via the wicknet.dev frontend server.