Godine 2010. tvrtka imala je 50 poslužitelja i jednostavan mrežni model: backend, frontend i vatrozid. Broj poslužitelja rastao je, model se složio: stagingovi, izolirani VLAN s ACL, zatim VPN s VRF, VLAN s ACL na L2, VRF s ACL na L3. Zbuni? Bit će zabavnije.
Kada je broj poslužitelja dosegao 16.000, bilo je nemoguće raditi bez suza s tolikim brojem heterogenih segmenata. Stoga su osmislili drugo rješenje. Uzmeli su Netfilter okvir, dodali mu Consul kao izvor podataka i dobili brzi distribuirani vatrozid. Zamijenili su ACL na usmjerivačima i koristili ga kao vanjski i unutarnji vatrozid. Za dinamičko upravljanje alatom razvili su sustav BEFW koji se primjenjivao posvuda: od upravljanja pristupom korisnika u proizvodnu mrežu do izoliranja segmenata mreže jedni od drugih.
Kako to sve funkcionira i zašto biste se trebali zainteresirati za ovaj sustav, objasnit će Ivan Agarov () — voditelj grupe infrastrukturne sigurnosti sektora Održavanje u Minsk centru razvoja tvrtke. Ivan je obožavatelj SELinuxa, voli Perl, piše kod. Kao voditelj grupe informacijske sigurnosti, redovito radi s logovima, backupovima i R&D-om kako bi zaštitio Wargaming od hakera i osigurao rad svih igračkih poslužitelja u tvrtki.
Povijesne informacije
Prije nego što objasnim kako smo to radili, ispričat ću kako smo uopće došli do toga i zašto je to bilo potrebno. Za to se vraćamo devet godina unazad: 2010. godina, tek su se pojavili World of Tanks. Tvrtka Wargaming imala je otprilike 50 poslužitelja.
Grafikon rasta poslužitelja tvrtke.
Imali smo mrežni model. Za to vrijeme bio je optimalan.
Mrežni model u 2010.
Na frontendu žive loši momci koji nas žele srušiti, ali tu je vatrozid. Na backendu vatrozid ne postoji, ali tu je 50 poslužitelja, sve ih poznajemo. Sve funkcionira dobro.
Tijekom 4 godine broj poslužitelja povećao se 100 puta, na 5000. Pojavile su se prve izolirane mreže — stagingovi: oni ne mogu u produkciju, a često su se tamo vrtili sadržaji koji su mogli biti opasni.
Mrežni model u 2014.
I dalje smo koristili iste uređaje, a sav rad odvijao se na izoliranim VLAN-ovima: ACL-ovi se pišu za VLAN-ove koji dopuštaju ili zabranjuju određenu vezu.
Do 2016. godine broj poslužitelja dosegao je 8000. Wargaming je preuzimao druge studije, pojavljivale su se dodatne partnerske mreže. Naši su, ali ne baš: za partnere VLAN često ne radi, treba koristiti VPN s VRF-om, a izolacije su postajale složenije. Mješavina izolacija ACL je rasla.
Mrežni model 2016. godine.
Do početka 2018. godine park strojeva porastao je na 16 000. Segmenta je bilo 6, a ostale nismo brojili, uključujući zatvorene, u kojima su se čuvali financijski podaci. Pojavili su se mrežni kontejneri (Kubernetes), DevOps, oblačne mreže povezane putem VPN-a, na primjer, iz IVS-a. Pravila je bilo jako mnogo — bilo je bolno.
Mrežni model i metode izolacije 2018. godine.
Za izolaciju smo koristili: VLAN s ACL-om na L2, VRF s ACL-om na L3, VPN i još mnogo toga. Previše.
Problemi
Svi žive s ACL-om i VLAN-om. Što uopće nije u redu? Na to pitanje odgovor će dati Harold, skrivajući bol.
Bilo je mnogo problema, ali masovnih — pet.
- Geometrijski rast cijene za nova pravila. Svako novo pravilo dodavalo se duže nego prethodno, jer je prvo trebalo provjeriti nema li već takvog pravila.
- Nema vatrozida unutar segmenata. Segmenti su jedni od drugih nekako odvojeni, unutar već nedostaje resursa.
- Pravila su se dugo primjenjivala. Rukama jedno lokalno pravilo operateri su mogli napisati za sat. Globalno je trajalo nekoliko dana.
- Poteškoće s revizijom pravila. Točnije, bila je nemoguća. Prva pravila pisana su još 2010. godine, a veliki dio njihovih autora već nije radio u tvrtki.
- Niska razina kontrole infrastrukture. To je glavni problem — slabo smo znali što se s nama uopće događa.
Ovako je izgledao mrežni inženjer 2018. godine kada je čuo: „Treba još malo ACL-a”.
Rješenja
Početkom 2018. godine odlučeno je nešto učiniti po tom pitanju.
Cijena integracija neprekidno raste. Polazna točka bila je to što su veliki podatkovni centri prestali podržavati izolirane VLAN-ove i ACL-e, jer je ponestalo memorije na uređajima.
Rješenje: uklonili smo ljudski faktor i maksimalno automatizirali davanje pristupa.
Nova pravila primjenjuju se dugo. Rješenje: ubrzati primjenu pravila, učiniti je distribuiranom i paralelnom. Za to je potreban distribuirani sustav, kako bi se pravila sama isporučivala, bez rsync-a ili SFTP-a na tisuću sustava.
Nedostatak vatrozida unutar segmenata. Vatrozid unutar segmenata počeo je stizati do nas kada su se unutar jedne mreže pojavljivali različiti servisi. Rješenje: koristiti vatrozid na razini hosta — host-based firewalls. Gotovo svugdje imamo Linux, a svugdje postoje iptables, to nije problem.
Problemi s auditom pravila. Rješenje: pohraniti sva pravila na jednome mjestu radi pregleda i upravljanja, tako ćemo moći sve auditirati.
Nizak nivo kontrole nad infrastrukturom. Rješenje: provesti inventarizaciju svih servisa i pristupa među njima.
To je više administrativni proces nego tehnički. Ponekad imamo 200-300 novih izdanja tjedno, posebno tijekom akcija i praznika. A to je samo za jedan tim naših DevOps-a. Sa tolikim brojem izdanja nije moguće vidjeti i razumjeti koji su potrebni portovi, IP-ovi, integracije. Stoga su nam trebali posebno obučeni menadžeri servisa koji su ispitivali timove: "Što uopće imate i zašto ste to pokrenuli?"
Nakon svega što smo pokrenuli, mrežni inženjer u 2019. godini izgledao je već ovako.
Consul
Odlučili smo da sve što smo pronašli uz pomoć menadžera servisa stavimo u Consul i odatle ćemo pisati pravila iptables.
Kako smo odlučili to raditi?
- Sakupljamo sve servise, mreže i korisnike.
- Na temelju njih ćemo napraviti pravila iptables.
- Automatizirat ćemo kontrolu.
- ….
- PROFIT.
Consul nije udaljeni API, može raditi na svakom čvoru i pisati u iptables. Ostaje samo osmisliti automatska sredstva kontrole koja će ukloniti suvišno i velika većina problema će biti riješena! Ostatak ćemo doraditi u procesu.
Zašto Consul?
Dobar se pokazao. 2014-15. godine koristili smo ga kao backend za Vault, u kojem pohranjujemo lozinke.
Ne gubi podatke.. Tijekom korištenja Consul nije gubio podatke ni tijekom jedne nesreće. To je ogroman plus za sustav upravljanja vatrozidom.
P2P veze ubrzavaju širenje promjena.. Sa P2P sve promjene dolaze brzo, nije potrebno čekati satima.
Pogodan REST API. Razmatrali smo također Apache ZooKeeper, ali on nema REST API, morat ćemo koristiti improvizacije.
Radi i kao spremište ključeva (KV) i kao katalog (Service Discovery). Možemo pohranjivati istovremeno servise, kataloge, data centre. To je zgodno ne samo za nas, nego i za susjedne timove, jer gradeći globalni servis, razmišljamo o skalabilnosti.
Napisano na Go, koji je dio Wargamingovog stoga. Volimo ovaj jezik, imamo puno Go programera.
Moćan ACL sustav. U Consulu možete upravljati tko i što može pisati pomoću ACL-a. Jamčimo da pravila vatrozida neće imati nikakvih preklapanja i da nećemo imati problema s tim.
No, Consul ima i nedostatke.
- Ne skalira se unutar podatkovnog centra, osim ako nemate poslovnu verziju. Skalira se samo putem federacije.
- Vrlo ovisi o kvaliteti mreže i opterećenju poslužitelja. Consul neće raditi ispravno kao poslužitelj na opterećenom poslužitelju ako mreža ima problema, kao što su nepravilne brzine. To je povezano s P2P vezama i modelima distribucije ažuriranja.
- Teškoće s praćenjem dostupnosti. U statusu Consul može pisati da je sve u redu, a on je već odavno pao.
Većinu tih problema riješili smo tijekom eksploatacije Consula, zbog čega je i odabran. Firma ima planove za alternativni backend, ali naučili smo se boriti s problemima i trenutno živimo s Consulom.
Kako radi Consul
U hipotetski podatkovni centar postavljamo poslužitelje — od tri do pet. Jedan ili dva poslužitelja ne bi bila dovoljna: ne bi mogli organizirati kvorum i odlučiti tko je u pravu, a tko nije, kada se podaci ne poklapaju. Više od pet nema smisla, performanse će opasti.
Klijenti se povezuju s poslužiteljima u bilo kojem redoslijedu: isti agenti, samo s oznakom server = false.
Nakon toga klijenti dobijaju popis P2P veza i stvaraju veze međusobno.
Na globalnoj razini povezujemo nekoliko podatkovnih centara. Također se povezuju P2P i komuniciraju.
Kada želimo preuzeti podatke iz drugog podatkovnog centra, zahtjev ide od poslužitelja do poslužitelja. Ova shema se naziva Serf protokolom. Serf protokol, kao i Consul, je razvoj HashiCorpa.
Nekoliko važnih činjenica o Consulu
Consul ima dokumentaciju koja opisuje njegov rad. Navest ću samo odabrane činjenice koje vrijedi znati.
Consul poslužitelji biraju vođu među glasačima. Consul bira vođu iz popisa poslužitelja za svaki podatkovni centar, a svi zahtjevi idu samo k njemu, bez obzira na broj poslužitelja. Zastoj vođe ne dovodi do ponovnog izbora. Ako vođa nije izabran — zahtjevi se ne obrađuju.
Željeli ste horizontalno skaliranje? Žao mi je, ne.
Zahtev za drugi data centar ide od majstora do majstora, bez obzira na to na koji server je došao. Odabrani majstor prima 100% opterećenja, osim opterećenja za prosleđivanje zahteva. Aktuelna kopija podataka postoji na svim serverima data centra, ali odgovara samo jedan.
Jedini način da se skalira je uključivanje stale moda na klijentu.
U stale modu može se odgovarati bez kvoruma. To je režim u kojem odustajemo od konzistentnosti podataka, ali se čita malo brže nego obično, a odgovara bilo koji server. Naravno, zapis se vrši samo preko majstora.
Consul ne kopira podatke između data centara. Tokom prikupljanja federacije, svaki server će imati samo svoje podatke. Za druge se uvek obraća drugom.
Atomarnost operacija nije zagarantovana van transakcije. Zapamtite, da promeniti nešto možete ne samo vi. Ako želite drugačije, izvršite transakciju sa zaključavanjem.
Zaključavajuće operacije ne garantuju zaključavanje. Zahtev ide od majstora do majstora, a ne direktno, pa nema garancija da će zaključavanje raditi kada izvršavate zaključavanje, na primer, u drugom data centru.
ACL takođe ne garantuje pristup (u mnogim slučajevima). ACL može da ne proradi, jer se čuva u jednom data centru federacije — u ACL data centru (Primarni DC). Ako Data Centar ne odgovori, ACL neće raditi.
Jedan zamrznuti majstor može uzrokovati zamrzavanje cele federacije. Na primer, u federaciji sa 10 data centara, a u jednom loša mreža, i jedan majstor pada. Svi koji komuniciraju s njim će se u krug zamrznuti: ide zahtev, na njega nema odgovora, thread se zamrzava. Nećete moći znati kada će se to desiti, jednostavno će, za sat ili dva, cela federacija pasti. Ništa ne možete učiniti povodom toga.
Status, kvorum i izbori obrađuju se posebnim tokom. Ponovni izbori se neće dogoditi, status ništa neće pokazati. Mislite da imate živog Consula, tražite, i ništa se ne dešava — nema odgovora. U tom trenutku status pokazuje da je sve u redu.
Susretali smo se s tim problemom, morali smo rekonstrisati određene delove data centara kako bismo ga izbegli.
U poslovnoj verziji Consul Enterprise nema nekih nedostataka iznad. Ima mnogo korisnih funkcija: izbor glasova, raspodjela, skaliranje. Postoji samo jedan „ali“ — sustav licenciranja za distribuirani sustav je vrlo skup.
Life hack: rm -rf /var/lib/consul — lijek za sve bolesti agenta. Ako vam nešto ne radi, jednostavno obrišite svoje podatke i učitajte podatke iz kopije. Najvjerojatnije će Consul početi raditi.
BEFW
Sada ćemo razgovarati o tome što smo dodali u Consul.
— to je akronim od BackEndFireWall. Moralo se nekako nazvati proizvod, kada sam stvarao repozitorij, da se tu stave prvih testnih commit-ova. To ime je ostalo.
Predlošci pravila
Pravila su napisana u sintaksi iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Sve ide u lanac BEFW, osim ESTABLISHED, RELATED i localhost. Predložak može biti bilo što, ovo je samo primjer.
Koliko je BEFW koristan?
Usluge
Imamo servis, u njemu uvijek postoji port, čvor na kojem radi. Iz svog čvora možemo lokalno pitati agenta i saznati da imamo neki servis. Također možemo postaviti oznake.
Svaki servis koji je pokrenut i registriran u Consulu postaje pravilo iptables. Imamo SSH — otvaramo port 22. Bash skripta je jednostavna: curl i iptables, više nije potrebno.
Klijenti
Kako otvoriti pristup ne svima, već selektivno? Po imenu servisa skladištiti IP-liste u KV skladištu.
Na primjer, želimo da svi iz desete mreže mogu pristupiti servisu SSH_TCP_22. Dodajemo jedno malo polje TTL? i sada imamo privremena odobrenja, na primjer, na jedan dan.
Pristupi
Povezujemo servise i klijente: imamo servis, za svaki je spremno KV skladište. Sada ne dajemo pristup svima, već selektivno.
Grupe
Ako svaki put pišemo tisuće IP-ova za pristupe, umorit ćemo se. Smislit ćemo grupacije — poseban podskup u KV. Nazvat ćemo ga Alias (ili grupe) i pohraniti ćemo tamo grupe prema istom principu.
Povezujemo: sada možemo otvoriti SSH ne konkretno na P2P, već na cijelu grupu ili nekoliko grupa. Također imamo TTL — možemo dodavati i uklanjati iz grupe privremeno.
Integracija
Naš problem — ljudski faktor i automatizacija. Dok smo ga riješili na ovaj način.
Radimo s Puppetom i tamo prenosimo sve što se odnosi na sustav (kod aplikacija). U puppetdb (običan PostgreSQL) pohranjuje se popis usluga koje su pokrenute, a mogu se pronaći prema vrsti resursa. Tamo se također može vidjeti tko se s kim povezuje. Također imamo sustav za povlačenje zahtjeva i zahtjeva za spajanje.
Napisali smo befw-sync — najjednostavnije rješenje koje pomaže pri prijenosu podataka. Prvo sync cookies se obraćaju puppetdb-u. Tamo je postavljen HTTP API: tražimo koje usluge imamo, što treba učiniti. Zatim se šalje zahtjev u Consul.
Postoji li integracija? Da: napisali smo pravila, odobrili prihvaćanje Pull Requesta. Treba li neki port ili dodati host u neku grupu? Pull Request, pregled — više nikakvih "Pronađi 200 drugih ACL i pokušaj nešto s tim učiniti".
Optimizacija
Ping localhost s praznim nizom pravila traje 0,075 ms.
Dodajmo u ovaj niz 10 000 adresa iptables. Kao rezultat, ping će se povećati 5 puta: iptables je potpuno linearno, obrada svake adrese traje određeno vrijeme.
Za vatrozid u koji migriramo tisuće ACL-a, imamo mnogo pravila, a to unosi kašnjenje. To je loše za igračke protokole.
Ali ako stavimo 10 000 adresa u ipset ping će se čak smanjiti.
Bit je u tome da je 'O' (složenost algoritma) za ipset uvijek jednako 1, bez obzira na to koliko pravila ima. Istina je da postoji ograničenje — pravila ne smiju biti više od 65535. Dok s tim živimo: mogu se kombinirati, proširiti, napraviti dva ipseta u jednom.
Pohrana
Logičan nastavak procesa iteracija je pohranjivanje informacija o klijentima za uslugu u ipset.
Sada imamo isti SSH, i ne zapisujemo odmah 100 IP adresa, već postavljamo ime ipseta s kojim trebamo komunicirati i sljedeće pravilo PADAJ. Može se preoblikovati u jedno pravilo „Tko nije ovdje, taj DROP”, ali tako je preglednije.
Sada imamo pravila i skupove. Glavni cilj je napraviti skup prije nego što napišemo pravilo, jer inače iptables neće zapisati pravilo.
Opća shema
U obliku sheme, sve što sam rekao izgleda ovako.
Commitamo u Puppet, sve se šalje na host, usluge su ovdje, ipset tamo, a tko tamo nije upisan, ne može ući.
Dopusti & negiraj
Da bismo brzo spašavali svijet ili brzo nekoga isključili, na početku svih lanaca napravili smo dva ipseta: rules_allow i rules_deny. Kako to radi?
Na primjer, netko stvara opterećenje na našem Webu putem botova. Nekada je bilo potrebno pronaći njegov IP u logovima, odnijeti ga mrežnim inženjerima kako bi pronašli izvor prometa i blokirali ga. Sada to izgleda drugačije.
Šaljemo u Consul, čekamo 2,5 s, i gotovo. Budući da Consul brzo raspoređuje zahvaljujući P2P-u, funkcionira posvuda, u bilo kojem dijelu svijeta.
Jednom sam potpuno zaustavio WOT, pogriješivši s vatrozidom. rules_allow — to je naše osiguranje od takvih situacija. Ako negdje pogriješimo s vatrozidom, nešto se blokira, uvijek možemo poslati uvjetni 0.0/0, kako bismo brzo sve podigli. Kasnije ćemo sve popraviti ručno.
Drugi setovi
Mogu se dodavati bilo koji drugi setovi u prostoru $IPSETS$.
Zašto? Ponekad su nekome potrebni ipset, na primjer, kako bi simulirali isključenje nekog dijela klastera. Svatko može donijeti bilo koje setove, nazvati ih i oni će se povući iz Consula. Pri tome setovi mogu sudjelovati u pravilima iptables, ili biti poput NOOP: konzistencija će biti održavana demonima.
Korisnici
Nekada je bilo tako: korisnik se spojio na mrežu i preko domene dobio parametre. Prije pojave sljedeće generacije vatrozida, Cisco nije mogla razumjeti gdje je korisnik, a gdje IP. Zato je pristup bio odobren samo putem hostname-a računala.
Što smo mi učinili? Uključili smo se u trenutku dobivanja adrese. Obično je to dot1x, Wi-Fi ili VPN — sve ide preko RADIUS-a. Za svakog korisnika kreiramo grupu po imenu korisnika i stavljamo u nju IP s TTL-om koji jednako odgovara njegovom dhcp.lease — čim istekne, pravilo nestaje.
Sada možemo otvarati pristup uslugama, kao i u druge grupe, po korisničkom imenu. Oslobodili smo se boli s hostname-ima, kada se oni mijenjaju, i skinuli opterećenje s mrežnih inženjera, jer im više nije potrebna Cisco. Sada inženjeri sami postavljaju pristupe na svojim serverima.
Izolacija
Paralelno smo počeli razmatrati izolaciju. Menadžeri usluga su napravili inventar, a mi smo analizirali sve naše mreže. Razdvojit ćemo ih na iste grupe, a na potrebnim serverima grupe smo dodali, na primjer, u deny. Sada ista izolacija pozornice ulazi u rules_deny u produkciji, ali ne u samu produkciju.
Shema radi brzo i jednostavno: skinemo sve ACL-ove s servera, rasterećujemo hardver, smanjujemo broj izoliranih VLAN-ova.
Kontrola cjelovitosti
Ranije smo imali poseban okidač koji je prijavljivao kada netko ručno mijenja pravilo vatrozida. Pismao sam ogroman linter za provjeru pravila vatrozida, bilo je to složeno. Sada cjelovitost nadzire BEFW. Revnosno prati da pravila koja postavljaju ne budu mijenjana. Ako netko promijeni pravila vatrozida, sve će se vratiti. 'Brzo sam pokrenuo proxy da radim od kuće' — takve opcije više nema.
BEFW nadgleda ipset iz usluga i popisa u befw.conf, pravila usluga u lancu BEFW. Međutim, ne prati ostale lance i pravila i druge ipsete.
Zaštita od kvarova
BEFW uvijek pohranjuje posljednje uspješno stanje direktno u binarnoj strukturi state.bin. Ako nešto pođe po zlu, uvijek se vraća na ovaj state.bin.
To je osiguranje od nestabilnog rada Consula kada nije poslao podatke ili ako je netko pogriješio i koristio pravila koja se ne mogu primijeniti. Da ne ostanemo bez vatrozida, BEFW će se vratiti na posljednje stanje ako na nekom koraku dođe do greške.
U kritičnim situacijama, to je garancija da ćemo ostati s funkcionalnim vatrozidom. Otvaramo sve sivo mreže u nadi da će administrator doći i popraviti. Nekad ću to prebaciti u konfiguracije, ali trenutno imamo samo tri sive mreže: 10/8, 172/12 i 192.168/16. U okviru našeg Consula, to je važna značajka koja pomaže u daljnjem razvoju.
Demo: tijekom prezentacije Ivan demonstrira demo način rada BEFW-a. Najbolje je gledati demonstraciju na . Izvorni kod dema dostupan je .
Skriveni problemi
Reći ću o greškama s kojima smo se susreli.
ipset add set 0.0.0.0/0. Što se događa ako dodate u ipset 0.0.0.0/0? Hoće li se dodati sve IP adrese? Hoće li se otvoriti pristup internetu?
Ne, dobit ćemo grešku koja nas je koštala dva sata zastoja. Osim toga, greška ne radi od 2016. godine, leži u RedHat Bugzilla pod brojem #1297092, a otkrili smo je slučajno — iz izvještaja programera.
Sada u BEFW-u postoji strogo pravilo da 0.0.0.0/0 pretvara u dvije adrese: 0.0.0.0/1 i 128.0.0.0/1.
ipset restore set < file. Što radi ipset kada mu kažete restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Ništa slično — radi merge, a stare adrese ne nestaju, pristup ne zatvarate.
Grešku smo pronašli kada smo testirali izolaciju. Sada postoji prilično složen sustav — umjesto restore provodi se create temp, zatim restore flush temp i restore temp. Na kraju swap: za atomarnost, jer ako prvo provodite flush i u tom trenutku kada dođe neki paket, on će biti odbijen i nešto će poći po krivu. Zato tu ima malo crne magije.
consul kv get -datacenter=other. Kao što sam već spomenuo, mislimo da tražimo neke podatke, ali ćemo dobiti ili podatke ili grešku. To možemo raditi putem Consula lokalno, ali ni u tom slučaju ni to ne radi.
Lokalni Consul klijent je omotač oko HTTP API-ja. No, on jednostavno visne i ne odgovara ni na Ctrl+C, ni na Ctrl+Z, ni na što, samo na kill -9 u susjednoj konzoli. S tim smo se susreli kada smo gradili veliki klaster. No, trenutno nemamo rješenja, pripremamo se za ispravak te greške u Consulu.
Consul lider ne odgovara. Naš master u data centru ne odgovara, mislimo: "Vjerojatno će sada djelovati algoritam ponovnog izbora?"
Ne, neće djelovati, i praćenje ništa neće pokazati: Consul će reći da postoji commitment index, lider je pronađen, sve je u redu.
Kako se s tim borimo? service consul restart u cron svaka sat. Ako imate 50 poslužitelja - nije strašno. Kada ih bude 16 000, shvatit ćete kako to funkcionira.
Zaključak
Na kraju smo dobili sljedeće prednosti:
- 100% pokrivenost svih Linux strojeva.
- Brzina.
- Automatizaciju.
- Osvojili smo opremu i mrežne inženjere od ropstva.
- Pojavile su se mogućnosti za integraciju koje su gotovo beskrajne: bilo s Kubernetes, bilo s Ansible, bilo s Python.
Nedostaci: Consul s kojim sada moramo živjeti, i vrlo visoka cijena greške. Kao primjer, jednom sam u 6 navečer (prvoklasno vrijeme u Rusiji) nešto mijenjao u popisima mreža. Tada smo gradili izolaciju na BEFW. Negdje sam pogriješio, mislim da sam odabrao pogrešnu masku, ali sve se srušilo u dvije sekunde. Monitoring se pali, dolazi dežurni podrške: "Sve nam leži!" Šef odjela je posijedio dok je objašnjavao biznisu zašto se to dogodilo.
Cijena greške je tako visoka da smo osmislili vlastitu složenu proceduru prevencije. Ako ćete to primjenjivati u velikoj produkciji, nemojte davati master-token nad Consul svima bez reda. To će loše završiti.
Troškovi. Kodirao sam 400 sati sam. Moja ekipa od 4 osobe troši 10 sati mjesečno na podršku za sve. U usporedbi s cijenom bilo kojeg novog generacijskog vatrozida, to je besplatno.
Planovi. Dugoročni plan je pronalaženje alternativnog transporta umjesto ili dodatno uz Consul. Moguće je da će to biti Kafka ili nešto slično. No, u narednim godinama živjet ćemo na Consulu.
Nadolazeći planovi: integracija sa Fail2ban, monitoringu, s nftables, eventualno s drugim distribucijama, metrike, napredno praćenje, optimizacija. Podrška za Kubernetes također je negdje u planovima, jer trenutno imamo nekoliko klastera i želju.
Još od planova:
- obilazak anomalija u prometu;
- upravljanje mrežnom kartom;
- podrška za Kubernetes;
- izrada paketa za sve sustave;
- Web-UI.
Neprestano radimo na proširenju konfiguracije, povećanju metrika i optimizaciji.
Pridružite se projektu. Projekt je ispao sjajan, ali, nažalost, to je još uvijek projekt jednog čovjeka. Dođite na i pokušajte nešto učiniti: komitirati, testirati, nešto predložiti, dati svoju procjenu.
U međuvremenu se pripremamo za , koji će se održati 6. i 7. travnja u Sankt Peterburgu, i pozivamo programere visokoprasnih sustava . Iskusni govornici već znaju što raditi, a novajlicima u izlaganjima preporučamo barem . Sudjelovanje na konferenciji kao govornik ima nekoliko prednosti. O čemu se radi, možete pročitati, na primjer, na kraju .
Izvor: habr.com
