@@ -39,7 +39,7 @@ Continue reading for an overview of the deployment and basic usage.
## Overview of deployment
Multi-tier deployment consisting of:
This is a Multi-tier deployment for after dark in order to run on k3s or other kubernetes cluster in a microservices way. Currently is meant to run on a single node cluster but you can still test a few things(see below) on a multinode cluster. Your site is being built by hugo and served by a separate nginx web server which is exposed as a service inside your cluster. Combined with a traefik ingress host rule it can be faced against the web abstractingly from its backend. The deployment is consisted of the following manifests:
* ``after-dark-k3s-hugo.yaml`` deploys a pod using two containers. First, an ephemeral initialization tasked with downloading After Dark from [source repo](https://git.habd.as/comfusion/after-dark) and, finally, the actual hugo container which kicks in and installs the site. When done it runs [`hugo server`](https://gohugo.io/commands/hugo_server/) in _watch mode_ so [Hugo](https://gohugo.io/) rebuilds After Dark site as files change.
* ``after-dark-nginx.yaml`` deploys an [nginx](https://www.nginx.com/) web server that serves the content of the rendered site. As file changes occur Hugo will rebuild the After Dark site and nginx will pick up the changes.
* Full rebuilt your site e.g after new styles appied ``$ kubectl exec $AD_POD -- hugo -c /my-content -d /output`` Note this will also revert drafts.
* Edit your posts ``$ kubectl exec -it $AD_POD -- vi /my-content/my-post.md`` or directly inside your host's ``/my-content``
``$ kubectl exec $AD_POD -- hugo -D -d /output``
* Full rebuilt your site e.g after new styles appied ``$ kubectl exec $AD_POD -- hugo -d /output`` Note this will also revert drafts.
* Edit your posts ``$ kubectl exec -it $AD_POD -- vi content/post/my-post.md`` or write your post locallt then push it to your pod. ``$ kubectl cp hello-world.md $AD_POD:content/post``. Make sure you've got your [front matter](https://gohugo.io/content-management/front-matter/) right.
* Backup your posts. Create a backup folder locally on your host then ``$ kubectl cp $AD_POD:content/post backup/``
* Check the stream of logs for troubleshooting ``$ kubectl logs -f $AD_POD``
### Browsing to your site
@@ -68,3 +71,12 @@ To view your site run `kubectl get svc` to locate the NodePort exposed to nginx.
Grab the port number next to `8080:` and use it to browse to your site using the node IP or, locally on the host, using the loopback e.g. `http://localhost:32146`. (Note: Ignore the <samp>Cluster-IP</samp> and the <samp>External-IP</samp>, you want the real IP of your host.)
### Other noteable features
* Except from the ``/rendered-site`` folder which , you will find locally on your server node and holds the built site, all other stuff are located inside the pod's overlay filesystem which is [ephemeral](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir). Therefore make sure you backup your posts.
* In case you delete your hugo pod or it crashes for other reasons, your site will still be served by the nginx which picks ups the last known built from the output folder mentioned above.
Whenever you delete your hugo pod, K8s scheduler will recreate it from scratch so you will start fresh. You will then need to copy back your stuff.
* If you are running in a multi node cluster (not currenty recommended, unless you have refactored the deployments to use shared [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)) both hugo and nginx will always be scheduled on the same node to ensure nginx is fed properly.
* The [nodeport](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport) this deployment uses to expose our web server is bound on all worker nodes of your cluster if you have more than one. This means you can reach you site form any node ([k8s service discovery and loadbalancing](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)). In the event you loose the node that actually holds the site your deployment will still be up as it will be rescheduled on an available worker but you will have to restore yours posts.
* Edit the provided ingress manifest in folder x to match your domain name e.g. example.com so that your site is publicly available in a nice URL instead of the nodeport