ఏదో ఒక సమయంలో నేను డాకర్ కంటైనర్లు మరియు డెబ్ ప్యాకేజీల రూపంలో డెలివరీ గురించి ఒక కథనాన్ని వ్రాయాలని నిర్ణయించుకున్నాను, కానీ నేను ప్రారంభించినప్పుడు, కొన్ని కారణాల వల్ల నేను మొదటి వ్యక్తిగత కంప్యూటర్లు మరియు కాలిక్యులేటర్ల సుదూర కాలాలకు తిరిగి తీసుకువెళ్లాను. సాధారణంగా, డాకర్ మరియు డెబ్ యొక్క పొడి పోలికలకు బదులుగా, పరిణామం అనే అంశంపై మేము ఈ ఆలోచనలను పొందాము, దీనిని నేను మీ పరిశీలన కోసం అందిస్తున్నాను.
ఏదైనా ఉత్పత్తి, అది ఏమైనప్పటికీ, ఏదో ఒకవిధంగా ఉత్పత్తి సర్వర్‌లకు చేరుకోవాలి, తప్పనిసరిగా కాన్ఫిగర్ చేయబడి, ప్రారంభించబడాలి. దాని గురించి ఈ వ్యాసం ఉంటుంది.
నేను ఒక చారిత్రాత్మక సందర్భంలో ఆలోచిస్తాను, "నేను దేని గురించి పాడతాను," నేను మొదట కోడ్ రాయడం ప్రారంభించినప్పుడు నేను చూసినవి మరియు ఇప్పుడు నేను గమనించినవి, ఈ సమయంలో మనం ఏమి ఉపయోగిస్తున్నాము మరియు ఎందుకు ఉపయోగిస్తున్నాము. వ్యాసం పూర్తి స్థాయి అధ్యయనం వలె నటించలేదు, కొన్ని పాయింట్లు తప్పిపోయాయి, ఇది నా వ్యక్తిగత అభిప్రాయం మరియు ఇప్పుడు ఏమి ఉంది.
కాబట్టి, మంచి పాత రోజుల్లో... నేను కనుగొన్న తొలి డెలివరీ పద్ధతి టేప్ రికార్డర్ల నుండి క్యాసెట్ టేపులను. నా దగ్గర కంప్యూటర్ BK-0010.01 ఉంది...
కాలిక్యులేటర్ల యుగం
లేదు, అంతకు ముందు క్షణం కూడా ఉంది, కాలిక్యులేటర్ కూడా ఉంది и .
కాబట్టి నేను కలిగి ఉన్నప్పుడు , అప్పుడు ప్రోగ్రామ్‌ను బదిలీ చేయడానికి మార్గం ఒక పెట్టెలో ఒక సాధారణ కాగితం ముక్క, దానిపై ప్రోగ్రామ్ వ్రాయబడింది, అవసరమైతే, దానిని మాన్యువల్‌గా అమలు చేయడానికి, కాలిక్యులేటర్‌లో వ్రాయబడుతుంది. మీరు ప్లే చేయాలనుకుంటే (అవును, ఈ యాంటిడిలువియన్ కాలిక్యులేటర్‌లో కూడా గేమ్‌లు ఉన్నాయి) - మీరు కూర్చుని ప్రోగ్రామ్‌ను కాలిక్యులేటర్‌లోకి నమోదు చేయండి. సహజంగానే, కాలిక్యులేటర్ ఆపివేయబడినప్పుడు, ప్రోగ్రామ్ ఉపేక్షలో అదృశ్యమైంది. తన చేతిలో కాగితంపై వ్రాసిన కాలిక్యులేటర్ కోడ్‌లతో పాటు, కార్యక్రమాలు “రేడియో” మరియు “టెక్నాలజీ ఫర్ యూత్” పత్రికలలో ప్రచురించబడ్డాయి మరియు ఆ కాలపు పుస్తకాలలో కూడా ప్రచురించబడ్డాయి.
తదుపరి మార్పు కాలిక్యులేటర్ , ఇది ఇప్పటికే అస్థిర డేటా నిల్వ యొక్క కొంత పోలికను కలిగి ఉంది. ఇప్పుడు గేమ్ లేదా ప్రోగ్రామ్ మాన్యువల్‌గా నమోదు చేయవలసిన అవసరం లేదు, కానీ బటన్‌లతో కొన్ని మాయా పాస్‌లను ప్రదర్శించిన తర్వాత, అది స్వయంగా లోడ్ అవుతుంది.
కాలిక్యులేటర్‌లోని అతిపెద్ద ప్రోగ్రామ్ యొక్క పరిమాణం 105 దశలు మరియు MK-52లో శాశ్వత మెమరీ పరిమాణం 512 దశలు.
మార్గం ద్వారా, ఈ కథనాన్ని చదువుతున్న ఈ కాలిక్యులేటర్ల అభిమానులు ఉంటే, కథనాన్ని వ్రాసే ప్రక్రియలో నేను Android కోసం కాలిక్యులేటర్ ఎమ్యులేటర్ మరియు దాని కోసం ప్రోగ్రామ్‌లను కనుగొన్నాను. గతానికి ముందుకు!
MK-52 గురించి చిన్న డైగ్రెషన్ (వికీపీడియా నుండి)
సోయుజ్ TM-52 అంతరిక్ష నౌకలో MK-7 అంతరిక్షంలోకి వెళ్లింది. ఆన్-బోర్డ్ కంప్యూటర్ విఫలమైతే ల్యాండింగ్ పథాన్ని లెక్కించడానికి ఇది ఉపయోగించబడాలి.
52 నుండి, ఎలెక్ట్రోనికా-ఆస్ట్రో మెమరీ విస్తరణ యూనిట్‌తో కూడిన MK-1988 నావిగేషనల్ కంప్యూటింగ్ కిట్‌లో భాగంగా నేవీ షిప్‌లకు సరఫరా చేయబడింది.
మొదటి వ్యక్తిగత కంప్యూటర్లు
తిరిగి కాలానికి వెళ్దాం . అక్కడ ఎక్కువ మెమరీ ఉందని స్పష్టంగా ఉంది మరియు కాగితం ముక్క నుండి కోడ్‌లో టైప్ చేయడం ఇకపై ఎంపిక కాదు (మొదట నేను అలా చేసాను, ఎందుకంటే వేరే మాధ్యమం లేదు). టేప్ రికార్డర్ల కోసం ఆడియో క్యాసెట్‌లు సాఫ్ట్‌వేర్‌ను నిల్వ చేయడానికి మరియు పంపిణీ చేయడానికి ప్రధాన సాధనంగా మారుతున్నాయి.
క్యాసెట్‌లో నిల్వ సాధారణంగా ఒకటి లేదా రెండు బైనరీ ఫైల్‌ల రూపంలో ఉంటుంది, మిగతావన్నీ లోపల ఉంటాయి. విశ్వసనీయత చాలా తక్కువగా ఉంది, నేను ప్రోగ్రామ్ యొక్క 2-3 కాపీలు ఉంచవలసి వచ్చింది. లోడ్ అయ్యే సమయాలు కూడా నిరుత్సాహకరంగా ఉన్నాయి మరియు ఈ లోపాలను అధిగమించడానికి ఔత్సాహికులు విభిన్న ఫ్రీక్వెన్సీ ఎన్‌కోడింగ్‌లతో ప్రయోగాలు చేశారు. ఆ సమయంలో, నేను ఇంకా ప్రొఫెషనల్ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌లో పాల్గొనలేదు (బేసిక్‌లో సాధారణ ప్రోగ్రామ్‌లను లెక్కించలేదు), కాబట్టి, దురదృష్టవశాత్తు, లోపల ప్రతిదీ ఎలా అమర్చబడిందో నేను మీకు వివరంగా చెప్పను. కంప్యూటర్‌లో చాలా వరకు RAM మాత్రమే ఉందనే వాస్తవం డేటా నిల్వ పథకం యొక్క సరళతను నిర్ణయించింది.
నమ్మదగిన మరియు పెద్ద నిల్వ మీడియా ఆవిర్భావం
తరువాత, ఫ్లాపీ డిస్కులు కనిపించాయి, కాపీ ప్రక్రియ సరళీకృతం చేయబడింది మరియు విశ్వసనీయత పెరిగింది.
కానీ తగినంత పెద్ద స్థానిక నిల్వలు HDDల రూపంలో కనిపించినప్పుడు మాత్రమే పరిస్థితి నాటకీయంగా మారుతుంది.
డెలివరీ రకం ప్రాథమికంగా మారుతోంది: సిస్టమ్‌ను కాన్ఫిగర్ చేసే ప్రక్రియను నిర్వహించే ఇన్‌స్టాలర్ ప్రోగ్రామ్‌లు కనిపిస్తాయి, అలాగే తీసివేసిన తర్వాత శుభ్రపరుస్తాయి, ఎందుకంటే ప్రోగ్రామ్‌లు కేవలం మెమరీలోకి చదవబడవు, కానీ ఇప్పటికే స్థానిక నిల్వకు కాపీ చేయబడ్డాయి, దాని నుండి మీరు వీటిని చేయాలి అవసరమైతే అనవసరమైన విషయాలను క్లియర్ చేయగలరు.
అదే సమయంలో, సరఫరా చేయబడిన సాఫ్ట్‌వేర్ యొక్క సంక్లిష్టత పెరుగుతోంది.
డెలివరీలోని ఫైల్‌ల సంఖ్య కొన్ని నుండి వందలు మరియు వేలకు పెరుగుతుంది, వివిధ ప్రోగ్రామ్‌లు ఒకే డేటాను ఉపయోగించినప్పుడు లైబ్రరీ సంస్కరణలు మరియు ఇతర ఆనందాల మధ్య వైరుధ్యాలు ప్రారంభమవుతాయి.
ఆ సమయంలో, Linux ఉనికి నాకు ఇంకా తెరవబడలేదు; నేను MS DOS మరియు తరువాత, Windows ప్రపంచంలో నివసించాను మరియు బోర్లాండ్ పాస్కల్ మరియు డెల్ఫీలో వ్రాసాను, కొన్నిసార్లు C++ వైపు చూసాను. చాలా మంది వ్యక్తులు ఇన్‌స్టాల్‌షీల్డ్‌ని ఉత్పత్తులను డెలివరీ చేయడానికి ఉపయోగించారు. , ఇది సాఫ్ట్‌వేర్‌ను అమలు చేయడం మరియు కాన్ఫిగర్ చేయడం కోసం కేటాయించిన అన్ని పనులను విజయవంతంగా పరిష్కరించింది.
ఇంటర్నెట్ యుగం
క్రమంగా, సాఫ్ట్‌వేర్ సిస్టమ్‌ల సంక్లిష్టత మరింత క్లిష్టంగా మారుతోంది; ఏకశిలా మరియు డెస్క్‌టాప్ అనువర్తనాల నుండి పంపిణీ చేయబడిన సిస్టమ్‌లు, సన్నని క్లయింట్లు మరియు మైక్రోసర్వీస్‌లకు పరివర్తన ఉంది. ఇప్పుడు మీరు ఒక ప్రోగ్రామ్‌ను మాత్రమే కాకుండా, వాటి సమితిని కాన్ఫిగర్ చేయాలి మరియు అవి అన్నీ కలిసి పని చేస్తాయి.
కాన్సెప్ట్ పూర్తిగా మారిపోయింది, ఇంటర్నెట్ వచ్చింది, క్లౌడ్ సేవల యుగం వచ్చింది. ఇప్పటివరకు, ప్రారంభ దశలో, వెబ్‌సైట్ల రూపంలో, ఎవరూ ప్రత్యేకంగా సేవల గురించి కలలు కన్నారు. కానీ అప్లికేషన్ల అభివృద్ధి మరియు డెలివరీ రెండింటిలోనూ ఇది ఒక మలుపు.
నా విషయానికొస్తే, ఆ సమయంలో డెవలపర్‌ల తరాలలో (లేదా అది నా వాతావరణంలో మాత్రమే) మార్పు వచ్చిందని నేను గుర్తించాను మరియు పాత డెలివరీ పద్ధతులన్నీ ఒక్క క్షణంలో మరచిపోయాయనే భావన ఉంది మరియు ప్రతిదీ చాలా కాలం నుండి ప్రారంభించబడింది. ప్రారంభం: అన్ని డెలివరీలు మోకాలి స్క్రిప్ట్‌లతో చేయడం ప్రారంభించబడ్డాయి మరియు దానిని గర్వంగా "నిరంతర డెలివరీ" అని పిలిచారు. వాస్తవానికి, పాతది మరచిపోయినప్పుడు మరియు ఉపయోగించనప్పుడు మరియు కొత్తది ఉనికిలో లేనప్పుడు గందరగోళ కాలం ప్రారంభమైంది.
మా కంపెనీలో నేను పనిచేసిన సందర్భాలు నాకు గుర్తున్నాయి (నేను పేరు పెట్టను), చీమల ద్వారా నిర్మించే బదులు (మావెన్ ఇంకా ప్రాచుర్యం పొందలేదు లేదా ఉనికిలో లేదు), ప్రజలు IDE లో జాడీలను సేకరించి నిర్మలంగా కట్టుబడి ఉన్నారు. అది SVN లో. దీని ప్రకారం, SVN నుండి ఫైల్‌ను తిరిగి పొందడం మరియు SSH ద్వారా కావలసిన మెషీన్‌కు కాపీ చేయడం విస్తరణలో ఉంటుంది. ఇది చాలా సరళమైనది మరియు వికృతమైనది.
అదే సమయంలో, FTP ద్వారా సరిదిద్దబడిన ఫైల్‌ను లక్ష్య యంత్రానికి కాపీ చేయడం ద్వారా PHPలోని సాధారణ సైట్‌ల డెలివరీ చాలా ప్రాచీనమైన రీతిలో జరిగింది. కొన్నిసార్లు ఇది అలా కాదు - ఉత్పత్తి సర్వర్‌లో కోడ్ ప్రత్యక్షంగా సవరించబడింది మరియు ఎక్కడైనా బ్యాకప్‌లు ఉంటే అది ప్రత్యేకంగా చిక్‌గా ఉంటుంది.
RPM మరియు DEB ప్యాకేజీలు
మరోవైపు, ఇంటర్నెట్ అభివృద్ధితో, UNIX-వంటి వ్యవస్థలు మరింత ప్రజాదరణ పొందడం ప్రారంభించాయి, ప్రత్యేకించి, ఆ సమయంలోనే నేను సుమారు 6లో RedHat Linux 2000ని కనుగొన్నాను. సహజంగానే, సాఫ్ట్‌వేర్ డెలివరీ చేయడానికి కొన్ని మార్గాలు కూడా ఉన్నాయి; వికీపీడియా ప్రకారం, RPM ప్రధాన ప్యాకేజీ మేనేజర్‌గా ఇప్పటికే 1995లో RedHat Linux 2.0 వెర్షన్‌లో కనిపించింది. మరియు అప్పటి నుండి మరియు ఈ రోజు వరకు, సిస్టమ్ RPM ప్యాకేజీల రూపంలో పంపిణీ చేయబడింది మరియు చాలా విజయవంతంగా ఉనికిలో ఉంది మరియు అభివృద్ధి చెందుతోంది.
డెబియన్ కుటుంబం యొక్క పంపిణీలు ఇదే మార్గాన్ని అనుసరించాయి మరియు డెబ్ ప్యాకేజీల రూపంలో డెలివరీని అమలు చేసింది, ఇది నేటికీ మారలేదు.
ప్యాకేజీ నిర్వాహకులు సాఫ్ట్‌వేర్ ఉత్పత్తులను స్వయంగా పంపిణీ చేయడానికి, ఇన్‌స్టాలేషన్ ప్రక్రియలో వాటిని కాన్ఫిగర్ చేయడానికి, విభిన్న ప్యాకేజీల మధ్య డిపెండెన్సీలను నిర్వహించడానికి, ఉత్పత్తులను తీసివేయడానికి మరియు అన్‌ఇన్‌స్టాలేషన్ ప్రక్రియలో అనవసరమైన అంశాలను శుభ్రం చేయడానికి మిమ్మల్ని అనుమతిస్తారు. ఆ. చాలా వరకు, అంతే అవసరం, అందుకే అవి అనేక దశాబ్దాల పాటు వాస్తవంగా మారలేదు.
క్లౌడ్ కంప్యూటింగ్ ప్యాకేజ్ మేనేజర్‌లకు ఫిజికల్ మీడియా నుండి మాత్రమే కాకుండా క్లౌడ్ రిపోజిటరీల నుండి కూడా ఇన్‌స్టాలేషన్‌ను జోడించింది, కానీ ప్రాథమికంగా కొద్దిగానే మార్చబడింది.
ప్రస్తుతం డెబ్ నుండి వైదొలగడానికి మరియు స్నాప్ ప్యాకేజీలకు మారడానికి కొన్ని ఎత్తుగడలు ఉన్నాయని గమనించాలి, అయితే దాని గురించి మరింత ఎక్కువ.
కాబట్టి, DEB లేదా RPM తెలియని ఈ కొత్త తరం క్లౌడ్ డెవలపర్‌లు కూడా నెమ్మదిగా అభివృద్ధి చెందారు, అనుభవాన్ని పొందారు, ఉత్పత్తులు మరింత క్లిష్టంగా మారాయి మరియు FTP, బాష్ స్క్రిప్ట్‌లు మరియు ఇలాంటి విద్యార్థి చేతిపనుల కంటే కొన్ని సహేతుకమైన డెలివరీ పద్ధతులు అవసరం.
మరియు ఇక్కడే డాకర్ చిత్రంలోకి వస్తుంది, వర్చువలైజేషన్, రిసోర్స్ డీలిమిటేషన్ మరియు డెలివరీ పద్ధతి యొక్క ఒక రకమైన మిశ్రమం. ఇది ఇప్పుడు ఫ్యాషన్ మరియు యవ్వనంగా ఉంది, కానీ ప్రతిదానికీ ఇది అవసరమా? ఇదేనా సర్వరోగ నివారిణి?
నా పరిశీలనల నుండి, చాలా తరచుగా డాకర్ ఒక సహేతుకమైన ఎంపికగా ప్రతిపాదించబడదు, కానీ ఒక వైపు, ఇది సంఘంలో మాట్లాడబడుతుంది మరియు దానిని ప్రతిపాదించే వారికి మాత్రమే తెలుసు. మరోవైపు, చాలా వరకు వారు మంచి పాత ప్యాకేజింగ్ సిస్టమ్‌ల గురించి మౌనంగా ఉంటారు - అవి ఉనికిలో ఉన్నాయి మరియు నిశ్శబ్దంగా మరియు గుర్తించబడకుండా తమ పనిని చేస్తాయి. అటువంటి పరిస్థితిలో, నిజంగా వేరే ఎంపిక లేదు - ఎంపిక స్పష్టంగా ఉంది - డాకర్.
మేము డాకర్‌ని ఎలా అమలు చేసాము మరియు దాని ఫలితంగా ఏమి జరిగిందో నా అనుభవాన్ని పంచుకోవడానికి ప్రయత్నిస్తాను.
స్వయంగా వ్రాసిన స్క్రిప్ట్‌లు
ప్రారంభంలో, అవసరమైన యంత్రాలకు జార్ ఆర్కైవ్‌లను అమర్చే బాష్ స్క్రిప్ట్‌లు ఉన్నాయి. ఈ ప్రక్రియను జెంకిన్స్ నిర్వహించారు. జార్ ఆర్కైవ్ ఇప్పటికే తరగతులు, వనరులు మరియు కాన్ఫిగరేషన్‌ను కలిగి ఉన్న అసెంబ్లీ అయినందున ఇది విజయవంతంగా పనిచేసింది. మీరు ప్రతిదీ గరిష్టంగా ఉంచినట్లయితే, దానిని స్క్రిప్ట్‌గా విస్తరించడం మీకు అవసరమైన అత్యంత కష్టమైన విషయం కాదు
కానీ స్క్రిప్ట్‌లకు అనేక ప్రతికూలతలు ఉన్నాయి:
- స్క్రిప్ట్‌లు సాధారణంగా త్వరితగతిన వ్రాయబడతాయి మరియు అవి చాలా ప్రాచీనమైనవి కాబట్టి అవి ఒకే ఒక ఉత్తమ సందర్భాన్ని కలిగి ఉంటాయి. డెవలపర్ వేగవంతమైన డెలివరీ పట్ల ఆసక్తిని కలిగి ఉన్నందున ఇది సులభతరం చేయబడింది మరియు సాధారణ స్క్రిప్ట్‌కు తగిన మొత్తంలో వనరుల పెట్టుబడి అవసరం.
- మునుపటి పాయింట్ యొక్క పర్యవసానంగా, స్క్రిప్ట్‌లు అన్‌ఇన్‌స్టాలేషన్ విధానాలను కలిగి ఉండవు
- ఏర్పాటు చేసిన అప్‌గ్రేడ్ విధానం లేదు
- కొత్త ఉత్పత్తి కనిపించినప్పుడు, మీరు కొత్త స్క్రిప్ట్‌ను వ్రాయాలి
- డిపెండెన్సీ మద్దతు లేదు
వాస్తవానికి, మీరు అధునాతన స్క్రిప్ట్‌ను వ్రాయవచ్చు, కానీ, నేను పైన వ్రాసినట్లుగా, ఇది అభివృద్ధి సమయం, మరియు కనీసం కాదు, మరియు మనకు తెలిసినట్లుగా, ఎల్లప్పుడూ తగినంత సమయం ఉండదు.
ఇవన్నీ స్పష్టంగా ఈ విస్తరణ పద్ధతి యొక్క అప్లికేషన్ పరిధిని సరళమైన సిస్టమ్‌లకు మాత్రమే పరిమితం చేస్తాయి. దీన్ని మార్చుకోవాల్సిన సమయం ఆసన్నమైంది.
డాకర్
ఏదో ఒక సమయంలో, తాజాగా ముద్రించిన మిడిల్స్ మా వద్దకు రావడం ప్రారంభించాయి, ఆలోచనలతో మరియు డాకర్ గురించి ఆరాటపడుతున్నాయి. సరే, చేతిలో జెండా - చేద్దాం! రెండు ప్రయత్నాలు జరిగాయి. రెండూ విఫలమయ్యాయి - గొప్ప ఆశయాల కారణంగా, కానీ నిజమైన అనుభవం లేకపోవడం వల్ల అనుకుందాం. దాన్ని బలవంతంగా పూర్తి చేయాల్సిన అవసరం ఉందా? ఇది అసంభవం - తగిన సాధనాలను ఉపయోగించే ముందు జట్టు తప్పనిసరిగా అవసరమైన స్థాయికి అభివృద్ధి చెందాలి. అదనంగా, రెడీమేడ్ డాకర్ చిత్రాలను ఉపయోగిస్తున్నప్పుడు, నెట్‌వర్క్ సరిగ్గా పని చేయకపోవడాన్ని మేము తరచుగా ఎదుర్కొంటాము (ఇది డాకర్ యొక్క తేమ కారణంగా కావచ్చు) లేదా ఇతరుల కంటైనర్‌లను విస్తరించడం కష్టం.
మేము ఎలాంటి అసౌకర్యాలను ఎదుర్కొన్నాము?
- బ్రిడ్జ్ మోడ్‌లో నెట్‌వర్క్ సమస్యలు
- కంటైనర్‌లో లాగ్‌లను వీక్షించడం అసౌకర్యంగా ఉంటుంది (అవి హోస్ట్ మెషీన్ యొక్క ఫైల్ సిస్టమ్‌లో విడిగా నిల్వ చేయబడకపోతే)
- ElasticSearch అప్పుడప్పుడు కంటైనర్ లోపల వింతగా స్తంభింపజేస్తుంది, కారణం కనుగొనబడలేదు, కంటైనర్ అధికారికం
- కంటైనర్ లోపల షెల్ ఉపయోగించడం అవసరం - ప్రతిదీ చాలా తొలగించబడింది, సాధారణ సాధనాలు లేవు
- సేకరించిన కంటైనర్ల పెద్ద పరిమాణం - నిల్వ చేయడానికి ఖరీదైనది
- పెద్ద పరిమాణంలో ఉన్న కంటైనర్ల కారణంగా, బహుళ సంస్కరణలకు మద్దతు ఇవ్వడం కష్టం
- ఇతర పద్ధతుల వలె కాకుండా (స్క్రిప్ట్‌లు లేదా డెబ్ ప్యాకేజీలు) ఎక్కువ నిర్మాణ సమయం
మరోవైపు, అదే డెబ్ ద్వారా జార్ ఆర్కైవ్ రూపంలో స్ప్రింగ్ సేవను అమలు చేయడం ఎందుకు అధ్వాన్నంగా ఉంది? వనరులను వేరుచేయడం నిజంగా అవసరమా? సేవను బాగా తగ్గించిన కంటైనర్‌లో నింపడం ద్వారా అనుకూలమైన ఆపరేటింగ్ సిస్టమ్ సాధనాలను కోల్పోవడం విలువైనదేనా?
ఆచరణలో చూపినట్లుగా, వాస్తవానికి ఇది అవసరం లేదు, 90% కేసులలో డెబ్ ప్యాకేజీ సరిపోతుంది.
మంచి పాత డెబ్ ఎప్పుడు విఫలమవుతుంది మరియు మనకు నిజంగా డాకర్ ఎప్పుడు అవసరం?
మా కోసం, ఇది పైథాన్‌లో సేవలను అమలు చేస్తోంది. మెషిన్ లెర్నింగ్ కోసం చాలా లైబ్రరీలు అవసరం మరియు ఆపరేటింగ్ సిస్టమ్ యొక్క ప్రామాణిక పంపిణీలో చేర్చబడలేదు (మరియు అక్కడ తప్పు సంస్కరణలు ఉన్నాయి), సెట్టింగ్‌లతో హ్యాక్‌లు, ఒకే హోస్ట్ సిస్టమ్‌లో నివసిస్తున్న వివిధ సేవలకు వేర్వేరు వెర్షన్‌ల అవసరం దారితీసింది ఈ , ఈ అణు మిశ్రమాన్ని అందించడానికి ఏకైక సహేతుకమైన మార్గం డాకర్. డాకర్ కంటైనర్‌ను అసెంబ్లింగ్ చేయడంలో శ్రమ తీవ్రత అన్నింటినీ డిపెండెన్సీలతో ప్రత్యేక డెబ్ ప్యాకేజీలుగా ప్యాక్ చేయాలనే ఆలోచన కంటే తక్కువగా ఉంది మరియు వాస్తవానికి వారి సరైన మనస్సులో ఎవరూ దీనిని చేపట్టరు.
బ్లూ-గ్రీన్ డిప్లాయ్ స్కీమ్‌ని ఉపయోగించి సేవలను అమలు చేయడం మేము డాకర్‌ని ఉపయోగించాలని ప్లాన్ చేస్తున్న రెండవ అంశం. కానీ ఇక్కడ నేను సంక్లిష్టతలో క్రమంగా పెరుగుదలను పొందాలనుకుంటున్నాను: మొదట, డెబ్ ప్యాకేజీలు నిర్మించబడ్డాయి, ఆపై వాటి నుండి డాకర్ కంటైనర్ నిర్మించబడింది.
స్నాప్ ప్యాకేజీలు
స్నాప్ ప్యాకేజీలకు తిరిగి వెళ్దాం. వారు మొదట అధికారికంగా ఉబుంటు 16.04లో కనిపించారు. సాధారణ deb ప్యాకేజీలు మరియు rpm ప్యాకేజీల వలె కాకుండా, snap అన్ని డిపెండెన్సీలను కలిగి ఉంటుంది. ఒక వైపు, ఇది లైబ్రరీ వైరుధ్యాలను నివారించడానికి మిమ్మల్ని అనుమతిస్తుంది, మరోవైపు, ఫలితంగా ప్యాకేజీ పరిమాణంలో పెద్దది. అదనంగా, ఇది సిస్టమ్ యొక్క భద్రతను కూడా ప్రభావితం చేస్తుంది: స్నాప్ డెలివరీ విషయంలో, ప్యాకేజీని సృష్టించే డెవలపర్ ద్వారా చేర్చబడిన లైబ్రరీలలోని అన్ని మార్పులను తప్పనిసరిగా పర్యవేక్షించాలి. సాధారణంగా, ప్రతిదీ చాలా సులభం కాదు మరియు సార్వత్రిక ఆనందం వాటిని ఉపయోగించడం ద్వారా రాదు. అయితే, అదే డాకర్‌ని వర్చువలైజేషన్ కోసం కాకుండా ప్యాకేజింగ్ సాధనంగా మాత్రమే ఉపయోగించినట్లయితే ఇది పూర్తిగా సహేతుకమైన ప్రత్యామ్నాయం.
ఫలితంగా, మేము ఇప్పుడు deb ప్యాకేజీలు మరియు డాకర్ కంటైనర్‌లను సహేతుకమైన కలయికలో ఉపయోగిస్తాము, బహుశా, కొన్ని సందర్భాల్లో మేము స్నాప్ ప్యాకేజీలతో భర్తీ చేస్తాము.
నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. దయచేసి.
మీరు డెలివరీ కోసం ఏమి ఉపయోగిస్తున్నారు?
-
స్వయంగా వ్రాసిన స్క్రిప్ట్‌లు
-
FTPకి మాన్యువల్‌గా కాపీ చేయండి
-
deb ప్యాకేజీలు
-
rpm ప్యాకేజీలు
-
స్నాప్ ప్యాకేజీలు
-
డాకర్-చిత్రాలు
-
వర్చువల్ మెషిన్ చిత్రాలు
-
మొత్తం HDDని క్లోన్ చేయండి
-
తోలుబొమ్మ
-
జవాబుదారీతనం
-
ఇతర
109 మంది వినియోగదారులు ఓటు వేశారు. 32 వినియోగదారులు దూరంగా ఉన్నారు.
మూలం: www.habr.com