కుబెర్నెట్‌లకు అప్లికేషన్‌లను రూపొందించడానికి మరియు డెలివరీ చేయడానికి మా ఓపెన్ సోర్స్ GitOps CLI యుటిలిటీ. ప్రమాణం చేసినట్లే, వెర్ఫ్‌కు కొత్త ఫీచర్‌లను జోడించడం మరియు సాంప్రదాయ విధానాలను సవరించడం ప్రారంభించింది. ఇప్పుడు మేము విడుదల v1.1ని ప్రదర్శించడానికి సంతోషిస్తున్నాము, ఇది అభివృద్ధిలో ఒక పెద్ద అడుగు మరియు భవిష్యత్తుకు పునాది కలెక్టర్ వర్ఫ్ సంస్కరణ ప్రస్తుతం అందుబాటులో ఉంది .
విడుదల యొక్క ఆధారం స్టేజ్ స్టోరేజ్ యొక్క కొత్త ఆర్కిటెక్చర్ మరియు రెండు కలెక్టర్ల పని యొక్క ఆప్టిమైజేషన్ (స్టేపెల్ మరియు డాకర్‌ఫైల్ కోసం). కొత్త స్టోరేజ్ ఆర్కిటెక్చర్ బహుళ హోస్ట్‌ల నుండి పంపిణీ చేయబడిన అసెంబ్లీలను మరియు ఒకే హోస్ట్‌లో సమాంతర సమావేశాలను అమలు చేసే అవకాశాన్ని తెరుస్తుంది.
పని యొక్క ఆప్టిమైజేషన్ అనేది స్టేజ్ సంతకాలను లెక్కించే దశలో అనవసరమైన గణనలను వదిలించుకోవడం మరియు ఫైల్ చెక్‌సమ్‌లను మరింత సమర్థవంతమైన వాటికి గణించే విధానాలను మార్చడం. ఈ ఆప్టిమైజేషన్ werf ఉపయోగించి ప్రాజెక్ట్ బిల్డ్‌ల సగటు సమయాన్ని తగ్గిస్తుంది. మరియు నిష్క్రియ బిల్డ్‌లు, కాష్‌లో అన్ని దశలు ఉన్నప్పుడు దశలు-నిల్వ, ఇప్పుడు నిజంగా వేగంగా ఉన్నాయి. చాలా సందర్భాలలో, బిల్డ్‌ని రీస్టార్ట్ చేయడానికి 1 సెకను కంటే తక్కువ సమయం పడుతుంది! జట్ల పని ప్రక్రియలో దశలను ధృవీకరించే విధానాలకు కూడా ఇది వర్తిస్తుంది. werf deploy и werf run.
ఈ విడుదలలో, కంటెంట్ ద్వారా చిత్రాలను ట్యాగ్ చేసే వ్యూహం కనిపించింది - కంటెంట్ ఆధారిత ట్యాగింగ్, ఇది ఇప్పుడు డిఫాల్ట్‌గా ప్రారంభించబడింది మరియు సిఫార్సు చేయబడినది మాత్రమే.
werf v1.1లోని కీలక ఆవిష్కరణలను నిశితంగా పరిశీలిద్దాం మరియు అదే సమయంలో భవిష్యత్తు ప్రణాళికల గురించి మీకు తెలియజేస్తాము.
werf v1.1లో ఏమి మారింది?
కాష్ నుండి దశలను ఎంచుకోవడానికి కొత్త స్టేజ్ నేమింగ్ ఫార్మాట్ మరియు అల్గోరిథం
కొత్త వేదిక పేరు తరం నియమం. ఇప్పుడు ప్రతి స్టేజ్ బిల్డ్ ఒక ప్రత్యేకమైన స్టేజ్ పేరును రూపొందిస్తుంది, ఇందులో 2 భాగాలు ఉంటాయి: ఒక సంతకం (v1.0లో ఉన్నట్లుగా) మరియు ఒక ప్రత్యేకమైన తాత్కాలిక ఐడెంటిఫైయర్.
ఉదాహరణకు, పూర్తి వేదిక చిత్రం పేరు ఇలా ఉండవచ్చు:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...లేదా సాధారణంగా:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
ఇక్కడ:
-
SIGNATUREస్టేజ్ సిగ్నేచర్, ఇది స్టేజ్ కంటెంట్ యొక్క ఐడెంటిఫైయర్‌ను సూచిస్తుంది మరియు ఈ కంటెంట్‌కు దారితీసిన Gitలో సవరణల చరిత్రపై ఆధారపడి ఉంటుంది; -
TIMESTAMP_MILLISECఒక కొత్త చిత్రం నిర్మించబడిన సమయంలో రూపొందించబడిన హామీ ఇవ్వబడిన ఏకైక ఇమేజ్ ఐడెంటిఫైయర్.
కాష్ నుండి దశలను ఎంచుకోవడానికి అల్గోరిథం Git కమిట్‌ల సంబంధాన్ని తనిఖీ చేయడంపై ఆధారపడి ఉంటుంది:
- వెర్ఫ్ ఒక నిర్దిష్ట దశ సంతకాన్ని లెక్కిస్తుంది.
- В దశలు-నిల్వ ఇచ్చిన సంతకం కోసం అనేక దశలు ఉండవచ్చు. సంతకంతో సరిపోలే అన్ని దశలను వెర్ఫ్ ఎంచుకుంటుంది.
- ప్రస్తుత దశ Gitకి లింక్ చేయబడితే (git-ఆర్కైవ్, Git ప్యాచ్‌లతో అనుకూల దశ:
install,beforeSetup,setup; లేదా git-latest-patch), అప్పుడు werf ప్రస్తుత కమిట్‌కి పూర్వీకుడైన కమిట్‌తో అనుబంధించబడిన దశలను మాత్రమే ఎంచుకుంటుంది (దీని కోసం బిల్డ్ అంటారు). - మిగిలిన తగిన దశల నుండి, ఒకటి ఎంపిక చేయబడింది - సృష్టి తేదీ ప్రకారం పురాతనమైనది.
వివిధ Git శాఖల కోసం ఒక వేదిక ఒకే సంతకాన్ని కలిగి ఉంటుంది. సంతకాలు సరిపోలినప్పటికీ, వివిధ శాఖలతో అనుబంధించబడిన కాష్‌ని ఈ శాఖల మధ్య ఉపయోగించకుండా werf నిరోధిస్తుంది.
.
స్టేజ్ స్టోరేజ్‌లో దశలను సృష్టించడం మరియు సేవ్ చేయడం కోసం కొత్త అల్గారిథమ్
కాష్ నుండి దశలను ఎంచుకున్నప్పుడు, werf తగిన దశను కనుగొనలేకపోతే, కొత్త దశను సమీకరించే ప్రక్రియ ప్రారంభించబడుతుంది.
బహుళ ప్రక్రియలు (ఒకటి లేదా అంతకంటే ఎక్కువ హోస్ట్‌లపై) దాదాపు ఒకే సమయంలో ఒకే దశను నిర్మించడాన్ని ప్రారంభించవచ్చని గమనించండి. Werf ఒక ఆశావాద నిరోధించే అల్గారిథమ్‌ను ఉపయోగిస్తుంది దశలు-నిల్వ తాజాగా సేకరించిన చిత్రాన్ని సేవ్ చేసే సమయంలో దశలు-నిల్వ. ఈ విధంగా, కొత్త స్టేజ్ బిల్డ్ సిద్ధంగా ఉన్నప్పుడు, వెర్ఫ్ బ్లాక్ అవుతుంది దశలు-నిల్వ మరియు సరియైన చిత్రం అక్కడ లేనట్లయితే మాత్రమే తాజాగా సేకరించిన చిత్రాన్ని అక్కడ సేవ్ చేస్తుంది (సంతకం మరియు ఇతర పారామితుల ద్వారా - కాష్ నుండి దశలను ఎంచుకోవడానికి కొత్త అల్గోరిథం చూడండి).
తాజాగా అసెంబుల్ చేయబడిన ఇమేజ్‌కి ప్రత్యేక ఐడెంటిఫైయర్ ఉండేలా హామీ ఇవ్వబడుతుంది TIMESTAMP_MILLISEC (కొత్త వేదిక నామకరణ ఆకృతిని చూడండి). ఒక సందర్భంలో దశలు-నిల్వ తగిన చిత్రం కనుగొనబడుతుంది, werf తాజాగా సంకలనం చేయబడిన చిత్రాన్ని విస్మరిస్తుంది మరియు కాష్ నుండి చిత్రాన్ని ఉపయోగిస్తుంది.
మరో మాటలో చెప్పాలంటే: చిత్రాన్ని నిర్మించడం పూర్తి చేసే మొదటి ప్రక్రియ (వేగవంతమైనది) దానిని దశల-నిల్వలో నిల్వ చేయడానికి హక్కును పొందుతుంది (తర్వాత ఇది అన్ని బిల్డ్‌లకు ఉపయోగించబడుతుంది). స్లో బిల్డ్ ప్రాసెస్ ప్రస్తుత దశ యొక్క బిల్డ్ ఫలితాలను సేవ్ చేయకుండా మరియు తదుపరి బిల్డ్‌కు వెళ్లకుండా వేగవంతమైన ప్రక్రియను ఎప్పటికీ నిరోధించదు.
.
మెరుగైన డాకర్‌ఫైల్ బిల్డర్ పనితీరు
ప్రస్తుతానికి, డాకర్‌ఫైల్ నుండి నిర్మించిన చిత్రం కోసం దశల పైప్‌లైన్ ఒక దశను కలిగి ఉంటుంది - dockerfile. సంతకాన్ని లెక్కించేటప్పుడు, ఫైళ్ళ చెక్సమ్ లెక్కించబడుతుంది context, ఇది అసెంబ్లీ సమయంలో ఉపయోగించబడుతుంది. ఈ మెరుగుదలకు ముందు, werf అన్ని ఫైల్‌ల ద్వారా పునరావృతంగా నడిచాడు మరియు ప్రతి ఫైల్ యొక్క సందర్భం మరియు మోడ్‌ను సంగ్రహించడం ద్వారా చెక్‌సమ్‌ను పొందాడు. v1.1తో ప్రారంభించి, werf Git రిపోజిటరీలో నిల్వ చేయబడిన లెక్కించిన చెక్‌సమ్‌లను ఉపయోగించవచ్చు.
అల్గోరిథం ఆధారంగా ఉంటుంది . అల్గోరిథం రికార్డులను పరిగణనలోకి తీసుకుంటుంది .dockerignore మరియు అవసరమైనప్పుడు మాత్రమే ఫైల్ ట్రీని పునరావృతంగా దాటుతుంది. ఈ విధంగా, మేము ఫైల్ సిస్టమ్‌ను చదవడం నుండి వేరు చేసాము మరియు పరిమాణంపై అల్గోరిథం యొక్క ఆధారపడటం context ముఖ్యమైనది కాదు.
అల్గోరిథం ట్రాక్ చేయని ఫైల్‌లను కూడా తనిఖీ చేస్తుంది మరియు అవసరమైతే, వాటిని చెక్‌సమ్‌లో పరిగణనలోకి తీసుకుంటుంది.
ఫైళ్లను దిగుమతి చేసేటప్పుడు మెరుగైన పనితీరు
werf v1.1 సంస్కరణలు ఎప్పుడు rsync సర్వర్‌ని ఉపయోగిస్తాయి . ఇంతకుముందు, హోస్ట్ సిస్టమ్ నుండి డైరెక్టరీ మౌంట్‌ని ఉపయోగించి దిగుమతి చేయడం రెండు దశల్లో జరిగింది.
MacOSలో దిగుమతి పనితీరు ఇకపై డాకర్ వాల్యూమ్‌ల ద్వారా పరిమితం చేయబడదు మరియు Linux మరియు Windows మాదిరిగానే దిగుమతులు పూర్తవుతాయి.
కంటెంట్ ఆధారిత ట్యాగింగ్
Werf v1.1 చిత్రం కంటెంట్ ద్వారా ట్యాగింగ్ అని పిలవబడే మద్దతు ఇస్తుంది - కంటెంట్ ఆధారిత ట్యాగింగ్. ఫలితంగా వచ్చిన డాకర్ చిత్రాల ట్యాగ్‌లు ఈ చిత్రాల కంటెంట్‌లపై ఆధారపడి ఉంటాయి.
ఆదేశాన్ని అమలు చేస్తున్నప్పుడు werf publish --tags-by-stages-signature లేదా werf ci-env --tagging-strategy=stages-signature అని పిలవబడే చిత్రాలను ప్రచురించింది వేదిక సంతకం చిత్రం. ప్రతి చిత్రం ఈ చిత్రం యొక్క దశల యొక్క దాని స్వంత సంతకంతో ట్యాగ్ చేయబడింది, ఇది ప్రతి దశ యొక్క సాధారణ సంతకం వలె విడిగా అదే నియమాల ప్రకారం లెక్కించబడుతుంది, అయితే ఇది చిత్రం యొక్క సాధారణ ఐడెంటిఫైయర్.
చిత్ర దశల సంతకం వీటిపై ఆధారపడి ఉంటుంది:
- ఈ చిత్రం యొక్క విషయాలు;
- ఈ కంటెంట్‌కు దారితీసిన Git మార్పుల చరిత్రలు.
Git రిపోజిటరీ ఎల్లప్పుడూ ఇమేజ్ ఫైల్‌ల కంటెంట్‌లను మార్చని డమ్మీ కమిట్‌లను కలిగి ఉంటుంది. ఉదాహరణకు, కేవలం వ్యాఖ్యలతో కమిట్‌లు లేదా విలీనం కమిట్‌లు లేదా Gitలోని ఫైల్‌లను మార్చే కమిట్‌లు ఇమేజ్‌లోకి దిగుమతి చేయబడవు.
కంటెంట్-ఆధారిత ట్యాగింగ్‌ని ఉపయోగిస్తున్నప్పుడు, ఇమేజ్ పేరులో మార్పుల కారణంగా కుబెర్నెట్స్‌లో అప్లికేషన్ పాడ్‌ల అనవసరమైన రీస్టార్ట్‌ల సమస్యలు, ఇమేజ్‌లోని కంటెంట్‌లు మారకపోయినప్పటికీ పరిష్కరించబడతాయి. మార్గం ద్వారా, ఒక అప్లికేషన్ యొక్క అనేక మైక్రోసర్వీస్‌లను ఒకే Git రిపోజిటరీలో నిల్వ చేయకుండా నిరోధించే కారణాలలో ఇది ఒకటి.
అలాగే, Git బ్రాంచ్‌లపై ట్యాగింగ్ చేయడం కంటే కంటెంట్-ఆధారిత ట్యాగింగ్ అనేది మరింత విశ్వసనీయమైన ట్యాగింగ్ పద్ధతి, ఎందుకంటే ఫలిత చిత్రాల కంటెంట్ ఒకే బ్రాంచ్‌లోని బహుళ కమిట్‌లను అసెంబ్లింగ్ చేయడానికి CI సిస్టమ్‌లో పైప్‌లైన్‌లను అమలు చేసే క్రమంపై ఆధారపడి ఉండదు.
ముఖ్యమైన: ఇప్పటి నుండి మొదలు దశలు-సంతకం అది - సిఫార్సు చేయబడిన ఏకైక ట్యాగింగ్ వ్యూహం. ఇది కమాండ్‌లో డిఫాల్ట్‌గా ఉపయోగించబడుతుంది werf ci-env (మీరు వేరే ట్యాగింగ్ స్కీమ్‌ను స్పష్టంగా పేర్కొనకపోతే).
. ఈ లక్షణానికి ప్రత్యేక ప్రచురణ కూడా కేటాయించబడుతుంది. నవీకరించబడింది (ఏప్రిల్ 3): వివరాలతో కూడిన కథనం .
లాగింగ్ స్థాయిలు
వినియోగదారుకు ఇప్పుడు అవుట్‌పుట్‌ను నియంత్రించడానికి, లాగింగ్ స్థాయిని సెట్ చేయడానికి మరియు డీబగ్గింగ్ సమాచారంతో పని చేయడానికి అవకాశం ఉంది. ఎంపికలు జోడించబడ్డాయి --log-quiet, --log-verbose, --log-debug.
డిఫాల్ట్‌గా, అవుట్‌పుట్ కనీస సమాచారాన్ని కలిగి ఉంటుంది:
వెర్బోస్ అవుట్‌పుట్ ఉపయోగిస్తున్నప్పుడు (--log-verbose) werf ఎలా పని చేస్తుందో మీరు చూడవచ్చు:
వివరణాత్మక అవుట్‌పుట్ (--log-debug), werf డీబగ్గింగ్ సమాచారంతో పాటు, ఉపయోగించిన లైబ్రరీల లాగ్‌లు కూడా ఉన్నాయి. ఉదాహరణకు, డాకర్ రిజిస్ట్రీతో పరస్పర చర్య ఎలా జరుగుతుందో మీరు చూడవచ్చు మరియు గణనీయమైన సమయాన్ని వెచ్చించే స్థలాలను కూడా రికార్డ్ చేయవచ్చు:
భవిష్యత్తు ప్రణాళికలు
హెచ్చరిక దిగువ వివరించిన ఎంపికలు గుర్తించబడ్డాయి v1.1 ఈ సంస్కరణలో అందుబాటులోకి వస్తాయి, సమీప భవిష్యత్తులో వాటిలో చాలా వరకు. అప్‌డేట్‌లు ఆటో అప్‌డేట్‌ల ద్వారా వస్తాయి . ఈ ఫీచర్‌లు v1.1 ఫంక్షన్‌ల స్థిరమైన భాగాన్ని ప్రభావితం చేయవు; వాటి రూపానికి ఇప్పటికే ఉన్న కాన్ఫిగరేషన్‌లలో మాన్యువల్ యూజర్ జోక్యం అవసరం లేదు.
వివిధ డాకర్ రిజిస్ట్రీ అమలులకు పూర్తి మద్దతు (కొత్త)
- వెర్షన్: v1.1
- తేదీలు: మార్చి
werfని ఉపయోగిస్తున్నప్పుడు వినియోగదారు పరిమితులు లేకుండా అనుకూల అమలును ఉపయోగించడం లక్ష్యం.
ప్రస్తుతం, మేము కింది పరిష్కారాల సెట్‌ను గుర్తించాము, దీని కోసం మేము పూర్తి మద్దతుకు హామీ ఇవ్వబోతున్నాము:
- డిఫాల్ట్ (లైబ్రరీ/రిజిస్ట్రీ)*,
- AWS ECR
- నీలవర్ణం*,
- డాకర్ హబ్
- GCR*,
- GitHub ప్యాకేజీలు
- GitLab రిజిస్ట్రీ*,
- నౌకాశ్రయం*,
- క్వే.
ప్రస్తుతం werf ద్వారా పూర్తిగా మద్దతిచ్చే సొల్యూషన్‌లు నక్షత్రం గుర్తుతో గుర్తించబడతాయి. ఇతరులకు మద్దతు ఉంది, కానీ పరిమితులతో.
రెండు ప్రధాన సమస్యలను గుర్తించవచ్చు:
- కొన్ని పరిష్కారాలు డాకర్ రిజిస్ట్రీ APIని ఉపయోగించి ట్యాగ్ తొలగింపుకు మద్దతు ఇవ్వవు, వినియోగదారులు werf యొక్క ఆటోమేటిక్ క్లీనప్‌ని ఉపయోగించకుండా నిరోధిస్తుంది. AWS ECR, డాకర్ హబ్ మరియు GitHub ప్యాకేజీలకు ఇది వర్తిస్తుంది.
- కొన్ని సొల్యూషన్‌లు నెస్టెడ్ రిపోజిటరీలు (డాకర్ హబ్, గిట్‌హబ్ ప్యాకేజీలు మరియు క్వే) అని పిలవబడే వాటికి మద్దతు ఇవ్వవు లేదా చేస్తాయి, అయితే వినియోగదారు వాటిని తప్పనిసరిగా UI లేదా API (AWS ECR) ఉపయోగించి మాన్యువల్‌గా సృష్టించాలి.
మేము పరిష్కారాల యొక్క స్థానిక APIలను ఉపయోగించి వీటిని మరియు ఇతర సమస్యలను పరిష్కరించబోతున్నాము. ఈ టాస్క్‌లో ప్రతిదానికి సంబంధించిన పరీక్షలతో వేర్ఫ్ ఆపరేషన్ యొక్క పూర్తి చక్రాన్ని కవర్ చేయడం కూడా ఉంటుంది.
డిస్ట్రిబ్యూటెడ్ ఇమేజ్ బిల్డ్ (↑)
- వెర్షన్: v1.2 v1.1 (ఈ ఫీచర్‌ని అమలు చేయడానికి ప్రాధాన్యత పెంచబడింది)
- తేదీలు: మార్చి-ఏప్రిల్ మార్చి
ప్రస్తుతానికి, werf v1.0 మరియు v1.1 చిత్రాలను నిర్మించడం మరియు ప్రచురించడం మరియు అప్లికేషన్‌ను Kubernetesకి అమలు చేయడం వంటి కార్యకలాపాల కోసం ఒక ప్రత్యేక హోస్ట్‌లో మాత్రమే ఉపయోగించబడతాయి.
కుబెర్నెట్స్‌లో అప్లికేషన్‌ల బిల్డ్ మరియు విస్తరణ అనేక ఏకపక్ష హోస్ట్‌లలో ప్రారంభించబడినప్పుడు మరియు ఈ హోస్ట్‌లు బిల్డ్‌ల (తాత్కాలిక రన్నర్‌లు) మధ్య తమ స్థితిని సేవ్ చేయనప్పుడు, వెర్ఫ్ యొక్క పంపిణీ పని యొక్క అవకాశాలను తెరవడానికి, ఉపయోగించగల సామర్థ్యాన్ని అమలు చేయడానికి వెర్ఫ్ అవసరం. స్టేజ్ స్టోర్‌గా డాకర్ రిజిస్ట్రీ.
ఇంతకుముందు, వెర్ఫ్ ప్రాజెక్ట్‌ను ఇప్పటికీ డాప్ అని పిలిచినప్పుడు, దీనికి అలాంటి అవకాశం ఉంది. అయినప్పటికీ, werfలో ఈ కార్యాచరణను అమలు చేస్తున్నప్పుడు పరిగణనలోకి తీసుకోవలసిన అనేక సమస్యలను మేము ఎదుర్కొన్నాము.
వ్యాఖ్య. ఈ ఫీచర్‌కు కలెక్టర్ కుబెర్నెటెస్ పాడ్‌ల లోపల పని చేయాల్సిన అవసరం లేదు, ఎందుకంటే దీన్ని చేయడానికి, మీరు స్థానిక డాకర్ సర్వర్‌పై ఆధారపడటాన్ని వదిలించుకోవాలి (కుబెర్నెట్స్ పాడ్‌లో స్థానిక డాకర్ సర్వర్‌కు ప్రాప్యత లేదు, ఎందుకంటే ప్రక్రియ కంటైనర్‌లో నడుస్తుంది మరియు వెర్ఫ్ మద్దతు ఇవ్వదు మరియు మద్దతు ఇవ్వదు. నెట్‌వర్క్‌లో డాకర్ సర్వర్‌తో పని చేయడం). Kubernetes అమలు కోసం మద్దతు ప్రత్యేకంగా అమలు చేయబడుతుంది.
GitHub చర్యలకు అధికారిక మద్దతు (కొత్తది)
- వెర్షన్: v1.1
- తేదీలు: మార్చి
వెర్ఫ్ డాక్యుమెంటేషన్‌ను కలిగి ఉంటుంది (విభాగాలు సూచన и మార్గనిర్దేశం), అలాగే werfతో పని చేయడానికి అధికారిక GitHub చర్య.
అదనంగా, ఇది ఎఫెమెరల్ రన్నర్‌లపై పని చేయడానికి వెర్ఫ్‌ను అనుమతిస్తుంది.
CI సిస్టమ్‌తో వినియోగదారు పరస్పర చర్య యొక్క మెకానిక్స్ అప్లికేషన్‌ను రూపొందించడానికి/రోల్ అవుట్ చేయడానికి నిర్దిష్ట చర్యలను ప్రారంభించడానికి పుల్ అభ్యర్థనలపై లేబుల్‌లను ఉంచడంపై ఆధారపడి ఉంటుంది.
వెర్ఫ్ (↓)తో స్థానిక అభివృద్ధి మరియు అప్లికేషన్‌ల విస్తరణ
- వెర్షన్: v1.1
- తేదీలు: జనవరి-ఫిబ్రవరి ఏప్రిల్
సంక్లిష్ట చర్యలు లేకుండా, స్థానికంగా మరియు ఉత్పత్తిలో అప్లికేషన్‌లను అమలు చేయడానికి ఒకే ఏకీకృత కాన్ఫిగరేషన్‌ను సాధించడం ప్రధాన లక్ష్యం.
werf కూడా ఆపరేటింగ్ మోడ్‌ను కలిగి ఉండాలి, దీనిలో అప్లికేషన్ కోడ్‌ని సవరించడం మరియు డీబగ్గింగ్ కోసం నడుస్తున్న అప్లికేషన్ నుండి తక్షణమే అభిప్రాయాన్ని స్వీకరించడం సౌకర్యంగా ఉంటుంది.
కొత్త శుభ్రపరిచే అల్గోరిథం (కొత్తది)
- వెర్షన్: v1.1
- తేదీలు: ఏప్రిల్
ప్రక్రియలో werf v1.1 ప్రస్తుత వెర్షన్‌లో cleanup కంటెంట్-ఆధారిత ట్యాగింగ్ స్కీమ్ కోసం చిత్రాలను శుభ్రపరచడానికి ఎటువంటి నిబంధన లేదు - ఈ చిత్రాలు పేరుకుపోతాయి.
అలాగే, ప్రస్తుత వెర్షన్ werf (v1.0 మరియు v1.1) ట్యాగింగ్ స్కీమ్‌ల క్రింద ప్రచురించబడిన చిత్రాల కోసం విభిన్న క్లీనప్ విధానాలను ఉపయోగిస్తుంది: Git శాఖ, Git ట్యాగ్ లేదా Git కమిట్.
అన్ని ట్యాగింగ్ స్కీమ్‌ల కోసం ఏకీకృతమైన Gitలోని కమిట్‌ల చరిత్ర ఆధారంగా చిత్రాలను శుభ్రపరిచే కొత్త అల్గారిథమ్ కనుగొనబడింది:
- ప్రతి git HEAD (శాఖలు మరియు ట్యాగ్‌లు) కోసం N1 అత్యంత ఇటీవలి కమిట్‌లతో అనుబంధించబడిన N2 చిత్రాల కంటే ఎక్కువ ఉండకూడదు.
- ప్రతి git HEAD (శాఖలు మరియు ట్యాగ్‌లు) కోసం N1 అత్యంత ఇటీవలి కమిట్‌లతో అనుబంధించబడిన N2 దశ చిత్రాల కంటే ఎక్కువ నిల్వ చేయవద్దు.
- ఏదైనా Kubernetes క్లస్టర్ వనరులలో ఉపయోగించిన అన్ని చిత్రాలను నిల్వ చేయండి (కాన్ఫిగరేషన్ ఫైల్ మరియు నేమ్‌స్పేస్‌ల యొక్క అన్ని kube సందర్భాలు స్కాన్ చేయబడతాయి; మీరు ఈ ప్రవర్తనను ప్రత్యేక ఎంపికలతో పరిమితం చేయవచ్చు).
- హెల్మ్ విడుదలలలో సేవ్ చేయబడిన వనరుల కాన్ఫిగరేషన్ మానిఫెస్ట్‌లలో ఉపయోగించిన అన్ని చిత్రాలను నిల్వ చేయండి.
- చిత్రం git నుండి ఏదైనా HEADతో అనుబంధించబడకపోతే (ఉదాహరణకు, సంబంధిత HEAD కూడా తొలగించబడినందున) మరియు Kubernetes క్లస్టర్‌లోని ఏ మానిఫెస్ట్‌లలో మరియు హెల్మ్ విడుదలలలో ఉపయోగించబడకపోతే అది తొలగించబడుతుంది.
సమాంతర చిత్ర నిర్మాణం (↓)
- వెర్షన్: v1.1
- తేదీలు: జనవరి-ఫిబ్రవరి ఏప్రిల్*
werf యొక్క ప్రస్తుత వెర్షన్ వివరించిన చిత్రాలు మరియు కళాఖండాలను సేకరిస్తుంది werf.yaml, వరుసగా. చిత్రాలు మరియు కళాఖండాల యొక్క స్వతంత్ర దశలను సమీకరించే ప్రక్రియను సమాంతరంగా చేయడం, అలాగే అనుకూలమైన మరియు సమాచార ఉత్పత్తిని అందించడం అవసరం.
* గమనిక: పంపిణీ చేయబడిన అసెంబ్లీని అమలు చేయడానికి ఎక్కువ ప్రాధాన్యత ఉన్నందున గడువు మార్చబడింది, ఇది మరింత క్షితిజ సమాంతర స్కేలింగ్ సామర్థ్యాలను జోడిస్తుంది, అలాగే GitHub చర్యలతో werfని ఉపయోగిస్తుంది. సమాంతర అసెంబ్లీ తదుపరి ఆప్టిమైజేషన్ దశ, ఒక ప్రాజెక్ట్‌ను సమీకరించేటప్పుడు నిలువు స్కేలబిలిటీని అందిస్తుంది.
హెల్మ్ 3కి మార్పు (↓)
- వెర్షన్: v1.2
- తేదీలు: ఫిబ్రవరి-మార్చి మే*
కొత్త కోడ్‌బేస్‌కి మైగ్రేషన్‌ని కలిగి ఉంటుంది మరియు ఇప్పటికే ఉన్న ఇన్‌స్టాలేషన్‌లను తరలించడానికి నిరూపితమైన, అనుకూలమైన మార్గం.
* గమనిక: హెల్మ్ 3కి మారడం వల్ల వెర్ఫ్‌కు ముఖ్యమైన ఫీచర్‌లు జోడించబడవు, ఎందుకంటే హెల్మ్ 3 (3-వే-మెర్జ్ మరియు టిల్లర్ లేదు) యొక్క అన్ని కీలక లక్షణాలు ఇప్పటికే వెర్ఫ్‌లో అమలు చేయబడ్డాయి. అంతేకాకుండా, వెర్ఫ్ కలిగి ఉంది సూచించిన వాటికి అదనంగా. అయితే, ఈ పరివర్తన మా ప్రణాళికల్లోనే ఉంది మరియు అమలు చేయబడుతుంది.
కుబెర్నెట్స్ కాన్ఫిగరేషన్‌ను వివరించడానికి Jsonnet (↓)
- వెర్షన్: v1.2
- తేదీలు: జనవరి-ఫిబ్రవరి ఏప్రిల్-మే
Jsonnet ఆకృతిలో Kubernetes కోసం కాన్ఫిగరేషన్ వివరణలకు Werf మద్దతు ఇస్తుంది. అదే సమయంలో, werf హెల్మ్‌తో అనుకూలంగా ఉంటుంది మరియు వివరణ ఆకృతి ఎంపిక ఉంటుంది.
కారణం ఏమిటంటే, గో టెంప్లేట్‌లు, చాలా మంది వ్యక్తుల ప్రకారం, అధిక ప్రవేశ అవరోధాన్ని కలిగి ఉంటాయి మరియు ఈ టెంప్లేట్‌ల కోడ్ యొక్క అవగాహన కూడా దెబ్బతింటుంది.
ఇతర Kubernetes కాన్ఫిగరేషన్ వివరణ సిస్టమ్‌లను (ఉదాహరణకు, Kustomize) పరిచయం చేసే అవకాశం కూడా పరిగణించబడుతోంది.
Kubernetes (↓)లో పని చేస్తున్నారు
- వెర్షన్: v1.2
- తేదీలు: ఏప్రిల్-మే మే-జూన్
లక్ష్యం: కుబెర్నెట్స్‌లోని రన్నర్‌లను ఉపయోగించి ఇమేజ్‌లు నిర్మించబడ్డాయని మరియు అప్లికేషన్ డెలివరీ చేయబడిందని నిర్ధారించుకోండి. ఆ. కుబెర్నెటెస్ పాడ్‌ల నుండి నేరుగా కొత్త చిత్రాలను నిర్మించవచ్చు, ప్రచురించవచ్చు, శుభ్రం చేయవచ్చు మరియు అమలు చేయవచ్చు.
ఈ సామర్థ్యాన్ని అమలు చేయడానికి, మీరు ముందుగా పంపిణీ చేయబడిన చిత్రాలను రూపొందించగలగాలి (పై పాయింట్ చూడండి).
దీనికి డాకర్ సర్వర్ లేకుండా బిల్డర్ ఆపరేటింగ్ మోడ్‌కు మద్దతు అవసరం (అనగా కనికో లాంటి బిల్డ్ లేదా బిల్డ్ ఇన్ యూజర్‌స్పేస్).
వెర్ఫ్ డాకర్‌ఫైల్‌తో మాత్రమే కాకుండా, దాని స్టాపెల్ బిల్డర్‌తో ఇంక్రిమెంటల్ రీబిల్డ్‌లు మరియు అన్సిబుల్‌తో కుబెర్నెట్స్‌లో నిర్మించడానికి మద్దతు ఇస్తుంది.
బహిరంగ అభివృద్ధికి ఒక అడుగు
మేము మా సంఘాన్ని ప్రేమిస్తున్నాము (, ) మరియు వెర్ఫ్‌ను మరింత మెరుగ్గా మార్చేందుకు, మేము ముందుకు సాగుతున్న దిశను అర్థం చేసుకోవడానికి మరియు అభివృద్ధిలో పాల్గొనడానికి మరింత మంది వ్యక్తులు సహాయం చేయాలని మేము కోరుకుంటున్నాము.
దీనికి మారాలని ఇటీవల నిర్ణయించారు మా బృందం యొక్క పని ప్రక్రియను బహిర్గతం చేయడానికి. ఇప్పుడు మీరు తక్షణ ప్రణాళికలను, అలాగే కింది ప్రాంతాలలో ప్రస్తుత పనిని చూడవచ్చు:
- ;
- ;
- ;
- .
సమస్యలతో చాలా పని జరిగింది:
- సంబంధం లేని వాటిని తొలగించారు.
- ఇప్పటికే ఉన్నవి తగిన సంఖ్యలో వివరాలు మరియు వివరాలతో ఒకే ఆకృతికి తీసుకురాబడ్డాయి.
- ఆలోచనలు మరియు సూచనలతో కొత్త సమస్యలు జోడించబడ్డాయి.
వెర్షన్ v1.1ని ఎలా ప్రారంభించాలి
సంస్కరణ ప్రస్తుతం అందుబాటులో ఉంది (ఛానెళ్లలో స్థిరంగా и రాతి-ఘన అయితే, స్థిరీకరణ జరిగినప్పుడు విడుదలలు కనిపిస్తాయి ea ఇప్పటికే ఉపయోగం కోసం తగినంత స్థిరంగా ఉంది, ఎందుకంటే చానల్స్ ద్వారా వెళ్ళింది ఆల్ఫా и బేటా) యాక్టివేట్ చేయబడింది క్రింది విధంగా:
source $(multiwerf use 1.1 ea)
werf COMMAND ...తీర్మానం
స్టాపెల్ మరియు డాకర్‌ఫైల్ బిల్డర్‌ల కోసం కొత్త స్టేజ్ స్టోరేజ్ ఆర్కిటెక్చర్ మరియు బిల్డర్ ఆప్టిమైజేషన్‌లు వెర్ఫ్‌లో పంపిణీ చేయబడిన మరియు సమాంతర నిర్మాణాలను అమలు చేసే అవకాశాన్ని తెరుస్తాయి. ఈ లక్షణాలు త్వరలో అదే v1.1 విడుదలలో కనిపిస్తాయి మరియు ఆటో-అప్‌డేట్ మెకానిజం ద్వారా స్వయంచాలకంగా అందుబాటులోకి వస్తాయి (వినియోగదారుల కోసం ).
ఈ విడుదలలో, చిత్ర కంటెంట్ ఆధారంగా ట్యాగింగ్ వ్యూహం జోడించబడింది - కంటెంట్ ఆధారిత ట్యాగింగ్, ఇది డిఫాల్ట్ వ్యూహంగా మారింది. ప్రధాన కమాండ్ లాగ్ కూడా పునర్నిర్మించబడింది: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
పంపిణీ చేయబడిన సమావేశాలను జోడించడం తదుపరి ముఖ్యమైన దశ. పంపిణీ చేయబడిన బిల్డ్‌లు v1.0 నుండి సమాంతర బిల్డ్‌ల కంటే ఎక్కువ ప్రాధాన్యతను సంతరించుకున్నాయి ఎందుకంటే అవి వెర్ఫ్‌కు మరింత విలువను జోడిస్తాయి: బిల్డర్‌ల నిలువు స్కేలింగ్ మరియు వివిధ CI/CD సిస్టమ్‌లలో ఎఫెమెరల్ బిల్డర్‌లకు మద్దతు, అలాగే GitHub చర్యలకు అధికారిక మద్దతునిచ్చే సామర్థ్యం. . అందువల్ల, సమాంతర సమావేశాల అమలు గడువులు మార్చబడ్డాయి. అయితే, మేము వీలైనంత త్వరగా రెండు అవకాశాలను అమలు చేయడానికి కృషి చేస్తున్నాము.
వార్తలను అనుసరించండి! మరియు మమ్మల్ని సందర్శించడం మర్చిపోవద్దు సమస్యను సృష్టించడానికి, ఇప్పటికే ఉన్నదాన్ని కనుగొని, ప్లస్‌ను జోడించడానికి, PRని సృష్టించడానికి లేదా ప్రాజెక్ట్ అభివృద్ధిని చూడటానికి.
PS
మా బ్లాగులో కూడా చదవండి:
- «»
- «";
- వెర్ఫ్‌లో ఆవిష్కరణల గురించి గమనికల శ్రేణి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com