Docker-in-Docker යනු බහාලුම් රූප තැනීම සඳහා කන්ටේනරය තුළම ක්‍රියාත්මක වන අථත්‍ය ඩොකර් ඩීමන් පරිසරයකි. Docker-in-Docker නිර්මාණය කිරීමේ ප්‍රධාන අරමුණ වූයේ ඩොකර්ව දියුණු කිරීමට උපකාර කිරීමයි. Jenkins CI ධාවනය කිරීමට බොහෝ අය එය භාවිතා කරයි. මෙය මුලින් සාමාන්‍ය දෙයක් ලෙස පෙනුනද, පසුව Jenkins CI කන්ටේනරයක Docker ස්ථාපනය කිරීමෙන් වළක්වා ගත හැකි ගැටළු මතු වේ. මෙය කරන්නේ කෙසේදැයි මෙම ලිපිය ඔබට කියයි. විස්තර නොමැතිව අවසාන විසඳුම ගැන ඔබ උනන්දු වන්නේ නම්, "ගැටළුව විසඳීම" යන ලිපියේ අවසාන කොටස කියවන්න.
Docker-in-Docker: "හොඳයි"
මීට අවුරුදු දෙකකටත් වඩා කලින් මම Docker එකට දැම්මා - වරප්රසාද සහ ලිවීය . ඉලක්කය වූයේ මූලික කණ්ඩායමට ඩොකර් වේගයෙන් සංවර්ධනය කිරීමට උපකාර කිරීමයි. Docker-in-Docker ට පෙර, සාමාන්‍ය සංවර්ධන චක්රය මෙසේ දිස් විය:
- හැකී හැක්;
- ගොඩනඟන්න;
- ධාවනය වන ඩොකර් ඩීමන් නැවැත්වීම;
- නව ඩොකර් ඩීමන් දියත් කිරීම;
- පරීක්ෂා කිරීම;
- චක්රය නැවත කරන්න.
ඔබට අලංකාර, ප්‍රතිනිෂ්පාදනය කළ හැකි එකලස් කිරීමක් (එනම්, බහාලුමක් තුළ) කිරීමට අවශ්‍ය නම්, එය වඩාත් සංකීර්ණ විය:
- හැකී හැක්;
- Docker හි ක්‍රියාකාරී අනුවාදයක් ක්‍රියාත්මක වන බවට වග බලා ගන්න;
- පැරණි ඩොකර් සමඟ නව ඩොකර් සාදන්න;
- නවත්වන්න ඩොකර් ඩීමන්;
- නව ඩොකර් ඩීමන් එකක් ආරම්භ කරන්න;
- පරීක්ෂණය;
- නව ඩොකර් ඩීමන් නවත්වන්න;
- නැවත නැවත.
Docker-in-Docker පැමිණීමත් සමඟ, ක්රියාවලිය සරල වී ඇත:
- හැකී හැක්;
- එකලස් කිරීම + එක් අදියරක දියත් කිරීම;
- චක්රය නැවත කරන්න.
මේ ක්‍රමය ගොඩක් හොඳයි නේද?
Docker-in-Docker: "නරක"
කෙසේ වෙතත්, ජනප්‍රිය විශ්වාසයට පටහැනිව, Docker-in-Docker යනු 100% තරු, පෝනියන් සහ යුනිකෝන් නොවේ. මම අදහස් කරන්නේ සංවර්ධකයෙකු දැන සිටිය යුතු ගැටළු කිහිපයක් ඇති බවයි.
ඒවායින් එකක් AppArmor සහ SELinux වැනි LSM (ලිනක්ස් ආරක්ෂක මොඩියුල) ගැන සැලකිලිමත් වේ: බහාලුමක් ධාවනය කරන විට, "අභ්‍යන්තර ඩොකර්" "බාහිර ඩොකර්" සමඟ ගැටෙන හෝ ව්‍යාකූල කරන ආරක්ෂක පැතිකඩ යෙදීමට උත්සාහ කළ හැකිය. වරප්‍රසාදිත ධජයේ මුල් ක්‍රියාත්මක කිරීම ඒකාබද්ධ කිරීමට උත්සාහ කිරීමේදී විසඳීමට ඇති දුෂ්කරම ගැටලුව මෙයයි. මගේ වෙනස්කම් ක්‍රියාත්මක වූ අතර සියලුම පරීක්ෂණ මගේ ඩේබියන් යන්ත්‍රය සහ උබුන්ටු පරීක්ෂණ වීඑම් මත සමත් වනු ඇත, නමුත් ඒවා මයිකල් ක්‍රොස්බිගේ යන්ත්‍රය මත කඩා වැටී දැවී යනු ඇත (මා මතක ඇති පරිදි ඔහුට ෆෙඩෝරා තිබුණි). ගැටලුවට නිශ්චිත හේතුව මට මතක නැත, නමුත් එය එසේ වන්නට ඇත්තේ මයික් SELINUX=enforce (මම AppArmor භාවිතා කළ) සමඟ වැඩ කරන බුද්ධිමත් පුද්ගලයෙක් නිසා සහ මගේ වෙනස්කම් SELinux පැතිකඩ ගණන් නොගත් නිසා විය හැක.
Docker-in-Docker: "නපුරු"
දෙවන ගැටළුව වන්නේ ඩොකර් ගබඩා ධාවක සමඟ ය. ඔබ Docker-in-Docker ධාවනය කරන විට, බාහිර Docker ක්‍රියාත්මක වන්නේ සාමාන්‍ය ගොනු පද්ධතියක් (EXT4, BTRFS, හෝ ඔබ සතුව ඇති ඕනෑම දෙයක්) මත වන අතර අභ්‍යන්තර Docker ක්‍රියා කරන්නේ කොපි-ඔන්-රයිට් පද්ධතියක් (AUFS, BTRFS, Device Mapper) මත ය. , etc.). , බාහිර ඩොකර් භාවිතා කිරීමට වින්‍යාස කර ඇති දේ මත පදනම්ව). මෙය වැඩ නොකරන බොහෝ සංයෝජන නිර්මාණය කරයි. උදාහරණයක් ලෙස, ඔබට AUFS මත AUFS ධාවනය කිරීමට නොහැකි වනු ඇත.
ඔබ BTRFS මත BTRFS ධාවනය කරන්නේ නම්, එය මුලින්ම ක්‍රියා කළ යුතුය, නමුත් කැදැලි උප වෙළුම් ඇති විට, මව් උප වෙළුම මකා දැමීම අසාර්ථක වනු ඇත. උපාංග සිතියම් මොඩියුලයට නාම අවකාශයක් නොමැත, එබැවින් ඩොකර් අවස්ථා කිහිපයක් එකම යන්ත්‍රයක එය ක්‍රියාත්මක කරන්නේ නම්, ඔවුන් සියල්ලන්ටම එකිනෙක සහ බහාලුම් උපස්ථ උපාංග මත ඇති පින්තූර බැලීමට (සහ බලපෑම් කිරීමට) හැකි වනු ඇත. මේක නරකයි.
මෙම ගැටළු බොහොමයක් විසඳීමට විසඳුම් තිබේ. උදාහරණයක් ලෙස, ඔබට අභ්‍යන්තර ඩොකර් තුළ AUFS භාවිතා කිරීමට අවශ්‍ය නම්, /var/lib/docker ෆෝල්ඩරය පරිමාවක් බවට පත් කරන්න, එවිට ඔබ හොඳින් වනු ඇත. Docker විසින් Device Mapper ඉලක්ක නාමවලට මූලික නාම අවකාශ කිහිපයක් එක් කර ඇති අතර එමඟින් එකම යන්ත්‍රයක බහු ඩොකර් ඇමතුම් ක්‍රියාත්මක වන්නේ නම්, ඒවා එකිනෙක නොපැමිණේ.
කෙසේ වෙතත්, මේවායින් දැකිය හැකි පරිදි එවැනි සැකසුම කිසිසේත් සරල නැත GitHub හි ඩින්ඩ් ගබඩාවේ.
Docker-in-Docker: එය නරක අතට හැරේ
ගොඩනැගීමේ හැඹිලිය ගැන කුමක් කිව හැකිද? මෙය ද තරමක් අපහසු විය හැකිය. මිනිසුන් බොහෝ විට මගෙන් අසන්නේ “මම Docker-in-Docker ධාවනය කරන්නේ නම්, සියල්ල නැවත මගේ අභ්‍යන්තර Docker වෙතට ඇද දැමීම වෙනුවට මගේ සත්කාරකයේ සත්කාරකත්වය දක්වන රූප භාවිතා කරන්නේ කෙසේද”?
සමහර ව්‍යවසායකයින් /var/lib/docker ධාරකයේ සිට Docker-in-Docker බහාලුමකට බැඳීමට උත්සාහ කර ඇත. සමහර විට ඔවුන් බහු බහාලුම් සමඟ /var/lib/docker බෙදා ගනී.
ඔබට ඔබේ දත්ත දූෂිත කිරීමට අවශ්‍යද? මක්නිසාද යත් මෙය හරියටම ඔබගේ දත්ත වලට හානි කරන බැවිනි!
ඩොකර් ඩීමන් පැහැදිලිවම නිර්මාණය කර ඇත්තේ /var/lib/docker වෙත සුවිශේෂී ප්‍රවේශයක් ලබා ගැනීමටය. මෙම ෆෝල්ඩරයේ ඇති ඩොකර් ගොනු කිසිවක් "ස්පර්ශ කිරීම, සිදුරු කිරීම හෝ ප්‍රොඩ්" නොකළ යුතුය.
මෙය එසේ වන්නේ ඇයි? මක්නිසාද යත් මෙය dotCloud සංවර්ධනය කිරීමේදී ඉගෙන ගත් දුෂ්කරම පාඩමක ප්‍රති result ලයකි. ඩොට්ක්ලවුඩ් බහාලුම් එන්ජිම ක්‍රියාත්මක වූයේ එකවර /var/lib/dotcloud වෙත ප්‍රවේශ වන බහු ක්‍රියාවලි ඇති කරමිනි. පරමාණුක ගොනු ප්‍රතිස්ථාපනය (ස්ථානගත සංස්කරණය වෙනුවට), උපදේශන සහ අනිවාර්ය අගුලු සහිත ගම්මිරිස් කිරීමේ කේතය සහ SQLite සහ BDB වැනි ආරක්ෂිත පද්ධති සමඟ වෙනත් අත්හදා බැලීම් වැනි කපටි උපක්‍රම සැමවිටම ක්‍රියාත්මක නොවීය. අපි අවසානයේ Docker බවට පත් වූ අපගේ බහාලුම් එන්ජිම ප්‍රතිනිර්මාණය කරන විට, විශාල සැලසුම් තීරණයක් වූයේ සියලු සමගාමී විකාර ඉවත් කිරීම සඳහා සියලුම බහාලුම් මෙහෙයුම් එකම ඩීමන් එකක් යටතේ ඒකාබද්ධ කිරීමයි.
මාව වැරදියට තේරුම් ගන්න එපා: බහු ක්‍රියාවලි සහ නවීන සමාන්තර පාලනයක් ඇතුළත් හොඳ, විශ්වාසදායක සහ වේගවත් දෙයක් කිරීමට සම්පූර්ණයෙන්ම හැකි ය. නමුත් අපි සිතන්නේ Docker එකම ක්‍රීඩකයා ලෙස භාවිතා කර කේතය ලිවීම සහ නඩත්තු කිරීම වඩාත් සරල සහ පහසු බවයි.
මෙයින් අදහස් කරන්නේ ඔබ /var/lib/docker නාමාවලිය බහු Docker අවස්ථා අතර බෙදා ගන්නේ නම්, ඔබට ගැටළු ඇති වේ. ඇත්ත වශයෙන්ම, මෙය විශේෂයෙන් පරීක්ෂා කිරීමේ මුල් අදියරේදී වැඩ කළ හැකිය. "අහන්න අම්මේ, මට උබුන්ටු ඩොකර් කෙනෙක් විදියට දුවන්න පුළුවන්!" නමුත් වඩා සංකීර්ණ දෙයක් උත්සාහ කරන්න, එනම් එකම රූපය වෙනස් අවස්ථා දෙකකින් ඇද ගැනීම වැනි, එවිට ඔබට ලෝකය දැවෙන බව පෙනෙනු ඇත.
මෙයින් අදහස් කරන්නේ ඔබේ CI පද්ධතිය ගොඩනැගීම් සහ නැවත ගොඩනැංවීම් සිදු කරන්නේ නම්, ඔබ ඔබේ Docker-in-Docker කන්ටේනරය නැවත ආරම්භ කරන සෑම අවස්ථාවකම, ඔබ එහි හැඹිලිය තුළට nuke වැටීමේ අවදානමක් ඇත. මෙය කිසිසේත් සිසිල් නොවේ!
දෝෂ නිරාකරණය කිරීම
අපි අඩියක් පස්සට යමු. ඔබට ඇත්තටම Docker-in-Docker අවශ්‍යද නැතහොත් ඔබට අවශ්‍ය වන්නේ Docker ධාවනය කිරීමට සහ එම CI පද්ධතියම කන්ටේනරයක පවතින අතරතුර ඔබේ CI පද්ධතියෙන් බහාලුම් සහ රූප තැනීමට සහ ධාවනය කිරීමට පමණක්ද?
බොහෝ දෙනෙකුට අවසාන විකල්පය අවශ්‍ය බව මම ඔට්ටු අල්ලමි, එයින් අදහස් කරන්නේ ජෙන්කින්ස් වැනි CI පද්ධතියක් බහාලුම් ධාවනය කිරීමට ඔවුන්ට අවශ්‍ය බවයි. මෙය කිරීමට ඇති පහසුම ක්‍රමය නම් ඔබේ CI බහාලුම් තුළට ඩොකර් සොකට් එකක් ඇතුළු කර එය -v ධජය සමඟ සම්බන්ධ කිරීමයි.
සරලව කිවහොත්, ඔබ ඔබේ CI කන්ටේනරය (ජෙන්කින්ස් හෝ වෙනත්) ධාවනය කරන විට, Docker-in-Docker සමඟින් යමක් හැක් කරනවා වෙනුවට, එය රේඛාවෙන් ආරම්භ කරන්න:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...මෙම බහාලුමට දැන් Docker සොකට් වෙත ප්‍රවේශය ඇති අතර එම නිසා බහාලුම් ධාවනය කිරීමට හැකි වේ. හැර "ළමා" බහාලුම් ධාවනය කිරීම වෙනුවට, එය "සහෝදර" බහාලුම් දියත් කරනු ඇත.
නිල ඩොකර් රූපය භාවිතයෙන් මෙය උත්සාහ කරන්න (ඩොකර් ද්විමය අඩංගු):
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerඑය Docker-in-Docker මෙන් පෙනෙන අතර ක්‍රියා කරයි, නමුත් එය Docker-in-Docker නොවේ: මෙම බහාලුම අමතර බහාලුම් සාදන විට, ඒවා ඉහළ මට්ටමේ ඩොකර් තුළ සාදනු ඇත. ඔබ කැදැල්ලෙහි අතුරු ආබාධ අත්විඳිය නොහැකි අතර එකලස් හැඹිලිය ඇමතුම් කිහිපයක් හරහා බෙදා ගනු ඇත.
සටහන: මෙම ලිපියේ පෙර අනුවාද ධාරකයේ සිට බහාලුම් වෙත Docker ද්විමය සම්බන්ධ කිරීමට උපදෙස් දී ඇත. Docker එන්ජිම තවදුරටත් ස්ථිතික හෝ ආසන්න ස්ථිතික පුස්තකාල ආවරණය නොකරන බැවින් මෙය දැන් විශ්වාස කළ නොහැකි වී ඇත.
එබැවින්, ඔබට Jenkins CI වෙතින් Docker භාවිතා කිරීමට අවශ්‍ය නම්, ඔබට විකල්ප 2ක් ඇත:
මූලික රූප ඇසුරුම් පද්ධතිය භාවිතයෙන් Docker CLI ස්ථාපනය කිරීම (එනම් ඔබේ රූපය Debian මත පදනම් වේ නම්, .deb පැකේජ භාවිතා කරන්න), Docker API භාවිතයෙන්.
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com