எங்கள் தொழில்நுட்ப இயக்குனரின் சமீபத்திய பேச்சுகளின் அடிப்படையில் வெளியீடுகளுடன் எங்கள் வலைப்பதிவைத் தொடங்குவோம் (டிமிட்ரி ஸ்டோலியாரோவ்). அவை அனைத்தும் 2016 இல் பல்வேறு தொழில்முறை நிகழ்வுகளில் நடந்தன மற்றும் DevOps மற்றும் Docker என்ற தலைப்புக்கு அர்ப்பணிக்கப்பட்டன. Badoo அலுவலகத்தில் டோக்கர் மாஸ்கோ சந்திப்பின் ஒரு வீடியோ, எங்களிடம் ஏற்கனவே உள்ளது நிகழ்நிலை. புதியவை அறிக்கைகளின் சாரத்தை வெளிப்படுத்தும் கட்டுரைகளுடன் இணைக்கப்படும். அதனால்…
மாநாட்டில் மே 31 , "ரஷியன் இன்டர்நெட் டெக்னாலஜிஸ்" (ஆர்ஐடி++ 2016) திருவிழாவின் ஒரு பகுதியாக நடத்தப்பட்டது, "தொடர்ச்சியான வரிசைப்படுத்தல் மற்றும் வரிசைப்படுத்தல்" என்ற பிரிவு, "டோக்கருடன் தொடர்ச்சியான விநியோகத்தின் சிறந்த நடைமுறைகள்" என்ற அறிக்கையுடன் திறக்கப்பட்டது. இது டோக்கர் மற்றும் பிற ஓப்பன் சோர்ஸ் தயாரிப்புகளைப் பயன்படுத்தி தொடர்ச்சியான டெலிவரி (சிடி) செயல்முறையை உருவாக்குவதற்கான சிறந்த நடைமுறைகளை சுருக்கி முறைப்படுத்தியது. உற்பத்தியில் இந்த தீர்வுகளுடன் நாங்கள் வேலை செய்கிறோம், இது நடைமுறை அனுபவத்தை நம்புவதற்கு அனுமதிக்கிறது.
ஒரு மணி நேரம் செலவழிக்க வாய்ப்பு இருந்தால் , அதை முழுமையாகப் பார்க்க பரிந்துரைக்கிறோம். இல்லையெனில், உரை வடிவத்தில் முக்கிய சுருக்கம் கீழே உள்ளது.
டோக்கருடன் தொடர்ச்சியான டெலிவரி
கீழே தொடர்ச்சியான டெலிவரி Git களஞ்சியத்திலிருந்து பயன்பாட்டுக் குறியீடு முதலில் உற்பத்திக்கு வந்து, பின்னர் காப்பகத்தில் முடிவடைவதன் விளைவாக நிகழ்வுகளின் சங்கிலியைப் புரிந்துகொள்கிறோம். இது போல் தெரிகிறது: Git → Build → Test → Release → Operate.
அறிக்கையின் பெரும்பகுதி கட்டுமான நிலைக்கு (விண்ணப்ப அசெம்பிளி) அர்ப்பணிக்கப்பட்டுள்ளது, மேலும் தலைப்புகள் வெளியீடு மற்றும் இயக்கம் ஆகியவை சுருக்கமாகத் தொடுக்கப்பட்டன. அவற்றைத் தீர்க்க உங்களை அனுமதிக்கும் சிக்கல்கள் மற்றும் வடிவங்களைப் பற்றி நாங்கள் பேசுவோம், மேலும் இந்த வடிவங்களின் குறிப்பிட்ட செயலாக்கங்கள் வேறுபட்டிருக்கலாம்.
இங்கு ஏன் டோக்கர் தேவை? இந்த ஓப்பன் சோர்ஸ் கருவியின் பின்னணியில் தொடர்ச்சியான டெலிவரி நடைமுறைகளைப் பற்றி பேச முடிவு செய்தது சும்மா இல்லை. முழு அறிக்கையும் அதன் பயன்பாட்டிற்கு அர்ப்பணிக்கப்பட்டிருந்தாலும், பயன்பாட்டுக் குறியீடு வெளியீட்டின் முக்கிய வடிவத்தைக் கருத்தில் கொள்ளும்போது பல காரணங்கள் வெளிப்படுத்தப்படுகின்றன.
முக்கிய வெளியீடு முறை
எனவே, பயன்பாட்டின் புதிய பதிப்புகளை நாங்கள் வெளியிடும்போது, நாங்கள் நிச்சயமாக எதிர்கொள்கிறோம் வேலையில்லா பிரச்சனை, உற்பத்தி சேவையகத்தை மாற்றும் போது உருவாக்கப்பட்டது. பயன்பாட்டின் பழைய பதிப்பிலிருந்து புதிய பதிப்பிற்கு ட்ராஃபிக் உடனடியாக மாற முடியாது: முதலில், புதிய பதிப்பு வெற்றிகரமாக பதிவிறக்கம் செய்யப்படவில்லை என்பதை உறுதிப்படுத்த வேண்டும், ஆனால் "வார்ம் அப்" (அதாவது, கோரிக்கைகளை வழங்க முற்றிலும் தயாராக உள்ளது).
எனவே, சிறிது நேரம் பயன்பாட்டின் இரண்டு பதிப்புகளும் (பழைய மற்றும் புதியவை) ஒரே நேரத்தில் வேலை செய்யும். இது தானாகவே வழிவகுக்கும் பகிரப்பட்ட வள மோதல்: பிணையம், கோப்பு முறைமை, ஐபிசி போன்றவை. டோக்கருடன், பயன்பாட்டின் வெவ்வேறு பதிப்புகளை தனித்தனி கொள்கலன்களில் இயக்குவதன் மூலம் இந்த சிக்கல் எளிதில் தீர்க்கப்படுகிறது, இதற்காக ஒரே ஹோஸ்டில் (சேவையகம்/மெய்நிகர் இயந்திரம்) ஆதார தனிமைப்படுத்தல் உத்தரவாதம் அளிக்கப்படுகிறது. நிச்சயமாக, நீங்கள் காப்பு இல்லாமல் சில தந்திரங்களைப் பெறலாம், ஆனால் ஒரு ஆயத்த மற்றும் வசதியான கருவி இருந்தால், அதற்கு நேர்மாறான காரணம் உள்ளது - அதை புறக்கணிக்க வேண்டாம்.
கன்டெய்னரைசேஷன் பயன்படுத்தும்போது பல நன்மைகளை வழங்குகிறது. எந்த பயன்பாடும் சார்ந்துள்ளது குறிப்பிட்ட பதிப்பு (அல்லது பதிப்பு வரம்பு) மொழிபெயர்ப்பாளர், தொகுதிகள்/நீட்டிப்புகள், மற்றும் அவற்றின் பதிப்புகளின் கிடைக்கும் தன்மை. இது உடனடியாக இயங்கக்கூடிய சூழலுக்கு மட்டுமல்ல, முழு சூழலுக்கும் பொருந்தும் கணினி மென்பொருள் மற்றும் அதன் பதிப்பு (பயன்படுத்தப்படும் லினக்ஸ் விநியோகம் வரை). கொள்கலன்களில் பயன்பாட்டுக் குறியீடு மட்டுமல்ல, தேவையான பதிப்புகளின் முன்பே நிறுவப்பட்ட கணினி மற்றும் பயன்பாட்டு மென்பொருளும் இருப்பதால், சார்புகளில் உள்ள சிக்கல்களை நீங்கள் மறந்துவிடலாம்.
நாம் பொதுமைப்படுத்த முக்கிய வெளியீடு முறை பின்வரும் காரணிகளைக் கருத்தில் கொண்டு புதிய பதிப்புகள்:
- முதலில், பயன்பாட்டின் பழைய பதிப்பு முதல் கொள்கலனில் இயங்குகிறது.
- புதிய பதிப்பு பின்னர் உருட்டப்பட்டு இரண்டாவது கொள்கலனில் "சூடு" செய்யப்படுகிறது. இந்தப் புதிய பதிப்பானது புதுப்பிக்கப்பட்ட பயன்பாட்டுக் குறியீட்டை மட்டுமின்றி, அதன் சார்புநிலைகள் மற்றும் கணினி கூறுகள் (உதாரணமாக, OpenSSL இன் புதிய பதிப்பு அல்லது முழு விநியோகம்) ஆகியவற்றைக் கொண்டு செல்லலாம் என்பது குறிப்பிடத்தக்கது.
- கோரிக்கைகளை வழங்க புதிய பதிப்பு முழுமையாக தயாராக இருக்கும் போது, போக்குவரத்து முதல் கொள்கலனில் இருந்து இரண்டாவது இடத்திற்கு மாறுகிறது.
- பழைய பதிப்பை இப்போது நிறுத்தலாம்.
பயன்பாட்டின் வெவ்வேறு பதிப்புகளை தனித்தனி கொள்கலன்களில் பயன்படுத்துவதற்கான இந்த அணுகுமுறை மற்றொரு வசதியை வழங்குகிறது - விரைவான திரும்புதல் பழைய பதிப்பிற்கு (எல்லாவற்றிற்கும் மேலாக, விரும்பிய கொள்கலனுக்கு போக்குவரத்தை மாற்றினால் போதும்).
இறுதி முதல் பரிந்துரை கேப்டனால் கூட தவறு கண்டுபிடிக்க முடியாதது போல் தெரிகிறது: "[டோக்கருடன் தொடர்ச்சியான டெலிவரியை ஏற்பாடு செய்யும் போது] டோக்கரைப் பயன்படுத்தவும் [மேலும் அது என்ன தருகிறது என்பதைப் புரிந்து கொள்ளுங்கள்]" நினைவில் கொள்ளுங்கள், இது ஒவ்வொரு சிக்கலையும் தீர்க்கும் ஒரு வெள்ளி புல்லட் அல்ல, ஆனால் ஒரு அற்புதமான அடித்தளத்தை வழங்கும் ஒரு கருவி.
மறுஉருவாக்கம்
"உருவாக்கம்" என்பதன் மூலம், பயன்பாடுகளை இயக்கும்போது ஏற்படும் பொதுவான சிக்கல்களின் தொகுப்பைக் குறிக்கிறோம். இதுபோன்ற வழக்குகளைப் பற்றி நாங்கள் பேசுகிறோம்:
- ஸ்டேஜிங்கிற்காக தரத் துறையால் சரிபார்க்கப்பட்ட ஸ்கிரிப்ட்கள் தயாரிப்பில் துல்லியமாக மீண்டும் உருவாக்கப்பட வேண்டும்.
- வெவ்வேறு களஞ்சிய கண்ணாடிகளிலிருந்து தொகுப்புகளைப் பெறக்கூடிய சேவையகங்களில் பயன்பாடுகள் வெளியிடப்படுகின்றன (காலப்போக்கில் அவை புதுப்பிக்கப்படும், மேலும் அவற்றுடன் நிறுவப்பட்ட பயன்பாடுகளின் பதிப்புகள்).
- "எல்லாம் உள்ளூரில் எனக்கு வேலை செய்கிறது!" (...மேலும் டெவலப்பர்கள் உற்பத்திக்கு அனுமதிக்கப்படுவதில்லை.)
- பழைய (காப்பகப்படுத்தப்பட்ட) பதிப்பில் ஏதாவது ஒன்றை நீங்கள் சரிபார்க்க வேண்டும்.
- ...
பயன்படுத்தப்படும் சூழல்களின் முழு இணக்கம் (அத்துடன் மனித காரணி இல்லாதது) அவசியம் என்பதற்கு அவற்றின் பொதுவான சாராம்சம் கொதிக்கிறது. மறுஉற்பத்திக்கு எப்படி உத்தரவாதம் அளிக்க முடியும்? டோக்கர் படங்களை உருவாக்கவும் Git இலிருந்து குறியீட்டை அடிப்படையாகக் கொண்டு, எந்தப் பணிக்கும் அவற்றைப் பயன்படுத்தவும்: சோதனைத் தளங்களில், உற்பத்தியில், புரோகிராமர்களின் உள்ளூர் இயந்திரங்களில்... அதே நேரத்தில், செய்யப்படும் செயல்களைக் குறைப்பது முக்கியம். после படத்தை அசெம்பிள் செய்தல்: எளிமையானது, பிழைகள் குறைவாக இருக்கும்.
உள்கட்டமைப்பு என்பது குறியீடு
உள்கட்டமைப்புத் தேவைகள் (சேவையக மென்பொருளின் கிடைக்கும் தன்மை, அதன் பதிப்பு போன்றவை) முறைப்படுத்தப்படாமலும், "திட்டமிடப்படாமலும்" இருந்தால், எந்தவொரு அப்ளிகேஷன் புதுப்பித்தலின் வெளியீடும் பேரழிவு தரும் விளைவுகளை ஏற்படுத்தலாம். எடுத்துக்காட்டாக, ஸ்டேஜிங்கில் நீங்கள் ஏற்கனவே PHP 7.0 க்கு மாறி, அதற்கேற்ப குறியீட்டை மீண்டும் எழுதியுள்ளீர்கள் - பின்னர் சில பழைய PHP (5.5) உடன் தயாரிப்பில் அதன் தோற்றம் நிச்சயமாக ஒருவரை ஆச்சரியப்படுத்தும். மொழிபெயர்ப்பாளர் பதிப்பில் ஒரு பெரிய மாற்றத்தை நீங்கள் மறந்துவிடக் கூடாது, ஆனால் "பிசாசு விவரங்களில் இருக்கிறார்": ஆச்சரியம் எந்த சார்புநிலையிலும் சிறிய புதுப்பிப்பில் இருக்கலாம்.
இந்த சிக்கலை தீர்க்க ஒரு அணுகுமுறை அறியப்படுகிறது IaC (உள்கட்டமைப்பு என்பது குறியீடாக, "உள்கட்டமைப்பு என்பது குறியீடாக") மற்றும் பயன்பாட்டுக் குறியீட்டுடன் உள்கட்டமைப்பு தேவைகளை சேமிப்பதை உள்ளடக்கியது. இதைப் பயன்படுத்தி, டெவலப்பர்கள் மற்றும் DevOps நிபுணர்கள் ஒரே Git பயன்பாட்டுக் களஞ்சியத்துடன் வேலை செய்யலாம், ஆனால் அதன் வெவ்வேறு பகுதிகளில். இந்த குறியீட்டிலிருந்து, Git இல் ஒரு டோக்கர் படம் உருவாக்கப்படுகிறது, இதில் உள்கட்டமைப்பின் அனைத்து பிரத்தியேகங்களையும் கணக்கில் எடுத்துக்கொண்டு பயன்பாடு பயன்படுத்தப்படுகிறது. எளிமையாகச் சொன்னால், படங்களைச் சேர்ப்பதற்கான ஸ்கிரிப்ட்கள் (விதிகள்) மூலக் குறியீட்டுடன் ஒரே களஞ்சியத்தில் இருக்க வேண்டும் மற்றும் ஒன்றாக இணைக்கப்பட வேண்டும்.
மல்டி-லேயர் அப்ளிகேஷன் ஆர்கிடெக்சரின் விஷயத்தில் - எடுத்துக்காட்டாக, டாக்கர் கொள்கலனுக்குள் ஏற்கனவே இயங்கும் பயன்பாட்டின் முன் நிற்கும் nginx உள்ளது - ஒவ்வொரு லேயருக்கும் Git இல் உள்ள குறியீட்டிலிருந்து டோக்கர் படங்கள் உருவாக்கப்பட வேண்டும். பின்னர் முதல் படத்தில் ஒரு மொழிபெயர்ப்பாளர் மற்றும் பிற "நெருங்கிய" சார்புகள் கொண்ட ஒரு பயன்பாடு இருக்கும், மேலும் இரண்டாவது படத்தில் அப்ஸ்ட்ரீம் nginx இருக்கும்.
டோக்கர் படங்கள், Git உடனான தொடர்பு
Git இலிருந்து சேகரிக்கப்பட்ட அனைத்து Docker படங்களையும் இரண்டு வகைகளாகப் பிரிக்கிறோம்: தற்காலிக மற்றும் வெளியீடு. தற்காலிக படங்கள் Git இல் உள்ள கிளையின் பெயரால் குறிக்கப்பட்டது, அடுத்த கமிட் மூலம் மேலெழுதப்படலாம் மற்றும் முன்னோட்டத்திற்காக மட்டுமே (உற்பத்திக்காக அல்ல) வெளியிடப்படும். இது வெளியிடப்பட்டவற்றிலிருந்து அவர்களின் முக்கிய வேறுபாடு: அவற்றில் எந்த குறிப்பிட்ட உறுதிப்பாடு உள்ளது என்பது உங்களுக்குத் தெரியாது.
தற்காலிகப் படங்களாகச் சேகரிப்பது அர்த்தமுள்ளதாக இருக்கிறது: மாஸ்டர் கிளை (மாஸ்டரின் தற்போதைய பதிப்பைத் தொடர்ந்து பார்க்க நீங்கள் அதை ஒரு தனி தளத்திற்கு தானாக உருட்டலாம்), வெளியீடுகளைக் கொண்ட கிளைகள், குறிப்பிட்ட புதுமைகளின் கிளைகள்.
தற்காலிக படங்களின் முன்னோட்டம் தயாரிப்பில் மொழிபெயர்ப்பின் தேவைக்கு வந்த பிறகு, டெவலப்பர்கள் ஒரு குறிப்பிட்ட குறிச்சொல்லை வைக்கின்றனர். குறிச்சொல் மூலம் தானாக சேகரிக்கப்படும் படத்தை வெளியிடு (அதன் குறிச்சொல் Git இலிருந்து வரும் குறிச்சொல்லை ஒத்துள்ளது) மற்றும் ஸ்டேஜிங்கிற்கு உருட்டப்பட்டது. தரமான துறையால் வெற்றிகரமாக சரிபார்க்கப்பட்டால், அது உற்பத்திக்கு செல்கிறது.
dapp
விவரிக்கப்பட்ட அனைத்தும் (ரோல்அவுட், பட அசெம்பிளி, அடுத்தடுத்த பராமரிப்பு) பாஷ் ஸ்கிரிப்டுகள் மற்றும் பிற "மேம்படுத்தப்பட்ட" கருவிகளைப் பயன்படுத்தி சுயாதீனமாக செயல்படுத்தப்படலாம். ஆனால் நீங்கள் இதைச் செய்தால், ஒரு கட்டத்தில் செயல்படுத்துவது பெரும் சிக்கலான மற்றும் மோசமான கட்டுப்பாட்டுக்கு வழிவகுக்கும். இதைப் புரிந்துகொண்டு, CI/CD-யை உருவாக்க எங்களின் சொந்த சிறப்புப் பணிப்பாய்வு பயன்பாட்டை உருவாக்கினோம் - dapp.
அதன் மூலக் குறியீடு ரூபி, ஓப்பன் சோர்ஸில் எழுதப்பட்டு அன்று வெளியிடப்பட்டது . துரதிர்ஷ்டவசமாக, ஆவணப்படுத்தல் தற்போது கருவியின் பலவீனமான புள்ளியாகும், ஆனால் நாங்கள் அதைச் செய்து வருகிறோம். மேலும் டாப்பைப் பற்றி ஒன்றுக்கு மேற்பட்ட முறை எழுதுவோம், பேசுவோம், ஏனென்றால்... முழு ஆர்வமுள்ள சமூகத்துடனும் அதன் திறன்களைப் பகிர்ந்து கொள்ள நாங்கள் உண்மையாக காத்திருக்க முடியாது, ஆனால் இதற்கிடையில், உங்கள் சிக்கல்களை அனுப்பவும் மற்றும் கோரிக்கைகளை இழுக்கவும் மற்றும்/அல்லது GitHub இல் திட்டத்தின் வளர்ச்சியைப் பின்பற்றவும்.
ஆகஸ்ட் 13, 2019 அன்று புதுப்பிக்கப்பட்டது: தற்போது ஒரு திட்டம் dapp என மறுபெயரிடப்பட்டது , அதன் குறியீடு Go இல் முழுமையாக மீண்டும் எழுதப்பட்டது, மேலும் அதன் ஆவணங்கள் கணிசமாக மேம்படுத்தப்பட்டுள்ளன.
Kubernetes
தொழில்முறை சூழலில் ஏற்கனவே குறிப்பிடத்தக்க அங்கீகாரத்தைப் பெற்ற மற்றொரு ஆயத்த திறந்த மூலக் கருவி Kubernetes,ஒரு டோக்கர் மேலாண்மை கிளஸ்டர். டோக்கரில் கட்டமைக்கப்பட்ட திட்டங்களின் செயல்பாட்டில் அதன் பயன்பாட்டின் தலைப்பு அறிக்கையின் எல்லைக்கு அப்பாற்பட்டது, எனவே விளக்கக்காட்சி சில சுவாரஸ்யமான அம்சங்களின் மேலோட்டமாக வரையறுக்கப்பட்டுள்ளது.
வெளியீட்டிற்கு, Kubernetes வழங்குகிறது:
- தயார்நிலை ஆய்வு - பயன்பாட்டின் புதிய பதிப்பின் தயார்நிலையை சரிபார்க்கிறது (அதற்கு போக்குவரத்தை மாற்ற);
- உருட்டல் புதுப்பிப்பு - கொள்கலன்களின் தொகுப்பில் தொடர்ச்சியான பட புதுப்பிப்பு (நிறுத்தம், புதுப்பித்தல், துவக்கத்திற்கான தயாரிப்பு, போக்குவரத்து மாறுதல்);
- ஒத்திசைவான புதுப்பிப்பு - வேறுபட்ட அணுகுமுறையுடன் ஒரு கிளஸ்டரில் ஒரு படத்தை புதுப்பித்தல்: முதலில் பாதி கொள்கலன்களில், பின்னர் மீதமுள்ளவை;
- கேனரி வெளியீடுகள் - முரண்பாடுகளைக் கண்காணிக்க வரையறுக்கப்பட்ட (சிறிய) கொள்கலன்களில் புதிய படத்தைத் தொடங்குதல்.
தொடர்ச்சியான டெலிவரி என்பது புதிய பதிப்பின் வெளியீடு மட்டுமல்ல, குபெர்னெட்டஸுக்கு அடுத்தடுத்த உள்கட்டமைப்பு பராமரிப்புக்கான பல திறன்கள் உள்ளன: உள்ளமைக்கப்பட்ட கண்காணிப்பு மற்றும் அனைத்து கொள்கலன்களுக்கும் பதிவு செய்தல், தானியங்கி அளவிடுதல் போன்றவை. இவை அனைத்தும் ஏற்கனவே வேலை செய்து, சரியானதாக காத்திருக்கிறது. உங்கள் செயல்முறைகளில் செயல்படுத்துதல்.
இறுதி பரிந்துரைகள்
- டோக்கரைப் பயன்படுத்தவும்.
- உங்கள் எல்லா தேவைகளுக்கும் பயன்பாடுகளின் டோக்கர் படங்களை உருவாக்கவும்.
- "உள்கட்டமைப்பு என்பது குறியீடு" என்ற கொள்கையைப் பின்பற்றவும்.
- ஜிட்டை டோக்கருடன் இணைக்கவும்.
- வெளியீட்டின் வரிசையை ஒழுங்குபடுத்துங்கள்.
- ஆயத்த தளத்தைப் பயன்படுத்தவும் (குபெர்னெட்ஸ் அல்லது வேறு).
வீடியோக்கள் மற்றும் ஸ்லைடுகள்
செயல்திறன் வீடியோ (சுமார் ஒரு மணி நேரம்) (அறிக்கை 5 வது நிமிடத்திலிருந்து தொடங்குகிறது - இந்த தருணத்திலிருந்து விளையாட இணைப்பைப் பின்தொடரவும்).
அறிக்கையின் விளக்கக்காட்சி:
சோசலிஸ்ட் கட்சி
எங்கள் வலைப்பதிவில் தலைப்பில் மற்ற அறிக்கைகள்:
- «» (Dmitry Stolyarov; மே 27, 2019 DevOpsConf இல்);
- «» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 8, 2018 ஹைலோட்++ இல்);
- «» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 7, 2017 ஹைலோட்++ இல்);
- «» (Dmitry Stolyarov; ஜூன் 6, 2017 RootConf இல்).
ஆதாரம்: www.habr.com