Guider för användare

Appar

En apps sida: driftsättningar, variabler, värdnamn med HTTP/3, viloläge, loggar och driftsättning från Git.

En app är en container-image som Velrix håller igång. Din första app driftsätter en; den här sidan handlar om att leva med den. Appens sida har ett huvud som säger hur den mår, och flikar: Översikt, Variabler, Volymer, Driftsättningar, Loggar och Inställningar, och fler när andra delar av Velrix lägger till sina egna.

Hur den mår

Statusen säger det med ett ord, och på Cockpit-tavlan med ett märke:

  • Frisk, med ett hjärta som slår: den körs och varje kopia som körs klarar sin hälsokontroll.
  • Startar: tills varje kopia som körs klarar den.
  • Sjuk, med ett sprucket hjärta: en kopia klarar inte sin kontroll.
  • Körs: den körs och har ingen hälsokontroll.
  • Sover, med en måne: den stoppades för att ingen frågade efter den (se Sov när den är ledig).
  • Offline: ingenting körs.

Huvudet visar också appens första värdnamn, zonen för servern den körs på och hur många kopior den kör. En app som inte får nå internet säger Ingen internetåtkomst där (se Internetåtkomst).

Översikt listar de senaste händelserna i meningar, till exempel vem som ändrade variablerna och när.

Driftsättningar

Varje ändring som påverkar det som körs blir en revision: en ny image, en driftsättning av variabler, en ny storlek. Fliken Driftsättningar visar den som är aktiv som ett kort: commitens första rad, dess författare och tid, var den kom ifrån, utrullningens senaste besked och Visa loggar. Kortets meny har Starta om, Driftsätt igen och Ta bort. När ingenting är aktivt står det Ingen aktiv driftsättning, med ett erbjudande att driftsätta.

Under kortet finns historiken, där varje revision är Aktiv, Driftsätts, Misslyckad, Tillbakarullad, Borttagen eller Överhoppad. Dölj överhoppade gör listan kortare.

En revision öppnas på en egen sida:

  • Detaljer: utfallet och faserna den gick igenom, var den kom ifrån, vad som ändrades, dess variabler och dess konfiguration, läsbar eller som velrix.json eller TOML att kopiera.
  • Byggloggar för en revision som CI byggt, Driftsättningsloggar och Nätverksloggar för dess tid.

Utrullning utan avbrott

En ny revision av en container-app startar som en extra kopia bredvid dem som körs. Velrix väntar tills den nya kopian är uppe, klarar sin hälsokontroll och används av sina värdnamn, och byter sedan ut de gamla kopiorna en i taget, var och en bedömd på samma sätt. Hela tiden körs så många kopior som du bad om, så inte heller en app med en enda kopia får något avbrott.

Om en ny kopia inte startar, kraschar eller inte klarar sin kontroll misslyckas revisionen och rullas tillbaka: bara kopior som hann få den nya revisionen går tillbaka, och den extra kopian försvinner. Kopior som utrullningen aldrig nådde lämnas orörda.

Två slag startas om på plats i stället, stoppas innan de startar: en VM, och en app vars volym bara en kopia får montera. Revisionen säger det.

Variabler

Fliken Variabler innehåller det som appen startar med. Försegla hemligheter: ett förseglat värde krypteras, visas aldrig igen och syns bara för containern.

Förberedda ändringar

Ändringar körs inte förrän du driftsätter dem. Varje ändring förbereds: raden färgas och säger Ny, Ändrad eller Borttagen, Cockpit-kortet säger Ändrad · 3 ändringar, och en rad över alla appens flikar säger Verkställ 3 ändringar, med Släng, Detaljer och Driftsätt (Skift+Enter). Driftsätt verkställer alla på en gång som en revision, vars nummer appen läser som VELRIX_REVISION.

Klistra in variabler tar en .env-fil eller ett JSON-objekt och förbereder rad för rad. Bredvid listan kan samma variabler kopieras som ENV eller JSON; förseglade utelämnas.

Referenser

Ett värde kan peka på en annan apps variabel eller på en delad, och slås upp när du driftsätter:

postgres://app:${{app:db.PASSWORD}}@${{app:db.INTERNAL_HOST}}:5432/app
  • ${{app:<namn>.VAR}}: en annan app med samma ägare, med namn eller id. VAR kan vara en av dess variabler eller en som Velrix ger, till exempel INTERNAL_HOST.
  • ${{shared.VAR}}: en delad variabel (nedan).

En referens som går runt i en cirkel, eller pekar på något som inte finns, nekas med sitt namn, och ingenting ändras. En referens till ett förseglat värde förseglas i appen som läser det. Du behöver rätt att hantera appen du läser från.

Delade variabler

Delade variabler hör till ägaren eller projektet, och alla appar där kan läsa dem som ${{shared.NAMN}}. Gör delad på en rad flyttar appens egen variabel dit och lämnar en referens kvar. Varje delad variabel listar apparna som använder den; en som används tas inte bort. När du ändrar en förbereds ändringen i varje app som läser den, så att var och en driftsätts när dess folk säger till.

Skapade hemligheter

Värdet ${{ secret(32) }} skapas när det driftsätts första gången: 32 bokstäver och siffror, eller de tecken du anger, till exempel ${{ secret(24, "abcdef0123456789") }}. Det behålls vid varje driftsättning efter det, tills du ändrar texten. Generator i radens meny skriver det åt dig.

Från Velrix

Varje container får också VELRIX_APP_ID, VELRIX_APP_NAME, VELRIX_INTERNAL_HOST och VELRIX_INTERNAL_URL (dess namn på projektnätverket), VELRIX_REVISION, VELRIX_COMMIT, och zonen och regionen för dess server. En egen variabel med samma namn går före.

Inställningar

En flik, Inställningar, rymmer allt annat, ett avsnitt var, med ett filter överst (/ hoppar dit): Källa och Bygge när ägaren har en Git-server, Driftsätt, Hälsa, Nätverk, Skalning, Policyer, och Ta bort sist.

Ändra storlek

Skalning har appens storlek: välj en annan ur katalogen, eller Egen där den driftansvarige tillåter det, och sedan Ändra storlek. Storleken prövas som när appen skapades, och mot servrarna appen körs på: de behöver minnet den växer med och kärnorna den ber om. Appen flyttas aldrig för en ny storlek. Varje kopia startas om med den nya storleken, som en revision, så en tillbakarullning ger också tillbaka den gamla storleken.

Sov när den är ledig

Slå på Sov när den är ledig under Skalning och välj antal Lediga minuter (10 som standard). När ingen har frågat efter appen så länge stoppas den, och nästa anrop väcker den:

  • Anrop som kommer medan den vaknar väntar, upp till 30 sekunder och upp till 100 åt gången. Därutöver får de en sida som säger att appen vaknar, och ombeds försöka igen om några sekunder.
  • Appens sida säger hur lång tid den senaste väckningen tog, så att du kan bedöma det.
  • Ingenting debiteras medan den sover. En volym förblir inkopplad.
  • En driftsättning medan den sover ändrar det som körs härnäst; nästa väckning kör den.

Bara anrop till dess värdnamn väcker den, över HTTP/1.1, HTTP/2 eller HTTP/3. En lastbalanserarport eller ett anrop från en annan app på projektnätverket gör det inte: låt sömnen vara av för en app som nås så. VM:er sover inte.

Värdnamn och HTTP/3

Nätverk ger appen dess namn, när du har bevisat domänen (Publik adress och värdnamn för appar). Varje namn får sitt certifikat av sig självt och svarar på HTTP/3, HTTP/2 och HTTP/1.1, utan något att ställa in: HTTP/3 är påslaget för varje app, och webbplatserna i Velrix Public Cloud, den här inräknad, levereras så. WebSockets fungerar över HTTP/1.1.

  • HTTPS-post: Nätverk visar DNS-posten att lägga in för varje namn, så att webbläsare använder HTTP/3 redan vid första besöket. Utan den går de över till HTTP/3 efter första svaret.
  • Certifikat: ett namn som ännu inte pekar på realmen säger Väntar på att DNS ska peka hit, och dess certifikat beställs så snart det pekar rätt.
  • Omdirigeras hit: namn som skickar besökare till ett av appens namn, med sökväg och frågesträng kvar (308 som standard; 301, 302 eller 307 om du vill).
  • Åtkomst: vem som får öppna namnen. Alla; Alla som är inloggade i den här realmen; eller Bara de som anges nedan: personer, organisationer och projekt. Besökarna loggar då först in på realmens egen inloggningssida. Ett jokerteckennamn kan inte skyddas.

När Velrix själv måste svara, för att ingen kopia är uppe, appen startar eller en besökare inte släpps in, visar sidan var det tog stopp, från besökaren via realmen till appen, med ett förfrågans-id att uppge.

Appar publicerar aldrig portar på en server. Webbtrafik går via värdnamn; för annan TCP eller UDP, som SSH, sätter du en lastbalanserare eller en flytande IP-adress framför appen (Nätverk › Lastbalanserare).

Internetåtkomst

En app på ett projektnätverk når internet bara när dess ägare tillåter det, och det är avstängt tills dess. Appens huvud säger Ingen internetåtkomst, och Inställningar har en rad Internetåtkomst med reglaget, för den som får hantera ägarens nätverk.

Loggar

Fliken Loggar är en vy över allt appen sagt, med realtidsföljning, sökning och nedladdning. Ett chip för varje slag den har rader i väljer vad du ser: Utdata, HTTP-anropen till dess värdnamn, och dess egna DNS-uppslag och nätverksflöden när den driftansvarige loggar dem för dess nätverk.

  • Filter: skriv @ för fälten i de valda slagen, till exempel @status:5*, @level:error eller @domain:*.example.com, bredvid fria ord. Alla måste stämma. Ett filter som inget valt slag kan stämma med stryks under och säger varför.
  • Fel har en röd kant. En stackspårning efter en varning eller ett fel, även ett utskrivet felobjekt, är en post, hopfälld till sin första rad.
  • DNS-rader säger vad ett namn löstes till.
  • Kolumner väljer kolumnerna för varje slag, och lokal tid eller UTC.

Driftsätt från ert eget Git

Kör Forgejo som en app från Bibliotek, koppla den under Git-servrar, så får appens Inställningar avsnitten Källa och Bygge:

  • Källa: servern, repot, grenen och imagen att driftsätta. Driftsätts vid push slår på eller av; Vänta på CI driftsätter först när commitens CI-körning lyckats. Imagenamnet kan använda {sha}, {short} eller {branch}.
  • Bygge: sökvägen till Containerfile och variabler vid bygget, förseglade och givna till CI-bygget.

Folk loggar in i Forgejo med sitt Velrix-konto, och organisationens medlemmar går med i dess team. CI körs som Velrix-jobb, vart och ett i en egen microVM, och utdata når Forgejo medan jobbet körs. Varje körning får en registernyckel som bara kan pusha till de repon som commitens regler nämner, och till deras byggcache: lager sparas i registret mellan körningarna, så ett bygge vars beroenden inte ändrats återanvänder dem. I våra tester tog ett bygge med ett beroendesteg på 200 MB 20 sekunder kallt och 9 sekunder med cachen.

Varje driftsättning är en revision som alla andra, utrullad utan avbrott och tillbakarullad om den misslyckas, med commiten, dess författare och CI-körningen på sin sida. Git över SSH går via en lastbalanserare; klona och pusha över HTTPS fungerar via appens värdnamn.

Som kod

Allt här är API-anrop, beskrivna i realmens Docs-fönster (API-referensen i din realm). En API-nyckel som skapats med en hel förmåga, till exempel allt i compute, följer med nya versioner: när en ny version lägger till något i den förmågan får nyckeln det, och dess sida säger Fick 2 rättigheter från en ny version. En nyckel med enstaka händelser eller bara läsrätt vidgas aldrig.