Sådan hoster du Ghost selv i 2026: MySQL, nyhedsbreve og sikkerhedskopiering af indhold

En fejlslagen Ghost-deployment går ikke altid ned. Den kan vise en login-side, selvom url-indstillingen er HTTP, eller content-volumen er blevet udskiftet. Start i stedet med en end-to-end-kontrol: gennemfør opsætningen af ejeren, udgiv et indlæg med et billede, tilmeld et medlem, og send et testnyhedsbrev via den konfigurerede e-mail.

Denne kontrol matcher Ghosts dokumenterede formål: en publishing-platform med memberships og nyhedsbreve. Den afslører også manglende dependencies, forkerte antagelser om proxien og ephemeral data tidligere, end en uptime-probe kan.

Afgræns Ghosts runtime

Tegn tre grænser omkring Ghost: ingress til port 2368, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre kræver tydelige ejere. Ghosts netværkskontrakt er MySQL 8, SMTP og valgfri object storage til sites med mange medier. Hold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv Ghost en afgrænset service credential.

Diagrammet er komplet, når en ren klient kan gennemføre opsætningen af ejeren, udgive et indlæg med et billede, tilmelde et medlem og sende et testnyhedsbrev via den konfigurerede e-mail. Registrer tids- og ressource­data for MySQL-forespørgsler, billedlagring, theme-rendering, antal medlemmer og begrænsninger hos bulk-mail-udbyderen. Hvis transaktionen fejler, identificerer den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.

Dokumentér, at Ghost overlever en udskiftning

Et container-image kan downloades igen; MySQL-databasen samt themes, billeder og indholdsfiler kan ikke. Mount /var/lib/ghost/content før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og kontrollér, at runtime-brugeren kan skrive, hvor Ghost forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at berøre produktionen. Øvelsen er kun bestået, når indlæg, medlemmer, nyhedsbreve, themes og billeder er tilbage, og et testmedlem kan åbne den gendannede publication. For databasebaseret state skal storage snapshots kombineres med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Credentials, roller og eksponerede overflader

Den applikationsspecifikke sikkerhedsrisiko er at bruge SQLite i en ikke-understøttet produktionstopologi eller at lække mail-credentials. Det operationelle svar er at beskytte Ghost Admin, opbevare mail- og database-credentials på serversiden og sætte den endelige HTTPS-URL før publicering. Gennemfør bootstrap via en begrænset route, og fjern straks den midlertidige setup-adgang bagefter.

url er konfiguration og ikke en hemmelighed; hold værdien eksplicit, mens de separate credentials, som Ghost bruger, beskyttes. Giv kun Ghost-processen adgang til de dokumenterede mounts og dependency-routes; undgå adgang til hostens root og Docker-socket. Log fejlslagen authentication og konfigurationsfejl, men redigér tokens, connection strings og brugerindhold.

Dokumentér Ghost-deploymenten end-to-end

Releaseregistreringen for Ghost skal indeholde fakta, ikke “ser fint ud”. Gem det valgte image digest, konfigurationschecksum, offentlige hostname og et tidsstemplet resultat for: gennemfør opsætningen af ejeren, udgiv et indlæg med et billede, tilmeld et medlem, og send et testnyhedsbrev via den konfigurerede e-mail. Brug eksempeldata, der ikke er fra produktionen, så kontrollen kan køres efter hver deployment.

Dokumentér to lifecycle-events separat. En udskiftning af containeren skal bevare normal drift; en ren recovery skal vise, at indlæg, medlemmer, nyhedsbreve, themes og billeder kommer tilbage, og at et testmedlem kan åbne den gendannede publication. Mål MySQL-forespørgsler, billedlagring, theme-rendering, antal medlemmer og begrænsninger hos bulk-mail-udbyderen, mens kontrollerne kører, og gem resultatet som det forventede niveau for denne version.

Test også en afvist eller ugyldig tilstand: Afvis midlertidigt testidentitetens adgang til MySQL 8, SMTP og valgfri object storage til sites med mange medier. Ghost skal fejle på en måde, der kan diagnosticeres, og må ikke overskrive sund state. Gendan den gyldige tilstand, kør eksemplet igen, og vedhæft de relevante redigerede logs. Disse artefakter giver en fremtidig rollback-beslutning et konkret grundlag.

Et Docker-baseline for Ghost

Hold den indledende Ghost-invocation tilstrækkeligt reproducerbar til, at den kan gennemgås i et pull request.

docker run -d \
  --name ghost \
  --restart unless-stopped \
  -p 127.0.0.1:2368:2368 \
  -v ghost-data:/var/lib/ghost/content \
  -e url=https://app.example.com \
  -e database__client=mysql \
  -e database__connection__host=mysql.internal \
  -e database__connection__user=ghost \
  -e database__connection__password=replace-with-a-strong-database-password \
  -e database__connection__database=ghost \
  ghost:latest

Stol ikke på latest, når der først findes rigtige data. Registrer det fungerende digest, container-brugeren og ejerskabet af mountet. Følg applikationsloggen gennem en komplet test — gennemfør opsætningen af ejeren, udgiv et indlæg med et billede, tilmeld et medlem, og send et testnyhedsbrev via den konfigurerede e-mail — og notér eventuelle migrations, før routen sættes bag produktions-trafik.

TLS er nemt; genererede URL'er er ikke

Sæt url til det endelige HTTPS-domæne før publicering. Send det valgte hostname til containerport 2368, videresend den oprindelige host og HTTPS-scheme, og undgå at publicere en ekstra direkte origin.

Test Ghost fra en ren ekstern klient. Adskil ingress-fejl fra den kendte applikationsgrænse — url-indstillingen er HTTP, eller content-volumen er blevet udskiftet. En certifikat-, DNS- eller 502-fejl hører til routing; en request, der når Ghost og fejler senere, hører til application state, kapacitet eller et understøttende krav. Guiden til TLS med custom domain dækker den første gruppe.

Kapacitets- og upgrade-kontroller

Kapacitetstests skal udøve MySQL-forespørgsler, billedlagring, theme-rendering, antal medlemmer og begrænsninger hos bulk-mail-udbyderen — ikke gentagne requests til /. Kør scenariet “gennemfør opsætningen af ejeren, udgiv et indlæg med et billede, tilmeld et medlem, og send et testnyhedsbrev via den konfigurerede e-mail” med realistisk concurrency, og registrer latency, error rate og vækst i storage.

Upgrade-planlægningen skal tage højde for denne risiko: Ghost-migrations, forventninger til Node-runtime og custom themes skal testes på et cloned site. Test den nye release med repræsentativt input, gentag derefter acceptance-transaktionen, og sammenlign resultatet. Hvis url-indstillingen er HTTP, eller content-volumen er blevet udskiftet, skal du registrere den fejlslagne transaktion og undersøge den første involverede grænse i stedet for at antage, at ingress er årsagen.

Flyt det gentagelige infrastrukturarbejde til Dockup

Routing, certifikater, serviceudskiftning og tilknyttet storage er rimelige automatiseringsmål. Dockup håndterer dette for Ghost og kan provisionere den tilknyttede managed database eller oprette forbindelse til services på kundens egen server.

Det, Dockup ikke bør opfinde, er Ghosts trust policy. Efter deployment skal du sætte url til det endelige HTTPS-domæne før publicering, håndhæve denne grænse — beskyt Ghost Admin, opbevar mail- og database-credentials på serversiden, og sæt den endelige HTTPS-URL før publicering — og verificere resultatet af dette scenarie: gennemfør opsætningen af ejeren, udgiv et indlæg med et billede, tilmeld et medlem, og send et testnyhedsbrev via den konfigurerede e-mail. Resultatet er infrastruktur med ét klik og en applikationsspecifik acceptance-test.

Ofte stillede spørgsmål

Hvad kræver Ghost til en produktionsdeployment?

Route Ghost-containeren på port 2368 gennem én HTTPS-origin. Det understøttende netværkskrav er MySQL 8, SMTP og valgfri object storage til sites med mange medier. Kald ikke Ghost klar, før du kan gennemføre opsætningen af ejeren, udgive et indlæg med et billede, tilmelde et medlem og sende et testnyhedsbrev via den konfigurerede e-mail.

Hvilke Ghost-data skal med i en sikkerhedskopi?

Gør /var/lib/ghost/content persistent, og inkludér MySQL-databasen samt themes, billeder og indholdsfiler i det samme recovery-manifest. En ren Ghost-restore er kun bestået, når indlæg, medlemmer, nyhedsbreve, themes og billeder er tilbage, og et testmedlem kan åbne den gendannede publication.

Kræver Ghost HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Ghost-origin, og hold port 2368 på den interne route. Anvend Ghost-indstillingen korrekt: Sæt url til det endelige HTTPS-domæne før publicering. For Ghost beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet klientadfærd, der afhænger af origin.

Hvordan bør en Ghost-upgrade testes?

Gendan den aktuelle Ghost-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi Ghost-migrations, forventninger til Node-runtime og custom themes skal testes på et cloned site. Behold det tidligere Ghost-image, indtil dets data-migration- og rollback-grænse er forstået.