Inventos "Docker + Gitlab CI සමඟ සංවර්ධන සහ පරීක්ෂණ ක්රියාවලිය" වෙතින් ඇලෙක්සැන්ඩර් සිගචෙව්ගේ වාර්තාවේ පිටපත කියවීමට මම යෝජනා කරමි.
Docker + Gitlab CI මත පදනම්ව සංවර්ධන සහ පරීක්ෂණ ක්රියාවලිය ක්රියාත්මක කිරීමට දැන් පටන් ගන්නා අය බොහෝ විට මූලික ප්‍රශ්න අසයි. ආරම්භ කළ යුත්තේ කොතැනින්ද? සංවිධානය කරන්නේ කෙසේද? පරීක්ෂා කරන්නේ කෙසේද?
Docker සහ Gitlab CI භාවිතා කරමින් සංවර්ධන සහ පරීක්ෂණ ක්රියාවලිය ගැන ව්‍යුහගත ආකාරයෙන් කතා කරන නිසා මෙම වාර්තාව හොඳයි. වාර්තාවම 2017 සිට. මෙම වාර්තාවෙන් ඔබට මූලික කරුණු, ක්‍රමවේදය, අදහස, භාවිතයේ අත්දැකීම් ඉගෙන ගත හැකි යැයි මම සිතමි.
කවුද ගණන් ගන්නේ, කරුණාකර පූසා යට.
මගේ නම ඇලෙක්සැන්ඩර් සිගචෙව්. මම Inventos සඳහා වැඩ කරනවා. ඩොකර් භාවිතා කිරීමේ මගේ අත්දැකීම් සහ සමාගමේ ව්යාපෘති මත අපි එය ක්‍රමයෙන් ක්රියාත්මක කරන ආකාරය ගැන මම ඔබට කියමි.
ඉදිරිපත් කිරීමේ මාතෘකාව: Docker සහ Gitlab CI භාවිතයෙන් සංවර්ධන ක්රියාවලිය.
මේ Docker ගැන මගේ දෙවෙනි කතාව. පළමු වාර්තාව නිකුත් කරන විට, අපි ඩොකර් ඉන් ඩිවලොප්මන්ට් භාවිතා කළේ සංවර්ධක යන්ත්‍රවල පමණි. ඩොකර් භාවිතා කළ සේවක සංඛ්යාව 2-3 ක් පමණ විය. ක්‍රමක්‍රමයෙන් අත්දැකීම් ලබමින් අපි ටිකක් ඉදිරියට ගියා. අපගේ වෙත සබැඳිය .
මෙම වාර්තාවේ කුමක් වනු ඇත්ද? අපි එකතු කර ඇති රාක්ක මොනවාද, අප විසඳා ඇති ගැටළු මොනවාද යන්න පිළිබඳව අපගේ අත්දැකීම් බෙදා ගන්නෙමු. සෑම තැනකම එය ලස්සන නැත, නමුත් ඉදිරියට යාමට ඉඩ දුන්නේය.
අපගේ ආදර්ශ පාඨය වන්නේ: අපට අතට ගත හැකි සියල්ල ඩොක් කරන්න.
අපි විසඳන ගැටලු මොනවාද?
සමාගමක කණ්ඩායම් කිහිපයක් සිටින විට, ක්‍රමලේඛකයා හවුල් සම්පතකි. ක්‍රමලේඛකයෙකු එක් ව්‍යාපෘතියකින් ඉවත් කර තවත් ව්‍යාපෘතියකට යම් කාලයක් ලබා දෙන අවස්ථා තිබේ.
ක්‍රමලේඛකයාට ඉක්මනින් අවබෝධ කර ගැනීම සඳහා, ඔහු ව්යාපෘතියේ ප්‍රභව කේතය බාගත කර හැකි ඉක්මනින් පරිසරය දියත් කළ යුතුය, එමඟින් මෙම ව්යාපෘතියේ ගැටළු තවදුරටත් විසඳීමට ඔහුට ඉඩ සලසයි.
සාමාන්යයෙන්, ඔබ මුල සිට ආරම්භ කරන්නේ නම්, ව්යාපෘතියේ කුඩා ලියකියවිලි ඇත. සකසන්නේ කෙසේද යන්න පිළිබඳ තොරතුරු ලබා ගත හැක්කේ පැරණි අයට පමණි. සේවකයින් දින එකකින් හෝ දෙකකින් තම සේවා ස්ථානය තනිවම පිහිටුවා ගනී. මෙය වේගවත් කිරීම සඳහා, අපි Docker භාවිතා කළෙමු.
ඊළඟ හේතුව වන්නේ සංවර්ධනයේ සැකසුම් ප්‍රමිතිකරණය කිරීමයි. මගේ අත්දැකීම් අනුව, සංවර්ධකයින් සෑම විටම මූලිකත්වය ගනී. සෑම පස්වන අවස්ථාවකදීම, අභිරුචි වසමක් ඇතුල් කරනු ලැබේ, උදාහරණයක් ලෙස, vasya.dev. ඔහු අසල වාඩි වී සිටින්නේ ඔහුගේ අසල්වැසි පෙටියා ය, ඔහුගේ වසම petya.dev වේ. ඔවුන් මෙම ඩොමේන් නාමය භාවිතා කරමින් වෙබ් අඩවියක් හෝ පද්ධතියේ යම් අංගයක් සංවර්ධනය කරයි.
පද්ධතිය වර්ධනය වන විට සහ මෙම ඩොමේන් නාම වින්‍යාසගත වීමට පටන් ගත් විට, සංවර්ධන පරිසර ගැටුමක් ඇති වන අතර අඩවි මාර්ගය නැවත ලියනු ලැබේ.
දත්ත සමුදා සැකසුම් සමඟද එය සිදු වේ. යමෙක් ආරක්ෂාව ගැන කරදර නොවන අතර හිස් මූල මුරපදයකින් ක්‍රියා කරයි. ස්ථාපන අදියරේදී, MySQL යමෙකුගෙන් මුරපදයක් ඉල්ලා සිටි අතර මුරපදය 123 බවට පත් විය. බොහෝ විට සිදුවන්නේ සංවර්ධකයාගේ කැපවීම මත දත්ත සමුදා වින්යාසය නිරන්තරයෙන් වෙනස් වීමයි. කවුරුහරි නිවැරදි කළා, කවුරුහරි වින්යාසය නිවැරදි කළේ නැහැ. අපි යම් ආකාරයක පරීක්ෂණ වින්‍යාසයක් ලබා ගන්නා විට උපක්‍රම තිබුණි .gitignore සහ සෑම සංවර්ධකයෙකුටම දත්ත සමුදාය ස්ථාපනය කිරීමට සිදු විය. මෙය ආරම්භ කිරීමට අපහසු විය. වෙනත් දේ අතර, දත්ත සමුදාය ගැන මතක තබා ගැනීම අවශ්ය වේ. දත්ත සමුදාය ආරම්භ කළ යුතුය, මුරපදයක් ඇතුළත් කළ යුතුය, පරිශීලකයෙකු ලියාපදිංචි කළ යුතුය, වගුවක් සෑදිය යුතුය, සහ යනාදිය.
තවත් ගැටළුවක් වන්නේ පුස්තකාලවල විවිධ අනුවාදයන් ය. සංවර්ධකයෙකු විවිධ ව්යාපෘති සමඟ වැඩ කිරීම බොහෝ විට සිදු වේ. මීට වසර පහකට පෙර (2017 සිට - සංස්. සටහන) ආරම්භ වූ ලෙගසි ව්‍යාපෘතියක් තිබේ. දියත් කරන අවස්ථාවේදී, අපි MySQL 5.5 සමඟ ආරම්භ කළෙමු. අපි MySQL හි වඩාත් නවීන අනුවාද ක්රියාත්මක කිරීමට උත්සාහ කරන නවීන ව්යාපෘති ද ඇත, උදාහරණයක් ලෙස, 5.7 හෝ ඊට වැඩි (2017 දී - සංස්. සටහන)
MySQL සමඟ වැඩ කරන ඕනෑම අයෙකු දන්නවා මෙම පුස්තකාල ඔවුන් සමඟ පරායත්තතා ගෙන එන බව. කඳවුරු 2 ක් එකට ධාවනය කිරීම තරමක් ගැටළු සහගත ය. අවම වශයෙන්, පැරණි සේවාලාභීන් නව දත්ත සමුදායට සම්බන්ධ වීම ගැටළුකාරී වේ. මෙය අනෙක් අතට ගැටළු කිහිපයක් ඇති කරයි.
ඊළඟ ගැටලුව වන්නේ සංවර්ධකයෙකු දේශීය යන්ත්රයක වැඩ කරන විට, ඔහු දේශීය සම්පත්, දේශීය ගොනු, දේශීය RAM භාවිතා කරයි. ගැටළු සඳහා විසඳුමක් සංවර්ධනය කරන අවස්ථාවේ ඇති සියලුම අන්තර්ක්‍රියා සිදු කරනු ලබන්නේ එය එක් යන්ත්රයක ක්‍රියා කරයි යන කාරණයේ රාමුව තුළ ය. උදාහරණයක් ලෙස, අපට නිෂ්පාදන 3 හි පසුබිම් සේවාදායකයන් ඇති විට, සංවර්ධකයා විසින් ගොනු මූල නාමාවලියට සුරකින අතර එතැන් සිට ඉල්ලීමට ප්‍රතිචාර දැක්වීමට nginx ගොනු ගනී. එවැනි කේතයක් නිෂ්පාදනයට ඇතුළු වූ විට, ගොනුව සේවාදායකයන් 3 න් එකක ඇති බව පෙනේ.
ක්ෂුද්‍ර සේවාවල දිශාව දැන් වර්ධනය වෙමින් පවතී. අපි අපගේ විශාල යෙදුම් එකිනෙක හා අන්තර්ක්‍රියා කරන කුඩා කොටස් කිහිපයකට බෙදන විට. විශේෂිත කාර්යයන් සඳහා තාක්ෂණයන් තෝරා ගැනීමට මෙය ඔබට ඉඩ සලසයි. සංවර්ධකයින් අතර වැඩ සහ වගකීම් බෙදා ගැනීමට ද එය ඔබට ඉඩ සලසයි.
JS මත වර්ධනය වන Frondend-developer, Backend මත කිසිදු බලපෑමක් නැත. පසුපෙළ සංවර්ධකයා, අපගේ නඩුවේදී, Ruby on Rails සංවර්ධනය කරන අතර Frondend වලට බාධා නොකරයි. API භාවිතයෙන් අන්තර්ක්‍රියා සිදු කෙරේ.
ප්‍රසාද දීමනාවක් ලෙස, ඩොකර්ගේ සහාය ඇතිව, අපට වේදිකාවේදී සම්පත් ප්‍රතිචක්‍රීකරණය කිරීමට හැකි විය. සෑම ව්යාපෘතියක්ම, එහි විශේෂතා නිසා, යම් යම් සැකසුම් අවශ්ය විය. භෞතික වශයෙන්, අථත්ය සේවාදායකයක් වෙන් කර ඒවා වෙන වෙනම වින්‍යාස කිරීම හෝ යම් ආකාරයක විචල්‍ය පරිසරයක් බෙදා ගැනීම අවශ්ය විය, පුස්තකාලවල අනුවාදය අනුව එකිනෙකට බලපෑම් කළ හැකි ව්යාපෘති.
මෙවලම්. අපි භාවිතා කරන්නේ කුමක්ද?
- Docker තමා. Dockerfile එක යෙදුමක පරායත්තතා විස්තර කරයි.
- Docker-compose යනු අපගේ Docker යෙදුම් කිහිපයක් එකට ගෙන එන මිටියකි.
- මූල කේතය ගබඩා කිරීමට අපි GitLab භාවිතා කරමු.
- පද්ධති ඒකාබද්ධ කිරීම සඳහා අපි GitLab-CI භාවිතා කරමු.
වාර්තාව කොටස් දෙකකින් සමන්විත වේ.
පළමු කොටසින් ඩොකර් සංවර්ධකයින්ගේ යන්ත්‍ර මත ධාවනය වූ ආකාරය ගැන කතා කරනු ඇත.
දෙවන කොටස GitLab සමඟ අන්තර් ක්‍රියා කරන්නේ කෙසේද, අපි පරීක්ෂණ පවත්වන ආකාරය සහ අපි Staging වෙත යොමු වන්නේ කෙසේද යන්න ගැන කතා කරනු ඇත.
ඩොකර් යනු අවශ්ය සංරචක විස්තර කිරීමට (ප්‍රකාශන ප්රවේශයක් භාවිතා කරමින්) ඉඩ දෙන තාක්‍ෂණයකි. මෙය උදාහරණයක් Dockerfile වේ. මෙහිදී අපි නිල Ruby:2.3.0 Docker රූපයෙන් අපට උරුම වන බව ප්‍රකාශ කරමු. එහි Ruby අනුවාදය 2.3 ස්ථාපනය කර ඇත. අපි අවශ්ය ගොඩනැගීමේ පුස්තකාල සහ NodeJS ස්ථාපනය කරමු. අපි නාමාවලියක් නිර්මාණය කරන බව අපි විස්තර කරමු /app. යෙදුම් නාමාවලිය වැඩ කරන නාමාවලිය ලෙස සකසන්න. මෙම නාමාවලිය තුළ අපි අවශ්ය අවම Gemfile සහ Gemfile.lock තබමු. අපි පසුව මෙම පරායත්ත රූපය ස්ථාපනය කරන ව්යාපෘති ගොඩනඟමු. බාහිර වරාය 3000 මත කන්ටේනරය සවන් දීමට සූදානම් බව අපි පෙන්වා දෙමු. අවසාන විධානය වන්නේ අපගේ යෙදුම කෙලින්ම දියත් කරන විධානයයි. අපි ව්යාපෘති ආරම්භක විධානය ක්රියාත්මක කරන්නේ නම්, යෙදුම නිශ්චිත විධානය ක්රියාත්මක කර ක්රියාත්මක කිරීමට උත්සාහ කරයි.
මෙය docker-compose ගොනුවකට අවම උදාහරණයකි. මෙම අවස්ථාවේදී, අපි බහාලුම් දෙකක් අතර සම්බන්ධයක් ඇති බව පෙන්වමු. මෙය සෘජුවම දත්ත සමුදා සේවාවට සහ වෙබ් සේවාවට අයත් වේ. අපගේ වෙබ් යෙදුම් බොහෝ අවස්ථාවලදී දත්ත ගබඩා කිරීම සඳහා පසුබිමක් ලෙස යම් ආකාරයක දත්ත සමුදායක් අවශ්ය වේ. අපි MySQL භාවිතා කරන බැවින්, උදාහරණය MySQL සමඟ ඇත - නමුත් වෙනත් දත්ත සමුදායක් (PostgreSQL, Redis) භාවිතා කිරීමෙන් කිසිවක් අපව වළක්වන්නේ නැත.
අපි MySQL 5.7.14 හි රූපය වෙනස් කිරීමකින් තොරව Docker hub වෙතින් නිල මූලාශ්‍රයෙන් ලබා ගනිමු. අපගේ වෙබ් යෙදුම සඳහා වගකිව යුතු රූපය වත්මන් නාමාවලියෙන් අපි එකතු කරමු. එය පළමු දියත් කිරීමේදී අපට රූපයක් එකතු කරයි. එවිට එය අප මෙහි ක්රියාත්මක කරන විධානය ක්රියාත්මක කරයි. අපි ආපසු ගියහොත්, Puma හරහා දියත් කිරීමේ විධානය අර්ථ දක්වා ඇති බව අපට පෙනෙනු ඇත. Puma යනු Ruby හි ලියා ඇති සේවාවකි. දෙවන නඩුවේදී, අපි ප්රතික්ෂේප කරමු. අපගේ අවශ්යතා හෝ කාර්යයන් අනුව මෙම විධානය අත්තනෝමතික විය හැක.
අපගේ සංවර්ධක ධාරක යන්ත්රයේ වරායක් බහාලුම් වරායේ 3000 සිට 3000 දක්වා යොමු කිරීමට අවශ්ය බව ද අපි විස්තර කරමු. මෙය iptables සහ එහි යාන්ත්රණය භාවිතයෙන් ස්වයංක්‍රීයව සිදු කරනු ලබන අතර එය සෘජුවම Docker හි තැන්පත් කර ඇත.
සංවර්ධකයාට පෙර පරිදිම, පවතින ඕනෑම IP ලිපිනයකට ප්‍රවේශ විය හැක, උදාහරණයක් ලෙස, 127.0.0.1 යනු යන්ත්රයේ දේශීය හෝ බාහිර IP ලිපිනයයි.
අවසාන පේළියේ වෙබ් කන්ටේනරය රඳා පවතින්නේ db කන්ටේනරය මත බවයි. අපි වෙබ් කන්ටේනරයේ ආරම්භය ඇමතූ විට, docker-compose මුලින්ම අප සඳහා දත්ත සමුදාය ආරම්භ කරයි. දැනටමත් දත්ත සමුදාය ආරම්භයේදී (ඇත්ත වශයෙන්ම, බහාලුම් දියත් කිරීමෙන් පසුව! මෙය දත්ත සමුදායේ සූදානම සහතික නොකරයි) යෙදුම, අපගේ පසුපෙළ දියත් කරනු ඇත.
මෙමගින් දත්ත සමුදාය ක්රියාත්මක නොවන විට දෝෂ මග හැරෙන අතර අප දත්ත සමුදා බහාලුම නැවැත්වූ විට සම්පත් ඉතිරි කරයි, එමගින් අනෙකුත් ව්යාපෘති සඳහා සම්පත් නිදහස් කරයි.
ව්යාපෘතියේ දත්ත සමුදා ඩොකරීකරණයේ භාවිතය අපට ලබා දෙන්නේ කුමක් ද? අපි සියලුම සංවර්ධකයින් සඳහා MySQL අනුවාදය සවි කරමු. මෙය අනුවාද අපසරනය වන විට, වාක්‍ය ඛණ්ඩය, වින්යාසය, පෙරනිමි සැකසුම් වෙනස් වන විට සිදු විය හැකි සමහර දෝෂ මඟහරවයි. දත්ත සමුදාය, පිවිසුම, මුරපදය සඳහා පොදු සත්කාරක නාමයක් නියම කිරීමට මෙය ඔබට ඉඩ සලසයි. අපි කලින් තිබ්බ config files වල නම් සහ ගැටුම් සත්තු වත්තෙන් ඈත් වෙනවා.
සංවර්ධන පරිසරය සඳහා වඩාත් ප්‍රශස්ත වින්‍යාසයක් භාවිතා කිරීමට අපට අවස්ථාව තිබේ, එය පෙරනිමියෙන් වෙනස් වේ. MySQL පෙරනිමියෙන් දුර්වල යන්ත්‍ර සඳහා වින්‍යාස කර ඇති අතර කොටුවෙන් පිටත එහි ක්රියාකාරිත්වය ඉතා දුර්වලය.
Docker ඔබට අවශ්ය අනුවාදයේ Python, Ruby, NodeJS, PHP පරිවර්තකය භාවිතා කිරීමට ඉඩ සලසයි. අපි යම් ආකාරයක අනුවාද කළමනාකරුවෙකු භාවිතා කිරීමේ අවශ්‍යතාවයෙන් මිදෙන්නෙමු. මීට පෙර, Ruby විසින් rpm පැකේජයක් භාවිතා කරන ලද අතර එය ව්යාපෘතිය අනුව අනුවාදය වෙනස් කිරීමට ඔබට ඉඩ සලසයි. ඩොකර් කන්ටේනරයට ස්තුති වන්නට, කේතය සුමට ලෙස සංක්‍රමණය කිරීමට සහ පරායත්තතා සමඟ එය සංස්කරණය කිරීමට ද එය ඉඩ දෙයි. පරිවර්තකය සහ කේතය යන දෙකෙහිම අනුවාදය තේරුම් ගැනීමට අපට කිසිදු ගැටළුවක් නොමැත. අනුවාදය යාවත්කාලීන කිරීමට, පැරණි කන්ටේනරය පහත් කර නව බහාලුම ඔසවන්න. යමක් වැරදී ඇත්නම්, අපට නව කන්ටේනරය පහත් කළ හැකිය, පැරණි කන්ටේනරය ඔසවන්න.
රූපය ගොඩනැගීමෙන් පසු, සංවර්ධනය සහ නිෂ්පාදනය යන දෙකෙහිම ඇති බහාලුම් සමාන වේ. විශාල ස්ථාපනයන් සඳහා මෙය විශේෂයෙන්ම සත්ය වේ.
Frontend මත අපි JavaScipt සහ NodeJS භාවිතා කරමු.
දැන් අපට ReacJS හි අවසාන ව්යාපෘතිය තිබේ. සංවර්ධකයා කන්ටේනරයේ ඇති සියල්ල ධාවනය කර උණුසුම්-රිලෝඩ් භාවිතයෙන් සංවර්ධනය කළේය.
මීළඟට, JavaScipt එකලස් කිරීමේ කාර්යය දියත් කරන අතර ස්ථිතික බවට සම්පාදනය කරන ලද කේතය nginx ඉතිරි කිරීමේ සම්පත් හරහා ලබා දෙනු ලැබේ.
මෙන්න මම අපේ අවසාන ව්යාපෘතියේ යෝජනා ක්‍රමය ලබා දුන්නා.
විසඳන ලද කාර්යයන් මොනවාද? ජංගම උපාංග අන්තර්ක්‍රියා කරන පද්ධතියක් ගොඩනැගීමේ අවශ්‍යතාවය අපට තිබුණි. ඔවුන්ට දත්ත ලැබෙනවා. එක් හැකියාවක් වන්නේ මෙම උපාංගයට තල්ලු දැනුම්දීම් යැවීමයි.
මේ සඳහා අප කර ඇත්තේ කුමක්ද?
අපි යෙදුමට එවැනි සංරචක බෙදුවෙමු: JS හි පරිපාලක කොටස, පසුපෙළ, Ruby on Rails යටතේ REST අතුරුමුහුණත හරහා ක්‍රියා කරයි. පසුපෙළ දත්ත සමුදාය සමඟ අන්තර්ක්‍රියා කරයි. උත්පාදනය කරන ලද ප්රතිඵලය සේවාදායකයාට ලබා දෙනු ලැබේ. පරිපාලක මණ්ඩලය REST අතුරුමුහුණත හරහා පසුපෙළ සහ දත්ත සමුදාය සමඟ අන්තර්ක්‍රියා කරයි.
අපට තල්ලු දැනුම්දීම් යැවීමේ අවශ්‍යතාවයක් ද ඇති විය. ඊට පෙර, ජංගම වේදිකා වෙත දැනුම්දීම් ලබා දීම සඳහා වගකිව යුතු යාන්ත්‍රණයක් ක්රියාත්මක කරන ව්‍යාපෘතියක් අපට තිබුණි.
අපි පහත යෝජනා ක්‍රමය සකස් කර ඇත: බ්‍රවුසරයේ ක්‍රියාකරු පරිපාලක පැනලය සමඟ අන්තර් ක්‍රියා කරයි, පරිපාලක පැනලය පසුබිම සමඟ අන්තර් ක්‍රියා කරයි, කාර්යය වන්නේ තල්ලු දැනුම්දීම් යැවීමයි.
තල්ලු දැනුම්දීම් NodeJS හි ක්රියාත්මක වන වෙනත් සංරචකයක් සමඟ අන්තර්ක්‍රියා කරයි.
පෝලිම් ඉදි කර පසුව ඔවුන්ගේ යාන්ත්රණය අනුව දැනුම්දීම් යවනු ලැබේ.
මෙහි දත්ත සමුදායන් දෙකක් ඇද ඇත. මේ වන විට Docker ගේ සහය ඇතිව අපි කිසිම ආකාරයකින් එකිනෙකට සම්බන්ධ නැති ස්වාධීන දත්ත සමුදායන් 2ක් භාවිතා කරමු. මීට අමතරව, ඔවුන්ට පොදු අථත්ය ජාලයක් ඇති අතර, භෞතික දත්ත සංවර්ධකයාගේ යන්ත්රයේ විවිධ බහලුම්වල ගබඩා කර ඇත.
එකම නමුත් ඉලක්කම් වලින්. කේතය නැවත භාවිතා කිරීම වැදගත් වන්නේ මෙහිදීය.
අපි මීට පෙර පුස්තකාල ස්වරූපයෙන් කේතය නැවත භාවිතා කිරීම ගැන කතා කළේ නම්, මෙම උදාහරණයේදී, Push දැනුම්දීම් වලට ප්‍රතිචාර දක්වන අපගේ සේවාව සම්පූර්ණ සේවාදායකයක් ලෙස නැවත භාවිතා වේ. එය API සපයයි. අපගේ නව සංවර්ධනය දැනටමත් එය සමඟ අන්තර් ක්‍රියා කරයි.
ඒ වන විට අපි NodeJS හි 4 අනුවාදය භාවිතා කරමින් සිටියෙමු. දැන් (2017 දී - සංස්කරණ සටහන) මෑත වර්ධනයන්හිදී අපි NodeJS හි 7 අනුවාදය භාවිතා කරමු. පුස්තකාලවල නව අනුවාද ඇතුළත් කිරීමට නව සංරචකවල ගැටලුවක් නොමැත.
අවශ්ය නම්, ඔබට Push දැනුම්දීම් සේවාවෙන් NodeJS අනුවාදය නැවත සකස් කර ඉහළ නැංවීමට හැකිය.
අපට API අනුකූලතාව පවත්වා ගත හැකි නම්, එය කලින් භාවිතා කළ වෙනත් ව්යාපෘති සමඟ ප්‍රතිස්ථාපනය කිරීමට හැකි වනු ඇත.
Docker එක් කිරීමට ඔබට අවශ්ය කුමක්ද? අවශ්ය පරායත්තතා විස්තර කරන අපගේ ගබඩාවට අපි Dockerfile එකක් එකතු කරමු. මෙම උදාහරණයේ දී, සංරචක තාර්කිකව බිඳී ඇත. මෙය පසුපෙළ සංවර්ධකයෙකුගේ අවම කට්ටලයයි.
නව ව්‍යාපෘතියක් නිර්මාණය කරන විට, අපි Dockerfile නිර්මාණය කරමු, අවශ්ය පරිසර පද්ධතිය විස්තර කරන්න (Python, Ruby, NodeJS). docker-compose හි, එය අවශ්ය පරායත්තතාව විස්තර කරයි - දත්ත සමුදාය. අපට එවැනි සහ එවැනි අනුවාදයක දත්ත ගබඩාවක් අවශ්ය බව අපි විස්තර කරමු, දත්ත එහි සහ එහි ගබඩා කරන්න.
ස්ථිතික සේවය කිරීම සඳහා අපි nginx සමඟ වෙනම තෙවන බහාලුමක් භාවිතා කරමු. පින්තූර උඩුගත කිරීමට හැකියාව ඇත. පසුපෙළ ඒවා පෙර සූදානම් කළ පරිමාවක තබයි, එය ස්ථිතික ලබා දෙන nginx සමඟ කන්ටේනරයක ද සවි කර ඇත.
nginx, mysql වින්යාසය ගබඩා කිරීම සඳහා, අපි අවශ්ය වින්‍යාසයන් ගබඩා කරන ඩොකර් ෆෝල්ඩරයක් එක් කළෙමු. සංවර්ධකයෙකු තම යන්ත්රයේ ගබඩාවක git ක්ලෝනයක් කරන විට, ඔහු දැනටමත් දේශීය සංවර්ධනය සඳහා ව්‍යාපෘතියක් සූදානම් කර ඇත. කුමන වරායක් හෝ යෙදිය යුතු සැකසුම් මොනවාද යන්න ප්රශ්නයක් නැත.
ඊළඟට, අපට සංරචක කිහිපයක් තිබේ: පරිපාලක, තොරතුරු-API, තල්ලු දැනුම්දීම්.
මේ සියල්ල ආරම්භ කිරීම සඳහා, අපි තවත් ගබඩාවක් නිර්මාණය කළෙමු, එය අපි dockerized-app ලෙස හැඳින්වුවෙමු. මේ මොහොතේ අපි එක් එක් සංරචකයට පෙර ගබඩා කිහිපයක් භාවිතා කරමු. ඒවා තාර්කිකව වෙනස් ය - GitLab හි එය ෆෝල්ඩරයක් මෙන් පෙනේ, නමුත් සංවර්ධකයාගේ යන්ත්රයේ, විශේෂිත ව්‍යාපෘතියක් සඳහා ෆෝල්ඩරයක්. එක් මට්ටමක් පහළට ඒකාබද්ධ කරනු ලබන සංරචක වේ.
මෙය dockerized-app හි අන්තර්ගතය සඳහා උදාහරණයකි. අපි සියලු සංරචකවල අන්තර්ක්‍රියා සඳහා අවශ්ය වින්‍යාසයන් පුරවන ඩොකර් නාමාවලිය ද මෙහි ගෙන එන්නෙමු. ව්යාපෘතිය ක්රියාත්මක කරන්නේ කෙසේද යන්න කෙටියෙන් විස්තර කරන README.md එකක් ඇත.
මෙන්න අපි docker-compose ගොනු දෙකක් යෙදුවා. පියවරෙන් පියවර ධාවනය කිරීමට හැකි වන පරිදි මෙය සිදු කෙරේ. සංවර්ධකයෙකු හරය සමඟ ක්‍රියා කරන විට, ඔහුට තල්ලු දැනුම්දීම් අවශ්ය නොවේ, ඔහු හුදෙක් ඩොකර් රචනා ගොනුවක් දියත් කරන අතර, ඒ අනුව, සම්පත සුරැකේ.
තල්ලු දැනුම්දීම් සමඟ ඒකාබද්ධ කිරීමට අවශ්ය නම්, docker-compose.yaml සහ docker-compose-push.yaml දියත් කෙරේ.
docker-compose.yaml සහ docker-compose-push.yaml ෆෝල්ඩරයක ඇති බැවින්, තනි අතථ්‍ය ජාලයක් ස්වයංක්‍රීයව නිර්මාණය වේ.
සංරචක විස්තරය. මෙය සංරචක එකතු කිරීම සඳහා වගකිව යුතු වඩාත් දියුණු ගොනුවකි. මෙහි කැපී පෙනෙන දේ කුමක්ද? මෙන්න අපි සමතුලිත සංරචකය හඳුන්වා දෙන්නෙමු.
මෙය nginx ධාවනය වන සූදානම් කළ Docker රූපයක් වන අතර Docker socket මත සවන් දෙන යෙදුමකි. ගතික, බහාලුම් සක්‍රිය සහ අක්‍රිය කර ඇති බැවින්, එය nginx වින්යාසය ප්‍රතිජනනය කරයි. අපි තුන්වන මට්ටමේ ඩොමේන් නාම මගින් සංරචක හැසිරවීම බෙදා හරිමු.
සංවර්ධන පරිසරය සඳහා, අපි .dev වසම භාවිතා කරමු - api.informer.dev. .dev වසමක් සහිත යෙදුම් සංවර්ධකයාගේ දේශීය යන්ත්රයේ ඇත.
තවද, configs එක් එක් ව්‍යාපෘතියට මාරු කරනු ලබන අතර සියලුම ව්යාපෘති එකවර දියත් කෙරේ.
ග්‍රැෆික් ලෙස, සේවාදායකයා අපගේ බ්‍රවුසරය හෝ අපි සමතුලිතයාට ඉල්ලීම් කරන යම් මෙවලමක් බව පෙනේ.
වසම් නාම සමතුලිතකය සම්බන්ධ කර ගත යුතු බහාලුම තීරණය කරයි.
එය පරිපාලක JS ලබා දෙන nginx විය හැක. මෙය API ලබා දෙන nginx හෝ රූප උඩුගත කිරීම් ආකාරයෙන් nginx වෙත ලබා දෙන ස්ථිතික ගොනු විය හැකිය.
රූප සටහනේ දැක්වෙන්නේ බහාලුම් අථත්ය ජාලයකින් සම්බන්ධ කර ඇති අතර ප්‍රොක්සියක් පිටුපස සැඟවී ඇති බවයි.
සංවර්ධකයාගේ යන්ත්‍රය මත, ඔබට IP දැනගෙන කන්ටේනරයට ප්‍රවේශ විය හැකිය, නමුත් ප්‍රතිපත්තිමය වශයෙන් අපි මෙය භාවිතා නොකරමු. සෘජු ප්රවේශයක් සඳහා ප්රායෝගිකව අවශ්ය නොවේ.
ඔබගේ යෙදුම ඩොකරීකරණය කිරීමට බැලිය යුතු උදාහරණය කුමක්ද? මගේ මතය අනුව, MySQL සඳහා නිල ඩොකර් රූපය හොඳ උදාහරණයක්.
එය තරමක් අභියෝගාත්මකයි. බොහෝ අනුවාද ඇත. නමුත් එහි ක්රියාකාරිත්වය තවදුරටත් සංවර්ධනය කිරීමේ ක්රියාවලිය තුළ පැන නැගිය හැකි බොහෝ අවශ්යතා ආවරණය කිරීමට ඔබට ඉඩ සලසයි. ඔබ කාලය ගත කරන්නේ නම් සහ ඒ සියල්ල අන්තර්ක්‍රියා කරන්නේ කෙසේදැයි සොයා බැලුවහොත්, ස්වයං-ක්රියාත්මක කිරීමේදී ඔබට කිසිදු ගැටළුවක් ඇති නොවනු ඇතැයි මම සිතමි.
Hub.docker.com හි සාමාන්යයෙන් github.com වෙත සබැඳි අඩංගු වේ, එහි අමු දත්ත අඩංගු වන අතර ඔබට රූපය ඔබම ගොඩනගා ගත හැකිය.
තවදුරටත් මෙම ගබඩාවේ docker-endpoint.sh ස්ක්‍රිප්ට් එකක් ඇත, එය ආරම්භක ආරම්භය සහ යෙදුම් දියත් කිරීම තවදුරටත් සැකසීම සඳහා වගකිව යුතුය.
එසේම මෙම උදාහරණයේ පරිසර විචල්‍යයන් භාවිතයෙන් වින්‍යාස කිරීමේ හැකියාව ඇත. තනි කන්ටේනරයක් ධාවනය කරන විට හෝ docker-compose හරහා පරිසර විචල්‍යයක් නිර්වචනය කිරීමෙන්, අපට MySQL හෝ අපට අවශ්ය ඕනෑම දෙයක් මත ඩොකර් සඳහා රූට් කිරීමට හිස් මුරපදයක් සැකසිය යුතු බව පැවසිය හැකිය.
අහඹු මුරපදයක් සෑදීමට විකල්පයක් ඇත. අපි කියන්නේ අපිට පරිශීලකයෙක් අවශ්‍යයි, පරිශීලකයාට මුරපදයක් සැකසීමට අවශ්ය වන අතර අපි දත්ත සමුදායක් සෑදිය යුතුයි.
අපගේ ව්යාපෘති වලදී, අපි ආරම්භ කිරීම සඳහා වගකිව යුතු Dockerfile තරමක් ඒකාබද්ධ කළෙමු. එහිදී අපි එය යෙදුම භාවිතා කරන පරිශීලක අයිතිවාසිකම්වල දිගුවක් බවට පත් කිරීම සඳහා අපගේ අවශ්යතා සඳහා එය නිවැරදි කළෙමු. මෙය පසුව යෙදුම් කොන්සෝලයෙන් දත්ත සමුදායක් නිර්මාණය කිරීමට අපට ඉඩ සලසයි. Ruby යෙදුම් වලට දත්ත සමුදායන් සෑදීම, වෙනස් කිරීම සහ මකා දැමීම සඳහා විධානයක් ඇත.
මෙය Github.com හි MySQL හි නිශ්චිත අනුවාදයක් පෙනෙන ආකාරය පිළිබඳ උදාහරණයකි. ඔබට Dockerfile එක විවෘත කර එහි ස්ථාපනය සිදුවන ආකාරය බලන්න.
docker-endpoint.sh යනු ඇතුල්වීමේ ස්ථානයට වගකියන ස්ක්‍රිප්ට් වේ. ආරම්භක ආරම්භයේදී, සමහර සූදානම් කිරීමේ පියවරයන් අවශ්ය වන අතර, මෙම සියලු ක්‍රියා සිදු කරනු ලබන්නේ ආරම්භක පිටපතේ පමණි.
අපි දෙවන කොටසට යමු.
මූලාශ්‍ර කේත ගබඩා කිරීමට, අපි gitlab වෙත මාරු විය. මෙය දෘශ්‍ය අතුරු මුහුණතක් ඇති තරමක් බලවත් පද්ධතියකි.
Gitlab හි එක් අංගයක් වන්නේ Gitlab CI ය. කේත බෙදා හැරීමේ පද්ධතියක් සංවිධානය කිරීමට හෝ ස්වයංක්‍රීය පරීක්ෂණ ක්රියාත්මක කිරීමට පසුව භාවිතා කරන විධාන මාලාවක් විස්තර කිරීමට එය ඔබට ඉඩ සලසයි.
Gitlab CI 2 කතාව - රූබි රුසියාව සමාජයෙන් වාර්තාව - තරමක් සවිස්තරාත්මක සහ සමහර විට එය ඔබට උනන්දුවක් දක්වනු ඇත.
Gitlab CI සක්‍රිය කිරීමට අවශ්ය දේ අපි දැන් බලමු. Gitlab CI ආරම්භ කිරීම සඳහා, අපට අවශ්ය වන්නේ .gitlab-ci.yml ගොනුව ව්යාපෘතියේ මූලයට දැමීම පමණි.
මෙහිදී අපි විස්තර කරන්නේ අපට test, deploy වැනි ප්‍රාන්තවල අනුපිළිවෙලක් ක්රියාත්මක කිරීමට අවශ්ය බවයි.
අපි අපගේ යෙදුම ගොඩ නැගීම සඳහා සෘජුවම docker-compose ලෙස හඳුන්වන ස්ක්‍රිප්ට් ක්රියාත්මක කරන්නෙමු. මෙය පසුබිම් උදාහරණයක් පමණි.
මීළඟට, දත්ත සමුදාය වෙනස් කිරීමට සහ පරීක්ෂණ ධාවනය කිරීමට සංක්රමණයන් ක්රියාත්මක කිරීම අවශ්ය බව අපි කියමු.
ස්ක්‍රිප්ට් නිවැරදිව ක්රියාත්මක කර දෝෂ කේතයක් ලබා නොදෙන්නේ නම්, පද්ධතිය යෙදවීමේ දෙවන අදියර දක්වා ගමන් කරයි.
වේදිකාගත කිරීම සඳහා යෙදවීමේ අදියර දැනට ක්රියාත්මක වේ. අපි ශුන්‍ය අක්‍රීය කාල නැවත ආරම්භයක් සංවිධානය නොකළෙමු.
අපි සියලු බහාලුම් බලහත්කාරයෙන් නිවා දමන්නෙමු, පසුව අපි පරීක්ෂා කිරීමේදී පළමු අදියරේදී එකතු කරන ලද සියලුම බහාලුම් නැවත ඔසවන්නෙමු.
අපි සංවර්ධකයින් විසින් ලියා ඇති දත්ත සමුදා සංක්රමණයන් වත්මන් පරිසර විචල්‍ය සඳහා ධාවනය කරන්නෙමු.
මෙය මාස්ටර් ශාඛාවට පමණක් අදාළ වන බව සටහනක් තිබේ.
වෙනත් ශාඛා වෙනස් කිරීමේදී ක්රියාත්මක නොවේ.
ශාඛා මගින් පෙරළීම් සංවිධානය කළ හැකිය.
මෙය තවදුරටත් සංවිධානය කිරීමට, අපි Gitlab Runner ස්ථාපනය කළ යුතුය.
මෙම උපයෝගීතාව Golang වලින් ලියා ඇත. එය Golang ලෝකයේ බහුලව දක්නට ලැබෙන පරිදි, කිසිදු පරායත්තතාවයක් අවශ්ය නොවන තනි ගොනුවකි.
ආරම්භයේදී, අපි Gitlab Runner ලියාපදිංචි කරන්නෙමු.
Gitlab වෙබ් අතුරු මුහුණතේ යතුර අපට ලැබේ.
එවිට අපි විධාන රේඛාවේ ආරම්භක විධානය අමතන්නෙමු.
Gitlab Runner අන්තර්ක්‍රියාකාරීව සකසන්න (Shell, Docker, VirtualBox, SSH)
Gitlab Runner හි කේතය .gitlab-ci.yml සැකසුම මත පදනම්ව සෑම කැපවීමකදීම ක්රියාත්මක වේ.
වෙබ් අතුරු මුහුණතේ Gitlab හි එය දෘශ්‍යමය වශයෙන් පෙනෙන ආකාරය. අපි GItlab CI සම්බන්ධ කළ පසු, අපි දැනට ගොඩනැගීමේ තත්ත්වය පෙන්වන ධජයක් ඇත.
අපි දකිනවා මිනිත්තු 4 කට පෙර කැපවීමක් සිදු කර ඇති අතර එය සියලු පරීක්ෂණ සමත් වූ අතර කිසිදු ගැටළුවක් ඇති නොකරයි.
අපට ඉදිකිරීම් දෙස සමීපව බැලිය හැකිය. මෙහිදී අපට පෙනෙන්නේ දැනටමත් ප්රාන්ත දෙකක් සම්මත වී ඇති බවයි. වේදිකාවේ තත්ත්වය සහ යෙදවීමේ තත්ත්වය පරීක්ෂා කිරීම.
අපි නිශ්චිත ගොඩනැගීමක් මත ක්ලික් කළහොත්, .gitlab-ci.yml අනුව ක්‍රියාවලියේදී ක්රියාත්මක වූ විධානවල කොන්සෝල ප්‍රතිදානයක් ඇත.
අපගේ නිෂ්පාදන ඉතිහාසය පෙනෙන්නේ මෙයයි. සාර්ථක උත්සාහයන් තිබෙන බව අපට පෙනෙනවා. පරීක්ෂණ ඉදිරිපත් කරන විට, එය ඊළඟ පියවරට නොයන අතර වේදිකා කේතය යාවත්කාලීන නොවේ.
අපි ඩොකර් ක්රියාත්මක කරන විට වේදිකාගත කිරීමේදී අපි විසඳූ කාර්යයන් මොනවාද? අපගේ පද්ධතිය සංරචක වලින් සමන්විත වන අතර අපට නැවත ආරම්භ කිරීමට අවශ්ය විය, ගබඩාවේ යාවත්කාලීන කරන ලද සංරචක වලින් කොටසක් පමණක් මිස සම්පූර්ණ පද්ධතිය නොවේ.
මෙය සිදු කිරීම සඳහා, අපි සියල්ල වෙනම ෆෝල්ඩර වලට කඩා දැමීමට සිදු විය.
අපි මෙය කළ පසු, Docker-compose එක එක් එක් තාත්තා සඳහා තමන්ගේම ජාල අවකාශයක් නිර්මාණය කිරීම සහ අසල්වැසියාගේ සංරචක නොපෙනීම පිළිබඳව අපට ගැටලුවක් ඇති විය.
එහා මෙහා යාමට, අපි Docker හි ජාලය අතින් නිර්මාණය කළෙමු. ඔබ මෙම ව්යාපෘතිය සඳහා එවැනි ජාලයක් භාවිතා කරන බව Docker-compose හි ලියා තිබුණි.
මේ අනුව, මෙම දැලෙන් ආරම්භ වන සෑම සංරචකයක්ම පද්ධතියේ අනෙකුත් කොටස්වල සංරචක දකියි.
මීළඟ ගැටළුව වන්නේ ව්යාපෘති කිහිපයක් හරහා වේදිකාගත කිරීමයි.
මේ සියල්ල ලස්සනට සහ නිෂ්පාදනයට හැකි තරම් සමීප වීමට නම්, වෙබ් අඩවියේ සෑම තැනකම භාවිතා වන වරාය 80 හෝ 443 භාවිතා කිරීම හොඳය.
අපි එය විසඳුවේ කෙසේද? අපි සියලුම ප්‍රධාන ව්යාපෘති සඳහා එක් Gitlab ධාවකයෙකු ලබා දී ඇත.
බෙදා හරින ලද Gitlab ධාවකයන් කිහිපයක් ධාවනය කිරීමට Gitlab ඔබට ඉඩ සලසයි, එමඟින් සියලු කාර්යයන් අවුල් සහගත ලෙස ගෙන ඒවා ක්රියාත්මක කරයි.
අපට නිවසක් නොමැති නිසා, අපි අපගේ ව්යාපෘති සමූහය එක් Gitlab ධාවකයකට සීමා කළෙමු, එය අපගේ පරිමාවන් සමඟ ගැටළු නොමැතිව කටයුතු කරයි.
අපි nginx-proxy වෙනම ආරම්භක ස්ක්‍රිප්ට් එකකට ගෙන ගොස් එහි ඇති සියලුම ව්යාපෘති සඳහා ජාලක එකතු කළෙමු.
අපගේ ව්‍යාපෘතියට එක් ජාලකයක් ඇති අතර, සමතුලිතයට ව්යාපෘති නම්වලින් ජාල කිහිපයක් ඇත. එය ඩොමේන් නාම මගින් තවදුරටත් ප්‍රොක්සි කළ හැක.
අපගේ ඉල්ලීම් වරාය 80 හි වසම හරහා පැමිණෙන අතර මෙම වසමට සේවය කරන බහාලුම් කණ්ඩායමක් තුළ විසඳනු ලැබේ.
එහි ඇති වෙනත් ගැටළු මොනවාද? සියලුම බහාලුම් පෙරනිමියෙන් root ලෙස ක්රියාත්මක වන්නේ මෙයයි. මෙය මූල පද්ධතියේ මූල ධාරකයට අසමාන වේ.
කෙසේ වෙතත්, ඔබ කන්ටේනරය ඇතුළු කළහොත්, එය root වන අතර මෙම කන්ටේනරය තුළ අප විසින් සාදන ලද ගොනුවට root හිමිකම් ලැබේ.
සංවර්ධකයා බහාලුමට ඇතුළු වී එහි ලිපිගොනු උත්පාදනය කරන විධාන කිහිපයක් සෑදුවා නම්, පසුව කන්ටේනරය අත්හැරියේ නම්, ඔහුට ප්‍රවේශය නොමැති ගොනුවක් ඔහුගේ වැඩ කරන නාමාවලියෙහි තිබේ.
එය විසඳිය හැක්කේ කෙසේද? ඔබට බහාලුම්වල සිටින පරිශීලකයින් එකතු කළ හැකිය.
අපි පරිශීලකයා එකතු කළ විට ඇති වූ ගැටළු මොනවාද?
පරිශීලකයෙකු නිර්මාණය කිරීමේදී, අපට බොහෝ විට එකම කණ්ඩායම් හැඳුනුම්පත (UID) සහ පරිශීලක හැඳුනුම්පත (GID) නොමැත.
කන්ටේනරය තුළ මෙම ගැටළුව විසඳීම සඳහා, අපි ID 1000 සහිත පරිශීලකයින් භාවිතා කරමු.
අපගේ නඩුවේදී, මෙය සමපාත වූයේ සියලුම සංවර්ධකයින් පාහේ උබුන්ටු මෙහෙයුම් පද්ධතිය භාවිතා කරන බැවිනි. තවද Ubuntu හි, පළමු පරිශීලකයාට 1000 හැඳුනුම්පතක් ඇත.
අපට සැලසුම් තිබේද?
Docker ලියකියවිලි කියවන්න. ව්යාපෘතිය ක්රියාශීලීව සංවර්ධනය වෙමින් පවතී, ලේඛන වෙනස් වේ. දැනට මාස දෙක තුනකට කලින් ලැබුණු දත්ත ටිකෙන් ටික යල් පැන යනවා.
අප විසින් විසඳන ලද සමහර ගැටළු දැනටමත් සම්මත ක්රම මගින් විසඳා ඇත.
ඒ නිසා මට කෙලින්ම වාද්‍ය වෘන්දයට යාමට දැනටමත් ඉදිරියට යාමට අවශ්‍යයි.
එක් උදාහරණයක් නම් ඩොකර්ගේ ගොඩනඟන ලද යාන්ත්රණය වන ඩොකර් ස්වර්ම් නම් කොටුවෙන් පිටතට පැමිණේ. මට Docker Swarm තාක්ෂණය මත පදනම්ව නිෂ්පාදනයේ යමක් ධාවනය කිරීමට අවශ්‍යයි.
පැටවුන් බිහි කිරීම ලොග් සමඟ වැඩ කිරීමට අපහසු වේ. දැන් ලඝු-සටහන් හුදකලා වී ඇත. ඒවා බහාලුම් හරහා විසිරී ඇත. එක් කාර්යයක් වන්නේ වෙබ් අතුරු මුහුණත හරහා ලඝු-සටහන් වෙත පහසු ප්රවේශයක් ලබා දීමයි.
මූලාශ්රය: www.habr.com