તમે હવે નિયમિત ડોકરફાઇલનો ઉપયોગ કરીને werf માં ડોકર છબીઓ બનાવી શકો છો

ક્યારેક ના પહોચવા કરતા. અથવા એપ્લિકેશન છબીઓ બનાવવા માટે નિયમિત ડોકરફાઇલ્સ માટે સમર્થન ન હોવાને કારણે અમે લગભગ કેવી રીતે ગંભીર ભૂલ કરી છે.

વિશે વાત કરીશું વર્ફ — GitOps ઉપયોગિતા જે કોઈપણ CI/CD સિસ્ટમ સાથે સંકલિત થાય છે અને સમગ્ર એપ્લિકેશન જીવનચક્રનું સંચાલન પૂરું પાડે છે, પરવાનગી આપે છે:

• છબીઓ એકત્રિત કરો અને પ્રકાશિત કરો,
• કુબરનેટ્સમાં એપ્લિકેશનો જમાવવા,
• ખાસ નીતિઓનો ઉપયોગ કરીને બિનઉપયોગી છબીઓ કાઢી નાખો.

પ્રોજેક્ટની ફિલસૂફી એ એક એકીકૃત સિસ્ટમમાં નિમ્ન-સ્તરના સાધનો એકત્રિત કરવાની છે જે DevOps એન્જિનિયરોને એપ્લિકેશન પર નિયંત્રણ આપે છે. જો શક્ય હોય તો, હાલની ઉપયોગિતાઓ (જેમ કે હેલ્મ અને ડોકર) નો ઉપયોગ કરવો જોઈએ. જો કોઈ સમસ્યાનો કોઈ ઉકેલ ન હોય, તો અમે આ માટે જરૂરી બધું બનાવી શકીએ છીએ અને સમર્થન આપી શકીએ છીએ.

પૃષ્ઠભૂમિ: તમારી પોતાની છબી કલેક્ટર

વર્ફમાં ઇમેજ કલેક્ટર સાથે આવું જ થયું: સામાન્ય ડોકરફાઇલ અમારા માટે પૂરતી ન હતી. જો તમે પ્રોજેક્ટના ઇતિહાસ પર એક ઝડપી નજર નાખો, તો આ સમસ્યા પહેલેથી જ werf ના પ્રથમ સંસ્કરણોમાં દેખાય છે (પછી હજુ પણ ડેપ તરીકે ઓળખાય છે).

ડોકર ઈમેજીસમાં એપ્લીકેશન બનાવવા માટે એક ટૂલ બનાવતી વખતે, અમને ઝડપથી સમજાયું કે ડોકરફાઈલ અમુક ચોક્કસ કાર્યો માટે અમારા માટે યોગ્ય નથી:

1. નીચેની માનક યોજના અનુસાર લાક્ષણિક નાની વેબ એપ્લિકેશનો બનાવવાની જરૂરિયાત:
   • સિસ્ટમ-વ્યાપી એપ્લિકેશન નિર્ભરતા સ્થાપિત કરો,
   • એપ્લિકેશન નિર્ભરતા પુસ્તકાલયોનું બંડલ ઇન્સ્ટોલ કરો,
   • સંપત્તિ ભેગી કરવી,
   • અને સૌથી અગત્યનું, છબીના કોડને ઝડપથી અને અસરકારક રીતે અપડેટ કરો.
2. જ્યારે પ્રોજેક્ટ ફાઇલોમાં ફેરફારો કરવામાં આવે છે, ત્યારે બિલ્ડરે બદલાયેલી ફાઇલો પર પેચ લાગુ કરીને ઝડપથી નવું સ્તર બનાવવું આવશ્યક છે.
3. જો અમુક ફાઈલો બદલાઈ ગઈ હોય, તો અનુરૂપ આશ્રિત સ્ટેજને ફરીથી બનાવવું જરૂરી છે.

આજે આપણા કલેક્ટર પાસે બીજી ઘણી શક્યતાઓ છે, પરંતુ આ શરૂઆતની ઈચ્છાઓ અને વિનંતીઓ હતી.

સામાન્ય રીતે, બે વાર વિચાર્યા વિના, અમે જે પ્રોગ્રામિંગ ભાષાનો ઉપયોગ કર્યો છે તેનાથી અમે પોતાને સજ્જ કરીએ છીએ (નીચે જુઓ) અને અમલ માટે રસ્તા પર ઉતર્યા પોતાના DSL! ઉદ્દેશ્યો અનુસાર, તેનો હેતુ એસેમ્બલી પ્રક્રિયાને તબક્કાવાર વર્ણવવાનો અને ફાઇલો પરના આ તબક્કાઓની નિર્ભરતા નક્કી કરવાનો હતો. અને તેને પૂરક બનાવ્યો પોતાના કલેક્ટર, જેણે DSL ને અંતિમ ધ્યેયમાં ફેરવ્યું - એસેમ્બલ ઇમેજ. શરૂઆતમાં ડીએસએલ રૂબીમાં હતું, પરંતુ તરીકે ગોલાંગમાં સંક્રમણ — અમારા કલેક્ટરનું રૂપરેખા YAML ફાઇલમાં વર્ણવવાનું શરૂ થયું.

રૂબીમાં ડીએપી માટે જૂની રૂપરેખા

YAML પર werf માટે વર્તમાન રૂપરેખા

સમયાંતરે કલેક્ટરનું તંત્ર પણ બદલાયું. શરૂઆતમાં, અમે અમારા રૂપરેખાંકનમાંથી ફ્લાય પર કામચલાઉ ડોકરફાઇલ જનરેટ કરી, અને પછી અમે અસ્થાયી કન્ટેનરમાં એસેમ્બલી સૂચનાઓ ચલાવવાનું શરૂ કર્યું અને કમિટ કરવાનું શરૂ કર્યું.

NB: આ ક્ષણે, અમારું કલેક્ટર, જે તેની પોતાની રૂપરેખા (YAML માં) સાથે કામ કરે છે અને તેને સ્ટેપલ કલેક્ટર કહેવામાં આવે છે, તે પહેલેથી જ એકદમ શક્તિશાળી સાધન તરીકે વિકસિત થઈ ગયું છે. તેનું વિગતવાર વર્ણન અલગ લેખને પાત્ર છે, અને મૂળભૂત વિગતો તેમાં મળી શકે છે દસ્તાવેજીકરણ.

સમસ્યાની જાગૃતિ

પરંતુ અમને સમજાયું, અને તરત જ નહીં, કે અમે એક ભૂલ કરી છે: અમે ક્ષમતા ઉમેરી નથી પ્રમાણભૂત ડોકરફાઇલ દ્વારા છબીઓ બનાવો અને તેમને સમાન એન્ડ-ટુ-એન્ડ એપ્લિકેશન મેનેજમેન્ટ ઇન્ફ્રાસ્ટ્રક્ચરમાં એકીકૃત કરો (એટલે ​​​​કે છબીઓ એકત્રિત કરો, તેને જમાવો અને સાફ કરો). કુબરનેટ્સમાં જમાવટ માટે સાધન બનાવવું અને ડોકરફાઇલ સપોર્ટને અમલમાં મૂકવું કેવી રીતે શક્ય છે, એટલે કે. મોટાભાગના પ્રોજેક્ટ માટે છબીઓનું વર્ણન કરવાની માનક રીત?..

આ પ્રશ્નનો જવાબ આપવાને બદલે, અમે એક ઉકેલ ઓફર કરીએ છીએ. જો તમારી પાસે પહેલેથી જ Dockerfile (અથવા Dockerfiles નો સમૂહ) હોય અને તમે werf નો ઉપયોગ કરવા માંગતા હોવ તો શું?

NB: માર્ગ દ્વારા, તમે શા માટે werf નો ઉપયોગ કરવા માંગો છો? મુખ્ય લક્ષણો નીચે મુજબ આવે છે:

• છબી સફાઈ સહિત સંપૂર્ણ એપ્લિકેશન મેનેજમેન્ટ ચક્ર;
• એક જ રૂપરેખામાંથી એક સાથે અનેક છબીઓની એસેમ્બલીનું સંચાલન કરવાની ક્ષમતા;
• હેલ્મ-સુસંગત ચાર્ટ માટે સુધારેલ જમાવટ પ્રક્રિયા.

તેમની વધુ સંપૂર્ણ સૂચિ અહીં મળી શકે છે પ્રોજેક્ટ પૃષ્ઠ.

તેથી, જો અગાઉ અમે અમારી રૂપરેખામાં ડોકરફાઇલને ફરીથી લખવાની ઓફર કરી હોત, તો હવે અમે ખુશીથી કહીશું: "તમારી ડોકરફાઇલ્સને બનાવવા દો!"

કેવી રીતે વાપરવું?

આ સુવિધાનો સંપૂર્ણ અમલીકરણ પ્રકાશનમાં દેખાયો werf v1.0.3-beta.1. સામાન્ય સિદ્ધાંત સરળ છે: વપરાશકર્તા werf રૂપરેખામાં હાલની ડોકરફાઈલનો માર્ગ સ્પષ્ટ કરે છે, અને પછી આદેશ ચલાવે છે 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 એક સાથે વિવિધ ડોકરફાઈલ્સમાંથી ઘણી છબીઓ બનાવવા માટે:

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

છેલ્લે, તે વધારાના બિલ્ડ પેરામીટર પસાર કરવા માટે પણ સપોર્ટ કરે છે, જેમ કે --build-arg и --add-host - werf રૂપરેખા દ્વારા. ડોકરફાઇલ ઇમેજ કન્ફિગરેશનનું સંપૂર્ણ વર્ણન અહીં ઉપલબ્ધ છે દસ્તાવેજીકરણ પૃષ્ઠ.

તે કેવી રીતે કામ કરે છે?

બિલ્ડ પ્રક્રિયા દરમિયાન, ડોકર ફંક્શનમાં સ્થાનિક સ્તરોની પ્રમાણભૂત કેશ. જો કે, શું મહત્વનું છે તે werf પણ છે ડોકરફાઈલ રૂપરેખાંકનને તેના ઈન્ફ્રાસ્ટ્રક્ચરમાં એકીકૃત કરે છે. આનો મતલબ શું થયો?

1. ડોકરફાઈલમાંથી બનેલી દરેક ઈમેજમાં એક સ્ટેજ કહેવાય છે dockerfile (Werf માં કયા તબક્કાઓ છે તે વિશે તમે વધુ વાંચી શકો છો અહીં).
2. સ્ટેજ માટે dockerfile werf એક હસ્તાક્ષરની ગણતરી કરે છે જે ડોકરફાઇલ રૂપરેખાંકનની સામગ્રી પર આધાર રાખે છે. જ્યારે Dockerfile રૂપરેખાંકન બદલાય છે, ત્યારે સ્ટેજ સિગ્નેચર બદલાય છે dockerfile અને werf નવા ડોકરફાઈલ રૂપરેખા સાથે આ તબક્કાનું પુનઃનિર્માણ શરૂ કરે છે. જો સહી બદલાતી નથી, તો વર્ફ કેશમાંથી છબી લે છે (વર્ફમાં હસ્તાક્ષરના ઉપયોગ વિશે વધુ વિગતો આમાં વર્ણવવામાં આવી હતી આ અહેવાલ).
3. આગળ, એકત્રિત કરેલી છબીઓ આદેશ સાથે પ્રકાશિત કરી શકાય છે werf publish (અથવા werf build-and-publish) અને તેનો ઉપયોગ કુબરનેટ્સ પર જમાવટ માટે કરો. ડોકર રજિસ્ટ્રીમાં પ્રકાશિત કરેલી છબીઓને માનક વેર્ફ ક્લિનઅપ ટૂલ્સનો ઉપયોગ કરીને સાફ કરવામાં આવશે, એટલે કે. જૂની છબીઓ (N દિવસ કરતાં જૂની), અસ્તિત્વમાં ન હોય તેવી Git શાખાઓ સાથે સંકળાયેલી છબીઓ અને અન્ય નીતિઓ આપમેળે સાફ થઈ જશે.

અહીં વર્ણવેલ મુદ્દાઓ વિશે વધુ વિગતો દસ્તાવેજીકરણમાં મળી શકે છે:

• પ્રકાશન પ્રક્રિયા;
• Kubernetes જમાવટ પ્રક્રિયા સાથે એકીકરણ;
• સફાઈ પ્રક્રિયા.

નોંધો અને સાવચેતીઓ

1. બાહ્ય URL ADD માં સમર્થિત નથી

હાલમાં તે નિર્દેશમાં બાહ્ય 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 માં અપ્રસ્તુત ફેરફારો માટે.

પરિણામ

ચોક્કસ જરૂરિયાતો માટે અમારા પોતાના બિલ્ડરને લખવાનો અમારો પ્રારંભિક માર્ગ સખત, પ્રમાણિક અને સીધો હતો: પ્રમાણભૂત ડોકરફાઇલની ટોચ પર ક્રૉચનો ઉપયોગ કરવાને બદલે, અમે કસ્ટમ સિન્ટેક્સ સાથે અમારું સોલ્યુશન લખ્યું. અને આના તેના ફાયદા હતા: સ્ટેપલ કલેક્ટર તેના કાર્યનો સંપૂર્ણ રીતે સામનો કરે છે.

જો કે, અમારા પોતાના બિલ્ડરને લખવાની પ્રક્રિયામાં, અમે હાલની ડોકરફાઈલ્સ માટેના સમર્થનની દૃષ્ટિ ગુમાવી દીધી છે. આ ખામી હવે ઠીક કરવામાં આવી છે, અને ભવિષ્યમાં અમે અમારા કસ્ટમ સ્ટેપલ બિલ્ડર સાથે વિતરિત બિલ્ડ્સ માટે અને કુબરનેટ્સ (એટલે ​​​​કે કનિકોમાં થાય છે તેમ કુબરનેટ્સની અંદરના દોડવીરો પર બિલ્ડ) માટે ડોકરફાઇલ સપોર્ટ વિકસાવવાની યોજના બનાવીએ છીએ.

તેથી, જો તમારી પાસે અચાનક બે ડોકરફાઈલ્સ પડેલી હોય તો... પ્રયાસ કરો વર્ફ!

પીએસ વિષય પરના દસ્તાવેજોની સૂચિ

• ઝડપી શરૂઆત માટે માર્ગદર્શિકાઓ;
• ડોકરફાઇલ બિલ્ડર રૂપરેખાંકનો;
• સ્ટેજ ઉપકરણ werf માં;
• છબી પ્રકાશન પ્રક્રિયા;
• Kubernetes જમાવટ પ્રક્રિયા સાથે એકીકરણ;
• સફાઈ પ્રક્રિયા;
• ડોકરફાઇલના વિકલ્પ તરીકે સ્ટેપલ બિલ્ડર.

અમારા બ્લોગમાં પણ વાંચો: “werf - કુબરનેટ્સમાં CI/CD માટે અમારું સાધન (વિહંગાવલોકન અને વિડિયો રિપોર્ટ)».

સોર્સ: www.habr.com