కుబెర్నెట్‌లకు అప్లికేషన్‌లను రూపొందించడానికి మరియు డెలివరీ చేయడానికి మా ఓపెన్ సోర్స్ GitOps CLI యుటిలిటీ. IN ఇమేజ్ కలెక్టర్‌లో కొత్త ఫీచర్ ప్రవేశపెట్టబడింది: కంటెంట్ ద్వారా చిత్రాలను ట్యాగ్ చేయడం లేదా కంటెంట్ ఆధారిత ట్యాగింగ్. ఇప్పటి వరకు, werfలోని సాధారణ ట్యాగింగ్ పథకంలో Git ట్యాగ్, Git శాఖ లేదా Git కమిట్ ద్వారా డాకర్ చిత్రాలను ట్యాగ్ చేయడం జరుగుతుంది. కానీ ఈ పథకాలన్నింటికీ ప్రతికూలతలు ఉన్నాయి, అవి కొత్త ట్యాగింగ్ వ్యూహం ద్వారా పూర్తిగా పరిష్కరించబడతాయి. దాని గురించిన వివరాలు మరియు ఇది ఎందుకు చాలా బాగుంది అనేవి కట్ క్రింద ఉన్నాయి.
ఒక Git రిపోజిటరీ నుండి మైక్రోసర్వీస్‌ల సమితిని విడుదల చేస్తోంది
అప్లికేషన్ అనేక ఎక్కువ లేదా తక్కువ స్వతంత్ర సేవలుగా విభజించబడినప్పుడు తరచుగా పరిస్థితి ఏర్పడుతుంది. ఈ సేవల విడుదలలు స్వతంత్రంగా జరుగుతాయి: ఒకటి లేదా అంతకంటే ఎక్కువ సేవలను ఒకేసారి విడుదల చేయవచ్చు, మిగిలినవి ఎటువంటి మార్పులు లేకుండా పనిని కొనసాగించాలి. కానీ కోడ్ నిల్వ మరియు ప్రాజెక్ట్ నిర్వహణ దృక్కోణం నుండి, అటువంటి అప్లికేషన్ సేవలను ఒకే రిపోజిటరీలో ఉంచడం మరింత సౌకర్యవంతంగా ఉంటుంది.
సేవలు నిజంగా స్వతంత్రంగా మరియు ఒకే అప్లికేషన్‌తో అనుబంధించబడనప్పుడు పరిస్థితులు ఉన్నాయి. ఈ సందర్భంలో, అవి వేర్వేరు ప్రాజెక్ట్‌లలో ఉంటాయి మరియు వాటి విడుదల ప్రతి ప్రాజెక్ట్‌లో ప్రత్యేక CI/CD ప్రక్రియల ద్వారా నిర్వహించబడుతుంది.
అయితే, వాస్తవానికి, డెవలపర్లు తరచుగా ఒకే అప్లికేషన్‌ను అనేక మైక్రోసర్వీస్‌లుగా విభజించారు, అయితే ప్రతిదానికి ప్రత్యేక రిపోజిటరీ మరియు ప్రాజెక్ట్‌ను సృష్టించడం అనేది స్పష్టమైన ఓవర్‌కిల్. ఈ పరిస్థితి గురించి మరింత చర్చించబడుతుంది: ఇలాంటి అనేక మైక్రోసర్వీస్‌లు ఒకే ప్రాజెక్ట్ రిపోజిటరీలో ఉన్నాయి మరియు CI/CDలో ఒకే ప్రక్రియ ద్వారా విడుదలలు జరుగుతాయి.
Git శాఖ మరియు Git ట్యాగ్ ద్వారా ట్యాగింగ్
అత్యంత సాధారణ ట్యాగింగ్ వ్యూహం ఉపయోగించబడిందని చెప్పండి - ట్యాగ్-లేదా-శాఖ. Git బ్రాంచ్‌ల కోసం, ఇమేజ్‌లు బ్రాంచ్ పేరుతో ట్యాగ్ చేయబడతాయి, ఒక్కో బ్రాంచ్‌కి ఒక్కో బ్రాంచ్ పేరుతో ఒకే ఒక్క ఇమేజ్ మాత్రమే ప్రచురించబడుతుంది. Git ట్యాగ్‌ల కోసం, ట్యాగ్ పేరు ప్రకారం చిత్రాలు ట్యాగ్ చేయబడతాయి.
కొత్త Git ట్యాగ్ సృష్టించబడినప్పుడు-ఉదాహరణకు, కొత్త వెర్షన్ విడుదలైనప్పుడు-డాకర్ రిజిస్ట్రీలోని అన్ని ప్రాజెక్ట్ చిత్రాల కోసం కొత్త డాకర్ ట్యాగ్ సృష్టించబడుతుంది:
-
myregistry.org/myproject/frontend:v1.1.10 -
myregistry.org/myproject/myservice1:v1.1.10 -
myregistry.org/myproject/myservice2:v1.1.10 -
myregistry.org/myproject/myservice3:v1.1.10 -
myregistry.org/myproject/myservice4:v1.1.10 -
myregistry.org/myproject/myservice5:v1.1.10 -
myregistry.org/myproject/database:v1.1.10
ఈ కొత్త చిత్రాల పేర్లు హెల్మ్ టెంప్లేట్‌ల ద్వారా కుబెర్నెట్స్ కాన్ఫిగరేషన్‌కు పంపబడతాయి. కమాండ్‌తో విస్తరణను ప్రారంభించినప్పుడు werf deploy ఫీల్డ్ నవీకరించబడుతోంది image కుబెర్నెటెస్ రిసోర్స్ మానిఫెస్ట్ మరియు మార్చబడిన ఇమేజ్ పేరు కారణంగా సంబంధిత వనరులను రీస్టార్ట్ చేస్తుంది.
సమస్య: నిజానికి, చిత్రం యొక్క కంటెంట్‌లు మునుపటి రోల్‌అవుట్ (Git ట్యాగ్) నుండి మారనట్లయితే, దాని డాకర్ ట్యాగ్ మాత్రమే ఇలా జరుగుతుంది అదనపు ఈ అనువర్తనాన్ని పునఃప్రారంభించడం మరియు తదనుగుణంగా, కొంత పనికిరాని సమయం సాధ్యమవుతుంది. ఈ పునఃప్రారంభాన్ని నిర్వహించడానికి నిజమైన కారణం లేనప్పటికీ.
ఫలితంగా, ప్రస్తుత ట్యాగింగ్ స్కీమ్‌తో అనేక వేర్వేరు Git రిపోజిటరీలను కంచె వేయడం అవసరం మరియు ఈ అనేక రిపోజిటరీల రోల్‌అవుట్‌ను నిర్వహించడంలో సమస్య తలెత్తుతుంది. సాధారణంగా, అటువంటి పథకం ఓవర్లోడ్ మరియు సంక్లిష్టమైనదిగా మారుతుంది. అనేక సేవలను ఒకే రిపోజిటరీగా కలపడం మరియు డాకర్ ట్యాగ్‌లను సృష్టించడం మంచిది, తద్వారా అనవసరమైన పునఃప్రారంభాలు ఉండవు.
Git కమిట్ ద్వారా ట్యాగింగ్
werf Git కమిట్‌లతో అనుబంధించబడిన ట్యాగింగ్ వ్యూహాన్ని కూడా కలిగి ఉంది.
Git-commit అనేది Git రిపోజిటరీ యొక్క కంటెంట్‌ల కోసం ఒక ఐడెంటిఫైయర్ మరియు Git రిపోజిటరీలోని ఫైల్‌ల సవరణ చరిత్రపై ఆధారపడి ఉంటుంది, కాబట్టి డాకర్ రిజిస్ట్రీలో చిత్రాలను ట్యాగ్ చేయడానికి దీన్ని ఉపయోగించడం లాజికల్‌గా కనిపిస్తుంది.
అయినప్పటికీ, Git కమిట్ ద్వారా ట్యాగ్ చేయడం Git శాఖలు లేదా Git ట్యాగ్‌ల ద్వారా ట్యాగ్ చేయడం వంటి ప్రతికూలతలను కలిగి ఉంటుంది:
- ఏ ఫైల్‌లను మార్చకుండా ఖాళీ కమిట్ సృష్టించబడవచ్చు, కానీ చిత్రం యొక్క డాకర్ ట్యాగ్ మార్చబడుతుంది.
- ఫైల్‌లను మార్చని విలీన నిబద్ధత సృష్టించబడుతుంది, కానీ చిత్రం యొక్క డాకర్ ట్యాగ్ మార్చబడుతుంది.
- ఇమేజ్‌లోకి దిగుమతి చేయని Gitలోని ఫైల్‌లను మార్చే కమిట్‌ను చేయవచ్చు మరియు చిత్రం యొక్క డాకర్ ట్యాగ్ మళ్లీ మార్చబడుతుంది.
Git శాఖ పేరును ట్యాగ్ చేయడం చిత్రం సంస్కరణను ప్రతిబింబించదు
Git శాఖల కోసం ట్యాగింగ్ వ్యూహంతో అనుబంధించబడిన మరొక సమస్య ఉంది.
బ్రాంచ్‌పై కమిట్‌లను కాలక్రమానుసారం వరుసగా సేకరించినంత కాలం శాఖ పేరుతో ట్యాగ్ చేయడం పని చేస్తుంది.
ప్రస్తుత స్కీమ్‌లో వినియోగదారు నిర్దిష్ట బ్రాంచ్‌తో అనుబంధించబడిన పాత కమిట్‌ను పునర్నిర్మించడం ప్రారంభిస్తే, పాత కమిట్ కోసం కొత్తగా నిర్మించిన చిత్రంతో సంబంధిత డాకర్ ట్యాగ్‌ని ఉపయోగించి werf చిత్రాన్ని మళ్లీ వ్రాస్తుంది. ఇప్పటి నుండి ఈ ట్యాగ్‌ని ఉపయోగించే విస్తరణలు పాడ్‌లను పునఃప్రారంభించేటప్పుడు చిత్రం యొక్క వేరొక సంస్కరణను లాగే ప్రమాదం ఉంది, దీని ఫలితంగా మా అప్లికేషన్ CI సిస్టమ్‌తో కనెక్షన్‌ను కోల్పోతుంది మరియు డీసింక్రొనైజ్ చేయబడుతుంది.
అదనంగా, వాటి మధ్య తక్కువ వ్యవధిలో ఒక బ్రాంచ్‌లోకి వరుస పుష్‌లతో, పాత కమిట్ కొత్తదాని కంటే తర్వాత సంకలనం చేయబడవచ్చు: చిత్రం యొక్క పాత వెర్షన్ Git బ్రాంచ్ ట్యాగ్‌ని ఉపయోగించి కొత్తదాన్ని ఓవర్‌రైట్ చేస్తుంది. ఇటువంటి సమస్యలను CI/CD వ్యవస్థ ద్వారా పరిష్కరించవచ్చు (ఉదాహరణకు, GitLab CIలో రెండోదాని పైప్‌లైన్ వరుస కమిట్‌ల కోసం ప్రారంభించబడింది). అయినప్పటికీ, అన్ని సిస్టమ్‌లు దీనికి మద్దతు ఇవ్వవు మరియు అటువంటి ప్రాథమిక సమస్యను నివారించడానికి మరింత నమ్మదగిన మార్గం ఉండాలి.
కంటెంట్ ఆధారిత ట్యాగింగ్ అంటే ఏమిటి?
కాబట్టి, కంటెంట్-ఆధారిత ట్యాగింగ్ అంటే ఏమిటి - కంటెంట్ ద్వారా చిత్రాలను ట్యాగ్ చేయడం.
డాకర్ ట్యాగ్‌లను సృష్టించడానికి, ఇది Git ప్రిమిటివ్స్ (Git బ్రాంచ్, Git ట్యాగ్...) కాదు, దీనితో అనుబంధించబడిన చెక్‌సమ్:
- చిత్రం యొక్క విషయాలు. చిత్రం ID ట్యాగ్ దాని కంటెంట్‌ను ప్రతిబింబిస్తుంది. కొత్త సంస్కరణను నిర్మిస్తున్నప్పుడు, చిత్రంలోని ఫైల్‌లు మారకపోతే ఈ ఐడెంటిఫైయర్ మారదు;
- Gitలో ఈ చిత్రాన్ని సృష్టించిన చరిత్ర. వివిధ Git శాఖలతో అనుబంధించబడిన చిత్రాలు మరియు werf ద్వారా విభిన్న నిర్మాణ చరిత్రలు వేర్వేరు ID ట్యాగ్‌లను కలిగి ఉంటాయి.
అటువంటి ఐడెంటిఫైయర్ ట్యాగ్ అని పిలవబడేది చిత్ర దశ సంతకం.
ప్రతి చిత్రం దశల సమితిని కలిగి ఉంటుంది: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch మొదలైనవి ప్రతి దశలో దాని కంటెంట్‌లను ప్రతిబింబించే ఐడెంటిఫైయర్ ఉంటుంది - వేదిక సంతకం (దశ సంతకం).
ఈ దశలతో కూడిన చివరి చిత్రం, ఈ దశల సెట్ యొక్క సంతకం అని పిలవబడే ట్యాగ్ చేయబడింది - దశల సంతకం, - ఇది చిత్రం యొక్క అన్ని దశలకు సాధారణీకరించబడుతుంది.
కాన్ఫిగరేషన్ నుండి ప్రతి చిత్రం కోసం werf.yaml సాధారణ సందర్భంలో, దాని స్వంత సంతకం మరియు దాని ప్రకారం, డాకర్ ట్యాగ్ ఉంటుంది.
దశ సంతకం ఈ సమస్యలన్నింటినీ పరిష్కరిస్తుంది:
- ఖాళీ Git కమిట్‌లకు నిరోధకత.
- ఇమేజ్‌కి సంబంధం లేని ఫైల్‌లను మార్చే Git నిరోధకం.
- బ్రాంచ్ యొక్క పాత Git కమిట్‌ల కోసం బిల్డ్‌లను పునఃప్రారంభించేటప్పుడు చిత్రం యొక్క ప్రస్తుత సంస్కరణను సరిదిద్దడంలో సమస్యకు దారితీయదు.
ఇది ఇప్పుడు సిఫార్సు చేయబడిన ట్యాగింగ్ వ్యూహం మరియు అన్ని CI సిస్టమ్‌లకు werfలో డిఫాల్ట్.
werfలో ఎలా ప్రారంభించాలి మరియు ఉపయోగించాలి
కమాండ్ ఇప్పుడు సంబంధిత ఎంపికను కలిగి ఉంది werf publish: --tag-by-stages-signature=true|false
CI సిస్టమ్‌లో, ట్యాగింగ్ వ్యూహం కమాండ్ ద్వారా నిర్దేశించబడుతుంది werf ci-env. గతంలో, దాని కోసం పరామితి నిర్వచించబడింది werf ci-env --tagging-strategy=tag-or-branch. ఇప్పుడు, మీరు పేర్కొన్నట్లయితే werf ci-env --tagging-strategy=stages-signature లేదా ఈ ఎంపికను పేర్కొనవద్దు, werf డిఫాల్ట్‌గా ట్యాగింగ్ వ్యూహాన్ని ఉపయోగిస్తుంది stages-signature. జట్టు werf ci-env కమాండ్ కోసం అవసరమైన ఫ్లాగ్‌లను స్వయంచాలకంగా సెట్ చేస్తుంది werf build-and-publish (లేదా werf publish), కాబట్టి ఈ ఆదేశాలకు అదనపు ఎంపికలు పేర్కొనవలసిన అవసరం లేదు.
ఉదాహరణకు, ఆదేశం:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature...ఈ క్రింది చిత్రాలను సృష్టించవచ్చు:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
ఇది 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d చిత్రం యొక్క దశల సంతకం backendమరియు f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - చిత్ర దశల సంతకం frontend.
ప్రత్యేక విధులను ఉపయోగిస్తున్నప్పుడు werf_container_image и werf_container_env హెల్మ్ టెంప్లేట్‌లలో దేనినీ మార్చవలసిన అవసరం లేదు: ఈ విధులు స్వయంచాలకంగా సరైన చిత్ర పేర్లను రూపొందిస్తాయి.
CI సిస్టమ్‌లో ఉదాహరణ కాన్ఫిగరేషన్:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployకాన్ఫిగరేషన్‌పై మరింత సమాచారం డాక్యుమెంటేషన్‌లో అందుబాటులో ఉంది:
- ;
- ;
- .
మొత్తం
- కొత్త ఎంపిక
werf publish --tag-by-stages-signature=true|false. - కొత్త ఎంపిక విలువ
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(పేర్కొనకపోతే, డిఫాల్ట్ అవుతుందిstages-signature). - మీరు మునుపు Git కమిట్‌ల కోసం ట్యాగింగ్ ఎంపికలను ఉపయోగించినట్లయితే (
WERF_TAG_GIT_COMMITలేదా ఎంపికwerf publish --tag-git-commit COMMIT), ఆపై ట్యాగింగ్ వ్యూహానికి మారాలని నిర్ధారించుకోండి దశలు-సంతకం. - కొత్త ప్రాజెక్ట్‌లను వెంటనే కొత్త ట్యాగింగ్ స్కీమ్‌కి మార్చడం మంచిది.
- werf 1.1కి బదిలీ చేసేటప్పుడు, పాత ప్రాజెక్ట్‌లను కొత్త ట్యాగింగ్ స్కీమ్‌కి మార్చడం మంచిది, కానీ పాతది ట్యాగ్-లేదా-శాఖ ఇప్పటికీ మద్దతు ఉంది.
కంటెంట్-ఆధారిత ట్యాగింగ్ వ్యాసంలో కవర్ చేయబడిన అన్ని సమస్యలను పరిష్కరిస్తుంది:
- ఖాళీ Git కమిట్‌లకు డాకర్ ట్యాగ్ పేరు ప్రతిఘటన.
- Gitకి డాకర్ ట్యాగ్ పేరు యొక్క ప్రతిఘటన చిత్రంతో సంబంధం లేని ఫైల్‌లను మారుస్తుంది.
- Git శాఖల కోసం పాత Git కమిట్‌ల కోసం బిల్డ్‌లను పునఃప్రారంభించేటప్పుడు చిత్రం యొక్క ప్రస్తుత సంస్కరణను సరిదిద్దడంలో సమస్యకు దారితీయదు.
దాన్ని ఉపయోగించు! మరియు మమ్మల్ని సందర్శించడం మర్చిపోవద్దు సమస్యను సృష్టించడానికి లేదా ఇప్పటికే ఉన్నదాన్ని కనుగొనడానికి, ప్లస్‌ని జోడించడానికి, PRని సృష్టించడానికి లేదా ప్రాజెక్ట్ అభివృద్ధిని చూడటానికి.
PS
మా బ్లాగులో కూడా చదవండి:
- «»
- «»
- «";
- వెర్ఫ్‌లో ఆవిష్కరణల గురించి గమనికల శ్రేణి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com