டோக்கர் மற்றும் கிட்லாப் CI உடன் மேம்பாடு மற்றும் சோதனை செயல்முறை

Inventos "Docker + Gitlab CI உடன் மேம்பாடு மற்றும் சோதனை செயல்முறை" இலிருந்து Alexander Sigachev இன் அறிக்கையின் டிரான்ஸ்கிரிப்டைப் படிக்க பரிந்துரைக்கிறேன்.

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

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

ஆர்வமுள்ளவர்கள், பூனையைப் பார்க்கவும்.

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

அறிக்கையின் தலைப்பு: டோக்கர் மற்றும் கிட்லாப் CI ஐப் பயன்படுத்தி மேம்பாட்டு செயல்முறை.

டோக்கரைப் பற்றிய எனது இரண்டாவது பேச்சு இது. முதல் அறிக்கையின் போது, ​​டெவலப்பர் மெஷின்களில் டெவலப்மென்ட்டில் மட்டுமே டோக்கரைப் பயன்படுத்தினோம். டோக்கரைப் பயன்படுத்திய ஊழியர்களின் எண்ணிக்கை சுமார் 2-3 பேர். மெல்ல மெல்ல, அனுபவம் கிடைத்து, சிறிது தூரம் நகர்ந்தோம். எங்களின் இணைப்பு முதல் அறிக்கை.

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

எங்கள் குறிக்கோள்: நம் கையில் கிடைக்கும் அனைத்தையும் ஆவணப்படுத்து.

நாம் என்ன பிரச்சினைகளை தீர்க்கிறோம்?

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

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

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

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

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

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

மற்றொரு சிக்கல் நூலகங்களின் வெவ்வேறு பதிப்புகள். ஒரு டெவலப்பர் வெவ்வேறு திட்டங்களில் பணிபுரிவது அடிக்கடி நிகழ்கிறது. ஒரு மரபு திட்டம் உள்ளது, இது ஐந்து ஆண்டுகளுக்கு முன்பு தொடங்கியது (2017 முதல் - ஆசிரியர் குறிப்பு). தொடக்கத்தில் நாங்கள் MySQL 5.5 உடன் தொடங்கினோம். MySQL இன் நவீன பதிப்புகளை செயல்படுத்த முயற்சிக்கும் நவீன திட்டங்களும் உள்ளன, எடுத்துக்காட்டாக 5.7 அல்லது அதற்கு மேற்பட்டவை (2017 இல் - ஆசிரியர் குறிப்பு)

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

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

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

JS இல் உருவாகும் ஒரு ஃபிரண்ட்எண்ட் டெவலப்பர், பின்தளத்தில் எந்த செல்வாக்கையும் கொண்டிருக்கவில்லை. பின்தள டெவலப்பர், எங்கள் விஷயத்தில், ரூபி ஆன் ரெயில்ஸை உருவாக்குகிறார் மற்றும் ஃப்ராண்டெண்டில் தலையிடாது. API ஐப் பயன்படுத்தி தொடர்பு செய்யப்படுகிறது.

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

கருவிகள். நாம் எதைப் பயன்படுத்துகிறோம்?

• டோக்கர் தானே. ஒரு Dockerfile ஒரு பயன்பாட்டின் சார்புகளை விவரிக்கிறது.
• Docker-compose என்பது எங்களின் பல Docker அப்ளிகேஷன்களை ஒன்றிணைக்கும் ஒரு தொகுப்பு ஆகும்.
• மூலக் குறியீட்டைச் சேமிக்க நாங்கள் GitLab ஐப் பயன்படுத்துகிறோம்.
• கணினி ஒருங்கிணைப்புக்கு GitLab-CI ஐப் பயன்படுத்துகிறோம்.

அறிக்கை இரண்டு பகுதிகளைக் கொண்டுள்ளது.

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

இரண்டாம் பகுதி GitLab உடன் எவ்வாறு தொடர்புகொள்வது, சோதனைகளை எவ்வாறு இயக்குவது மற்றும் எப்படி ஸ்டேஜிங்கிற்குச் செல்கிறோம் என்பதைப் பற்றி பேசும்.

டோக்கர் என்பது தேவையான கூறுகளை விவரிக்க (ஒரு அறிவிப்பு அணுகுமுறையைப் பயன்படுத்தி) அனுமதிக்கும் ஒரு தொழில்நுட்பமாகும். இது ஒரு உதாரணம் Dockerfile. ரூபி:2.3.0 இன் அதிகாரப்பூர்வ டோக்கர் படத்திலிருந்து நாங்கள் பெறுகிறோம் என்று இங்கே அறிவிக்கிறோம். இதில் ரூபி பதிப்பு 2.3 நிறுவப்பட்டுள்ளது. தேவையான சட்டசபை நூலகங்கள் மற்றும் NodeJS ஐ நிறுவுகிறோம். நாங்கள் ஒரு கோப்பகத்தை உருவாக்குகிறோம் என்று விவரிக்கிறோம் /app. பயன்பாட்டு கோப்பகத்தை வேலை செய்யும் கோப்பகமாக ஒதுக்குகிறோம். இந்த கோப்பகத்தில் தேவையான குறைந்தபட்ச Gemfile மற்றும் Gemfile.lock ஆகியவற்றை வைக்கிறோம். இந்த சார்பு படத்தை நிறுவும் திட்டங்களை நாங்கள் உருவாக்குகிறோம். கன்டெய்னர் வெளிப்புற போர்ட் 3000 இல் கேட்க தயாராக இருக்கும் என்று நாங்கள் குறிப்பிடுகிறோம். கடைசி கட்டளை எங்கள் பயன்பாட்டை நேரடியாக தொடங்கும் கட்டளையாகும். ப்ராஜெக்ட் ரன் கட்டளையை இயக்கினால், அப்ளிகேஷன் குறிப்பிட்ட கட்டளையை இயக்கி இயக்க முயற்சிக்கும்.

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

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

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

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

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

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

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

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

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

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

Frontend இல் நாம் JavaScipt மற்றும் NodeJS ஐப் பயன்படுத்துகிறோம்.

இப்போது ReacJS இல் எங்களின் கடைசி திட்டம் உள்ளது. டெவலப்பர் கொள்கலனில் உள்ள அனைத்தையும் தொடங்கினார் மற்றும் ஹாட்-ரீலோடைப் பயன்படுத்தி உருவாக்கினார்.

அடுத்து, JavaScipt ஐ இணைக்கும் பணி தொடங்கப்பட்டது மற்றும் நிலையான முறையில் கூடியிருந்த குறியீடு nginx வழியாக அனுப்பப்பட்டு, வளங்களைச் சேமிக்கிறது.

எங்கள் சமீபத்திய திட்டத்தின் வரைபடத்தை இங்கே வழங்கியுள்ளேன்.

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

இதற்கு நாம் என்ன செய்தோம்?

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

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

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

NodeJS இல் செயல்படுத்தப்படும் மற்றொரு கூறுகளுடன் புஷ் அறிவிப்புகள் தொடர்பு கொள்கின்றன.

வரிசைகள் கட்டப்பட்டு, அவற்றின் சொந்த பொறிமுறையின்படி அறிவிப்புகள் அனுப்பப்படுகின்றன.

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

அதே விஷயம் ஆனால் எண்ணிக்கையில். குறியீடு மறுபயன்பாடு இங்கே முக்கியமானது.

நூலகங்களின் வடிவத்தில் குறியீட்டை மீண்டும் பயன்படுத்துவதைப் பற்றி நாங்கள் முன்பு பேசியிருந்தால், இந்த எடுத்துக்காட்டில் புஷ் அறிவிப்புகளுக்கு பதிலளிக்கும் எங்கள் சேவை முழுமையான சேவையகமாக மீண்டும் பயன்படுத்தப்படுகிறது. இது API ஐ வழங்குகிறது. நமது புதிய வளர்ச்சி அதனுடன் தொடர்பு கொள்கிறது.

அந்த நேரத்தில் நாங்கள் NodeJS இன் பதிப்பு 4 ஐப் பயன்படுத்தினோம். இப்போது (2017 இல் - ஆசிரியர் குறிப்பு) எங்கள் சமீபத்திய மேம்பாடுகளில் NodeJS இன் பதிப்பு 7 ஐப் பயன்படுத்துகிறோம். நூலகங்களின் புதிய பதிப்புகளை உள்ளடக்கிய புதிய கூறுகளில் எந்தப் பிரச்சனையும் இல்லை.

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

நாம் API இணக்கத்தன்மையை பராமரிக்க முடிந்தால், முன்பு பயன்படுத்தப்பட்ட பிற திட்டங்களுடன் அதை மாற்ற முடியும்.

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

ஒரு புதிய திட்டத்தை உருவாக்கும் போது, ​​நாங்கள் ஒரு Dockerfile ஐ உருவாக்கி, தேவையான சுற்றுச்சூழல் அமைப்பை (Python, Ruby, NodeJS) விவரிக்கிறோம். docker-composeல், தேவையான சார்புநிலையை விவரிக்கிறது - தரவுத்தளம். தரவுகளை அங்கொன்றும் இங்கொன்றுமாகச் சேமிக்க, அத்தகைய பதிப்புகளின் தரவுத்தளம் தேவை என்பதை நாங்கள் விவரிக்கிறோம்.

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

nginx மற்றும் mysql உள்ளமைவைச் சேமிக்க, ஒரு Docker கோப்புறையைச் சேர்த்துள்ளோம், அதில் தேவையான கட்டமைப்புகளைச் சேமிக்கிறோம். ஒரு டெவலப்பர் தனது கணினியில் ஒரு களஞ்சியத்தின் ஜிட் குளோனை உருவாக்கும் போது, ​​அவர் ஏற்கனவே உள்ளூர் மேம்பாட்டிற்காக ஒரு திட்டம் தயாராக உள்ளது. எந்த போர்ட் அல்லது எந்த அமைப்புகளைப் பயன்படுத்துவது என்பது பற்றி எந்த கேள்வியும் இல்லை.

அடுத்து எங்களிடம் பல கூறுகள் உள்ளன: நிர்வாகம், தகவல்-ஏபிஐ, புஷ் அறிவிப்புகள்.

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

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

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

புஷ் அறிவிப்புகளுடன் ஒருங்கிணைக்க வேண்டிய அவசியம் இருந்தால், docker-compose.yaml மற்றும் docker-compose-push.yaml ஆகியவை தொடங்கப்படும்.

docker-compose.yaml மற்றும் docker-compose-push.yaml கோப்புறையில் இருப்பதால், ஒரு மெய்நிகர் நெட்வொர்க் தானாகவே உருவாக்கப்படும்.

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

இது nginxஐ இயக்கும் ஆயத்த டோக்கர் படம் மற்றும் டோக்கர் சாக்கெட்டைக் கேட்கும் பயன்பாடு. டைனமிக், கொள்கலன்கள் ஆன் மற்றும் ஆஃப் செய்யப்படுவதால், nginx config மீண்டும் உருவாக்கப்படுகிறது. மூன்றாம் நிலை டொமைன் பெயர்களைப் பயன்படுத்தி கூறுகளின் கையாளுதலை நாங்கள் விநியோகிக்கிறோம்.

அபிவிருத்தி சூழலுக்கு நாம் .dev டொமைனைப் பயன்படுத்துகிறோம் - api.informer.dev. டெவலப்பரின் உள்ளூர் கணினியில் .dev டொமைனுடன் கூடிய பயன்பாடுகள் கிடைக்கும்.

பின்னர் கட்டமைப்புகள் ஒவ்வொரு திட்டத்திற்கும் மாற்றப்படும் மற்றும் அனைத்து திட்டங்களும் ஒரே நேரத்தில் தொடங்கப்படும்.

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

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

இது nginx ஆக இருக்கலாம், இது நிர்வாக குழுவிற்கு JS ஐ வழங்குகிறது. இதை nginx ஆல் செய்ய முடியும், இது API ஐ வழங்குகிறது அல்லது நிலையான கோப்புகள், nginx ஆல் படங்களை ஏற்றும் வடிவத்தில் வழங்கப்படுகிறது.

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

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

எனது விண்ணப்பத்தை டாக்கரைஸ் செய்ய நான் என்ன உதாரணத்தைப் பார்க்க வேண்டும்? என் கருத்துப்படி, MySQLக்கான அதிகாரப்பூர்வ டாக்கர் படம் ஒரு நல்ல உதாரணம்.

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

Hub.docker.com பொதுவாக github.com க்கான இணைப்புகளைக் கொண்டிருக்கும், இதில் மூல தரவு நேரடியாக வழங்கப்படுகிறது, அதில் இருந்து நீங்களே ஒரு படத்தை உருவாக்கலாம்.

மேலும் இந்த களஞ்சியத்தில் ஒரு ஸ்கிரிப்ட் docker-endpoint.sh உள்ளது, இது பயன்பாட்டு துவக்கத்தின் ஆரம்ப துவக்கத்திற்கும் மேலும் செயலாக்கத்திற்கும் பொறுப்பாகும்.

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

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

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

Github.com இல் MySQL இன் குறிப்பிட்ட பதிப்பு எப்படி இருக்கும் என்பதற்கு இது ஒரு எடுத்துக்காட்டு. நீங்கள் Dockerfile ஐத் திறந்து, அங்கு நிறுவல் எவ்வாறு நடைபெறுகிறது என்பதைப் பார்க்கலாம்.

நுழைவுப் புள்ளிக்கு docker-endpoint.sh ஸ்கிரிப்ட் பொறுப்பு. ஆரம்ப துவக்கத்தின் போது, ​​சில தயாரிப்பு நடவடிக்கைகள் தேவை மற்றும் இந்த செயல்கள் அனைத்தும் துவக்க ஸ்கிரிப்ட்டில் சேர்க்கப்படும்.

இரண்டாம் பாகத்திற்கு செல்வோம்.

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

கிட்லாப் கூறுகளில் ஒன்று கிட்லாப் சிஐ ஆகும். குறியீடு விநியோக அமைப்பை ஒழுங்கமைக்க அல்லது தானியங்கு சோதனையை இயக்குவதற்குப் பயன்படுத்தப்படும் கட்டளைகளின் வரிசையை விவரிக்க இது உங்களை அனுமதிக்கிறது.

Gitlab CI 2 பற்றிய அறிக்கை https://goo.gl/uohKjI - ரூபி ரஷ்யா கிளப்பின் அறிக்கை மிகவும் விரிவானது மற்றும் உங்களுக்கு ஆர்வமாக இருக்கலாம்.

இப்போது Gitlab CI ஐ செயல்படுத்த என்ன தேவை என்று பார்ப்போம். Gitlab CI ஐத் தொடங்க, திட்டத்தின் மூலத்தில் .gitlab-ci.yml கோப்பை வைக்க வேண்டும்.

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

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

அடுத்து தரவுத்தளத்தை மாற்றுவதற்கும் சோதனைகளை இயக்குவதற்கும் இடம்பெயர்வுகளை இயக்குவது அவசியம் என்று கூறுகிறோம்.

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

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

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

தற்போதைய மாறி சூழலுக்கு டெவலப்பர்களால் எழுதப்பட்ட தரவுத்தள இடம்பெயர்வுகளை இயக்குவோம்.

இது மாஸ்டர் கிளைக்கு மட்டுமே பயன்படுத்தப்பட வேண்டும் என்று ஒரு குறிப்பு உள்ளது.

மற்ற கிளைகளை மாற்றும்போது வேலை செய்யாது.

கிளைகளுடன் ரோல்அவுட்களை ஒழுங்கமைக்க முடியும்.

இதை மேலும் ஒழுங்கமைக்க, நாம் Gitlab Runner ஐ நிறுவ வேண்டும்.

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

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

Gitlab இணைய இடைமுகத்தில் விசையைப் பெறுகிறோம்.

பின்னர் கட்டளை வரியில் துவக்க கட்டளையை அழைக்கிறோம்.

கிட்லாப் ரன்னரை உரையாடல் முறையில் உள்ளமைத்தல் (ஷெல், டோக்கர், விர்ச்சுவல்பாக்ஸ், எஸ்எஸ்எச்)

.gitlab-ci.yml அமைப்பைப் பொறுத்து Gitlab Runner இல் உள்ள குறியீடு ஒவ்வொரு உறுதிப்பாட்டிலும் செயல்படுத்தப்படும்.

இணைய இடைமுகத்தில் உள்ள Gitlab இல் இது எவ்வாறு காட்சியளிக்கிறது. ஜிட்லேப் சிஐயை இணைத்த பிறகு, பில்ட் தற்போது எந்த நிலையில் உள்ளது என்பதைக் காட்டும் கொடி எங்களிடம் உள்ளது.

4 நிமிடங்களுக்கு முன்பு அனைத்து சோதனைகளையும் கடந்து எந்த பிரச்சனையும் ஏற்படாத ஒரு உறுதிமொழி எடுக்கப்பட்டதை நாங்கள் காண்கிறோம்.

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

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

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

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

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

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

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

இவ்வாறு, இந்த கண்ணியுடன் தொடங்கும் ஒவ்வொரு கூறுகளும் கணினியின் மற்ற பகுதிகளில் உள்ள கூறுகளைப் பார்க்கின்றன.

அடுத்த சிக்கல் பல திட்டங்களுக்கு இடையில் ஸ்டேஜிங்கைப் பிரிப்பதாகும்.

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

இதை எப்படி தீர்த்தோம்? அனைத்து பெரிய திட்டங்களுக்கும் ஒரு கிட்லாப் ரன்னரை நாங்கள் நியமித்துள்ளோம்.

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

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

நாங்கள் nginx-proxy ஐ ஒரு தனி வெளியீட்டு ஸ்கிரிப்ட்டிற்கு நகர்த்தி அதில் அனைத்து திட்டங்களின் கட்டங்களையும் எழுதினோம்.

எங்கள் திட்டத்தில் ஒரு கட்டம் உள்ளது, மேலும் பேலன்சரில் திட்டப் பெயர்களின் அடிப்படையில் பல கட்டங்கள் உள்ளன. இது டொமைன் பெயர்கள் மூலம் மேலும் ப்ராக்ஸி செய்யலாம்.

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

வேறு என்ன பிரச்சனைகள் இருந்தன? எல்லா கொள்கலன்களும் முன்னிருப்பாக ரூட்டாக இயங்குவது இதுதான். இது கணினியின் ரூட் சமமற்ற ரூட் ஹோஸ்ட் ஆகும்.

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

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

இதை எப்படித் தீர்க்க முடியும்? கொள்கலனில் இருக்கும் பயனர்களை நீங்கள் சேர்க்கலாம்.

பயனரைச் சேர்த்தபோது என்ன சிக்கல்கள் ஏற்பட்டன?

ஒரு பயனரை உருவாக்கும் போது, ​​குழு ஐடி (யுஐடி) மற்றும் பயனர் ஐடி (ஜிஐடி) பெரும்பாலும் பொருந்தாது.

கண்டெய்னரில் உள்ள இந்தச் சிக்கலைத் தீர்க்க, ஐடி 1000 உள்ள பயனர்களைப் பயன்படுத்துகிறோம்.

எங்கள் விஷயத்தில், கிட்டத்தட்ட எல்லா டெவலப்பர்களும் உபுண்டு OS ஐப் பயன்படுத்துகிறார்கள் என்ற உண்மையுடன் இது ஒத்துப்போகிறது. உபுண்டு ஓஎஸ்ஸில் முதல் பயனருக்கு ஐடி 1000 உள்ளது.

எங்களிடம் திட்டங்கள் உள்ளதா?

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

நாங்கள் தீர்க்கும் சில சிக்கல்கள் ஏற்கனவே நிலையான வழிமுறைகளால் தீர்க்கப்பட்டிருக்கலாம்.

நான் உண்மையில் முன்னேறி நேரடியாக ஆர்கெஸ்ட்ரேஷனுக்கு செல்ல விரும்புகிறேன்.

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

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

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