ProHoster > Blog > Administrimi > Etiketimi me bazë përmbajtjeje në mbledhësin werf: përse dhe si funksionon?

Etiketimi me bazë përmbajtjeje në mbledhësin werf: përse dhe si funksionon?

Etiketimi me bazë përmbajtjeje në mbledhësin werf: përse dhe si funksionon?

werf — nuestra herramienta CLI de GitOps de cĂłdigo abierto para la construcciĂłn y entrega de aplicaciones en Kubernetes. En la versiĂłn v1.1 se introdujo una nueva funcionalidad en el constructor de imĂĄgenes: etiquetado de imĂĄgenes por contenido o content-based tagging. Hasta ahora, el esquema tĂ­pico de etiquetado en werf implicaba etiquetar imĂĄgenes de Docker segĂșn la etiqueta de Git, la rama de Git o el commit de Git. Pero todos estos esquemas tienen desventajas que se resuelven completamente con la nueva estrategia de etiquetado. Detalles sobre ella y por quĂ© es tan buena se presentan a continuaciĂłn.

Despliegue de un conjunto de microservicios desde un Ășnico repositorio de Git

A menudo se da la situaciĂłn en la que una aplicaciĂłn estĂĄ dividida en mĂșltiples servicios mĂĄs o menos independientes. Las versiones de estos servicios pueden ocurrir de forma independiente: se puede lanzar una o varias versiones a la vez, mientras que los demĂĄs deben seguir funcionando sin cambios. Sin embargo, desde el punto de vista del almacenamiento de cĂłdigo y la gestiĂłn del proyecto, resulta mĂĄs conveniente mantener tales servicios de la aplicaciĂłn en un Ășnico repositorio.

Hay situaciones en las que los servicios son realmente independientes y no estån relacionados con una sola aplicación. En ese caso, estarån ubicados en proyectos separados y su lanzamiento se realizarå a través de diferentes procesos de CI/CD en cada uno de los proyectos.

Sin embargo, en la prĂĄctica, los desarrolladores a menudo descomponen una Ășnica aplicaciĂłn en varios microservicios, pero crear un repositorio y proyecto separados para cada uno... es un exceso evidente. De esto es de lo que se tratarĂĄ a continuaciĂłn: varios de estos microservicios residen en un Ășnico repositorio de proyecto y los lanzamientos se realizan a travĂ©s de un Ășnico proceso en CI/CD.

Etiquetado por rama de Git y etiqueta de Git

Supongamos que se utiliza la estrategia de etiquetado mĂĄs comĂșn — tag-or-branch. Para las ramas de Git, las imĂĄgenes se etiquetan con el nombre de la rama, para una Ășnica rama en un momento dado existe solo una imagen publicada con el nombre de esa rama. Para las etiquetas de Git, las imĂĄgenes se etiquetan con el nombre de la etiqueta correspondiente.

Al crear una nueva etiqueta de Git — por ejemplo, al lanzar una nueva versión — para todas las imágenes del proyecto en Docker Registry se creará una nueva etiqueta de Docker:

  • myregistry.org/myproject/frontend:v1.1.10
  • myregistry.org/myproject/myservice1:v1.1.10
  • myregistry.org/myproject/myservice2:v1.1.10
  • myregistry.org/myproject/myservice3:v1.1.10
  • myregistry.org/myproject/myservice4:v1.1.10
  • myregistry.org/myproject/myservice5:v1.1.10
  • myregistry.org/myproject/database:v1.1.10

Estos nuevos nombres de imagen llegan a la configuración de Kubernetes a través de plantillas de Helm. Al ejecutar el despliegue con el comando werf deploy se actualiza el campo image en los manifiestos de recursos de Kubernetes y se reinician los recursos correspondientes debido al cambio en el nombre de la imagen.

Problemi: en el caso de que realmente no se haya cambiado el contenido de la imagen desde el despliegue anterior (etiqueta de Git), sino solo su etiqueta de Docker, ocurre un reinicio extra de esta aplicaciĂłn y, por lo tanto, puede haber un cierto tiempo de inactividad. Aunque no hubo razones reales para realizar este reinicio.

Si pĂ«rfundim, me skemĂ«n aktuale tĂ« etiketimit Ă«shtĂ« e nevojshme tĂ« krijohen disa depove tĂ« ndara Git, dhe ndodhet problemi i organizimit tĂ« lansimit tĂ« kĂ«tyre depove tĂ« shumta. NĂ« pĂ«rgjithĂ«si, njĂ« skemĂ« e tillĂ« rezulton e mbushur dhe e komplikuar. ËshtĂ« mĂ« mirĂ« tĂ« bashkohen shumĂ« shĂ«rbime nĂ« njĂ« depo tĂ« vetme dhe tĂ« krijohen etiketa Docker nĂ« mĂ«nyrĂ« qĂ« tĂ« mos ketĂ« rinisje tĂ« panevojshme.

Etiketimi sipas Git-commit

Në werf gjithashtu ekziston një strategji etiketimi e lidhur me Git-commit.

Git-commit është identifikuesi i përmbajtjes së depozitës Git dhe varet nga historia e ndryshimeve të skedave në depozitën Git, prandaj duket logjik të përdoret për etiketimin e imazheve në Docker Registry.

Megjithatë, etiketimi sipas Git-commit ka të njëjtat disavantazhe si ai sipas degëve Git ose etiketave Git:

  • Mund tĂ« jetĂ« krijuar njĂ« kommit bosh, i cili nuk ndryshon skedarĂ«t, dhe Docker-etiketimi i imazhit do tĂ« ndryshohet.
  • Mund tĂ« jetĂ« krijuar njĂ« kommit bashkues, i cili nuk ndryshon skedarĂ«t, dhe Docker-etiketimi i imazhit do tĂ« ndryshohet.
  • Mund tĂ« jetĂ« krijuar njĂ« kommit, i cili ndryshon ato skedarĂ« nĂ« Git, qĂ« nuk importohen nĂ« imazh, dhe Docker-etiketimi i imazhit do tĂ« ndryshohet pĂ«rsĂ«ri.

Etiketimi sipas emrit të degës Git nuk reflekton versionin e imazhit

Ka edhe një problem tjetër që lidhet me strategjinë e etiketimit sipas degëve Git.

Etiketimi sipas emrit të degës funksionon derisa kommitet e kësaj dege të mblidhen me radhë në rend kronologjik.

Nëse në skemën aktuale përdoruesi nis një rivendosje të një kommiti të vjetër, të lidhur me një degë të caktuar, atëherë werf do të mbivendosë imazhin sipas Docker-etiketimit me versionin e ri të ndërtuar për kommitin e vjetër. Depojat që përdorin këtë etikë nga atë moment rrezikojnë që gjatë rinisjes së pod'ave të bëjnë pull një version tjetër të imazhit, si rezultat i së cilës aplikacioni ynë humb lidhjen me sistemin CI, duke u shkëputur.

Për më tepër, gjatë protrudimeve radhës në një degë me një distancë të vogël kohe mes tyre, kommiti i vjetër mund të ndërtohet më vonë se ai më i ri: versioni i vjetër i imazhit do të mbivendosë versionin e ri sipas etiketës Git. Këto probleme mund të zgjidhen nga sistemi CI/CD (p.sh., në GitLab CI për një seri kommitesh fillon pipeline i fundit). Megjithatë, kjo nuk mbështetet nga të gjithë sistemet dhe duhet të ketë një mënyrë më të besueshme për të parandaluar një problem kaq themelor.

ÇfarĂ« Ă«shtĂ« etiketimi i bazuar nĂ« pĂ«rmbajtje?

Pra, çfarĂ« Ă«shtĂ« etiketimi i bazuar nĂ« pĂ«rmbajtje — etiketimi i imazheve sipas pĂ«rmbajtjes.

Për të krijuar Docker-etiketa, nuk përdoren primitivët e Git-it (Git-dega, Git-etiketa
), por një kontroll i shumësisë i lidhur me:

  • pĂ«rmbajtjen e imazhit. Identifikuesi-etiketĂ« i imazhit reflekton pĂ«rmbajtjen e tij. GjatĂ« ndĂ«rtimit tĂ« njĂ« versioni tĂ« ri ky identifikues nuk do tĂ« ndryshojĂ«, nĂ«se nĂ« imazh nuk janĂ« ndryshuar skedarĂ«t;
  • historinĂ« e krijimit tĂ« kĂ«tij imazhi nĂ« Git. Imazhet qĂ« lidhen me degĂ« tĂ« ndryshme Git dhe histori tĂ« ndryshme ndĂ«rtimi pĂ«rmes werf, do tĂ« kenĂ« etiketa-identifikues tĂ« ndryshme.

Një etiketë identifikimi e tillë është e njohur si firma e fazave të imazhit.

Çdo imazh pĂ«rbĂ«het nga njĂ« grup fazash: from, before-install, git-archive, install, imports-after-install, before-setup,
 git-latest-patch etj. Çdo fazĂ« ka njĂ« identifikues qĂ« reflekton pĂ«rmbajtjen e saj, — firma e fazĂ«s (stage signature).

Imazhi pĂ«rfundimtar, i pĂ«rbĂ«rĂ« nga kĂ«to faza, etiketohet me firmĂ«n e ashtuquajtur tĂ« grupit tĂ« kĂ«tyre fazave — stages signature, — e cila Ă«shtĂ« njĂ« pĂ«rmbledhje pĂ«r tĂ« gjitha fazat e imazhit.

Çdo imazh nga konfigurimi werf.yaml nĂ« rregull do tĂ« ketĂ« njĂ« tĂ« tillĂ« firmĂ« dhe, pĂ«r pasojĂ«, njĂ« etiketĂ« Docker.

Firma e fazave zgjidh të gjitha problemet e përmendura:

  • ËshtĂ« e qĂ«ndrueshme ndaj komiteteve tĂ« zbrazĂ«ta Git.
  • ËshtĂ« e qĂ«ndrueshme ndaj komiteteve Git qĂ« ndryshojnĂ« skedarĂ«t, qĂ« nuk janĂ« relevancĂ« pĂ«r imazhin.
  • Nuk shkakton njĂ« problem me mbivendosjen e versionit aktual tĂ« imazhit kur rinisni ndĂ«rtimet pĂ«r komitetet e vjetra Git tĂ« degĂ«s.

Tani kjo është strategjia e rekomanduar për etiketimin dhe përdoret si parazgjedhje në werf për të gjitha sistemet CI.

Si të aktivizoni dhe përdorni në werf

Opsioni përkatës u shfaq në komandën werf publish: --tag-by-stages-signature=true|false

Në sistemin CI, strategjia e etiketimit përcaktohet nga komanda werf ci-env. Më parë, për të është përcaktuar parametri werf ci-env --tagging-strategy=tag-or-branch. Tani, nëse e specifikoni werf ci-env --tagging-strategy=stages-signature apo nuk e specifikoni këtë opsion, werf do të përdorë si parazgjedhje strategjinë e etiketimit stages-signature. Komanda werf ci-env do të vendosë automatikisht flag-at e nevojshëm për komandën werf build-and-publish (ose werf publish), prandaj nuk është e nevojshme të jepni opsione shtesë për këto komanda.

PĂ«r shembull, komanda:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature


 mund të krijojë imazhe të mëposhtme:

  • registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
  • registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

KĂ«tu 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d — Ă«shtĂ« firma e fazave tĂ« imazhit backend, dhe f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — firma e fazave tĂ« imazhit frontend.

Duke përdorur funksione speciale werf_container_image dhe werf_container_env në shabllonat Helm nuk ka nevojë të ndryshoni asgjë: këto funksione do të krijojnë automatikisht emrat e saktë të imazheve.

Shembulli i konfigurimit në sistemin CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Më shumë informacion në lidhje me konfigurimin është i disponueshëm në dokumentacion:

Në përfundim

  • MundĂ«si e re werf publish --tag-by-stages-signature=true|false.
  • Vlera e re e opsionit werf ci-env --tagging-strategy=stages-signature|tag-or-branch (nĂ«se nuk e spesifikoni, atĂ«herĂ« parazgjedhja do tĂ« jetĂ« stages-signature).
  • NĂ«se deri tani ishin pĂ«rdorur opsione etiketimi sipas komiteteve Git (WERF_TAG_GIT_COMMIT apo opsioni werf publish --tag-git-commit COMMIT), atĂ«herĂ« Ă«shtĂ« e domosdoshme tĂ« kaloni nĂ« strategjinĂ« e etiketimit stages-signature.
  • Projektet e reja Ă«shtĂ« mirĂ« t'i kaloni menjĂ«herĂ« nĂ« skemĂ«n e re tĂ« etiketimit.
  • Projektet e vjetra, kur kaloni nĂ« werf 1.1, Ă«shtĂ« e dĂ«shirueshme t'i kaloni nĂ« skemĂ«n e re tĂ« etiketimit, por e vjetra tag-or-branch ndihmohet akoma.

Etiketime e bazuar në përmbajtje zgjidh të gjitha problemet e përmendura në artikull:

  • QĂ«ndrueshmĂ«ria e emrit tĂ« tag-Ă«ve Docker ndaj komiteteve bosh tĂ« Git.
  • QĂ«ndrueshmĂ«ria e emrit tĂ« tag-Ă«ve Docker ndaj komiteteve tĂ« Git qĂ« ndryshojnĂ« skedarĂ«t e parĂ«ndĂ«sishĂ«m pĂ«r imazhin.
  • Nuk shkakton njĂ« problem me mbingarkimin e versionit aktual tĂ« imazhit kur rilansohet ndĂ«rtimi pĂ«r komitetet e vjetra tĂ« Git pĂ«r degĂ«t e Git.

Përdorni! Dhe mos harroni të na vizitoni në GitHub, për të krijuar një issue ose për të gjetur një të ekzistueshëm, për të vendosur një plus, për të krijuar një PR ose thjesht për të ndjekur zhvillimin e projektit.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

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