werf - የእኛ መሳሪያ ለ CI / ሲዲ በኩበርኔትስ (አጠቃላይ እይታ እና የቪዲዮ ዘገባ)

ግንቦት 27 በዴቭኦፕስኮንፍ 2019 ኮንፈረንስ ዋና አዳራሽ፣ የበዓሉ አካል በሆነው RIT++ 2019, እንደ "ቀጣይ ማድረስ" ክፍል አንድ ሪፖርት "werf - የእኛ መሣሪያ ለ CI / ሲዲ በኩበርኔትስ" ተሰጥቷል. ስለ እነዚያ ይናገራል ወደ ኩበርኔትስ በሚሰራጭበት ጊዜ ሁሉም ሰው የሚያጋጥማቸው ችግሮች እና ችግሮች, እንዲሁም ስለ ጥቃቅን ነገሮች ወዲያውኑ ሊታዩ አይችሉም. ሊሆኑ የሚችሉ መፍትሄዎችን በመተንተን, ይህ በክፍት ምንጭ መሳሪያ ውስጥ እንዴት እንደሚተገበር እናሳያለን werf.

ከዝግጅቱ ጀምሮ የእኛ መገልገያ (የቀድሞው ዳፕ ተብሎ የሚጠራው) ታሪካዊ ምዕራፍ ላይ ደርሷል በ GitHub ላይ 1000 ኮከቦች — እያደገ ያለው የተጠቃሚው ማህበረሰብ ለብዙ DevOps መሐንዲሶች ኑሮን ቀላል እንደሚያደርግ ተስፋ እናደርጋለን።

እናስተዋውቅ ቪዲዮ ከሪፖርቱ ጋር (~ 47 ደቂቃዎች፣ ከጽሁፉ የበለጠ መረጃ ሰጭ) እና ከሱ የወጣው ዋና በፅሁፍ መልክ። ሂድ!

ኮድ ወደ Kubernetes በማድረስ ላይ

ንግግሩ ከአሁን በኋላ ስለ werf አይሆንም፣ ነገር ግን ስለ CI/CD Kubernetes፣ ይህም ማለት ሶፍትዌራችን በዶከር ኮንቴይነሮች ውስጥ እንደታሸገ ያሳያል። (ስለዚህ ጉዳይ ተናገርኩኝ የ2016 ሪፖርት)እና K8s በምርት ውስጥ ለማስኬድ ጥቅም ላይ ይውላል (ስለዚህ ተጨማሪ በ 2017 ዓመታ).

በ Kubernetes ማድረስ ምን ይመስላል?

• የጊት ማከማቻ ኮድ እና እሱን ለመገንባት መመሪያዎችን የያዘ ነው። አፕሊኬሽኑ በDocker ምስል ውስጥ ተገንብቶ በDocker መዝገብ ውስጥ ታትሟል።
• ተመሳሳዩ ማከማቻ መተግበሪያን እንዴት ማሰማራት እና ማስኬድ እንደሚችሉ መመሪያዎችን ይዟል። በማሰማራት ደረጃ, እነዚህ መመሪያዎች ወደ Kubernetes ይላካሉ, ይህም የሚፈለገውን ምስል ከመዝገቡ ውስጥ ተቀብሎ ያስጀምረዋል.
• በተጨማሪም, ብዙውን ጊዜ ፈተናዎች አሉ. ከእነዚህ ውስጥ አንዳንዶቹ ምስል በሚታተምበት ጊዜ ሊደረጉ ይችላሉ. እንዲሁም (ተመሳሳይ መመሪያዎችን በመከተል) የመተግበሪያውን ቅጂ (በተለየ የK8s ስም ቦታ ወይም የተለየ ክላስተር) ማሰማራት እና እዚያ ሙከራዎችን ማካሄድ ይችላሉ።
• በመጨረሻም፣ ከ Git (ወይም የአዝራር ጠቅታዎች) ክስተቶችን የሚቀበል እና ሁሉንም የተመደቡትን ደረጃዎች የሚጠራ የCI ስርዓት ያስፈልግዎታል፡ መገንባት፣ ማተም፣ ማሰማራት፣ መሞከር።

እዚህ ጥቂት ጠቃሚ ማስታወሻዎች አሉ:

1. ምክንያቱም የማይለወጥ መሠረተ ልማት ስላለን ነው። (የማይለወጥ መሠረተ ልማት)በሁሉም ደረጃዎች (ማዘጋጀት ፣ ማምረት ፣ ወዘተ) ጥቅም ላይ የሚውለው የመተግበሪያ ምስል ፣ አንድ መሆን አለበት. ስለዚህ ጉዳይ በበለጠ ዝርዝር እና በምሳሌዎች ተናገርኩኝ. እዚህ.
2. ምክንያቱም መሠረተ ልማትን እንደ ኮድ አቀራረብ ነው የምንከተለው። (አይሲሲ), የመተግበሪያ ኮድ, የመገጣጠም እና የማስጀመር መመሪያዎች መሆን አለባቸው በትክክል በአንድ ማከማቻ ውስጥ. ስለዚህ ጉዳይ የበለጠ መረጃ ለማግኘት ይመልከቱ ተመሳሳይ ዘገባ.
3. የመላኪያ ሰንሰለት (ማድረስ) እኛ ብዙውን ጊዜ እንደዚህ እናያለን-መተግበሪያው ተሰብስቦ ፣ ተፈተነ ፣ ተለቋል (የመልቀቅ ደረጃ) እና ያ ነው - መላኪያ ተካሂዷል. ግን እንደ እውነቱ ከሆነ ተጠቃሚው እርስዎ ያወጡትን ያገኛል፣ አይደለም ከዚያም ወደ ምርት ሲያደርሱት እና እዚያ መሄድ ሲችል እና ይህ ምርት ሠርቷል. ስለዚህ የመላኪያ ሰንሰለት ያበቃል ብዬ አምናለሁ። በተግባር ደረጃ ላይ ብቻ (ሩጫ), ወይም በትክክል ፣ ኮዱ ከምርት በተወገደበት ቅጽበት (በአዲስ መተካት)።

ወደ ኩበርኔትስ ወደሚገኘው የማስረከቢያ ዘዴ እንመለስ፡ የተፈጠረው በእኛ ብቻ ሳይሆን በጥሬው ይህንን ችግር በተቋቋመው ሁሉ ነው። በእርግጥ ይህ ስርዓተ-ጥለት አሁን GitOps ይባላል (ስለ ቃሉ እና ከሱ በስተጀርባ ስላለው ሀሳቦች የበለጠ ማንበብ ይችላሉ። እዚህ). የእቅዱን ደረጃዎች እንመልከት.

ደረጃ መገንባት

Dockerfiles እንዴት እንደሚፃፍ እና እንደሚሮጥ ሁሉም ሰው ሲያውቅ በ2019 ስለ Docker ምስሎችን ስለመገንባት ማውራት የምትችል ይመስላል። docker build?... ትኩረት ልሰጥባቸው የምፈልጋቸው ነገሮች እነሆ፡-

1. የምስል ክብደት ጉዳዮች, ስለዚህ ተጠቀም ባለብዙ-ደረጃበምስሉ ላይ በትክክል ለሥራው አስፈላጊ የሆነውን መተግበሪያ ብቻ ለመተው.
2. የንብርብሮች ብዛት ሰንሰለቶችን በማጣመር መቀነስ አለበት RUN- እንደ ትርጉሙ ትዕዛዞች.
3. ሆኖም, ይህ ችግሮችን ይጨምራል ማረም, ምክንያቱም ስብሰባው ሲሰናከል, ችግሩን ከፈጠረው ሰንሰለት ትክክለኛውን ትዕዛዝ ማግኘት አለብዎት.
4. የመሰብሰቢያ ፍጥነት አስፈላጊ ምክንያቱም ለውጦችን በፍጥነት ለማውጣት እና ውጤቱን ለማየት እንፈልጋለን. ለምሳሌ፣ ማመልከቻ በሚገነቡበት ጊዜ ሁሉ በቋንቋ ቤተ-መጽሐፍት ውስጥ ያሉ ጥገኞችን እንደገና መገንባት አይፈልጉም።
5. ብዙ ጊዜ ከአንድ Git ማከማቻ ያስፈልግዎታል ብዙ ምስሎች, ይህም በ Dockerfiles ስብስብ (ወይም በአንድ ፋይል ውስጥ በተሰየሙ ደረጃዎች) እና በ Bash ስክሪፕት ከተከታታይ ስብሰባቸው ጋር ሊፈታ ይችላል.

ይህ ሁሉም ሰው የሚያጋጥመው የበረዶ ግግር ጫፍ ብቻ ነበር። ግን ሌሎች ችግሮችም አሉ, በተለይም:

1. ብዙውን ጊዜ በስብሰባው ደረጃ አንድ ነገር እንፈልጋለን ተራራ (ለምሳሌ ፣ የሶስተኛ ወገን ማውጫ ውስጥ ያለ የትዕዛዝ ውጤት መሸጎጫ)።
2. እንፈልጋለን የሚጠራ በሼል ውስጥ ከመጻፍ ይልቅ.
3. እንፈልጋለን ያለ Docker ይገንቡ (ለዚህ ሁሉንም ነገር ማዋቀር የሚያስፈልገን ተጨማሪ ቨርቹዋል ማሽን ለምን ያስፈልገናል, አስቀድመን ኮንቴይነሮችን የምናስኬድበት የኩበርኔትስ ክላስተር እያለን?).
4. ትይዩ ስብሰባ, በተለያዩ መንገዶች ሊረዳ የሚችል: ከ Dockerfile የተለያዩ ትዕዛዞች (ባለብዙ-ደረጃ ጥቅም ላይ ከዋለ), ብዙ ተመሳሳይ ማከማቻዎች, በርካታ Dockerfiles.
5. የተከፋፈለ ስብሰባ: ነገሮችን በፖዳዎች ውስጥ መሰብሰብ እንፈልጋለን ምክንያቱም "ኤፌመር" ናቸው የእነሱ መሸጎጫ ይጠፋል, ይህም ማለት በተለየ ቦታ መቀመጥ አለበት.
6. በመጨረሻም የፍላጎቶችን ቁንጮ ብዬ ጠራሁት አውቶማቲክ: ወደ ማከማቻው መሄድ ፣ አንዳንድ ትዕዛዞችን መተየብ እና እንዴት እና በትክክል ምን ማድረግ እንዳለበት በመረዳት ተሰብስቦ የተዘጋጀ ምስል ማግኘት ጥሩ ነው። ሆኖም፣ እኔ በግሌ ሁሉም ልዩነቶች በዚህ መንገድ አስቀድሞ ሊታዩ እንደሚችሉ እርግጠኛ አይደለሁም።

እና ፕሮጀክቶቹ እነኚሁና፡-

• moby/buildkit - እነዚህን ሁሉ ችግሮች ለመፍታት እየሞከረ ያለው ከዶከር ኢንክ (በአሁኑ የዶከር ስሪቶች ውስጥ ቀድሞውኑ የተዋሃደ) ገንቢ;
• ካኒኮ - ያለ Docker እንዲገነቡ የሚያስችልዎ የ Google ገንቢ;
• Buildpacks.io - የ CNCF ሙከራ አውቶማቲክ አስማት እና በተለይም አስደሳች መፍትሄ ለንብርብሮች ዳግመኛ መሠረት;
• እና እንደ ሌሎች መገልገያዎች ስብስብ ቤልዳህ, genuinetools/img...

... እና በ GitHub ላይ ስንት ኮከቦች እንዳላቸው ተመልከት። ማለትም በአንድ በኩል. docker build አለ እና የሆነ ነገር ማድረግ ይችላል, ግን በእውነቱ ጉዳዩ ሙሉ በሙሉ አልተፈታም የዚህ ማረጋገጫው የአማራጭ ሰብሳቢዎች ትይዩ እድገት ነው, እያንዳንዱም የችግሮቹን አንዳንድ ክፍሎች ይፈታል.

በ werf ውስጥ ስብሰባ

ስለዚህ ደረስን። werf (ከዚህ በፊት ዝነኛ እንደ ዳፕ) - ለብዙ አመታት ስንሰራ ከነበረው ፍላንት ኩባንያ የተገኘ ክፍት ምንጭ መገልገያ። ይህ ሁሉ የተጀመረው ከ 5 ዓመታት በፊት የዶከርፋይል ስብሰባን በሚያመቻቹ በባሽ ስክሪፕቶች ነው ፣ እና ላለፉት 3 ዓመታት ሙሉ ልማት በአንድ ፕሮጀክት ማዕቀፍ ውስጥ ተከናውኗል የራሱ የጊት ማከማቻ (መጀመሪያ በሩቢ፣ እና ከዚያ እንደገና ተፃፈ ወደ መሄድ እና በተመሳሳይ ጊዜ እንደገና ተሰይሟል). በ werf ውስጥ ምን የስብሰባ ጉዳዮች ተፈትተዋል?

በሰማያዊ ጥላ የተሸፈኑት ችግሮች ቀድሞውኑ ተተግብረዋል, ትይዩ ግንባታው በተመሳሳይ አስተናጋጅ ውስጥ ተሠርቷል, እና በቢጫው ላይ የተገለጹት ጉዳዮች በበጋው መጨረሻ ላይ ለማጠናቀቅ ታቅደዋል.

በመዝገብ ቤት ውስጥ የህትመት ደረጃ (ማተም)

ደወልን። docker push... - ምስልን ወደ መዝገቡ በመስቀል ላይ ምን አስቸጋሪ ሊሆን ይችላል? እና እዚህ ጥያቄው የሚነሳው "በምስሉ ላይ ምን መለያ ማድረግ አለብኝ?" ባለን ምክንያት ይነሳል Gitflow (ወይም ሌላ የጊት ስትራቴጂ) እና ኩበርኔትስ፣ እና ኢንደስትሪው በኩበርኔትስ ውስጥ የሚሆነው በጊት ውስጥ የሚሆነውን መከተሉን ለማረጋገጥ እየሞከረ ነው። ለነገሩ ጊት የእውነት ምንጫችን ብቻ ነው።

በዚህ ጉዳይ ላይ ምን ከባድ ነገር አለ? እንደገና መባዛትን ያረጋግጡበተፈጥሮ ውስጥ የማይለዋወጥ በጊት ውስጥ ካለው ቁርጠኝነት (የማይለወጥ), ወደ ዶከር ምስል, እሱም ተመሳሳይ በሆነ መልኩ መቀመጥ አለበት.

ለእኛም አስፈላጊ ነው መነሻውን ይወስኑ, ምክንያቱም በኩበርኔትስ ውስጥ የሚሠራው መተግበሪያ ከየትኛው እንደተገነባ ለመረዳት ስለፈለግን (ከዚያም ልዩነቶችን እና ተመሳሳይ ነገሮችን ማድረግ እንችላለን)።

የመለያ ስልቶች

የመጀመሪያው ቀላል ነው git መለያ. እንደ ምስል መለያ የተደረገበት መዝገብ አለን። 1.0. Kubernetes ይህ ምስል የሚሰቀልበት መድረክ እና ምርት አለው። በጊት ውስጥ ግዴታዎችን እንሰራለን እና በሆነ ጊዜ መለያ እንሰጣለን 2.0. ከማከማቻው ውስጥ በተሰጠው መመሪያ መሰረት እንሰበስባለን እና በመለያው ውስጥ በመዝገብ ውስጥ እናስቀምጠዋለን 2.0. ወደ መድረክ እንጠቀጣለን እና ሁሉም ነገር ደህና ከሆነ ፣ ከዚያ ወደ ምርት።

የዚህ አቀራረብ ችግር በመጀመሪያ መለያውን ማዘጋጀታችን ነው, እና ከዚያ በኋላ ብቻ ሞከርን እና ተንከባሎ. ለምን? በመጀመሪያ፣ በቀላሉ አመክንዮአዊ አይደለም፡ እስካሁን ያልሞከርነውን የሶፍትዌር ስሪት እየሰጠን ነው (ሌላ ማድረግ አንችልም፣ ምክንያቱም ለመፈተሽ መለያ ማድረግ አለብን)። በሁለተኛ ደረጃ, ይህ መንገድ ከ Gitflow ጋር ተኳሃኝ አይደለም.

ሁለተኛው አማራጭ ነው ፡፡ git መፈጸም + መለያ. ዋናው ቅርንጫፍ መለያ አለው። 1.0; ለእሱ በመመዝገቢያ ውስጥ - ወደ ምርት የተዘረጋ ምስል. በተጨማሪም የኩበርኔትስ ክላስተር ቅድመ እይታ እና የማሳያ ቅርጾች አሉት። በመቀጠል Gitflowን እንከተላለን-በዋናው ቅርንጫፍ ለልማት (develop) አዲስ ባህሪያትን እንሰራለን፣ በዚህም ምክንያት ከመለያ ጋር ቃል ኪዳን እንገባለን። #c1. ይህንን ለዪ ተጠቅመን እንሰበስባለን እና በመዝገቡ ውስጥ እናተምነው (#c1). በተመሳሳዩ ለዪ ለቅድመ-እይታ እንለቃለን። እኛ በቁርጠኝነትም እንዲሁ እናደርጋለን #c2 и #c3.

በቂ ባህሪያት እንዳሉ ስንገነዘብ ሁሉንም ነገር ማረጋጋት እንጀምራለን. በ Git ውስጥ ቅርንጫፍ ይፍጠሩ release_1.1 (መሰረቱ ላይ #c3 ከ develop). ይህን ልቀት መሰብሰብ አያስፈልግም፣ ምክንያቱም... ይህ በቀድሞው ደረጃ ተከናውኗል. ስለዚህ፣ በቀላሉ ወደ መድረክ ልንዘረጋው እንችላለን። ሳንካዎችን እናስተካክላለን #c4 እና በተመሳሳይ ሁኔታ ወደ መድረክ ይንከባለል። በተመሳሳይ ጊዜ ልማት እየተካሄደ ነው develop, ለውጦች በየጊዜው የሚወሰዱበት release_1.1. የሆነ ጊዜ ላይ፣ ቁርጠኝነት ተሰብስቦ ወደ መድረክ ተሰቅለናል፣ ይህም ደስተኞች ነን (#c25).

ከዚያ የመልቀቂያውን ቅርንጫፍ (በፍጥነት ወደፊት) እንቀላቅላለንrelease_1.1) በመምህርነት። በዚህ ቃል ኪዳን ላይ ከአዲሱ ስሪት ጋር መለያ አደረግን (1.1). ግን ይህ ምስል ቀድሞውኑ በመዝገቡ ውስጥ ተሰብስቧል ፣ ስለዚህ እንደገና ላለመሰብሰብ ፣ አሁን ባለው ምስል ላይ ሁለተኛ መለያ እንጨምራለን (አሁን በመዝገቡ ውስጥ መለያዎች አሉት) #c25 и 1.1). ከዚያ በኋላ ወደ ምርት እንጠቀጣለን.

ወደ ዝግጅት አንድ ምስል ብቻ መሰቀሉ ጉድለት አለ (#c25) እና በምርት ውስጥ የተለየ ነው (1.1), ነገር ግን "በአካል" እነዚህ ከመዝገቡ ውስጥ ተመሳሳይ ምስል መሆናቸውን እናውቃለን.

ትክክለኛው ጉዳቱ ለመዋሃድ ቁርጠኝነት ምንም ድጋፍ የለም ፣ በፍጥነት ወደፊት ማድረግ አለብዎት።

ወደ ፊት ሄደን ብልሃትን እንሰራለን...የቀላል ዶከርፋይል ምሳሌ እንመልከት፡-

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

በሚከተለው መርህ መሰረት ከእሱ ፋይል እንገንባ.

• SHA256 ከተጠቀሙባቸው ምስሎች መለያዎች (ruby:2.3 и nginx:alpine), የይዘታቸው ቼኮች ናቸው;
• ሁሉም ቡድኖች (RUN, CMD እናም ይቀጥላል.);
• SHA256 ከተጨመሩ ፋይሎች።

... እና ቼክሱን (እንደገና SHA256) ከእንደዚህ አይነት ፋይል ይውሰዱ። ይህ ፊርማ የ Docker ምስልን ይዘት የሚገልጽ ሁሉም ነገር.

ወደ ሥዕላዊ መግለጫው እንመለስ እና ከመፈፀም ይልቅ ፊርማዎችን እንጠቀማለን፣ ማለትም እ.ኤ.አ. ምስሎችን በፊርማዎች መለያ ያድርጉ።

አሁን፣ አስፈላጊ ሆኖ ሲገኝ፣ ለምሳሌ፣ ከተለቀቁት ወደ ዋና ለውጦችን ለማዋሃድ፣ እውነተኛ የውህደት ቃል መፈጸም እንችላለን፡ የተለየ መለያ ይኖረዋል፣ ግን ተመሳሳይ ፊርማ። በተመሳሳዩ መለያ ምስሉን ወደ ምርት እንዘረጋለን።

ጉዳቱ አሁን ምን ዓይነት ቁርጠኝነት ወደ ምርት እንደተገፋ መወሰን አይቻልም - ቼኮች በአንድ አቅጣጫ ብቻ ይሰራሉ። ይህ ችግር በሜታዳታ ተጨማሪ ንብርብር ተፈቷል - በኋላ ላይ የበለጠ እነግራችኋለሁ።

በ werf ውስጥ መለያ መስጠት

በዌርፍም የበለጠ ሄድን እና በአንድ ማሽን ላይ በማይከማች መሸጎጫ የተከፋፈለ ግንባታ ለመስራት በዝግጅት ላይ ነን...ስለዚህ ሁለት አይነት የዶከር ምስሎችን እየገነባን እንጠራቸዋለን። መድረክ и ምስል.

የ werf Git ማከማቻ የተለያዩ የግንባታ ደረጃዎችን የሚገልጹ በግንባታ-ተኮር መመሪያዎችን ያከማቻል (ከመጫኑ በፊት, ጫን, ከማዋቀር በፊት, አዘገጃጀት). የመጀመሪያውን ደረጃ ምስል እንደ መጀመሪያዎቹ ደረጃዎች ቼክ ድምር ከተገለጸ ፊርማ ጋር እንሰበስባለን. ከዚያም የምንጭ ኮዱን እንጨምራለን, ለአዲሱ ደረጃ ምስል የእሱን ቼክ እናሰላለን ... እነዚህ ክዋኔዎች በሁሉም ደረጃዎች ይደጋገማሉ, በዚህም ምክንያት የመድረክ ምስሎች ስብስብ እናገኛለን. ከዚያም የመጨረሻውን ምስል እንሰራለን, እሱም ስለ አመጣጡም ሜታዳታ ይዟል. እና ይህን ምስል በተለያየ መንገድ መለያ እንሰጣለን (ዝርዝሮች በኋላ).

ከዚህ በኋላ የመተግበሪያው ኮድ ብቻ የተቀየረበት አዲስ ቃል ታየ እንበል። ምን ይሆናል? ለኮድ ለውጦች፣ ማጣበቂያ ይፈጠራል እና አዲስ የመድረክ ምስል ይዘጋጃል። ፊርማው እንደ አሮጌው የመድረክ ምስል እና የአዲሱ ጠጋኝ ቼክ ድምር ይወሰናል። ከዚህ ምስል አዲስ የመጨረሻ ምስል ይፈጠራል። ተመሳሳይ ባህሪ ከሌሎች ደረጃዎች ለውጦች ጋር ይከሰታል.

ስለዚህ የመድረክ ምስሎች በስርጭት ሊቀመጡ የሚችሉ መሸጎጫዎች ናቸው, እና ከእሱ የተፈጠሩት ምስሎች ወደ ዶከር መዝገብ ቤት ይሰቀላሉ.

መዝገቡን ማጽዳት

ከተሰረዙ መለያዎች በኋላ የተንጠለጠሉ ንብርብሮችን ስለመሰረዝ እየተነጋገርን አይደለም - ይህ የ Docker መዝገብ ቤት ራሱ መደበኛ ባህሪ ነው። ስለ አንድ ሁኔታ እየተነጋገርን ያለነው ብዙ የዶከር መለያዎች ሲከማቹ እና አንዳንዶቹን እንደማንፈልግ ተረድተናል ነገር ግን ቦታ ይወስዳሉ (እና/ወይንም እንከፍላለን)።

የጽዳት ስልቶች ምንድ ናቸው?

1. ምንም ማድረግ አይችሉም አታጽዱ. አንዳንድ ጊዜ ብዙ መለያዎችን ከመፍታት ይልቅ ለተጨማሪ ቦታ ትንሽ መክፈል ቀላል ነው። ግን ይህ እስከ አንድ ነጥብ ድረስ ብቻ ነው የሚሰራው.
2. ሙሉ ዳግም ማስጀመር. ሁሉንም ምስሎች ከሰረዙ እና በ CI ስርዓት ውስጥ ያሉትን አሁን ያሉትን ብቻ እንደገና ከተገነቡ ችግር ሊፈጠር ይችላል. ኮንቴይነሩ በምርት ላይ እንደገና ከተጀመረ, ለእሱ አዲስ ምስል ይጫናል - እስካሁን በማንም ያልተረጋገጠ. ይህ የማይለወጥ መሠረተ ልማትን ይገድላል.
3. ሰማያዊ-አረንጓዴ. አንድ መዝገብ መብዛት ጀመረ - ምስሎችን ወደ ሌላ እንሰቅላለን። ልክ እንደ ቀድሞው ዘዴ ተመሳሳይ ችግር: መሞላት የጀመረውን መዝገብ በየትኛው ጊዜ ማጽዳት ይችላሉ?
4. በጊዜው. ከ1 ወር በላይ የቆዩ ምስሎች በሙሉ ይሰረዙ? ግን በእርግጠኝነት ለአንድ ወር ያልዘመነ አገልግሎት ይኖራል...
5. በእጅ አስቀድሞ ሊሰረዝ የሚችለውን ይወስኑ።

ሁለት እውነተኛ አዋጭ አማራጮች አሉ፡ አታጽዱ ወይም የሰማያዊ-አረንጓዴ + ጥምረት በእጅ። በሁለተኛው ጉዳይ ላይ ስለሚከተሉት ጉዳዮች እየተነጋገርን ነው-መመዝገቢያውን ለማጽዳት ጊዜው እንደደረሰ ሲረዱ, አዲስ ይፍጠሩ እና ሁሉንም አዲስ ምስሎች ወደ እሱ ለምሳሌ በወር ውስጥ ይጨምራሉ. እና ከአንድ ወር በኋላ በኩበርኔትስ ውስጥ የትኞቹ ፖዶች አሁንም አሮጌውን መዝገብ እየተጠቀሙ እንደሆኑ ይመልከቱ እና ወደ አዲሱ መዝገብ ቤት ያስተላልፉ።

ምን ላይ ደርሰናል። werf? እኛ እንሰበስባለን:

1. Git head: ሁሉም መለያዎች, ሁሉም ቅርንጫፎች - በምስሎቹ ውስጥ በ Git ውስጥ መለያ የተደረገባቸውን ነገሮች ሁሉ እንደሚያስፈልገን በማሰብ (እና ካልሆነ, በ Git እራሱ ውስጥ መሰረዝ አለብን);
2. በአሁኑ ጊዜ ወደ ኩበርኔትስ የሚወጡ ሁሉም እንክብሎች;
3. የድሮ ReplicaSets (በቅርብ ጊዜ የተለቀቀው)፣ እና የ Helm ልቀቶችን ለመቃኘት እና የቅርብ ጊዜ ምስሎችን እዚያ ለመምረጥ አቅደናል።

... እና ከዚህ ስብስብ የተፈቀደላቸው ዝርዝር ያዘጋጁ - የማንሰርዛቸውን የምስሎች ዝርዝር። ሁሉንም ነገር እናጸዳለን, ከዚያ በኋላ ወላጅ አልባ የመድረክ ምስሎችን እናገኛለን እና እነሱንም እንሰርዛቸዋለን.

ደረጃ አሰማራ

አስተማማኝ መግለጫ

በስምሪት ውስጥ ትኩረትን ለመሳብ የምፈልገው የመጀመሪያው ነጥብ የተሻሻለው የንብረት ውቅር መልቀቅ ነው፣ በአዋጅ የተገለጸው። የኩበርኔትስ ሀብቶችን የሚገልጽ የመጀመሪያው የ YAML ሰነድ ሁል ጊዜ በእውነቱ በክላስተር ውስጥ ከሚሰራው ውጤት በጣም የተለየ ነው። ኩበርኔትስ ወደ ውቅር ስለሚጨምር፡-

1. መለያዎች;
2. የአገልግሎት መረጃ;
3. ብዙ ነባሪ እሴቶች;
4. ክፍል አሁን ካለው ሁኔታ ጋር;
5. እንደ የመግቢያ webhook አካል የተደረጉ ለውጦች;
6. የተለያዩ ተቆጣጣሪዎች (እና የጊዜ ሰሌዳው) ሥራ ውጤት.

ስለዚህ, አዲስ የንብረት ውቅር ሲመጣ (አዲስ) አሁን ያለውን የ"ቀጥታ" ውቅር ወስደን መፃፍ አንችልም (መኖር). ይህንን ለማድረግ ማነፃፀር አለብን አዲስ ከመጨረሻው የተተገበረው ውቅር ጋር (ለመጨረሻ ጊዜ የተተገበረ) እና ወደ ላይ ይንከባለል መኖር ማጣበቂያ ተቀብሏል.

ይህ አካሄድ ይባላል ባለ 2-መንገድ ውህደት. ለምሳሌ በሄልም ውስጥ ጥቅም ላይ ይውላል.

በተጨማሪም አለ ባለ 3-መንገድ ውህደትበዚህ ውስጥ የሚለየው፡-

• ማወዳደር ለመጨረሻ ጊዜ የተተገበረ и አዲስ, የተሰረዘውን እንመለከታለን;
• ማወዳደር አዲስ и መኖር, የተጨመረውን ወይም የተለወጠውን እንመለከታለን;
• የተደመረው ፕላስተር በ ላይ ተተግብሯል መኖር.

1000+ አፕሊኬሽኖችን ከ Helm ጋር አሰማርተናል፣ ስለዚህ የምንኖረው በ2-መንገድ ውህደት ነው። ነገር ግን፣ ሄልም በመደበኛነት እንዲሠራ የሚረዱን በፕላተቶቻችን የፈታናቸው በርካታ ችግሮች አሉት።

እውነተኛ የታቀደ ልቀት ሁኔታ

የእኛ የሲአይ ስርዓት በሚቀጥለው ክስተት ላይ በመመስረት ለ Kubernetes አዲስ ውቅር ካመነጨ በኋላ ለአገልግሎት ያስተላልፋል (ተግብር) ወደ ክላስተር - Helm በመጠቀም ወይም kubectl apply. በመቀጠል፣ ቀደም ሲል የተገለጸው የኤን-መንገድ ውህደት ይከሰታል፣ ለዚህም የ Kubernetes API ለ CI ስርዓት እና ለተጠቃሚው ምላሽ ይሰጣል።

ሆኖም ግን, አንድ ትልቅ ችግር አለ: ከሁሉም በኋላ የተሳካ መተግበሪያ ማለት የተሳካ ልቀት ማለት አይደለም።. ኩበርኔትስ ምን ለውጦች መተግበር እንዳለባቸው ከተረዳ እና ከተተገበረ ውጤቱ ምን እንደሚሆን አናውቅም. ለምሳሌ በፊተኛው ክፍል ውስጥ ያሉ ፖድዎችን ማዘመን እና እንደገና ማስጀመር ስኬታማ ሊሆን ይችላል ነገር ግን በኋለኛው ውስጥ አይደለም እና አሂድ አፕሊኬሽን ምስሎችን የተለያዩ ስሪቶች እናገኛለን።

ሁሉንም ነገር በትክክል ለመስራት ይህ እቅድ ተጨማሪ ማገናኛን ይፈልጋል - ከ Kubernetes API የሁኔታ መረጃ የሚቀበል እና የነገሮችን ትክክለኛ ሁኔታ ለበለጠ ትንተና የሚያስተላልፍ ልዩ መከታተያ። በ Go ውስጥ የክፍት ምንጭ ቤተ-መጽሐፍት ፈጠርን - cubedog (ማስታወቂያውን ይመልከቱ እዚህ)ይህንን ችግር የሚፈታ እና በ werf ውስጥ የተገነባ ነው.

የዚህ መከታተያ ባህሪ በ werf ደረጃ የተዋቀረው በDeployments ወይም StatefulSets ላይ የተቀመጡ ማብራሪያዎችን በመጠቀም ነው። ዋና ማብራሪያ- fail-mode - የሚከተሉትን ትርጉሞች ይረዳል:

• IgnoreAndContinueDeployProcess - ይህንን አካል የማውጣትን ችግሮች ችላ ብለን ማሰማራቱን እንቀጥላለን;
• FailWholeDeployProcessImmediately - በዚህ አካል ውስጥ ያለ ስህተት የማሰማራት ሂደቱን ያቆማል;
• HopeUntilEndOfDeployProcess - ይህ አካል በማሰማራት መጨረሻ ላይ እንደሚሰራ ተስፋ እናደርጋለን.

ለምሳሌ፣ ይህ የሀብቶች እና የማብራሪያ እሴቶች ጥምረት fail-mode:

ለመጀመሪያ ጊዜ ስንሰራጭ የመረጃ ቋቱ (MongoDB) ገና ዝግጁ ላይሆን ይችላል - ማሰማራት አይሳካም። ግን እስኪጀምር ድረስ ለጊዜው መጠበቅ ትችላላችሁ፣ እና ማሰማራቱ አሁንም ይከናወናል።

በ werf ውስጥ ለኩቤዶግ ሁለት ተጨማሪ ማብራሪያዎች አሉ።

• failures-allowed-per-replica - ለእያንዳንዱ ቅጂ የሚፈቀደው ቁጥር;
• show-logs-until - ከሁሉም የታቀፉ ፖድዎች ዌርፍ (በ stdout) ምዝግብ ማስታወሻዎች እስከሚያሳዩበት ጊዜ ድረስ ይቆጣጠራል። ነባሪው ነው። PodIsReady (ትራፊክ ወደ ፖድ መምጣት ሲጀምር የማንፈልጋቸውን መልዕክቶች ችላ ለማለት) ነገር ግን እሴቶች እንዲሁ ልክ ናቸው፡ ControllerIsReady и EndOfDeploy.

ከማሰማራት ሌላ ምን እንፈልጋለን?

ቀደም ሲል ከተገለጹት ሁለት ነጥቦች በተጨማሪ እኛ እንፈልጋለን-

• ለማየት። መዝገቦች - እና አስፈላጊ የሆኑትን ብቻ, እና ሁሉንም ነገር በተከታታይ አይደለም;
• ትራክ እድገት, ምክንያቱም ስራው ለብዙ ደቂቃዎች "በፀጥታ" ከተሰቀለ, እዚያ ምን እየተፈጠረ እንዳለ መረዳት አስፈላጊ ነው;
• አለ አውቶማቲክ መልሶ መመለስ የሆነ ችግር ከተፈጠረ (እና ስለዚህ የማሰማራቱን ትክክለኛ ሁኔታ ማወቅ በጣም አስፈላጊ ነው). ልቀቱ አቶሚክ መሆን አለበት፡ ወይ እስከ መጨረሻው ያልፋል፣ ወይም ሁሉም ነገር ወደ ቀድሞው ሁኔታው ​​ይመለሳል።

ውጤቶች

ለእኛ እንደ ኩባንያ ፣ ሁሉንም የተገለጹትን ልዩነቶች በተለያዩ የማስረከቢያ ደረጃዎች (ግንባታ ፣ ማተም ፣ ማሰማራት) ለመተግበር የ CI ስርዓት እና መገልገያ በቂ ናቸው ። werf.

ከመደምደሚያ ይልቅ -

በ werf እገዛ ለዴቭኦፕስ መሐንዲሶች ብዙ ችግሮችን በመፍታት ረገድ ጥሩ መሻሻል አሳይተናል እናም ሰፊው ማህበረሰብ ቢያንስ ይህንን መገልገያ በተግባር ቢሞክር ደስ ይለናል። አንድ ላይ ጥሩ ውጤት ለማግኘት ቀላል ይሆናል.

ቪዲዮዎች እና ስላይዶች

ቪዲዮ ከአፈፃፀሙ (~ 47 ደቂቃዎች):

የዝግጅት አቀራረብን ሪፖርት ያድርጉ፡

PS

በብሎጋችን ውስጥ ስለ ኩበርኔትስ ሌሎች ዘገባዎች፡-

• «በኩበርኔትስ ውስጥ የራስ-ስኬል እና የንብረት አስተዳደር» (ዲሚትሪ ስቶልያሮቭ፤ ኤፕሪል 27፣ 2019 በ"አድማ" ላይ);
• «Kubernetes ማራዘም እና ማሟያ» (አንድሬ ፖሎቮቭ፣ ኤፕሪል 8፣ 2019 በ Saint HighLoad++ ላይ);
• «የውሂብ ጎታዎች እና Kubernetes» (ዲሚትሪ ስቶልያሮቭ፣ ኖቬምበር 8፣ 2018 በሃይሎድ++ ላይ);
• «ክትትል እና Kubernetes» (ዲሚትሪ ስቶልያሮቭ፣ ሜይ 28፣ 2018 በRootConf);
• «CI/ሲዲ ከ Kubernetes እና GitLab ጋር ያሉ ምርጥ ልምዶች» (ዲሚትሪ ስቶልያሮቭ፣ ኖቬምበር 7፣ 2017 በሃይሎድ++ ላይ);
• «በትንሽ ፕሮጀክቶች ውስጥ ከ Kubernetes ጋር ያለን ልምድ» (ዲሚትሪ ስቶልያሮቭ፣ ሰኔ 6፣ 2017 በRootConf).

ምንጭ: hab.com