Blueprints

En blueprint är en mall för en hel applikationsstack: dess containrar, den hanterade databas den behöver och hemligheterna som binder ihop dem. När du driftsätter en skapas allt detta i en resursgrupp du väljer, under ett instansnamn du väljer, i en enda åtgärd.

Vad en driftsättning skapar

• En containerinstans med instansnamnet — blueprintens containrar med deras startordning, hälsokontroller, slutpunkter och beräkningsresurser. Det är en vanlig containerinstans och hanteras som alla andra; dess översikt visar vilken Mall den driftsattes från.
• De hanterade resurser som blueprinten deklarerar — i dag PostgreSQL-databaser — med namnet <instance>-<resource>. De är fullvärdiga plattformsresurser och tas inte bort tillsammans med instansen.
• Ett valv med namnet <instance>-secrets, när blueprinten har något hemligt: de hemliga parametrar du angav eller lät generera, och anslutningsuppgifterna till dess hanterade resurser. Instansens identitet får Secrets Reader på valvet, och containrarna får värdena när de startar.

En blueprint utan hemligheter och utan hanterade resurser skapar bara containerinstansen. Vad du gör med resultatet efteråt beskrivs i Efter en driftsättning.

Var blueprints kommer ifrån

Ursprung	Vad det är	Visas i
Plattformskatalogen	De blueprints som levereras med plattformens release — bland dem PocketBase, Supabase och Stackship Data Hub — plus de som hämtas från det katalogförråd som valdes vid installationen. Som standard är det Stackships publika katalog, som lägger till fler, bland dem Keycloak	Varje boundary
Katalogkällor	Git-förråd som en boundary ansluter för att publicera sina egna blueprints — se Katalogkällor	Den boundaryn
Boundary-mallar	Mallar som sparats i en boundary via API:t — se Publicera mallar med API:t	Den boundaryn

Varje blueprint har en slug, sin identifierare. Plattformskatalogen äger sina slugs: en boundary kan inte publicera en blueprint under en slug som plattformskatalogen använder. När plattformskatalogen senare tar en slug som en boundary redan använder, driftsätts plattformens blueprint för den slugen. Blueprints med taggen stackship byggs och underhålls av Stackship, och katalogen visar dem först.

Hur en driftsättning går till

Innan något skapas kontrollerar plattformen varje behörighet och namn som driftsättningen kommer att behöva, i den ordning de behövs, och nekar driftsättningen — utan att skapa något — om någon av dem inte går igenom. Se Förhandskontroller.

En driftsättning som går igenom tas emot direkt och körs som en åtgärd du kan följa. Stegen körs i den här ordningen:

Steg	Vad det gör	När
Prepare the instance vault	Skapar <instance>-secrets	Blueprinten behöver ett valv
Write parameters and generated secrets	Skriver varje hemlig parameter till valvet	Blueprinten behöver ett valv
Provision postgres '<name>'	Skapar databasen, väntar upp till fem minuter på att den tar emot anslutningar och skriver dess anslutningsuppgifter till valvet	En gång per hanterad resurs
Create the container instance	Skapar instansen med de beräkningsresurser du valde. Först ges instansens identitet Secrets Reader på varje valv som dess containrar läser från	Alltid
Grant the instance access to its vault	Ger instansens identitet Secrets Reader på valvet	Blueprinten behöver ett valv

Allt skapas med dina egna behörigheter, inte plattformens.

En blueprints containrar läser hemligheter bara från instansens valv: en mall vars secretRef pekar ut något annat valv nekas när den publiceras, och nekas vid driftsättning om den sparades före den regeln. En första driftsättning nekas också när det redan finns ett valv med instansvalvets namn, eftersom den nya instansen skulle få läsåtkomst till allt i det.

Se upp

En blueprint kör avbilder som dess författare har valt, med läsåtkomst till instansens valv given med dina behörigheter. Den som kan publicera mallar i boundaryn — med blueprints/templates/write, eller genom att pusha till förrådet för en katalogkälla — bestämmer vilka avbilderna är. Granska en blueprint från en katalogkälla eller via mall-API:t innan du driftsätter den.

När en driftsättning misslyckas

Det som stegen före felet skapade ligger kvar i resursgruppen, och felmeddelandet talar om vad. Det är avsiktligt: en driftsättning misslyckas oftast på något du just ska rätta, och ett nytt försök återanvänder valvet och databasen i stället för att skapa dem igen — se Försök igen efter ett fel. Om du inte tänker försöka igen tar du bort det som blev kvar.

Om Blueprints-tjänsten startas om medan en driftsättning står i kö eller körs, misslyckas driftsättningen med ett meddelande som ber dig försöka igen.

Sidor

• Driftsätt en blueprint
• Katalogkällor — publicera ditt teams blueprints från ett git-förråd
• Efter en driftsättning
• Skriv egna blueprints
• Eget tema för Keycloak
• Behörigheter