தொடர்ச்சியான ஒருங்கிணைப்பிற்காக டோக்கரில் மைக்ரோ சர்வீஸின் தானியங்கு சோதனை

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

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

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

இந்த அணுகுமுறையின் ஆட்டோமேஷன் பல சிக்கல்களை முன்வைக்கிறது, அதற்கான தீர்வு கீழே விவரிக்கப்படும்:

• அதே டாக்கர் ஹோஸ்டில் இணையான பணிகளின் முரண்பாடுகள்;
• சோதனை மறு செய்கைகளின் போது தரவுத்தளத்தில் அடையாளங்காட்டி முரண்பாடுகள்;
• மைக்ரோ சர்வீஸ்கள் தயாராக இருக்கும் வரை காத்திருக்கிறது;
• வெளிப்புற அமைப்புகளுக்கு பதிவுகளை ஒன்றிணைத்தல் மற்றும் வெளியிடுதல்;
• வெளிச்செல்லும் HTTP கோரிக்கைகளை சோதித்தல்;
• வலை சாக்கெட் சோதனை (SignalR ஐப் பயன்படுத்தி);
• OAuth அங்கீகாரம் மற்றும் அங்கீகாரத்தை சோதிக்கிறது.

இந்த கட்டுரை அடிப்படையாக கொண்டது என் பேச்சு SECR 2019 இல். எனவே படிக்க மிகவும் சோம்பேறிகளுக்கு, பேச்சின் பதிவு இதோ.

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

ஒரே ஸ்கிரிப்ட் டெவலப்பர்களால் தங்களின் விண்டோஸ் டெஸ்க்டாப்களிலும் லினக்ஸின் கீழ் உள்ள கிட்லாப் சிஐ சர்வராலும் இயக்கப்படுகிறது.

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

பின்வரும் காரணங்களுக்காக சோதனை உள்ளூர் சர்வரில் இயங்க வேண்டும்:

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

கூடுதலாக, ஸ்டாண்டைப் பயன்படுத்துவது விரும்பத்தகாதது, ஏனெனில்:

• ஒரு நிலைப்பாட்டை அதில் இயங்கும் மோசமான குறியீட்டால் மட்டும் உடைக்க முடியாது, ஆனால் சரியான குறியீடு செயலாக்க முடியாத தரவுகளாலும் உடைக்கப்படலாம்;
• சோதனையின் போது செய்யப்பட்ட அனைத்து மாற்றங்களையும் திரும்பப் பெற எவ்வளவு கடினமாக முயற்சித்தாலும், ஏதோ தவறு ஏற்படலாம் (இல்லையெனில், ஏன் சோதனை?).

திட்டம் மற்றும் செயல்முறை அமைப்பு பற்றி

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

திட்டமானது நிலையான தொடர்ச்சியான ஒருங்கிணைப்பு செயல்முறையைப் பயன்படுத்துகிறது, இதில் மைக்ரோ சர்வீஸை ஒவ்வொரு உறுதிப்பாட்டிலும் சோதனை செய்வது அடங்கும். ஒரு பணியை ஒதுக்கிய பிறகு, டெவலப்பர் மைக்ரோ சர்வீஸில் மாற்றங்களைச் செய்து, அதை கைமுறையாகச் சோதித்து, கிடைக்கக்கூடிய அனைத்து தானியங்கு சோதனைகளையும் இயக்குகிறார். தேவைப்பட்டால், டெவலப்பர் சோதனைகளை மாற்றுகிறார். சிக்கல்கள் எதுவும் கண்டறியப்படவில்லை என்றால், இந்த சிக்கலின் கிளைக்கு ஒரு உறுதியளிக்கப்படுகிறது. ஒவ்வொரு உறுதிப்பாட்டிற்கும் பிறகு, சோதனைகள் தானாகவே சர்வரில் இயங்கும். ஒரு பொதுவான கிளையில் ஒன்றிணைந்து, அதில் தானியங்கி சோதனைகளைத் தொடங்குவது வெற்றிகரமான மதிப்பாய்வுக்குப் பிறகு நிகழ்கிறது. பகிரப்பட்ட கிளையின் சோதனைகள் தேர்ச்சி பெற்றால், Amazon Elastic Container Service (bench) இல் சோதனை சூழலில் சேவை தானாகவே புதுப்பிக்கப்படும். அனைத்து டெவலப்பர்கள் மற்றும் சோதனையாளர்களுக்கும் நிலைப்பாடு அவசியம், அதை உடைக்க அறிவுறுத்தப்படவில்லை. இந்தச் சூழலில் உள்ள சோதனையாளர்கள் கைமுறைச் சோதனைகளைச் செய்வதன் மூலம் பிழைத்திருத்தம் அல்லது புதிய அம்சத்தைச் சரிபார்க்கின்றனர்.

திட்ட கட்டமைப்பு

பயன்பாடு பத்துக்கும் மேற்பட்ட சேவைகளைக் கொண்டுள்ளது. அவற்றில் சில .NET Core மற்றும் சில NodeJ களில் எழுதப்பட்டுள்ளன. ஒவ்வொரு சேவையும் அமேசான் எலாஸ்டிக் கொள்கலன் சேவையில் டோக்கர் கொள்கலனில் இயங்குகிறது. ஒவ்வொன்றும் அதன் சொந்த Postgres தரவுத்தளத்தைக் கொண்டுள்ளது, மேலும் சிலவற்றில் Redis உள்ளது. பொதுவான தரவுத்தளங்கள் இல்லை. பல சேவைகளுக்கு ஒரே தரவு தேவைப்பட்டால், இந்தத் தரவு, அது மாறும்போது, ​​SNS (எளிய அறிவிப்பு சேவை) மற்றும் SQS (அமேசான் எளிய வரிசை சேவை) வழியாக இந்த ஒவ்வொரு சேவைக்கும் அனுப்பப்படும், மேலும் சேவைகள் அதை அவற்றின் சொந்த தரவுத்தளங்களில் சேமிக்கின்றன.

SQS மற்றும் SNS

SQS ஆனது HTTPS நெறிமுறையைப் பயன்படுத்தி செய்திகளை ஒரு வரிசையில் வைக்க மற்றும் வரிசையில் இருந்து செய்திகளைப் படிக்க உங்களை அனுமதிக்கிறது.

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

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

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

API நுழைவாயில்

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

நிகழ் நேர அறிவிப்புகள்

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

நன்கு அறியப்பட்ட சோதனை அணுகுமுறை

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

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

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

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

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

தீர்வுக்கு செல்லலாம்

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

சோதனை சூழலை அமைத்தல்

முதல் பணி ஒரு சோதனை சூழலை வரிசைப்படுத்துவதாகும். மைக்ரோ சர்வீஸை இயக்க தேவையான படிகள்:

• உள்ளூர் சூழலுக்கான சோதனையின் கீழ் சேவையை உள்ளமைக்கவும், சுற்றுச்சூழல் மாறிகளில் தரவுத்தளம் மற்றும் AWS உடன் இணைப்பதற்கான விவரங்களைக் குறிப்பிடவும்;
• Postgres ஐத் தொடங்கி Liquibase ஐ இயக்குவதன் மூலம் இடம்பெயர்வைச் செய்யவும்.
  தொடர்புடைய DBMS களில், தரவுத்தளத்தில் தரவை எழுதுவதற்கு முன், நீங்கள் ஒரு தரவுத் திட்டத்தை உருவாக்க வேண்டும், வேறுவிதமாகக் கூறினால், அட்டவணைகள். ஒரு பயன்பாட்டைப் புதுப்பிக்கும்போது, ​​புதிய பதிப்பால் பயன்படுத்தப்படும் படிவத்திற்கு அட்டவணைகள் கொண்டு வரப்பட வேண்டும், மேலும் தரவை இழக்காமல் இருக்க வேண்டும். இது இடம்பெயர்வு எனப்படும். தொடக்கத்தில் காலியான தரவுத்தளத்தில் அட்டவணைகளை உருவாக்குவது இடம்பெயர்வின் ஒரு சிறப்பு நிகழ்வு. பயன்பாட்டிலேயே இடம்பெயர்வு கட்டமைக்கப்படலாம். .NET மற்றும் NodeJS இரண்டும் இடம்பெயர்வு கட்டமைப்பைக் கொண்டுள்ளன. எங்கள் விஷயத்தில், பாதுகாப்பு காரணங்களுக்காக, தரவுத் திட்டத்தை மாற்றுவதற்கான உரிமையை மைக்ரோ சர்வீஸ்கள் இழக்கின்றன, மேலும் இடம்பெயர்வு Liquibase ஐப் பயன்படுத்தி செய்யப்படுகிறது.
• அமேசான் லோக்கல்ஸ்டாக்கைத் தொடங்கவும். இது வீட்டில் இயங்கும் AWS சேவைகளை செயல்படுத்துவதாகும். Docker Hub இல் LocalStackக்கான ஆயத்தப் படம் உள்ளது.
• LocalStack இல் தேவையான நிறுவனங்களை உருவாக்க ஸ்கிரிப்டை இயக்கவும். ஷெல் ஸ்கிரிப்ட்கள் AWS CLI ஐப் பயன்படுத்துகின்றன.

திட்டத்தில் சோதனைக்கு பயன்படுத்தப்படுகிறது போஸ்ட்மேன். இது முன்பு இருந்தது, ஆனால் இது கைமுறையாக தொடங்கப்பட்டது மற்றும் ஏற்கனவே ஸ்டாண்டில் பயன்படுத்தப்பட்ட ஒரு பயன்பாட்டை சோதித்தது. இந்த கருவி உங்களை தன்னிச்சையான HTTP(S) கோரிக்கைகளை செய்ய அனுமதிக்கிறது மற்றும் பதில்கள் எதிர்பார்ப்புகளுடன் பொருந்துமா என்பதை சரிபார்க்கவும். வினவல்கள் ஒரு தொகுப்பாக இணைக்கப்பட்டு, முழு தொகுப்பையும் இயக்க முடியும்.

தானியங்கி சோதனை எவ்வாறு செயல்படுகிறது?

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

டோக்கர் பல சிக்கல்களைத் தீர்க்கிறார்:

• ஹோஸ்ட் உள்ளமைவிலிருந்து சுதந்திரம்;
• சார்புகளை நிறுவுதல்: டோக்கர் ஹப்பில் இருந்து படங்களை டோக்கர் பதிவிறக்குகிறது;
• கணினியை அதன் அசல் நிலைக்குத் திருப்புதல்: கொள்கலன்களை அகற்றுவது.

டோக்கர்-இசையமைத்தல் கன்டெய்னர்களை இணையத்தில் இருந்து தனிமைப்படுத்தப்பட்ட மெய்நிகர் நெட்வொர்க்கில் இணைக்கிறது, இதில் கொள்கலன்கள் டொமைன் பெயர்களால் ஒன்றையொன்று கண்டுபிடிக்கின்றன.

சோதனையானது ஷெல் ஸ்கிரிப்ட் மூலம் கட்டுப்படுத்தப்படுகிறது. விண்டோஸில் சோதனையை இயக்க, நாங்கள் git-bash ஐப் பயன்படுத்துகிறோம். எனவே, விண்டோஸ் மற்றும் லினக்ஸ் இரண்டிற்கும் ஒரு ஸ்கிரிப்ட் போதுமானது. திட்டத்தில் உள்ள அனைத்து டெவலப்பர்களாலும் Git மற்றும் Docker நிறுவப்பட்டுள்ளது. விண்டோஸில் Git ஐ நிறுவும் போது, ​​git-bash நிறுவப்பட்டுள்ளது, எனவே அனைவருக்கும் அதுவும் உள்ளது.

ஸ்கிரிப்ட் பின்வரும் படிகளைச் செய்கிறது:

• டாக்கர் படங்களை உருவாக்குதல்

  docker-compose build

• தரவுத்தளத்தையும் லோக்கல்ஸ்டாக்கையும் துவக்குகிறது

  docker-compose up -d <контейнер>

• தரவுத்தள இடம்பெயர்வு மற்றும் LocalStack தயாரித்தல்

  docker-compose run <контейнер>

• சோதனையின் கீழ் சேவையைத் தொடங்குதல்

  docker-compose up -d <сервис>

• சோதனையை இயக்குதல் (நியூமன்)
• அனைத்து கொள்கலன்களையும் நிறுத்துதல்

  docker-compose down

• ஸ்லாக்கில் முடிவுகளை இடுகையிடுகிறது
  பச்சை செக்மார்க் அல்லது சிவப்பு குறுக்கு மற்றும் பதிவிற்கான இணைப்புடன் செய்திகள் செல்லும் அரட்டை எங்களிடம் உள்ளது.

பின்வரும் டோக்கர் படங்கள் இந்த படிகளில் ஈடுபட்டுள்ளன:

• சோதனை செய்யப்படும் சேவையானது தயாரிப்புக்கான அதே படம்தான். சூழல் மாறிகள் மூலம் சோதனைக்கான உள்ளமைவு.
• Postgres, Redis மற்றும் LocalStack ஆகியவற்றிற்கு, Docker Hub இலிருந்து தயாராக தயாரிக்கப்பட்ட படங்கள் பயன்படுத்தப்படுகின்றன. லிக்விபேஸ் மற்றும் நியூமேனுக்கான ஆயத்த படங்களும் உள்ளன. அவர்களின் எலும்புக்கூட்டில் எங்களுடையதை உருவாக்குகிறோம், எங்கள் கோப்புகளை அங்கே சேர்க்கிறோம்.
• LocalStack ஐத் தயாரிக்க, நீங்கள் ஒரு ஆயத்த AWS CLI படத்தைப் பயன்படுத்தி, அதன் அடிப்படையில் ஒரு ஸ்கிரிப்ட் கொண்ட படத்தை உருவாக்கவும்.

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

நீங்கள் சந்திக்கக்கூடிய சிக்கல்கள்

தயார்நிலைக்காக காத்திருக்கிறது

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

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

முடிவு: SQS மற்றும் SNS இரண்டிலிருந்தும் 200 பதிலுக்காக காத்திருக்கும் LocalStack வழங்கல் ஸ்கிரிப்டுகள்.

இணையான பணி முரண்பாடுகள்

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

முடிவு: COMPOSE_PROJECT_NAME மாறியை ஸ்கிரிப்ட் ஒரு தனிப்பட்ட மதிப்பாக அமைக்கிறது.

விண்டோஸ் அம்சங்கள்

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

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

git இவ்வாறு கட்டமைக்கப்படுகிறது:

git config core.autocrlf input

1. Git-bash நிலையான லினக்ஸ் கோப்புறைகளைப் பின்பற்றுகிறது மற்றும் exe கோப்பை (docker.exe உட்பட) அழைக்கும் போது, ​​முழுமையான லினக்ஸ் பாதைகளை விண்டோஸ் பாதைகளுடன் மாற்றுகிறது. இருப்பினும், உள்ளூர் இயந்திரத்தில் இல்லாத பாதைகளுக்கு (அல்லது கொள்கலனில் உள்ள பாதைகளுக்கு) இது அர்த்தமல்ல. இந்த நடத்தையை முடக்க முடியாது.

முடிவு: பாதையின் தொடக்கத்தில் கூடுதல் சாய்வைச் சேர்க்கவும்: /பின் என்பதற்குப் பதிலாக //பின். லினக்ஸ் அத்தகைய பாதைகளைப் புரிந்துகொள்கிறது; அதற்கு, பல சாய்வுகள் ஒன்று போலவே இருக்கும். ஆனால் git-bash அத்தகைய பாதைகளை அடையாளம் காணவில்லை மற்றும் அவற்றை மாற்ற முயற்சிப்பதில்லை.

பதிவு வெளியீடு

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

அசல் தீர்வு செய்ய இருந்தது docker- வரை எழுது கொடி இல்லை -d, ஆனால் ஷெல் திறன்களைப் பயன்படுத்தி, இந்த செயல்முறையை பின்னணிக்கு அனுப்பவும்:

docker-compose up <service> &

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

முடிவு:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

சோதனை மறு செய்கைகளின் போது அடையாளங்காட்டி முரண்பாடு

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

அதைத் தவிர்க்க, ஐடிகள் தனிப்பட்டதாக இருக்க வேண்டும் அல்லது சோதனையால் உருவாக்கப்பட்ட அனைத்துப் பொருட்களும் நீக்கப்பட வேண்டும். தேவைகள் காரணமாக சில பொருட்களை நீக்க முடியாது.

முடிவு: போஸ்ட்மேன் ஸ்கிரிப்ட்களைப் பயன்படுத்தி GUIDகளை உருவாக்கவும்.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

பின்னர் வினவலில் உள்ள குறியீட்டைப் பயன்படுத்தவும் {{myUUID}}, இது மாறியின் மதிப்புடன் மாற்றப்படும்.

LocalStack மூலம் ஒத்துழைப்பு

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

முடிவு: தபால்காரரிடமிருந்து லோக்கல்ஸ்டாக்கிற்கு கோரிக்கைகள்.

AWS சேவைகள் API ஆவணப்படுத்தப்பட்டுள்ளது, SDK இல்லாமல் வினவல்களைச் செய்ய அனுமதிக்கிறது.

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

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

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

சோதனையில் உள்ள மைக்ரோ சர்வீஸில் இருந்து வரும் HTTP கோரிக்கைகளை சோதிக்கிறது

சில சேவைகள் AWS தவிர வேறு ஏதாவது HTTP மூலம் வேலை செய்கின்றன, மேலும் சில AWS அம்சங்கள் LocalStack இல் செயல்படுத்தப்படவில்லை.

முடிவு: இந்த சந்தர்ப்பங்களில் இது உதவும் MockServer, இதில் தயாராக உள்ள படம் உள்ளது டோக்கர் மையம். எதிர்பார்க்கப்படும் கோரிக்கைகள் மற்றும் அவற்றுக்கான பதில்கள் HTTP கோரிக்கையால் கட்டமைக்கப்படுகின்றன. API ஆவணப்படுத்தப்பட்டுள்ளது, எனவே நாங்கள் போஸ்ட்மேனிடம் கோரிக்கைகளை வைக்கிறோம்.

OAuth அங்கீகாரம் மற்றும் அங்கீகாரத்தை சோதிக்கிறது

நாங்கள் OAuth மற்றும் பயன்படுத்துகிறோம் JSON வலை டோக்கன்கள் (JWT). சோதனைக்கு OAuth வழங்குநர் தேவை, அதை நாங்கள் உள்நாட்டில் இயக்க முடியும்.

சேவைக்கும் OAuth வழங்குநருக்கும் இடையேயான அனைத்து தொடர்புகளும் இரண்டு கோரிக்கைகளுக்கு வரும்: முதலில், உள்ளமைவு கோரப்பட்டது /. well-known/openid-configuration, பின்னர் பொது விசை (JWKS) அமைப்பிலிருந்து முகவரியில் கோரப்பட்டது. இவை அனைத்தும் நிலையான உள்ளடக்கம்.

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

சிக்னல்ஆர் சோதனையின் அம்சங்கள்

போஸ்ட்மேன் வெப்சாக்கெட்டுகளுடன் வேலை செய்வதில்லை. SignalR ஐ சோதிக்க ஒரு சிறப்பு கருவி உருவாக்கப்பட்டது.

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

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

பல வாடிக்கையாளர்களை இயக்க விருப்பத்தைப் பயன்படுத்தவும் --அளவு docker-compose கட்டளை வரியில்.

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

முடிவு: கொள்கலனில் உள்ள கிளையன்ட் பொறிமுறையைப் பயன்படுத்துகிறது சுகாதார சோதனைஹோஸ்டில் உள்ள ஸ்கிரிப்ட்டின் நிலையைப் பற்றி தெரிவிக்க. இணைப்பு நிறுவப்பட்டவுடன் கிளையன்ட் ஒரு குறிப்பிட்ட பாதையில் ஒரு கோப்பை உருவாக்குகிறார், /healthcheck என்று சொல்லுங்கள். டோக்கர் கோப்பில் உள்ள HealthCheck ஸ்கிரிப்ட் இதுபோல் தெரிகிறது:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

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

நியூமேன் முடித்த பிறகு, ஸ்கிரிப்ட் 0 குறியீட்டைக் கொண்டு கிளையண்டுடன் உள்ள அனைத்து கொள்கலன்களும் நிறுத்தப்பட்டதா என்பதைச் சரிபார்க்கிறது.

ஹாப்பின்ஸ் உள்ளது

மேலே விவரிக்கப்பட்ட சிரமங்களை நாங்கள் சமாளித்த பிறகு, எங்களிடம் நிலையான இயங்கும் சோதனைகள் இருந்தன. சோதனைகளில், ஒவ்வொரு சேவையும் தரவுத்தளம் மற்றும் Amazon LocalStack ஆகியவற்றுடன் தொடர்புகொண்டு, ஒரு யூனிட்டாக செயல்படுகிறது.

இந்தச் சோதனைகள், 30+ டெவலப்பர்கள் கொண்ட குழுவை, 10+ மைக்ரோ சர்வீஸ்களின் சிக்கலான தொடர்புடன் அடிக்கடி பயன்படுத்தப்படும் ஒரு பயன்பாட்டில் உள்ள பிழைகளிலிருந்து பாதுகாக்கிறது.

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