ఒక విధానం Iac (కోడ్‌గా మౌలిక సదుపాయాలు) రిపోజిటరీలో నిల్వ చేయబడిన కోడ్‌ను మాత్రమే కాకుండా, ఈ కోడ్ చుట్టూ ఉన్న వ్యక్తులు మరియు ప్రక్రియలను కూడా కలిగి ఉంటుంది. సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ నుండి ఇన్‌ఫ్రాస్ట్రక్చర్ మేనేజ్‌మెంట్ మరియు వివరణ వరకు విధానాలను మళ్లీ ఉపయోగించడం సాధ్యమేనా? మీరు వ్యాసం చదివేటప్పుడు ఈ ఆలోచనను గుర్తుంచుకోవడం మంచిది.
ఇది నా ట్రాన్స్క్రిప్ట్ న .
స్లయిడ్‌లు మరియు వీడియోలు
- డ్రై రన్ 2019-04-24
బాష్ చరిత్రగా మౌలిక సదుపాయాలు
మీరు కొత్త ప్రాజెక్ట్‌కి వచ్చారని అనుకుందాం, మరియు వారు మీకు ఇలా చెప్పారు: “మా దగ్గర ఉంది కోడ్‌గా మౌలిక సదుపాయాలు". వాస్తవానికి అది మారుతుంది బాష్ చరిత్రగా మౌలిక సదుపాయాలు లేదా ఉదాహరణకు బాష్ చరిత్రగా డాక్యుమెంటేషన్. ఇది చాలా వాస్తవమైన పరిస్థితి, ఉదాహరణకు, డెనిస్ లైసెంకో ప్రసంగంలో ఇదే విధమైన కేసును వివరించాడు , వారు బాష్ చరిత్ర నుండి ప్రాజెక్ట్ కోసం ఒక పొందికైన మౌలిక సదుపాయాలను ఎలా పొందారో చెప్పాడు.
కొంత కోరికతో, మనం చెప్పగలం బాష్ చరిత్రగా మౌలిక సదుపాయాలు ఇది కోడ్ లాంటిది:
- పునరుత్పత్తి: మీరు బాష్ చరిత్రను తీసుకోవచ్చు, అక్కడ నుండి ఆదేశాలను అమలు చేయవచ్చు మరియు మీరు అవుట్‌పుట్‌గా పని చేసే కాన్ఫిగరేషన్‌ను పొందవచ్చు.
- సంస్కరణ: ఎవరు లోపలికి వచ్చారో మరియు వారు ఏమి చేసారో మీకు తెలుసు, మళ్ళీ, ఇది మిమ్మల్ని నిష్క్రమణ వద్ద పని చేసే కాన్ఫిగరేషన్‌కు దారితీస్తుందనేది వాస్తవం కాదు.
- కథ: ఎవరు ఏం చేశారనేది కథ. మీరు సర్వర్‌ను కోల్పోతే మాత్రమే మీరు దానిని ఉపయోగించలేరు.
నేను ఏమి చేయాలి?
కోడ్‌గా మౌలిక సదుపాయాలు
వంటి వింత కేసు కూడా బాష్ చరిత్రగా మౌలిక సదుపాయాలు మీరు దానిని చెవుల ద్వారా లాగవచ్చు కోడ్‌గా మౌలిక సదుపాయాలు, కానీ మేము మంచి పాత LAMP సర్వర్ కంటే మరింత సంక్లిష్టమైన పనిని చేయాలనుకున్నప్పుడు, ఈ కోడ్‌ను ఏదో ఒకవిధంగా సవరించాలి, మార్చాలి, మెరుగుపరచాలి అనే నిర్ణయానికి వస్తాము. తదుపరి మేము మధ్య సమాంతరాలను పరిగణించాలనుకుంటున్నాము కోడ్‌గా మౌలిక సదుపాయాలు మరియు సాఫ్ట్‌వేర్ అభివృద్ధి.
పొడి
స్టోరేజ్ సిస్టమ్ డెవలప్‌మెంట్ ప్రాజెక్ట్‌లో, సబ్‌టాస్క్ ఉంది : మేము కొత్త విడుదలను విడుదల చేస్తున్నాము - తదుపరి పరీక్ష కోసం దీనిని రూపొందించాలి. పని చాలా సులభం:
- ssh ద్వారా ఇక్కడ లాగిన్ చేసి, ఆదేశాన్ని అమలు చేయండి.
- ఫైల్‌ను అక్కడ కాపీ చేయండి.
- ఇక్కడ ఆకృతీకరణను సరిచేయండి.
- అక్కడ సేవను ప్రారంభించండి
- ...
- లాభం!
వివరించిన తర్కం కోసం, బాష్ తగినంత కంటే ఎక్కువగా ఉంటుంది, ముఖ్యంగా ప్రాజెక్ట్ యొక్క ప్రారంభ దశల్లో, ఇది ఇప్పుడే ప్రారంభమైనప్పుడు. ఈ , కానీ కాలక్రమేణా సారూప్యతను అమలు చేయడానికి అభ్యర్థనలు ఉన్నాయి, కానీ కొద్దిగా భిన్నంగా ఉంటాయి. గుర్తుకు వచ్చే మొదటి విషయం కాపీ-పేస్ట్. ఇప్పుడు మన దగ్గర ఇప్పటికే దాదాపు ఒకే పని చేసే రెండు సారూప్య స్క్రిప్ట్‌లు ఉన్నాయి. కాలక్రమేణా, స్క్రిప్ట్‌ల సంఖ్య పెరిగింది మరియు వివిధ స్క్రిప్ట్‌ల మధ్య సమకాలీకరించాల్సిన ఇన్‌స్టాలేషన్‌ను అమలు చేయడానికి నిర్దిష్ట వ్యాపార తర్కం ఉందని మేము ఎదుర్కొన్నాము, ఇది చాలా క్లిష్టంగా ఉంటుంది.
డ్రై (మీరే పునరావృతం చేయవద్దు) వంటి అభ్యాసం ఉందని ఇది మారుతుంది. ఇప్పటికే ఉన్న కోడ్‌ని మళ్లీ ఉపయోగించాలనే ఆలోచన ఉంది. ఇది సరళంగా అనిపిస్తుంది, కానీ మేము దీనికి వెంటనే రాలేదు. మా విషయంలో, ఇది సామాన్యమైన ఆలోచన: స్క్రిప్ట్‌ల నుండి కాన్ఫిగరేషన్‌లను వేరు చేయడం. ఆ. ఇన్‌స్టాలేషన్ ఎలా విడిగా అమలు చేయబడుతుందనే వ్యాపార తర్కం, కాన్ఫిగర్లు విడిగా.
CFM కోసం SOLID
కాలక్రమేణా ప్రాజెక్ట్ పెరిగింది మరియు అన్సిబుల్ యొక్క ఆవిర్భావం. దాని ప్రదర్శనకు ప్రధాన కారణం ఏమిటంటే, జట్టులో నైపుణ్యం ఉంది మరియు బాష్ సంక్లిష్ట తర్కం కోసం రూపొందించబడలేదు. అన్సిబుల్ సంక్లిష్ట తర్కాన్ని కూడా కలిగి ఉండటం ప్రారంభించింది. సంక్లిష్ట తర్కం గందరగోళంగా మారకుండా నిరోధించడానికి, సాఫ్ట్‌వేర్ అభివృద్ధిలో కోడ్‌ను నిర్వహించడానికి సూత్రాలు ఉన్నాయి SOLID అలాగే, ఉదాహరణకు, గ్రిగరీ పెట్రోవ్ నివేదికలో “ఐటి స్పెషలిస్ట్‌కు వ్యక్తిగత బ్రాండ్ ఎందుకు అవసరం” అనే ప్రశ్నను లేవనెత్తారు, సాఫ్ట్‌వేర్ అభివృద్ధిలో, కొన్ని సామాజిక సంస్థలతో పనిచేయడం సులభం అయ్యే విధంగా ఒక వ్యక్తి రూపొందించబడ్డాడు వస్తువులు. మేము ఈ రెండు ఆలోచనలను మిళితం చేసి, వాటిని అభివృద్ధి చేయడం కొనసాగిస్తే, మనం కూడా ఉపయోగించవచ్చని గమనించవచ్చు SOLID భవిష్యత్తులో ఈ తర్కాన్ని నిర్వహించడం మరియు సవరించడం సులభతరం చేయడానికి.
ఒకే బాధ్యత సూత్రం
ప్రతి తరగతి ఒక పనిని మాత్రమే చేస్తుంది.
కోడ్‌ని మిక్స్ చేసి, ఏకశిలా దివ్య స్పఘెట్టి రాక్షసులను తయారు చేయాల్సిన అవసరం లేదు. మౌలిక సదుపాయాలు సాధారణ ఇటుకలను కలిగి ఉండాలి. మీరు అన్సిబుల్ ప్లేబుక్‌ను చిన్న ముక్కలుగా విభజించి, అన్సిబుల్ పాత్రలను చదివితే, వాటిని నిర్వహించడం సులభం అవుతుంది.
ఓపెన్ క్లోజ్డ్ ప్రిన్సిపల్
ఓపెన్/క్లోజ్డ్ సూత్రం.
- పొడిగింపుకు తెరవండి: అంటే కొత్త ఎంటిటీ రకాలను సృష్టించడం ద్వారా ఎంటిటీ యొక్క ప్రవర్తనను పొడిగించవచ్చు.
- మార్చడానికి మూసివేయబడింది: ఒక ఎంటిటీ యొక్క ప్రవర్తనను విస్తరించిన ఫలితంగా, ఆ ఎంటిటీలను ఉపయోగించే కోడ్‌లో ఎటువంటి మార్పులు చేయకూడదు.
ప్రారంభంలో, మేము వర్చువల్ మెషీన్‌లలో టెస్ట్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ని అమలు చేసాము, కానీ విస్తరణ యొక్క వ్యాపార తర్కం అమలు నుండి వేరుగా ఉన్నందున, మేము ఎటువంటి సమస్యలు లేకుండా బేర్‌మెటల్‌కి రోలింగ్‌ను జోడించాము.
లిస్కోవ్ ప్రత్యామ్నాయ సూత్రం
బార్బరా లిస్కోవ్ యొక్క ప్రత్యామ్నాయ సూత్రం. ప్రోగ్రామ్‌లోని వస్తువులు ప్రోగ్రామ్ యొక్క సరైన అమలును మార్చకుండా వాటి ఉపరకాల ఉదాహరణలతో భర్తీ చేయబడాలి
మీరు దీన్ని మరింత విస్తృతంగా చూస్తే, అక్కడ వర్తించే నిర్దిష్ట ప్రాజెక్ట్ యొక్క లక్షణం కాదు SOLID, ఇది సాధారణంగా CFM గురించి ఉంటుంది, ఉదాహరణకు, మరొక ప్రాజెక్ట్‌లో వివిధ జావా, అప్లికేషన్ సర్వర్లు, డేటాబేస్‌లు, OS మొదలైన వాటిపై బాక్స్డ్ జావా అప్లికేషన్‌ను అమలు చేయడం అవసరం. ఈ ఉదాహరణను ఉపయోగించి, నేను మరిన్ని సూత్రాలను పరిశీలిస్తాను SOLID
మా విషయంలో, మేము ఇంబ్జావా లేదా ఒరాకిల్‌జావా పాత్రను ఇన్‌స్టాల్ చేసి ఉంటే, అప్పుడు మనకు జావా బైనరీ ఎక్జిక్యూటబుల్ ఉంటుందని ఇన్‌ఫ్రాస్ట్రక్చర్ టీమ్‌లో ఒప్పందం ఉంది. ఇది అవసరం ఎందుకంటే అప్‌స్ట్రీమ్ పాత్రలు ఈ ప్రవర్తనపై ఆధారపడి ఉంటాయి; అదే సమయంలో, అప్లికేషన్ డిప్లాయ్‌మెంట్ లాజిక్‌ను మార్చకుండానే ఒక జావా ఇంప్లిమెంటేషన్/వెర్షన్‌ను మరొక దానితో భర్తీ చేయడానికి ఇది అనుమతిస్తుంది.
ఇక్కడ సమస్య ఏమిటంటే, దీనిని అన్సిబుల్‌లో అమలు చేయడం అసాధ్యం, దీని ఫలితంగా జట్టులో కొన్ని ఒప్పందాలు కనిపిస్తాయి.
ఇంటర్‌ఫేస్ సెగ్రిగేషన్ ప్రిన్సిపల్
ఇంటర్‌ఫేస్ విభజన సూత్రం: “ఒక సాధారణ-ప్రయోజన ఇంటర్‌ఫేస్ కంటే చాలా క్లయింట్-నిర్దిష్ట ఇంటర్‌ఫేస్‌లు మెరుగ్గా ఉంటాయి.
ప్రారంభంలో, మేము అప్లికేషన్ డిప్లాయ్‌మెంట్ యొక్క అన్ని వేరియబిలిటీలను ఒక Ansible ప్లేబుక్‌లో ఉంచడానికి ప్రయత్నించాము, కానీ మద్దతు ఇవ్వడం కష్టం, మరియు మనకు బాహ్య ఇంటర్‌ఫేస్ పేర్కొనబడినప్పుడు (క్లయింట్ పోర్ట్ 443ని ఆశిస్తాడు), ఆపై వ్యక్తిగతంగా ఒక మౌలిక సదుపాయాలను సమీకరించవచ్చు. ఒక నిర్దిష్ట అమలు కోసం ఇటుకలు.
డిపెండెన్సీ ఇన్వర్షన్ ప్రిన్సిపల్
డిపెండెన్సీ విలోమ సూత్రం. అధిక స్థాయిలలోని మాడ్యూల్స్ దిగువ స్థాయిలలోని మాడ్యూళ్ళపై ఆధారపడకూడదు. రెండు రకాల మాడ్యూల్‌లు తప్పనిసరిగా సంగ్రహణలపై ఆధారపడి ఉండాలి. సంగ్రహణలు వివరాలపై ఆధారపడకూడదు. వివరాలు తప్పనిసరిగా సంగ్రహాలపై ఆధారపడి ఉండాలి.
ఇక్కడ ఉదాహరణ యాంటీప్యాటర్న్ ఆధారంగా ఉంటుంది.
- కస్టమర్‌లలో ఒకరికి ప్రైవేట్ క్లౌడ్ ఉంది.
- మేము క్లౌడ్ లోపల వర్చువల్ మిషన్లను ఆర్డర్ చేసాము.
- కానీ క్లౌడ్ యొక్క స్వభావం కారణంగా, అప్లికేషన్ విస్తరణ VM ఏ హైపర్‌వైజర్‌లో ఉందో దానితో ముడిపడి ఉంది.
ఆ. హై-లెవల్ అప్లికేషన్ డిప్లాయ్‌మెంట్ లాజిక్ హైపర్‌వైజర్ దిగువ స్థాయిలకు డిపెండెన్సీలతో ప్రవహిస్తుంది మరియు దీని అర్థం ఈ లాజిక్‌ని మళ్లీ ఉపయోగిస్తున్నప్పుడు సమస్యలు. ఈ విధంగా చేయవద్దు.
ఇంటరాక్షన్
కోడ్‌గా ఇన్‌ఫ్రాస్ట్రక్చర్ అనేది కోడ్‌కి సంబంధించినది మాత్రమే కాదు, కోడ్ మరియు వ్యక్తుల మధ్య సంబంధం, ఇన్‌ఫ్రాస్ట్రక్చర్ డెవలపర్‌ల మధ్య పరస్పర చర్యల గురించి కూడా.
బస్ ఫ్యాక్టర్
మీ ప్రాజెక్ట్‌లో మీకు వాస్య ఉందని అనుకుందాం. వాస్యకు మీ మౌలిక సదుపాయాల గురించి ప్రతిదీ తెలుసు, వాస్య అకస్మాత్తుగా అదృశ్యమైతే ఏమి జరుగుతుంది? ఇది చాలా వాస్తవమైన పరిస్థితి, ఎందుకంటే అతను బస్సుతో కొట్టబడవచ్చు. కొన్నిసార్లు ఇది జరుగుతుంది. ఇది జరిగితే మరియు కోడ్, దాని నిర్మాణం, అది ఎలా పని చేస్తుంది, ప్రదర్శనలు మరియు పాస్‌వర్డ్‌ల గురించి జ్ఞానం జట్టులో పంపిణీ చేయబడకపోతే, మీరు అనేక అసహ్యకరమైన పరిస్థితులను ఎదుర్కోవచ్చు. ఈ ప్రమాదాలను తగ్గించడానికి మరియు బృందంలో జ్ఞానాన్ని పంపిణీ చేయడానికి, మీరు వివిధ విధానాలను ఉపయోగించవచ్చు
పెయిర్ డివోప్సింగ్
ఇది ఇష్టం లేదు , నిర్వాహకులు బీర్ తాగారు, పాస్‌వర్డ్‌లు మార్చారు మరియు పెయిర్ ప్రోగ్రామింగ్ యొక్క అనలాగ్. ఆ. ఇద్దరు ఇంజనీర్లు ఒక కంప్యూటర్, ఒక కీబోర్డ్ వద్ద కూర్చుని మీ మౌలిక సదుపాయాలను కలిసి ఏర్పాటు చేయడం ప్రారంభించండి: సర్వర్‌ని సెటప్ చేయడం, ఆన్సిబుల్ రోల్ రాయడం మొదలైనవి. ఇది బాగుంది, కానీ అది మాకు పని చేయలేదు. కానీ ఈ అభ్యాసం యొక్క ప్రత్యేక సందర్భాలు పనిచేశాయి. ఒక కొత్త ఉద్యోగి వస్తాడు, అతని గురువు అతనితో కలిసి నిజమైన పనిని తీసుకుంటాడు, పని చేస్తాడు మరియు జ్ఞానాన్ని బదిలీ చేస్తాడు.
మరో ప్రత్యేక సందర్భం ఒక సంఘటన కాల్. ఒక సమస్య సమయంలో, డ్యూటీలో ఉన్నవారు మరియు పాల్గొన్న వారి సమూహం గుమిగూడుతుంది, ఒక నాయకుడు నియమించబడ్డాడు, అతను తన స్క్రీన్‌ను పంచుకుంటాడు మరియు ఆలోచనల రైలును వాయిస్తాడు. ఇతర పాల్గొనేవారు నాయకుడి ఆలోచనలను అనుసరిస్తారు, కన్సోల్ నుండి ఉపాయాలపై గూఢచర్యం చేస్తారు, వారు లాగ్‌లో పంక్తిని కోల్పోలేదని తనిఖీ చేస్తారు మరియు సిస్టమ్ గురించి కొత్త విషయాలను నేర్చుకుంటారు. ఈ విధానం చాలా తరచుగా పని చేస్తుంది.
కోడ్ సమీక్ష
సబ్జెక్టివ్‌గా, కోడ్ రివ్యూను ఉపయోగించి అవస్థాపన మరియు ఇది ఎలా పని చేస్తుందనే దాని గురించి జ్ఞానాన్ని వ్యాప్తి చేయడం మరింత ప్రభావవంతంగా ఉంటుంది:
- రిపోజిటరీలోని కోడ్ ద్వారా మౌలిక సదుపాయాలు వివరించబడ్డాయి.
- ప్రత్యేక శాఖలో మార్పులు జరుగుతాయి.
- విలీన అభ్యర్థన సమయంలో, మీరు ఇన్‌ఫ్రాస్ట్రక్చర్‌లో మార్పుల డెల్టాను చూడవచ్చు.
ఇక్కడ ముఖ్యాంశం ఏమిటంటే, సమీక్షకులను ఒక షెడ్యూల్ ప్రకారం ఒక్కొక్కరిగా ఎంపిక చేయడం, అనగా. కొంత సంభావ్యతతో మీరు కొత్త అవస్థాపనకు చేరుకుంటారు.
కోడ్ శైలి
కాలక్రమేణా, సమీక్షల సమయంలో గొడవలు కనిపించడం ప్రారంభించాయి, ఎందుకంటే... సమీక్షకులు వారి స్వంత శైలిని కలిగి ఉన్నారు మరియు సమీక్షకుల భ్రమణ వాటిని విభిన్న శైలులతో పేర్చారు: 2 ఖాళీలు లేదా 4, కామెల్‌కేస్ లేదా స్నేక్_కేస్. దీన్ని వెంటనే అమలు చేయడం సాధ్యం కాలేదు.
- మొదటి ఆలోచన లిన్టర్‌ను ఉపయోగించమని సిఫార్సు చేయడం, అన్నింటికంటే, ప్రతి ఒక్కరూ ఇంజనీర్లు, ప్రతి ఒక్కరూ తెలివైనవారు. కానీ వివిధ సంపాదకులు, OS, అనుకూలమైనది కాదు
- ఇది ప్రతి సమస్యాత్మక కమిట్‌కు స్లాక్‌గా వ్రాసి లింటర్ అవుట్‌పుట్‌ను జోడించే బాట్‌గా పరిణామం చెందింది. కానీ చాలా సందర్భాలలో చేయవలసిన ముఖ్యమైన పనులు ఉన్నాయి మరియు కోడ్ పరిష్కరించబడలేదు.
గ్రీన్ బిల్డ్ మాస్టర్
సమయం గడిచిపోతుంది మరియు నిర్దిష్ట పరీక్షలలో ఉత్తీర్ణత సాధించని వాటిని మాస్టర్‌లోకి అనుమతించలేమని మేము నిర్ణయానికి వచ్చాము. వోయిలా! మేము గ్రీన్ బిల్డ్ మాస్టర్‌ను కనుగొన్నాము, ఇది చాలా కాలంగా సాఫ్ట్‌వేర్ అభివృద్ధిలో సాధన చేయబడింది:
- ప్రత్యేక శాఖలో అభివృద్ధి జరుగుతోంది.
- ఈ థ్రెడ్‌పై పరీక్షలు నడుస్తున్నాయి.
- పరీక్షలు విఫలమైతే, కోడ్ దానిని మాస్టర్‌గా మార్చదు.
ఈ నిర్ణయం తీసుకోవడం చాలా బాధాకరం, ఎందుకంటే... చాలా వివాదానికి కారణమైంది, కానీ అది విలువైనది, ఎందుకంటే... సమీక్షలు శైలిలో తేడాలు లేకుండా విలీనాల కోసం అభ్యర్థనలను స్వీకరించడం ప్రారంభించాయి మరియు కాలక్రమేణా సమస్య ప్రాంతాల సంఖ్య తగ్గడం ప్రారంభమైంది.
IaC పరీక్ష
స్టైల్ చెకింగ్‌తో పాటు, మీరు ఇతర విషయాలను ఉపయోగించవచ్చు, ఉదాహరణకు, మీ ఇన్‌ఫ్రాస్ట్రక్చర్ వాస్తవానికి అమలు చేయగలదో లేదో తనిఖీ చేయడానికి. లేదా అవస్థాపనలో మార్పులు డబ్బు నష్టానికి దారితీయకుండా చూసుకోండి. ఇది ఎందుకు అవసరం కావచ్చు? ప్రశ్న సంక్లిష్టమైనది మరియు తాత్వికమైనది, సరిహద్దు పరిస్థితులను తనిఖీ చేయని పవర్‌షెల్‌లో ఆటో-స్కేలర్ ఉందని కథనంతో సమాధానం ఇవ్వడం ఉత్తమం => అవసరమైన దానికంటే ఎక్కువ VMలు సృష్టించబడ్డాయి => క్లయింట్ అనుకున్నదానికంటే ఎక్కువ డబ్బు ఖర్చు చేశాడు. ఇది చాలా ఆహ్లాదకరమైనది కాదు, కానీ మునుపటి దశల్లో ఈ లోపాన్ని పట్టుకోవడం చాలా సాధ్యమే.
సంక్లిష్టమైన మౌలిక సదుపాయాలను మరింత క్లిష్టంగా ఎందుకు చేయాలి? ఇన్‌ఫ్రాస్ట్రక్చర్‌కు సంబంధించిన పరీక్షలు, కోడ్‌ల మాదిరిగానే, సరళీకరణ గురించి కాదు, మీ మౌలిక సదుపాయాలు ఎలా పని చేయాలో తెలుసుకోవడం.
IaC టెస్టింగ్ పిరమిడ్
IaC టెస్టింగ్: స్టాటిక్ అనాలిసిస్
మీరు మొత్తం ఇన్‌ఫ్రాస్ట్రక్చర్‌ను ఒకేసారి అమలు చేసి, అది పనిచేస్తుందో లేదో తనిఖీ చేస్తే, దీనికి చాలా సమయం పడుతుందని మరియు చాలా సమయం అవసరమని మీరు కనుగొనవచ్చు. అందువల్ల, ఆధారం త్వరగా పని చేసేదిగా ఉండాలి, అది చాలా ఉంది మరియు ఇది చాలా ప్రాచీన ప్రదేశాలను కవర్ చేస్తుంది.
బాష్ గమ్మత్తైనది
ఒక చిన్న ఉదాహరణ చూద్దాం. ప్రస్తుత డైరెక్టరీలోని అన్ని ఫైల్‌లను ఎంచుకుని, మరొక స్థానానికి కాపీ చేయండి. గుర్తుకు వచ్చే మొదటి విషయం:
for i in * ; do
cp $i /some/path/$i.bak
doneఫైల్ పేరులో ఖాళీ ఉంటే ఏమి చేయాలి? సరే, మేము తెలివైనవాళ్లం, కోట్‌లను ఎలా ఉపయోగించాలో మాకు తెలుసు:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneబాగా చేశారా? లేదు! డైరెక్టరీలో ఏమీ లేనట్లయితే, అనగా. గ్లోబింగ్ పనిచేయదు.
find . -type f -exec mv -v {} dst/{}.bak ;ఇప్పుడు బాగా చేశారా? లేదు... ఫైల్ పేరులో ఏముందో మర్చిపోయాను n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirస్టాటిక్ విశ్లేషణ సాధనాలు
మేము కోట్‌లను మరచిపోయినప్పుడు మునుపటి దశ నుండి సమస్య పట్టుకోవచ్చు, దీనికి ప్రకృతిలో చాలా నివారణలు ఉన్నాయి , సాధారణంగా వాటిలో చాలా ఉన్నాయి మరియు చాలా మటుకు మీరు మీ IDE క్రింద మీ స్టాక్ కోసం ఒక లింటర్‌ను కనుగొనవచ్చు.
భాష
టూల్
బాష్
రూబీ
పైథాన్
జవాబుదారీతనం
IaC పరీక్ష: యూనిట్ పరీక్షలు
మేము మునుపటి ఉదాహరణ నుండి చూసినట్లుగా, లింటర్లు సర్వశక్తిమంతమైనవి కావు మరియు అన్ని సమస్య ప్రాంతాలను సూచించలేవు. ఇంకా, సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌లో టెస్టింగ్‌తో సారూప్యతతో, మేము యూనిట్ పరీక్షలను రీకాల్ చేయవచ్చు. వెంటనే గుర్తుకు వచ్చేది , , , . కానీ అన్సిబుల్, చెఫ్, సాల్ట్‌స్టాక్ మరియు వారిలాంటి ఇతరులతో ఏమి చేయాలి?
చాలా ప్రారంభంలో మేము మాట్లాడాము SOLID మరియు మన మౌలిక సదుపాయాలు చిన్న ఇటుకలతో ఉండాలి. వారి సమయం వచ్చింది.
- మౌలిక సదుపాయాలు చిన్న ఇటుకలుగా విభజించబడ్డాయి, ఉదాహరణకు, అన్సిబుల్ పాత్రలు.
- డాకర్ లేదా VM అయినా ఏదో ఒక రకమైన పర్యావరణం అమలు చేయబడుతుంది.
- మేము ఈ పరీక్షా వాతావరణానికి మా Ansible పాత్రను వర్తింపజేస్తాము.
- మేము ఊహించిన విధంగా ప్రతిదీ పని చేస్తుందో లేదో తనిఖీ చేస్తాము (మేము పరీక్షలను అమలు చేస్తాము).
- మేము సరే లేదా సరే అని నిర్ణయిస్తాము.
IaC టెస్టింగ్: యూనిట్ టెస్టింగ్ టూల్స్
ప్రశ్న, CFM కోసం పరీక్షలు ఏమిటి? మీరు స్క్రిప్ట్‌ను అమలు చేయవచ్చు లేదా మీరు దీని కోసం రెడీమేడ్ పరిష్కారాలను ఉపయోగించవచ్చు:
CFM
టూల్
చేసాడు
తల
తల
సాల్ట్‌స్టాక్
testinfra కోసం ఉదాహరణ, వినియోగదారులను తనిఖీ చేయడం test1, test2 ఉనికిలో ఉన్నాయి మరియు సమూహంలో ఉన్నాయి sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsఏమి ఎంచుకోవాలి? ప్రశ్న సంక్లిష్టంగా మరియు అస్పష్టంగా ఉంది, 2018-2019కి గితుబ్‌లో ప్రాజెక్ట్‌లలో మార్పులకు ఉదాహరణ ఇక్కడ ఉంది:
IaC టెస్టింగ్ ఫ్రేమ్‌వర్క్‌లు
ప్రశ్న తలెత్తుతుంది: అన్నింటినీ కలిపి ఎలా ప్రారంభించాలి? చెయ్యవచ్చు తగినంత సంఖ్యలో ఇంజనీర్లు ఉంటే. లేదా మీరు రెడీమేడ్ పరిష్కారాలను తీసుకోవచ్చు, అయినప్పటికీ వాటిలో చాలా ఎక్కువ లేవు:
CFM
టూల్
చేసాడు
తల
Terraform
2018-2019కి గితుబ్‌లోని ప్రాజెక్ట్‌లలో మార్పులకు ఉదాహరణ:
మాలిక్యూల్ vs. టెస్ట్ కిచెన్
ప్రారంభంలో మేము :
- సమాంతరంగా VMని సృష్టించండి.
- అన్సిబుల్ పాత్రలను వర్తింపజేయండి.
- తనిఖీని అమలు చేయండి.
25-35 పాత్రలకు ఇది 40-70 నిమిషాలు పనిచేసింది, ఇది చాలా పొడవుగా ఉంది.
తదుపరి దశ జెంకిన్స్/డాకర్/అన్సిబుల్/మాలిక్యూల్‌కు మారడం. ఐడియాలజికల్ గా అంతా ఒకటే
- లింట్ ప్లేబుక్స్.
- పాత్రలను వరుసలో ఉంచండి.
- కంటైనర్‌ను ప్రారంభించండి
- అన్సిబుల్ పాత్రలను వర్తింపజేయండి.
- testinfraని అమలు చేయండి.
- బలహీనతను తనిఖీ చేయండి.
40 పాత్రల కోసం లైంటింగ్ మరియు డజను కోసం పరీక్షలు సుమారు 15 నిమిషాలు పట్టడం ప్రారంభించాయి.
ఏది ఎంచుకోవాలి అనేది ఉపయోగించిన స్టాక్, జట్టులో నైపుణ్యం మొదలైన అనేక అంశాలపై ఆధారపడి ఉంటుంది. యూనిట్ పరీక్ష ప్రశ్నను ఎలా మూసివేయాలో ఇక్కడ ప్రతి ఒక్కరూ స్వయంగా నిర్ణయించుకుంటారు
IaC పరీక్ష: ఇంటిగ్రేషన్ పరీక్షలు
ఇన్‌ఫ్రాస్ట్రక్చర్ టెస్టింగ్ పిరమిడ్‌లో తదుపరి దశ ఏకీకరణ పరీక్షలు. అవి యూనిట్ పరీక్షల మాదిరిగానే ఉంటాయి:
- మౌలిక సదుపాయాలు చిన్న ఇటుకలుగా విభజించబడ్డాయి, ఉదాహరణకు అన్సిబుల్ పాత్రలు.
- డాకర్ లేదా VM అయినా ఏదో ఒక రకమైన పర్యావరణం అమలు చేయబడుతుంది.
- ఈ పరీక్ష వాతావరణం కోసం దరఖాస్తు చేసుకోండి చాల పాత్రధారుల పాత్రలు.
- మేము ఊహించిన విధంగా ప్రతిదీ పని చేస్తుందో లేదో తనిఖీ చేస్తాము (మేము పరీక్షలను అమలు చేస్తాము).
- మేము సరే లేదా సరే అని నిర్ణయిస్తాము.
స్థూలంగా చెప్పాలంటే, యూనిట్ పరీక్షలలో వలె మేము సిస్టమ్ యొక్క వ్యక్తిగత మూలకం యొక్క పనితీరును తనిఖీ చేయము, సర్వర్ మొత్తంగా ఎలా కాన్ఫిగర్ చేయబడిందో మేము తనిఖీ చేస్తాము.
IaC టెస్టింగ్: ఎండ్ టు ఎండ్ పరీక్షలు
పిరమిడ్ పైభాగంలో ఎండ్ టు ఎండ్ టెస్ట్‌లు మనకు స్వాగతం పలుకుతాయి. ఆ. మేము ప్రత్యేక సర్వర్, ప్రత్యేక స్క్రిప్ట్ లేదా మా మౌలిక సదుపాయాల యొక్క ప్రత్యేక ఇటుక పనితీరును తనిఖీ చేయము. మేము అనేక సర్వర్లు ఒకదానితో ఒకటి కనెక్ట్ అయ్యాయో లేదో తనిఖీ చేస్తాము, మా మౌలిక సదుపాయాలు మేము ఆశించిన విధంగా పనిచేస్తాయి. దురదృష్టవశాత్తు, నేను రెడీమేడ్ బాక్స్డ్ సొల్యూషన్‌లను ఎప్పుడూ చూడలేదు, బహుశా ఎందుకంటే... ఇన్‌ఫ్రాస్ట్రక్చర్ తరచుగా ప్రత్యేకమైనది మరియు టెంప్లేట్ చేయడం మరియు టెస్టింగ్ కోసం ఫ్రేమ్‌వర్క్‌ను రూపొందించడం కష్టం. ఫలితంగా, ప్రతి ఒక్కరూ వారి స్వంత పరిష్కారాలను సృష్టిస్తారు. డిమాండ్ ఉంది, కానీ సమాధానం లేదు. అందువల్ల, ఇతరులను మంచి ఆలోచనలకు నెట్టడానికి లేదా ప్రతిదీ మన ముందు చాలా కాలం క్రితం కనుగొనబడినందున నా ముక్కును రుద్దడానికి ఏమి ఉందో నేను మీకు చెప్తాను.
గొప్ప చరిత్ర కలిగిన ప్రాజెక్ట్. ఇది పెద్ద సంస్థలలో ఉపయోగించబడుతుంది మరియు బహుశా మీలో ప్రతి ఒక్కరూ దానితో పరోక్షంగా దాటారు. అప్లికేషన్ అనేక డేటాబేస్‌లు, ఇంటిగ్రేషన్‌లు మొదలైన వాటికి మద్దతు ఇస్తుంది. ఇన్‌ఫ్రాస్ట్రక్చర్ ఎలా ఉంటుందో తెలుసుకోవడం చాలా డాకర్-కంపోజ్ ఫైల్‌లు మరియు ఏ వాతావరణంలో ఏ పరీక్షలను అమలు చేయాలో తెలుసుకోవడం జెంకిన్స్.
ఫ్రేమ్‌వర్క్‌లో ఉండే వరకు ఈ పథకం చాలా కాలం పాటు పనిచేసింది మేము దీన్ని Openshiftకి బదిలీ చేయడానికి ప్రయత్నించలేదు. కంటైనర్లు అలాగే ఉంటాయి, కానీ ప్రయోగ వాతావరణం మారింది (మళ్ళీ హలో డ్రై).
పరిశోధన ఆలోచన మరింత ముందుకు సాగింది మరియు ఓపెన్‌షిఫ్ట్‌లో వారు APB (అన్సిబుల్ ప్లేబుక్ బండిల్) వంటి వాటిని కనుగొన్నారు, ఇది కంటైనర్‌లో మౌలిక సదుపాయాలను ఎలా అమర్చాలో జ్ఞానాన్ని ప్యాక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఆ. ఇన్‌ఫ్రాస్ట్రక్చర్‌ని ఎలా అమర్చాలనే దానిపై పునరావృతమయ్యే, పరీక్షించదగిన జ్ఞానం ఉంది.
మేము వైవిధ్యమైన అవస్థాపనలోకి ప్రవేశించే వరకు ఇవన్నీ బాగానే ఉన్నాయి: పరీక్షల కోసం మాకు Windows అవసరం. ఫలితంగా, ఏమి, ఎక్కడ, ఎలా అమర్చాలి మరియు పరీక్షించాలనే జ్ఞానం జెంకిన్స్‌లో ఉంది.
ముగింపు
కోడ్ వలె మౌలిక సదుపాయాలు
- రిపోజిటరీలో కోడ్.
- మానవ పరస్పర చర్య.
- మౌలిక సదుపాయాల పరీక్ష.
లింకులు
- డ్రై రన్ 2019-04-24
- &
మూలం: www.habr.com