updated documentation

Dockerfile

@@ -1,11 +1,31 @@
+# use the classic alpine image
 FROM alpine as Builder
-RUN apk update && apk add curl git
+
+# install curl and git
+RUN apk add curl git
+
+# download and unnzip the hugo binary then place it in /usr/local/bin
 RUN curl -L https://github.com/gohugoio/hugo/releases/download/v0.92.2/hugo_0.92.2_Linux-ARM64.tar.gz > hugo.tar.gz && tar -zxf hugo.tar.gz && mv hugo /usr/local/bin
+
+# clone the blog repository as well as the theme submodule
 RUN git clone --recurse-submodules https://gitlab.com/AHMZA/blog.git
+
+# set blog (the folder we just cloned) as the current DIR
 WORKDIR blog
+
+# Hugo generates the static files and minifies them
 RUN hugo --minify
 
+
+
+# Nginx image is as basic as we can get
 FROM nginx
+
+# copy the nginx.conf file
 COPY --from=Builder /blog/nginx.conf /etc/nginx/nginx.conf
+
+# copy the static files
 COPY --from=Builder /blog/public/ /usr/share/nginx/html
+
+# Tell the image to expose port 80 for HTTP
 EXPOSE 80

README.md

@@ -1,39 +1,57 @@
 # blog-hugo
-I am hoping to migrate my dynamic blog currently hosted using GHOST CMS
+
-to a static site using HUGO.
+This is probably the hundredth rendition of this site xD Previously to
+using HUGO my blog was built using GHOST CMS which is a great platform
+and is feature rich. However my problem came with the base design
+philosophy of a CMS, relying on a Database.
+
+HUGO is a static site generator meaning it takes a readable file format
+like markdown and then compiles all that down into HTML (Static Files)
+This removes the need for a database and in turn improves performance of
+the site ten fold.
 
 ## Pros of static sites
+
 * Security
 * Reliability
 * Speed
 * Scalability
 * Low Resource requirement
 
-## Why
+## Cons of a static site
-The reasons above all fit well with my current goal of trying to containerise
-all of the services running on my home lab. Currently I have 2 servers running
-Proxmox VE with a combined 48 threads and 256GB of RAM which as you can imagine
-take a lot of power.
 
-The plan is to slowly move the majority of my services to a cluster of
+* Less user friendly
-4 RaspberryPis. If all the services required support the ARM CPU architecture
+
-then I can completely decommission the power hungry servers.
+## Why
+
+The reasons above all fit within my goal of trying to containerise
+services running in my home lab.
+
+The plan is to move the services I use to a cluster of Raspberry Pis. As
+long as the services have an ARM image or I can build an ARM image then
+this is a viable solution
 
 ## How
-I am still coming up with the deployment method of this site but from what I
-have seen the Gitlab CI/CD pipeline makes a lot of sense as the site will be
-hosted on Gitlab anyway.
-* Update Gitlab with new code
-* Gitlab generates a docker image
-* Docker Swarm cluster uses that image to host the site
 
+The deployment method of this site relies on the Gitlab CI/CD pipeline.
+* Clone the repository
+* Push changes to Gitlab
+* Gitlab runners create the docker image
+* Image is pushed to my private docker repository
+* Pi cluster uses that image to host the site locally
 
 ## When Pulling / Cloning
+
+Be sure to add `--recurse-submodules` as the theme used is a submodule
+
 ``` bash
 git clone --recurse-submodules git@gitlab.com:AHMZA/blog.git
 ```
 
 ## Update the theme
+
+As the theme is a submodule it will need to be update with the following
+
 ``` bash
 git submodule update --remote --merge
 ```

nginx.conf

@@ -36,9 +36,9 @@ http {
         # save logs here
         access_log /var/log/nginx/access.log compression;
 
-        # where the root here
+        # where's the root dir
         root /usr/share/nginx/html;
-        # what file to server as index
+        # what file to serve as index
         index index.html index.htm;
 
         location / {