Driftsätt en blueprint

Varje driftsättning kräver blueprints/read på boundaryn och containerinstance/write i resursgruppen. En blueprint med hemligheter eller en databas kräver mer; guiden kontrollerar allt innan något skapas — se Förhandskontroller, och Behörigheter för hela listan.

Hitta en blueprint

Öppna Marknadsplats i sidomenyn i portalen på https://portal.example.com. Varje kort visar blueprintens ikon, namn, beskrivning, kategori, version, några av dess taggar, hur många komponenter den har och en knapp Distribuera — som bara visas för den som har containerinstance/write på boundaryn. En blueprint som publicerats från något av din boundarys förråd visar också det förrådet.

• Sök blueprints… söker i namn, beskrivningar, kategorier och taggar; varje ord du skriver måste träffa.
• Raden med taggar filtrerar katalogen. Väljer du flera taggar visas blueprints som har någon av dem; Rensa filter nollställer sökningen och taggarna.
• När katalogen har mer än en kategori finns flikar överst som begränsar den till en; Alla visar allt.
• Blueprints med taggen stackship visas först under I fokus, med märket Stackship. Resten följer under Fler blueprints.

Välj Distribuera på ett kort. Guiden, Distribuera <blueprint>, har fem steg.

Översikt

Blueprintens beskrivning, kategori, version och taggar, och en länk till dess dokumentation. När blueprinten skapar hanterade resurser listar Det här skapas var och en av dem och de komponenter som läser den.

Namn och placering

Grundkonfiguration frågar efter:

• Instansnamn — 3 till 50 gemener, siffror och bindestreck. Börja namnet med en bokstav och avsluta det med en bokstav eller siffra, även om fältet godtar en inledande siffra eller ett bindestreck i någon av ändarna: varje komponent nås på <instance>-<component>, som är ett Service-namn i Kubernetes och måste börja med en bokstav, och ett namn med bindestreck i någon ände går igenom kontrollerna men får driftsättningen att misslyckas när dess första resurs skapas. Namnet måste vara ledigt i resursgruppen. Det blir containerinstansens namn och prefix för allt annat blueprinten skapar — <instance>-secrets för valvet och <instance>-<resource> för varje hanterad resurs.
• Boundary, Cluster och Resource group — var instansen och allt blueprinten skapar ska ligga. Varje fält fylls i åt dig när det bara finns ett val.

Se upp

Bara instansnamnet kontrolleras mot att vara ledigt. Ett valv med namnet <instance>-secrets eller en databas med namnet <instance>-<resource> som redan finns i resursgruppen används som det är, inte nekas: driftsättningen skriver sina hemligheter i det valvet som nya versioner av nycklar som redan finns där, ger den nya instansens identitet Secrets Reader på hela valvet — så att den kan läsa varje hemlighet som redan finns där, inte bara blueprintens — och ger den nya instansen den databasens anslutningsuppgifter. Kontrollera resursgruppen efter de namnen innan du driftsätter.

Parametrar

Konfiguration visar blueprintens parametrar, var och en som ett fält av sin typ:

• Ett fält du lämnar tomt får blueprintens standardvärde.
• Parametrar som blueprinten markerar som avancerade, och hemligheter den kan generera, ligger hopfällda under Avancerade inställningar. Om du inte öppnar det och anger dem gäller standardvärdena och hemligheterna genereras.
• Värden som plattformen sätter ihop själv — signerade nycklar, anslutningssträngar byggda av ett genererat lösenord — är inga fält alls. En rad under formuläret talar om hur många av dem som genereras vid driftsättningen och lagras i instansens valv.

Hemliga värden skrivs till instansens valv, aldrig in i själva containerinstansen. Alla egenskaper en parameter kan ha beskrivs i Parametrar.

Beräkning

Beräkning har en rad per komponent, med dess Beräkningsplan och Repliker förifyllda med blueprintens standardvärden. Planerna visas med sin processor och sitt minne.

• När boundaryns policy för beräkningsplaner inte tillåter en komponents standardplan börjar raden tom och säger varför; välj en av de planer policyn tillåter.
• När blueprinten anger en lägsta plan för en komponent visar raden Minst: <plan>, och planer med mindre processor eller mindre minne visas som Under ritningens minimum och går inte att välja. Driftsättningen nekar också en mindre plan, innan den skapar något.
• Repliker kan vara 0 till 10, och en komponent med en beständig volym kör högst en. Fältet stoppar inte ett högre antal; driftsättningen misslyckas då vid Create the container instance, efter att valvet och eventuell databas har skapats.

Förhandskontroller

Granska & Distribuera sammanfattar instansnamnet, resursgruppen och parametrarna. Hemligheter du angav visas som Angiven; hemligheter som kommer att genereras visas som Kommer att genereras.

Under Innan du driftsätter kontrollerar plattformen allt som driftsättningen kommer att behöva, i den ordning det behövs, utan att skapa något. Kontrollerna körs igen när du ändrar namnet eller resursgruppen, och Skicka är avstängd så länge någon av dem nekas.

En nekad behörighet säger Be en ägare om <action> på <scope>. En Owner på den nivån kan ge dig en roll som innehåller den, eller så kan du begära en roll för några timmar med Just-in-time-åtkomst.

Valvbehörigheten har sin lösning på plats: Begär tillfällig åtkomst skickar en begäran om Owner på det nya valvet, och rutan följer den. När en ägare har godkänt den väljer du Aktivera åtkomst; kontrollerna körs igen och Skicka blir tillgänglig.

Viktigt

Själva behörigheten ges bara av den som har Owner eller Platform Owner på valvet eller högre, tilldelad direkt eller aktiverad via just-in-time-åtkomst. Owner via en grupp, eller en anpassad roll med rbac/members/write, går igenom kontrollen men inte tilldelningen: driftsättningen misslyckas då vid Create the container instance eller Grant the instance access to its vault, efter att valvet, dess hemligheter och eventuell databas har skapats, och skickar Owner-begäran åt dig. Aktivera den och försök igen.

Kontrollerna gäller behörigheter och namn, inte resten av konfigurationen. Att läsa en hanterad databas anslutningsuppgifter kräver också postgrescluster/readSecrets på den, vilket inte kontrolleras i förväg, och containerinstansens egna regler — repliker, planer, portar — tillämpas när den skapas. När kontrollerna inte går att köra alls visar sidan Kontrollerna kunde inte köras och Skicka förblir tillgänglig; driftsättningen kör samma kontroller och nekar om något saknas.

En blueprints containrar läser hemligheter bara från instansens valv. En mall som pekar ut något annat valv nekas när den publiceras, och en som sparades före den regeln nekas av kontrollerna och av driftsättningen, innan något skapas.

Se upp

En blueprint från en katalogkälla eller via mall-API:t är skriven av den som kan publicera i boundaryn, och dess avbilder körs med läsåtkomst till instansens valv, given med dina behörigheter. Granska mallen innan du driftsätter den.

Driftsätt och följ förloppet

Välj Skicka. Driftsättningen tas emot direkt och du hamnar på dess sida, Distribuerar <instance>:

• Sammanfattning — försökets nummer, Resursgrupp, Instans, vem som startade den (Startad av), när den blev Accepterad och Avslutad, och vid ett nytt försök en länk till föregående försök.
• Steg — varje steg medan det körs, uppdaterat löpande.
• Resultat — att det lyckades, eller Misslyckades vid <step> med felet.

När driftsättningen lyckas tar Öppna instansen dig till containerinstansen. Driftsättningen registreras också bland boundaryns operationer.

Försök igen efter ett fel

Försök igen kör en misslyckad driftsättning på nytt som ett nytt försök av samma driftsättning: samma instansnamn, parametrar och beräkningsresurser, med blueprinten som den ser ut i katalogen nu. Valvet och eventuell databas som det misslyckade försöket skapade återanvänds i stället för att skapas igen. Hemligheterna skrivs på nytt: värden du angav är desamma, och värden som plattformen genererar genereras på nytt och lagras som nya versioner.

När felet var valvbehörigheten visar sidan samma ruta Begär tillfällig åtkomst som guiden, och Försök igen blir tillgänglig när din åtkomst är aktiv.

Ett nytt försök kan inte ändra indata. Vill du ändra dem driftsätter du blueprinten igen med samma instansnamn: det som det misslyckade försöket lämnade i resursgruppen återanvänds på samma sätt. Ger du upp i stället tar du bort det som blev kvar.

Viktigt

Driftsättningar listas per boundary. Alla med blueprints/read på boundaryn ser varje driftsättning i den, oavsett resursgrupp, med dess fel, och kan försöka igen med vilken misslyckad som helst. Ett nytt försök hoppar över kontrollerna ovan, körs med behörigheterna hos den som försöker igen och återanvänder den ursprungliga användarens parametrar — hemliga värden hen angav inräknade, som skrivs till valvet på nytt.

Med CLI:t

stsh blueprint catalog                          # katalogen
stsh blueprint catalog supabase                 # en blueprint, med dess parametrar
stsh blueprint deploy supabase my-supabase -g my-resource-group -c my-cluster --dry-run
stsh blueprint deploy pocketbase my-pocketbase -g my-resource-group -c my-cluster --set storage_size=10Gi
stsh blueprint deploys list
stsh blueprint deploys get <deployment-id>
stsh blueprint deploys retry <deployment-id>

• deploy tar blueprintens slug och instansnamnet. Ange parametrar med --set namn=värde, upprepat, eller från ett JSON-objekt med --file. Ett värde som kan läsas som JSON skickas som JSON, medan parametrar är strängar — citera sådana värden: --set theme_enabled='"true"'.
• CLI:t driftsätter varje komponent med blueprintens egna standardvärden för beräkning.
• --dry-run skriver ut förhandskontrollerna och avslutar utan att skapa något. När valvbehörigheten nekas erbjuder det sig att skicka åtkomstbegäran åt dig.
• --wait-for-access skickar den begäran om den behövs, väntar på att en ägare godkänner den, frågar innan den aktiveras och driftsätter sedan i samma körning.
• deploy och deploys retry följer åtgärden tills den är klar; --no-wait återvänder så snart driftsättningen har tagits emot.

deploy_not_accepted

503 vid de här rutterna:

Varje driftsättning följs som en operation, och en driftsättning som inte går att följa startas inte: koden betyder att operationen inte kunde öppnas, så driftsättningen togs inte emot. Ingenting skapades och ingen driftsättning registrerades; vid ett nytt försök ligger den misslyckade driftsättningen kvar som den var. En torrkörning svarar aldrig med koden, och en driftsättning svarar med den först när alla förhandskontroller har gått igenom.

En plattform i produktion ersätter kroppen i varje 5xx-svar, så kroppen anger bara koden och rådet finns här i stället för i svaret:

{
  "error": "An internal error occurred.",
  "code": "deploy_not_accepted",
  "module": "blueprints",
  "correlationId": "3f2b9c1e-6d4a-4e0b-9a51-2c7d8e0f4b6a"
}

Försök igen: skicka driftsättningen igen, eller gör ett nytt försök med den misslyckade driftsättningen — se Försök igen efter ett fel. Det är säkert, eftersom ingenting startades. Om operationen öppnades men svaret aldrig kom fram visar boundaryns operationer en extra driftsättningsoperation för instansen, som blir Superseded när du försöker igen. Om koden fortsätter att komma, rapportera den med correlationId.

Nästa steg

• Efter en driftsättning — instansen, dess valv och dess databaser
• Behörigheter