ፕሮሆስተር > ጦማር > አስተዳደር > በይዘት ላይ የተመሰረተ መለያ በ werf ገንቢ ውስጥ፡ ለምን እና እንዴት ነው የሚሰራው?

በይዘት ላይ የተመሰረተ መለያ በ werf ገንቢ ውስጥ፡ ለምን እና እንዴት ነው የሚሰራው?

በይዘት ላይ የተመሰረተ መለያ በ werf ገንቢ ውስጥ፡ ለምን እና እንዴት ነው የሚሰራው?

werf መተግበሪያዎችን ወደ ኩበርኔትስ ለመገንባት እና ለማድረስ የእኛ ክፍት ምንጭ GitOps CLI መገልገያ ነው። ውስጥ መልቀቅ v1.1 አዲስ ባህሪ በምስል ሰብሳቢው ውስጥ አስተዋወቀ፡ ምስሎችን በይዘት መለያ መስጠት ወይም ይዘት ላይ የተመሠረተ መለያ መስጠት. እስካሁን ድረስ፣ በ werf ውስጥ ያለው የተለመደው የመለያ አሰጣጥ ዘዴ Docker ምስሎችን በ Git tag፣ Git ቅርንጫፍ ወይም በጂት ቁርጠኝነት መለያ መስጠትን ያካትታል። ነገር ግን እነዚህ ሁሉ እቅዶች በአዲሱ የመለያ ስልት ሙሉ በሙሉ የተፈቱ ጉዳቶች አሏቸው። ስለ እሱ እና ለምን በጣም ጥሩ እንደሆነ ዝርዝሮች በቆራጩ ስር ናቸው።

ከአንድ የጂት ማከማቻ የማይክሮ አገልግሎቶችን በማንከባለል ላይ

አፕሊኬሽኑ ወደ ብዙ ወይም ባነሰ ገለልተኛ አገልግሎቶች ሲከፋፈል ብዙ ጊዜ ይከሰታል። የእነዚህ አገልግሎቶች ልቀቶች በተናጥል ሊከሰቱ ይችላሉ-አንድ ወይም ብዙ አገልግሎቶች በአንድ ጊዜ ሊለቀቁ ይችላሉ, የተቀሩት ግን ያለ ምንም ለውጥ መስራታቸውን መቀጠል አለባቸው. ነገር ግን ከኮድ ማከማቻ እና የፕሮጀክት አስተዳደር እይታ አንጻር እንደዚህ ያሉ የመተግበሪያ አገልግሎቶችን በአንድ ማከማቻ ውስጥ ማስቀመጥ የበለጠ አመቺ ነው.

አገልግሎቶቹ በእውነት ነጻ ሲሆኑ እና ከአንድ መተግበሪያ ጋር ያልተያያዙ ሁኔታዎች አሉ። በዚህ ሁኔታ, በተናጥል ፕሮጀክቶች ውስጥ ይገኛሉ እና መልቀቃቸው በእያንዳንዱ ፕሮጀክቶች ውስጥ በተለየ የሲአይ / ሲዲ ሂደቶች ይከናወናሉ.

ነገር ግን፣ እንደ እውነቱ ከሆነ፣ ገንቢዎች ብዙውን ጊዜ አንድ መተግበሪያን ወደ ብዙ ማይክሮ ሰርቪስ ይከፋፍሏቸዋል፣ ነገር ግን ለእያንዳንዱ የተለየ ማከማቻ እና ፕሮጀክት መፍጠር... ግልጽ ከልክ ያለፈ ኪሳራ ነው። ተጨማሪ የሚብራራው ይህ ሁኔታ ነው፡ ብዙ እንደዚህ ያሉ ጥቃቅን አገልግሎቶች በአንድ የፕሮጀክት ማከማቻ ውስጥ የሚገኙ እና የሚለቀቁት በ CI/CD ውስጥ በአንድ ሂደት ነው።

በጊት ቅርንጫፍ እና በጊት መለያ መለያ መስጠት

በጣም የተለመደው የመለያ ስልት ጥቅም ላይ ይውላል እንበል - መለያ-ወይም-ቅርንጫፍ. ለጂት ቅርንጫፎች ምስሎች በቅርንጫፉ ስም መለያ ተሰጥቷቸዋል፣ ለአንድ ቅርንጫፍ በአንድ ጊዜ በዚያ ቅርንጫፍ ስም የታተመ አንድ ምስል ብቻ አለ። ለጂት መለያዎች ምስሎች በመለያው ስም መለያ ተሰጥቷቸዋል።

አዲስ Git መለያ ሲፈጠር - ለምሳሌ አዲስ ስሪት ሲወጣ - በ Docker መዝገብ ውስጥ ላሉ ሁሉም የፕሮጀክት ምስሎች አዲስ 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

እነዚህ አዲስ የምስል ስሞች በሄልም አብነቶች በኩል ወደ Kubernetes ውቅር ይተላለፋሉ። በትእዛዙ ማሰማራት ሲጀምሩ werf deploy መስክ እየተዘመነ ነው። image በ Kubernetes ሪሶርስ በተለወጠው የምስል ስም ምክንያት ተጓዳኝ ሀብቶችን ያሳያል እና እንደገና ያስጀምራል።

ችግር፦ እንደ እውነቱ ከሆነ የምስሉ ይዘት ካለፈው መልቀቅ (ጂት ታግ) በኋላ ካልተቀየረ ፣ ግን Docker መለያው ብቻ ከሆነ ፣ ይህ ይከሰታል ትርፍ ይህን መተግበሪያ እንደገና ማስጀመር እና, በዚህ መሰረት, የተወሰነ ጊዜ ማቆም ይቻላል. ምንም እንኳን ይህንን ዳግም ማስጀመር ለማከናወን ምንም እውነተኛ ምክንያት ባይኖርም.

በውጤቱም፣ አሁን ባለው የመለያ ዘዴ በርካታ የተለያዩ የጂት ማከማቻዎችን ማጠር አስፈላጊ ሲሆን የእነዚህን በርካታ ማከማቻዎች መልቀቅን የማደራጀት ችግር ተፈጥሯል። በአጠቃላይ እንዲህ ዓይነቱ እቅድ ከመጠን በላይ መጫን እና ውስብስብ ሆኖ ይታያል. ብዙ አገልግሎቶችን በአንድ ማከማቻ ውስጥ በማጣመር እና አላስፈላጊ ዳግም ማስጀመር እንዳይኖር የዶከር መለያዎችን መፍጠር የተሻለ ነው።

በጊት ቁርጠኝነት መለያ መስጠት

werf ከጂት መፈጸም ጋር የተያያዘ የመለያ ስልት አለው።

Git-commit የጂት ማከማቻ ይዘቶች መለያ ነው እና በጂት ማከማቻ ውስጥ ባሉ የፋይሎች የአርትዖት ታሪክ ላይ የተመሰረተ ነው ስለዚህ በ Docker መዝገብ ውስጥ ምስሎችን ለመሰየም መጠቀም ምክንያታዊ ይመስላል።

ነገር ግን፣ በGit ቁርጠኝነት መለያ መስጠት በ Git ቅርንጫፎች ወይም Git መለያዎች መለያ ከመስጠት ጋር ተመሳሳይ ጉዳቶች አሉት።

  • ምንም ፋይሎችን የማይቀይር ባዶ ቁርጠኝነት ሊፈጠር ይችላል ነገር ግን የምስሉ Docker መለያ ይቀየራል።
  • ፋይሎቹን የማይለውጥ የውህደት ቃል ሊፈጠር ይችላል፣ ነገር ግን የምስሉ Docker መለያ ይቀየራል።
  • በጊት ውስጥ ወደ ምስሉ የማይገቡ ፋይሎችን የሚቀይር ቃል ኪዳን ሊደረግ ይችላል እና የምስሉ Docker መለያ እንደገና ይቀየራል።

የጂት ቅርንጫፍ ስም መለያ መስጠት የምስል ሥሪትን አያንፀባርቅም።

ከጂት ቅርንጫፎች መለያ አሰጣጥ ስትራቴጂ ጋር የተያያዘ ሌላ ችግር አለ።

በቅርንጫፍ ስም መለያ መስጠት የሚሠራው በዚያ ቅርንጫፍ ላይ ያሉ ድርጊቶች በቅደም ተከተል በቅደም ተከተል እስከተሰበሰቡ ድረስ ነው።

አሁን ባለው እቅድ ተጠቃሚው ከአንድ የተወሰነ ቅርንጫፍ ጋር የተያያዘ የድሮ ቁርጠኝነትን እንደገና መገንባት ከጀመረ ዌርፍ ምስሉን በአዲስ መልክ የተሰራውን የድሮ ቁርጠኝነትን በመጠቀም ተዛማጅ Docker መለያን በመጠቀም ምስሉን እንደገና ይጽፋል። ከአሁን በኋላ ይህን መለያ ተጠቅመው የሚሰማሩ ማሰማራቶች ፖዶችን እንደገና በሚያስጀምሩበት ጊዜ የተለየ የምስሉን ስሪት የመሳብ አደጋ ያጋጥማቸዋል፣ በዚህ ምክንያት መተግበሪያችን ከCI ሲስተሙ ጋር ያለውን ግንኙነት ያቋርጣል እና የማይመሳሰል ይሆናል።

በተጨማሪም ፣በመካከላቸው አጭር ጊዜ ባለው አንድ ቅርንጫፍ ውስጥ በተከታታይ በመገፋፋት ፣የቀድሞው ቃል ከአዲሱ ዘግይቶ ሊጠናቀር ይችላል፡የቀድሞው የምስሉ ስሪት የጊት ቅርንጫፍ መለያን በመጠቀም አዲሱን ይተካል። እንደነዚህ ያሉ ችግሮች በ CI / ሲዲ ስርዓት ሊፈቱ ይችላሉ (ለምሳሌ በ GitLab CI ውስጥ የኋለኛው የቧንቧ መስመር ለተከታታይ ድርጊቶች ተጀምሯል). ሆኖም ግን, ሁሉም ስርዓቶች ይህንን አይደግፉም እና እንደዚህ አይነት መሰረታዊ ችግርን ለመከላከል የበለጠ አስተማማኝ መንገድ መኖር አለበት.

በይዘት ላይ የተመሰረተ መለያ መስጠት ምንድነው?

ስለዚህ በይዘት ላይ የተመሰረተ መለያ መስጠት ምንድነው - ምስሎችን በይዘት መለያ መስጠት።

የዶከር መለያዎችን ለመፍጠር፣ ጥቅም ላይ የሚውሉት Git primitives (Git ቅርንጫፍ፣ Git ታግ...) አይደሉም፣ ነገር ግን ከሚከተለው ጋር የተያያዘ ቼክ ድምር ነው፡-

  • የምስሉ ይዘት. የምስሉ መታወቂያ መለያ ይዘቱን ያንፀባርቃል። አዲስ ስሪት ሲገነቡ, በምስሉ ውስጥ ያሉት ፋይሎች ካልተቀየሩ ይህ መለያ አይለወጥም;
  • ይህንን ምስል በ Git ውስጥ የመፍጠር ታሪክ. ከተለያዩ የጂት ቅርንጫፎች ጋር የተቆራኙ ምስሎች እና የተለያዩ የግንባታ ታሪክ በ werf በኩል የተለያዩ የመታወቂያ መለያዎች ይኖራቸዋል።

እንዲህ ዓይነቱ መለያ መለያ የሚጠራው ነው የምስል ደረጃ ፊርማ.

እያንዳንዱ ምስል የተወሰኑ ደረጃዎችን ያቀፈ ነው- from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ወዘተ. እያንዳንዱ ደረጃ ይዘቱን የሚያንፀባርቅ መለያ አለው - የመድረክ ፊርማ (የደረጃ ፊርማ).

የመጨረሻው ምስል, እነዚህን ደረጃዎች ያካተተ, የእነዚህ ደረጃዎች ስብስብ ፊርማ ተብሎ በሚጠራው መለያ ተሰጥቷል - ደረጃዎች ፊርማ, - ለሁሉም የምስሉ ደረጃዎች አጠቃላይ የሆነ.

ለእያንዳንዱ ምስል ከማዋቀሪያው werf.yaml በአጠቃላይ ሁኔታ, የራሱ ፊርማ እና, በዚህ መሠረት, የዶከር መለያ ይኖራል.

የመድረክ ፊርማ እነዚህን ሁሉ ችግሮች ይፈታል-

  • ባዶ Git መፈጸምን የሚቋቋም።
  • Gitን የሚቋቋም ከምስሉ ጋር የማይዛመዱ ፋይሎችን የሚቀይር ተግባር ይፈጽማል።
  • እንደገና በሚጀመርበት ጊዜ አሁን ያለውን የምስሉን እትም እንደገና ወደ ማደስ ችግር አይመራም።

ይህ አሁን የሚመከረው የመለያ ስልት ነው እና በሁሉም የCI ሲስተሞች ነባሪው ነው።

በ werf ውስጥ እንዴት ማንቃት እና መጠቀም እንደሚቻል

ትዕዛዙ አሁን ተጓዳኝ አማራጭ አለው። werf publish: --tag-by-stages-signature=true|false

በ CI ስርዓት ውስጥ የመለያ ስልት በትእዛዙ ይገለጻል werf ci-env. ቀደም ሲል, መለኪያው ለእሱ ተገልጿል werf ci-env --tagging-strategy=tag-or-branch. አሁን፣ ከገለጹ werf ci-env --tagging-strategy=stages-signature ወይም ይህን አማራጭ አይግለጹ፣ werf የመለያ ስልቱን በነባሪነት ይጠቀማል stages-signature. ቡድን werf ci-env ለትእዛዙ አስፈላጊ የሆኑትን ባንዲራዎች በራስ-ሰር ያዘጋጃል werf build-and-publish (ወይም werf publish), ስለዚህ ለእነዚህ ትዕዛዞች ምንም ተጨማሪ አማራጮች መገለጽ አያስፈልግም.

ለምሳሌ ትዕዛዙ፡-

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

... የሚከተሉትን ምስሎች መፍጠር ይችላል:

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

ይህ ነው 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d የምስሉ ደረጃዎች ፊርማ ነው backendና f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - የምስል ደረጃዎች ፊርማ frontend.

ልዩ ተግባራትን ሲጠቀሙ werf_container_image и werf_container_env በ Helm አብነቶች ውስጥ ምንም ነገር መለወጥ አያስፈልግም: እነዚህ ተግባራት ትክክለኛ የምስል ስሞችን በራስ-ሰር ያመነጫሉ.

የምሳሌ ውቅር በCI ስርዓት ውስጥ፡-

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

ስለ ውቅረት ተጨማሪ መረጃ በሰነዱ ውስጥ ይገኛል፡-

ԸՆԴՀԱՆՈՒՐ ԳԻՆ

  • አዲስ አማራጭ werf publish --tag-by-stages-signature=true|false.
  • አዲስ አማራጭ ዋጋ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ካልተገለጸ ነባሪው ይሆናል። stages-signature).
  • ከዚህ ቀደም ለጂት መፈጸም አማራጮችን ከተጠቀሙ (WERF_TAG_GIT_COMMIT ወይም አማራጭ werf publish --tag-git-commit COMMIT), ከዚያ ወደ መለያ ስልት መቀየርዎን እርግጠኛ ይሁኑ ደረጃዎች-ፊርማ.
  • አዳዲስ ፕሮጀክቶችን ወዲያውኑ ወደ አዲሱ የመለያ ዘዴ መቀየር የተሻለ ነው.
  • ወደ werf 1.1 በሚተላለፉበት ጊዜ የቆዩ ፕሮጀክቶችን ወደ አዲሱ የመለያ ዘዴ መቀየር ተገቢ ነው, ነገር ግን አሮጌው መለያ-ወይም-ቅርንጫፍ አሁንም የሚደገፍ ነው።

በይዘት ላይ የተመሰረተ መለያ መስጠት በአንቀጹ ውስጥ ያሉትን ሁሉንም ችግሮች ይፈታል፡-

  • የዶከር መለያ ስም በባዶ Git ይፈፀማል።
  • ለጂት የዶከር መለያ ስም መቋቋም ለምስሉ የማይዛመዱ ፋይሎችን እንዲቀይር ያደርጋል።
  • ዳግም በሚጀመርበት ጊዜ አሁን ያለውን የምስሉን እትም እንደገና የማደስ ችግርን አያመጣም።

ተጠቀምበት! እና እኛን መጎብኘትዎን አይርሱ የፊልሙችግር ለመፍጠር ወይም ያለውን ለማግኘት፣ ፕላስ ለመጨመር፣ PR ለመፍጠር ወይም የፕሮጀክቱን እድገት በቀላሉ ለመመልከት።

PS

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ