Update Servers/Documentation/Zensical.md
This commit is contained in:
@@ -4,7 +4,9 @@ After many years of Material for MKDocs being updated with new features and secu
|
||||
!!! info "Assumptions"
|
||||
It is assumed that you are deploying this server into `Ubuntu Server 24.04.2 LTS (Minimal)`. It is also assumed that you are running every command as a user with superuser privileges (e.g. `root`).
|
||||
|
||||
### Architectural Overview
|
||||
You are generally safe to have a GuestVM with 16GB for the virtual disk, and expand it over-time based on your needs. CPU count and RAM allocation can also be extremely low based on your preferences, since this is simply a static page website at the end of the day.
|
||||
|
||||
## Architectural Overview
|
||||
It is useful to understand the flow of data and how everything inter-connects, so I have provided a sequence diagram that you can follow below:
|
||||
|
||||
``` mermaid
|
||||
@@ -24,7 +26,7 @@ sequenceDiagram
|
||||
NGINX-->>NGINX: Serve files from /srv/zensical/site
|
||||
```
|
||||
|
||||
### Setup Python Environment
|
||||
## Setup Python Environment
|
||||
The first thing we need to do is install the necessary python packages and install the zensical software stack inside of it.
|
||||
|
||||
```sh
|
||||
@@ -39,7 +41,8 @@ zensical new .
|
||||
deactivate
|
||||
```
|
||||
|
||||
### Configure Zensical Settings
|
||||
## Zensical
|
||||
### Configure Settings
|
||||
Now we want to set some sensible defaults for Zensical to style it to look as close to Material for MKDocs as possible.
|
||||
|
||||
```sh
|
||||
@@ -65,47 +68,7 @@ sed -i -E 's/^[[:space:]]*#([[:space:]]*"navigation\.tabs",[[:space:]]*)/\1/' ze
|
||||
sed -i -E 's/^[[:space:]]*#([[:space:]]*"navigation\.tabs\.sticky",[[:space:]]*)/\1/' zensical.toml
|
||||
```
|
||||
|
||||
### Deploy NGINX Webserver
|
||||
We need to deploy NGINX as a webserver, because when using reverse proxies like Traefik, it seems to not get along with Zensical at all. Attempts to resolve this all failed, so putting the statically-built copies of site data that Zensical generates into NGINX's root directory is the second-best solution I came up with. Traefik can be reasonably expected to behave when interacting with NGINX versus Zensical's built-in webserver.
|
||||
|
||||
```sh
|
||||
sudo apt install -y nginx
|
||||
sudo rm -f /etc/nginx/sites-enabled/default
|
||||
sudo tee /etc/nginx/sites-available/zensical.conf > /dev/null <<'EOF'
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
server_name _;
|
||||
|
||||
root /srv/zensical/site;
|
||||
index index.html;
|
||||
|
||||
# Primary document handling
|
||||
location / {
|
||||
try_files $uri $uri/ /index.html;
|
||||
}
|
||||
|
||||
# Static asset caching (safe for docs)
|
||||
location ~* \.(css|js|png|jpg|jpeg|gif|svg|ico|woff2?)$ {
|
||||
expires 7d;
|
||||
add_header Cache-Control "public, max-age=604800, immutable";
|
||||
try_files $uri =404;
|
||||
}
|
||||
|
||||
# Prevent access to source or metadata
|
||||
location ~* \.(toml|md)$ {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
EOF
|
||||
|
||||
sudo ln -s /etc/nginx/sites-available/zensical.conf /etc/nginx/sites-enabled/zensical.conf
|
||||
sudo nginx -t
|
||||
sudo systemctl reload nginx
|
||||
sudo systemctl enable nginx
|
||||
```
|
||||
|
||||
### Create Zensical Watchdog Service
|
||||
### Create Watchdog Service
|
||||
Since NGINX has taken over hosting the webpages, this does not need to be accessible from other servers, only NGINX itself which runs on the same host as Zensical. We only want to use the `zensical serve` command to keep a watchdog on the documentation folder and automatically rebuild the static site content when changes are detected. These changes are then served by NGINX's webserver.
|
||||
|
||||
```sh
|
||||
@@ -149,7 +112,47 @@ sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now zensical-watchdog.service
|
||||
```
|
||||
|
||||
### Create Gitea Runner
|
||||
## NGINX Webserver
|
||||
We need to deploy NGINX as a webserver, because when using reverse proxies like Traefik, it seems to not get along with Zensical at all. Attempts to resolve this all failed, so putting the statically-built copies of site data that Zensical generates into NGINX's root directory is the second-best solution I came up with. Traefik can be reasonably expected to behave when interacting with NGINX versus Zensical's built-in webserver.
|
||||
|
||||
```sh
|
||||
sudo apt install -y nginx
|
||||
sudo rm -f /etc/nginx/sites-enabled/default
|
||||
sudo tee /etc/nginx/sites-available/zensical.conf > /dev/null <<'EOF'
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
server_name _;
|
||||
|
||||
root /srv/zensical/site;
|
||||
index index.html;
|
||||
|
||||
# Primary document handling
|
||||
location / {
|
||||
try_files $uri $uri/ /index.html;
|
||||
}
|
||||
|
||||
# Static asset caching (safe for docs)
|
||||
location ~* \.(css|js|png|jpg|jpeg|gif|svg|ico|woff2?)$ {
|
||||
expires 7d;
|
||||
add_header Cache-Control "public, max-age=604800, immutable";
|
||||
try_files $uri =404;
|
||||
}
|
||||
|
||||
# Prevent access to source or metadata
|
||||
location ~* \.(toml|md)$ {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
EOF
|
||||
|
||||
sudo ln -s /etc/nginx/sites-available/zensical.conf /etc/nginx/sites-enabled/zensical.conf
|
||||
sudo nginx -t
|
||||
sudo systemctl reload nginx
|
||||
sudo systemctl enable nginx
|
||||
```
|
||||
|
||||
## Gitea ACT Runner
|
||||
Now is time for the arguably most-important stage of deployment, which is setting up a [Gitea Act Runner](https://docs.gitea.com/usage/actions/act-runner). This is how document changes in a Gitea repository will propagate automatically into Zensical's `/srv/zensical/docs` folder.
|
||||
|
||||
```sh
|
||||
@@ -171,7 +174,7 @@ sudo chown gitearunner:gitearunner /etc/gitea_runner
|
||||
sudo -u gitearunner gitea_runner generate-config > /etc/gitea_runner/config.yaml
|
||||
```
|
||||
|
||||
#### Obtain & Configure Gitea Runner Registration Token
|
||||
### Configure Registration Token
|
||||
- Navigate to: "**<Gitea Repo> > Settings > Actions > Runners**"
|
||||
- If you don't see this, it needs to be enabled. Navigate to: "**<Gitea Repo> > Settings > "Enable Repository Actions: Enabled" > Update Settings**"
|
||||
- Click the "**Create New Runner**" button on the top-right of the page and copy the registration token somewhere temporarily.
|
||||
@@ -193,7 +196,7 @@ sudo chmod 600 /var/lib/gitea_runner/.runner
|
||||
|
||||
```
|
||||
|
||||
#### Create Gitea Runner Service
|
||||
### Create Service
|
||||
Now we need to configure the Gitea runner to start automatically via a service just like the Zensical Watchdog service.
|
||||
|
||||
```sh
|
||||
@@ -267,7 +270,7 @@ jobs:
|
||||
curl -d "https://kb.bunny-lab.io - Zensical job status: ${{ job.status }}" https://ntfy.bunny-lab.io/gitea-runners
|
||||
```
|
||||
|
||||
### Traefik Reverse Proxy Configuration
|
||||
## Traefik Reverse Proxy
|
||||
It is assumed that you use a [Traefik](https://kb.bunny-lab.io/Servers/Containerization/Docker/Compose/Traefik/) reverse proxy and are configured to use [dynamic configuration files](https://kb.bunny-lab.io/Servers/Containerization/Docker/Compose/Traefik/#dynamic-configuration-files). Add the file below to expose the Zensical service to the rest of the world.
|
||||
|
||||
```yaml title="kb.bunny-lab.io.yml"
|
||||
|
||||
Reference in New Issue
Block a user