Baserow'n itsehostaus vuonna 2026: data, URL-osoitteet ja varmuuskopiot yhdessä

Baserow-kontti voi näyttää olevan kunnossa, vaikka käyttäjille tärkeä toiminto ei toimisi. Baserow'ssa tämä piilevä vika tarkoittaa yleensä sitä, että julkinen URL-osoite muuttuu sen jälkeen, kun käyttäjät ovat luoneet jako- ja callback-linkkejä. Tässä oppaassa hyväksymistestinä pidetään seuraavaa kokonaisuutta: ”luo tietokanta ja näkymä, tuo CSV-tiedosto, muokkaa rivejä kahdesta istunnosta ja lataa tiedosto ennen all-in-one-pinon uudelleenkäynnistystä”. Käyttöönotto suunnitellaan tämän lopputuloksen pohjalta.

Baserow'n rooli pinossa on selkeä: Airtable-tyyliset tietokannat, joiden taustalla ovat Postgres ja Redis. Tuotannossa ei siis ole olennaista se, vastaako portti 80 kerran, vaan se, pysyvätkö tila, riippuvuudet ja julkinen osoite yhdenmukaisina uudelleenkäynnistyksen, päivityksen ja palautuksen jälkeen.

Mistä Baserow riippuu

Prosessin tila ja tuotteen tila ovat Baserow'ssa eri asioita. Portti 80 voi vastata, vaikka käyttäjälle näkyvä transaktio epäonnistuisi. Paikallinen runtime-vaatimus on riittävä muisti niputettua Postgresia, Redis-palvelua, backendia ja workereita varten. Pidä elinkaari eksplisiittisenä, jotta Baserow'n siirtäminen hostilta toiselle ei muuta toimintaa huomaamatta.

Suorita tämä readiness-testi merkittävien määritysmuutosten jälkeen: luo tietokanta ja näkymä, tuo CSV-tiedosto, muokkaa rivejä kahdesta istunnosta ja lataa tiedosto ennen all-in-one-pinon uudelleenkäynnistystä. Älä sisällytä kalliita ulkoisia tarkistuksia liveness-probeihin, jotta palveluntarjoajan häiriö ei aiheuta uudelleenkäynnistyssilmukkaa. Kapasiteettia suunniteltaessa seuraa niputettua Postgresia, Redis-palvelua, Celery-workereita, rivimäärää, tuontikokoa ja samanaikaisia muokkaajia. Ne kuvaavat Baserow'n todellista kuormitusta paremmin kuin sivupyynnöt.

Docker-perusmääritys Baserow'lle

Seuraava komento tekee konttirajan näkyväksi ilman, että se teeskentelee kaikkien ulkoisten palveluiden käyttöönottoa.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Ennen ingressin avaamista tarkista ratkaistu ympäristö, mountit ja kuuntelija. Varmista paikallinen vaatimus ennen altistamista: muistia on oltava riittävästi niputettua Postgresia, Redis-palvelua, backendia ja workereita varten. Käynnistys on onnistunut vasta, kun voit luoda tietokannan ja näkymän, tuoda CSV-tiedoston, muokata rivejä kahdesta istunnosta ja ladata tiedoston ennen all-in-one-pinon uudelleenkäynnistystä – ei silloin, kun docker ps tulostaa Up.

Domainit, välityspalvelimen headerit ja portti 80

Julkaise Baserow yhdellä HTTPS-hostnimellä ja pidä raaka portti 80 yksityisenä. Aseta BASEROW_PUBLIC_URL täsmälleen ulkoista originia vastaavaksi. Näin selaimet ja API-asiakkaat eivät opi kahta keskenään kilpailevaa osoitetta.

Suorita tunnetusti toimiva transaktio puhtaalta clientilta ja tarkista ensimmäinen epäonnistuva pyyntö. Käytä custom-domain-opasta, kun DNS- tai TLS-määritykset ovat väärin. Käsittele tilanne ”julkinen URL-osoite muuttuu sen jälkeen, kun käyttäjät ovat luoneet jako- ja callback-linkkejä” erillisenä sovellusongelman diagnoosina, kun reitin toiminta on varmistettu.

Varmuuskopioi data, jota Baserow ei voi luoda uudelleen

Määritä Baserow'n palautuspiste ja palautumisaika koko /baserow/data-puun sekä säännöllisten loogisten tietokantavientien perusteella. Mounttaa /baserow/data ennen bootstrapia, kirjoita vaaratonta esimerkkidataa ja korvaa kontti varmistaaksesi, että kyseinen polku on todella pysyvä. Named volume ratkaisee redeployn jälkeisen pysyvyyden, mutta ei tietomurron tai palvelimen menetyksen ongelmaa.

Rakenna puhdas palautusympäristö, käytä samaa kiinnitettyä sovellusversiota ja varmista, että taulukot, näkymät, käyttäjät, automaatiot ja tiedostot palautuvat täydellisestä /baserow/data-varmuuskopiosta. Kirjaa komennot, omistajuuden korjaukset ja kulunut aika. Varmuuskopio-opas tarjoaa hyödyllisen standardin: varmuuskopioon voi luottaa vasta palautuksen jälkeen, ei sen lataamisen jälkeen.

Älä anna Baserow'lle koko hostia

Arvioi Baserow'n suorittamaa toimintaa, älä vain sen kirjautumislomaketta. Tässä suuririskinen virhe on all-in-one-imagen käyttäminen ilman varmuuskopiosuunnitelmaa sen niputetuille palveluille. Toteuta tämä rajaus: sulje rekisteröityminen tarvittaessa, säilytä SECRET_KEY ja rajoita julkiset jaetut näkymät vain tarkoitettuun dataan.

Luo SECRET_KEY kerran, pidä se Gitin ulkopuolella ja säilytä se palautusmanifestin yhteydessä, koska sen muuttaminen voi mitätöidä salatun tai allekirjoitetun sovellustilan. Älä ratkaise käyttöoikeusvirhettä ajamalla konttia root-käyttäjänä tai mounttaamalla hostia laajasti. Resurssirajat kuuluvat myös tietoturvasuunnitteluun, kun käyttäjät voivat käynnistää niputetun Postgresin, Redis-palvelun ja Celery-workerit sekä vaikuttaa rivimäärään, tuontikokoon ja samanaikaisten muokkaajien määrään.

Lokit, jotka auttavat seuraavassa kysymyksessä

Joutokäynnin health check kertoo Baserow'sta vain vähän. Seuraa niputettua Postgresia, Redis-palvelua, Celery-workereita, rivimäärää, tuontikokoa ja samanaikaisia muokkaajia ja hälytä käyttäjien kokemasta oireesta: tämän toiminnon epäonnistumisesta: ”luo tietokanta ja näkymä, tuo CSV-tiedosto, muokkaa rivejä kahdesta istunnosta ja lataa tiedosto ennen all-in-one-pinon uudelleenkäynnistystä”. Pidä liveness paikallisena ja kevyenä; anna readinessin ilmoittaa migraatioista tai alustuksesta aiheuttamatta restart stormia.

Riskialtis päivitysalue syntyy siitä, että all-in-one-image siirtää useita palveluita yhdessä, joten tietokanta- ja sovellusmigraatiot on harjoiteltava snapshot-pohjaisesti. Lue release notesit, ota snapshot tilasta, ota kohdeversio käyttöön palautetun kopion päällä ja toista hyväksymistoiminto. Jos julkinen URL-osoite muuttuu sen jälkeen, kun käyttäjät ovat luoneet jako- ja callback-linkkejä, yhdistä clientin pyyntö ensimmäiseen asiaankuuluvaan sovelluslokiin sen sijaan, että poistaisit tilan tai lisäisit uudelleenohjauksia summittaisesti.

Viisi tarkistusta, jotka ovat konttien health checkiä vahvempia

Ennen oikeiden käyttäjien saapumista laadi Baserow'lle release worksheet. Siinä on nimettävä kiinnitetty image, portti 80, kanoninen origin, pysyvät polut ja riittävästä muistista niputettua Postgresia, Redis-palvelua, backendia ja workereita varten vastaava omistaja. Liitä mukaan tämän transaktion odotettu tulos: luo tietokanta ja näkymä, tuo CSV-tiedosto, muokkaa rivejä kahdesta istunnosta ja lataa tiedosto ennen all-in-one-pinon uudelleenkäynnistystä.

Käytä worksheetia normaalin korvauksen ja puhtaan palautuksen jälkeen. Palautus hyväksytään vain, jos taulukot, näkymät, käyttäjät, automaatiot ja tiedostot palautuvat täydellisestä /baserow/data-varmuuskopiosta. Kerää myös lyhyt resurssijälki, joka kattaa niputetun Postgresin, Redis-palvelun, Celery-workerit, rivimäärän, tuontikoon ja samanaikaiset muokkaajat. Säilytä se releasen yhteydessä, jotta tulevia kapasiteettimuutoksia voidaan verrata samaan kuormaan.

Sisällytä yksi hallittu virhe: lähetä vaaratonta syötettä lähellä tähän rajaan liittyvää resurssi- tai muotorajaa: julkinen URL-osoite muuttuu sen jälkeen, kun käyttäjät ovat luoneet jako- ja callback-linkkejä. Varmista, että Baserow ilmoittaa ongelmasta oikealla rajalla, palauta kelvollinen ehto ja suorita transaktio uudelleen. Näin testataan virheiden näkyvyyttä, ei pelkkää onnistumista, ja estetään terveen näköistä käyttöliittymää peittämästä rikkinäistä workeria, callbackia tai tietokantayhteyttä.

Liitä Baserow Dockupin elinkaareen

Dockupin yhden napsautuksen Baserow-käyttöönoton pitäisi tehdä korvaamisesta turvallista: reitti osoittaa edelleen porttiin 80, salaisuuksia ei leivota imageen ja pysyvät polut palautuvat uuteen konttiin. Sama käyttöönotto voi toimia Dockupin laskennassa tai liitetyllä koneella.

Viimeistele sovelluskohtaiset toimet varmistamalla paikallinen vaatimus — riittävä muisti niputettua Postgresia, Redis-palvelua, backendia ja workereita varten — määrittämällä kanoninen julkinen osoite ja suorittamalla tämä hyväksymistesti: luo tietokanta ja näkymä, tuo CSV-tiedosto, muokkaa rivejä kahdesta istunnosta ja lataa tiedosto ennen all-in-one-pinon uudelleenkäynnistystä. Lisää palautuksen tulos runbookiin ennen oikeiden käyttäjien saapumista.

Usein kysytyt kysymykset

Mitä Baserow tarvitsee tuotantokäyttöönottoon?

Reititä Baserow-kontti portissa 80 yhden HTTPS-originin kautta. Paikallinen runtime-vaatimus on riittävä muisti niputettua Postgresia, Redis-palvelua, backendia ja workereita varten. Älä pidä Baserow'ta valmiina, ennen kuin voit luoda tietokannan ja näkymän, tuoda CSV-tiedoston, muokata rivejä kahdesta istunnosta ja ladata tiedoston ennen all-in-one-pinon uudelleenkäynnistystä.

Mitkä Baserow'n tiedot kuuluvat varmuuskopioon?

Säilytä /baserow/data ja sisällytä koko /baserow/data-puu sekä säännölliset loogiset tietokantaviennit samaan palautusmanifestiin. Puhdas Baserow-palautus hyväksytään vain, kun taulukot, näkymät, käyttäjät, automaatiot ja tiedostot palautuvat täydellisestä /baserow/data-varmuuskopiosta.

Tarvitseeko Baserow HTTPS:n reverse proxyn takana?

Käytä julkisessa Baserow-originissa HTTPS:ää ja pidä portti 80 sisäisessä reitissä. Käytä Baserow'n asetusta oikein: aseta BASEROW_PUBLIC_URL täsmälleen ulkoista originia vastaavaksi. Baserow'ssa HTTPS suojaa tunnistetietoja ja käyttäjäsisältöä siirron aikana sekä pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten Baserow'n päivitys pitäisi testata?

Palauta Baserow'n nykyinen tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistransaktio. Kiinnitä erityistä huomiota siihen, että all-in-one-image siirtää useita palveluita yhdessä, joten tietokanta- ja sovellusmigraatiot on harjoiteltava snapshot-pohjaisesti. Säilytä edellinen Baserow-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.