🥇የሚቻል፡ የ120 ቪኤም ውቅር ከCoreOS ወደ CentOS በ18 ወራት ስደት

ይህ የንግግሩ ግልባጭ ነው። DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

ይህ በራሱ የተጻፈ የውቅረት ማኔጅመንት ሲስተም የተጠቀመ የፕሮጀክት ታሪክ ነው እና ወደ አንሴብል የተደረገው ሽግግር 18 ወራት የፈጀበት ምክንያት።

ቀን ቁጥር - ХХХ: ከመጀመሪያው በፊት

መጀመሪያ ላይ፣ መሠረተ ልማቱ Hyper-V የሚሄዱ ብዙ የተለያዩ አስተናጋጆችን ያቀፈ ነበር። ቨርቹዋል ማሽን መፍጠር ብዙ እርምጃዎችን ይጠይቃል፡ ዲስኮችን በትክክለኛው ቦታ ላይ ማስቀመጥ፣ ዲ ኤን ኤስ መመዝገብ፣ DHCP ማስቀመጥ፣ የVM ውቅረትን በgit ማከማቻ ውስጥ ማስቀመጥ። ይህ ሂደት በከፊል ሜካናይዝድ የተደረገ ነበር፣ ነገር ግን ለምሳሌ ቪኤምኤስ በአስተናጋጆች መካከል በእጅ ተሰራጭቷል። ግን፣ ለምሳሌ፣ ገንቢዎች በgit ውስጥ ያለውን የVM ውቅር አስተካክለው ቪኤምን እንደገና በማስነሳት ሊተገበሩ ይችላሉ።

ብጁ ውቅር አስተዳደር መፍትሔ

የመጀመርያው ሃሳብ IaC ተብሎ የተፀነሰ ነው፡ ብዙ ሀገር አልባ ቪኤምዎች ዳግም ሲነሱ ግዛታቸውን ወደ ዜሮ ዳግም ያስጀምራሉ ብዬ እገምታለሁ። የVM ውቅር አስተዳደር ምን ነበር? በስርዓተ-ፆታ ቀላል ይመስላል:

የማይንቀሳቀስ MAC ለቪኤም ተቸንክሯል።
ISO ያለው CoreOS እና የቡት ዲስክ ከቪኤም ጋር ተገናኝተዋል።
CoreOS የማበጀት ስክሪፕቱን በአይፒው ላይ በመመስረት ከድር አገልጋይ በማውረድ ይጀምራል።
ስክሪፕቱ በአይፒ አድራሻው መሰረት የVM ውቅርን በSCP በኩል ያወርዳል።
የስርዓት ዩኒት ፋይሎች የእግር ልብስ እና የባሽ እስክሪፕቶች የእግር ልብስ ተጀምሯል።

ይህ መፍትሔ ብዙ ግልጽ ችግሮች ነበሩት:

CoreOS ISO ተቋርጧል።
ቪኤም ሲሰደዱ/ሲፈጠሩ ብዙ ውስብስብ አውቶሜትድ ድርጊቶች እና አስማት።
የተወሰነ የሶፍትዌር እትም ሲያስፈልግ ለማዘመን አስቸጋሪ ነው። በከርነል ሞጁሎች የበለጠ አስደሳች።
ቪኤም ያለ ውሂብ እንዲሁ አልተገኙም፣ ማለትም. ቪኤምኤስ ተጨማሪ የተጠቃሚ ውሂብ ከተጫነበት ዲስክ ጋር ታየ።
አንድ ሰው የስርዓተ ክወናውን ጥገኞች ያለማቋረጥ እየደበደበ ነበር እና CoreOS ዳግም በሚነሳበት ጊዜ ይቀዘቅዛል። በCoreOS ውስጥ ያሉትን መሳሪያዎች በመጠቀም ይህንን ለመያዝ አስቸጋሪ ነበር።
የምስጢር አስተዳደር.
CM አልነበረም። ለCoreOS bash እና YML ውቅሮች ነበሩ።

የVM ውቅርን ለመተግበር፣ ዳግም ማስጀመር አለብዎት፣ ግን ዳግም ላይነሳ ይችላል። ግልጽ የሆነ ችግር ይመስላል, ግን ቋሚ ዲስኮች የሉም - ምዝግብ ማስታወሻዎችን ለማስቀመጥ ምንም ቦታ የለም. ደህና፣ እሺ፣ ምዝግብ ማስታወሻዎቹ እንዲላኩ የከርነል መጫኛ አማራጩን ለመጨመር እንሞክር። ግን አይሆንም, ሁሉም ነገር ምን ያህል የተወሳሰበ ነው.

ቀን #0፡ ችግሩን ይወቁ

የተለመደው የልማት መሠረተ ልማት ነበር: ጄንኪንስ, የሙከራ አካባቢዎች, ክትትል, መዝገብ ቤት. CoreOS የተነደፈው k8s ስብስቦችን ለማስተናገድ ነው፣ i.e. ችግሩ CoreOS እንዴት ጥቅም ላይ እንደዋለ ነበር። የመጀመሪያው እርምጃ ቁልል መምረጥ ነበር. በዚህ ላይ ተረጋጋን።

CentOS እንደ መሰረታዊ ስርጭት, ምክንያቱም ይህ ለምርት አካባቢዎች በጣም ቅርብ የሆነ ስርጭት ነው.
የሚጠራ ለማዋቀር አስተዳደር, ምክንያቱም ላይ ሰፊ ምርመራ ተደረገ።
ጄንከንዝ ነባር ሂደቶችን በራስ-ሰር ለማካሄድ እንደ ማዕቀፍ, ምክንያቱም ቀድሞውኑ ለልማት ሂደቶች በንቃት ጥቅም ላይ ውሏል
የሚያስችሉ ከፍተኛ-V እንደ ምናባዊ መድረክ. ከታሪኩ ወሰን በላይ የሆኑ በርካታ ምክንያቶች አሉ, ግን በአጭሩ - ደመናን መጠቀም አንችልም, የራሳችንን ሃርድዌር መጠቀም አለብን.

ቀን ቁጥር 30: ነባር ስምምነቶችን ማስተካከል - ስምምነቶች እንደ ኮድ

ቁልል ግልጽ በሆነ ጊዜ ለመንቀሳቀስ ዝግጅት ተጀመረ። ነባር ስምምነቶችን በኮድ መልክ ማስተካከል (ስምምነቶች እንደ ኮድ!) ሽግግር የእጅ ሥራ -> ሜካናይዜሽን -> አውቶማቲክ.

1. ቪኤምዎችን ያዋቅሩ

ለዚህ ትልቅ ስራ ይሰራል። በትንሹ የሰውነት እንቅስቃሴዎች የVM ውቅሮችን መቆጣጠር ይችላሉ፡-

የጂት ማከማቻ ይፍጠሩ።
የቪኤምዎችን ዝርዝር በእቃ ዝርዝር ውስጥ፣ በመጫወቻ መጽሐፍት እና ሚናዎች ውስጥ አወቃቀሮችን እናስቀምጣለን።
Ansible ን ማስኬድ የሚችሉበት ልዩ የጄንኪንስ ባሪያ እያዘጋጀን ነው።
ሥራ እንፈጥራለን እና ጄንኪንስን እናዋቅራለን።

የመጀመሪያው ሂደት ዝግጁ ነው. ስምምነቶቹ የተስተካከሉ ናቸው.

2. አዲስ ቪኤም ይፍጠሩ

እዚህ ሁሉም ነገር በጣም ምቹ አልነበረም. ከሊኑክስ በ Hyper-V ላይ ቪኤም ለመፍጠር በጣም ምቹ አይደለም. ይህንን ሂደት ሜካናይዜሽን ለማድረግ ከተደረጉት ሙከራዎች አንዱ፡-

Ansbile በWinRM በኩል ወደ ዊንዶውስ አስተናጋጅ ይገናኛል።
አቅም ያለው የኃይል ሼል ስክሪፕት ያካሂዳል።
Powershell ስክሪፕት አዲስ ቪኤም ይፈጥራል።
Hyper-V/ScVMM ን በመጠቀም በእንግዳው ስርዓተ ክወና ውስጥ ቪኤም ሲፈጥሩ የአስተናጋጁ ስም ተዋቅሯል።
የDHCP ኪራይ ውል ሲያዘምኑ፣ ቪኤም የአስተናጋጅ ስሙን ይልካል።
በጎራ ተቆጣጣሪው በኩል መደበኛ የ ddns እና dhcp ውህደት የዲኤንኤስ መዝገቡን ያዋቅራል።
VMን ወደ ክምችትዎ ማከል እና በአንሲብል ማዋቀር ይችላሉ።

3.የቪኤም አብነት ፍጠር

እዚህ ምንም አልፈጠሩም - ፓከር ወሰዱ።

ማሸጊያውን፣ kickstart config ወደ git ማከማቻው ያክሉ።
ልዩ የጄንኪንስ ባሪያን በሃይፐር-ቪ እና ፓከር በማዘጋጀት ላይ።
ሥራ እንፈጥራለን እና ጄንኪንስን እናዋቅራለን።

ይህ አገናኝ እንዴት እንደሚሰራ፡-

ፓከር ባዶ ቪኤም ይፈጥራል እና ISO ን ያነሳል።
የ VM ቡትስ፣ ፓከር የኪክስታርት ፋይላችንን ከፍሎፒ ዲስክ ወይም http ለመጠቀም ትዕዛዙን ወደ ቡት ጫኚው ውስጥ ያስገባል።
አናኮንዳ በእኛ ውቅረት ተጀምሯል፣ እና የመጀመሪያው የስርዓተ ክወና ውቅር ተከናውኗል።
ፓከር ቪኤም እስኪገኝ ድረስ ይጠብቃል።
በቪኤም ውስጥ ያለው ፓከር በአካባቢያዊ ሁኔታ ሊሠራ ይችላል።
አሲሲሲል በደረጃ #1 ውስጥ የሚሰራውን በትክክል ተመሳሳይ ሚናዎችን ይጠቀማል።
ፓከር የVM አብነት ወደ ውጭ ይልካል።

ቀን #75፡ ስምምነቱን ሳይሰበር እንደገና ፍጠር = ሊሞከር የሚችል + የሙከራ ኩሽና

የውል ስምምነቶችን በኮድ ማንሳት በቂ ላይሆን ይችላል። ከሁሉም በላይ, በሂደቱ ውስጥ እና በሂደቱ ውስጥ የሆነ ነገር ለመለወጥ ከፈለጉ, የሆነ ነገር መስበር ይችላሉ. ስለዚህ, በመሠረተ ልማት ረገድ, የዚህን መሰረተ ልማት መሞከር ይታያል. በቡድኑ ውስጥ እውቀትን ለማመሳሰል፣ ሊሆኑ የሚችሉ ሚናዎችን መሞከር ጀመርን። ወደ ጥልቀት አልገባም ምክንያቱም ... በዚያን ጊዜ የተከናወኑትን ክስተቶች የሚገልጽ ጽሑፍ አለ። ከቻልክ ፈትኑኝ ወይም የYML ፕሮግራመሮች የመሞከር ህልም ካላችሁ ፈትኑኝ?(ስፖይለር ይህ የመጨረሻው ስሪት አልነበረም እና በኋላ ሁሉም ነገር ይበልጥ የተወሳሰበ ሆነ እንዴት መፈተሽ መጀመር እንደሚቻል, ፕሮጀክቱን በአንድ አመት ውስጥ እንደገና ማደስ እና ማበድ የለበትም).

ቀን #130፡ ምናልባት CentOS+ansible አያስፈልግም? ምናልባት ክፍት የሥራ ቦታ?

መሰረተ ልማቶችን የማስተዋወቅ ሂደት ብቸኛው እንዳልነበር እና የጎን ንኡስ ፕሮጀክቶች እንደነበሩ መረዳት አለብን። ለምሳሌ፣ የእኛን መተግበሪያ በክፍት ፈረቃ ለማስጀመር ጥያቄ መጣ እና ይህም ከአንድ ሳምንት በላይ ምርምር አድርጓል አፕሊኬሽኑን በOpenshift ውስጥ እናስጀምረዋለን እና ያሉትን መሳሪያዎችን እናነፃፅራለን የመንቀሳቀስ ሂደቱን የቀነሰው. ውጤቱም ክፍት ሥራ ሁሉንም ፍላጎቶች የማይሸፍን ነው ፣ እውነተኛ ሃርድዌር ወይም ቢያንስ ከከርነል ጋር የመጫወት ችሎታ ያስፈልግዎታል።

ቀን # 170፡ ክፍት ስራ ተስማሚ አይደለም፣ በWindows Azure Pack እድል እንውሰድ?

Hyper-V በጣም ተግባቢ አይደለም፣ SCVMM የተሻለ አያደርገውም። ነገር ግን ለ SCVMM ተጨማሪ እና Azureን የሚመስለው እንደ ዊንዶውስ አዙር ጥቅል ያለ ነገር አለ። ግን በእውነቱ, ምርቱ የተተወ ይመስላል: ሰነዶቹ የተበላሹ አገናኞች እና በጣም ትንሽ ናቸው. ነገር ግን የደመናችንን ሕይወት ለማቅለል አማራጮች ጥናት አካል አድርገው፣ እነሱም ተመልክተውታል።

ቀን #250፡ የዊንዶውስ አዙር ጥቅል በጣም ጥሩ አይደለም። በ SCVMM ላይ እንቆያለን።

የዊንዶውስ አዙር ጥቅል ተስፋ ሰጪ መስሎ ነበር፣ ነገር ግን WAPን ከውስብስብ ጉዳዮቹ ጋር ላለማስፈላለግ ባህሪያት ወደ ስርዓቱ እንዳያመጣ ተወስኗል እና ከ SCVMM ጋር ቆየ።

ቀን # 360: የዝሆንን ቁራጭ መብላት

ከአንድ አመት በኋላ ብቻ ወደ ቦታው ለመሄድ መድረክ ዝግጁ ነበር እና የመንቀሳቀስ ሂደቱ ተጀመረ. ለዚሁ ዓላማ, SMART ተግባር ተዘጋጅቷል. ሁሉንም ቪኤምዎች ፈትሸው አወቃቀሩን አንድ በአንድ አውጥተን በአንሲብል ገልፀው በሙከራዎች ሸፍነን ጀመርን።

ቀን # 450: ምን አይነት ስርዓት አግኝተዋል?

ሂደቱ ራሱ አስደሳች አይደለም. መደበኛ ነው ፣ አብዛኛዎቹ አወቃቀሮች በአንጻራዊነት ቀላል ወይም isomorphic እንደነበሩ ልብ ሊባል ይችላል እና በፓሬቶ መርህ መሠረት 80% የቪኤም ውቅሮች 20% ጊዜ ያስፈልጋቸዋል። በተመሳሳይ መርህ 80% የሚሆነው ጊዜ እንቅስቃሴውን ለማዘጋጀት እና በእንቅስቃሴው ላይ 20% ብቻ ነው.

ቀን # 540: የመጨረሻ

በ18 ወራት ውስጥ ምን ሆነ?

ስምምነቶቹ ኮድ ሆኑ.
የእጅ ሥራ -> ሜካናይዜሽን -> አውቶማቲክ.

አገናኞች

ምንጭ: hab.com

ሊቻል የሚችል፡ የ120 ቪኤም ውቅር ከCoreOS ወደ CentOS በ18 ወራት ውስጥ ማዛወር