Docker Compose

Kjør en komplett, gratis Status200-instans på én Linux-server med Docker Compose. Denne siden tar deg fra en ny server til en kjørende instans, og dekker deretter HTTPS, herding for produksjon, sikkerhetskopier, oppdateringer og fjerning. Vil du heller jobbe med Status200s egen kode, se Lokal utvikling.

Slik fungerer det#

Docker Compose kjører hver del av Status200 som en container på serveren din. All trafikk kommer inn gjennom containeren ingress, som sender den videre til app. Appen lagrer dataene sine i PostgreSQL, ClickHouse og Valkey. En medfølgende probe kjører monitorenes sjekker og rapporterer tilbake gjennom ingressen.

For produksjon i stor skala, eller når du trenger høy tilgjengelighet, bruk i stedet Helm-chartet på Kubernetes: Docker Compose kjører én kopi av hver tjeneste på én server.

Krav#

Velg størrelsen på serveren etter hva du skal kjøre på den. Det er telemetrien (logger, metrikker, traces) som bestemmer minne og disk; se Dimensjonering og kapasitetsplanlegging når du kjenner volumene dine.

Minimum for et homelab passer for personlig og eksperimentell bruk — noen kjører Status200 på en Raspberry Pi.

Du trenger også:

• Docker med tillegget Docker Compose v2 (kommandoen docker compose).
• Git, for å hente Status200.
• Node.js og npm, som kjører skriptene npm start og npm run update som pakker inn Docker Compose.
• Port 80 og 443 ledige på serveren. Tabellen nedenfor viser hver port Status200 bruker på verten.

Det finnes også en videogjennomgang av installasjonen.

Installer Status200#

1. Klon release-grenen#

   Grenen release inneholder filene for den nyeste releasen.

   Bash

   git clone --depth 1 --single-branch --branch release https://git.wilix.dev/status200/status200.git
   cd oneuptime

2. Opprett config.env#

   Alle innstillingene til Status200 ligger i config.env. Start med eksemplet:

   Bash

   cp config.example.env config.env

3. Angi vertsnavnet#

   Åpne config.env og sett HOST til domenenavnet eller IP-adressen folk skal bruke for å nå Status200, uten http://. Behold localhost bare for å prøve Status200 på din egen datamaskin.

   config.envINI

   HOST=status200.example.com

4. Generer tilfeldige hemmeligheter#

   Eksempelfilen har plassholderhemmeligheter som er offentlige på GitHub. Erstatt hver av dem med sin egen tilfeldige verdi:

   Bash

   while grep -q "please-change-this-to-random-value" config.env; do
     sed -i "0,/please-change-this-to-random-value/{s/please-change-this-to-random-value/$(openssl rand -hex 32)/}" config.env
   done
   grep -c "please-change-this" config.env

   Den siste kommandoen skriver ut 0: Det er ingen plassholder igjen. Løkken bruker GNU sed, som alle Linux-servere har. Dette er innstillingene den fyller ut:

   Innstilling	Hva den beskytter
   ONEUPTIME_SECRET	Kall mellom Status200s egne tjenester.
   ENCRYPTION_SECRET	Hemmelighetene Status200 lagrer, som integrasjonstokener og SMTP-passord, og påloggingstokenene den utsteder.
   DATABASE_PASSWORD, CLICKHOUSE_PASSWORD, VALKEY_PASSWORD	De tre datalagrene.
   REGISTER_PROBE_KEY	Registrering av prober hos instansen din.
   GLOBAL_PROBE_1_KEY, GLOBAL_PROBE_2_KEY	De globale probene Docker Compose kan kjøre (probe-1 kjører som standard).
   STATUS200_RUNNER_KEY	Den medfølgende Runneren.
   GLOBAL_RUNNER_KEY	Den medfølgende globale Runneren, som kjører JavaScript-trinnene til alle prosjekter.

   Viktig

   Angi hemmelighetene før første start, og behold dem etterpå. PostgreSQL tar bare passordet sitt når den oppretter databasen, og endrer du ENCRYPTION_SECRET senere, blir hver verdi som er kryptert med den gamle, uleselig. Er DATABASE_PASSWORD fortsatt plassholderen ved første start, gir npm start den en tilfeldig verdi før PostgreSQL oppretter databasen sin.

5. Start Status200#

   npmDocker CLI

   npm

   Bash

   npm start

   Docker CLI

   Bash

   (export $(grep -v '^#' config.env | xargs) && docker compose up --remove-orphans -d)

   Første start tar flere minutter: Docker laster ned imagene, og Status200 oppretter databasene sine. npm start venter til hver del svarer, og avslutter med Status200 is up!

6. Opprett den første kontoen#

   Åpne http:// etterfulgt av HOST (for eksempel http://localhost) og registrer deg. Den første kontoen på en ny instans blir hovedadministratoren, som kan åpne Admin Dashboard på /admin.

   Alle som kan nå siden, kan registrere seg etter deg. For å hindre det åpner du Admin Dashboard, går til Innstillinger > Autentisering og slår av Tillat registrering. Personer du inviterer til et prosjekt, kan fortsatt opprette kontoen sin.

Sett opp HTTPS#

Status200 leverer vanlig HTTP til du velger én av to måter å legge til HTTPS på:

Hvis du legger statussider eller dashbord på egne domener, er det enklest å la Status200 håndtere TLS: Ingressen bestiller og leverer selv sertifikatene for de domenene.

Med HTTP_PROTOCOL=https bygger Status200 HTTPS-lenker, holder påloggingsinformasjonskapsler på HTTPS og ber nettlesere om å nå HOST-en din bare over HTTPS. En nettleser holder seg til det i ett år, på alle porter for det navnet, så hvis HOST en dag må svare over vanlig HTTP igjen, setter du HSTS_MAX_AGE_SECONDS=0 i config.env en stund før: Nettlesere glemmer regelen ved neste besøk.

La Status200 hente et sertifikat#

1. Pek domenet ditt mot serveren#

   Opprett en DNS-post A (eller AAAA for IPv6) for domenet ditt, med serverens offentlige IP-adresse som verdi. Med en AAAA-post slår du også på IPv6 for Status200: se Besøkendes adresser.

2. Slå på henting av sertifikater#

   Angi disse verdiene i config.env:

   config.envINI

   HOST=status200.example.com
   PROVISION_SSL=true
   HTTP_PROTOCOL=https

   HOST må være et domenenavn: Status200 kan ikke få et sertifikat for en IP-adresse eller for localhost.

3. Start på nytt med de nye innstillingene#

   Bash

   npm start

4. Åpne instansen over HTTPS#

   Åpne https://status200.example.com. Status200 bestiller sertifikatet når den starter, sjekker det deretter hver time og fornyer det når det er mindre enn 30 dager igjen. Til det første sertifikatet kommer, vanligvis i løpet av noen minutter, leverer ingressen et midlertidig selvsignert sertifikat, og nettleseren advarer deg.

Bruk din egen reverse proxy#

Disse stegene kjører proxyen på samme server som Status200. Kjører proxyen din på en annen maskin, hopper du over det første steget, peker proxyen mot port 80 på denne serveren og lar bare proxyen nå port 80 og 443 med brannmuren til skyleverandøren din: en besøkende som når Status200 utenom proxyen, kan velge adressen Status200 teller vedkommende etter.

1. Flytt ingressen bort fra port 80 og 443#

   Proxyen trenger port 80 og 443, så flytt ingressen til andre porter, publisert bare på serverens loopback-adresse 127.0.0.1, slik at besøkende bare når Status200 gjennom proxyen din. Proben og Runneren bruker vertens nettverk og når Status200 gjennom http://localhost, så de flytter med:

   config.envINI

   ONEUPTIME_HTTP_PORT=127.0.0.1:8080
   STATUS_PAGE_HTTPS_PORT=127.0.0.1:8443
   GLOBAL_PROBE_1_STATUS200_URL=http://localhost:8080
   ONEUPTIME_RUNNER_STATUS200_URL=http://localhost:8080

2. Fortell Status200 at den står bak en proxy#

   config.envINI

   HOST=status200.example.com
   HTTP_PROTOCOL=https
   PROVISION_SSL=false
   TRUSTED_PROXY_HOPS=2

   HTTP_PROTOCOL=https får lenkene Status200 bygger til å bruke HTTPS. TRUSTED_PROXY_HOPS=2 teller proxyen din og Status200s ingress, så Status200 leser den besøkendes ekte adresse for IP-tillatelseslister og hastighetsbegrensninger. Legg til én for hver ekstra proxy som legger til i X-Forwarded-For, som et CDN eller en lastbalanserer.

3. Start Status200 på nytt på de nye portene#

   Bash

   (export $(grep -v '^#' config.env | xargs) && docker compose up --remove-orphans -d)
   bash Tests/Scripts/status-check.sh localhost:8080

   npm start sjekker http://localhost på port 80, der proxyen din skal ligge, så sjekk den nye porten selv. Skriptet avslutter med Status200 is up!

4. Konfigurer proxyen#

   CaddyNginx

   Caddy

   Caddyfile

   status200.example.com {
       reverse_proxy localhost:8080
   }

   Caddy henter og fornyer sertifikatet selv, omdirigerer HTTP til HTTPS og slipper WebSocket-tilkoblinger gjennom. Last inn Caddy på nytt etter at du har endret filen, for eksempel med sudo systemctl reload caddy.

   Nginx

   /etc/nginx/conf.d/status200.confNginx

   map $http_upgrade $status200_connection_upgrade {
       default upgrade;
       ""      close;
   }
   
   server {
       listen 80;
       server_name status200.example.com;
       return 301 https://$host$request_uri;
   }
   
   server {
       listen 443 ssl;
       server_name status200.example.com;
   
       ssl_certificate     /etc/letsencrypt/live/status200.example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/status200.example.com/privkey.pem;
   
       # The limits Status200's own ingress uses.
       client_max_body_size 50M;
       proxy_read_timeout 300s;
       proxy_send_timeout 300s;
   
       proxy_http_version 1.1;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection $status200_connection_upgrade;
   
       location / {
           proxy_pass http://127.0.0.1:8080;
       }
   
       # MCP clients keep a stream open.
       location /mcp {
           proxy_pass http://127.0.0.1:8080;
           proxy_buffering off;
           proxy_read_timeout 86400s;
           proxy_send_timeout 86400s;
       }
   }

   Sertifikatbanene er der Certbot legger et sertifikat fra Let's Encrypt; bruk banene til ditt eget sertifikat hvis det kommer fra et annet sted. Sjekk filen og last inn Nginx på nytt med sudo nginx -t && sudo systemctl reload nginx.

   Begge sender X-Forwarded-Proto, som forteller Status200 at en besøkende kom over HTTPS. Alle andre proxyer må også sende den, ellers holdes ikke påloggingsinformasjonskapslene for statussider og dashbord på egne domener på HTTPS.

5. Åpne instansen gjennom proxyen#

   Åpne https://status200.example.com. Du skal se påloggingssiden til Status200, levert med proxyens sertifikat.

Besøkendes adresser#

Status200 teller hver besøkende etter adressen vedkommende kobler til fra: påloggingsgrensene, de andre grensene per adresse og IP-tillatelseslistene for statussider og dashbord leser den alle. To oppsett trenger en innstilling for at den adressen skal være den besøkendes egen:

Uten IPv6 på Status200s nettverk sender Docker hver besøkende som kommer over IPv6 videre til Status200 fra én adresse av sin egen, og Status200 teller dem alle som én besøkende: én persons mislykkede pålogginger kan låse de andre ute. Å slå på IPv6 krever Docker Engine 27 eller nyere (docker version viser din).

1. Slå på IPv6#

   Opprett docker-compose.override.yml ved siden av docker-compose.yml, eller legg dette til i den du har; npm start og npm run update leser den:

   docker-compose.override.ymlYAML

   networks:
     oneuptime:
       enable_ipv6: true

2. Start Status200 på nytt#

   Bash

   npm stop
   npm start

   Status200 stopper og starter igjen med IPv6 på nettverket sitt. Dataene dine beholdes. Docker kan ikke fjerne et nettverk som en egen container fortsatt er koblet til, for eksempel en reverse proxy: koble den fra Status200s nettverk først, og koble den til igjen etterpå. Stopper npm start med has active endpoints, kobler du den fra og kjører npm stop og npm start på nytt.

3. Sjekk nettverket#

   Bash

   docker network ls --quiet --filter name=_oneuptime | xargs docker network inspect | grep EnableIPv6

   Den skriver ut "EnableIPv6": true,.

Når flere personer logger på fra den samme private nettverksadressen, sier siden Status200-tilstand i Admin Dashboard fra, med innstillingen som endrer det.

Sjekkliste for produksjon#

Docker Compose kjører én kopi av hver tjeneste på én server, noe som passer for små team og homelab. Gå gjennom denne listen før du stoler på det.

Bytt databasepassordet#

PostgreSQL beholder passordet den ble opprettet med, så endrer du bare DATABASE_PASSWORD i config.env, stenger du Status200 ute fra databasen sin. For å gi en installasjon som startet med plassholderen et eget passord, endrer du det i PostgreSQL og i config.env samtidig, og starter deretter Status200 på nytt:

NEW_PASSWORD=$(openssl rand -hex 32) &&
  (export $(grep -v '^#' config.env | xargs) && docker compose exec -T postgres psql -U "$DATABASE_USERNAME" -d "$DATABASE_NAME" -c "ALTER USER \"$DATABASE_USERNAME\" PASSWORD '$NEW_PASSWORD'") &&
  sed -i "s/^DATABASE_PASSWORD=.*/DATABASE_PASSWORD=$NEW_PASSWORD/" config.env
npm start

Har du satt DATABASE_BACKUP_PASSWORD og DATABASE_RESTORE_PASSWORD, gir du dem også den nye verdien.

Sikkerhetskopiering og gjenoppretting#

PostgreSQL inneholder alt du konfigurerer: monitorer, hendelser, statussider, brukere. npm run backup dumper det til en fil i mappen Backups.

1. Gi sikkerhetskopiskriptet databasepassordet#

   Sett DATABASE_BACKUP_PASSWORD i config.env til verdien av DATABASE_PASSWORD. Skriptet leser config.env som ren tekst, så ${DATABASE_PASSWORD} som følger med, blir aldri fylt ut.

2. Kjør sikkerhetskopieringen#

   Bash

   npm run backup

   Det ber om sudo-passordet ditt og skriver Backups/db-<day of the month>.backup, slik at daglige sikkerhetskopier erstatter dem fra en måned tidligere. Kjør det minst én gang om dagen.

3. Kopier sikkerhetskopiene bort fra serveren#

   En sikkerhetskopi på samme disk som databasen overlever ikke at den disken går tapt.

Bare selve serveren når PostgreSQL: Den svarer på port 5400 på 127.0.0.1. For å ta sikkerhetskopi av den fra en annen maskin åpner du en SSH-tunnel fra den maskinen, og kobler deretter til maskinens egen port 5400:

ssh -N -L 5400:127.0.0.1:5400 you@status200.example.com

services:
  postgres:
    ports:
      - "10.0.0.5:5401:5432"

ClickHouse holder telemetrien din i Docker-volumet status200_clickhouse, og ingen skript sikkerhetskopierer det. Hvis du må beholde den telemetrien, sikkerhetskopierer du volumet med et ClickHouse-verktøy som clickhouse-backup, eller kopierer det mens Status200 er stoppet.

For å gjenopprette PostgreSQL setter du verdiene DATABASE_RESTORE_* i config.env: DATABASE_RESTORE_PASSWORD til verdien av DATABASE_PASSWORD, som for sikkerhetskopier, og DATABASE_RESTORE_FILENAME til sikkerhetskopien som skal gjenopprettes, for eksempel db-31.backup. Kjør deretter bash restore.sh. Databasen det gjenoppretter til, må allerede finnes; i en kjørende installasjon gjør den det.

Oppdater Status200#

Ta sikkerhetskopi først, og kjør deretter:

git checkout release
git pull
npm run update

npm run update ber om sudo-passordet ditt, legger til nye innstillinger fra config.example.env i config.env (dine egne verdier blir værende), henter de nye imagene og starter Status200 på nytt. Som npm start avslutter det med Status200 is up!

Å gå over til en ny hovedversjon (fra 13 til 14, for eksempel) kan kreve mer: Les Oppgradering av Status200 før du begynner.

APP_TAG=release i config.env henter alltid den nyeste releasen av Community Edition. For å bli på én versjon setter du APP_TAG til nummeret, for eksempel 14.0.22. For Enterprise Edition er taggene enterprise-release og enterprise-14.0.22.

Avinstaller Status200#

Stopp Status200 og fjern containerne og nettverket:

npm run down

Dataene dine blir værende i volumene status200_postgres og status200_clickhouse, og mappen oneuptime beholder config.env og sikkerhetskopiene dine. For å slette dataene også:

(export $(grep -v '^#' config.env | xargs) && docker compose down --volumes --remove-orphans)

Slett deretter mappen oneuptime.

Feilsøking#

sudo usermod -aG docker $USER

npm run ps
npm run logs

(export $(grep -v '^#' config.env | xargs) && docker compose logs app) | grep -A 5 CoreSSL

Neste steg#