ආයුබෝවන් හැමෝටම!
මට ඇත්ත වශයෙන්ම මාතෘකාවට කෙලින්ම යාමට අවශ්‍යයි, නමුත් මගේ කතාව ගැන ටිකක් පැවසීම වඩාත් නිවැරදි වනු ඇත:
පිවිසුම්
මම ඉදිරිපස තනි පිටු යෙදුම්, Scala/java සහ nodejs සේවාදායකයේ සංවර්ධනය කිරීමේ අත්දැකීම් ඇති ක්‍රමලේඛකයෙක්මි.
සෑහෙන කාලයක් (අනිවාර්‍යෙන්ම යුවලක් හෝ අවුරුදු තුනක්), Docker යනු ස්වර්ගයේ සිට මන්නා වන අතර පොදුවේ ඉතා සිසිල් මෙවලමක් වන අතර නියත වශයෙන්ම සෑම සංවර්ධකයෙකුටම එය භාවිතා කළ හැකි බව මගේ අදහස විය. මෙයින් කියවෙන්නේ සෑම සංවර්ධකයෙකුම ඔවුන්ගේ දේශීය යන්ත්‍රයේ ඩොකර් ස්ථාපනය කර තිබිය යුතු බවයි. මගේ මතය ගැන කුමක් කිව හැකිද, එකම hh හි පළ කර ඇති පුරප්පාඩු දෙස බලන්න. සෑම තත්පරයකම ඩොකර් ගැන සඳහනක් අඩංගු වන අතර, එය ඔබ සතු නම්, මෙය ඔබේ තරඟකාරී වාසිය වනු ඇත 😉
මම යන අතරමගදී, මට ඩොකර් සහ එහි පරිසර පද්ධතිය කෙරෙහි ඔවුන්ගේ විවිධ ආකල්ප සහිත බොහෝ පුද්ගලයින් මුණගැසුණි. සමහරු පැවසුවේ මෙය හරස් වේදිකා ක්‍රියාකාරිත්වය සහතික කරන පහසු දෙයක් බවයි. කන්ටේනර්වල දුවන්නේ ඇයිද, එයින් ලැබෙන ලාභය කුමක්දැයි දෙවැන්නාට වැටහුණේ නැත, තුන්වැන්නා කිසිසේත් ගණන් ගත්තේ නැත, කරදර වූයේ නැත (ඔවුන් කේතය ලියා ගෙදර ගියේය - මම ඔවුන්ට ඊර්ෂ්‍යා කරමි, ආකාරය :)
භාවිතය සඳහා හේතු
මම ඩොකර් භාවිතා කළේ ඇයි? පහත සඳහන් හේතු නිසා විය හැකිය:
- දත්ත සමුදාය දියත් කිරීම, යෙදුම් වලින් 99% ඒවා භාවිතා කරයි
- ඉදිරිපස බෙදා හැරීම සඳහා nginx දියත් කිරීම සහ පසුපෙළට ප්‍රොක්සි කිරීම
- ඔබට යෙදුම ඩොකර් රූපයක ඇසුරුම් කළ හැකිය, මේ ආකාරයෙන් මගේ යෙදුම ඩොකර් පවතින ඕනෑම තැනක ක්‍රියා කරයි, බෙදා හැරීමේ ගැටළුව වහාම විසඳනු ලැබේ
- පෙට්ටියෙන් පිටත සේවා සොයාගැනීම, ඔබට ක්ෂුද්‍ර සේවා නිර්මාණය කළ හැකිය, එක් එක් බහාලුම් (පොදු ජාලයකට සම්බන්ධ) අන්වර්ථයක් හරහා පහසුවෙන් තවත් කෙනෙකුට ළඟා විය හැකිය, ඉතා පහසුය
- එය කන්ටේනරයක් නිර්මාණය කිරීම සහ එහි "සෙල්ලම්" කිරීම විනෝදජනකයි.
ඩොකර් ගැන මම නිතරම අකමැති දේ:
- මගේ යෙදුම ක්‍රියා කිරීමට නම්, මට සේවාදායකයේ ඩොකර් අවශ්ය වේ. මගේ යෙදුම් jre හෝ nodejs මත ධාවනය වන අතර ඒවා සඳහා පරිසරය දැනටමත් සේවාදායකයේ තිබේ නම් මට මෙය අවශ්ය වන්නේ ඇයි?
- මට මගේ (පුද්ගලික) දේශීයව ගොඩනඟන ලද රූපය දුරස්ථ සේවාදායකයක ධාවනය කිරීමට අවශ්ය නම්, මට මගේම ඩොකර් ගබඩාවක් අවශ්ය වේ, මට කොහේ හරි වැඩ කිරීමට රෙජිස්ට්‍රිය අවශ්ය වන අතර මට https වින්‍යාස කිරීමටද අවශ්ය වේ, මන්ද ඩොකර් ක්ලි ක්‍රියා කරන්නේ https හරහා පමණි. අපොයි... රූපය දේශීයව සුරැකීමට විකල්ප තිබේ
docker saveසහ හුදෙක් scp හරහා රූපය යවන්න ... නමුත් එය බොහෝ ශරීර චලනයන් වේ. ඊට අමතරව, ඔබේම ගබඩාව දිස්වන තුරු එය "කිහිලිකරු" විසඳුමක් ලෙස පෙනේ docker-compose. එය අවශ්ය වන්නේ බහාලුම් ධාවනය කිරීමට පමණි. එච්චරයි. එයාට වෙන දෙයක් කරන්න බෑ.Docker-composeඑහි ගොනු වල අනුවාද සමූහයක් ඇත, එහිම වාක්‍ය ඛණ්ඩය. කොච්චර declarative උනත් මට එයාලගේ documentation කියවන්න ඕන නෑ. මට එය වෙනත් තැනක අවශ්ය නොවනු ඇත.- කණ්ඩායමක වැඩ කරන විට, බොහෝ අය Dockerfile එකක් ලියන්නේ ඉතා වංක ලෙස, එය හැඹිලිගත වන්නේ කෙසේදැයි නොතේරෙන අතර, ඔවුන්ට අවශ්ය සහ අවශ්ය නොවන සියල්ල රූපයට එක් කරන්න, Dockerhub හෝ පුද්ගලික ගබඩාවක නොමැති පින්තූර වලින් උරුම වන්න, සමහරක් සාදන්න
docker-composeදත්ත සමුදායන් සහිත ගොනු සහ කිසිවක් නොනැසී පවතී. ඒ අතරම, සංවර්ධකයින් ආඩම්බරයෙන් ප්‍රකාශ කරන්නේ ඩොකර් සිසිල් බවත්, සෑම දෙයක්ම ඔවුන් සඳහා දේශීයව ක්‍රියා කරන බවත්, පුරප්පාඩුව තුළ HR වැදගත් ලෙස ලියන බවත්ය: "අපි ඩොකර් භාවිතා කරන අතර අපට එවැනි සේවා පළපුරුද්දක් ඇති අපේක්ෂකයෙකු අවශ්ය වේ." - Docker හි ඇති සියල්ල ඉහළ නැංවීම පිළිබඳ සිතුවිලි වලින් මා නිරන්තරයෙන් හොල්මන් කරයි: postgresql, kafka, redis. සෑම දෙයක්ම බහාලුම්වල ක්‍රියා නොකරන බව කණගාටුවට කරුණකි, සෑම දෙයක්ම වින්‍යාස කිරීමට සහ ධාවනය කිරීමට පහසු නොවේ. මෙය තෙවන පාර්ශවීය සංවර්ධකයින් විසින් සහය දක්වනු ලබන අතර, විකුණුම්කරුවන් විසින්ම නොවේ. මාර්ගය වන විට, ප්‍රශ්නය වහාම පැන නගී: වෙළෙන්දන් ඩොකර් හි ඔවුන්ගේ නිෂ්පාදන නඩත්තු කිරීම ගැන කරදර නොවන්න, මෙය ඇයි, සමහර විට ඔවුන් යමක් දන්නවාද?
- බහාලුම් දත්තවල අඛණ්ඩ පැවැත්ම පිළිබඳව ප්‍රශ්නය සැමවිටම පැන නගී. එවිට ඔබ සිතන්නේ, මම ධාරක නාමාවලිය සවි කළ යුතුද නැතහොත් ඩොකර් පරිමාවක් සෑදිය යුතුද නැතහොත් දැනට පවතින දත්ත බහාලුමක් සෑදිය යුතුද යන්නයි.
deprecated? මම ඩිරෙක්ටරියක් සවි කරන්නේ නම්, බහාලුම් දියත් කළ පරිශීලකයාගේ හැඳුනුම්පතට කන්ටේනරයේ ඇති පරිශීලකයාගේ uid සහ gid ගැලපේදැයි මට සහතික විය යුතුය, එසේ නොමැතිනම් කන්ටේනරය විසින් සාදන ලද ගොනු මූල අයිතිවාසිකම් සමඟ නිර්මාණය වේ. මම භාවිතා කරන්නේ නම්volumeඑවිට දත්ත සමහරක් තුළ සරලව නිර්මාණය වනු ඇත/usr/*සහ uid සහ gid සමඟ එකම කතාව පළමු අවස්ථාවේ දී මෙන් වනු ඇත. ඔබ තෙවන පාර්ශවීය සංරචකයක් දියත් කරන්නේ නම්, ඔබ ලියකියවිලි කියවා ප්‍රශ්නයට පිළිතුර සෙවිය යුතුය: “සංරචකය ලිපිගොනු ලියන්නේ කුමන බහාලුම් නාමාවලිවලද?”
වැඩි වෙලාවක් Docker එක්ක tinker කරන්න වෙනවට මම හැමදාම කැමති වුනේ නෑ ආරම්භක අදියරේදී: මම කන්ටේනර් දියත් කරන්නේ කෙසේද, දියත් කළ යුතු පින්තූර මොනවාද, දිගු ඩොකර් විධාන සඳහා අන්වර්ථයන් අඩංගු Makefiles සෑදුවා. මට docker පරිසර පද්ධතිය තුළ වෙනත් මෙවලමක් ඉගෙන ගැනීමට අවශ්ය නොවූ නිසා මම docker-compose වලට වෛර කළා. සහ docker-compose up විශේෂයෙන් ඔවුන් තවමත් එහි හමු වූවා නම් එය මට කරදරයක් විය build ඉදිකිරීම්, ඒ වෙනුවට දැනටමත් එකලස් කරන ලද රූප. මට ඇත්තටම අවශ්ය වූයේ නිෂ්පාදනයක් කාර්යක්ෂමව හා ඉක්මනින් සෑදීම පමණි. නමුත් මට ඩොකර් භාවිතා කරන්නේ කෙසේදැයි සොයා ගැනීමට නොහැකි විය.
Ansible හඳුන්වා දීම
මෑතකදී (මාස තුනකට පෙර), මම DevOps කණ්ඩායමක් සමඟ වැඩ කළෙමි, එහි සෑම සාමාජිකයෙකුම පාහේ ඩොකර් කෙරෙහි නිෂේධාත්මක ආකල්පයක් දැරීය. හේතු සඳහා:
- docker iptables නීති රීති (ඔබට එය daemon.json හි අක්‍රිය කළ හැකි වුවද)
- ඩොකර් දෝෂ සහිත වන අතර අපි එය නිෂ්පාදනයේදී ධාවනය නොකරමු
- docker daemon බිඳ වැටුණහොත්, යටිතල පහසුකම් සහිත සියලුම බහාලුම් ඒ අනුව කඩා වැටේ
- ඩොකර් අවශ්ය නැත
- Ansible සහ virtual machines තියෙනවනම් ඇයි docker
එම රැකියාවේදීම, මම තවත් මෙවලමක් සමඟ දැන හඳුනා ගත්තෙමි - ඇන්සිබල්. මම ඒ ගැන වරක් අසා ඇත, නමුත් මම මගේම සෙල්ලම් පොත් ලිවීමට උත්සාහ කළේ නැත. දැන් මම මගේ කාර්යයන් ලිවීමට පටන් ගත් අතර පසුව මගේ දැක්ම සම්පූර්ණයෙන්ම වෙනස් විය! මට වැටහුණු නිසා: ඇන්සිබල් සතුව එකම ඩොකර් බහාලුම්, රූප ගොඩනැගීම, ජාල යනාදිය ධාවනය කිරීම සඳහා මොඩියුල ඇති අතර බහාලුම් දේශීයව පමණක් නොව දුරස්ථ සේවාදායකයන් මතද ධාවනය කළ හැකිය! මගේ සතුටට සීමාවක් නැත - මම සාමාන්‍ය මෙවලමක් සොයාගෙන මගේ Makefile සහ docker-compose ගොනු ඉවතට විසි කළෙමි, ඒවා yaml කාර්යයන් සමඟ ප්‍රතිස්ථාපනය විය. වැනි කන්ස්ට්‍රක්ට් භාවිතා කර කේතය අඩු කර ඇත loop, when, ආදිය
දත්ත සමුදායන් වැනි තෙවන පාර්ශ්ව සංරචක ධාවනය සඳහා ඩොකර්
මම මෑතකදී ssh උමං ගැන දැන හඳුනා ගත්තෙමි. දුරස්ථ සේවාදායකයක වරාය දේශීය වරායකට “ඉදිරියට” යැවීම ඉතා පහසු බව පෙනී ගියේය. දුරස්ථ සේවාදායකය වලාකුළේ ඇති යන්ත්‍රයක් හෝ VirtualBox තුළ ක්‍රියාත්මක වන අතථ්‍ය යන්ත්‍රයක් විය හැකිය. මගේ සගයාට හෝ මට දත්ත සමුදායක් (හෝ වෙනත් තෙවන පාර්ශවීය සංරචකයක්) අවශ්ය නම්, අපට මෙම සංරචකය සමඟ සේවාදායකය ආරම්භ කර සේවාදායකය අවශ්ය නොවන විට එය ක්‍රියා විරහිත කළ හැකිය. පෝට් ෆෝවර්ඩ් කිරීම ඩොකර් කන්ටේනරයක ක්‍රියාත්මක වන දත්ත සමුදායක් හා සමාන බලපෑමක් ලබා දෙයි.
මෙම විධානය මගේ දේශීය වරාය postgresql ධාවනය වන දුරස්ථ සේවාදායකයකට යොමු කරයි:
ssh -L 9000:localhost:5432 [විද්‍යුත් ආරක්‍ෂිත]
දුරස්ථ සේවාදායකයක් භාවිතා කිරීම කණ්ඩායම් සංවර්ධනය සමඟ ගැටළුව විසඳයි. එවැනි සේවාදායකයක් එකවර සංවර්ධකයින් කිහිප දෙනෙකුට භාවිතා කළ හැකිය; ඔවුන්ට postgresql වින්‍යාස කිරීමට, ඩොකර් සහ අනෙකුත් සංකීර්ණතා තේරුම් ගැනීමට අවශ්ය නොවේ. දුරස්ථ සේවාදායකයක, නිශ්චිත අනුවාදයක් ස්ථාපනය කිරීමට අපහසු නම්, ඔබට එකම දත්ත ගබඩාව ඩොකර් තුළම ස්ථාපනය කළ හැකිය. සංවර්ධකයින්ට අවශ්ය වන්නේ ssh ප්‍රවේශය සැපයීමයි!
SSH උමං යනු සාමාන්‍ය VPN එකක සීමිත ක්‍රියාකාරීත්වයක් බව මම මෑතකදී කියෙව්වා! ඔබට OpenVPN හෝ වෙනත් VPN ක්‍රියාත්මක කිරීම් ස්ථාපනය කර යටිතල පහසුකම් සකසා එය සංවර්ධකයින්ට භාවිතය සඳහා ලබා දිය හැක. මෙය ඉතා සිසිල් ය!
වාසනාවකට මෙන්, AWS, GoogleCloud සහ වෙනත් අය ඔබට වසරක් නොමිලේ භාවිතා කරයි, එබැවින් ඒවා භාවිතා කරන්න! භාවිතයේ නොමැති විට ඔබ ඒවා නිවා දමන්නේ නම් ඒවා ලාභදායී වේ. මට gcloud වැනි දුරස්ථ සේවාදායකයක් අවශ්ය වන්නේ මන්දැයි මම නිතරම කල්පනා කළෙමි, මට ඒවා හමු වූ බව පෙනේ.
දේශීය අතථ්‍ය යන්ත්‍රයක් ලෙස, ඔබට ඩොකර් බහාලුම්වල ක්‍රියාකාරීව භාවිතා කරන ඇල්පයින් එකම භාවිතා කළ හැකිය. හොඳයි, හෝ යන්ත්‍රය වේගවත් කිරීම සඳහා වෙනත් සැහැල්ලු බෙදාහැරීම්.
පහළම පේළිය: ඔබට දුරස්ථ සේවාදායකයන් මත හෝ අථත්‍ය පෙට්ටිය තුළ දත්ත සමුදායන් සහ වෙනත් යටිතල පහසුකම් හොඳ දේවල් ධාවනය කළ හැකිය. මෙම අරමුණු සඳහා මට ඩොකර් අවශ්ය නොවේ.
ඩොකර් පින්තූර සහ බෙදා හැරීම ගැන ටිකක්
මම දැනටමත් ලියා ඇත ඩොකර් පින්තූර භාවිතා කිරීම කිසිදු සහතිකයක් ලබා නොදෙන බව මට පැවසීමට අවශ්ය විය. ඩොකර් රූප අවශ්ය වන්නේ ඩොකර් කන්ටේනරයක් සෑදීමට පමණි. ඔබ ඩොකර් රූපයකට යාවත්කාලීන කරන්නේ නම්, ඔබ ඩොකර් බහාලුම් භාවිතා කිරීමට උත්ශ්‍රේණි කරන අතර ඔබ ඒවා පමණක් භාවිතා කරයි.
මෘදුකාංග සංවර්ධකයින් ඔවුන්ගේ නිෂ්පාදන ඩොකර් රූපයකින් පමණක් ගෙන යන තැනක් ඔබ කොතැනක හෝ දැක තිබේද?
බොහෝ නිෂ්පාදනවල ප්‍රතිඵලය වන්නේ නිශ්චිත වේදිකාවක් සඳහා ද්විමය ගොනු වේ; ඒවා සරලවම ඩොකර් රූපයට එකතු කරනු ලැබේ, එය අපේක්ෂිත වේදිකාවෙන් උරුම වේ. dockerhub හි මෙතරම් සමාන පින්තූර ඇත්තේ මන්දැයි ඔබ කවදා හෝ කල්පනා කර තිබේද? උදාහරණයක් ලෙස nginx ඇතුළු කරන්න, ඔබට විවිධ පුද්ගලයින්ගෙන් පින්තූර 100500 ක් පෙනෙනු ඇත. මෙම පුද්ගලයින් nginx විසින්ම සංවර්ධනය කර නැත, ඔවුන් හුදෙක් ඔවුන්ගේ ඩොකර් රූපයට නිල nginx එකතු කර බහාලුම් දියත් කිරීමේ පහසුව සඳහා ඔවුන්ගේම වින්‍යාසයන් සමඟ එය පදම් කර ඇත.
සාමාන්යයෙන්, ඔබට එය tgz හි ගබඩා කළ හැකිය, යමෙකුට එය ඩොකර් තුළ ධාවනය කිරීමට අවශ්ය නම්, ඔවුන්ට ඩොකර්ෆයිල් වෙත tgz එකතු කිරීමට ඉඩ දෙන්න, අවශ්ය පරිසරයෙන් උරුම වී tgz හි යෙදුම වෙනස් නොකරන අමතර බනිස් සෑදීමට ඉඩ දෙන්න. ඩොකර් රූපයක් නිර්මාණය කරන ඕනෑම අයෙකු tgz යනු කුමක්ද සහ ඔහුට වැඩ කිරීමට අවශ්ය දේ දැන ගනු ඇත. මම docker එක පාවිච්චි කරන්නේ මෙහෙමයි
පහළ පේළිය: මට ඩොකර් රෙජිස්ට්‍රි අවශ්ය නැත, මම යම් ආකාරයක S3 හෝ ගූගල් ඩ්‍රයිව්/ඩ්‍රොප්බොක්ස් වැනි ගොනු ගබඩාවක් භාවිතා කරමි
CI හි ඩොකර්
මම වැඩ කරපු සියලුම සමාගම් සමානයි. ඒවා සාමාන්යයෙන් සිල්ලර බඩු වේ. එනම්, ඔවුන්ට එක් යෙදුමක්, එක් තාක්‍ෂණ තොගයක් ඇත (හොඳයි, සමහර විට යුවලක් හෝ ක්‍රමලේඛන භාෂා තුනක්).
මෙම සමාගම් CI ක්‍රියාවලිය ක්‍රියාත්මක වන ඔවුන්ගේ සේවාදායකයන්හි ඩොකර් භාවිතා කරයි. ප්‍රශ්නය: ඔබේ සේවාදායකයේ ඩොකර් කන්ටේනරයක ව්‍යාපෘති තැනීමට ඔබට අවශ්ය වන්නේ ඇයි? ගොඩනැගීම සඳහා පරිසරයක් පමණක් සකස් නොකරන්නේ මන්ද, උදාහරණයක් ලෙස, ගොඩනැගීම සිදුවන සේවාදායකයට අවශ්ය nodejs, php, jdk, copy ssh යතුරු යනාදිය ස්ථාපනය කරන Ansible playbook එකක් ලියන්න.
දැන් මට තේරෙනවා මේක මගේ පාදයට වෙඩි තියන්නේ කියලා, මොකද ඩොකර් හුදකලා වීමෙන් කිසිම ලාභයක් ගෙන එන්නේ නැහැ. ඩොකර් හි CI සමඟ මා මුහුණ දුන් ගැටළු:
- නැවතත් ඔබට ගොඩනැගීමට ඩොකර් රූපයක් අවශ්ය වේ. ඔබට රූපයක් සෙවීමට හෝ ඔබේම dockerfile ලිවීමට අවශ්ය වේ.
- 90%ක් ඔබට ssh යතුරු කිහිපයක් යොමු කිරීමට අවශ්ය වන අතර, ඔබට ඩොකර් රූපයට ලිවීමට අවශ්ය නොවන රහස් දත්ත.
- කන්ටේනරය නිර්මාණය වී මිය යයි, ඒ සමඟම සියලුම හැඹිලි නැති වී යයි. මීළඟ ගොඩනැගීම මඟින් සියලුම ව්‍යාපෘති පරායත්තතා නැවත බාගත කරනු ඇත, එය කාලය ගතවන සහ අකාර්යක්ෂම වන අතර කාලය මුදල් වේ.
සංවර්ධකයින් ඩොකර් බහාලුම්වල ව්‍යාපෘති ගොඩනඟන්නේ නැත (මම වරක් එවැනි රසිකයෙක්, ඇත්ත වශයෙන්ම, පසුගිය xD වලදී මට මා ගැනම කණගාටුයි). java වලදී සංස්කරණ කිහිපයක් තිබිය හැකි අතර ඒවා එක විධානයකින් ඔබට දැන් අවශ්ය ආකාරයට වෙනස් කළ හැකිය. nodejs වලත් එහෙමයි, nvm තියෙනවා.
නිගමනය
ඩොකර් ඉතා බලවත් හා නම්‍යශීලී මෙවලමක් බව මම විශ්වාස කරමි, මෙය එහි අඩුපාඩුවයි (අමුතුයි, ඔව්). එහි ආධාරයෙන්, සමාගම්වලට පහසුවෙන් එය සම්බන්ධ කර ගත හැකි අතර අවශ්ය හා අවශ්ය නොවන ස්ථානවල එය භාවිතා කළ හැකිය. සංවර්ධකයින් ඔවුන්ගේ බහාලුම්, ඔවුන්ගේ සමහර පරිසරයන් දියත් කරයි, එවිට ඒ සියල්ල CI සහ නිෂ්පාදනයට සුමටව ගලා යයි. DevOps කණ්ඩායම මෙම බහාලුම් ධාවනය කිරීමට යම් ආකාරයක කේතයක් ලියයි.
ඩොකර් පමණක් භාවිතා කරන්න වඩාත් ම මෑත ඔබේ වැඩ ප්‍රවාහයේ අදියර, ආරම්භයේදී එය ව්‍යාපෘතියට ඇදගෙන නොයන්න. එය ඔබේ ව්‍යාපාරික ගැටලු විසඳන්නේ නැත. ඔහු ගැටළු වෙනත් මට්ටමකට ගෙන ගොස් ඔහුගේම විසඳුම් ලබා දෙනු ඇත, ඔබ ද්විත්ව වැඩ කරනු ඇත.
ඩොකර් අවශ්ය විට: දී ඇති ක්‍රියාවලියක් ප්‍රශස්ත කිරීමට ඩොකර් ඉතා හොඳ බව මම නිගමනය කළෙමි, නමුත් මූලික ක්‍රියාකාරීත්වය ගොඩනැගීමට නොවේ
ඔබ තවමත් ඩොකර් භාවිතා කිරීමට තීරණය කරන්නේ නම්, එවිට:
- අතිශයින්ම පරෙස්සම් වන්න
- ඩොකර් භාවිතා කිරීමට සංවර්ධකයින්ට බල නොකරන්න
- එහි භාවිතය එක තැනක ස්ථානගත කරන්න, සියලුම Dockfile සහ docker-compose repositories හරහා එය පැතිර නොයන්න
PS:
- මට මෑතකදී හමු විය සහ ඔවුන් පවසන්නේ එය ඇන්සිබල් සමඟ ඉතා හොඳින් ක්‍රියා කරන අතර රූප ගොඩනැගීමේ ක්‍රියාවලිය ඒකාබද්ධ කිරීමට ඔබට ඉඩ සලසයි (ඩොකර් රූපය ඇතුළුව)
කියවීමට ස්තූතියි, ඔබේ කටයුතු සහ ඵලදායී වැඩ කරන දිනවල විනිවිද පෙනෙන තීරණ ගැනීමට මම ඔබට ප්රාර්ථනා කරමි!
මූලාශ්රය: www.habr.com