కంటైనర్ చిత్రాల "స్మార్ట్" శుభ్రపరిచే సమస్య మరియు వెర్ఫ్‌లో దాని పరిష్కారం

కుబెర్నెట్‌లకు డెలివరీ చేయబడిన క్లౌడ్ స్థానిక అప్లికేషన్‌ల కోసం ఆధునిక CI/CD పైప్‌లైన్‌ల వాస్తవికతలలో కంటైనర్ రిజిస్ట్రీలలో (డాకర్ రిజిస్ట్రీ మరియు దాని అనలాగ్‌లు) పేరుకుపోయిన చిత్రాలను శుభ్రపరచడంలో సమస్యలను వ్యాసం చర్చిస్తుంది. చిత్రాల ఔచిత్యానికి ప్రధాన ప్రమాణాలు మరియు శుభ్రపరచడం ఆటోమేట్ చేయడం, స్థలాన్ని ఆదా చేయడం మరియు జట్ల అవసరాలను తీర్చడంలో ఏర్పడే ఇబ్బందులు ఇవ్వబడ్డాయి. చివరగా, నిర్దిష్ట ఓపెన్ సోర్స్ ప్రాజెక్ట్ యొక్క ఉదాహరణను ఉపయోగించి, ఈ ఇబ్బందులను ఎలా అధిగమించవచ్చో మేము మీకు తెలియజేస్తాము.

పరిచయం

కంటైనర్ రిజిస్ట్రీలోని చిత్రాల సంఖ్య వేగంగా పెరుగుతుంది, ఎక్కువ నిల్వ స్థలాన్ని తీసుకుంటుంది మరియు దాని ధరను గణనీయంగా పెంచుతుంది. రిజిస్ట్రీలో ఆక్రమించబడిన స్థలం యొక్క ఆమోదయోగ్యమైన వృద్ధిని నియంత్రించడానికి, పరిమితం చేయడానికి లేదా నిర్వహించడానికి, ఇది ఆమోదించబడుతుంది:

1. చిత్రాల కోసం నిర్ణీత సంఖ్యలో ట్యాగ్‌లను ఉపయోగించండి;
2. చిత్రాలను ఏదో ఒక విధంగా శుభ్రం చేయండి.

మొదటి పరిమితి చిన్న జట్లకు కొన్నిసార్లు ఆమోదయోగ్యమైనది. డెవలపర్‌లు తగినంత శాశ్వత ట్యాగ్‌లను కలిగి ఉంటే (latest, main, test, boris మొదలైనవి), రిజిస్ట్రీ పరిమాణంలో ఉబ్బిపోదు మరియు ఎక్కువ కాలం మీరు దానిని శుభ్రపరచడం గురించి ఆలోచించాల్సిన అవసరం లేదు. అన్నింటికంటే, అన్ని అసంబద్ధమైన చిత్రాలు తొలగించబడతాయి మరియు శుభ్రపరచడానికి ఏ పని మిగిలి ఉండదు (ప్రతిదీ సాధారణ చెత్త కలెక్టర్ చేత చేయబడుతుంది).

అయితే, ఈ విధానం అభివృద్ధిని చాలా పరిమితం చేస్తుంది మరియు ఆధునిక CI/CD ప్రాజెక్ట్‌లకు చాలా అరుదుగా వర్తిస్తుంది. అభివృద్ధిలో అంతర్భాగమైంది ఆటోమేషన్, ఇది చాలా వేగంగా వినియోగదారులకు కొత్త కార్యాచరణను పరీక్షించడానికి, అమలు చేయడానికి మరియు అందించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉదాహరణకు, మా అన్ని ప్రాజెక్ట్‌లలో, ప్రతి కమిట్‌తో CI పైప్‌లైన్ స్వయంచాలకంగా సృష్టించబడుతుంది. దీనిలో, చిత్రం అసెంబుల్ చేయబడింది, పరీక్షించబడింది, డీబగ్గింగ్ మరియు మిగిలిన చెక్‌ల కోసం వివిధ కుబెర్నెట్స్ సర్క్యూట్‌లకు రోల్‌అవుట్ చేయబడింది మరియు అన్నీ సరిగ్గా ఉంటే, మార్పులు తుది వినియోగదారుకు చేరుతాయి. మరియు ఇది ఇకపై రాకెట్ సైన్స్ కాదు, కానీ చాలా మందికి రోజువారీ సంఘటన - మీరు ఈ కథనాన్ని చదువుతున్నందున మీ కోసం చాలా మటుకు.

బగ్‌లను పరిష్కరించడం మరియు కొత్త కార్యాచరణను అభివృద్ధి చేయడం సమాంతరంగా నిర్వహించబడుతుంది మరియు విడుదలలు రోజుకు చాలాసార్లు నిర్వహించబడతాయి కాబట్టి, అభివృద్ధి ప్రక్రియ గణనీయమైన సంఖ్యలో కమిట్‌లతో కూడి ఉంటుందని స్పష్టంగా తెలుస్తుంది, అంటే. రిజిస్ట్రీలో పెద్ద సంఖ్యలో చిత్రాలు. ఫలితంగా, రిజిస్ట్రీ యొక్క సమర్థవంతమైన శుభ్రపరచడం నిర్వహించే సమస్య తలెత్తుతుంది, అనగా. సంబంధం లేని చిత్రాలను తీసివేయడం.

కానీ ఒక చిత్రం సంబంధితంగా ఉందో లేదో మీరు ఎలా నిర్ణయిస్తారు?

చిత్రం యొక్క ఔచిత్యం కోసం ప్రమాణాలు

చాలా సందర్భాలలో, ప్రధాన ప్రమాణాలు:

1. మొదటిది (అన్నింటిలో అత్యంత స్పష్టమైనది మరియు అత్యంత క్లిష్టమైనది) ఆ చిత్రాలు ప్రస్తుతం కుబెర్నెట్స్‌లో ఉపయోగిస్తున్నారు. ఈ చిత్రాలను తీసివేయడం వలన గణనీయమైన ఉత్పత్తి సమయ వ్యయాలు (ఉదాహరణకు, ప్రతిరూపణ కోసం ఇమేజ్‌లు అవసరం కావచ్చు) లేదా ఏదైనా లూప్‌లపై బృందం డీబగ్గింగ్ చేసే ప్రయత్నాలను తిరస్కరించవచ్చు. (ఈ కారణంగా మేము ఒక ప్రత్యేకతను కూడా చేసాము ప్రోమేతియస్ ఎగుమతిదారు, ఇది ఏదైనా కుబెర్నెట్స్ క్లస్టర్‌లో అటువంటి చిత్రాలు లేకపోవడాన్ని ట్రాక్ చేస్తుంది.)

2. రెండవది (తక్కువ స్పష్టమైనది, కానీ చాలా ముఖ్యమైనది మరియు మళ్లీ దోపిడీకి సంబంధించినది) - చిత్రాలు తీవ్రమైన సమస్యలను గుర్తించిన సందర్భంలో రోల్‌బ్యాక్ కోసం అవసరం ప్రస్తుత సంస్కరణలో. ఉదాహరణకు, హెల్మ్ విషయంలో, ఇవి విడుదల యొక్క సేవ్ చేయబడిన సంస్కరణల్లో ఉపయోగించబడే చిత్రాలు. (మార్గం ద్వారా, హెల్మ్‌లో డిఫాల్ట్‌గా పరిమితి 256 పునర్విమర్శలు, కానీ ఎవరైనా నిజంగా సేవ్ చేయాల్సిన అవసరం లేదు ఇటువంటి ఒక పెద్ద సంఖ్యలో సంస్కరణలు? అవసరమైతే వారికి "వెనక్కి వెళ్లండి".

3. మూడవది - డెవలపర్ అవసరాలు: వారి ప్రస్తుత పనికి సంబంధించిన అన్ని చిత్రాలు. ఉదాహరణకు, మేము PRని పరిశీలిస్తున్నట్లయితే, చివరి కమిట్‌కు మరియు మునుపటి కమిట్‌కి అనుగుణమైన చిత్రాన్ని వదిలివేయడం అర్ధమే: ఈ విధంగా డెవలపర్ ఏదైనా పనికి త్వరగా తిరిగి వెళ్లి తాజా మార్పులతో పని చేయవచ్చు.

4. నాల్గవ - చిత్రాలు ఆ మా అప్లికేషన్ యొక్క సంస్కరణలకు అనుగుణంగా ఉంటుంది, అనగా తుది ఉత్పత్తి: v1.0.0, 20.04.01/XNUMX/XNUMX, సియెర్రా, మొదలైనవి.

NB: ఇక్కడ నిర్వచించబడిన ప్రమాణాలు వివిధ కంపెనీల నుండి డజన్ల కొద్దీ అభివృద్ధి బృందాలతో పరస్పర చర్య చేసిన అనుభవం ఆధారంగా రూపొందించబడ్డాయి. అయితే, వాస్తవానికి, అభివృద్ధి ప్రక్రియలలోని ప్రత్యేకతలు మరియు ఉపయోగించిన మౌలిక సదుపాయాలపై ఆధారపడి (ఉదాహరణకు, కుబెర్నెట్స్ ఉపయోగించబడదు), ఈ ప్రమాణాలు భిన్నంగా ఉండవచ్చు.

అర్హత మరియు ఇప్పటికే ఉన్న పరిష్కారాలు

కంటైనర్ రిజిస్ట్రీలతో జనాదరణ పొందిన సేవలు, ఒక నియమం వలె, వారి స్వంత ఇమేజ్ క్లీనప్ విధానాలను అందిస్తాయి: వాటిలో మీరు రిజిస్ట్రీ నుండి ట్యాగ్ తీసివేయబడే పరిస్థితులను నిర్వచించవచ్చు. అయితే, ఈ పరిస్థితులు పేర్లు, సృష్టి సమయం మరియు ట్యాగ్‌ల సంఖ్య* వంటి పారామితుల ద్వారా పరిమితం చేయబడ్డాయి.

* నిర్దిష్ట కంటైనర్ రిజిస్ట్రీ అమలులపై ఆధారపడి ఉంటుంది. మేము ఈ క్రింది పరిష్కారాల యొక్క అవకాశాలను పరిగణించాము: Azure CR, Docker Hub, ECR, GCR, GitHub ప్యాకేజీలు, GitLab కంటైనర్ రిజిస్ట్రీ, హార్బర్ రిజిస్ట్రీ, JFrog ఆర్టిఫ్యాక్టరీ, Quay.io - సెప్టెంబర్'2020 నాటికి.

ఈ పారామితుల సమితి నాల్గవ ప్రమాణాన్ని సంతృప్తి పరచడానికి సరిపోతుంది - అంటే, సంస్కరణలకు అనుగుణంగా ఉండే చిత్రాలను ఎంచుకోవడానికి. అయితే, అన్ని ఇతర ప్రమాణాల కోసం, అంచనాలు మరియు ఆర్థిక సామర్థ్యాలపై ఆధారపడి - ఒక రకమైన రాజీ పరిష్కారాన్ని (పటిష్టమైన లేదా, దానికి విరుద్ధంగా, మరింత సరళమైన విధానం) ఎంచుకోవాలి.

ఉదాహరణకు, మూడవ ప్రమాణం - డెవలపర్‌ల అవసరాలకు సంబంధించినది - జట్లలో ప్రక్రియలను నిర్వహించడం ద్వారా పరిష్కరించబడుతుంది: చిత్రాలకు నిర్దిష్ట పేరు పెట్టడం, ప్రత్యేక అనుమతి జాబితాలు మరియు అంతర్గత ఒప్పందాలను నిర్వహించడం. కానీ అంతిమంగా ఇది ఇప్పటికీ స్వయంచాలకంగా ఉండాలి. మరియు రెడీమేడ్ పరిష్కారాల సామర్థ్యాలు సరిపోకపోతే, మీరు మీ స్వంతంగా ఏదైనా చేయాలి.

మొదటి రెండు ప్రమాణాలతో పరిస్థితి సారూప్యంగా ఉంటుంది: బాహ్య సిస్టమ్ నుండి డేటాను స్వీకరించకుండా వారు సంతృప్తి చెందలేరు - అప్లికేషన్లు అమలు చేయబడినది (మా విషయంలో, కుబెర్నెట్స్).

Gitలో వర్క్‌ఫ్లో యొక్క ఇలస్ట్రేషన్

మీరు Gitలో ఇలాంటి పని చేస్తున్నారని అనుకుందాం:

రేఖాచిత్రంలో తల ఉన్న చిహ్నం ప్రస్తుతం కుబెర్నెట్స్‌లో ఏ యూజర్‌లకైనా (ముగింపు వినియోగదారులు, టెస్టర్‌లు, మేనేజర్‌లు మొదలైనవి) అమర్చబడిన లేదా డీబగ్గింగ్ మరియు సారూప్య ప్రయోజనాల కోసం డెవలపర్‌లచే ఉపయోగించబడే కంటైనర్ చిత్రాలను సూచిస్తుంది.

క్లీనప్ విధానాలు చిత్రాలను ఉంచడానికి మాత్రమే అనుమతిస్తే ఏమి జరుగుతుంది (తొలగించబడదు) ఇచ్చిన ట్యాగ్ పేర్ల ద్వారా?

సహజంగానే, అటువంటి దృశ్యం ఎవరినీ సంతోషపెట్టదు.

విధానాలు చిత్రాలను తొలగించకుండా అనుమతిస్తే ఏమి మారుతుంది? ఇచ్చిన సమయ విరామం / చివరి కమిట్‌ల సంఖ్య ప్రకారం?

ఫలితం మెరుగ్గా మారింది, కానీ ఇప్పటికీ ఆదర్శానికి దూరంగా ఉంది. అన్నింటికంటే, బగ్‌లను డీబగ్ చేయడానికి రిజిస్ట్రీలో (లేదా K8లలో కూడా అమర్చబడినవి) ఇమేజ్‌లు అవసరమయ్యే డెవలపర్‌లను మేము కలిగి ఉన్నాము...

ప్రస్తుత మార్కెట్ పరిస్థితిని సంగ్రహంగా చెప్పాలంటే: కంటైనర్ రిజిస్ట్రీలలో లభించే విధులు శుభ్రపరిచేటప్పుడు తగినంత సౌలభ్యాన్ని అందించవు మరియు దీనికి ప్రధాన కారణం బయటి ప్రపంచంతో సంభాషించడానికి మార్గం లేదు. అటువంటి సౌలభ్యం అవసరమయ్యే బృందాలు డాకర్ రిజిస్ట్రీ API (లేదా సంబంధిత అమలు యొక్క స్థానిక API) ఉపయోగించి "బయటి నుండి" చిత్ర తొలగింపును స్వతంత్రంగా అమలు చేయవలసి వస్తుంది.

అయితే, మేము విభిన్న రిజిస్ట్రీలను ఉపయోగించి వేర్వేరు బృందాల కోసం ఇమేజ్ క్లీనప్‌ను ఆటోమేట్ చేసే సార్వత్రిక పరిష్కారం కోసం చూస్తున్నాము...

యూనివర్సల్ ఇమేజ్ క్లీనింగ్‌కి మా మార్గం

ఈ అవసరం ఎక్కడ నుండి వస్తుంది? వాస్తవం ఏమిటంటే, మేము డెవలపర్‌ల యొక్క ప్రత్యేక సమూహం కాదు, కానీ CI/CD సమస్యలను సమగ్రంగా పరిష్కరించడంలో సహాయపడే అనేకమందికి ఒకేసారి సేవలందించే బృందం. మరియు దీనికి ప్రధాన సాంకేతిక సాధనం ఓపెన్ సోర్స్ యుటిలిటీ వర్ఫ్. దీని విశిష్టత ఏమిటంటే ఇది ఒకే ఫంక్షన్‌ను నిర్వహించదు, కానీ అన్ని దశలలో నిరంతర డెలివరీ ప్రక్రియలతో పాటుగా ఉంటుంది: అసెంబ్లీ నుండి విస్తరణ వరకు.

రిజిస్ట్రీకి చిత్రాలను ప్రచురించడం* (అవి నిర్మించబడిన వెంటనే) అటువంటి యుటిలిటీ యొక్క స్పష్టమైన విధి. మరియు చిత్రాలు నిల్వ కోసం అక్కడ ఉంచబడినందున, అప్పుడు - మీ నిల్వ అపరిమితంగా లేకపోతే - మీరు వాటిని తదుపరి శుభ్రపరచడానికి బాధ్యత వహించాలి. మేము ఇందులో ఎలా విజయం సాధించాము, పేర్కొన్న అన్ని ప్రమాణాలను సంతృప్తి పరచడం, మరింత చర్చించబడుతుంది.

* రిజిస్ట్రీలు వేర్వేరుగా ఉన్నప్పటికీ (డాకర్ రిజిస్ట్రీ, గిట్‌ల్యాబ్ కంటైనర్ రిజిస్ట్రీ, హార్బర్ మొదలైనవి), వారి వినియోగదారులు అదే సమస్యలను ఎదుర్కొంటారు. మా విషయంలో సార్వత్రిక పరిష్కారం రిజిస్ట్రీ అమలుపై ఆధారపడి ఉండదు, ఎందుకంటే రిజిస్ట్రీల వెలుపల నడుస్తుంది మరియు అందరికీ ఒకే విధమైన ప్రవర్తనను అందిస్తుంది.

మేము werfని ఉదాహరణగా అమలు చేస్తున్నప్పటికీ, ఉపయోగించిన విధానాలు ఇలాంటి ఇబ్బందులను ఎదుర్కొంటున్న ఇతర బృందాలకు ఉపయోగకరంగా ఉంటాయని మేము ఆశిస్తున్నాము.

అలా బిజీ అయిపోయాం బాహ్య చిత్రాలను శుభ్రపరిచే యంత్రాంగాన్ని అమలు చేయడం - కంటైనర్ల కోసం రిజిస్ట్రీలలో ఇప్పటికే నిర్మించబడిన సామర్థ్యాలకు బదులుగా. ట్యాగ్‌ల సంఖ్య మరియు వాటి సృష్టి సమయం (పైన పేర్కొన్నది) కోసం అదే ఆదిమ విధానాలను రూపొందించడానికి డాకర్ రిజిస్ట్రీ APIని ఉపయోగించడం మొదటి దశ. వాటికి జోడించారు అమలు చేయబడిన మౌలిక సదుపాయాలలో ఉపయోగించిన చిత్రాల ఆధారంగా జాబితాను అనుమతించండి, అనగా కుబెర్నెటీస్. తరువాతి కోసం, అమలు చేయబడిన అన్ని వనరుల ద్వారా పునరావృతం చేయడానికి మరియు విలువల జాబితాను పొందడానికి Kubernetes APIని ఉపయోగించడం సరిపోతుంది. image.

ఈ పనికిమాలిన పరిష్కారం అత్యంత క్లిష్టమైన సమస్యను (ప్రమాణ సంఖ్య 1) పరిష్కరించింది, కానీ శుభ్రపరిచే యంత్రాంగాన్ని మెరుగుపరచడానికి మా ప్రయాణం ప్రారంభం మాత్రమే. తదుపరి - మరియు మరింత ఆసక్తికరమైన - దశ నిర్ణయం Git చరిత్రతో ప్రచురించిన చిత్రాలను అనుబంధించండి.

ట్యాగింగ్ పథకాలు

ప్రారంభించడానికి, మేము తుది చిత్రం శుభ్రపరచడానికి అవసరమైన సమాచారాన్ని నిల్వ చేసే విధానాన్ని ఎంచుకున్నాము మరియు ట్యాగింగ్ స్కీమ్‌లపై ప్రక్రియను రూపొందించాము. చిత్రాన్ని ప్రచురించేటప్పుడు, వినియోగదారు నిర్దిష్ట ట్యాగింగ్ ఎంపికను ఎంచుకున్నారు (git-branch, git-commit లేదా git-tag) మరియు సంబంధిత విలువను ఉపయోగించారు. CI సిస్టమ్స్‌లో, పర్యావరణ వేరియబుల్స్ ఆధారంగా ఈ విలువలు స్వయంచాలకంగా సెట్ చేయబడ్డాయి. నిజానికి చివరి చిత్రం నిర్దిష్ట Git ఆదిమతో అనుబంధించబడింది, లేబుల్‌లలో శుభ్రపరచడానికి అవసరమైన డేటాను నిల్వ చేస్తుంది.

ఈ విధానం Gitని సత్యం యొక్క ఏకైక మూలంగా ఉపయోగించడానికి అనుమతించే విధానాల సమితికి దారితీసింది:

• Gitలో ఒక శాఖ/ట్యాగ్‌ని తొలగిస్తున్నప్పుడు, రిజిస్ట్రీలోని అనుబంధిత చిత్రాలు స్వయంచాలకంగా తొలగించబడతాయి.
• ఎంచుకున్న స్కీమాలో ఉపయోగించిన ట్యాగ్‌ల సంఖ్య మరియు అనుబంధిత కమిట్ సృష్టించబడిన సమయం ద్వారా Git ట్యాగ్‌లు మరియు కమిట్‌లతో అనుబంధించబడిన చిత్రాల సంఖ్యను నియంత్రించవచ్చు.

మొత్తంమీద, ఫలితంగా అమలు చేయడం మా అవసరాలను సంతృప్తిపరిచింది, అయితే త్వరలో మాకు కొత్త సవాలు ఎదురుకానుంది. వాస్తవం ఏమిటంటే, Git ఆదిమాంశాల ఆధారంగా ట్యాగింగ్ స్కీమ్‌లను ఉపయోగిస్తున్నప్పుడు, మేము అనేక లోపాలను ఎదుర్కొన్నాము. (వారి వివరణ ఈ కథనం యొక్క పరిధికి మించినది కాబట్టి, ప్రతి ఒక్కరూ తమ వివరాలతో తమను తాము పరిచయం చేసుకోవచ్చు ఇక్కడ.) అందువల్ల, ట్యాగింగ్ (కంటెంట్ ఆధారిత ట్యాగింగ్)కు మరింత సమర్థవంతమైన విధానానికి మారాలని నిర్ణయించుకున్నందున, మేము ఇమేజ్ క్లీనింగ్ అమలును పునఃపరిశీలించవలసి వచ్చింది.

కొత్త అల్గోరిథం

ఎందుకు? కంటెంట్-ఆధారిత ట్యాగింగ్‌తో, ప్రతి ట్యాగ్ Gitలో బహుళ కమిట్‌లను తీర్చగలదు. చిత్రాలను శుభ్రపరిచేటప్పుడు, మీరు ఇకపై ఊహించలేరు మాత్రమే రిజిస్ట్రీకి కొత్త ట్యాగ్ జోడించబడిన కమిట్ నుండి.

కొత్త శుభ్రపరిచే అల్గోరిథం కోసం, ట్యాగింగ్ స్కీమ్‌ల నుండి దూరంగా వెళ్లి నిర్మించాలని నిర్ణయించారు మెటా-ఇమేజ్ ప్రక్రియ, వీటిలో ప్రతి ఒక్కటి సమూహాన్ని నిల్వ చేస్తుంది:

• ప్రచురణ ప్రదర్శించబడిన నిబద్ధత (కంటెయినర్ రిజిస్ట్రీలో చిత్రం జోడించబడిందా, మార్చబడిందా లేదా అలాగే ఉండిపోయిందా అనేది పట్టింపు లేదు);
• మరియు మా అంతర్గత ఐడెంటిఫైయర్ సమీకరించబడిన చిత్రానికి అనుగుణంగా ఉంటుంది.

మరో మాటలో చెప్పాలంటే, ఇది అందించబడింది Gitలో కమిట్‌లతో ప్రచురించబడిన ట్యాగ్‌లను లింక్ చేయడం.

తుది కాన్ఫిగరేషన్ మరియు సాధారణ అల్గోరిథం

శుభ్రపరచడాన్ని కాన్ఫిగర్ చేస్తున్నప్పుడు, వినియోగదారులు ఇప్పుడు ప్రస్తుత చిత్రాలను ఎంచుకునే విధానాలకు ప్రాప్యతను కలిగి ఉన్నారు. అటువంటి ప్రతి విధానం నిర్వచించబడింది:

• అనేక సూచనలు, అనగా. స్కానింగ్ సమయంలో ఉపయోగించే Git ట్యాగ్‌లు లేదా Git శాఖలు;
• మరియు సెట్ నుండి ప్రతి సూచన కోసం శోధించిన చిత్రాల పరిమితి.

వివరించడానికి, డిఫాల్ట్ పాలసీ కాన్ఫిగరేషన్ ఇలా కనిపించడం ప్రారంభించింది:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ఈ కాన్ఫిగరేషన్ కింది నియమాలకు అనుగుణంగా మూడు విధానాలను కలిగి ఉంది:

1. చివరి 10 Git ట్యాగ్‌ల కోసం చిత్రాన్ని సేవ్ చేయండి (ట్యాగ్ సృష్టి తేదీ ద్వారా).
2. గత వారంలో కార్యాచరణతో 2 కంటే ఎక్కువ థ్రెడ్‌ల కోసం గత వారంలో ప్రచురించబడిన 10 చిత్రాల కంటే ఎక్కువ సేవ్ చేయవద్దు.
3. శాఖల కోసం 10 చిత్రాలను సేవ్ చేయండి main, staging и production.

చివరి అల్గోరిథం క్రింది దశలకు మరుగుతుంది:

• కంటైనర్ రిజిస్ట్రీ నుండి మానిఫెస్ట్‌లను తిరిగి పొందడం.
• కుబెర్నెట్స్‌లో ఉపయోగించిన చిత్రాలను మినహాయించి, ఎందుకంటే K8s APIని పోలింగ్ చేయడం ద్వారా మేము ఇప్పటికే వాటిని ముందే ఎంచుకున్నాము.
• Git చరిత్రను స్కాన్ చేయడం మరియు పేర్కొన్న విధానాల ఆధారంగా చిత్రాలను మినహాయించడం.
• మిగిలిన చిత్రాలను తీసివేస్తోంది.

మా ఉదాహరణకి తిరిగి వెళితే, వెర్ఫ్‌తో ఇలా జరుగుతుంది:

అయినప్పటికీ, మీరు werfని ఉపయోగించనప్పటికీ, అధునాతన ఇమేజ్ క్లీనింగ్‌కి సారూప్యమైన విధానం - ఒక ఇంప్లిమెంటేషన్‌లో లేదా మరొకటి (ఇమేజ్ ట్యాగింగ్‌కు ప్రాధాన్య విధానం ప్రకారం) - ఇతర సిస్టమ్‌లు/యుటిలిటీలకు వర్తించవచ్చు. ఇది చేయుటకు, ఉత్పన్నమయ్యే సమస్యలను గుర్తుంచుకోవడం మరియు మీ స్టాక్‌లో ఆ అవకాశాలను కనుగొనడం సరిపోతుంది, అది వారి పరిష్కారాన్ని సాధ్యమైనంత సజావుగా ఏకీకృతం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మేము ప్రయాణించిన మార్గం మీ ప్రత్యేక కేసును కొత్త వివరాలు మరియు ఆలోచనలతో చూడటానికి మీకు సహాయపడుతుందని మేము ఆశిస్తున్నాము.

తీర్మానం

• ముందుగానే లేదా తరువాత, చాలా జట్లు రిజిస్ట్రీ ఓవర్‌ఫ్లో సమస్యను ఎదుర్కొంటాయి.
• పరిష్కారాల కోసం శోధిస్తున్నప్పుడు, చిత్రం యొక్క ఔచిత్యం కోసం ప్రమాణాలను గుర్తించడం మొదట అవసరం.
• జనాదరణ పొందిన కంటైనర్ రిజిస్ట్రీ సేవలు అందించే సాధనాలు "బయటి ప్రపంచం"ని పరిగణనలోకి తీసుకోని చాలా సరళమైన క్లీనప్‌ను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తాయి: కుబెర్నెట్స్‌లో ఉపయోగించిన చిత్రాలు మరియు బృందం యొక్క వర్క్‌ఫ్లోల యొక్క విశేషాలు.
• అనువైన మరియు సమర్థవంతమైన అల్గోరిథం తప్పనిసరిగా CI/CD ప్రక్రియలపై అవగాహన కలిగి ఉండాలి మరియు డాకర్ ఇమేజ్ డేటాతో మాత్రమే కాకుండా పని చేస్తుంది.

PS

మా బ్లాగులో కూడా చదవండి:

• «వెర్ఫ్ కలెక్టర్‌లో కంటెంట్-ఆధారిత ట్యాగింగ్: ఇది ఎందుకు మరియు ఎలా పని చేస్తుంది?";
• «వెర్ఫ్‌కి 3-మార్గం విలీనం: హెల్మ్ “స్టెరాయిడ్స్‌పై”తో కుబెర్నెటెస్‌కు విస్తరణ";
• «వెర్ఫ్‌లో మోనోరెపో మరియు మల్టీరెపోకు మద్దతు మరియు డాకర్ రిజిస్ట్రీ దానితో ఏమి చేయాలి";
• «werf 1.1 విడుదల: ఈ రోజు బిల్డర్‌కు మెరుగుదలలు మరియు భవిష్యత్తు కోసం ప్రణాళికలు".

మూలం: www.habr.com