Hallinnoitu PostgreSQL Dockupissa: kattava opas

Hallinnoitu PostgreSQL tarjoaa sovellukselle valmistellun tietokannan, jonka elinkaaren hallinta on erotettu palvelun containerista. Dockup tukee luontia, käynnistystä ja pysäytystä, lokeja, koon tarkastelua, varmuuskopioita, palautusta alustan kautta, vain luku -käyttäjiä, noden vaihtoa ja private networking -yhteyksiä.

Keskeinen toimintaperiaate on erottaminen: sovelluksen image on kertakäyttöinen, PostgreSQL-data säilyy, tunnistetiedot ovat secret-arvoja ja tietokannan palautus on testattava erillään sovelluksen rollbackista.

Miten hallinnoitu PostgreSQL-tietokanta luodaan?

Valitse haluamasi workspace ja luo sitten tietokanta:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Listaa tietokannat ja varmista täsmällinen slug sekä tila:

dockup db list --json

Tietokantaoperaatioissa käytetään project/db-kohteita:

dockup db size production/main-db --json

Odota provisioning-prosessin valmistumista ennen sovelluksen liittämistä. Älä päättele hostnamea, porttia, käyttäjänimeä tai salasanaa tietokannan nimestä.

Free-plan sallii kolme tietokantaa yhdessä workspacessa ja sisältää 10 dollarin aloitussaldon. Maksulliset planit — Hobby 5 dollarilla, Pro 20 dollarilla kuukaudessa — sallivat rajattoman määrän tietokantoja, workspaceja ja deploymenteja. CPU:n, RAM-muistin ja levyn käyttö mitataan minuuttikohtaisesti sisältyvää käyttösaldoa vasten.

Miten sovellus yhdistetään turvallisesti?

Hae tietokannan yhteystiedot Dockupin tietokantakäyttöliittymästä ja käsittele connection stringiä secret-arvona. Älä lisää sitä repositoryyn tai agentin transkriptiin.

Aseta se palvelulle:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Redeploy on välttämätön, koska käynnissä oleva prosessi sai ympäristönsä käynnistyksen yhteydessä. Tallennettu arvo maskataan ympäristöasetuksia luettaessa.

Määritä sovelluksen connection pooling harkiten. Liian monet suuret poolit sisältävät application workerit voivat kuluttaa kaikki tietokantayhteydet loppuun, vaikka CPU:n ja muistin käyttö näyttäisi terveeltä. Määritä poolin koko työkuorman ja tietokannan kapasiteetin perusteella, älä frameworkin hyväksymän enimmäismäärän mukaan.

Testaa uusi yhteys deployn jälkeen. Health endpoint voi vahvistaa, että HTTP-prosessi on käynnissä, mutta se ei todista, että uusi tietokantasessio voidaan muodostaa.

Environment variables and secrets -oppaassa käsitellään tunnistetietojen kierrätystä ja maskattua tulostetta.

Miten private networking suojaa PostgreSQL-liikennettä?

Ota käyttöön projektille private network:

dockup network enable production --json

Projektin palvelut ja hallinnoidut tietokannat saavat pysyvät <slug>.internal-hostname-nimet. Redeployaa sovellus, jotta se saa injektoidut sisäiset yhteysmuuttujat.

Poista tietokannan julkinen listener ja tee siitä vain private networkin kautta käytettävä:

dockup db private production/main-db --json

Palauta julkinen ja private access tarvittaessa:

dockup db private production/main-db --off --json

Tietokannan muuttaminen vain private networkin kautta käytettäväksi luo sen containerin uudelleen, mutta säilyttää datan. Ajoita ja varmista muutos tietokantaoperaationa, älä harmittomana DNS-muutoksena.

Private networking hallitsee reittiä, kun taas PostgreSQL-tunnistetiedot hallitsevat identiteettiä ja valtuutusta. Säilytä molemmat. Erilliset projektit eivät voi tavoittaa toisiaan, koska jokaisella projektilla on oma verkkonsa.

Private networking and internal domains -artikkelissa kuvataan koko topologia.

Miten PostgreSQL:n varmuuskopiointi ja palautus toimivat?

Listaa olemassa olevat varmuuskopiot:

dockup db backups production/main-db --json

Käynnistä palvelimella tehtävä varmuuskopio:

dockup db backup production/main-db --json

Backup-komento luo tietokannan rakenteen ja sisällön huomioivan varmuuskopion raakavolumen hot copyn sijaan. Kirjaa varmuuskopion ID, luontiaika, tietokantaversio ja syy.

Dockup tukee hallinnoitujen tietokantavarmuuskopioiden palauttamista alustan kautta. Nykyinen CLI-viite ei dokumentoi dockup db restore -komentoa, joten tämä opas ei keksi sellaista. Tee palautus tuetusta Dockup-käyttöliittymästä, valitse täsmällinen varmuuskopio, hanki tuotantohyväksyntä ja varmista lopputulos.

Palautussuunnitelman tulee sisältää:

1. Palautuspiste ja arvioitu menetettävien kirjoitusten ajanjakso.
2. Sovelluksen kirjoitusten jäädytys tai ylläpitotila.
3. Tietokannan ja extensionien yhteensopivuus.
4. Nykytilan tuore varmuuskopio silloin, kun siitä on hyötyä.
5. Palautuksesta vastaava henkilö ja hyväksyntä.
6. Sovelluksen uudelleenyhdistäminen ja smoke test.
7. Auditointi- ja incident-tiedot.

Varmuuskopioita ei ole todistettu toimiviksi ennen kuin palautusharjoitus onnistuu. Testaa prosessi non-production-tietokannalla tai hyväksytyssä palautusympäristössä.

Säilytä varmuuskopiot hyväksytyn policy-määrityksen mukaisesti. Poista vanhentuneet palautuspisteet vain tuetun tietokantakäyttöliittymän kautta, kun olet varmistanut, ettei mikään palautus- tai compliance-vaatimus enää perustu niihin.

Miten vain luku -käyttäjät toimivat PostgreSQL:ssä?

Ylimääräiset vain luku -käyttäjät ovat hyödyllisiä analytiikkaan, tukitutkimuksiin, preview-deploymenteihin ja työkaluille, joiden on tehtävä kyselyitä ilman kirjoitusoikeutta.

Listaa käyttäjät:

dockup db users production/main-db --json

Luo käyttäjä labelilla:

dockup db user-add production/main-db \
  --label analytics \
  --json

Tallenna luotu tunnistetieto turvallisesti luonnin aikana äläkä toista sitä agentin vastauksessa. Peruuta ylimääräisen käyttäjän käyttöoikeus tuetun tietokannan käyttäjienhallintakäyttöliittymän kautta, kun sen käyttötarkoitus päättyy.

Vain luku -oikeus tietokannan permission-tasolla on vahvempi kuin query-työkalulle annettu ohje ”älä kirjoita”. Se sallii silti pääsyn luettavissa olevaan tuotantodataan, joten yksityisyyttä ja least privilege -periaatetta koskevia sääntöjä on noudatettava.

Dockup luo automaattisesti vain luku -käyttäjän pull requestia tai branch-preview’ta varten private networking -projektissa. Preview voi käyttää samaa tuotantotietokantaa osoitteessa <slug>.internal ja lukea dataa ilman kirjoitusoikeutta.

Miten kokoa, lokeja ja sijoittelua valvotaan?

Tarkastele levyllä käytettyä kokoa:

dockup db size production/main-db --json

Tarkastele sovelluksen runtime-lokeja yhteysvirheiden löytämiseksi paljastamatta salasanoja tai kokonaisia connection stringejä:

dockup logs production/api --json

Tietokannan ylläpito voi tehdä siitä riippuvaiset palvelut hetkellisesti saavuttamattomiksi. Ajoita tilaa muuttavat operaatiot, vaadi niiden tekemiseen nimenomainen operatiivinen hyväksyntä ja kerro vaikutuksista ennen toimenpiteitä.

Siirrä tietokanta nodejen välillä kohdenoden ID:n avulla:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

Migraatio on stateful-operaatio. Varmista varmuuskopioiden tila, ylläpitoa koskevat odotukset, private-network-yhteydet ja sovelluksen tarkistukset siirron jälkeen.

Hallinnoidun PostgreSQL:n tuotantotarkistuslista

Täydellisessä runbookissa kirjataan:

Alue	Vaadittu näyttö
Identiteetti	Täsmällinen project/db-kohde
Yhteydet	Salainen connection string ja testattu uusi sessio
Verkko	Julkinen, private tai vain private -policy
Käyttöoikeudet	Sovelluksen rooli ja nimetyt vain luku -käyttäjät
Kapasiteetti	Nykyinen koko ja kasvun tarkastelu
Varmuuskopiot	Viimeaikaisten varmuuskopioiden ID:t ja säilytys
Palautus	Onnistunut palautusharjoitus
Operaatiot	Käynnistyksen, pysäytyksen, restartin ja migraation hyväksyntä
Auditointi	Tietokantamuutokset voidaan jäljittää tekijään

Sovelluksen deployment rollback ei palauta PostgreSQL:ää. Tietokannan palautus ei automaattisesti peruuta sovelluskoodia. Koordinoi molemmat vain silloin, kun skeeman yhteensopivuus sitä edellyttää.

Laajempia skaalauspäätöksiä varten lue database scaling strategies. Täsmälliset komennot löytyvät Dockup CLI reference -dokumentaatiosta.

Suunnittele skeemamigraatiot deployta ja rollbackia varten

Sovelluksen deployment ja tietokannan skeemamuutos tapahtuvat eri aikatauluilla. Turvallinen migraatio on yleensä taaksepäin yhteensopiva vähintään yhden release-ikkunan ajan: lisää nullable-sarake ennen sen pakolliseksi määrittämistä, deployaa koodi, joka käsittelee molempia skeemoja, backfillaa tiedot hallitusti ja poista vanha rakenne myöhemmin.

Älä tee health checkistä pitkää migraatiota suorittavaa. Jos sovellus käynnistää useita replikoita, varmista, että vain yksi migration runner voi ottaa muutoksen vastuulleen. PRO containerin exec-komento voi suorittaa one-shot-komennon ja välittää sen todellisen exit coden:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Käytä sitä vain, kun migraatiokomento on tarkistettu ja palvelu on käynnissä tuetulla pääpalvelimella. Tallenna stdout, stderr ja exit code. Onnistunut sovellusdeploy ei tarkoita, että epäonnistunut migraatio voidaan jättää huomiotta.

Kierrätä tietokannan tunnistetiedot ilman käyttökatkoa

Luo uusi tunnistetieto tai vain luku -käyttäjä, päivitä käyttävän palvelun secret, redeployaa palvelu ja varmista uusi yhteys ennen vanhan tunnistetiedon peruuttamista. Olemassa olevat connection poolit voivat peittää uuden salasanan virheellisyyden siihen asti, kunnes ne yhdistävät uudelleen.

Käytä ensisijaisen sovellustunnuksen vaihtamiseen tuettua Dockup-käyttöliittymää ja tietokannan policy-määritystä. Luo ylimääräistä analytiikkakäyttäjää varten nimetty vain luku -tili ja jaa se vain hyväksytylle käyttäjälle.

Rotation-tietueessa tulee olla käyttäjän label, käyttävät palvelut, deployment-ID:t, varmennuskysely, peruutusaika ja auditointitapahtuma — ei koskaan salasanaa.

Seuraa kasvua ennen skaalausta

Tietokannan koko on yksi mittari:

dockup db size production/main-db --json

Yhdistä se sovelluksen query-latenssiin, yhteyksien määrään, cachen toimintaan, varmuuskopioiden kestoon ja tallennustilan kasvuun. Suurempi CPU- tai muistiresurssi ei välttämättä korjaa puuttuvia indeksejä tai rajoittamattomia queryjä.

Tutustu database scaling strategies -ohjeeseen ennen nodejen vaihtamista tai resurssien kasvattamista. Hallinnoitu PostgreSQL vähentää provisioningiin tarvittavaa työtä, mutta skeeman ja queryjen suunnittelu on edelleen sovelluksen vastuulla.

Erota käytettävyys ja oikeellisuus

Käynnissä oleva tietokantacontainer todistaa, että PostgreSQL on käytettävissä, ei sitä, että sovelluksen queryt toimivat oikein. Sisällytä deployn jälkeiseen varmennukseen riskitön uusi yhteys ja edustava lukuoperaatio. Kirjoitustestissä käytä erillistä transaktiota tai testitietuetta, jonka voi poistaa turvallisesti.

Hallinnoidun PostgreSQL:n runbookissa tulee myös määritellä, aiheuttavatko replikat, analytiikkakäyttäjät, previewt tai background workerit lisäkuormaa yhteyksille.

Tarkista PostgreSQL:n käyttöoikeudet säännöllisesti

Listaa ylimääräiset käyttäjät, varmista, että jokaisella labelilla on aktiivinen omistaja, ja poista vanhentuneet tilit. Tämä yksinkertainen tarkistus estää hallinnoidun PostgreSQL:n lukuoikeuksien kertymisen previewiden, analytiikkaprojektien tai tukitutkimusten päätyttyä.

Aloita varmennettavalla deploymentilla

Luo non-production PostgreSQL -tietokanta, yhdistä testipalvelu maskatun secret-arvon kautta, tee varmuuskopio ja suorita palautusharjoitus ennen tuotantoon siirtymistä.

Aloita maksutta osoitteessa app.dockup.ai. Free-plan maksaa 0 dollaria kuukaudessa, sisältää 10 dollarin aloitussaldon ja tukee yhtä workspacea, kolmea tietokantaa ja kolmea deploymentia.

UKK

Mitä hallinnoituja tietokantatyyppejä Dockup tukee?

Dockup tukee hallinnoituina tietokantoina PostgreSQL:ää, MySQL:ää, MongoDB:tä ja Redis:iä.

Miten sovelluksen tulisi saada PostgreSQL-yhteyden connection string?

Käsittele connection stringiä secret-ympäristömuuttujana, aseta se täsmälliselle palvelulle ja redeployaa palvelu, jotta uusi container saa sen käyttöönsä.

Voiko Dockup luoda vain luku -käyttäjän PostgreSQL:ään?

Kyllä. Database user-add -komento luo ylimääräisen vain luku -käyttäjän ja palauttaa sen salasanan kerran luonnin yhteydessä.

Onko dockup db restore CLI -komento dokumentoitu?

Nykyinen CLI-viite ei dokumentoi sellaista. Dockup tukee varmuuskopioiden palautusta alustan käyttöliittymän kautta, joten käytä tätä tuettua tapaa sen sijaan, että keksisit flagin tai komennon.

Palauttaako sovelluksen rollback PostgreSQL-tietokannan?

Ei. Sovelluksen deployment-historia ja tietokannan varmuuskopiohistoria ovat erillisiä palautusjärjestelmiä, ja niitä on koordinoitava silloin, kun skeemamuutokset edellyttävät molempia.