Kas tas Consul ir kam jis reikalingas
Kai tavo infrastruktūra auga kaip mielės, o mikroservisų skaičius pradeda priminti telefonų knygą, greitai susiduri su problema – kaip visa tai valdyti? Čia ir ateina į pagalbą Consul. Tai ne tik service discovery įrankis, bet ir pilnavertė sistema, kuri padeda servisams rasti vieniems kitus, saugoti konfigūraciją ir net užtikrinti, kad viskas veikia kaip reikiant.
HashiCorp sukurtas Consul sprendžia labai konkrečią problemą: moderniose aplikacijose nebegalime tiesiog įrašyti IP adreso į konfigūraciją ir tikėtis, kad viskas veiks. Konteineriai gimsta ir miršta, servisai keliasi tarp serverių, o load balanceriai turi žinoti, kur siųsti užklausas. Tradicinis požiūris su statinėmis konfigūracijomis čia tiesiog neveikia.
Service discovery – kaip tai veikia praktikoje
Įsivaizduok, kad turi mikroservisų architektūrą su dešimtimis skirtingų servisų. Pavyzdžiui, tavo payment servisas turi kreiptis į user-management servisą. Senais laikais įrašytum kažką panašaus į http://user-service:8080 ir tiek. Bet kas nutinka, kai user-service perkelia į kitą serverį? Arba kai paleidžiamas papildomas instance’as load balancing’ui?
Consul sprendžia šią problemą elegantiškai. Kiekvienas servisas užsiregistruoja Consul’e, nurodydamas savo vardą, IP adresą, portą ir kitas svarbias detales. Kai payment servisui reikia pasiekti user-management, jis tiesiog paklausia Consul: „Ei, kur dabar yra user-management?”. Consul atsako su visais aktyviais instance’ais, ir payment servisas gali pasirinkti bet kurį iš jų.
Registracija atrodo maždaug taip:
{
"service": {
"name": "user-management",
"port": 8080,
"tags": ["production", "v2"],
"check": {
"http": "http://localhost:8080/health",
"interval": "10s"
}
}
}
Čia matome ne tik pagrindinę informaciją, bet ir health check konfigūraciją. Tai labai svarbu – Consul nuolat tikrina, ar servisas gyvas, ir automatiškai pašalina neveikiančius instance’us iš sąrašo.
DNS ir API – du būdai pasiekti servisus
Vienas iš gražiausių Consul dalykų – galima naudoti įprastą DNS. Tai reiškia, kad net senos aplikacijos, kurios nieko nežino apie Consul, gali juo naudotis. Tiesiog nurodai DNS serverį į Consul, ir viskas veikia. Pavyzdžiui, user-management.service.consul automatiškai resolvinasi į teisingą IP adresą.
Bet jei nori daugiau kontrolės ir funkcionalumo, yra HTTP API. Per jį gali ne tik gauti servisų sąrašą, bet ir filtruoti pagal tags, tikrinti health status, net gauti papildomą metadata. API užklausa atrodo paprastai:
curl http://localhost:8500/v1/catalog/service/user-management
Atsakymas bus JSON su visa reikalinga informacija. Tai ypač patogu, kai rašai custom integracijas arba nori dinamiškai keisti elgesį priklausomai nuo to, kokie servisai prieinami.
Key-Value store – konfigūracija, kuri gyvena
Be service discovery, Consul turi integruotą key-value store. Skamba paprastai, bet praktikoje tai neįtikėtinai galingas įrankis. Gali saugoti bet kokią konfigūraciją – nuo feature flags iki pilnų config failų. Ir svarbiausia – gali keisti šią konfigūraciją live, be aplikacijos restart’o.
Pavyzdžiui, sakai:
consul kv put config/payment-service/max-retry-attempts 5
Tavo payment servisas gali watch’inti šį key ir automatiškai atnaujinti savo konfigūraciją, kai reikšmė pasikeičia. Nebereikia deployt’inti naujos versijos tik tam, kad pakeistum vieną parametrą.
Dar geriau – gali organizuoti konfigūraciją hierarchiškai. Pavyzdžiui:
config/global/database-timeout
config/production/database-timeout
config/payment-service/database-timeout
Aplikacija gali skaityti nuo specifinio iki bendro, implementuodama fallback logiką. Tai leidžia turėti default reikšmes, bet override’inti jas specifiniams servisams ar aplinkoms.
Health checks – ne tik ping
Consul health checks yra daug sudėtingesni nei paprastas „ar servisas atsako”. Gali konfigūruoti įvairius check tipus: HTTP, TCP, script-based, TTL-based. Kiekvienas turi savo use case’ą.
HTTP check’ai puikiai tinka web servisams – tiesiog patikrina, ar endpoint’as grąžina 200 status kodą. TCP check’ai naudingi duomenų bazėms ar kitiems ne-HTTP servisams. Script-based check’ai leidžia paleisti bet kokį scriptą ir spręsti pagal exit code’ą. O TTL check’ai leidžia pačiam servisui pranešti, kad jis gyvas – naudingas variantas, kai servisas turi sudėtingą vidinę logiką ir pats geriausiai žino savo būklę.
Štai sudėtingesnis health check pavyzdys:
{
"check": {
"id": "payment-health",
"name": "Payment Service Health",
"http": "http://localhost:8080/health",
"method": "GET",
"interval": "10s",
"timeout": "1s",
"deregister_critical_service_after": "30m"
}
}
Tas deregister_critical_service_after parametras ypač svarbus – jei servisas neveikia 30 minučių, Consul automatiškai jį išregistruoja. Tai užtikrina, kad neturėsi „zombių” servisų, kurie užregistruoti, bet seniai nebeegzistuoja.
Multi-datacenter setup ir WAN gossip
Kai infrastruktūra išsiplečia per kelis datacenterius, Consul iš tiesų nušvinta. Jis natively palaiko multi-DC setups su WAN gossip protokolu. Tai reiškia, kad gali turėti Consul cluster’į kiekviename DC, ir jie visi žinos vienas apie kitą.
Praktiškai tai atrodo taip: kiekviename datacenter’yje turi lokalų Consul cluster’į. Servisai registruojasi lokaliame cluster’yje, bet gali query’inti servisus iš kitų DC. Pavyzdžiui:
curl http://localhost:8500/v1/catalog/service/user-management?dc=eu-west
Tai leidžia implementuoti sudėtingas failover strategijas. Jei servisas nepasiekiamas lokaliame DC, aplikacija gali automatiškai kreiptis į kitą DC. Arba gali turėti „read replicas” skirtinguose regionuose ir routinti traffic’ą pagal geografinę lokaciją.
WAN gossip protokolas užtikrina, kad informacija tarp DC sinchronizuojasi efektyviai, nenaudojant per daug bandwidth’o. Tai ne full replication – kiekvienas DC saugo savo duomenis, bet meta-informacija apie kitus DC yra prieinama.
Integracijos su kitais įrankiais
Consul puikiai integruojasi su modernia DevOps ekosistema. Su Kubernetes gali naudoti service mesh funkcionalumą per Consul Connect. Su Terraform – automatiškai provision’inti infrastruktūrą ir registruoti servisus. Su Vault – dinamiškai generuoti credentials.
Ypač įdomi integracija su Envoy proxy. Consul gali veikti kaip control plane Envoy’ui, automatiškai konfigūruodamas routing rules, load balancing ir net service-to-service encryption. Tai leidžia turėti pilnavertį service mesh be Istio sudėtingumo.
Pavyzdžiui, su Consul Connect gali apibrėžti, kurie servisai gali bendrauti tarpusavyje:
Kind = "service-intentions"
Name = "user-management"
Sources = [
{
Name = "payment-service"
Action = "allow"
},
{
Name = "*"
Action = "deny"
}
]
Tai zero-trust security modelis – default’u niekas negali kreiptis į servisą, nebent explicitly leista.
Kaip pradėti ir ko vengti
Pradėti su Consul galima labai paprastai – single node development režimu. Tiesiog parsisiuntus binary ir paleidus consul agent -dev. Bet production’e reikia cluster’io su bent trimis server node’ais dėl high availability.
Dažniausia klaida – bandyti viską iš karto. Pradėk nuo paprasto service discovery. Kai tai veikia, pridėk health checks. Paskui key-value store konfigūracijai. Ir tik tada žiūrėk į sudėtingesnius dalykus kaip service mesh ar multi-DC.
Kitas svarbus dalykas – monitoring. Consul turi metrics endpoint’ą, kurį gali scrape’inti su Prometheus. Būtinai stebėk raft latency, leader elections, ir failed health checks. Tai ankstyvieji warning signalai, kad kažkas negerai.
Ir nepamirški backup’ų. Nors Consul yra distributed sistema, verta reguliariai backup’inti snapshot’us. Ypač jei naudoji key-value store kritinei konfigūracijai. Komanda paprasta:
consul snapshot save backup.snap
Dėl security – production’e visada naudok ACL (Access Control Lists). Default’u Consul yra visiškai atviras, kas tikrai nėra gerai. Su ACL gali kontroliuoti, kas gali registruoti servisus, skaityti konfigūraciją, ar keisti settings.
Kas toliau su Consul ekosistema
Consul nuolat evoliucionuoja. Naujausiose versijose matome vis daugiau dėmesio service mesh funkcionalumui, geresnę Kubernetes integraciją, ir performance optimizacijas dideliems deployment’ams. HashiCorp aiškiai investuoja į tai, kad Consul taptų ne tik service discovery įrankiu, bet pilnaverte platformos dalimi.
Praktikoje tai reiškia, kad investicija į Consul mokymąsi ir implementaciją yra ilgalaikė. Tai ne dar vienas hype tool, kuris po metų bus pamirštas. Tai brandus produktas su didele community ir enterprise palaikymu.
Jei dar nenaudoji jokio service discovery sprendimo, Consul yra puikus pasirinkimas. Jei naudoji kažką kita – vis tiek verta pažiūrėti, ką Consul siūlo. Galbūt rasi funkcionalumo, kurio tau trūksta. O jei jau naudoji Consul – tikrai yra daugiau features, kuriuos dar neišnaudoji pilnai. Pabandyk key-value store, jei dar nenaudoji. Arba pažiūrėk į Connect, jei reikia service mesh. Sistema tikrai turi ką pasiūlyti įvairaus lygio projektams.
