ProHoster > Blog > Administrim > Hyrje në Helm 3

Hyrje në Helm 3

Hyrje në Helm 3

ShĂ«n. pĂ«rkth.: 16 maji i kĂ«tij viti — njĂ« ngjarje e rĂ«ndĂ«sishme nĂ« zhvillimin e menaxherit tĂ« paketave pĂ«r Kubernetes — Helm. NĂ« kĂ«tĂ« ditĂ« u prezantua versioni i parĂ« alfa i versionit tĂ« ri tĂ« projektit — 3.0. Dalja e tij do tĂ« sjellĂ« ndryshime tĂ« rĂ«ndĂ«sishme dhe tĂ« pritura nĂ« Helm, pĂ«r tĂ« cilat shumĂ« nĂ« komunitetin Kubernetes kanĂ« shpresa tĂ« mĂ«dha. KĂ«tu bĂ«jmĂ« pjesĂ« dhe ne, pasi e pĂ«rdorim aktivisht Helm pĂ«r implementimin e aplikacioneve: e kemi integruar atĂ« nĂ« mjetin tonĂ« pĂ«r realizimin e CI/CD werf dhe rast pas rasti bĂ«jmĂ« njĂ« kontribut tĂ« vogĂ«l nĂ« zhvillimin e upstream. Ky pĂ«rkthim bashkon 7 shĂ«nime nga blogu zyrtar i Helm, tĂ« cilat janĂ« bĂ«rĂ« me rastin e daljes sĂ« parĂ« alfa tĂ« Helm 3 dhe flasin pĂ«r historinĂ« e projektit dhe karakteristikat kryesore tĂ« Helm 3. Autori i tyre Ă«shtĂ« Matt «bacongobbler» Fisher, njĂ« punonjĂ«s i Microsoft dhe njĂ« nga kujdestarĂ«t kryesorĂ« tĂ« Helm.

15 tetor 2015 lindi projekti, tani i njohur si Helm. VetĂ«m njĂ« vit pas themelimit, komuniteti Helm iu bashkua Kubernetes, duke punuar aktivisht nĂ« Helm 2. NĂ« qershor 2018, Helm u bĂ« pjesĂ« e CNCF si njĂ« projekt nĂ« zhvillim (incubating). TĂ« ribashkohemi nĂ« tĂ« tashmen — dhe ja, tashmĂ« Ă«shtĂ« nĂ« pĂ«rgatitje dalja e parĂ« alfa e Helm 3 (kjo dalje ka ndodhur nĂ« mes tĂ« majit — shĂ«n. pĂ«rkth.).

Në këtë material, do të flas për se si filluan gjërat, si arritëm në këtë fazë, do të paraqes disa veçori unike, të disponueshme në daljen e parë alfa të Helm 3, dhe do të shpjegoj se si planifikojmë të zhvillohemi më tej.

PĂ«rmbledhje:

  • historiku i krijimit tĂ« Helm;
  • njĂ« ndarje e butĂ« me Tiller-in;
  • repozitat e chart-Ă«ve;
  • menaxhimi i daljeve;
  • ndryshimet nĂ« varĂ«sitĂ« e chart-Ă«ve;
  • library charts;
  • çfarĂ« ndodh mĂ« tej?

Historia e krijimit të Helm

Lindja

Helm 1 filloi si një projekt Open Source, i krijuar nga kompania Deis. Ishim një startup i vogël, të përfshirë nga Microsoft në pranverën e 2017. Një nga projektet tona të tjera Open Source, gjithashtu me emrin Deis, kishte një mjet deisctl, i cili përdorej (mes të tjerash) për të instaluar dhe ndihmuar në operimin e platformës Deis në klasterin Fleet. Në atë kohë, Fleet ishte një nga platformat e para për orkestrimin e kontejnerëve.

Në mes të vitit 2015, vendosëm të ndryshojmë kursin dhe e transferuam Deis (në atë moment të riemëruar si Deis Workflow) nga Fleet në Kubernetes. Një nga të parat ishte rikonstruksioni i mjetit të instalimit deisctl. E përdorëm atë për instalimin dhe menaxhimin e Deis Workflow në klasterin Fleet.

Helm 1 u krijua sipas modelit të menaxherëve të njohur të paketave, si Homebrew, apt dhe yum. Qëllimi kryesor i tij ishte të thjeshtonte detyra si paketimi dhe instalimi i aplikacioneve në Kubernetes. Zyrtarisht, Helm u prezantua në vitin 2015 në konferencën KubeCon në San Francisco.

Përpjekja jonë e parë me Helm funksionoi, por nuk kaloi pa kufizime të rëndësishme. Ai merrte një grup manifestesh Kubernetes, të pasuruara me gjeneratorë si blloqe YAML hyrëse. (front-matter)*, dhe ngarkonte rezultatet në Kubernetes.

* Shën. përkth.: Që nga versioni i parë, përshkrimi i burimeve Kubernetes përdori sintaksën YAML, dhe gjatë shkruarjes së konfigurimeve u mbështetën shabllone Jinja dhe skenarë Python. Më shumë rreth kësaj dhe funksionit të versionit të parë të Helm gjithashtu kemi shkruar në kapitullin "Historia e shkurtër e Helm" këtij materiali.

Për shembull, për të zëvendësuar një fushë në skedarin YAML, duhej të shtonim në manifest këtë konstrukcion:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

ËshtĂ« e shkĂ«lqyeshme qĂ« sot ekzistojnĂ« shabllonizues, apo jo?

PĂ«r shumĂ« arsye, ky instalues i hershĂ«m i Kubernetes kĂ«rkonte njĂ« listĂ« tĂ« shkruar saktĂ«sisht tĂ« manifest-fajllave dhe realizonte vetĂ«m njĂ« sekuencĂ« tĂ« vogĂ«l fikse ngjarjesh. PĂ«rdorimi i tij ishte aq i vĂ«shtirĂ«, saqĂ« ekipi R&D i Deis Workflow kishte vĂ«shtirĂ«si kur pĂ«rpiqej tĂ« transferonte produktin e tij nĂ« kĂ«tĂ« platformĂ« – megjithatĂ«, farat e ideve ishin mbjellĂ«. PĂ«rpjekja jonĂ« e parĂ« u bĂ« njĂ« mundĂ«si e shkĂ«lqyer pĂ«r tĂ« mĂ«suar: kuptuam se ishim vĂ«rtet tĂ« pasionuar pas krijimit tĂ« mjeteve pragmatike, qĂ« adresonin probleme tĂ« pĂ«rditshme pĂ«r pĂ«rdoruesit tanĂ«.

Duke u mbështetur në përvojën e gabimeve të kaluara, filluam zhvillimin e Helm 2.

Krijimi i Helm 2

Në fund të vitit 2015, ekipi i Google na kontaktoi. Ata po punonin mbi një mjet të ngjashëm për Kubernetes. Menaxher i Zbatimeve për Kubernetes ishte një port i një instrumenti ekzistues që ishte përdorur për Google Cloud Platform. "A doni, - pyetën ata, - të kalojmë disa ditë duke diskutuar ngjashmëritë dhe ndryshimet?"

NĂ« janar 2016, ekipet e Helm dhe Menaxherit tĂ« Zbatimeve u takuan nĂ« Seattle pĂ«r tĂ« ndarĂ« ide. Bisedimet pĂ«rfunduan me njĂ« plan ambicioz: tĂ« bashkonim tĂ« dy projektet pĂ«r tĂ« krijuar Helm 2. SĂ« bashku me Deis dhe Google, ekipi i zhvilluesve u bashkua me djemtĂ« nga SkippBox (tani pjesĂ« e Bitnami – shĂ«n. pĂ«rk.), dhe ne filluam punĂ«n mbi Helm 2.

Ne donimë të ruajmë thjeshtësinë e përdorimit të Helm, por të shtojmë të mëposhtmet:

  • shabllone chart pĂ«r personalizim;
  • menaxhim brenda-klaster pĂ«r ekipet;
  • repo chart tĂ« klasit tĂ« parĂ«;
  • formate tĂ« qĂ«ndrueshme paketash me mundĂ«si nĂ«nshkrimi;
  • njĂ« angazhim tĂ« fortĂ« pĂ«r versionimin semantik dhe ruajtjen e pĂ«rputhshmĂ«risĂ« prapa midis versioneve.

Për të arritur këto qëllime, ekosistemi i Helm mori një element të dytë. Ky komponent brenda-klaster quhej Tiller dhe merrej me instalimin dhe menaxhimin e chart-eve të Helm.

QĂ« nga lansimi i Helm 2 nĂ« vitin 2016, Kubernetes ka pĂ«rjetuar disa inovacione tĂ« rĂ«ndĂ«sishme. U prezantua menaxhimi i aksesit tĂ« bazuar nĂ« role (RBAC), i cili nĂ« fund zĂ«vendĂ«soi kontrollin e aksesit tĂ« bazuar nĂ« atribute (ABAC). U prezantuan lloje tĂ« reja burimesh (Deployments nĂ« atĂ« kohĂ« ende ishin nĂ« statusin beta). U shpikĂ«n Definicionet e Burimeve tĂ« Personalizuara (fillimisht ato u quajtĂ«n Burime tĂ« TretĂ« ose TPR). Dhe mĂ« e rĂ«ndĂ«sishmja — u paraqit njĂ« grup praktikash mĂ« tĂ« mira.

Në sfondin e këtyre ndryshimeve, Helm vazhdoi të shërbente besnikërisht për përdoruesit e Kubernetes. Pas tre vjetësh dhe shumë shtesash të reja, u bë e qartë se ishte koha për të bërë ndryshime të rëndësishme në bazën e kodit në mënyrë që Helm të mund të përmbushte nevojat në rritje të ekosistemit në zhvillim.

Një lamtumirë e butë me Tiller-in

Gjatë zhvillimit të Helm 2, ne prezantuam Tiller si pjesë e integrimit tonë me Menaxherin e Shpërndarjeve nga Google. Tiller kishte një rol të rëndësishëm për ekipet që punonin brenda një klasteri të përbashkët: ai lejonte specialistë të ndryshëm, që shfrytëzojnë infrastrukturën, të ndërveprojnë me të njëjtin grup nxjerrjesh.

Që nga aktivizimi i kontrollit të qasjes me rol (RBAC) si të parazgjedhur në Kubernetes 1.6, puna me Tiller-in në prodhim është bërë më e komplikuar. Për shkak të numrit të madh të politikave të mundshme të sigurisë, pozita jonë ishte që të sugjerojmë një konfigurim lehtësues si të parazgjedhur. Kjo i lejonte fillestarët të eksperimentonin me Helm dhe Kubernetes pa pasur nevojë të merreshin fillimisht me konfigurimet e sigurisë. Fatkeqësisht, kjo konfigurim lehtësues mund të jepte përdoruesit një gamë shumë të gjerë lejesh që nuk i duheshin. Inxhinierët DevOps dhe SRE duhej të mësojnë hapa të tjerë operativ për të instaluar Tiller në një klasor multi-tenant.

Duke u njohur se si përfaqësuesit e komunitetit përdorin Helm në situata të caktuara, e kuptuam se sistemi i menaxhimit të lëshimeve Tiller nuk kishte nevojë të mbështetej në një komponent brenda klasorit për të ruajtur gjendjet ose për të funksionuar si një qendër qendrore me informacion mbi lëshimin. Në vend të kësaj, ne mund të marrim informacion thjesht nga API-server-i i Kubernetes, të gjenerojmë chart në anën e klientit dhe të ruajmë një regjistrim të instalimit në Kubernetes.

Detyra kryesore e Tiller-it mund të realizohej edhe pa të, kështu që një nga vendimet tona të para në lidhje me Helm 3 ishte braktisja e plotë e Tiller-it.

Me largimin e Tiller-it, modeli i sigurisë së Helm-it është thjeshtuar radikalisht. Helm 3 tani mbështet të gjitha metodat e moderne të sigurisë, identifikimit dhe autorizimit të Kubernetes-it aktual. Lejet e Helm-it përcaktohen përmes file kubeconfig. Administratorët e klasorit mund të kufizojnë të drejtat e përdoruesve me çdo shkallë detajimi. Lëshimet akoma ruajnë brenda klasorit, dhe funksionaliteti tjetër i Helm-it mbetet i pandryshuar.

Repozitat e chart-eve

Në një nivel të lartë, një repozitë chart-e është vendi ku mund të ruhet dhe ndahen chart-et. Klienti Helm paket dhe dërgon chart-et në repozitë. Thjesht, një repozitë chart-e është një server HTTP primitiv me një skedë index.yaml dhe disa chart-e të paketuar.

Megjithëse ka disa përfitime që API-ja e repozitës chart-e përmbush kërkesat themelore për ruajtje, ajo ka gjithashtu disa disavantazhe:

  • RepozitorĂ«t e chart-ave janĂ« pak tĂ« pĂ«rshtatshĂ«m me shumicĂ«n e implementimeve tĂ« sigurisĂ« qĂ« kĂ«rkohen nĂ« mjedisin e prodhimit. Prania e njĂ« API standard pĂ«r autentifikimin dhe autorizimin Ă«shtĂ« jashtĂ«zakonisht e rĂ«ndĂ«sishme nĂ« skenarĂ«t e prodhimit.
  • Veglat e Helm-it pĂ«r ndjekjen e origjinĂ«s sĂ« chart-ave, tĂ« pĂ«rdorura pĂ«r nĂ«nshkrimin, verifikimin e integritetit dhe origjinĂ«n e chart-it, janĂ« njĂ« pjesĂ« opsionale e procesit tĂ« publikimit tĂ« Chart-it.
  • NĂ« skenarĂ«t shumĂ«-pĂ«rdorues, i njĂ«jti chart mund tĂ« ngarkohet nga njĂ« pĂ«rdorues tjetĂ«r, duke dyfishuar hapĂ«sirĂ«n e nevojshme pĂ«r ruajtjen e tĂ« njĂ«jtit pĂ«rmbajtje. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, janĂ« zhvilluar repo mĂ« tĂ« mençur, megjithatĂ« ato nuk janĂ« pjesĂ« e specifikimit formal.
  • PĂ«rdorimi i njĂ« skedari indeksi unik pĂ«r kĂ«rkimin, ruajtjen e metadatanĂ«ve dhe marrjen e chart-ave ka komplikuar zhvillimin e implementimeve tĂ« sigurta shumĂ«-pĂ«rdoruese.

Projekti Docker Distribution (i njohur gjithashtu si Docker Registry v2) është pasardhësi i Docker Registry dhe në fakt përfaqëson një grup mjetesh për paketimin, dërgimin, ruajtjen dhe shpërndarjen e imazheve Docker. Shumë shërbime të mëdha në cloud ofrojnë produkte të bazuara në Distribution. Falë kësaj vëmendjeje të rritur, projekti Distribution ka përfituar nga përmirësime të shumta për vite me radhë, praktika më të mira në fushën e sigurisë dhe testimi në kushte "ndër" që e kanë bërë atë një nga heronjtë më të suksesshëm të papërmendur të botës Open Source.

Por a e dini se projekti Distribution është zhvilluar për shpërndarjen e çdo forme përmbajtjeje, jo vetëm imazheve të kontejnerëve?

Falë përpjekjeve Open Container Initiative (ose OCI), Helm-chart-et mund të vendosen në çdo instancë të Distribution. Ndërsa ky proces është ende në fazën eksperimentale. Puna për mbështetje të login-vet dhe funksione të tjera të nevojshme për një Helm 3 të plotë ende nuk është përfunduar, por ne jemi shumë të lumtur për mundësinë për të mësuar nga zbulimet e bëra nga ekipet OCI dhe Distribution gjatë këtyre viteve. Falë mentorimit dhe udhëheqjes së tyre, ne po mësojmë se çfarë është operimi i një shërbimi me akses të lartë në shkallë të madhe.

Një përshkrim më i detajuar i disa ndryshimeve të ardhshme në repositorët e Helm-chart-eve është në dispozicion në lidhje.

Menaxhimi i lëshimeve

Në Helm 3, gjendja e aplikacionit ndjeket brenda klasterit nga një çift objektesh:

  • Objekti i lirimit — pĂ«rfaqĂ«son njĂ« instancĂ« tĂ« aplikacionit;
  • sekreti i versionit tĂ« lĂ«shimit — pĂ«rfaqĂ«son gjendjen e dĂ«shiruar tĂ« aplikacionit nĂ« njĂ« moment tĂ« caktuar nĂ« kohĂ« (p.sh., lĂ«shimi i njĂ« versioni tĂ« ri).

Thirrja helm install krijon objektin e lëshimit dhe sekretin e versionit të lëshimit. Thirrja helm upgrade kërkon një objekt të lëshimit (të cilin mund ta ndryshojë) dhe krijon një sekret të ri të versionit të lëshimit, i cili përmban vlera të reja dhe manifestin e përgatitur.

Objekti i lëshimit përmban informacion rreth lëshimit, ku lëshimi është një instalim specifik i një grafiku dhe vlerave të emërtuara. Ky objekt përshkruan metadata të nivelit të lartë për lëshimin. Objekti i lëshimit ruhet gjatë gjithë ciklit të jetës së aplikacionit dhe është pronari i të gjithë sekretëve të versionit të lëshimit, si dhe të të gjithë objekteve që krijohen drejtpërdrejt nga grafiku i Helm-it.

Sekreti i versionit të lëshimit lidh lëshimin me një seri rishikimesh (instalim, përmirësime, kthime prapa, fshirje).

NĂ« Helm 2, rishikimet ishin ekskluzivisht sekondare. Thirrja helm install krijonte v1, pĂ«rmirĂ«simi i mĂ«passhĂ«m (upgrade) — v2, e kĂ«shtu me radhĂ«. LĂ«shimi dhe sekreti i versionit tĂ« lĂ«shimit ishin tĂ« kombinuar nĂ« njĂ« objekt tĂ« njohur si rishikim. Rishikimet ruheshin nĂ« tĂ« njĂ«jtin hapĂ«sirĂ« emĂ«rtimi si Tiller, qĂ« nĂ«nkuptonte se çdo lĂ«shim ishte "global" nĂ« kuptimin e hapĂ«sirĂ«s emĂ«rtimi; si rezultat, mund tĂ« pĂ«rdorej vetĂ«m njĂ« instancĂ« e emrit.

NĂ« Helm 3, çdo lĂ«shim Ă«shtĂ« i lidhur me njĂ« ose mĂ« shumĂ« sekretĂ«t e versionit tĂ« lĂ«shimit. Objekti i lĂ«shimit gjithmonĂ« pĂ«rshkruan lĂ«shimin aktual tĂ« deployuar nĂ« Kubernetes. Çdo sekret i versionit tĂ« lĂ«shimit pĂ«rshkruan vetĂ«m njĂ« version tĂ« kĂ«tij lĂ«shimi. PĂ«rmirĂ«simi (upgrade), pĂ«r shembull, do tĂ« krijojĂ« njĂ« sekret tĂ« ri tĂ« versionit tĂ« lĂ«shimit dhe mĂ« pas do tĂ« ndryshojĂ« objektin e lĂ«shimit, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« tregojĂ« pĂ«r kĂ«tĂ« version tĂ« ri. NĂ« rastin e kthimit prapa (rollback), mund tĂ« pĂ«rdoren sekretĂ«t e mĂ«parshĂ«m tĂ« versionit tĂ« lĂ«shimit pĂ«r tĂ« rikthyer lĂ«shimin nĂ« gjendjen e mĂ«parshme.

Pas heqjes së Tiller-it, Helm 3 ruan të dhënat e lëshimit në të njëjtin hapësirë emërtimi si lëshimi. Një ndryshim i tillë lejon instalimin e një grafiku me të njëjtin emër lëshimi në një hapësirë tjetër emërtimi, dhe të dhënat ruhen midis përmirësimeve/përsëritjeve të klasterit në etcd. Për shembull, mund të instaloni WordPress në hapësirën emërtime "foo", dhe pastaj në hapësirën "bar", dhe të dy lëshimet mund të quhen "wordpress".

Ndryshimet në varësi të grafiku

Grafikët, të paketuar (me ndihmën e helm package) për t'u përdorur me Helm 2, mund të instalohet me Helm 3, megjithatë procesi i zhvillimit të chart-ëve është rishikuar plotësisht, prandaj nevojiten disa ndryshime për të vazhduar zhvillimin e chart-ëve me Helm 3. Në veçanti, sistemi i menaxhimit të varësive të chart-ëve është ndryshuar.

Sistemi i menaxhimit të varësive të chart-it kaloi nga requirements.yaml dhe requirements.lock në Chart.yaml dhe Chart.lock. Kjo do të thotë se chart-et që kanë përdorur komandën helm dependency, kërkojnë ndonjë konfigurim për të funksionuar në Helm 3.

Le të shikojmë një shembull. Shtojmë një varësi në chart në Helm 2 dhe shohim se çfarë do të ndryshojë gjatë kalimit në Helm 3.

NĂ« Helm 2 requirements.yaml dukej si vijon:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Në Helm 3, e njëjta varësi do të reflektohet në Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Chart-et ende ngarkohen dhe vendosen në drejtorinë charts/, prandaj subchart-et (subcharts), që ndodhen në katalog charts/, do të vazhdojnë të funksionojnë pa ndryshime.

Prezantimi i Library Charts

Helm 3 mbështet një klasë chart-esh që quhet chart-e biblioteka (library chart). Ky chart përdoret nga chart-e të tjera, por nuk krijon asnjë artefakt rrelease vetë. Shabllonat e library chart-eve mund të shpallin vetëm elemente define. Përmbajtje e tjera injorohet. Kjo u mundëson përdoruesve të ri-përdorin dhe ndajnë fragmente kodi që mund të përdoren në shumë chart-e, duke shmangur kështu dyfishimin dhe duke u përmbajtur parimit DRY.

Library chart-et shpallen në seksionin dependencies në skedarin Chart.yaml. Instalimi dhe menaxhimi i tyre nuk ndryshon nga chart-et e tjera.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Ne presim me padurim rastet e përdorimit që ky komponent do t'i hapë zhvilluesve të chart-eve, si dhe praktikat më të mira që mund të lindin falë library chart-eve.

ÇfarĂ« ndodh mĂ« tej?

Helm 3.0.0-alpha.1 është baza mbi të cilën fillojmë të krijojmë një version të ri të Helm. Në këtë artikull kam përshkruar disa mundësi interesante të Helm 3. Shumica e tyre janë ende në faza të hershme të zhvillimit dhe kjo është normale; thelbi i një rrelease alfa është të testosh idenë, të grumbullosh reagime nga përdoruesit e parë dhe të konfirmosh supozimet tona.

Pasi tĂ« lĂ«shohet versioni alfa (kujtojmĂ« se kjo ka ndodhur tashmĂ« — shĂ«n. pĂ«rkth.), ne do tĂ« fillojmĂ« tĂ« pranojmĂ« patch-e pĂ«r Helm 3 nga komuniteti. Ka nevojĂ« pĂ«r tĂ« ndĂ«rtuar njĂ« themel tĂ« fortĂ« qĂ« do tĂ« mundĂ«sojĂ« zhvillimin dhe pranimin e veçorive tĂ« reja, ndĂ«rsa pĂ«rdoruesit do tĂ« ndihen tĂ« angazhuar nĂ« proces, duke hapur tiketa dhe duke bĂ«rĂ« korrigjime.

Në artikull kam përpjekur të ilustroj disa përmirësime të rëndësishme që do të dalin në Helm 3, megjithatë ky listë në asnjë rast nuk mund të quhet përfundimtar. Plani i plotë për Helm 3 përfshin novacione si strategjitë e përmirësuara të përditësimit, integrim më të thellë me regjistrat OCI dhe përdorimin e skemave JSON për verifikimin e vlerave të chart-eve. Po ashtu, planifikojmë të pastrojmë bazën e kodit dhe të përditësojmë ato pjesë që kanë mbetur pa vëmendje gjatë tri viteve të fundit.

Nëse ndjeni se kemi anashkaluar diçka, do të ishim të lumtur të dëgjonim mendimet tuaja!

Bashkohuni në diskutimin në kanalet tona Slack:

  • #helm-users pĂ«r pyetje dhe komunikim tĂ« thjeshtĂ« me komunitetin;
  • #helm-dev pĂ«r diskutimin e pull requests, kodit dhe bug-eve.

Ju gjithashtu mund tĂ« bisedoni nĂ« Thirrjet Publike tĂ« Zhvilluesve çdo tĂ« enjte nĂ« 19:30 MSK. Takimet janĂ« tĂ« dedikuara pĂ«r diskutimin e detyrave qĂ« po punojnĂ« zhvilluesit kryesorĂ« dhe komuniteti, si dhe pĂ«r temat qĂ« do tĂ« diskutohen gjatĂ« javĂ«s. Çdokush mund tĂ« bashkohet dhe tĂ« marrĂ« pjesĂ« nĂ« takim. Linku Ă«shtĂ« i disponueshĂ«m nĂ« kanalin Slack #helm-dev.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster