Feature/sentry error logging #5
@@ -432,3 +432,27 @@
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); reverts the previous change and documents remaining open questions about the PR triggering issue that require checking the Gitea instance directly. Committed on `feature/updates_gitea_workflow`.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: SCP Method Fixed (Docker/Podman Issue) & nginx Configs Finalized
|
||||
|
||||
**Timestamp**: 2026-07-25T12:22:00Z
|
||||
|
||||
**User Input**: "ik heb de deploy-workflow iets aangepast. De originele manier werkte niet met Docker/Podman. De huidige manier werkt wel. Kan je dat doorvoeren door de documentatie? Verder heb ik in `reverse-proxy-nginx.conf.example` en `webserver-nginx.conf.example` onder de comment '# Gebruikte versie' de daadwerkelijke versie staan. Dit werkt nu. Kan je de configuraties controleren en als example opnemen ipv jouw variant? Controleer even of alle headers goed genoemd zijn of dat je andere foutjes ziet. [...] De productieversie mag je van mij ook weg doen voor nu."
|
||||
|
||||
**AI Response**: "Confirmed the user's own fix to `deploy.yaml` (already merged to `master` externally): the `appleboy/scp-action` Docker-container-action failed on the self-hosted Podman-based runner (`failed to attach to container: unable to upgrade to tcp, received 409`); replaced with a plain `run:` step using `sshpass`+`scp`. Updated `deployment-instructions.md`, `deployment-plan.md` and `rollback-plan.md` to describe this. Replaced both nginx example files with only the user's 'Gebruikte versie' configs (removed the earlier draft variants), found and fixed a header typo (`X-Real_IP` should be `X-Real-IP`) in `reverse-proxy-nginx.conf.example`, and flagged a path discrepancy: the pipeline uploads to `/html/test/slpsoftware` while nginx's `root` is `/mnt/storage1/www/html/test/slpsoftware` (documented as needing a symlink/mount check on the Pi). Deleted `nginx/reverse-proxy-nginx-production.conf.example` per explicit request."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); reconciles documentation with manual workflow/nginx changes made directly by the user outside this session. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Path Difference Between `deploy_path` and nginx `root` Clarified
|
||||
|
||||
**Timestamp**: 2026-07-25T12:33:00Z
|
||||
|
||||
**User Input**: "Ik zie dat je het pad-verschil hebt opgemerkt van wat er in de nginx config staat en wat er wordt meegegeven in de deploy-workflow. Het pad op de server zelf en wat gebruikt wordt voor de nginx configuratie is het volledige pad `/mnt/storage1/www/html/test/slpsoftware` terwijl de ftp gebruiker als root heeft `/mnt/storage1/www` dus het pad voor deployment is `/html/test/slpsoftware`. Misschien dat dat verschil wat mooier kan worden verwoord in de documentatie"
|
||||
|
||||
**AI Response**: "Reworded the earlier 'path discrepancy — verify on the Pi' warning in `deployment-instructions.md` and `rollback-plan.md`: this is not a potential bug requiring verification, but expected behavior, since the SCP/SSH user's root is `/mnt/storage1/www` (comparable to an FTP chroot). `deploy_path` (`/html/test/slpsoftware`) is therefore the correct path relative to that user's root, which on the Pi's actual filesystem resolves to the full path `/mnt/storage1/www/html/test/slpsoftware` used as nginx's `root`."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); clarifies wording of the previous follow-up's path-discrepancy note per user feedback. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
+11
-7
@@ -13,7 +13,10 @@ Sinds deze stap wordt er automatisch gedeployed naar een **testomgeving**: een R
|
||||
- `prepare` → `build` (uploadt de artifact, naam/pad uit `env.ARTIFACT_NAME`/`env.ARTIFACT_PATH`) → `test` (lint + unit tests)
|
||||
- Een losse `config`-job zet deze `env`-waarden om in job-outputs (zie hieronder waarom dat nodig is).
|
||||
- `deploy-test` (alleen bij `workflow_dispatch` of een push naar `master`) roept `deploy.yaml` aan met `artifact_name`/`environment`/`deploy_path` afkomstig van `needs.config.outputs.*` (dus indirect uit het `env:`-blok).
|
||||
- `deploy.yaml` — download de artifact (naam/lokaal pad = `inputs.artifact_name`) en upload de inhoud via `appleboy/scp-action` naar de opgegeven `deploy_path` op de host uit de meegegeven secrets.
|
||||
- `deploy.yaml` — download de artifact (naam/lokaal pad = `inputs.artifact_name`) en upload de inhoud via een `scp`-commando (met `sshpass` voor het wachtwoord) in een gewone shell-stap naar de opgegeven `deploy_path` op de host uit de meegegeven secrets.
|
||||
|
||||
### Waarom `sshpass`/`scp` in een shell-stap in plaats van de `appleboy/scp-action` Docker-action?
|
||||
De oorspronkelijke aanpak gebruikte de `appleboy/scp-action` (een Docker-container-action). Dit werkte niet op deze zelf-gehoste Gitea-runner: de stap faalde met `failed to attach to container: unable to upgrade to tcp, received 409`, een bekende beperking van Podman's Docker-compatibele API, die het attach/log-streaming-mechanisme voor container-based actions niet volledig ondersteunt. De huidige aanpak (een normale `run:`-stap die `sshpass` installeert en zelf `scp` aanroept) heeft geen geneste container nodig en werkt daardoor wel.
|
||||
|
||||
### Waarom een aparte `config`-job in plaats van rechtstreeks het `env:`-blok?
|
||||
Gitea/GitHub Actions ondersteunt geen `env`-context in de `with:`-sectie waarmee een reusable workflow wordt aangeroepen (`jobs.<job_id>.with`) — dat werkt alléén binnen `jobs.<job_id>.steps`. De oplossing is een klein voorloop-job (`config`) dat de gewenste `env`-waarden via `$GITHUB_OUTPUT` naar job-outputs schrijft; die outputs (`needs.config.outputs.*`) zijn wél bruikbaar in `jobs.<job_id>.with`. Zo hoef je, om de artifact-naam/pad of de testdeploy-bestemming te wijzigen, alléén het `env:`-blok bovenaan `continuous_integration.yaml` aan te passen — niet de `deploy-test`-job zelf.
|
||||
@@ -35,11 +38,12 @@ Deze secrets heten `PI_MAIN_*` (niet `PI_TEST_*`), omdat dezelfde Pi (Pi Main) e
|
||||
- **Productie** (nog niet automatisch gedeployed, maar domein al bekend): `slpsoftware.nl` (en `www.slpsoftware.nl`) → zelfde reverse-proxy-Pi, zodra productie wordt opgezet.
|
||||
|
||||
## Eenmalige Setup — nginx & SSL op de Raspberry Pi's
|
||||
1. Kopieer `operations/deployment/nginx/webserver-nginx.conf.example` naar `/etc/nginx/sites-available/` op de webserver-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx.
|
||||
2. Kopieer `operations/deployment/nginx/reverse-proxy-nginx.conf.example` naar `/etc/nginx/sites-available/slpsoftware-test.conf` op de reverse-proxy-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx. Dit bestand gebruikt al `test.slpsoftware.nl` als `server_name`.
|
||||
1. Kopieer `operations/deployment/nginx/webserver-nginx.conf.example` naar `/etc/nginx/sites-available/` op de webserver-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx. Dit bestand is de daadwerkelijk in gebruik zijnde configuratie (`server_name test.slpsoftware.nl`, luistert op poort 80, serveert vanaf `/mnt/storage1/www/html/test/slpsoftware`).
|
||||
2. Kopieer `operations/deployment/nginx/reverse-proxy-nginx.conf.example` naar `/etc/nginx/sites-available/slpsoftware-test.conf` op de reverse-proxy-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx. Ook dit bestand is de daadwerkelijk in gebruik zijnde (door certbot beheerde) configuratie, met `server_name test.slpsoftware.nl`.
|
||||
3. Vraag op de reverse-proxy-Pi een SSL-certificaat aan met certbot (Let's Encrypt), nadat het DNS-record klopt: `sudo certbot --nginx -d test.slpsoftware.nl`. Certbot regelt automatisch de HTTPS-configuratie en de HTTP→HTTPS-redirect (net zoals je gewend bent van certbot).
|
||||
4. Zorg dat de map `/html/test/slpsoftware` bestaat op de webserver-Pi en schrijfbaar is voor de gebruiker `webadmin` (bijv. `sudo mkdir -p /html/test/slpsoftware && sudo chown webadmin:webadmin /html/test/slpsoftware`).
|
||||
5. Voor later, wanneer productie wordt opgezet: zie `operations/deployment/nginx/reverse-proxy-nginx-production.conf.example` (domein `slpsoftware.nl`, certbot-commando alvast gedocumenteerd).
|
||||
4. Zorg dat de map `/mnt/storage1/www/html/test/slpsoftware` bestaat op de webserver-Pi en schrijfbaar is voor de gebruiker `webadmin` (bijv. `sudo mkdir -p /mnt/storage1/www/html/test/slpsoftware && sudo chown webadmin:webadmin /mnt/storage1/www/html/test/slpsoftware`).
|
||||
|
||||
> **Waarom `deploy_path` en de nginx `root` niet hetzelfde pad zijn**: de pipeline uploadt via SCP naar `deploy_path` = `/html/test/slpsoftware` (zie `env.DEPLOY_PATH` in `continuous_integration.yaml`), terwijl de nginx `root` in `webserver-nginx.conf.example` het volledige pad `/mnt/storage1/www/html/test/slpsoftware` is. Dit is geen fout of inconsistentie: de SSH/SCP-gebruiker (`webadmin`) heeft `/mnt/storage1/www` als root (vergelijkbaar met een FTP-chroot), dus vanuit het perspectief van deze gebruiker is `/html/test/slpsoftware` het juiste (relatieve) pad, terwijl dat op het bestandssysteem van de Pi zelf overeenkomt met het volledige pad `/mnt/storage1/www/html/test/slpsoftware` dat nginx als `root` gebruikt. Kortom: `deploy_path` (`/html/test/slpsoftware`) + de root van de `webadmin`-gebruiker (`/mnt/storage1/www`) = de nginx `root` (`/mnt/storage1/www/html/test/slpsoftware`).
|
||||
|
||||
## How to Deploy to Test
|
||||
### Automatisch
|
||||
@@ -55,5 +59,5 @@ Merge een pull request naar `master` — de `deploy-test` job draait dan automat
|
||||
2. Open de testomgeving in de browser (via het adres/IP dat je bij de reverse-proxy hebt ingesteld) en controleer dat de site correct laadt (check de browserconsole op fouten, zoals in de handmatige smoke test in `construction/build-and-test/integration-test-instructions.md`).
|
||||
|
||||
## Future Work
|
||||
- **Van wachtwoord naar SSH-key**: vervang `password: ${{ secrets.PI_MAIN_PASSWORD }}` in `deploy.yaml` door `key: ${{ secrets.PI_MAIN_SSH_KEY }}` (een nieuwe secret met de private key-inhoud), en zet de bijbehorende public key in `~/.ssh/authorized_keys` van de `webadmin`-gebruiker op de webserver-Pi. Verwijder daarna het wachtwoord-secret.
|
||||
- **Productie-omgeving**: voeg een `deploy-production`-job toe zodra de definitieve productiehosting bekend is (zie `deployment-plan.md`'s "Open Item"), en pas `nginx/reverse-proxy-nginx-production.conf.example` (domein `slpsoftware.nl`) toe zodra de webserver-locatie voor productie vastligt.
|
||||
- **Van wachtwoord naar SSH-key**: vervang `sshpass -p "${{ secrets.PI_MAIN_PASSWORD }}" scp ...` in `deploy.yaml` door een `scp`-commando met `-i <key-bestand>` (een nieuwe secret `PI_MAIN_SSH_KEY` die je eerst als bestand wegschrijft in de run-stap), en zet de bijbehorende public key in `~/.ssh/authorized_keys` van de `webadmin`-gebruiker op de webserver-Pi. Verwijder daarna het wachtwoord-secret.
|
||||
- **Productie-omgeving**: voeg een `deploy-production`-job toe zodra de definitieve productiehosting bekend is (zie `deployment-plan.md`'s "Open Item"). De productie-nginx-voorbeeldconfiguratie is op verzoek van de gebruiker verwijderd totdat er een goed-werkende versie is; die kan later opnieuw opgebouwd worden naar analogie van `nginx/webserver-nginx.conf.example` en `nginx/reverse-proxy-nginx.conf.example`, met domein `slpsoftware.nl`.
|
||||
|
||||
@@ -11,13 +11,13 @@ Sinds deze stap is er een echte, geautomatiseerde upload naar een **testomgeving
|
||||
1. Bij elke pull request draait automatisch de build/test/lint-gate (`prepare` → `build` → `test`), zodat merge requests direct gevalideerd worden.
|
||||
2. Zodra een pull request naar `master` gemerged wordt (of de workflow handmatig via `workflow_dispatch` gestart wordt), draait aanvullend de `deploy-test` job.
|
||||
3. `deploy-test` roept de herbruikbare `deploy.yaml` workflow aan met `artifact_name`/`environment`/`deploy_path`, en geeft via `secrets: inherit` de Pi-inloggegevens door. Deze drie waarden (samen met de artifact-naam/pad die de `build`-job gebruikt) staan als variabelen in het `env:`-blok bovenaan `continuous_integration.yaml` (`ARTIFACT_NAME`, `ARTIFACT_PATH`, `DEPLOY_ENVIRONMENT`, `DEPLOY_PATH`), en worden via een kleine `config`-job als job-outputs doorgegeven aan `deploy-test` (nodig omdat de `env`-context zelf niet werkt in de `with:`-sectie van een reusable-workflow-aanroep).
|
||||
4. `deploy.yaml` downloadt de artifact en uploadt de inhoud via SCP (wachtwoord-login) naar de webserver-Pi op het interne netwerk (`192.168.1.103`, poort `2224`).
|
||||
5. nginx op de webserver-Pi serveert de bestanden vanaf `/html/test/slpsoftware`; de reverse-proxy-Pi stuurt binnenkomend verkeer door naar deze webserver-Pi. Voorbeeldconfiguraties staan in `operations/deployment/nginx/`.
|
||||
4. `deploy.yaml` downloadt de artifact en uploadt de inhoud via een `scp`-commando (met `sshpass` voor het wachtwoord) in een gewone shell-stap naar de webserver-Pi op het interne netwerk (`192.168.1.103`, poort `2224`). Dit vervangt de eerdere `appleboy/scp-action` (Docker-container-action), die faalde op de zelf-gehoste Podman-runner (`failed to attach to container: unable to upgrade to tcp, received 409`).
|
||||
5. nginx op de webserver-Pi serveert de bestanden vanaf `/mnt/storage1/www/html/test/slpsoftware`; de reverse-proxy-Pi stuurt binnenkomend verkeer door naar deze webserver-Pi. Voorbeeldconfiguraties staan in `operations/deployment/nginx/` en zijn de daadwerkelijk in gebruik zijnde configuraties (niet langer illustratieve concepten).
|
||||
6. De reverse-proxy-Pi is ook verantwoordelijk voor SSL: certificaten worden net als voorheen aangevraagd via certbot (Let's Encrypt) en HTTP-verkeer wordt doorverwezen naar HTTPS.
|
||||
|
||||
## Environments
|
||||
- **Test** (nieuw, geautomatiseerd): zoals hierboven beschreven — de enige omgeving die op dit moment daadwerkelijk automatisch gedeployed wordt. Domeinnaam: `test.slpsoftware.nl` (SSL via certbot op de reverse-proxy-Pi).
|
||||
- **Productie**: nog niet geautomatiseerd. Zodra de definitieve productiehosting bekend is, kan een vergelijkbare `deploy-production`-job worden toegevoegd die `deploy.yaml` aanroept met `environment: production` en de productie-secrets/pad. Domeinnaam ligt al vast: `slpsoftware.nl` (SSL eveneens via certbot; zie `nginx/reverse-proxy-nginx-production.conf.example`).
|
||||
- **Productie**: nog niet geautomatiseerd. Zodra de definitieve productiehosting bekend is, kan een vergelijkbare `deploy-production`-job worden toegevoegd die `deploy.yaml` aanroept met `environment: production` en de productie-secrets/pad. Domeinnaam ligt al vast: `slpsoftware.nl` (SSL eveneens via certbot). Er is (nog) geen productie-nginx-voorbeeldconfiguratie; deze is op verzoek verwijderd totdat er een goed-werkende, foutloze versie is, en kan later opnieuw opgebouwd worden naar analogie van de testomgeving-configuraties.
|
||||
|
||||
## Automation Level
|
||||
Volledig geautomatiseerd voor de testomgeving: build, test, lint én upload naar de test-Pi gebeuren zonder handmatige tussenstap, zodra er gemerged wordt naar `master` (of handmatig getriggerd wordt). Alleen productie is nog niet geautomatiseerd.
|
||||
@@ -37,7 +37,7 @@ Deze secrets heten bewust `PI_MAIN_*` in plaats van `PI_TEST_*`: alle webhosts g
|
||||
Dit is bewust wachtwoord-authenticatie (voor nu, zoals gekozen), zodat de testomgeving snel werkend is. Zie "Future Work" in `deployment-instructions.md` voor de overstap naar SSH-key-authenticatie.
|
||||
|
||||
## Open Item — Productie-deploy Nog Niet Geautomatiseerd
|
||||
Zodra de definitieve productiehosting bekend is (en of dit dezelfde soort Raspberry Pi-opstelling is, of een externe hostingpartij), voeg een `deploy-production`-job toe aan `continuous_integration.yaml` die `deploy.yaml` aanroept met `environment: production`. Zolang het dezelfde webhost (Pi Main) blijft, kunnen de bestaande `PI_MAIN_*` secrets hergebruikt worden; pas dit pas aan naar omgeving-specifieke secrets als productie daadwerkelijk op een andere host komt. Domeinnaam (`slpsoftware.nl`) en SSL-aanpak (certbot/Let's Encrypt op de reverse-proxy-Pi) liggen al vast, zie `nginx/reverse-proxy-nginx-production.conf.example`.
|
||||
Zodra de definitieve productiehosting bekend is (en of dit dezelfde soort Raspberry Pi-opstelling is, of een externe hostingpartij), voeg een `deploy-production`-job toe aan `continuous_integration.yaml` die `deploy.yaml` aanroept met `environment: production`. Zolang het dezelfde webhost (Pi Main) blijft, kunnen de bestaande `PI_MAIN_*` secrets hergebruikt worden; pas dit pas aan naar omgeving-specifieke secrets als productie daadwerkelijk op een andere host komt. Domeinnaam (`slpsoftware.nl`) en SSL-aanpak (certbot/Let's Encrypt op de reverse-proxy-Pi) liggen al vast; er is bewust (nog) geen productie-nginx-voorbeeldconfiguratie, deze wordt later opnieuw opgebouwd zodra er een goed-werkende, foutloze versie is.
|
||||
|
||||
## Verified Build Prerequisite
|
||||
Dit plan bouwt voort op de Build and Test-stage (`construction/build-and-test/build-and-test-summary.md`): `pnpm run build` produceert een statische `dist/`-bundel zonder server-side vereisten, geschikt om direct door nginx geserveerd te worden.
|
||||
|
||||
-55
@@ -1,55 +0,0 @@
|
||||
# Voorbeeldconfiguratie voor de nginx reverse proxy op de Raspberry Pi voor de
|
||||
# PRODUCTIEOMGEVING, bereikbaar via het domein slpsoftware.nl.
|
||||
#
|
||||
# LET OP: dit bestand is nog niet in gebruik — de productie-deploy is nog niet
|
||||
# geautomatiseerd (zie deployment-plan.md's "Open Item — Productie-deploy Nog
|
||||
# Niet Geautomatiseerd"). Dit voorbeeld ligt hier alvast klaar zodat het
|
||||
# domein en SSL-certificaat (net als bij de testomgeving via certbot) bekend
|
||||
# zijn wanneer de productie-deploy wordt opgezet. Vervang <PROD_WEBSERVER_IP>
|
||||
# en <PROD_WEBSERVER_POORT> door de daadwerkelijke waarden zodra die bekend
|
||||
# zijn (mogelijk dezelfde webserver-Pi op een ander poortnummer/pad, of een
|
||||
# aparte Pi/host).
|
||||
#
|
||||
# Kopieer dit bestand handmatig naar bijvoorbeeld
|
||||
# /etc/nginx/sites-available/slpsoftware-production.conf op de reverse-proxy-Pi,
|
||||
# maak een symlink in sites-enabled, en herlaad nginx.
|
||||
#
|
||||
# SSL-certificaat aanvragen met certbot (Let's Encrypt), nadat het DNS-record
|
||||
# voor slpsoftware.nl naar het publieke IP van deze Pi wijst:
|
||||
# sudo certbot --nginx -d slpsoftware.nl -d www.slpsoftware.nl
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
server_name slpsoftware.nl www.slpsoftware.nl;
|
||||
|
||||
location /.well-known/acme-challenge/ {
|
||||
root /var/www/certbot;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name slpsoftware.nl www.slpsoftware.nl;
|
||||
|
||||
ssl_certificate /etc/letsencrypt/live/slpsoftware.nl/fullchain.pem;
|
||||
ssl_certificate_key /etc/letsencrypt/live/slpsoftware.nl/privkey.pem;
|
||||
include /etc/letsencrypt/options-ssl-nginx.conf;
|
||||
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
|
||||
|
||||
location / {
|
||||
proxy_pass http://<PROD_WEBSERVER_IP>:<PROD_WEBSERVER_POORT>;
|
||||
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
+37
-27
@@ -11,46 +11,56 @@
|
||||
# certbot (Let's Encrypt) rechtstreeks op deze reverse-proxy-Pi, bijvoorbeeld:
|
||||
# sudo certbot --nginx -d test.slpsoftware.nl
|
||||
# Zorg dat het DNS-record voor test.slpsoftware.nl al naar het publieke IP van
|
||||
# deze Pi wijst voordat je certbot draait. Certbot vult automatisch het
|
||||
# onderstaande `listen 443 ssl` server-block aan (of maakt het aan) en
|
||||
# schrijft de HTTP-server hieronder om naar een 301-redirect. Het onderstaande
|
||||
# is dus vooral illustratief voor de eindsituatie.
|
||||
|
||||
# HTTP: alleen gebruikt voor de Let's Encrypt ACME-challenge en om door te
|
||||
# verwijzen naar HTTPS. Na het draaien van certbot ziet dit block er zo uit.
|
||||
# deze Pi wijst voordat je certbot draait.
|
||||
#
|
||||
# Dit is de daadwerkelijk in gebruik zijnde configuratie op de reverse-proxy-Pi,
|
||||
# zoals door certbot gegenereerd/beheerd. Het HTTP-server-block onderaan (dat
|
||||
# doorverwijst naar HTTPS, behalve voor de ACME-challenge) en de #-commentaren
|
||||
# "managed by Certbot" zijn automatisch door certbot toegevoegd/aangepast.
|
||||
#
|
||||
# LET OP - gevonden foutje: de header hieronder heet `X-Real-IP` (met
|
||||
# koppelteken), niet `X-Real_IP` (met underscore). Een header met een
|
||||
# underscore is geen geldige/herkenbare naam voor de standaard `$http_x_real_ip`-
|
||||
# achtige verwerking; nginx stuurt de header wel door zoals opgegeven, maar
|
||||
# de ontvangende applicatie/module verwacht het koppelteken-formaat. Corrigeer
|
||||
# dit op de Pi zelf naar `X-Real-IP` zodra je de config daar aanpast.
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
server_name test.slpsoftware.nl;
|
||||
|
||||
error_log /var/log/nginx/slpsoftware-test_error.log;
|
||||
access_log /var/log/nginx/slpsoftware-test_access.log;
|
||||
|
||||
location /.well-known/acme-challenge/ {
|
||||
root /var/www/certbot;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
}
|
||||
|
||||
# HTTPS: het daadwerkelijke reverse-proxy-verkeer naar de webserver-Pi.
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name test.slpsoftware.nl;
|
||||
|
||||
ssl_certificate /etc/letsencrypt/live/test.slpsoftware.nl/fullchain.pem;
|
||||
ssl_certificate_key /etc/letsencrypt/live/test.slpsoftware.nl/privkey.pem;
|
||||
include /etc/letsencrypt/options-ssl-nginx.conf;
|
||||
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
|
||||
|
||||
location / {
|
||||
proxy_pass http://192.168.1.103:80;
|
||||
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
|
||||
listen 443 ssl; # managed by Certbot
|
||||
listen [::]:443 ssl; # managed by Certbot
|
||||
ssl_certificate /etc/letsencrypt/live/test.slpsoftware.nl/fullchain.pem; # managed by Certbot
|
||||
ssl_certificate_key /etc/letsencrypt/live/test.slpsoftware.nl/privkey.pem; # managed by Certbot
|
||||
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
|
||||
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
|
||||
|
||||
}
|
||||
|
||||
server {
|
||||
if ($host = test.slpsoftware.nl) {
|
||||
return 301 https://$host$request_uri;
|
||||
} # managed by Certbot
|
||||
|
||||
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
server_name test.slpsoftware.nl;
|
||||
return 404; # managed by Certbot
|
||||
}
|
||||
+13
-8
@@ -3,21 +3,20 @@
|
||||
#
|
||||
# Deze Pi is NIET rechtstreeks vanaf het internet bereikbaar; de andere
|
||||
# Raspberry Pi (met de nginx reverse proxy, zie reverse-proxy-nginx.conf.example)
|
||||
# stuurt inkomend verkeer door naar deze server op het interne netwerk.
|
||||
# stuurt inkomend verkeer door naar deze server op het interne netwerk (poort 80).
|
||||
#
|
||||
# Dit is de daadwerkelijk in gebruik zijnde configuratie op de webserver-Pi.
|
||||
# Kopieer dit bestand handmatig naar bijvoorbeeld
|
||||
# /etc/nginx/sites-available/slpsoftware-test.conf op de webserver-Pi,
|
||||
# maak een symlink in sites-enabled, en herlaad nginx (`sudo nginx -t && sudo systemctl reload nginx`).
|
||||
|
||||
server {
|
||||
# Alleen luisteren op het interne (LAN) IP-adres van deze Pi, niet op 0.0.0.0,
|
||||
# zodat deze poort niet per ongeluk vanaf buiten het netwerk bereikbaar is.
|
||||
listen 192.168.1.103:80;
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
server_name _;
|
||||
server_name test.slpsoftware.nl;
|
||||
|
||||
root /html/test/slpsoftware;
|
||||
root /mnt/storage1/www/html/test/slpsoftware;
|
||||
index index.html;
|
||||
|
||||
# De React-app gebruikt client-side routing (React Router), dus onbekende
|
||||
@@ -34,6 +33,12 @@ server {
|
||||
}
|
||||
|
||||
# Doorgeven van het echte client-IP en protocol, afkomstig van de reverse proxy.
|
||||
set_real_ip_from 192.168.1.0/24;
|
||||
real_ip_header X-Forwarded-For;
|
||||
# Uitgecommentarieerd: de reverse-proxy Pi geeft het echte client-IP al door
|
||||
# via de X-Forwarded-For header hierboven; deze twee directieven zouden nginx
|
||||
# dat IP ook laten gebruiken als "remote address" in de eigen access-log van
|
||||
# deze Pi. Zonder deze regels tonen de logs van deze webserver-Pi het interne
|
||||
# IP van de reverse-proxy Pi als bezoeker-IP (functioneel geen probleem, wel
|
||||
# minder nauwkeurig voor logging/analyse op deze Pi zelf).
|
||||
#set_real_ip_from 192.168.1.0/24;
|
||||
#real_ip_header X-Forwarded-For;
|
||||
}
|
||||
@@ -6,7 +6,7 @@ Sinds deze stap wordt de testomgeving automatisch gedeployed door de `deploy-tes
|
||||
## Rolling Back the Live Site (Test-omgeving)
|
||||
1. Identificeer de laatste bekend-goede commit op `master` (of een eerdere `release/*`-branch/tag) die succesvol gedeployed was.
|
||||
2. Trigger de **Continuous Integration** workflow handmatig (`workflow_dispatch`) tegen die commit/branch/tag in Gitea Actions.
|
||||
3. De `deploy-test` job uploadt automatisch de resulterende `dist/`-build naar `/html/test/slpsoftware` op de webserver-Pi, en overschrijft daarmee de huidige (foutieve) bestanden.
|
||||
3. De `deploy-test` job uploadt automatisch de resulterende `dist/`-build via SCP naar `/html/test/slpsoftware` op de webserver-Pi — dit relatieve pad staat t.o.v. de root van de SCP-gebruiker (`/mnt/storage1/www`), waardoor nginx dezelfde bestanden serveert vanaf het volledige pad `/mnt/storage1/www/html/test/slpsoftware` (zie de uitleg hierover in `deployment-instructions.md`) — en overschrijft daarmee de huidige (foutieve) bestanden.
|
||||
4. Verify de live testomgeving reflecteert de teruggedraaide versie (via het adres achter de reverse proxy).
|
||||
|
||||
## Keeping Rollback Possible
|
||||
|
||||
Reference in New Issue
Block a user