TL; DR: do të ketë një përshkrim të Keycloak, një sistem kontrolli aksesi me burim të hapur, analiza e strukturës së brendshme, detajet e konfigurimit.
Hyrje dhe idetë kryesore
Në këtë artikull, ne do të shohim idetë themelore që duhen mbajtur parasysh kur vendosni një grup Keycloak në krye të Kubernetes.
Nëse dëshironi të dini më shumë rreth Keycloak, referojuni lidhjeve në fund të artikullit. Për t'u zhytur më shumë në praktikë, mund të studioni me një modul që zbaton idetë kryesore të këtij artikulli (udhëzuesi i nisjes është atje, ky artikull do të ofrojë një përmbledhje të pajisjes dhe cilësimeve, përafërsisht. përkthyes).
Keycloak është një sistem gjithëpërfshirës i shkruar në Java dhe i ndërtuar në krye të një serveri aplikacioni . Me pak fjalë, është një kornizë për autorizim që u jep përdoruesve të aplikacionit aftësitë e federatës dhe SSO (hyrje e vetme).
Ju ftojmë të lexoni zyrtarin ose për kuptim të hollësishëm.
Nisja e Keycloak
Keycloak kërkon dy burime të vazhdueshme të të dhënave për të ekzekutuar:
- Një bazë të dhënash e përdorur për të ruajtur të dhënat e vendosura, të tilla si informacionet e përdoruesit
- Cache e rrjetit të të dhënave, e cila përdoret për të memorizuar të dhënat nga baza e të dhënave, si dhe për të ruajtur disa meta të dhëna jetëshkurtra dhe që ndryshojnë shpesh, siç janë sesionet e përdoruesve. Zbatuar , e cila zakonisht është dukshëm më e shpejtë se baza e të dhënave. Por në çdo rast, të dhënat e ruajtura në Infinispan janë kalimtare - dhe nuk ka nevojë të ruhen askund kur grupi riniset.
Keycloak funksionon në katër mënyra të ndryshme:
- Normal - një dhe vetëm një proces, i konfiguruar nëpërmjet një skedari e pavarur.xml
- Grup i rregullt (opsioni i disponueshmërisë së lartë) - të gjitha proceset duhet të përdorin të njëjtin konfigurim, i cili duhet të sinkronizohet manualisht. Cilësimet ruhen në një skedar i pavarur-ha.xml, përveç kësaj ju duhet të bëni akses të përbashkët në bazën e të dhënave dhe një balancues të ngarkesës.
- Grupimi i domenit — Nisja e një grupi në modalitetin normal bëhet shpejt një detyrë rutinë dhe e mërzitshme ndërsa grupi rritet, pasi sa herë që ndryshon konfigurimi, të gjitha ndryshimet duhet të bëhen në secilën nyje të grupit. Mënyra e funksionimit të domenit e zgjidh këtë problem duke vendosur një vendndodhje të përbashkët të ruajtjes dhe duke publikuar konfigurimin. Këto cilësime ruhen në skedar domain.xml
- Replikimi midis qendrave të të dhënave — nëse doni të ekzekutoni Keycloak në një grup me disa qendra të dhënash, më shpesh në vende të ndryshme gjeografike. Në këtë opsion, çdo qendër e të dhënave do të ketë grupin e vet të serverëve Keycloak.
Në këtë artikull do të shqyrtojmë në detaje opsionin e dytë, d.m.th grumbull i rregullt, dhe ne gjithashtu do të prekim pak temën e riprodhimit midis qendrave të të dhënave, pasi ka kuptim që këto dy opsione të ekzekutohen në Kubernetes. Për fat të mirë, në Kubernetes nuk ka asnjë problem me sinkronizimin e cilësimeve të disa pods (nyjeve Keycloak), kështu që grupimi i domenit Nuk do të jetë shumë e vështirë për ta bërë.
Gjithashtu ju lutem vini re se fjala grumbull për pjesën tjetër të artikullit do të zbatohet vetëm për një grup nyjesh Keycloak që punojnë së bashku, nuk ka nevojë t'i referoheni një grupi Kubernetes.
Grup i rregullt i çelësave
Për të ekzekutuar Keycloak në këtë modalitet, ju duhet:
- konfiguroni bazën e të dhënave të jashtme të përbashkët
- instaloni balancuesin e ngarkesës
- kanë një rrjet të brendshëm me mbështetje IP multicast
Ne nuk do të diskutojmë ngritjen e një baze të dhënash të jashtme, pasi nuk është qëllimi i këtij artikulli. Le të supozojmë se ka një bazë të dhënash që funksionon diku - dhe ne kemi një pikë lidhjeje me të. Ne thjesht do t'i shtojmë këto të dhëna në variablat e mjedisit.
Për të kuptuar më mirë se si funksionon Keycloak në një grupim failover (HA), është e rëndësishme të dini se sa varet gjithçka nga aftësitë e grupimit të Wildfly.
Wildfly përdor disa nënsisteme, disa prej tyre përdoren si balancues i ngarkesës, disa për tolerancën e gabimeve. Balancuesi i ngarkesës siguron disponueshmërinë e aplikacionit kur një nyje grupi është e mbingarkuar, dhe toleranca e gabimeve siguron disponueshmërinë e aplikacionit edhe nëse disa nyje grupi dështojnë. Disa nga këto nënsisteme:
-
mod_cluster: Punon në lidhje me Apache si një balancues i ngarkesës HTTP, varet nga multicast TCP për të gjetur hostet si parazgjedhje. Mund të zëvendësohet me një balancues të jashtëm. -
infinispan: Një cache e shpërndarë duke përdorur kanalet JGroups si një shtresë transporti. Për më tepër, ai mund të përdorë protokollin HotRod për të komunikuar me një grup të jashtëm Infinispan për të sinkronizuar përmbajtjen e cache-it. -
jgroups: Ofron mbështetje komunikimi në grup për shërbime shumë të disponueshme bazuar në kanalet JGroups. Tubat e emërtuar lejojnë që instancat e aplikimit në një grup të lidhen në grupe në mënyrë që komunikimi të ketë karakteristika të tilla si besueshmëria, rregullsia dhe ndjeshmëria ndaj dështimeve.
Balancues i ngarkesës
Kur instaloni një balancues si një kontrollues hyrjeje në një grupim Kubernetes, është e rëndësishme të mbani parasysh gjërat e mëposhtme:
Keycloak supozon se adresa e largët e klientit që lidhet nëpërmjet HTTP me serverin e vërtetimit është adresa e vërtetë IP e kompjuterit të klientit. Cilësimet e balancuesit dhe hyrjes duhet të vendosin saktë kokat e HTTP X-Forwarded-For и X-Forwarded-Proto, dhe gjithashtu ruani titullin origjinal HOST. Versioni i fundit ingress-nginx (> 0.22.0)
Aktivizimi i flamurit proxy-address-forwarding duke vendosur një variabël mjedisi PROXY_ADDRESS_FORWARDING в true i jep Keycloak të kuptuarit se po punon pas një përfaqësuesi.
Ju gjithashtu duhet të aktivizoni seancat ngjitëse në hyrje. Keycloak përdor një memorie të shpërndarë Infinispan për të ruajtur të dhënat e lidhura me sesionin aktual të vërtetimit dhe sesionin e përdoruesit. Memoriet e fshehta funksionojnë me një pronar të vetëm si parazgjedhje, me fjalë të tjera, ai sesion i veçantë ruhet në një nyje në grup dhe nyjet e tjera duhet ta kërkojnë atë nga distanca nëse kanë nevojë për qasje në atë sesion.
Konkretisht, në kundërshtim me dokumentacionin, bashkëngjitja e një sesioni me emrin cookie nuk funksionoi për ne
AUTH_SESSION_ID. Keycloak ka një lak ridrejtues, ndaj ju rekomandojmë të zgjidhni një emër tjetër të skedarit të skedarit për seancën ngjitëse.
Keycloak gjithashtu bashkangjit emrin e nyjës që iu përgjigj e para AUTH_SESSION_ID, dhe meqenëse çdo nyje në versionin shumë të disponueshëm përdor të njëjtën bazë të dhënash, secila prej tyre një identifikues i veçantë dhe unik i nyjeve për menaxhimin e transaksioneve. Rekomandohet të vendosni JAVA_OPTS opsione jboss.node.name и jboss.tx.node.id unike për secilën nyje - mund të vendosni, për shembull, emrin e pod. Nëse vendosni një emër pod, mos harroni për kufirin prej 23 karakteresh për variablat jboss, kështu që është më mirë të përdorni një StatefulSet sesa një Deployment.
Një tjetër raketë - nëse pod fshihet ose rifillohet, cache e tij humbet. Duke marrë parasysh këtë, ia vlen të vendosni numrin e pronarëve të cache-ve për të gjitha cache në të paktën dy, në mënyrë që të mbetet një kopje e cache. Zgjidhja është vrapimi kur filloni podin, duke e vendosur atë në drejtori /opt/jboss/startup-scripts në enë:
Përmbajtja e skriptit
embed-server --server-config=standalone-ha.xml --std-out=echo
batch
echo * Setting CACHE_OWNERS to "${env.CACHE_OWNERS}" in all cache-containers
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
run-batch
stop-embedded-serverpastaj vendosni vlerën e ndryshores mjedisore CACHE_OWNERS ndaj të kërkuarve.
Rrjet privat me mbështetje multicast IP
Nëse përdorni Weavenet si një CNI, multicast do të funksionojë menjëherë - dhe nyjet tuaja Keycloak do të shohin njëri-tjetrin sapo të lëshohen.
Nëse nuk keni mbështetje multicast ip në grupin tuaj Kubernetes, mund të konfiguroni JGroups që të punojnë me protokolle të tjera për të gjetur nyje.
Opsioni i parë është përdorimi KUBE_DNSe cila përdor headless service për të gjetur nyjet Keycloak, thjesht kaloni JGroups emrin e shërbimit që do të përdoret për të gjetur nyjet.
Një tjetër mundësi është përdorimi i metodës KUBE_PING, i cili punon me API për të kërkuar nyje (duhet të konfiguroni serviceAccount me të drejta list и get, dhe më pas konfiguroni podet që të punojnë me këtë serviceAccount).
Mënyra se si JGroups gjejnë nyjet konfigurohet duke vendosur variabla të mjedisit JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Për KUBE_PING ju duhet të zgjidhni pods duke pyetur namespace и labels.
️ Nëse përdorni multicast dhe ekzekutoni dy ose më shumë grupe Keycloak në një grupim Kubernetes (le të themi një në hapësirën e emrave
production, i dyti -staging) - nyjet e një grupi Keycloak mund të bashkohen me një grup tjetër. Sigurohuni që të përdorni një adresë unike multicast për çdo grup duke vendosur variablajboss.default.multicast.addressиjboss.modcluster.multicast.addressвJAVA_OPTS.
Replikimi midis qendrave të të dhënave
Lidhje
Keycloak përdor grupe të shumta të veçanta të cache Infinispan për secilën qendër të të dhënave ku ndodhen grupimet Keycloack të përbëra nga nyjet Keycloak. Por nuk ka asnjë ndryshim midis nyjeve Keycloak në qendra të ndryshme të të dhënave.
Nyjet Keycloak përdorin një rrjet të jashtëm të të dhënave Java (serverët Infinispan) për komunikim midis qendrave të të dhënave. Komunikimi funksionon sipas protokollit .
Memoria e fshehtë Infinispan duhet të konfigurohet me atributin remoteStore, në mënyrë që të dhënat të mund të ruhen nga distanca (në një qendër tjetër të dhënash, përafërsisht. përkthyes) cache. Ekzistojnë grupe të veçanta infinispan midis serverëve JDG, në mënyrë që të dhënat të ruhen në JDG1 në vend site1 do të përsëritet në JDG2 në vend site2.
Dhe së fundi, serveri marrës JDG njofton serverët Keycloak për grupin e tij përmes lidhjeve të klientit, gjë që është një veçori e protokollit HotRod. Nyjet e tastierës janë të ndezura site2 përditësoni memoriet e tyre Infinispan dhe sesioni specifik i përdoruesit bëhet gjithashtu i disponueshëm në nyjet Keycloak në site2.
Për disa cache, është gjithashtu e mundur që të mos bëni kopje rezervë dhe të shmangni plotësisht shkrimin e të dhënave përmes serverit Infinispan. Për ta bërë këtë, duhet të hiqni cilësimin remote-store cache specifike Infinispan (në skedar i pavarur-ha.xml), pas së cilës disa specifike replicated-cache gjithashtu nuk do të nevojitet më në anën e serverit Infinispan.
Vendosja e cache-ve
Ekzistojnë dy lloje të memories në Keycloak:
-
Lokal. Ndodhet pranë bazës së të dhënave dhe shërben për të reduktuar ngarkesën në bazën e të dhënave, si dhe për të reduktuar vonesën e përgjigjes. Ky lloj cache ruan sferën, klientët, rolet dhe meta të dhënat e përdoruesit. Ky lloj cache nuk përsëritet, edhe nëse cache është pjesë e një grupi Keycloak. Nëse një hyrje në cache ndryshon, një mesazh për ndryshimin dërgohet te serverët e mbetur në grup, pas së cilës hyrja përjashtohet nga cache. Shih përshkrimin
workShihni më poshtë për një përshkrim më të detajuar të procedurës. -
Replikuar. Përpunon seancat e përdoruesve, shenjat jashtë linje dhe gjithashtu monitoron gabimet e identifikimit për të zbuluar përpjekjet për phishing me fjalëkalim dhe sulme të tjera. Të dhënat e ruajtura në këto cache janë të përkohshme, të ruajtura vetëm në RAM, por mund të përsëriten në të gjithë grupin.
Memoriet Infinispan
Seancat - një koncept në Keycloak, memorie të veçanta të quajtura authenticationSessions, përdoren për të ruajtur të dhënat e përdoruesve të veçantë. Kërkesat nga këto cache zakonisht nevojiten nga shfletuesi dhe serverët Keycloak, jo nga aplikacionet. Këtu hyn në lojë varësia nga sesionet ngjitëse dhe vetë cache-të e tilla nuk kanë nevojë të riprodhohen, edhe në rastin e modalitetit Active-Active.
Shenjat e Veprimit. Një koncept tjetër, zakonisht përdoret për skenarë të ndryshëm kur, për shembull, përdoruesi duhet të bëjë diçka në mënyrë asinkrone me postë. Për shembull, gjatë procedurës forget password cache actionTokens përdoret për të gjurmuar meta të dhënat e shenjave të lidhura - për shembull, një token është përdorur tashmë dhe nuk mund të aktivizohet përsëri. Ky lloj cache zakonisht duhet të kopjohet midis qendrave të të dhënave.
Ruajtja në memorie dhe plakja e të dhënave të ruajtura punon për të lehtësuar ngarkesën në bazën e të dhënave. Ky lloj memorizimi përmirëson performancën, por shton një problem të dukshëm. Nëse një server Keycloak përditëson të dhënat, serverët e tjerë duhet të njoftohen në mënyrë që ata të mund të përditësojnë të dhënat në memorien e tyre të fshehtë. Keycloak përdor cache lokale realms, users и authorization për ruajtjen e të dhënave nga baza e të dhënave.
Ekziston edhe një cache e veçantë work, i cili përsëritet në të gjitha qendrat e të dhënave. Ai në vetvete nuk ruan asnjë të dhënë nga baza e të dhënave, por shërben për të dërguar mesazhe në lidhje me plakjen e të dhënave në nyjet e grupimit midis qendrave të të dhënave. Me fjalë të tjera, sapo të dhënat përditësohen, nyja Keycloak u dërgon një mesazh nyjeve të tjera në qendrën e tij të të dhënave, si dhe nyjeve në qendrat e tjera të të dhënave. Pas marrjes së një mesazhi të tillë, çdo nyje fshin të dhënat përkatëse në memorien e saj lokale.
Sesionet e përdoruesve. Cache me emra sessions, clientSessions, offlineSessions и offlineClientSessions, zakonisht përsëriten ndërmjet qendrave të të dhënave dhe shërbejnë për të ruajtur të dhënat rreth sesioneve të përdoruesve që janë aktive ndërsa përdoruesi është aktiv në shfletues. Këto cache punojnë me aplikacionin që përpunon kërkesat HTTP nga përdoruesit fundorë, kështu që ato shoqërohen me sesione ngjitëse dhe duhet të përsëriten midis qendrave të të dhënave.
Mbrojtje me forcë brutale. Cache loginFailures Përdoret për të gjurmuar të dhënat e gabimit të hyrjes, si p.sh. sa herë një përdorues ka futur një fjalëkalim të pasaktë. Replikimi i kësaj cache është përgjegjësi e administratorit. Por për një llogaritje të saktë, ia vlen të aktivizoni përsëritjen midis qendrave të të dhënave. Por nga ana tjetër, nëse nuk i përsëritni këto të dhëna, do të përmirësoni performancën dhe nëse lind kjo çështje, replikimi mund të mos aktivizohet.
Kur hapni një grup Infinispan, duhet të shtoni përkufizime të cache në skedarin e cilësimeve:
<replicated-cache-configuration name="keycloak-sessions" mode="ASYNC" start="EAGER" batching="false">
</replicated-cache-configuration>
<replicated-cache name="work" configuration="keycloak-sessions" />
<replicated-cache name="sessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineSessions" configuration="keycloak-sessions" />
<replicated-cache name="actionTokens" configuration="keycloak-sessions" />
<replicated-cache name="loginFailures" configuration="keycloak-sessions" />
<replicated-cache name="clientSessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineClientSessions" configuration="keycloak-sessions" />Duhet të konfiguroni dhe nisni grupin Infinispan përpara se të filloni grupin Keycloak
Pastaj ju duhet të konfiguroni remoteStore për cache Keycloak. Për ta bërë këtë, mjafton një skript, i cili bëhet në mënyrë të ngjashme me atë të mëparshmin, i cili përdoret për të vendosur variablin CACHE_OWNERS, duhet ta ruani në një skedar dhe ta vendosni në një direktori /opt/jboss/startup-scripts:
Përmbajtja e skriptit
embed-server --server-config=standalone-ha.xml --std-out=echo
batch
echo *** Update infinispan subsystem ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)
echo ** Add remote socket binding to infinispan server **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})
echo ** Update replicated-cache work element **
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=work,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache sessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=sessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache offlineSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=offlineSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache clientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=clientSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache offlineClientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=offlineClientSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache loginFailures element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=loginFailures,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache actionTokens element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
cache=actionTokens,
remote-servers=["remote-cache"],
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache authenticationSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)
echo *** Update undertow subsystem ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)
run-batch
stop-embedded-serverMos harroni të instaloni JAVA_OPTS për nyjet Keycloak për të ekzekutuar HotRod: remote.cache.host, remote.cache.port dhe emrin e shërbimit jboss.site.name.
Lidhje dhe dokumentacion shtesë
Artikulli u përkthye dhe u përgatit për Habr nga punonjësit — kurse intensive, kurse video dhe trajnime korporative nga specialistë praktikues (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)
Burimi: www.habr.com