La esenco de la rakonto pri la plej populara pakaĵmanaĝero por Kubernetes povus esti prezentita per emoji:
- la skatolo estas Helm (kio estas la plej proksima al la plej nova eldono de Emoji);
- lock - sekureco;
- la vireto estas la solvo de la problemo.
Fakte, ĉio estos iom pli komplika, kaj la rakonto estas plena de teknikaj detaloj pri Kiel fari Helm sekura.
- Mallonge kio estas Helm, se vi ne sciis aŭ forgesis. Kiajn problemojn ĝi solvas kaj kie ĝi situas en la ekosistemo.
- Ni rigardu la Helm-arkitekturon. Neniu konversacio pri sekureco kaj kiel fari ilon aŭ solvon pli sekura estas kompleta sen kompreni la arkitekturon de la komponanto.
- Ni diskutu Helm-komponentojn.
- La plej brula demando estas la estonteco - la nova versio de Helm 3.
Ĉio en ĉi tiu artikolo validas por Helm 2. Ĉi tiu versio estas nuntempe en produktado kaj plej verŝajne estas tiu, kiun vi nuntempe uzas, kaj ĝi estas la versio, kiu enhavas la sekurecajn riskojn.
Pri la parolanto: Aleksandro Ĥajorov () disvolviĝas dum 10 jaroj, helpante plibonigi enhavon kaj aliĝis al la komitato . Nun li laboras ĉe Chainstack kiel disvolva gvidanto - ĉi tio estas hibrido inter evoluestro kaj persono, kiu respondecas pri liverado de finaj eldonoj. Tio estas, ĝi situas sur la batalkampo, kie ĉio okazas de la kreado de produkto ĝis ĝia funkciado.
Chainstack estas malgranda, aktive kreskanta noventrepreno, kies misio estas ebligi klientojn forgesi pri la infrastrukturo kaj komplekseco de funkciigado de malcentralizitaj aplikoj; la evolua teamo situas en Singapuro. Ne petu al Chainstack vendi aŭ aĉeti kriptan moneron, sed proponu paroli pri entreprenaj blokĉenaj kadroj, kaj ili feliĉe respondos al vi.
Kasko
Ĉi tio estas pakaĵa (diagramo) administranto por Kubernetes. La plej intuicia kaj universala maniero alporti aplikojn al Kubernetes-grupo.
Ni, kompreneble, parolas pri pli struktura kaj industria aliro ol krei viajn proprajn manifestojn YAML kaj verki malgrandajn utilecojn.
Helm estas la plej bona kiu estas nuntempe havebla kaj populara.
Kial Helm? Ĉefe ĉar ĝi estas subtenata de la CNCF. Cloud Native estas granda organizo kaj estas la gepatra kompanio por projektoj Kubernetes, ktpd, Fluentd kaj aliaj.
Alia grava fakto estas, ke Helm estas tre populara projekto. Kiam mi komencis paroli pri kiel sekurigi Helm en januaro 2019, la projekto havis mil stelojn en GitHub. Ĝis majo estis 12 mil da ili.
Multaj homoj interesiĝas pri Helm, do eĉ se vi ankoraŭ ne uzas ĝin, vi profitos sciante pri ĝia sekureco. Sekureco estas grava.
La kerna Helm-teamo estas subtenata de Microsoft Azure kaj tial estas sufiĉe stabila projekto, male al multaj aliaj. La liberigo de Helm 3 Alpha 2 meze de julio indikas, ke estas sufiĉe multaj homoj laborantaj pri la projekto, kaj ili havas la deziron kaj energion evoluigi kaj plibonigi Helm.
Helm solvas plurajn radikajn problemojn de aplika administrado en Kubernetes.
- Aplika pakado. Eĉ aplikaĵo kiel "Saluton, Mondo" en WordPress jam konsistas el pluraj servoj, kaj vi volas paki ilin kune.
- Administri la kompleksecon kiu venas kun administrado de ĉi tiuj aplikoj.
- Vivciklo kiu ne finiĝas post kiam la aplikaĵo estas instalita aŭ deplojita. Ĝi daŭre vivas, ĝi devas esti ĝisdatigita, kaj Helm helpas pri tio kaj provas alporti la ĝustajn rimedojn kaj politikojn por tio.
Ensakado ĝi estas organizita en klara maniero: ekzistas metadatumoj plene konforme al la laboro de regula pakadministranto por Linukso, Vindozo aŭ MacOS. Tio estas, deponejo, dependecoj de diversaj pakaĵoj, metainformoj por aplikaĵoj, agordoj, agordaj funkcioj, informindeksado ktp. Helm permesas akiri kaj uzi ĉion ĉi por aplikoj.
Komplekseco-Administrado. Se vi havas multajn aplikojn de la sama tipo, tiam parametrigo necesas. Ŝablonoj venas de ĉi tio, sed por eviti devi elpensi vian propran manieron krei ŝablonojn, vi povas uzi tion, kion Helm proponas el la skatolo.
Aplika Vivciklo-Administrado — laŭ mi, ĉi tiu estas la plej interesa kaj nesolvita demando. Jen kial mi venis al Helm en la tago. Ni bezonis observi la aplikaĵan vivociklon kaj volis movi niajn CI/KD kaj aplikaĵciklojn al ĉi tiu paradigmo.
Helm permesas vin:
- administri deplojojn, enkondukas la koncepton de agordo kaj revizio;
- sukcese efektivigi rollback;
- uzu hokojn por malsamaj eventoj;
- aldonu pliajn aplikajn kontrolojn kaj respondu al iliaj rezultoj.
Krome Helm havas "kuirilarojn" - grandega nombro da bongustaj aferoj, kiuj povas esti inkluzivitaj en formo de kromaĵoj, simpligante vian vivon. Kromaĵoj povas esti skribitaj sendepende, ili estas sufiĉe izolitaj kaj ne postulas harmonian arkitekturon. Se vi volas efektivigi ion, mi rekomendas fari ĝin kiel kromaĵo, kaj poste eble inkluzivi ĝin en kontraŭfluo.
Helm baziĝas sur tri ĉefaj konceptoj:
- Chart Repo — priskribo kaj aro de parametrigoj eblaj por via manifesto.
- config —tio estas, la valoroj kiuj estos aplikitaj (teksto, nombraj valoroj, ktp.).
- ĵeto kolektas la du suprajn komponentojn, kaj kune ili iĝas Release. Eldonaĵoj povas esti versiigitaj, tiel atingante fakorganizitan vivociklon: malgrandan en la momento de instalado kaj grandajn en la momenton de ĝisdatigo, plialtiĝo aŭ malfunkciigo.
Helm-arkitekturo
La diagramo koncipe prezentas la altnivelan arkitekturon de Helm.
Mi memorigu vin, ke Helm estas io rilata al Kubernetes. Tial ni ne povas fari sen Kubernetes-areto (rektangulo). La kube-apiserver-komponento loĝas sur la majstro. Sen Helm ni havas Kubeconfig. Helm alportas unu malgrandan binaron, se vi povas nomi ĝin tiel, Helm CLI-ilaĵo, kiu estas instalita sur komputilo, tekkomputilo, ĉefkomputilo - sur io ajn.
Sed ĉi tio ne sufiĉas. Helm havas servilan komponenton nomitan Tiller. Ĝi reprezentas la interesojn de Helm ene de la areto; ĝi estas aplikaĵo ene de la Kubernetes areto, same kiel iu ajn alia.
La sekva komponanto de Chart Repo estas deponejo kun diagramoj. Estas oficiala deponejo, kaj povas esti privata deponejo de firmao aŭ projekto.
Interago
Ni rigardu kiel la arkitekturaj komponantoj interagas kiam ni volas instali aplikaĵon uzante Helm.
- Ni parolas
Helm install, aliru la deponejon (Chart Repo) kaj ricevu Helm-diagramon.
- La Helm-utilo (Helm CLI) interagas kun Kubeconfig por eltrovi kiun areton kontakti.
- Ricevinte ĉi tiun informon, la utileco rilatas al Tiller, kiu situas en nia areto, kiel aplikaĵo.
- Tiller vokas Kube-apiserver por plenumi agojn en Kubernetes, krei iujn objektojn (servoj, podoj, kopioj, sekretoj ktp.).
Poste, ni malfaciligos la diagramon por vidi la atakvektoron, al kiu la tuta Helm-arkitekturo entute povas esti elmontrita. Kaj tiam ni provos protekti ŝin.
Vektoro de atako
La unua ebla malforta punkto estas privilegiita API-la uzanto. Kiel parto de la skemo, ĉi tio estas retpirato, kiu akiris administran aliron al la Helm CLI.
Senprivilegia API-uzanto povas ankaŭ prezenti danĝeron se ĝi estas ie proksime. Tia uzanto havos malsaman kuntekston, ekzemple, li povas esti fiksita en unu cluster nomspaco en la Kubeconfig-agordoj.
La plej interesa atakvektoro povas esti procezo kiu loĝas ene de areto ie proksime de Tiller kaj povas aliri ĝin. Ĉi tio povas esti retservilo aŭ mikroservo, kiu vidas la retan medion de la areto.
Ekzotika, sed ĉiam pli populara, atakvariaĵo implikas Chart Repo. Diagramo kreita de senskrupula aŭtoro povas enhavi nesekurajn rimedojn, kaj vi kompletigos ĝin per kredo. Aŭ ĝi povas anstataŭigi la diagramon, kiun vi elŝutas el la oficiala deponejo kaj, ekzemple, krei rimedon en formo de politikoj kaj pligrandigi ĝian aliron.
Ni provu fordefendi atakojn de ĉiuj ĉi tiuj kvar flankoj kaj eltrovi kie estas problemoj en la Helm-arkitekturo, kaj kie, eble, ekzistas neniuj.
Ni pligrandigu la diagramon, aldonu pliajn elementojn, sed konservu ĉiujn bazajn komponantojn.
La Helm CLI komunikas kun la Chart Repo, interagas kun Kubeconfig, kaj la laboro estas transdonita al la areto al la Tiller-komponento.
Tiller estas reprezentita per du objektoj:
- Tiller-deploy svc, kiu elmontras certan servon;
- Tiller-deploji pod (en la diagramo en ununura kopio en unu kopio), sur kiu la tuta ŝarĝo kuras, kiu aliras la areton.
Malsamaj protokoloj kaj kabaloj estas uzataj por interagado. De sekureca vidpunkto, ni plej interesiĝas pri:
- La mekanismo per kiu la Helm CLI aliras la diagraman deponejon: kia protokolo, ĉu ekzistas aŭtentigo kaj kio povas esti farita per ĝi.
- La protokolo per kiu Helm CLI, uzante kubectl, komunikas kun Tiller. Ĉi tio estas RPC-servilo instalita ene de la areto.
- Tiller mem estas alirebla por mikroservoj, kiuj loĝas en la areto kaj interagas kun la Kube-apiserver.
Ni diskutu ĉiujn ĉi tiujn areojn en ordo.
RBAC
Ne utilas paroli pri ajna sekureco por Helm aŭ iu ajn alia servo ene de la areto krom se RBAC estas ebligita.
Ŝajnas, ke ĉi tio ne estas la lasta rekomendo, sed mi certas, ke multaj homoj ankoraŭ ne ebligis RBAC eĉ en produktado, ĉar ĝi estas multe da tumulto kaj multaj aferoj devas esti agorditaj. Tamen mi kuraĝigas vin fari ĉi tion.
- reteja advokato por RBAC. Ĝi enhavas grandegan kvanton da interesaj materialoj, kiuj helpos vin starigi RBAC, montri kial ĝi estas bona kaj kiel esence vivi kun ĝi en produktado.
Mi provos klarigi kiel funkcias Tiller kaj RBAC. Tiller funkcias ene de la areto sub certa servokonto. Tipe, se RBAC ne estas agordita, ĉi tiu estos la superuzanto. En la baza agordo, Tiller estos administranto. Tial oni ofte diras, ke Tiller estas SSH-tunelo al via areto. Fakte, ĉi tio estas vera, do vi povas uzi apartan dediĉitan servokonton anstataŭ la Defaŭltan Servan Konton en la supra diagramo.
Kiam vi pravigigas Helm kaj instalas ĝin sur la servilo por la unua fojo, vi povas agordi la servokonton uzante --service-account. Ĉi tio permesos al vi uzi uzanton kun la minimuma bezonata aro de rajtoj. Vere, vi devos krei tian "girlandon": Role kaj RoleBinding.
Bedaŭrinde, Helm ne faros tion por vi. Vi aŭ via administranto de Kubernetes-grupo devas prepari aron da Roloj kaj Rolligadoj por la servo-konto anticipe por pasi Helm.
La demando ŝprucas - kia estas la diferenco inter Rolo kaj ClusterRole? La diferenco estas, ke ClusterRole funkcias por ĉiuj nomspacoj, male al regulaj Roloj kaj RoleBindings, kiuj nur funkcias por specialigita nomspaco. Vi povas agordi politikojn por la tuta areto kaj ĉiuj nomspacoj, aŭ personecigitaj por ĉiu nomspaco individue.
Menciindas, ke RBAC solvas alian grandan problemon. Multaj homoj plendas, ke Helm, bedaŭrinde, ne estas plurtenado (ne subtenas plurtenadon). Se pluraj teamoj konsumas areton kaj uzas Helm, estas esence neeble agordi politikojn kaj limigi ilian aliron ene de ĉi tiu areto, ĉar ekzistas certa servokonto sub kiu Helm funkcias, kaj ĝi kreas ĉiujn rimedojn en la areto de sub ĝi. , kio foje tre maloportuna. Ĉi tio estas vera - kiel la binara dosiero mem, kiel la procezo, Helm Tiller havas neniun koncepton de plurtenado.
Tamen ekzistas bonega maniero, kiu permesas vin ruli Tiller plurfoje en areto. Ne estas problemo pri tio, Tiller povas esti lanĉita en ĉiu nomspaco. Tiel, vi povas uzi RBAC, Kubeconfig kiel kuntekston, kaj limigi aliron al speciala Helm.
Ĝi aspektos tiel.
Ekzemple, estas du Kubeconfigs kun kunteksto por malsamaj teamoj (du nomspacoj): X-Teamo por la disvolva teamo kaj la administra grupo. La administra grupo havas sian propran larĝan Tiller, kiu situas en la Kube-sistema nomspaco, konforme progresinta servo-konto. Kaj aparta nomspaco por la evolua teamo, ili povos disfaldi siajn servojn al speciala nomspaco.
Ĉi tio estas realigebla aliro, Tiller ne estas tiom potenca, ke ĝi multe influos vian buĝeton. Ĉi tiu estas unu el la rapidaj solvoj.
Bonvolu agordi Tiller aparte kaj provizi Kubeconfig kun kunteksto por la teamo, por specifa programisto aŭ por la medio: Dev, Staging, Production (estas dubinde, ke ĉio estos sur la sama areto, tamen tio povas esti farita).
Daŭrigante nian rakonton, ni ŝanĝu de RBAC kaj parolu pri ConfigMaps.
ConfigMaps
Helm uzas ConfigMaps kiel sian datumbutikon. Kiam ni parolis pri arkitekturo, ekzistis neniu datumbazo ie ajn, kiu stokus informojn pri eldonoj, agordoj, malfunkciigo, ktp. ConfigMaps estas uzata por tio.
La ĉefa problemo pri ConfigMaps estas konata - ili principe estas nesekuraj; estas neeble stoki sentemajn datumojn. Ni parolas pri ĉio, kio ne devus iri preter la servo, ekzemple pasvortoj. La plej denaska maniero por Helm nun estas ŝanĝi de uzado de ConfigMaps al sekretoj.
Ĉi tio estas farita tre simple. Anstataŭigu la agordon de Tiller kaj specifu, ke la stokado estos sekreto. Tiam por ĉiu deplojo vi ricevos ne ConfigMap, sed sekreton.
Vi povus argumenti, ke sekretoj mem estas stranga koncepto kaj ne tre sekura. Tamen indas kompreni, ke la programistoj de Kubernetes mem faras tion. Komencante de versio 1.10, t.e. Jam de sufiĉe da tempo eblas, almenaŭ en publikaj nuboj, konekti la ĝustan stokadon por konservi sekretojn. La teamo nun laboras pri manieroj pli bone distribui aliron al sekretoj, individuaj podoj aŭ aliaj estaĵoj.
Pli bone estas transdoni Storage Helm al sekretoj, kaj ili, siavice, estas sekurigitaj centre.
Kompreneble ĝi restos limo de konservado de datumoj de 1 MB. Helm ĉi tie uzas etcd kiel distribuitan stokadon por ConfigMaps. Kaj tie ili konsideris, ke tio estas taŭga datumpeco por reproduktado ktp. Estas interesa diskuto pri ĉi tio ĉe Reddit, mi rekomendas trovi ĉi tiun amuzan legadon por la semajnfino aŭ legi la ekstrakton .
Chart Repos
Leteroj estas la plej socie vundeblaj kaj povas fariĝi fonto de "Viro en la mezo", precipe se vi uzas akcian solvon. Antaŭ ĉio, ni parolas pri deponejoj, kiuj estas elmontritaj per HTTP.
Vi certe devas elmontri Helm Repo per HTTPS - ĉi tio estas la plej bona elekto kaj estas malmultekosta.
atentu diagramo subskriba mekanismo. La teknologio estas simpla kiel diable. Ĉi tio estas la sama afero, kiun vi uzas en GitHub, kutima PGP-maŝino kun publikaj kaj privataj ŝlosiloj. Agordu kaj certigu, havante la necesajn ŝlosilojn kaj subskribante ĉion, ke ĉi tio estas vere via diagramo.
Krome, Helm-kliento subtenas TLS (ne en la servilflanka HTTP-senco, sed reciproka TLS). Vi povas uzi servilon kaj klientajn ŝlosilojn por komuniki. Verdire, mi ne uzas tian mekanismon ĉar mi ne ŝatas reciprokajn atestojn. Esence, - la ĉefa ilo por agordi Helm Repo por Helm 2 - ankaŭ subtenas bazan aŭtorikon. Vi povas uzi bazan aŭton se ĝi estas pli oportuna kaj trankvila.
Estas ankaŭ kromaĵo , kiu permesas vin gastigi Chart Repos sur Google Cloud Storage. Ĉi tio estas sufiĉe oportuna, funkcias bonege kaj estas sufiĉe sekura, ĉar ĉiuj priskribitaj mekanismoj estas reciklitaj.
Se vi ebligas HTTPS aŭ TLS, uzu mTLS kaj ebligas bazan aŭtorikon por plu redukti riskojn, vi ricevos sekuran komunikadkanalon kun Helm CLI kaj Chart Repo.
gRPC API
La sekva paŝo estas tre grava - sekurigi Tiller, kiu situas en la areto kaj estas, unuflanke, servilo, aliflanke, ĝi mem aliras aliajn komponantojn kaj provas ŝajnigi esti iu.
Kiel mi jam diris, Tiller estas servo kiu elmontras gRPC, la Helm-kliento venas al ĝi per gRPC. Defaŭlte, kompreneble, TLS estas malŝaltita. Kial ĉi tio estis farita estas diskutebla demando, ŝajnas al mi simpligi la aranĝon ĉe la komenco.
Por produktado kaj eĉ surscenigo, mi rekomendas ebligi TLS sur gRPC.
Miaopinie, male al mTLS por leteroj, ĉi tio taŭgas ĉi tie kaj estas farita tre simple - kreu PQI-infrastrukturon, kreu atestilon, lanĉu Tiller, translokigu la atestilon dum inicialigo. Post ĉi tio, vi povas ekzekuti ĉiujn Helm-komandojn, prezentante vin kun la generita atestilo kaj privata ŝlosilo.
Tiel vi protektos vin kontraŭ ĉiuj petoj al Tiller de ekster la areto.
Do, ni sekurigis la konektan kanalon al Tiller, ni jam diskutis pri RBAC kaj ĝustigis la rajtojn de la apiserver de Kubernetes, reduktante la domajnon kun kiu ĝi povas interagi.
Protektita Helmo
Ni rigardu la finan diagramon. Ĝi estas la sama arkitekturo kun la samaj sagoj.
Ĉiuj ligoj nun povas esti sekure desegnitaj verde:
- por Chart Repo ni uzas TLS aŭ mTLS kaj bazan aŭton;
- mTLS por Tiller, kaj ĝi estas elmontrita kiel gRPC-servo kun TLS, ni uzas atestojn;
- la areto uzas specialan servokonton kun Role kaj RoleBinding.
Ni signife sekurigis la areton, sed iu inteligenta diris:
"Povas ekzisti nur unu absolute sekura solvo - malŝaltita komputilo, kiu situas en betona skatolo kaj estas gardata de soldatoj."
Estas malsamaj manieroj manipuli datumojn kaj trovi novajn atakvektorojn. Tamen, mi certas, ke ĉi tiuj rekomendoj atingos bazan industrian normon por sekureco.
Bono
Ĉi tiu parto ne rekte rilatas al sekureco, sed ankaŭ estos utila. Mi montros al vi interesajn aferojn, pri kiuj malmultaj homoj scias. Ekzemple, kiel serĉi leterojn - oficialajn kaj neoficialajn.
En la deponejo Nun estas ĉirkaŭ 300 leteroj kaj du fluoj: stabila kaj kovilo. Ĉiu, kiu kontribuas, scias perfekte, kiel malfacile estas iri de kovilo al stalo, kaj kiel facile estas flugi el stalo. Tamen ĉi tio ne estas la plej bona ilo por serĉi leterojn por Prometeo kaj kion ajn alia vi ŝatas, pro unu simpla kialo - ĝi ne estas portalo, kie vi povas oportune serĉi pakaĵojn.
Sed estas servo , kio faras ĝin multe pli oportuna trovi leterojn. Plej grave, estas multaj pli da eksteraj deponejoj kaj preskaŭ 800 ĉarmoj disponeblaj. Krome, vi povas konekti vian deponejon se ial vi ne volas sendi viajn leterojn al stalo.
Provu hub.helm.sh kaj ni disvolvu ĝin kune. Ĉi tiu servo estas sub la Helm-projekto, kaj vi eĉ povas kontribui al ĝia UI se vi estas antaŭfina programisto kaj nur volas plibonigi la aspekton.
Mi ankaŭ ŝatus atentigi vian atenton Malferma Service Broker API-integriĝo. Ĝi sonas maloportuna kaj neklara, sed ĝi solvas problemojn, kiujn ĉiuj alfrontas. Mi klarigu per simpla ekzemplo.
Estas Kubernetes-grupo en kiu ni volas ruli klasikan aplikaĵon - WordPress. Ĝenerale, datumbazo estas necesa por plena funkcieco. Estas multaj malsamaj solvoj, ekzemple, vi povas lanĉi vian propran ŝtatplenan servon. Ĉi tio ne estas tre oportuna, sed multaj homoj faras ĝin.
Aliaj, kiel ni ĉe Chainstack, uzas administritajn datumbazojn kiel MySQL aŭ PostgreSQL por siaj serviloj. Tial niaj datumbazoj troviĝas ie en la nubo.
Sed aperas problemo: ni devas konekti nian servon kun datumbazo, krei datumbazan guston, translokigi la akreditaĵojn kaj iel administri ĝin. Ĉio ĉi estas kutime farita permane de la sistemadministranto aŭ programisto. Kaj ne estas problemo kiam estas malmultaj aplikoj. Kiam estas multaj, vi bezonas kombinaĵon. Estas tia rikoltmaŝino - ĝi estas Service Broker. Ĝi permesas vin uzi specialan kromprogramon por publika nuba areto kaj mendi rimedojn de la provizanto per Broker, kvazaŭ ĝi estus API. Por fari tion, vi povas uzi denaskajn ilojn de Kubernetes.
Ĝi estas tre simpla. Vi povas pridemandi, ekzemple, Administritan MySQL en Azure kun baza nivelo (ĉi tio povas esti agordita). Uzante la Azure API, la datumbazo estos kreita kaj preta por uzo. Vi ne bezonas malhelpi ĉi tion, la kromaĵo respondecas pri tio. Ekzemple, OSBA (Azure kromaĵo) resendos akreditaĵojn al la servo kaj transdonos ĝin al Helm. Vi povos uzi WordPress kun nuba MySQL, tute ne trakti administritajn datumbazojn kaj ne zorgi pri ŝtatplenaj servoj ene.
Ni povas diri, ke Helm funkcias kiel gluo, kiu unuflanke permesas vin disfaldi servojn, kaj aliflanke, konsumi la rimedojn de nubaj provizantoj.
Vi povas skribi vian propran kromprogramon kaj uzi ĉi tiun tutan historion surloke. Tiam vi simple havos vian propran kromprogramon por la kompania Cloudprovizanto. Mi rekomendas provi ĉi tiun aliron, precipe se vi havas grandskalon kaj volas rapide disfaldi dev, enscenigon aŭ la tutan infrastrukturon por funkcio. Ĉi tio faciligos la vivon por viaj operacioj aŭ DevOps.
Alia trovo, kiun mi jam menciis, estas helm-gcs kromaĵo, kiu ebligas al vi uzi Google-buckets (objektostokado) por stoki Helm-diagramojn.
Vi nur bezonas kvar komandojn por komenci uzi ĝin:
- instali la kromprogramon;
- iniciati ĝin;
- starigu la vojon al la sitelo, kiu situas en gcp;
- publikigi leterojn laŭ la norma maniero.
La beleco estas, ke la denaska gcp-metodo estos uzata por rajtigo. Vi povas uzi servokonton, programistan konton, kion ajn vi volas. Ĝi estas tre oportuna kaj kostas nenion por funkcii. Se vi, kiel mi, antaŭenigas la opsless-filozofion, tiam ĉi tio estos tre oportuna, precipe por malgrandaj teamoj.
Alternativoj
Helm ne estas la sola serva administradsolvo. Estas multaj demandoj pri ĝi, tial verŝajne la tria versio aperis tiel rapide. Kompreneble ekzistas alternativoj.
Ĉi tiuj povas esti specialigitaj solvoj, ekzemple, Ksonnet aŭ Metapartiklo. Vi povas uzi viajn klasikajn ilojn pri administrado de infrastrukturoj (Ansible, Terraform, Chef, ktp.) por la samaj celoj, pri kiuj mi parolis.
Fine estas solvo , kies populareco kreskas.
Operator Framework estas la ĉefa Helm-alternativo por konsideri.
Ĝi estas pli indiĝena de CNCF kaj Kubernetes, sed la baro al eniro estas multe pli alta, vi devas programi pli kaj priskribi manifestojn malpli.
Estas diversaj aldonaĵoj, kiel Draft, Scaffold. Ili multe plifaciligas la vivon, ekzemple, ili simpligas la ciklon de sendo kaj lanĉo de Helm por ke programistoj disfaldu testmedion. Mi nomus ilin potenculoj.
Jen vida diagramo de kie ĉio estas.
Sur la x-akso estas la nivelo de via persona kontrolo pri kio okazas, sur la y-akso estas la nivelo de denaskeco de Kubernetes. Helm-versio 2 falas ie en la mezo. En versio 3, ne ege, sed kaj kontrolo kaj la nivelo de denaskeco estis plibonigitaj. Solvoj ĉe la Ksonnet-nivelo ankoraŭ estas malsuperaj eĉ al Helm 2. Tamen, ili indas rigardi por scii kio alia estas en ĉi tiu mondo. Kompreneble, via agorda administranto estos sub via kontrolo, sed ĝi tute ne estas denaska de Kubernetes.
La Operatora Kadro estas absolute indiĝena de Kubernetes kaj permesas vin administri ĝin multe pli elegante kaj skrupule (sed memoru pri la enirnivelo). Prefere, ĉi tio taŭgas por speciala aplikaĵo kaj la kreado de administrado por ĝi, prefere ol amasa rikoltmaŝino por paki grandegan nombron da aplikoj uzante Helm.
Pligrandigiloj simple iom plibonigas kontrolon, kompletigas laborfluon aŭ tranĉas angulojn sur CI/KD-duktoj.
La estonteco de Helm
La bona novaĵo estas, ke venas Helm 3. La alfa versio de Helm 3.0.0-alpha.2 jam estis publikigita, vi povas provi ĝin. Ĝi estas sufiĉe stabila, sed funkcieco ankoraŭ estas limigita.
Kial vi bezonas Helm 3? Antaŭ ĉio, ĉi tio estas rakonto pri malapero de Tiller, kiel komponanto. Ĉi tio, kiel vi jam komprenas, estas grandega paŝo antaŭen, ĉar el la vidpunkto de la sekureco de la arkitekturo, ĉio estas simpligita.
Kiam Helm 2 estis kreita, kiu estis ĉirkaŭ la tempo de Kubernetes 1.8 aŭ eĉ pli frue, multaj el la konceptoj estis nematuraj. Ekzemple, la CRD-koncepto nun estas aktive efektivigita, kaj Helm faros uzu CRDstoki strukturojn. Eblos uzi nur la klienton kaj ne konservi la servilan parton. Sekve, uzu denaskajn Kubernetes-komandojn por labori kun strukturoj kaj rimedoj. Ĉi tio estas grandega paŝo antaŭen.
Aperos subteno por indiĝenaj OCI-deponejoj (Malferma Uja Iniciato). Ĉi tio estas grandega iniciato, kaj Helm interesiĝas ĉefe por afiŝi ĝiajn furorlistojn. Ĝi venas al la punkto, ke, ekzemple, Docker Hub subtenas multajn OCI-normojn. Mi ne konjektas, sed eble klasikaj provizantoj de deponejoj de Docker komencos doni al vi la ŝancon gastigi viajn Helm-diagramojn.
La polemika rakonto por mi estas Lua subteno, kiel ŝablona motoro por verki manuskriptojn. Mi ne estas granda ŝatanto de Lua, sed ĉi tio estus tute nedeviga funkcio. Mi kontrolis ĉi tion 3 fojojn - uzi Lua ne estos necesa. Tial tiuj, kiuj volas povi uzi Lua, tiuj, kiuj ŝatas Go, aliĝu al nia grandega tendaro kaj uzu go-tmpl por tio.
Fine, tio, kion mi certe mankis, estis skemo-apero kaj datumtipvalidigo. Ne estos pli da problemoj kun int aŭ ĉeno, ne necesas envolvi nulon per citiloj. JSONS-skemo aperos, kiu permesos al vi eksplicite priskribi ĉi tion por valoroj.
Estos peze reverkita evento-movita modelo. Ĝi jam estis koncipe priskribita. Rigardu la branĉon Helm 3, kaj vi vidos kiom da eventoj kaj hokoj kaj aliaj aferoj estis aldonitaj, kio multe simpligos kaj, aliflanke, aldonos kontrolon pri la deplojprocezoj kaj reagoj al ili.
Helm 3 estos pli simpla, pli sekura kaj pli amuza, ne ĉar ni ne ŝatas Helm 2, sed ĉar Kubernetes fariĝas pli progresinta. Sekve, Helm povas uzi la evoluojn de Kubernetes kaj krei bonegajn administrantojn por Kubernetes sur ĝi.
Alia bona novaĵo estas tio Aleksandro Ĥajorov diros al vi, Ni memorigu vin, ke la konferenco pri integriĝo de evoluaj, testaj kaj operaciaj procezoj okazos en Moskvo. 30 septembro kaj 1 oktobro. Vi ankoraŭ povas fari ĝin ĝis la 20-a de aŭgusto kaj rakontu al ni pri via sperto kun la solvo taskoj de la aliro DevOps.
Sekvu konferencajn kontrolejojn kaj novaĵojn ĉe и .
fonto: www.habr.com