Fluxuri și automatizare

Un flux este un graf orientat: noduri legate prin fire, parcurse dintr-un singur punct de pornire. Nu este, în mod deliberat, un script cu o buclă. Patru reguli îi fixează forma, iar editorul refuză să publice un desen care încalcă una dintre ele, numind nodul greșit.

• Exact un declanșator. Nodul declanșator este singura intrare și el hotărăște ce variabile există în restul desenului.
• Fără cicluri. Un fir care duce înapoi la un nod din care a plecat este refuzat, pentru că un flux nu știe să aștepte: o buclă pur și simplu nu s-ar termina niciodată.
• Fiecare nod trebuie să fie accesibil dinspre declanșator. Un nod rămas atârnat este o greșeală pe care o captură de ecran nu o arată, deci este o greșeală în momentul publicării.
• Ramurile sunt parcurse una după alta, niciodată alături. Două ramuri simultane ar scrie în state în același moment, iar rezultatul ar depinde de hazardul ceasului.

Editorul este o pânză și nu există o a doua. Un flux nou se deschide direct pe ea, iar un flux care era o listă dreaptă de pași se deschide ca un lanț drept de noduri.

• Paleta conține cele douăsprezece tipuri de nod. Un clic pune unul pe pânză, sau se trage la locul dorit.
• Un nod se mută trăgându-l de antetul lui. Tot restul nodului este un control și deci nu pornește o tragere.
• Un fir merge de la un punct de ieșire la un punct de intrare. Se trage de la unul la celălalt, sau se dă clic întâi pe ieșire și apoi pe intrare. Ambele fac același lucru, iar a doua este calea de la tastatură.
• Lăsarea unui fir în gol nu face nimic. Pentru a scoate unul se selectează și se apasă Delete, sau se folosește crucea așezată pe el.
• Mărirea merge de la 50 la 200 la sută, Încadrare arată întregul desen, iar tragerea fundalului mută vederea. Nu există o hartă în miniatură.

Douăsprezece tipuri, iar lista este scurtă în mod intenționat. Fiecare tip este un panou, nouă traduceri, o ramură în executor și un rând în tabelul de adevăr, deci un tip care își merită locul valorează mai mult decât unul care aproape și-l merită.

Cinci momente, iar cel ales nu spune doar când rulează fluxul. Spune și ce variabile există, pe care le oferă selectorul și pe care platforma refuză să le salveze. O cale care nu poate exista în acel moment este o eroare la salvare și nu un text gol în mijlocul unei rulări.

Fiecare valoare pe care un flux o poate citi vine din unul dintre aceste grupuri. Selectorul din editor arată grupurile care există la declanșatorul ales și nimic altceva. A citi o cale necunoscută este o eroare și niciodată o valoare goală: o presupunere greșită trebuie să facă zgomot.

Un nod set scrie în state. Valoarea lui este text literal, în afară de cazul în care bifați căsuța de expresie; atunci este citită ca un șablon, cu variabilele acestei rulări deja completate.

• Acea bifă este o alegere deliberată. O valoare care conține din întâmplare două acolade, o bucată de Ansible sau un fragment de Helm, înseamnă în continuare ceea ce spunea. Nimic nu își schimbă sensul din cauza unei modificări pe care nu a cerut-o nimeni.
• Limbajul este numai ieșire. Două acolade și o cale, și nimic altceva: fără assign, fără capture, fără buclă, fără include. Ce scrie pe pânză este ce iese, cu valorile completate.
• Există 46 de filtre: text, numere, date, puținele filtre de listă care produc text și proprii quote, ini și ipoctet. Selectorul din editor le enumeră. Două familii lipsesc intenționat, cele care dau cu zarul și cele care întorc un obiect acolo unde se dorea un cuvânt.
• Secretele nu sunt disponibile aici, nici fragmentele reutilizabile. Ceea ce scrie un nod set ajunge în consemnarea rulării, iar un secret nu are ce căuta acolo.

Un flux se poate opri și poate aștepta o persoană și poate parcurge aceleași noduri de mai multe ori. Niciuna nu era posibilă cât timp o execuție nu putea fi pusă în așteptare și trezită mai târziu; acea coadă există acum.

• Un nod de aprobare oprește execuția, creează o cerere și anunță contul. Răspunsul necesită un drept separat, astfel încât cine a scris fluxul să nu fie automat cel care îl semnează.
• Fiecare cerere poartă un termen și ce se întâmplă fără răspuns: continuă ca aprobat, continuă ca respins sau încheie execuția ca neaplicabilă. Nu există o a patra opțiune, pentru că o execuție care așteaptă la nesfârșit este una despre care nimeni nu mai aude.
• Pentru fiecare parcurge ieșirea buclei o dată pentru fiecare element al unei liste. În buclă, state.loop conține elementul curent, poziția lui și totalul.
• Nimic din afara unei bucle nu se poate lega de nodurile din interiorul ei. Acele noduri rulează din nou la fiecare rundă, iar o notificare legată de ambele ar scrie un mesaj pe rundă.
• Un pas de aprobare poate trimite și e-mail. Acesta ajunge doar la membrii care pot decide asupra aprobărilor, nu la toți cei care văd fluxuri, iar notificarea din panou este scrisă oricum.

O execuție oprită nu este o execuție eșuată. Trei lucruri o pot pune deoparte, iar toate trei folosesc aceeași coadă: o aprobare, o pauză lungă și un subflux al cărui copil așteaptă la rândul lui.

• O pauză de o jumătate de minut sau mai scurtă așteaptă pur și simplu în cadrul cererii care a pornit-o, exact ce doriți când lăsați un agent să își revină. Tot ce durează mai mult pune execuția deoparte, astfel încât comanda care a pornit-o se încheie imediat, iar restul fluxului urmează mai târziu.
• Un subflux execută un alt flux al acestui cont ca un singur pas. Rezultatul lui decide ieșirea: un copil reușit sau care nu a găsit nimic de făcut continuă pe OK, iar unul eșuat pe Eroare. Starea, execuția și numele fluxului se află în state.subflow.
• Un flux nu trebuie să se atingă niciodată pe sine, nici direct, nici prin alt flux. Acest lucru este verificat la publicare, iar mesajul numește lanțul găsit.
• Fluxurile se pot apela pe cel mult trei niveluri. Deoarece fluxurile se editează separat, această limită este verificată de două ori: la publicare și în timp ce execuția chiar avansează.

Un punct de intrare de webhook îi dă unui sistem din afară un URL numai al lui. Acel sistem trimite JSON, fluxul din spatele URL-ului rulează, iar răspunsul este un cod de stare gol. Punctele de intrare stau la Scripturi, în fila Webhookuri, și sunt obiecte de sine stătătoare: același punct de intrare poate arăta către alt flux fără ca expeditorul să observe ceva.

1. 01Creați punctul de intrare și dați-i un nume pe care îl veți recunoaște mai târziu. URL-ul este generat și nu se poate alege: 32 de caractere aleatorii, adică 160 de biți, așa că ghicirea nu este o strategie.
2. 02Alegeți cum se legitimează expeditorul și copiați secretul. Este arătat o singură dată și niciodată după aceea; dacă se pierde, îl regenerați, iar atunci primiți și un URL nou.
3. 03Îndreptați punctul de intrare către un flux al cărui declanșator este un webhook. Punctul de intrare poate exista înaintea fluxului, iar până atunci o cerere este acceptată și primește un 202 care nu pornește nimic. Aceasta este ordinea în care oamenii construiesc asta în realitate, deci nu este tratată ca o greșeală.

Semnătura este cuvântul sha256, un semn egal și HMAC-SHA256 peste exact octeții mărcii de timp, ai unui punct și ai corpului, în hexazecimal cu litere mici. Merge în X-Provibr-Signature, iar marca de timp merge în X-Provibr-Timestamp, în secunde întregi de la epocă.

O cerere a cărei marcă de timp are peste 300 de secunde, sau se află în viitor, este refuzată cu un 401. Acea fereastră este o regulă adevărată și nu un ornament, pentru că marca de timp se află în materialul semnat: o cerere interceptată nu poate fi retrimisă mâine lipind peste ea o marcă proaspătă.

Semnarea unei cereri înseamnă o linie de openssl. Acest exemplu trimite un obiect mic; textul pentru terminal rămâne în engleză în mod intenționat, ca să corespundă cu ceea ce arată terminalul.

# Sign the raw body together with the timestamp, then post it.
SECRET="$PROVIBR_WEBHOOK_SECRET"
BODY='{"reason":"maintenance","attempt":1}'
TS=$(date +%s)
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -r | cut -d' ' -f1)

curl -sS -X POST 'https://app.provibr.com/api/hooks/flows/<your-slug>' \
  -H 'Content-Type: application/json' \
  -H "X-Provibr-Timestamp: $TS" \
  -H "X-Provibr-Signature: sha256=$SIG" \
  --data "$BODY"

Fiecare cerere lasă o chitanță, acceptată sau nu: rezultatul, starea întoarsă, adresa sursă în întregime și câți octeți au fost citiți cu adevărat. Corpul nu este păstrat niciodată. Chitanțele dispar după 90 de zile, mai devreme decât rulările însele, pentru că o adresă sursă este o dată cu caracter personal a cuiva care nu este clientul nostru.

Două întrebări care seamănă au aici două răspunsuri diferite. Cine a schimbat ce și când este o revizie. Ce a parcurs cu adevărat această rulare anume este o copie păstrată pe rularea însăși. O fotografie nu poate răspunde la prima întrebare, iar o revizie nu poate răspunde la a doua, deci există amândouă.

• Fiecare publicare scrie o revizie, chiar și o publicare care nu a schimbat nimic. Numărul urcă pe flux și nu este niciodată refolosit.
• Diferența dintre două revizii este o listă lizibilă și nu JSON brut: un nod adăugat, scos sau modificat cu câmpurile numite, un fir adăugat sau scos. Unde se află un nod pe pânză nu este o modificare.
• Restaurarea nu derulează înapoi. Scrie desenul vechi ca o revizie nouă peste istorie, cu o notă despre locul din care a venit.
• Fiecare rulare păstrează desenul pe care l-a parcurs. Modificarea ulterioară a unui flux nu rescrie niciodată ce a făcut o rulare mai veche.
• O rulare are un rând pentru fiecare nod vizitat, cu rezultatul și ieșirea prin care a plecat, și un rând pentru fiecare nod nevizitat, cu motivul. Nevizitat este un fapt care merită notat, nu o absență.
• Lista rulărilor filtrează după declanșator, stare și revizie și se exportă în CSV. Exportul se oprește la 5000 de rânduri și o spune chiar în fișier, în loc să se termine în tăcere.

Șabloanele de script țin alături o istorie proprie: fiecare versiune salvată a conținutului și o diferență linie cu linie între oricare două dintre ele.