ప్రోహోస్టర్ > బ్లాగ్ > పరిపాలన > మీరు ఇప్పుడు సాధారణ డాకర్‌ఫైల్‌ని ఉపయోగించి వెర్ఫ్‌లో డాకర్ చిత్రాలను రూపొందించవచ్చు

మీరు ఇప్పుడు సాధారణ డాకర్‌ఫైల్‌ని ఉపయోగించి వెర్ఫ్‌లో డాకర్ చిత్రాలను రూపొందించవచ్చు

ఎప్పుడూ కంటే ఆలస్యం చేయడం మంచిది. లేదా అనువర్తన చిత్రాలను రూపొందించడానికి సాధారణ డాకర్‌ఫైల్‌లకు మద్దతు లేకపోవడం ద్వారా మేము దాదాపుగా ఎలా తీవ్రమైన తప్పు చేసాము.

మీరు ఇప్పుడు సాధారణ డాకర్‌ఫైల్‌ని ఉపయోగించి వెర్ఫ్‌లో డాకర్ చిత్రాలను రూపొందించవచ్చు

గురించి మాట్లాడతాం వర్ఫ్ — ఏదైనా CI/CD సిస్టమ్‌తో అనుసంధానించే GitOps యుటిలిటీ మరియు మొత్తం అప్లికేషన్ లైఫ్‌సైకిల్ నిర్వహణను అందిస్తుంది, వీటిని అనుమతిస్తుంది:

  • చిత్రాలను సేకరించి ప్రచురించండి,
  • కుబెర్నెట్స్‌లో అప్లికేషన్‌లను అమలు చేయండి,
  • ప్రత్యేక విధానాలను ఉపయోగించి ఉపయోగించని చిత్రాలను తొలగించండి.


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

నేపథ్యం: మీ స్వంత ఇమేజ్ కలెక్టర్

వెర్ఫ్‌లోని ఇమేజ్ కలెక్టర్‌తో ఇలా జరిగింది: సాధారణ డాకర్‌ఫైల్ మాకు సరిపోలేదు. మీరు ప్రాజెక్ట్ చరిత్రను శీఘ్రంగా పరిశీలించినట్లయితే, ఈ సమస్య ఇప్పటికే werf యొక్క మొదటి సంస్కరణల్లో కనిపించింది (అప్పుడు ఇప్పటికీ డప్ అని పిలుస్తారు).

డాకర్ ఇమేజ్‌లుగా అప్లికేషన్‌లను రూపొందించడానికి ఒక సాధనాన్ని సృష్టిస్తున్నప్పుడు, కొన్ని నిర్దిష్టమైన పనుల కోసం డాకర్‌ఫైల్ మాకు తగినది కాదని మేము త్వరగా గ్రహించాము:

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

ఈ రోజు మా కలెక్టర్‌కు అనేక ఇతర అవకాశాలు ఉన్నాయి, కానీ ఇవి ప్రారంభ కోరికలు మరియు కోరికలు.

సాధారణంగా, రెండుసార్లు ఆలోచించకుండా, మేము ఉపయోగించిన ప్రోగ్రామింగ్ భాషతో మమ్మల్ని ఆయుధాలు చేసుకున్నాము (కింద చూడుము) మరియు అమలు చేయడానికి రహదారిని నొక్కండి సొంత DSL! లక్ష్యాలకు అనుగుణంగా, అసెంబ్లీ ప్రక్రియను దశల్లో వివరించడానికి మరియు ఫైళ్లపై ఈ దశల డిపెండెన్సీలను నిర్ణయించడానికి ఉద్దేశించబడింది. మరియు దానిని పూర్తి చేసింది సొంత కలెక్టర్, ఇది DSLని చివరి లక్ష్యంగా మార్చింది - అసెంబుల్డ్ ఇమేజ్. మొదట DSL రూబీలో ఉంది, కానీ గోలాంగ్‌కు మార్పు — మా కలెక్టర్ యొక్క కాన్ఫిగర్ YAML ఫైల్‌లో వివరించడం ప్రారంభించబడింది.

మీరు ఇప్పుడు సాధారణ డాకర్‌ఫైల్‌ని ఉపయోగించి వెర్ఫ్‌లో డాకర్ చిత్రాలను రూపొందించవచ్చు
రూబీలో డాప్ కోసం పాత కాన్ఫిగర్

మీరు ఇప్పుడు సాధారణ డాకర్‌ఫైల్‌ని ఉపయోగించి వెర్ఫ్‌లో డాకర్ చిత్రాలను రూపొందించవచ్చు
YAMLలో werf కోసం ప్రస్తుత కాన్ఫిగర్

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

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

సమస్యపై అవగాహన

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

ఈ ప్రశ్నకు సమాధానమివ్వడానికి బదులుగా, మేము ఒక పరిష్కారాన్ని అందిస్తున్నాము. మీరు ఇప్పటికే డాకర్‌ఫైల్ (లేదా డాకర్ ఫైల్‌ల సెట్)ని కలిగి ఉంటే మరియు werfని ఉపయోగించాలనుకుంటే ఏమి చేయాలి?

NB: మార్గం ద్వారా, మీరు వెర్ఫ్‌ని ఎందుకు ఉపయోగించాలనుకుంటున్నారు? ప్రధాన లక్షణాలు క్రిందికి వస్తాయి:

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

వాటి యొక్క పూర్తి జాబితాను ఇక్కడ చూడవచ్చు ప్రాజెక్ట్ పేజీ.

కాబట్టి, ఇంతకుముందు మేము మా కాన్ఫిగరేషన్‌లో డాకర్‌ఫైల్‌ను తిరిగి వ్రాయమని ఆఫర్ చేసి ఉంటే, ఇప్పుడు మేము సంతోషంగా చెబుతాము: “వెర్ఫ్ మీ డాకర్‌ఫైల్‌లను నిర్మించనివ్వండి!”

ఎలా ఉపయోగించాలి?

ఈ ఫీచర్ యొక్క పూర్తి అమలు విడుదలలో కనిపించింది 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 config ద్వారా. డాకర్‌ఫైల్ ఇమేజ్ కాన్ఫిగరేషన్ యొక్క పూర్తి వివరణ ఇక్కడ అందుబాటులో ఉంది డాక్యుమెంటేషన్ పేజీ.

అది ఎలా పనిచేస్తుంది?

నిర్మాణ ప్రక్రియలో, డాకర్ ఫంక్షన్లలో స్థానిక లేయర్‌ల ప్రామాణిక కాష్. అయితే, ముఖ్యమైనది ఏమిటంటే అది కూడా వర్ఫ్ డాకర్‌ఫైల్ కాన్ఫిగరేషన్‌ను దాని ఇన్‌ఫ్రాస్ట్రక్చర్‌లో అనుసంధానిస్తుంది. దీని అర్థం ఏమిటి?

  1. డాకర్‌ఫైల్ నుండి నిర్మించబడిన ప్రతి చిత్రం ఒక దశను కలిగి ఉంటుంది dockerfile (వెర్ఫ్‌లో ఏ దశలు ఉన్నాయో మీరు మరింత చదువుకోవచ్చు ఇక్కడ).
  2. వేదిక కోసం dockerfile werf డాకర్‌ఫైల్ కాన్ఫిగరేషన్‌లోని విషయాలపై ఆధారపడిన సంతకాన్ని గణిస్తుంది. డాకర్‌ఫైల్ కాన్ఫిగరేషన్ మారినప్పుడు, స్టేజ్ సిగ్నేచర్ మారుతుంది dockerfile మరియు werf కొత్త డాకర్‌ఫైల్ కాన్ఫిగర్‌తో ఈ దశ యొక్క పునర్నిర్మాణాన్ని ప్రారంభిస్తుంది. సంతకం మారకపోతే, werf కాష్ నుండి చిత్రాన్ని తీసుకుంటుంది (వెర్ఫ్‌లో సంతకాల వినియోగం గురించి మరిన్ని వివరాలు వివరించబడ్డాయి ఈ నివేదిక).
  3. తరువాత, సేకరించిన చిత్రాలను ఆదేశంతో ప్రచురించవచ్చు werf publish (లేదా werf build-and-publish) మరియు కుబెర్నెట్‌లకు విస్తరణ కోసం దీన్ని ఉపయోగించండి. డాకర్ రిజిస్ట్రీకి ప్రచురించబడిన చిత్రాలు ప్రామాణిక వెర్ఫ్ క్లీనప్ సాధనాలను ఉపయోగించి శుభ్రపరచబడతాయి, అనగా. పాత చిత్రాలు (N రోజుల కంటే పాతవి), ఉనికిలో లేని Git శాఖలతో అనుబంధించబడిన చిత్రాలు మరియు ఇతర విధానాలు స్వయంచాలకంగా శుభ్రపరచబడతాయి.

ఇక్కడ వివరించిన పాయింట్ల గురించి మరిన్ని వివరాలను డాక్యుమెంటేషన్‌లో చూడవచ్చు:

గమనికలు మరియు జాగ్రత్తలు

1. ADDలో బాహ్య URLకి మద్దతు లేదు

ప్రస్తుతం ఇది డైరెక్టివ్‌లో బాహ్య URLని ఉపయోగించడానికి మద్దతు లేదు ADD. పేర్కొన్న URL వద్ద వనరు మారినప్పుడు వెర్ఫ్ పునర్నిర్మాణాన్ని ప్రారంభించదు. మేము త్వరలో ఈ ఫీచర్‌ని జోడించాలనుకుంటున్నాము.

2. మీరు చిత్రానికి .git జోడించలేరు

సాధారణంగా చెప్పాలంటే, డైరెక్టరీని జోడించడం .git చిత్రంలో - ఒక దుర్మార్గపు చెడు అభ్యాసం మరియు ఇక్కడ ఎందుకు ఉంది:

  1. ఉంటే .git తుది చిత్రంలో ఉంటుంది, ఇది సూత్రాలను ఉల్లంఘిస్తుంది 12 కారకాల యాప్: తుది చిత్రం తప్పనిసరిగా ఒకే కమిట్‌తో లింక్ చేయబడాలి కాబట్టి, అది చేయడం సాధ్యం కాదు git checkout ఏకపక్ష నిబద్ధత.
  2. .git చిత్రం యొక్క పరిమాణాన్ని పెంచుతుంది (రిపోజిటరీ పెద్ద ఫైల్‌లు ఒకసారి దానికి జోడించబడి ఆపై తొలగించబడినందున పెద్దదిగా ఉండవచ్చు). నిర్దిష్ట కమిట్‌తో మాత్రమే అనుబంధించబడిన పని చెట్టు పరిమాణం Gitలో కార్యకలాపాల చరిత్రపై ఆధారపడి ఉండదు. ఈ సందర్భంలో, అదనంగా మరియు తదుపరి తొలగింపు .git చివరి చిత్రం నుండి పని చేయదు: చిత్రం ఇప్పటికీ అదనపు పొరను పొందుతుంది - ఈ విధంగా డాకర్ పని చేస్తుంది.
  3. అదే కమిట్‌ను నిర్మించినప్పటికీ, వేర్వేరు పని చెట్ల నుండి డాకర్ అనవసరమైన పునర్నిర్మాణాన్ని ప్రారంభించవచ్చు. ఉదాహరణకు, GitLab ప్రత్యేక క్లోన్ చేసిన డైరెక్టరీలను సృష్టిస్తుంది /home/gitlab-runner/builds/HASH/[0-N]/yourproject సమాంతర అసెంబ్లీ ప్రారంభించబడినప్పుడు. అదనపు రీఅసెంబ్లీ డైరెక్టరీ కారణంగా ఉంటుంది .git అదే నిబద్ధత నిర్మించబడినప్పటికీ, ఒకే రిపోజిటరీ యొక్క వివిధ క్లోన్ చేసిన సంస్కరణల్లో భిన్నంగా ఉంటుంది.

వెర్ఫ్‌ను ఉపయోగించినప్పుడు చివరి పాయింట్ కూడా పరిణామాలను కలిగి ఉంటుంది. కొన్ని ఆదేశాలను అమలు చేస్తున్నప్పుడు (ఉదా. werf deploy) ఈ ఆదేశాలను అమలు చేసినప్పుడు, werf పేర్కొన్న చిత్రాలకు దశ సంతకాలను గణిస్తుంది werf.yaml, మరియు అవి తప్పనిసరిగా అసెంబ్లీ కాష్‌లో ఉండాలి - లేకపోతే కమాండ్ పనిని కొనసాగించదు. స్టేజ్ సంతకం కంటెంట్‌పై ఆధారపడి ఉంటే .git, అప్పుడు మేము అసంబద్ధమైన ఫైల్‌లలో మార్పులకు అస్థిరంగా ఉండే కాష్‌ని పొందుతాము మరియు werf అటువంటి పర్యవేక్షణను క్షమించలేరు (మరిన్ని వివరాల కోసం, చూడండి డాక్యుమెంటేషన్).

సాధారణంగా అవసరమైన కొన్ని ఫైళ్లను మాత్రమే జోడించడం సూచనల ద్వారా ADD ఏదైనా సందర్భంలో వ్రాసిన సామర్థ్యం మరియు విశ్వసనీయతను పెంచుతుంది Dockerfile, మరియు దీని కోసం సేకరించిన కాష్ యొక్క స్థిరత్వాన్ని కూడా మెరుగుపరుస్తుంది Dockerfile, Gitలో అసంబద్ధమైన మార్పులకు.

ఫలితం

నిర్దిష్ట అవసరాల కోసం మా స్వంత బిల్డర్‌ను వ్రాయడానికి మా ప్రారంభ మార్గం కఠినంగా, నిజాయితీగా మరియు సూటిగా ఉంటుంది: ప్రామాణిక డాకర్‌ఫైల్ పైన క్రాచెస్‌ని ఉపయోగించకుండా, మేము మా పరిష్కారాన్ని అనుకూల సింటాక్స్‌తో వ్రాసాము. మరియు ఇది దాని ప్రయోజనాలను కలిగి ఉంది: స్టెపెల్ కలెక్టర్ దాని పనిని సంపూర్ణంగా ఎదుర్కుంటుంది.

అయినప్పటికీ, మా స్వంత బిల్డర్‌ను వ్రాసే ప్రక్రియలో, మేము ఇప్పటికే ఉన్న డాకర్‌ఫైల్‌లకు మద్దతును కోల్పోయాము. ఈ లోపం ఇప్పుడు పరిష్కరించబడింది మరియు భవిష్యత్తులో మేము పంపిణీ చేయబడిన బిల్డ్‌ల కోసం మరియు కుబెర్నెట్‌లను (అంటే కనికోలో చేసినట్లుగా కుబెర్నెటెస్‌లోని రన్నర్‌లపై బిల్డ్ చేయడం) కోసం మా కస్టమ్ స్టాపెల్ బిల్డర్‌తో పాటు డాకర్‌ఫైల్ మద్దతును అభివృద్ధి చేయాలని ప్లాన్ చేస్తున్నాము.

కాబట్టి, మీరు అకస్మాత్తుగా రెండు డాకర్‌ఫైల్‌లను కలిగి ఉంటే... ప్రయత్నించండి వర్ఫ్!

PS అంశంపై డాక్యుమెంటేషన్ జాబితా

మా బ్లాగులో కూడా చదవండి: "werf - Kubernetes లో CI / CD కోసం మా సాధనం (అవలోకనం మరియు వీడియో నివేదిక)".

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి