ProHoster > බ්ලොග් > පරිපාලනය > ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක

ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක

වෙනදාට වඩා ප්‍රමාද වීම හොඳය. එසේත් නැතිනම් යෙදුම් රූප තැනීමට සාමාන්‍ය ඩොකර්ෆයිල් සඳහා සහය නොදැක්වීමෙන් අප බරපතල වැරැද්දක් කර ඇත්තේ කෙසේද?

ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක

අපි කතා කරමු werf — GitOps උපයෝගීතාව ඕනෑම CI/CD පද්ධතියක් සමඟ ඒකාබද්ධ වන අතර සම්පූර්ණ යෙදුම් ජීවන චක්‍රය කළමනාකරණය කිරීම සපයයි, ඉඩ දෙයි:

  • පින්තූර එකතු කර ප්‍රකාශනය කරන්න,
  • Kubernetes හි යෙදුම් යෙදවීම,
  • විශේෂ ප්‍රතිපත්ති භාවිතයෙන් භාවිත නොකළ පින්තූර මකන්න.


ව්‍යාපෘතියේ දර්ශනය වන්නේ DevOps ඉංජිනේරුවන්ට යෙදුම් පාලනය කරන තනි ඒකාබද්ධ පද්ධතියකට පහත් මට්ටමේ මෙවලම් එකතු කිරීමයි. හැකි නම්, පවතින උපයෝගිතා (Helm සහ Docker වැනි) භාවිතා කළ යුතුය. ගැටලුවකට විසඳුමක් නොමැති නම්, අපට මේ සඳහා අවශ්‍ය සියල්ල නිර්මාණය කර සහාය විය හැකිය.

පසුබිම: ඔබේම රූප එකතු කරන්නා

werf හි රූප එකතු කරන්නා සමඟ සිදු වූයේ මෙයයි: සුපුරුදු Dockerfile අපට ප්‍රමාණවත් නොවීය. ඔබ ව්‍යාපෘතියේ ඉතිහාසය දෙස ඉක්මනින් බැලුවහොත්, මෙම ගැටළුව දැනටමත් werf හි පළමු අනුවාද වල දර්ශනය විය (එවිට තවමත් dapp ලෙස හැඳින්වේ).

Docker images බවට යෙදුම් තැනීම සඳහා මෙවලමක් නිර්මාණය කරන අතරතුර, Dockerfile ඉතා නිශ්චිත කාර්යයන් සඳහා අපට සුදුසු නොවන බව අපට ඉක්මනින් වැටහුණි:

  1. පහත සම්මත යෝජනා ක්‍රමයට අනුව සාමාන්‍ය කුඩා වෙබ් යෙදුම් තැනීමේ අවශ්‍යතාවය:
    • පද්ධතිය පුරා යෙදුම් පරායත්තතා ස්ථාපනය කරන්න,
    • යෙදුම් පරායත්ත පුස්තකාල මිටියක් ස්ථාපනය කරන්න,
    • වත්කම් එකතු කරන්න,
    • සහ වඩාත්ම වැදගත් දෙය නම්, රූපයේ කේතය ඉක්මනින් හා කාර්යක්ෂමව යාවත්කාලීන කරන්න.
  2. ව්‍යාපෘති ගොනු සඳහා වෙනස්කම් සිදු කරන විට, තනන්නා විසින් වෙනස් කරන ලද ගොනුවලට පැච් එකක් යෙදීමෙන් ඉක්මනින් නව ස්ථරයක් සෑදිය යුතුය.
  3. ඇතැම් ගොනු වෙනස් වී ඇත්නම්, ඊට අනුරූප පරායත්ත අදියර නැවත ගොඩනැංවීම අවශ්ය වේ.

අද අපේ එකතු කරන්නාට වෙනත් බොහෝ හැකියාවන් ඇත, නමුත් මේවා ආරම්භක ආශාවන් සහ පෙළඹවීම් විය.

පොදුවේ ගත් කල, දෙවරක් නොසිතා, අපි භාවිතා කළ ක්‍රමලේඛන භාෂාවෙන් අපි සන්නද්ධ විය (පහත බලන්න) සහ ක්‍රියාත්මක කිරීමට පාරට බැස්සා තමන්ගේම DSL! අරමුණු වලට අනුකූලව, එකලස් කිරීමේ ක්‍රියාවලිය අදියර වශයෙන් විස්තර කිරීමට සහ ගොනු මත මෙම අදියරවල පරායත්තතා තීරණය කිරීමට අදහස් කරන ලදී. සහ එය සම්පූර්ණ කළා තමන්ගේම එකතු කරන්නා, DSL අවසාන ඉලක්කය බවට පත් කළ - එකලස් කරන ලද රූපයක්. මුලදී DSL එක Ruby වල තිබුනා, නමුත් Golang වෙත සංක්රමණය — අපගේ එකතුකරන්නාගේ වින්‍යාසය YAML ගොනුවක විස්තර කිරීමට පටන් ගත්තේය.

ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක
Ruby හි ​​dapp සඳහා පැරණි වින්‍යාසය

ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක
YAML මත werf සඳහා වත්මන් වින්‍යාසය

කාලයත් සමඟ එකතුකරන්නාගේ යාන්ත්‍රණය ද වෙනස් විය. මුලදී, අපි අපගේ වින්‍යාසයෙන් පියාසර කරන විට තාවකාලික ඩොකර්ෆයිල් එකක් ජනනය කළෙමු, පසුව අපි තාවකාලික බහාලුම්වල එකලස් කිරීමේ උපදෙස් ක්‍රියාත්මක කර කැපවීමට පටන් ගත්තෙමු.

NB: මේ මොහොතේ, අපගේ එකතු කරන්නා, එහිම වින්‍යාසය සමඟ ක්‍රියා කරයි (YAML හි) සහ ස්ටැපල් එකතු කරන්නා ලෙස හැඳින්වේ, දැනටමත් තරමක් ප්‍රබල මෙවලමක් දක්වා වර්ධනය වී ඇත. එහි සවිස්තරාත්මක විස්තරය වෙනම ලිපි සඳහා සුදුසු වන අතර මූලික තොරතුරු සොයා ගත හැක ලියකියවිලි.

ගැටලුව පිළිබඳ දැනුවත්භාවය

නමුත් අපි එක වැරැද්දක් කර ඇති බව අපට වැටහුණා, වහාම නොවේ: අපි හැකියාව එකතු කළේ නැත සම්මත Dockerfile හරහා පින්තූර සාදන්න සහ ඒවා එකම අන්තයේ සිට අවසානය දක්වා යෙදුම් කළමනාකරණ යටිතල ව්‍යුහයට ඒකාබද්ධ කරන්න (එනම් පින්තූර එකතු කිරීම, ඒවා යෙදවීම සහ පිරිසිදු කිරීම). Kubernetes හි යෙදවීම සඳහා මෙවලමක් සෑදීමට සහ Dockerfile සහාය ක්‍රියාත්මක නොකිරීමට හැකි වන්නේ කෙසේද, i.e. බොහෝ ව්‍යාපෘති සඳහා රූප විස්තර කිරීමට සම්මත ක්‍රමය?..

මෙම ප්රශ්නයට පිළිතුරු දෙනවා වෙනුවට අපි විසඳුමක් ඉදිරිපත් කරමු. ඔබට දැනටමත් Dockerfile (හෝ Dockerfiles කට්ටලයක්) තිබේ නම් සහ werf භාවිතා කිරීමට අවශ්‍ය නම් කුමක් කළ යුතුද?

NB: මාර්ගය වන විට, ඔබට werf භාවිතා කිරීමට අවශ්‍ය වන්නේ ඇයි? ප්රධාන ලක්ෂණ පහත දක්වා ඇත:

  • රූප පිරිසිදු කිරීම ඇතුළුව සම්පූර්ණ යෙදුම් කළමනාකරණ චක්රය;
  • එක් වින්‍යාසයකින් එකවර පින්තූර කිහිපයක එකලස් කිරීම කළමනාකරණය කිරීමේ හැකියාව;
  • Helm-අනුකූල ප්‍රස්ථාර සඳහා වැඩි දියුණු කළ යෙදවීමේ ක්‍රියාවලිය.

ඒවායේ වඩාත් සම්පූර්ණ ලැයිස්තුවක් සොයාගත හැකිය ව්යාපෘති පිටුව.

ඉතින්, කලින් අපි අපේ වින්‍යාසය තුළ ඩොකර්ෆයිල් නැවත ලිවීමට ඉදිරිපත් වූවා නම්, දැන් අපි සතුටින් මෙසේ කියමු: “වර්ෆ්ට ඔබේ ඩොකර්ෆයිල් තැනීමට ඉඩ දෙන්න!”

භාවිතා කරන්නේ කෙසේද?

මෙම විශේෂාංගයේ සම්පූර්ණ ක්‍රියාත්මක කිරීම නිකුතුවේ දිස් විය werf v1.0.3-beta.1. සාමාන්‍ය මූලධර්මය සරලයි: පරිශීලකයා werf config හි පවතින Dockerfile වෙත මාර්ගය සඳහන් කරයි, ඉන්පසු විධානය ක්‍රියාත්මක කරයි. werf build... එපමණයි - වර්ෆ් රූපය එකලස් කරනු ඇත. අපි වියුක්ත උදාහරණයක් බලමු.

ඊළඟ එක නිවේදනය කරමු Dockerfile ව්යාපෘති මූලයේ:

FROM ubuntu:18.04
RUN echo Building ...

සහ අපි නිවේදනය කරන්නම් werf.yamlමෙය භාවිතා කරන Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

සෑම! වම දුවන්න werf build:

ඔබට දැන් සාමාන්‍ය ඩොකර් ගොනුවක් භාවිතයෙන් වර්ෆ් තුළ ඩොකර් රූප තැනිය හැක

ඊට අමතරව, ඔබට පහත සඳහන් දේ ප්රකාශ කළ හැකිය werf.yaml විවිධ Dockerfiles වලින් පින්තූර කිහිපයක් එකවර ගොඩනැගීමට:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

අවසාන වශයෙන්, එය වැනි අතිරේක ගොඩනැගීමේ පරාමිතීන් සම්මත කිරීමට ද සහාය වේ --build-arg и --add-host - werf config හරහා. Dockerfile රූප වින්‍යාසය පිළිබඳ සම්පූර්ණ විස්තරයක් මෙහි ඇත ලේඛන පිටුව.

එය ක්රියාත්මක වන්නේ කෙසේද?

ගොඩනැගීමේ ක්‍රියාවලියේදී, Docker හි දේශීය ස්ථරවල සම්මත හැඹිලිය ක්‍රියා කරයි. කෙසේ වෙතත්, වැදගත් වන්නේ එය ද වේ Dockerfile වින්‍යාසය එහි යටිතල ව්‍යුහයට අනුකලනය කරයි. මෙමගින් කුමක් වෙයිද?

  1. Dockerfile එකකින් සාදන ලද සෑම රූපයක්ම එක් අදියරකින් සමන්විත වේ dockerfile (Werf හි කුමන අදියරයන් ගැන ඔබට වැඩිදුර කියවිය හැකිය මෙහි).
  2. වේදිකාව සඳහා dockerfile werf විසින් Dockerfile වින්‍යාසයේ අන්තර්ගතය මත රඳා පවතින අත්සනක් ගණනය කරයි. Dockerfile වින්‍යාසය වෙනස් වූ විට, අදියර අත්සන වෙනස් වේ dockerfile සහ werf විසින් නව Dockerfile වින්‍යාසයක් සමඟ මෙම අදියර නැවත ගොඩනැගීම ආරම්භ කරයි. අත්සන වෙනස් නොවේ නම්, werf හැඹිලියෙන් රූපය ලබා ගනී (වර්ෆ් හි අත්සන් භාවිතය පිළිබඳ වැඩි විස්තර විස්තර කර ඇත මෙම වාර්තාව).
  3. ඊළඟට, එකතු කරන ලද පින්තූර විධානය සමඟ ප්රකාශයට පත් කළ හැකිය werf publish (හෝ werf build-and-publish) සහ Kubernetes වෙත යෙදවීම සඳහා එය භාවිතා කරන්න. Docker Registry වෙත ප්‍රකාශිත පින්තූර සම්මත werf cleanup tools භාවිතයෙන් පිරිසිදු කෙරේ, i.e. පැරණි පින්තූර (N දිනට වඩා පැරණි), නොපවතින Git ශාඛා හා සම්බන්ධ රූප සහ අනෙකුත් ප්‍රතිපත්ති ස්වයංක්‍රීයව පිරිසිදු කෙරේ.

මෙහි විස්තර කර ඇති කරුණු පිළිබඳ වැඩි විස්තර ලේඛනගතව සොයාගත හැකිය:

සටහන් සහ පූර්වාරක්ෂාවන්

1. ADD හි බාහිර URL සහාය නොදක්වයි

දැනට එය විධානයක බාහිර URL භාවිතා කිරීමට සහාය නොදක්වයි ADD. නිශ්චිත URL හි ඇති සම්පත වෙනස් වන විට Werf නැවත ගොඩනැගීමක් ආරම්භ නොකරනු ඇත. අපි ඉක්මනින්ම මෙම විශේෂාංගය එක් කිරීමට සැලසුම් කරමු.

2. ඔබට රූපයට .git එකතු කළ නොහැක

පොදුවේ ගත් කල, නාමාවලියක් එකතු කිරීම .git රූපයේ - දරුණු නරක පුරුද්දක් සහ මෙන්න ඇයි:

  1. නම් .git අවසාන රූපයේ පවතී, මෙය මූලධර්ම උල්ලංඝනය කරයි 12 සාධක යෙදුම: අවසාන රූපය තනි කැපවීමකට සම්බන්ධ කළ යුතු බැවින්, එය කළ නොහැකි විය යුතුය git checkout අත්තනෝමතික කැපවීම.
  2. .git රූපයේ ප්‍රමාණය වැඩි කරයි (විශාල ලිපිගොනු වරක් එයට එකතු කර පසුව මකා දැමීම නිසා ගබඩාව විශාල විය හැක). නිශ්චිත කැපවීමකට පමණක් සම්බන්ධ වැඩ-ගසක ප්‍රමාණය Git හි මෙහෙයුම් ඉතිහාසය මත රඳා නොපවතී. මෙම අවස්ථාවේදී, එකතු කිරීම සහ පසුව ඉවත් කිරීම .git අවසාන රූපයෙන් ක්‍රියා නොකරනු ඇත: රූපය තවමත් අමතර තට්ටුවක් ලබා ගනී - ඩොකර් ක්‍රියා කරන ආකාරය මෙයයි.
  3. ඩොකර් හට අනවශ්‍ය නැවත ගොඩනැගීමක් ආරම්භ කළ හැකිය, එකම කැපවීම ගොඩනඟමින් සිටියද, නමුත් විවිධ වැඩ ගස් වලින්. උදාහරණයක් ලෙස, GitLab වෙනම ක්ලෝන කළ නාමාවලි නිර්මාණය කරයි /home/gitlab-runner/builds/HASH/[0-N]/yourproject සමාන්තර එකලස් කිරීම සක්රිය කළ විට. අතිරේක නැවත එකලස් කිරීම ඩිරෙක්ටරිය නිසා සිදුවනු ඇත .git එකම කැපවීම ගොඩනගා ඇතත්, එකම ගබඩාවේ විවිධ ක්ලෝන කරන ලද අනුවාද වල වෙනස් වේ.

werf භාවිතා කරන විට අවසාන කරුණ ද ප්රතිවිපාක ඇත. සමහර විධාන ක්‍රියාත්මක කරන විට නිර්මිත හැඹිලිය තිබීම Werf හට අවශ්‍ය වේ (උදා. werf deploy) මෙම විධානයන් ක්‍රියාත්මක වන විට, werf විසින් නිශ්චිතව දක්වා ඇති පින්තූර සඳහා අදියර අත්සන් ගණනය කරයි werf.yaml, සහ ඒවා එකලස් කිරීමේ හැඹිලියේ තිබිය යුතුය - එසේ නොමැතිනම් විධානය දිගටම වැඩ කිරීමට නොහැකි වනු ඇත. වේදිකාවේ අත්සන අන්තර්ගතය මත රඳා පවතී නම් .git, එවිට අපට අදාළ නොවන ලිපිගොනු වල වෙනස්කම් වලට අස්ථායී හැඹිලියක් ලැබෙන අතර, එවැනි අතපසු වීමකට සමාව දීමට werf ට නොහැකි වනු ඇත (වැඩි විස්තර සඳහා, බලන්න ලියකියවිලි).

සමස්තයක් ලෙස අවශ්ය සමහර ගොනු පමණක් එකතු කිරීම උපදෙස් හරහා ADD ඕනෑම අවස්ථාවක ලිඛිත කාර්යක්ෂමතාව සහ විශ්වසනීයත්වය වැඩි කරයි Dockerfile, සහ මේ සඳහා එකතු කරන ලද හැඹිලියේ ස්ථාවරත්වය ද වැඩි දියුණු කරයි Dockerfile, Git හි අදාල නොවන වෙනස්කම් වලට.

ප්රතිඵලය

නිශ්චිත අවශ්‍යතා සඳහා අපගේම තනන්නා ලිවීමට අපගේ ආරම්භක මාර්ගය දුෂ්කර, අවංක සහ සරල විය: සම්මත Dockerfile මත කිහිලිකරු භාවිතා කිරීම වෙනුවට, අපි අභිරුචි වාක්‍ය ඛණ්ඩය සමඟ අපගේ විසඳුම ලිව්වෙමු. මෙය එහි වාසි ඇත: ස්ටැපල් එකතු කරන්නා එහි කාර්යය සමඟ හොඳින් කටයුතු කරයි.

කෙසේ වෙතත්, අපගේම තනන්නා ලිවීමේ ක්‍රියාවලියේදී, දැනට පවතින ඩොකර්ෆයිල් සඳහා ඇති සහය අපට නොපෙනී ගියේය. මෙම දෝෂය දැන් නිරාකරණය කර ඇති අතර, අනාගතයේදී අපි බෙදා හරින ලද ගොඩනැගීම් සඳහා සහ Kubernetes භාවිතා කරන ගොඩනැගීම් සඳහා අපගේ අභිරුචි ස්ටැපල් සාදන්නා සමඟ ඩොකර්ෆයිල් සහාය සංවර්ධනය කිරීමට සැලසුම් කරමු (එනම්, කනිකෝ හි සිදු කර ඇති පරිදි, කුබර්නෙටස් ඇතුළත ධාවකයන් මත ගොඩනඟයි).

ඉතින්, ඔබට හදිසියේම ඩොකර්ෆයිල් කිහිපයක් තිබේ නම් ... උත්සාහ කරන්න werf!

PS මාතෘකාව පිළිබඳ ලේඛන ලැයිස්තුව

අපගේ බ්ලොග් අඩවියේ ද කියවන්න: "werf - Kubernetes හි CI / CD සඳහා අපගේ මෙවලම (දළ විශ්ලේෂණය සහ වීඩියෝ වාර්තාව)".

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න