Ga naar de hoofdinhoud

Updates en schaling

Operaties op dag twee: nieuwe releases binnenhalen en Kanera meer ruimte geven naarmate het team groeit.

Updates​

Elke Kanera-release is een getagde versie, zoals v1.9.0 met zijn eigen docker-compose.yml. Bijwerken betekent het omwisselen van het opstelbestand van de nieuwe release en het ophalen van de afbeeldingen. Je kunt releases overslaan: rechtstreeks van v1.9.0 naar v1.12.0 gaan is prima, omdat elke lopende databasemigratie tijdens de update op volgorde wordt uitgevoerd.

Update naar de nieuwste release​

Van jouw kanera map op de server:

docker compose exec -T postgres pg_dump -U kanera kanera | gzip > kanera-$(date +%F).sql.gz
cp docker-compose.yml docker-compose.previous.yml
curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/latest/download/docker-compose.yml
docker compose pull
docker compose up -d
docker compose logs migrate

Lees voordat u het uitvoert het release-opmerkingen voor elke release tussen uw versie en de nieuwe. Een wijziging waarvoor actie nodig is, zoals een nieuwe instelling of een eenmalige herverbinding, wordt vermeld onder de release waarin deze is geïntroduceerd, dus als u van v1.9.0 naar v1.12.0 gaat, betekent dit dat u de opmerkingen van 1.10.0, 1.11.0 en 1.12.0 moet lezen.

Om naar een specifieke release te gaan in plaats van de nieuwste, download je het opstelbestand per tag:

curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/download/v1.9.0/docker-compose.yml

Controleer welke versie u gebruikt​

docker compose images api

De TAG kolom toont bijvoorbeeld de vrijgave 1.9.0. De eerste regel van docker-compose.yml noemt het ook.

Voordat u gaat updaten​

  • Maak een back-up van de database en uploads. De pg_dump hierboven heeft betrekking op de database; de kanera_uploads volume heeft een eigen kopie nodig. Bewaar beide, plus jouw .env, van de primaire schijf van de server. Zie Opslag en back-ups.
  • Bewaar het vorige opstelbestand. De cp hierboven slaat het op als docker-compose.previous.yml, wat je nodig hebt om terug te draaien.
  • Houd uw wijzigingen buiten docker-compose.yml. De update vervangt dat bestand. Zet poorten, extra netwerken of andere lokale wijzigingen in een docker-compose.override.yml ernaast; Compose voegt het automatisch samen en updates laten het met rust.
  • Zorg ervoor dat de huidige implementatie in orde is. Een update mag een bestaand database-, opslag- of routeringsprobleem niet verbergen.

Controleer de update​

docker compose images api
docker compose ps --all
docker compose logs --tail=100 api worker public-api mcp
curl https://kanera.example.com/api/health

De api afbeelding moet de nieuwe versie tonen, en migrate moet worden weergegeven als afgesloten met code 0. Controleer ook de openbare gezondheidseindpunten API en MCP als u deze openbaar maakt. Meld u vervolgens aan, open een gevuld bord en maak en verwijder een tijdelijke kaart.

Als een update mislukt​

  • De migratie is niet gestart: herstel de Compose- of omgevingsfout en voer het opnieuw uit docker compose up -d.
  • De migratie is mislukt: bewaar de logboeken en de back-up en voer deze niet herhaaldelijk uit zonder de fout te begrijpen. Open een probleem met de migrate logboeken.
  • Je moet teruggaan: een oudere release kan niet worden uitgevoerd met een database waarvan de nieuwere is gemigreerd. Kanera stoppen (docker compose down), herstel de database vóór de update en upload samen, plaats het vorige opstelbestand terug (mv docker-compose.previous.yml docker-compose.yml), en rennen docker compose up -d.
  • Herstel nooit een back-up over een actieve nieuwere versie. Test uw herstelprocedure op een afzonderlijke database of host voordat u erop vertrouwt.

Schaalnotities​

De standaardimplementatie maakt gebruik van meerdere app-API-replica's en één werker.

  • API_REPLICAS bestuurt app API procestelling. Standaard ingesteld op 2.
  • PUBLIC_API_REPLICAS controleert het aantal openbare API-processen. Standaard ingesteld op 1.
  • MCP_REPLICAS regelt het aantal MCP-processen. Standaard ingesteld op 1.
  • Houd worker precies bij 1.
  • Valkey is vereist voor realtime fanout-, aanwezigheids- en gedeelde tarieflimieten.

Verhoog replica's alleen als de server voldoende CPU-, geheugen- en databaseverbindingscapaciteit heeft. Als je verhoogt API_REPLICAS, recensie PG_POOL_MAX en PostgreSQL max_connections.

De individuele arbeider is doelbewust. Het voert planners, notificaties en webhook-leveringen uit, en opschoontaken, en een tweede kopie zou dat werk dupliceren in plaats van delen. Als de levering achterop raakt, kijk dan naar de database- en uitgaande netwerkcapaciteit voordat u meer werkprocessen overweegt.