வாடிக்கையாளரின் தளத்தில் தொடர்ச்சியான வரிசைப்படுத்தலை நாங்கள் செயல்படுத்துகிறோம்

ட்ரூ இன்ஜினியரிங்கில் நாங்கள் வாடிக்கையாளர் சேவையகங்களுக்கு புதுப்பிப்புகளைத் தொடர்ந்து வழங்குவதற்கான செயல்முறையை அமைத்துள்ளோம், மேலும் இந்த அனுபவத்தைப் பகிர்ந்து கொள்ள விரும்புகிறோம்.

தொடங்குவதற்கு, நாங்கள் வாடிக்கையாளருக்கான ஆன்லைன் அமைப்பை உருவாக்கி அதை எங்கள் சொந்த குபெர்னெட்ஸ் கிளஸ்டரில் பயன்படுத்தினோம். இப்போது எங்கள் உயர்-சுமை தீர்வு வாடிக்கையாளரின் தளத்திற்கு நகர்ந்துள்ளது, அதற்காக நாங்கள் முழு தானியங்கி தொடர்ச்சியான வரிசைப்படுத்தல் செயல்முறையை அமைத்துள்ளோம். இதற்கு நன்றி, நாங்கள் சந்தைக்கு நேரத்தை விரைவுபடுத்தினோம் - தயாரிப்பு சூழலுக்கு மாற்றங்களை வழங்குதல்.

இந்த கட்டுரையில், தொடர்ச்சியான வரிசைப்படுத்தல் (சிடி) செயல்முறையின் அனைத்து நிலைகளையும் அல்லது வாடிக்கையாளர் தளத்திற்கு புதுப்பிப்புகளை வழங்குவதையும் பற்றி பேசுவோம்:

1. இந்த செயல்முறை எவ்வாறு தொடங்குகிறது?
2. வாடிக்கையாளரின் Git களஞ்சியத்துடன் ஒத்திசைவு,
3. பின்தளம் மற்றும் முன்பகுதியின் அசெம்பிளி,
4. சோதனைச் சூழலில் தானியங்கி பயன்பாட்டு வரிசைப்படுத்தல்,
5. தயாரிப்புக்கு தானியங்கி வரிசைப்படுத்தல்.

அமைவு விவரங்களைப் பகிர்ந்து கொள்வோம்.

1. சிடியைத் தொடங்கவும்

டெவலப்பர் எங்கள் Git களஞ்சியத்தின் வெளியீட்டு கிளையில் மாற்றங்களைத் தள்ளுவதன் மூலம் தொடர்ச்சியான வரிசைப்படுத்தல் தொடங்குகிறது.

எங்கள் பயன்பாடு மைக்ரோ சர்வீஸ் கட்டமைப்பில் இயங்குகிறது மற்றும் அதன் அனைத்து கூறுகளும் ஒரு களஞ்சியத்தில் சேமிக்கப்படும். இதற்கு நன்றி, அனைத்து மைக்ரோ சர்வீஸ்களும் சேகரிக்கப்பட்டு நிறுவப்பட்டுள்ளன, அவற்றில் ஒன்று மாறினாலும் கூட.

பல காரணங்களுக்காக ஒரு களஞ்சியத்தின் மூலம் பணியை ஏற்பாடு செய்தோம்:

• வளர்ச்சியின் எளிமை - பயன்பாடு தீவிரமாக வளர்ந்து வருகிறது, எனவே நீங்கள் அனைத்து குறியீடுகளுடனும் ஒரே நேரத்தில் வேலை செய்யலாம்.
• ஒரு சிஐ/சிடி பைப்லைன், ஒரே அமைப்பாகப் பயன்பாடு அனைத்து சோதனைகளிலும் தேர்ச்சி பெற்று வாடிக்கையாளரின் உற்பத்திச் சூழலுக்கு வழங்கப்படுகிறது.
• பதிப்புகளில் உள்ள குழப்பத்தை நாங்கள் நீக்குகிறோம் - மைக்ரோ சர்வீஸ் பதிப்புகளின் வரைபடத்தைச் சேமித்து, ஹெல்ம் ஸ்கிரிப்ட்களில் ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும் அதன் உள்ளமைவை விவரிக்க வேண்டியதில்லை.

2. வாடிக்கையாளரின் மூலக் குறியீட்டின் Git களஞ்சியத்துடன் ஒத்திசைவு

செய்யப்பட்ட மாற்றங்கள் வாடிக்கையாளரின் Git களஞ்சியத்துடன் தானாகவே ஒத்திசைக்கப்படும். அங்கு அப்ளிகேஷன் அசெம்பிளி கட்டமைக்கப்படுகிறது, இது கிளையைப் புதுப்பித்த பிறகு தொடங்கப்பட்டு, தொடர்ச்சிக்கு வரிசைப்படுத்தப்படுகிறது. இரண்டு செயல்முறைகளும் அவற்றின் சூழலில் ஒரு Git களஞ்சியத்திலிருந்து உருவாகின்றன.

வாடிக்கையாளரின் களஞ்சியத்துடன் நேரடியாக வேலை செய்ய முடியாது, ஏனெனில் மேம்பாடு மற்றும் சோதனைக்கு எங்கள் சொந்த சூழல்கள் தேவை. இந்த நோக்கங்களுக்காக நாங்கள் எங்கள் Git களஞ்சியத்தைப் பயன்படுத்துகிறோம் - இது அவர்களின் Git களஞ்சியத்துடன் ஒத்திசைக்கப்பட்டுள்ளது. ஒரு டெவலப்பர் எங்கள் களஞ்சியத்தின் பொருத்தமான கிளைக்கு மாற்றங்களை இடுகையிட்டவுடன், GitLab உடனடியாக இந்த மாற்றங்களை வாடிக்கையாளரிடம் தள்ளும்.

இதற்குப் பிறகு நீங்கள் சட்டசபை செய்ய வேண்டும். இது பல நிலைகளைக் கொண்டுள்ளது: பின்தளம் மற்றும் முன்பக்க அசெம்பிளி, சோதனை மற்றும் உற்பத்திக்கு வழங்குதல்.

3. பின்தளம் மற்றும் முன்பகுதியை அசெம்பிள் செய்தல்

பின்தளம் மற்றும் முன்பகுதியை உருவாக்குதல் என்பது GitLab ரன்னர் அமைப்பில் செய்யப்படும் இரண்டு இணையான பணிகளாகும். அதன் அசல் சட்டசபை கட்டமைப்பு அதே களஞ்சியத்தில் அமைந்துள்ளது.

GitLab இல் உருவாக்குவதற்கான YAML ஸ்கிரிப்டை எழுதுவதற்கான பயிற்சி.

GitLab Runner தேவையான களஞ்சியத்திலிருந்து குறியீட்டை எடுத்து, Java பயன்பாட்டு உருவாக்க கட்டளையுடன் அதை ஒருங்கிணைத்து அதை Docker பதிவேட்டில் அனுப்புகிறது. இங்கே நாம் பின்தளம் மற்றும் முன்பகுதியை ஒருங்கிணைத்து, டோக்கர் படங்களைப் பெறுகிறோம், அதை வாடிக்கையாளரின் பக்கத்தில் ஒரு களஞ்சியத்தில் வைக்கிறோம். டோக்கர் படங்களை நிர்வகிக்க நாங்கள் பயன்படுத்துகிறோம் கிரேடில் சொருகி.

டோக்கரில் வெளியிடப்படும் வெளியீட்டுப் பதிப்போடு எங்கள் படங்களின் பதிப்புகளை ஒத்திசைக்கிறோம். சீரான செயல்பாட்டிற்காக, நாங்கள் பல மாற்றங்களைச் செய்துள்ளோம்:

1. சோதனைச் சூழலுக்கும் உற்பத்திச் சூழலுக்கும் இடையே கொள்கலன்கள் மீண்டும் கட்டப்படுவதில்லை. சோதனைச் சூழலிலும் உற்பத்தியிலும் அனைத்து அமைப்புகள், சூழல் மாறிகள் மற்றும் சேவைகளுடன் ஒரே கொள்கலன் வேலை செய்யும் வகையில் அளவுருக்களை உருவாக்கினோம்.

2. ஹெல்ம் மூலம் பயன்பாட்டைப் புதுப்பிக்க, அதன் பதிப்பை நீங்கள் குறிப்பிட வேண்டும். நாங்கள் பேக்கெண்ட், ஃபிரண்ட்எண்ட் மற்றும் அப்ளிகேஷனைப் புதுப்பிக்கிறோம் - இவை மூன்று வெவ்வேறு பணிகள், எனவே பயன்பாட்டின் ஒரே பதிப்பை எல்லா இடங்களிலும் பயன்படுத்துவது முக்கியம். இந்த பணிக்கு, எங்கள் K8S கிளஸ்டர் உள்ளமைவு மற்றும் பயன்பாடுகள் ஒரே Git களஞ்சியத்தில் இருப்பதால், Git வரலாற்றிலிருந்து தரவைப் பயன்படுத்துகிறோம்.

கட்டளை செயல்படுத்தல் முடிவுகளிலிருந்து பயன்பாட்டு பதிப்பைப் பெறுகிறோம்
git describe --tags --abbrev=7.

4. சோதனை சூழலில் (UAT) அனைத்து மாற்றங்களையும் தானாக வரிசைப்படுத்துதல்

இந்த உருவாக்க ஸ்கிரிப்ட்டின் அடுத்த படி K8S கிளஸ்டரை தானாக புதுப்பிக்க வேண்டும். முழு பயன்பாடும் கட்டமைக்கப்பட்டு, அனைத்து கலைப்பொருட்களும் டோக்கர் பதிவேட்டில் வெளியிடப்பட்டிருந்தால் இது நிகழ்கிறது. இதற்குப் பிறகு, சோதனை சூழல் புதுப்பிப்பு தொடங்குகிறது.

கிளஸ்டர் புதுப்பிப்பு பயன்படுத்தத் தொடங்கியது ஹெல்ம் புதுப்பிப்பு. இதன் விளைவாக, ஏதாவது திட்டத்தின் படி நடக்கவில்லை என்றால், ஹெல்ம் தானாகவே மற்றும் சுயாதீனமாக அதன் அனைத்து மாற்றங்களையும் திரும்பப் பெறும். அவரது வேலையைக் கட்டுப்படுத்த வேண்டிய அவசியமில்லை.

கே8எஸ் கிளஸ்டர் உள்ளமைவை அசெம்பிளியுடன் சேர்த்து வழங்குகிறோம். எனவே, அடுத்த கட்டமாக அதை புதுப்பித்தல்: configMaps, deployments, Services, secrets மற்றும் நாங்கள் மாற்றிய வேறு K8S உள்ளமைவுகள்.

ஹெல்ம் சோதனைச் சூழலில் பயன்பாட்டின் ரோல்அவுட் புதுப்பிப்பை இயக்குகிறது. பயன்பாடு உற்பத்திக்கு பயன்படுத்தப்படுவதற்கு முன். சோதனைச் சூழலில் நாங்கள் வைத்திருக்கும் வணிக அம்சங்களைப் பயனர்கள் கைமுறையாகச் சோதிக்கும் வகையில் இது செய்யப்படுகிறது.

5. தயாரிப்புக்கான அனைத்து மாற்றங்களையும் தானாக வரிசைப்படுத்துதல்

உற்பத்தி சூழலுக்கு ஒரு புதுப்பிப்பை வரிசைப்படுத்த, நீங்கள் GitLab இல் ஒரு பொத்தானைக் கிளிக் செய்ய வேண்டும் - மேலும் கொள்கலன்கள் உடனடியாக உற்பத்தி சூழலுக்கு வழங்கப்படும்.

ஒரே பயன்பாடு வெவ்வேறு சூழல்களில்-சோதனை மற்றும் உற்பத்தி-புனரமைப்பு இல்லாமல் வேலை செய்ய முடியும். பயன்பாட்டில் எதையும் மாற்றாமல் அதே கலைப்பொருட்களைப் பயன்படுத்துகிறோம், மேலும் அளவுருக்களை வெளிப்புறமாக அமைக்கிறோம்.

பயன்பாட்டு அமைப்புகளின் நெகிழ்வான அளவுரு பயன்பாடு செயல்படுத்தப்படும் சூழலைப் பொறுத்தது. அனைத்து சூழல் அமைப்புகளையும் வெளிப்புறமாக நகர்த்தியுள்ளோம்: அனைத்தும் K8S உள்ளமைவு மற்றும் ஹெல்ம் அளவுருக்கள் மூலம் அளவுருவாக உள்ளது. ஹெல்ம் ஒரு அசெம்பிளியை சோதனைச் சூழலுக்குப் பயன்படுத்தும்போது, ​​சோதனை அமைப்புகள் அதற்குப் பயன்படுத்தப்படும், மேலும் தயாரிப்பு அமைப்புகள் உற்பத்திச் சூழலுக்குப் பயன்படுத்தப்படும்.

மிகவும் கடினமான விஷயம் என்னவென்றால், சுற்றுச்சூழலைச் சார்ந்து பயன்படுத்தப்பட்ட அனைத்து சேவைகள் மற்றும் மாறிகளை அளவுருவாக மாற்றுவது மற்றும் அவற்றை சூழல் மாறிகள் மற்றும் ஹெல்மிற்கான சுற்றுச்சூழல் அளவுருக்களின் விளக்கம்-கட்டமைவுகளாக மொழிபெயர்ப்பது.

பயன்பாட்டு அமைப்புகள் சூழல் மாறிகளைப் பயன்படுத்துகின்றன. கோ டெம்ப்ளேட்களைப் பயன்படுத்தி டெம்ப்ளேட் செய்யப்பட்ட K8S configmap ஐப் பயன்படுத்தி அவற்றின் மதிப்புகள் கொள்கலன்களில் அமைக்கப்பட்டுள்ளன. எடுத்துக்காட்டாக, டொமைன் பெயருக்கு சூழல் மாறியை அமைப்பது பின்வருமாறு:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - இந்த மாறி சுற்றுச்சூழலின் பெயரை (தயாரிப்பு, நிலை, UAT) சேமிக்கிறது.
.Values.app.properties.app_external_domain – இந்த மாறியில் நாம் விரும்பிய டொமைனை .Values.yaml கோப்பில் அமைக்கிறோம்

பயன்பாட்டைப் புதுப்பிக்கும்போது, ​​ஹெல்ம் வார்ப்புருக்களிலிருந்து configmap.yaml கோப்பை உருவாக்கி, பயன்பாட்டுப் புதுப்பிப்பு தொடங்கும் சூழலைப் பொறுத்து APP_EXTERNAL_DOMAIN மதிப்பை விரும்பிய மதிப்புடன் நிரப்புகிறது. இந்த மாறி ஏற்கனவே கொள்கலனில் அமைக்கப்பட்டுள்ளது. பயன்பாட்டிலிருந்து இதை அணுகலாம், எனவே ஒவ்வொரு பயன்பாட்டு சூழலும் இந்த மாறிக்கு வெவ்வேறு மதிப்பைக் கொண்டிருக்கும்.

ஒப்பீட்டளவில் சமீபத்தில், K8S ஆதரவு ஸ்பிரிங் கிளவுட்டில் தோன்றியது, இதில் configMaps உடன் பணிபுரிவது உட்பட: ஸ்பிரிங் கிளவுட் குபெர்னெட்ஸ். திட்டம் தீவிரமாக வளரும் மற்றும் தீவிரமாக மாறும் போது, ​​நாம் அதை உற்பத்தியில் பயன்படுத்த முடியாது. ஆனால் நாங்கள் அதன் நிலையை தீவிரமாக கண்காணித்து DEV உள்ளமைவுகளில் பயன்படுத்துகிறோம். அது நிலைப்படுத்தப்பட்டவுடன், சூழல் மாறிகளைப் பயன்படுத்துவதிலிருந்து அதற்கு மாறுவோம்.

மொத்தம்

எனவே, தொடர்ச்சியான வரிசைப்படுத்தல் கட்டமைக்கப்பட்டு வேலை செய்கிறது. அனைத்து புதுப்பிப்புகளும் ஒரு விசை அழுத்தத்துடன் நிகழ்கின்றன. தயாரிப்பு சூழலில் மாற்றங்களை வழங்குவது தானாகவே உள்ளது. மற்றும், முக்கியமாக, புதுப்பிப்புகள் கணினியை நிறுத்தாது.

எதிர்காலத் திட்டங்கள்: தானியங்கி தரவுத்தள இடம்பெயர்வு

தரவுத்தளத்தை மேம்படுத்துவது மற்றும் இந்த மாற்றங்களை திரும்பப் பெறுவதற்கான சாத்தியக்கூறுகள் குறித்து நாங்கள் யோசித்தோம். எல்லாவற்றிற்கும் மேலாக, பயன்பாட்டின் இரண்டு வெவ்வேறு பதிப்புகள் ஒரே நேரத்தில் இயங்குகின்றன: பழையது இயங்குகிறது, புதியது இயங்குகிறது. மேலும் புதிய பதிப்பு செயல்படும் என்று உறுதியாக இருந்தால் மட்டுமே பழையதை அணைப்போம். தரவுத்தள இடம்பெயர்வு பயன்பாட்டின் இரண்டு பதிப்புகளிலும் வேலை செய்ய உங்களை அனுமதிக்கும்.

எனவே, நெடுவரிசையின் பெயரையோ அல்லது பிற தரவையோ மாற்ற முடியாது. ஆனால் நாம் ஒரு புதிய நெடுவரிசையை உருவாக்கலாம், பழைய நெடுவரிசையிலிருந்து தரவை நகலெடுத்து, தரவைப் புதுப்பிக்கும்போது, ​​ஒரே நேரத்தில் மற்றொரு நெடுவரிசையில் நகலெடுத்து புதுப்பிக்கும் தூண்டுதல்களை எழுதலாம். பயன்பாட்டின் புதிய பதிப்பின் வெற்றிகரமான வரிசைப்படுத்தலுக்குப் பிறகு, வெளியீட்டு ஆதரவு காலத்திற்குப் பிறகு, பழைய நெடுவரிசையையும் தேவையற்ற தூண்டுதலையும் நீக்க முடியும்.

பயன்பாட்டின் புதிய பதிப்பு சரியாக வேலை செய்யவில்லை என்றால், தரவுத்தளத்தின் முந்தைய பதிப்பு உட்பட முந்தைய பதிப்பிற்கு நாம் திரும்பலாம். சுருக்கமாக, எங்கள் மாற்றங்கள் பயன்பாட்டின் பல பதிப்புகளுடன் ஒரே நேரத்தில் வேலை செய்ய உங்களை அனுமதிக்கும்.

கே8எஸ் ஜாப் வழியாக தரவுத்தள இடம்பெயர்வை தானியக்கமாக்க திட்டமிட்டுள்ளோம், அதை சிடி செயல்பாட்டில் ஒருங்கிணைக்கிறோம். இந்த அனுபவத்தை நாங்கள் நிச்சயமாக ஹப்ரேயில் பகிர்ந்து கொள்வோம்.

ஆதாரம்: www.habr.com