And why we replaced n8n with Laravel along the way
Kada smo počeli da gradimo našu internu platformu za automatizaciju, mislili smo da imamo savršen tehnološki stek. Imali smo n8n za orkestraciju tokova posla, Semaphore UI za pokretanje Ansible playbook-ova i jasnu viziju kako da u potpunosti automatizujemo hosting operacije. Nekoliko meseci kasnije, gledao sam u ono što se može opisati samo kao paukova mreža — i shvatio da moramo početi iz početka.
Ja sam tehnički direktor (CTO) u Savvii-ju, kompaniji za upravljani hosting sa sedištem u Holandiji. Specijalizovani smo za veb sajtove zasnovane na PHP-u — e-trgovinu, WordPress i slična radna opterećenja — i opslužujemo tri segmenta klijenata: manje klijente, preprodavce (resellere) i agencije. Svaki ima različite potrebe, različit obim i drugačija očekivanja.
Segment agencija je bio onaj gde smo osećali najveći pritisak. Agencije su zahtevni klijenti, ali njihovi interni timovi su često mešavina tehničkih i netehničkih ljudi. Njima je potreban grafički interfejs. Oni ne mogu raditi u komandnoj liniji. I što smo više agencija uvodili u sistem, to je bivalo očiglednije: bio nam je potreban pravi kontrolni panel podržan pouzdanom automatizacijom.
Ansible Tower i slični alati su nam bili na radaru, ali su bili ili previše složeni za postavljanje, imali nedoslednu dokumentaciju, ili su nosili brige oko performansi i suvereniteta podataka. Želeli smo rešenje koje možemo samostalno hostovati, ažurirati bez drame i prepustiti našem timu za podršku bez potrebe za nedeljama obuke.
Sveli smo izbor pre donošenja konačne odluke. Dva ključna faktora su brzo suzila izbor:
Suverenitet podataka. Nijedan alat koji čuva stanje ili akreditive u cloud-u treće strane nije dolazio u obzir. Samostalno hostovanje (self-hosting) nije imalo alternativu.
Korisničko iskustvo za netehničke korisnike. Naš tim prve linije podrške su odlični komunikatori, a ne sistem administratori. Šta god da izaberemo moralo je biti lako za korišćenje bez eskalacije svakog incidenta ka DevOps timu. Alati koje smo procenjivali obuhvatali su:
| Kriterijum | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Samostalno hostovan | Da — jedan binarni fajl / jednostavno pokretanje | Da — self-hosted izdanje | Da (AWX) / mešovito (AAP cloud opcije) | Da |
| UX za prvu liniju podrške | Izuzetna jasnoća zadataka i inventara | Dobar za autore; loš za operativnu primopredaju | Prekomplikovani RBAC koncepti; strmo za podršku | Usmeren na poslove; komplikovana Ansible ergonomija |
| Ansible inventar i izvršavanje | Izgrađen oko projekata i šablona | Nije kontrolna ravan za Ansible | Izvorni, ali složen put nadogradnje | Moguće; nije prvenstveno namenjen za Ansible |
| API za prilagođeni middleware | Konzistentan API za zadatke i projekte | Opsežan; potpuno drugačiji operativni model | API površina Tower-a varira po verzijama | Zreo API za poslove; drugačiji primitivi |
| Teret nadogradnje i održavanja | Bezbolne nadogradnje u praksi | Zavisi od kompleksnosti radnih tokova | Često težak (K8s / mnogobrojne zavisnosti) | Umeren; JVM potrošnja |
Semaphore UI je pobedio po oba kriterijuma. Instalacija je bila jednostavna. Nadogradnje su bile bezbolne. Interfejs je bio dovoljno čist da osoba bez inženjerskog znanja može tačno da razume šta se dešava. Povezivanje našeg postojećeg Ansible inventara bilo je praktično bez ikakvog trenja — jedina tačka gde nam je bila potrebna pomoć bila je konfiguracija inventara, što je brzo rešeno uz podršku. Dokumentacija Semaphore-a je bila temeljita i ulila nam je puno poverenje.
Početna arhitektura koristila je n8n kao orkestracioni sloj između HostBill-a (naplata), Semaphore UI-a i CMDB-a. Na papiru je izgledalo sjajno — vizuelno, low-code, bez potrebe za programerom za održavanje.
Vizuelni interfejs n8n-a je odličan za jednostavne linearne tokove. Ali čim su se pojavili uslovi, obrada grešaka, višestepeni povratni pozivi i upravljanje stanjem — preglednost je nestala. Ono što je počelo kao čist dijagram pretvorilo se u nepreglednu elektronsku šemu.
Nema bezbednog čuvanja stanja
Nije postojao bezbedan način za čuvanje međustanja između koraka u verziji koju smo koristili.
Bezbednosne nedoumice
Nedostatak pouzdanog maskiranja lozinki u logovima — ozbiljan rizik kada Ansible povratni pozivi uključuju generisane akreditive.
Krhki povratni pozivi
Rukovanje povratnim pozivima između n8n-a, Semaphore-a i CMDB-a zahtevalo je previše među-koraka što je činilo tokove nestabilnim.
Zamenili smo n8n namenskom Laravel aplikacijom. To je pravi middleware — ne "no-code" alat, već sistem koji naš tim u potpunosti poseduje, kontroliše i razume.
Bezbednosni model
Svaki server poseduje authorized_keys fajl koji tačno ograničava šta Semaphore SSH ključ zapravo sme da uradi. Korišćenjem command direktive u authorized_keys, definišemo precizno koje komande Semaphore sme da pokrene. Nakon početne postavke, Semaphore takođe gubi root pristup — može se povezati samo na korisničke naloge.
Ovo drastično smanjuje radijus potencijalne štete u slučaju bilo kakvog bezbednosnog incidenta.
Segment agencija, sa kojim smo počeli, pokreće oko 600 servera kroz ovu arhitekturu. Ukupan obim kroz sva tri segmenta će na kraju iznositi između 3.000 i 4.000 servera, i postepeno uvodimo celu platformu.
Semaphore-ov planer (scheduler) je sledeći na redu za automatska ažuriranja servera — što se trenutno rešava eksternim alatima, ali prelazi na Ansible pod kontrolom planera.
Nezavisnost podrške
Podrška može samostalno koristiti Semaphore bez uplitanja DevOps tima u svaki incident.
Obaveštenja u realnom vremenu
Slack integracija daje inženjerima trenutna upozorenja kada playbook ne uspe.
Pregledni šabloni
Mali broj šablona zahvaljujući prosleđivanju promenljivih putem API-ja — izbegnuto gomilanje.
Tačan CMDB
CMDB ostaje tačan automatski — nema više manuelnog održavanja.
Najvažnija stvar koju bismo uradili drugačije: posvetili bismo više vremena dizajnu arhitekture pre pisanja ijedne linije automatizacije. Morali smo da krenemo ispočetka više nego jednom jer nismo dovoljno pažljivo razmislili o tome koji tokovi mogu bezbedno da skaliraju i graciozno podnesu greške.
Arhitektura na prvom mestu
Posvetite više vremena dizajnu arhitekture pre pisanja prve linije automatizacije. Pažljivo razmislite o tokovima koji će skalirati i pouzdano rukovati greškama.
Procenjujte po korisničkom iskustvu, ne samo po mogućnostima
Ako vaš tim za podršku ne može samostalno da upotrebi alat u 2 sata ujutru bez pozivanja senior inženjera, to je pogrešan alat.
Suverenitet podataka je ključan
Znajte tačno gde se nalaze vaši akreditivi i stanje pre nego što uđete u produkciju.
Dobra dokumentacija je jasan signal kvaliteta
Ako je dokumentacija alata neorganizovana i zapuštena, najverovatnije je takav i sam softver.
Start with OSS, upgrade to Pro when your team grows. Enterprise support and SLA are available — including for hosting providers running thousands of servers.
