మొదట, ఒక చిన్న సిద్ధాంతం. ఏం జరిగింది ?
సరళంగా చెప్పాలంటే, ఈ పత్రం SaaS అప్లికేషన్‌ల అభివృద్ధిని సులభతరం చేయడానికి రూపొందించబడింది, ఆధునిక అప్లికేషన్‌ల అభివృద్ధిలో తరచుగా ఎదురయ్యే సమస్యలు మరియు అభ్యాసాల గురించి డెవలపర్‌లు మరియు DevOps ఇంజనీర్‌లకు తెలియజేయడం ద్వారా సహాయపడుతుంది.
Heroku ప్లాట్‌ఫారమ్ డెవలపర్‌లచే పత్రం సృష్టించబడింది.
ఏదైనా ప్రోగ్రామింగ్ భాషలో వ్రాసిన అప్లికేషన్‌లకు మరియు బ్యాకింగ్ సేవల (డేటాబేస్‌లు, మెసేజ్ క్యూలు, కాష్‌లు మొదలైనవి) కలయికను ఉపయోగించి ట్వెల్వ్-ఫాక్టర్ యాప్ వర్తించబడుతుంది.
ఈ పద్దతిపై ఆధారపడిన కారకాల గురించి క్లుప్తంగా:
- కోడ్‌బేస్ - సంస్కరణ నియంత్రణలో ఒక కోడ్‌బేస్ ట్రాక్ చేయబడింది - బహుళ విస్తరణలు
- డిపెండెన్సీలు - డిపెండెన్సీలను స్పష్టంగా ప్రకటించండి మరియు వేరు చేయండి
- ఆకృతీకరణ - రన్‌టైమ్‌లో కాన్ఫిగరేషన్‌ను సేవ్ చేయండి
- బ్యాకింగ్ సేవలు - బ్యాకింగ్ సేవలను ప్లగ్-ఇన్ వనరులుగా పరిగణించండి
- బిల్డ్, రిలీజ్, రన్ - అసెంబ్లీ మరియు అమలు దశలను ఖచ్చితంగా వేరు చేయండి
- ప్రక్రియలు - అప్లికేషన్‌ను ఒకటి లేదా అంతకంటే ఎక్కువ స్థితిలేని ప్రక్రియలుగా అమలు చేయండి
- పోర్ట్ బైండింగ్ - పోర్ట్ బైండింగ్ ద్వారా సేవలను ఎగుమతి చేయండి
- సమాంతరత - ప్రక్రియలను ఉపయోగించి మీ అప్లికేషన్‌ను స్కేల్ చేయండి
- డిస్పోజబిలిటీ - ఫాస్ట్ స్టార్టప్ మరియు క్లీన్ షట్‌డౌన్‌తో విశ్వసనీయతను పెంచుకోండి
- అప్లికేషన్ అభివృద్ధి/ఆపరేషన్ సమానత్వం – మీ డెవలప్‌మెంట్, స్టేజింగ్ మరియు ప్రొడక్షన్ పరిసరాలను వీలైనంత సారూప్యంగా ఉంచండి
- లాగింగ్ – ఈవెంట్‌ల స్ట్రీమ్‌గా లాగ్‌ను వీక్షించండి
- అడ్మినిస్ట్రేషన్ పనులు - తాత్కాలిక ప్రక్రియలను ఉపయోగించి పరిపాలన/నిర్వహణ పనులను నిర్వహించండి
మీరు క్రింది వనరుల నుండి 12 కారకాల గురించి మరింత సమాచారాన్ని పొందవచ్చు:
- - తప్పక చదవాలి
- - అధికారిక అనువాదం
- - వాటిని మెరుగుపరిచే లక్ష్యంతో 12 కారకాలపై తాజా పరిశీలన.
బ్లూ-గ్రీన్ విస్తరణ అంటే ఏమిటి?
బ్లూ-గ్రీన్ డిప్లాయ్‌మెంట్ అనేది అప్లికేషన్‌ను డెలివరీ చేసే పద్ధతి ఉత్పత్తి అంతిమ క్లయింట్ తన వైపు నుండి ఎటువంటి మార్పులను చూడని విధంగా. మరో మాటలో చెప్పాలంటే, సున్నాతో అప్లికేషన్‌ని అమలు చేయడం సమయములో చేయబడినాయి కాబట్టి.
క్లాసిక్ BG డిప్లాయ్ స్కీమ్ క్రింది చిత్రంలో చూపిన విధంగా కనిపిస్తుంది.
- ప్రారంభంలో ఒకే కోడ్, అప్లికేషన్, ప్రాజెక్ట్‌తో 2 భౌతిక సర్వర్లు ఉన్నాయి మరియు రౌటర్ (బ్యాలన్సర్) ఉంది.
- రూటర్ ప్రారంభంలో అన్ని అభ్యర్థనలను సర్వర్‌లలో ఒకదానికి నిర్దేశిస్తుంది (ఆకుపచ్చ).
- మీరు మళ్లీ విడుదల చేయాల్సిన సమయంలో, మొత్తం ప్రాజెక్ట్ మరొక సర్వర్‌లో నవీకరించబడుతుంది (నీలం), ఇది ప్రస్తుతం ఏ అభ్యర్థనలను ప్రాసెస్ చేయడం లేదు.
- కోడ్ ఆన్ అయిన తర్వాత నీలం సర్వర్ పూర్తిగా నవీకరించబడింది, రౌటర్ నుండి మారడానికి ఆదేశం ఇవ్వబడింది ఆకుపచ్చ న నీలం సర్వర్.
- ఇప్పుడు క్లయింట్‌లందరూ కోడ్‌తో నడుస్తున్న ఫలితాన్ని చూస్తారు నీలం సర్వర్.
- కొంతసేపు, ఆకుపచ్చ కు విఫలమైతే సర్వర్ బ్యాకప్ కాపీగా పనిచేస్తుంది నీలం సర్వర్ మరియు వైఫల్యం మరియు బగ్‌ల సందర్భంలో, రూటర్ వినియోగదారు ప్రవాహాన్ని తిరిగి మారుస్తుంది ఆకుపచ్చ పాత స్థిరమైన సంస్కరణతో సర్వర్, మరియు కొత్త కోడ్ పునర్విమర్శ మరియు పరీక్ష కోసం పంపబడుతుంది.
- మరియు ప్రక్రియ ముగింపులో, ఇది అదే విధంగా నవీకరించబడుతుంది ఆకుపచ్చ సర్వర్. మరియు దానిని నవీకరించిన తర్వాత, రూటర్ అభ్యర్థన ప్రవాహాన్ని తిరిగి మారుస్తుంది ఆకుపచ్చ సర్వర్.
ఇది చాలా బాగుంది మరియు మొదటి చూపులో దానితో ఏవైనా సమస్యలు ఉండకూడదు.
కానీ మేము ఆధునిక ప్రపంచంలో నివసిస్తున్నందున, క్లాసికల్ స్కీమ్‌లో సూచించిన భౌతిక మార్పిడితో కూడిన ఎంపిక మాకు సరిపోదు. ప్రస్తుతానికి సమాచారాన్ని రికార్డ్ చేయండి, మేము దాని తర్వాత తిరిగి వస్తాము.
చెడు మరియు మంచి సలహా
నిరాకరణ: క్రింద ఉన్న ఉదాహరణలు నేను ఉపయోగించే యుటిలిటీస్/మెథడాలజీలను చూపుతాయి, మీరు సారూప్యమైన ఫంక్షన్‌లతో ఖచ్చితంగా ఏదైనా ప్రత్యామ్నాయాలను ఉపయోగించవచ్చు.
చాలా ఉదాహరణలు వెబ్ డెవలప్‌మెంట్‌తో ఒక విధంగా లేదా మరొక విధంగా కలుస్తాయి (ఇది ఆశ్చర్యకరమైనది), PHP మరియు డాకర్‌తో.
దిగువ పేరాగ్రాఫ్‌లు నిర్దిష్ట ఉదాహరణలను ఉపయోగించి కారకాల ఉపయోగం యొక్క సరళమైన ఆచరణాత్మక వివరణను అందిస్తాయి; మీరు ఈ అంశంపై మరింత సిద్ధాంతాన్ని పొందాలనుకుంటే, అసలు మూలానికి ఎగువ లింక్‌లను అనుసరించండి.
1. కోడ్‌బేస్
ఒక సమయంలో సర్వర్‌లకు ఫైల్‌లను అప్‌లోడ్ చేయడానికి FTP మరియు FileZillaని ఉపయోగించండి, ఉత్పత్తి సర్వర్‌లో కాకుండా మరెక్కడైనా కోడ్‌ను నిల్వ చేయవద్దు.
ప్రాజెక్ట్ ఎల్లప్పుడూ ఒకే కోడ్ బేస్ కలిగి ఉండాలి, అంటే, అన్ని కోడ్ ఒకటి నుండి వస్తుంది Git రిపోజిటరీ. సర్వర్లు (ఉత్పత్తి, స్టేజింగ్, టెస్ట్1, టెస్ట్2...) ఒక సాధారణ రిపోజిటరీ యొక్క శాఖల నుండి కోడ్‌ను ఉపయోగిస్తాయి. ఈ విధంగా మేము కోడ్ స్థిరత్వాన్ని సాధిస్తాము.
2. డిపెండెన్సీలు
ఫోల్డర్‌లలోని అన్ని లైబ్రరీలను నేరుగా ప్రాజెక్ట్ యొక్క మూలానికి డౌన్‌లోడ్ చేయండి. లైబ్రరీ యొక్క ప్రస్తుత సంస్కరణతో ఫోల్డర్‌కు కొత్త కోడ్‌ను బదిలీ చేయడం ద్వారా నవీకరణలను చేయండి. 20 మరిన్ని సేవలు నడుస్తున్న హోస్ట్ సర్వర్‌లో అవసరమైన అన్ని యుటిలిటీలను నేరుగా ఇన్‌స్టాల్ చేయండి.
ప్రాజెక్ట్ ఎల్లప్పుడూ స్పష్టంగా అర్థమయ్యే డిపెండెన్సీల జాబితాను కలిగి ఉండాలి (డిపెండెన్సీల ద్వారా నేను పర్యావరణాన్ని కూడా సూచిస్తాను). అన్ని డిపెండెన్సీలు స్పష్టంగా నిర్వచించబడాలి మరియు వేరుచేయబడాలి.
ఒక ఉదాహరణగా తీసుకుందాం కంపోజర్ и డాకర్.
కంపోజర్ — PHPలో లైబ్రరీలను ఇన్‌స్టాల్ చేయడానికి మిమ్మల్ని అనుమతించే ప్యాకేజీ మేనేజర్. సంస్కరణలను ఖచ్చితంగా లేదా వదులుగా పేర్కొనడానికి మరియు వాటిని స్పష్టంగా నిర్వచించడానికి కంపోజర్ మిమ్మల్ని అనుమతిస్తుంది. సర్వర్‌లో 20 వేర్వేరు ప్రాజెక్ట్‌లు ఉండవచ్చు మరియు ప్రతి ఒక్కటి వ్యక్తిగత ప్యాకేజీలు మరియు లైబ్రరీల యొక్క వ్యక్తిగత జాబితాను కలిగి ఉంటాయి.
డాకర్ — అప్లికేషన్ రన్ అయ్యే వాతావరణాన్ని నిర్వచించడానికి మరియు వేరు చేయడానికి మిమ్మల్ని అనుమతించే యుటిలిటీ. దీని ప్రకారం, కంపోజర్ మాదిరిగానే, కానీ మరింత క్షుణ్ణంగా, అప్లికేషన్ దేనితో పనిచేస్తుందో మేము గుర్తించగలము. PHP యొక్క నిర్దిష్ట సంస్కరణను ఎంచుకోండి, ప్రాజెక్ట్ పని చేయడానికి అవసరమైన ప్యాకేజీలను మాత్రమే ఇన్‌స్టాల్ చేయండి, అదనంగా ఏమీ జోడించకుండా. మరియు ముఖ్యంగా, హోస్ట్ మెషీన్ మరియు ఇతర ప్రాజెక్ట్‌ల ప్యాకేజీలు మరియు పర్యావరణంతో జోక్యం చేసుకోకుండా. అంటే, డాకర్ ద్వారా నడుస్తున్న సర్వర్‌లోని అన్ని ప్రాజెక్ట్‌లు ఖచ్చితంగా ఏదైనా ప్యాకేజీలను మరియు పూర్తిగా భిన్నమైన వాతావరణాన్ని ఉపయోగించగలవు.
3. ఆకృతీకరణ
కాన్ఫిగరేషన్‌లను నేరుగా కోడ్‌లో స్థిరాంకాలుగా నిల్వ చేయండి. పరీక్ష సర్వర్ కోసం ప్రత్యేక స్థిరాంకాలు, ఉత్పత్తి కోసం వేరు. ప్రాజెక్ట్ యొక్క వ్యాపార లాజిక్‌లో నేరుగా పర్యావరణంపై ఆధారపడి అప్లికేషన్ యొక్క ఆపరేషన్‌ను టైప్ చేయండి.
ఆకృతీకరణలు - ప్రాజెక్ట్ విస్తరణలు భిన్నంగా ఉండే ఏకైక మార్గం ఇది. ఆదర్శవంతంగా, కాన్ఫిగరేషన్‌లను ఎన్విరాన్‌మెంట్ వేరియబుల్స్ (env vars) ద్వారా పంపాలి.
అంటే, మీరు అనేక కాన్ఫిగరేషన్ ఫైల్‌లను .config.prod .config.local నిల్వ చేసి, విస్తరణ సమయంలో వాటిని .config (అప్లికేషన్ డేటాను చదివే ప్రధాన కాన్ఫిగరేషన్)కి పేరు మార్చినప్పటికీ - ఇది సరైన విధానం కాదు, ఎందుకంటే ఈ సందర్భంలో కాన్ఫిగరేషన్‌ల నుండి సమాచారం అందరు అప్లికేషన్ డెవలపర్‌లకు పబ్లిక్‌గా అందుబాటులో ఉంటుంది మరియు ప్రొడక్షన్ సర్వర్ నుండి డేటా రాజీపడుతుంది. అన్ని కాన్ఫిగరేషన్‌లు తప్పనిసరిగా డిప్లాయ్‌మెంట్ సిస్టమ్ (CI/CD)లో నేరుగా నిల్వ చేయబడాలి మరియు విస్తరణ సమయంలో నిర్దిష్ట పర్యావరణానికి అవసరమైన విభిన్న విలువలతో విభిన్న వాతావరణాల కోసం రూపొందించబడతాయి.
4. మూడవ పక్ష సేవలు
పర్యావరణంతో ఖచ్చితంగా ముడిపడి ఉండండి, నిర్దిష్ట వాతావరణాలలో ఒకే సేవల కోసం వేర్వేరు కనెక్షన్‌లను ఉపయోగించండి.
వాస్తవానికి, ఈ పాయింట్ కాన్ఫిగరేషన్‌లకు సంబంధించిన పాయింట్‌తో బలంగా అతివ్యాప్తి చెందుతుంది, ఎందుకంటే ఈ పాయింట్ లేకుండా, సాధారణ కాన్ఫిగరేషన్ డేటాను తయారు చేయడం సాధ్యం కాదు మరియు సాధారణంగా, కాన్ఫిగర్ చేసే సామర్థ్యం ఏమీ తగ్గదు.
క్యూ సర్వర్లు, డేటాబేస్‌లు, కాషింగ్ సేవలు వంటి బాహ్య సేవలకు సంబంధించిన అన్ని కనెక్షన్‌లు తప్పనిసరిగా స్థానిక వాతావరణం మరియు మూడవ పక్షం/ఉత్పత్తి వాతావరణం రెండింటికీ ఒకే విధంగా ఉండాలి. మరో మాటలో చెప్పాలంటే, ఏ సమయంలోనైనా, కనెక్షన్ స్ట్రింగ్‌ని మార్చడం ద్వారా, నేను అప్లికేషన్ కోడ్‌ని మార్చకుండానే బేస్ #1కి కాల్‌లను బేస్ #2తో భర్తీ చేయగలను. లేదా, ముందుకు చూస్తే, ఒక ఉదాహరణగా, సేవను స్కేలింగ్ చేసేటప్పుడు, మీరు అదనపు కాష్ సర్వర్ కోసం ఏదైనా ప్రత్యేక మార్గంలో కనెక్షన్‌ని పేర్కొనవలసిన అవసరం లేదు.
5. బిల్డ్, రిలీజ్, ఎగ్జిక్యూట్
విడుదలను వెనక్కి తీసుకునే అవకాశం లేకుండా సర్వర్‌లో కోడ్ యొక్క చివరి సంస్కరణను మాత్రమే కలిగి ఉండండి. డిస్క్ స్థలాన్ని పూరించాల్సిన అవసరం లేదు. లోపంతో కోడ్‌ని ఉత్పత్తిలోకి విడుదల చేయవచ్చని భావించే ఎవరైనా చెడ్డ ప్రోగ్రామర్!
విస్తరణ యొక్క అన్ని దశలు తప్పనిసరిగా ఒకదానికొకటి వేరు చేయబడాలి.
వెనక్కి వెళ్లే అవకాశం ఉంది. త్వరిత యాక్సెస్‌లో సేవ్ చేయబడిన అప్లికేషన్ యొక్క పాత కాపీలతో (ఇప్పటికే సమీకరించబడి మరియు యుద్ధానికి సిద్ధంగా ఉంది) విడుదలలను చేయండి, తద్వారా లోపాల విషయంలో మీరు పాత సంస్కరణను పునరుద్ధరించవచ్చు. అంటే, షరతులతో ఒక ఫోల్డర్ ఉంది విడుదలలు మరియు ఫోల్డర్ ప్రస్తుత, మరియు విజయవంతమైన విస్తరణ మరియు ఫోల్డర్‌ని అసెంబ్లీ చేసిన తర్వాత ప్రస్తుత లోపల ఉన్న కొత్త విడుదలకు సింబాలిక్ లింక్ ద్వారా లింక్ చేయబడింది విడుదలలు విడుదల సంఖ్య యొక్క సంప్రదాయ పేరుతో.
ఇక్కడే మేము బ్లూ-గ్రీన్ డిప్లాయ్‌మెంట్‌ని గుర్తుంచుకుంటాము, ఇది కోడ్‌ల మధ్య మారడానికి మాత్రమే కాకుండా, అన్ని వనరులు మరియు ప్రతిదానిని వెనక్కి తీసుకునే సామర్థ్యంతో పర్యావరణాల మధ్య కూడా మారడానికి మిమ్మల్ని అనుమతిస్తుంది.
6. ప్రక్రియలు
అప్లికేషన్ స్థితి డేటాను నేరుగా అప్లికేషన్‌లోనే నిల్వ చేయండి. అప్లికేషన్ యొక్క RAM లోనే సెషన్లను ఉపయోగించండి. థర్డ్-పార్టీ సర్వీస్‌ల మధ్య వీలైనంత ఎక్కువ భాగస్వామ్యాన్ని ఉపయోగించండి. అప్లికేషన్ ఒక ప్రక్రియను మాత్రమే కలిగి ఉంటుంది మరియు స్కేలింగ్‌ను అనుమతించదు అనే వాస్తవంపై ఆధారపడండి.
సెషన్‌లకు సంబంధించి, థర్డ్-పార్టీ సర్వీస్‌లచే నియంత్రించబడే కాష్‌లో మాత్రమే డేటాను నిల్వ చేయండి (memcached, redis), కాబట్టి మీ వద్ద 20 అప్లికేషన్ ప్రాసెస్‌లు నడుస్తున్నప్పటికీ, వాటిలో ఏవైనా కాష్‌ని యాక్సెస్ చేసిన తర్వాత, క్లయింట్‌తో కలిసి పని చేయడం కొనసాగించగలరు వినియోగదారు మరొక ప్రక్రియలో అప్లికేషన్‌తో పని చేస్తున్న అదే స్థితి. ఈ విధానంతో, మీరు థర్డ్-పార్టీ సేవల యొక్క ఎన్ని కాపీలు ఉపయోగించినా, ప్రతిదీ సాధారణంగా మరియు డేటాకు ప్రాప్యతతో సమస్యలు లేకుండా పని చేస్తుందని తేలింది.
7. పోర్ట్ బైండింగ్
మూడవ పక్ష సేవలతో ఎలా పని చేయాలో వెబ్ సర్వర్ మాత్రమే తెలుసుకోవాలి. లేదా ఇంకా ఉత్తమం, వెబ్ సర్వర్‌లో నేరుగా మూడవ పక్ష సేవలను ఇన్‌స్టాల్ చేయండి. ఉదాహరణకు, Apacheలో PHP మాడ్యూల్‌గా.
కొన్ని చిరునామా మరియు పోర్ట్ (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), అంటే, nginx నుండి నేను php-fpm రెండింటినీ యాక్సెస్ చేయగలను మరియు postgres, మరియు php-fpm నుండి postgres మరియు nginx వరకు మరియు వాస్తవానికి ప్రతి సేవ నుండి నేను మరొక సేవను యాక్సెస్ చేయగలను. ఈ విధంగా, ఒక సేవ యొక్క సాధ్యత మరొక సేవ యొక్క సాధ్యతతో ముడిపడి ఉండదు.
8. సమాంతరత
ఒక ప్రక్రియతో పని చేయండి, లేకపోతే అనేక ప్రక్రియలు ఒకదానితో ఒకటి కలిసి ఉండవు!
స్కేలింగ్ కోసం గదిని వదిలివేయండి. డాకర్ స్వార్మ్ దీనికి చాలా బాగుంది.
డాకర్ స్వార్మ్ అనేది ఒకే మెషీన్‌లోని విభిన్న యంత్రాలు మరియు కంటైనర్‌ల సమూహం రెండింటి మధ్య కంటైనర్‌ల క్లస్టర్‌లను సృష్టించడానికి మరియు నిర్వహించడానికి ఒక సాధనం.
సమూహాన్ని ఉపయోగించి, నేను ప్రతి ప్రాసెస్‌కి ఎన్ని వనరులను కేటాయిస్తాను మరియు అదే సేవ యొక్క ఎన్ని ప్రక్రియలను నేను ప్రారంభించాలో నిర్ణయించగలను మరియు ఇచ్చిన పోర్ట్‌లోని డేటాను స్వీకరించే అంతర్గత బ్యాలెన్సర్ దానిని స్వయంచాలకంగా ప్రక్రియలకు ప్రాక్సీ చేస్తుంది. ఈ విధంగా, సర్వర్‌పై లోడ్ పెరిగినట్లు చూసినప్పుడు, నేను మరిన్ని ప్రక్రియలను జోడించగలను, తద్వారా నిర్దిష్ట ప్రక్రియలపై లోడ్ తగ్గుతుంది.
9. డిస్పోజబిలిటీ
ప్రక్రియలు మరియు డేటాతో పని చేయడానికి క్యూలను ఉపయోగించవద్దు. ఒక ప్రక్రియను చంపడం మొత్తం అప్లికేషన్‌ను ప్రభావితం చేస్తుంది. ఒక్క సర్వీస్ తగ్గిపోతే అన్నీ తగ్గిపోతాయి.
ప్రతి ప్రక్రియ మరియు సేవను ఎప్పుడైనా ఆఫ్ చేయవచ్చు మరియు ఇది ఇతర సేవలను ప్రభావితం చేయకూడదు (అయితే, సేవ మరొక సేవకు అందుబాటులో ఉండదని దీని అర్థం కాదు, కానీ దీని తర్వాత మరొక సేవ ఆఫ్ చేయబడదు). అన్ని ప్రక్రియలు సరసముగా ముగించబడాలి, తద్వారా అవి ముగించబడినప్పుడు, ఏ డేటా దెబ్బతినదు మరియు మీరు తదుపరిసారి దాన్ని ఆన్ చేసినప్పుడు సిస్టమ్ సరిగ్గా పని చేస్తుంది. అంటే, అత్యవసర ముగింపు సందర్భంలో కూడా, డేటా దెబ్బతినకూడదు (లావాదేవీ విధానం ఇక్కడ అనుకూలంగా ఉంటుంది, డేటాబేస్‌లోని ప్రశ్నలు సమూహాలలో మాత్రమే పని చేస్తాయి మరియు సమూహం నుండి కనీసం ఒక ప్రశ్న విఫలమైతే లేదా అమలు చేయబడినట్లయితే లోపం, అప్పుడు సమూహం నుండి ఏ ఇతర ప్రశ్న కూడా చివరికి విఫలం కాదు).
10. అప్లికేషన్ డెవలప్‌మెంట్/ఆపరేషన్ సమానత్వం
అప్లికేషన్ యొక్క ఉత్పత్తి, స్టేజింగ్ మరియు స్థానిక వెర్షన్ తప్పనిసరిగా భిన్నంగా ఉండాలి. ఉత్పత్తిలో మేము Yii లైట్ ఫ్రేమ్‌వర్క్‌ని మరియు స్థానికంగా Yiiని ఉపయోగిస్తాము, తద్వారా ఇది ఉత్పత్తిలో వేగంగా పని చేస్తుంది!
వాస్తవానికి, అన్ని విస్తరణలు మరియు కోడ్‌తో పని దాదాపు ఒకే వాతావరణంలో ఉండాలి (మేము భౌతిక హార్డ్‌వేర్ గురించి మాట్లాడటం లేదు). అలాగే, ఏదైనా డెవలప్‌మెంట్ ఉద్యోగి అవసరమైతే ఉత్పత్తికి కోడ్‌ను అమలు చేయగలగాలి, మరియు ప్రత్యేకంగా శిక్షణ పొందిన డెవొప్స్ డిపార్ట్‌మెంట్ కాదు, ప్రత్యేక శక్తికి ధన్యవాదాలు మాత్రమే అప్లికేషన్‌ను ఉత్పత్తిలోకి తీసుకురాగలదు.
దీనికి డాకర్ కూడా మాకు సహాయం చేస్తుంది. మునుపటి అన్ని పాయింట్లను గమనించినట్లయితే, డాకర్‌ని ఉపయోగించడం వల్ల ఉత్పత్తిపై మరియు స్థానిక మెషీన్‌పై పర్యావరణాన్ని ఒకటి లేదా రెండు ఆదేశాలను నమోదు చేసే ప్రక్రియను తీసుకువస్తుంది.
11. లాగ్‌లు
మేము ఫైల్‌లు మరియు డేటాబేస్‌లకు లాగ్‌లను వ్రాస్తాము! మేము లాగ్‌ల నుండి ఫైల్‌లు మరియు డేటాబేస్‌లను శుభ్రం చేయము. 9000 పెటా బైట్‌లతో హార్డ్‌డ్రైవ్‌ని కొనుగోలు చేద్దాం మరియు అది సరే.
అన్ని లాగ్‌లను ఈవెంట్‌ల స్ట్రీమ్‌గా పరిగణించాలి. లాగ్‌లను ప్రాసెస్ చేయడంలో అప్లికేషన్ కూడా పాల్గొనకూడదు. లాగ్‌లు stdoutకి అవుట్‌పుట్ చేయబడాలి లేదా udp వంటి ప్రోటోకాల్ ద్వారా పంపబడాలి, తద్వారా లాగ్‌లతో పని చేయడం వలన అప్లికేషన్‌కు ఎటువంటి సమస్యలు ఏర్పడవు. గ్రేలాగ్ దీనికి మంచిది. Udp ద్వారా అన్ని లాగ్‌లను స్వీకరించే గ్రేలాగ్ (ఈ ప్రోటోకాల్‌కు ప్యాకెట్ యొక్క విజయవంతమైన స్వీకరణ గురించి ప్రతిస్పందన కోసం వేచి ఉండాల్సిన అవసరం లేదు) అప్లికేషన్‌తో ఏ విధంగానూ జోక్యం చేసుకోదు మరియు లాగ్‌ల నిర్మాణం మరియు ప్రాసెసింగ్‌తో మాత్రమే వ్యవహరిస్తుంది. అటువంటి విధానాలతో పని చేయడానికి అప్లికేషన్ లాజిక్ మారదు.
12. అడ్మినిస్ట్రేషన్ పనులు
డేటా, డేటాబేస్‌లు మొదలైనవాటిని అప్‌డేట్ చేయడానికి, APIలో విడిగా సృష్టించబడిన ఎండ్‌పాయింట్‌ని ఉపయోగించండి, దాన్ని వరుసగా 2 సార్లు అమలు చేయడం వలన ప్రతిదీ నకిలీ చేయబడి ఉంటుంది. కానీ మీరు తెలివితక్కువవారు కాదు, మీరు రెండుసార్లు క్లిక్ చేయరు మరియు మాకు వలసలు అవసరం లేదు.
అన్ని అడ్మినిస్ట్రేషన్ పనులు విడుదల స్థాయిలో అన్ని కోడ్‌ల మాదిరిగానే అదే వాతావరణంలో నిర్వహించబడాలి. అంటే, మనం డేటాబేస్ యొక్క నిర్మాణాన్ని మార్చవలసి వస్తే, కొన్ని విజువల్ డేటాబేస్ నిర్వహణ సాధనాల ద్వారా నిలువు వరుసల పేర్లను మార్చడం మరియు కొత్త వాటిని జోడించడం ద్వారా మేము దానిని మానవీయంగా చేయము. అటువంటి విషయాల కోసం, మేము ప్రత్యేక స్క్రిప్ట్‌లను సృష్టిస్తాము - వలసలు, ఇవి సాధారణ మరియు అర్థమయ్యే ఫలితంతో ప్రతిచోటా మరియు అన్ని వాతావరణాలలో ఒకే విధంగా అమలు చేయబడతాయి. ప్రాజెక్ట్‌ను డేటాతో నింపడం వంటి అన్ని ఇతర పనుల కోసం, ఇలాంటి పద్ధతులను ఉపయోగించాలి.
PHP, లారావెల్, లాడాక్, డాకర్-కంపోజ్‌లో ఉదాహరణ అమలు
PS అన్ని ఉదాహరణలు MacOSలో రూపొందించబడ్డాయి. వాటిలో చాలా వరకు Linux కి కూడా సరిపోతాయి. Windows వినియోగదారులు, నన్ను క్షమించండి, కానీ నేను చాలా కాలంగా Windowsతో పని చేయలేదు.
మన PCలో PHP యొక్క ఏ వెర్షన్ ఇన్‌స్టాల్ చేయబడని మరియు ఏమీ లేని పరిస్థితిని ఊహించుకుందాం.
డాకర్ మరియు డాకర్-కంపోజ్ యొక్క తాజా వెర్షన్‌లను ఇన్‌స్టాల్ చేయండి. (ఇది ఇంటర్నెట్‌లో చూడవచ్చు)
docker -v &&
docker-compose -v
1. ఉంచండి
git clone https://github.com/Laradock/laradock.git &&
ls
లారాడాక్ గురించి, ఇది చాలా కూల్ విషయం అని నేను చెప్తాను, ఇందులో చాలా కంటైనర్లు మరియు సహాయక విషయాలు ఉన్నాయి. కానీ దాని రిడెండెన్సీ కారణంగా ఉత్పత్తిలో మార్పులు లేకుండా లారాడాక్‌ని ఉపయోగించమని నేను సిఫార్సు చేయను. లారాడాక్‌లోని ఉదాహరణల ఆధారంగా మీ స్వంత కంటైనర్లను సృష్టించడం మంచిది, ఇది మరింత ఆప్టిమైజ్ చేయబడుతుంది, ఎందుకంటే ఎవరికీ ఒకే సమయంలో ఉన్న ప్రతిదీ అవసరం లేదు.
2. మా అప్లికేషన్‌ను అమలు చేయడానికి లారాడాక్‌ను కాన్ఫిగర్ చేయండి.
cd laradock &&
cp env-example .env
2.1 కొన్ని ఎడిటర్‌లో habr డైరెక్టరీని (లారాడాక్ క్లోన్ చేయబడిన పేరెంట్ ఫోల్డర్) తెరవండి. (నా PHPS స్టార్మ్ విషయంలో)
ఈ దశలో మేము ప్రాజెక్ట్ పేరు మాత్రమే ఇస్తాము.
2.2 కార్యస్థల చిత్రాన్ని ప్రారంభించండి. (మీ విషయంలో, చిత్రాలు నిర్మించడానికి కొంత సమయం పడుతుంది)
వర్క్‌స్పేస్ అనేది డెవలపర్ తరపున ఫ్రేమ్‌వర్క్‌తో పని చేయడానికి ప్రత్యేకంగా సిద్ధం చేయబడిన చిత్రం.
మేము ఉపయోగించి కంటైనర్ లోపలికి వెళ్తాము
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3 లారావెల్‌ని ఇన్‌స్టాల్ చేస్తోంది
composer create-project --prefer-dist laravel/laravel application
2.4 ఇన్‌స్టాలేషన్ తర్వాత, ప్రాజెక్ట్‌తో డైరెక్టరీ సృష్టించబడిందో లేదో తనిఖీ చేసి, కంపోజ్‌ని చంపండి.
ls
exit
docker-compose down
2.5 PHPStormకి తిరిగి వెళ్లి, .env ఫైల్‌లో మన లారావెల్ అప్లికేషన్‌కు సరైన మార్గాన్ని సెట్ చేద్దాం.
3. అన్ని కోడ్‌లను Gitకి జోడించండి.
దీన్ని చేయడానికి, మేము గితుబ్‌లో (లేదా మరెక్కడైనా) రిపోజిటరీని సృష్టిస్తాము. టెర్మినల్‌లోని habr డైరెక్టరీకి వెళ్లి క్రింది కోడ్‌ను అమలు చేద్దాం.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
ప్రతిదీ క్రమంలో ఉందో లేదో తనిఖీ చేద్దాం.
సౌలభ్యం కోసం, Git కోసం కొన్ని విజువల్ ఇంటర్‌ఫేస్‌ని ఉపయోగించమని నేను సిఫార్సు చేస్తున్నాను, నా విషయంలో అది . (ఇక్కడ ఒక రిఫరల్ లింక్ ఉంది)
4. లాంచ్ చేద్దాం!
ప్రారంభించడానికి ముందు, పోర్ట్‌లు 80 మరియు 443లో ఏదీ వేలాడదీయడం లేదని నిర్ధారించుకోండి.
docker-compose up -d nginx php-fpm
కాబట్టి, మా ప్రాజెక్ట్ 3 ప్రత్యేక సేవలను కలిగి ఉంటుంది:
- nginx - వెబ్ సర్వర్
- php-fpm - వెబ్ సర్వర్ నుండి అభ్యర్థనలను స్వీకరించడానికి php
- కార్యస్థలం - డెవలపర్‌ల కోసం php
ప్రస్తుతానికి, మేము 4లో 12 పాయింట్లను కలిసే అప్లికేషన్‌ని సృష్టించామని సాధించాము, అవి:
1. కోడ్‌బేస్ — అన్ని కోడ్‌లు ఒకే రిపోజిటరీలో ఉన్నాయి (చిన్న గమనిక: లారావెల్ ప్రాజెక్ట్‌లో డాకర్‌ని జోడించడం సరైనది కావచ్చు, కానీ ఇది ముఖ్యమైనది కాదు).
2. డిపెండెన్సీలు - మా డిపెండెన్సీలన్నీ అప్లికేషన్/composer.jsonలో మరియు ప్రతి కంటైనర్‌లోని ప్రతి డాకర్‌ఫైల్‌లో స్పష్టంగా వ్రాయబడ్డాయి.
3. బ్యాకింగ్ సేవలు — ప్రతి సేవ (php-fom, nignx, వర్క్‌స్పేస్) దాని స్వంత జీవితాన్ని గడుపుతుంది మరియు బయటి నుండి కనెక్ట్ చేయబడింది మరియు ఒక సేవతో పని చేస్తున్నప్పుడు, మరొకటి ప్రభావితం కాదు.
4. ప్రక్రియలు - ప్రతి సేవ ఒక ప్రక్రియ. ప్రతి సేవ అంతర్గత స్థితిని నిర్వహించదు.
5. పోర్ట్ బైండింగ్
docker ps
మనం చూడగలిగినట్లుగా, ప్రతి సేవ దాని స్వంత పోర్ట్‌లో నడుస్తుంది మరియు అన్ని ఇతర సేవలకు అందుబాటులో ఉంటుంది.
6. సమాంతరత
డాకర్ ఒకే సేవల యొక్క బహుళ ప్రక్రియలను వాటి మధ్య ఆటోమేటిక్ లోడ్ బ్యాలెన్సింగ్‌తో రూపొందించడానికి అనుమతిస్తుంది.
కంటైనర్లను ఆపి, వాటిని జెండా ద్వారా నడపండి --స్థాయి
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
మనం చూడగలిగినట్లుగా, php-fpm కంటైనర్ యొక్క కాపీలు సృష్టించబడ్డాయి. ఈ కంటైనర్‌తో పని చేయడంలో మేము దేనినీ మార్చాల్సిన అవసరం లేదు. మేము దీన్ని పోర్ట్ 9000లో యాక్సెస్ చేయడాన్ని కూడా కొనసాగిస్తాము మరియు డాకర్ మాకు కంటైనర్‌ల మధ్య లోడ్‌ను నియంత్రిస్తుంది.
7. డిస్పోజబిలిటీ - ప్రతి కంటైనర్‌ను మరొకదానికి హాని చేయకుండా చంపవచ్చు. కంటైనర్‌ను ఆపివేయడం లేదా పునఃప్రారంభించడం తదుపరి లాంచ్‌ల సమయంలో అప్లికేషన్ యొక్క ఆపరేషన్‌ను ప్రభావితం చేయదు. ప్రతి కంటైనర్‌ను ఎప్పుడైనా ఎత్తవచ్చు.
8. అప్లికేషన్ అభివృద్ధి/ఆపరేషన్ సమానత్వం - మన పరిసరాలన్నీ ఒకేలా ఉంటాయి. ఉత్పత్తిలో ఉన్న సర్వర్‌లో సిస్టమ్‌ను అమలు చేయడం ద్వారా, మీరు మీ ఆదేశాలలో దేనినీ మార్చాల్సిన అవసరం లేదు. ప్రతిదీ అదే విధంగా డాకర్‌పై ఆధారపడి ఉంటుంది.
9. లాగింగ్ — ఈ కంటైనర్‌లలోని అన్ని లాగ్‌లు స్ట్రీమ్‌కి వెళ్లి డాకర్ కన్సోల్‌లో కనిపిస్తాయి. (ఈ సందర్భంలో, వాస్తవానికి, ఇతర ఇంట్లో తయారుచేసిన కంటైనర్‌లతో, మీరు దానిని జాగ్రత్తగా చూసుకోకపోతే ఇది అలా ఉండకపోవచ్చు)
docker-compose logs -f
కానీ PHP మరియు Nginxలోని డిఫాల్ట్ విలువలు కూడా ఫైల్‌కి లాగ్‌లను వ్రాస్తాయి. 12 కారకాలకు అనుగుణంగా, ఇది అవసరం ఆపివేయడంలో ప్రతి కంటైనర్ యొక్క కాన్ఫిగరేషన్‌లలోని ఫైల్‌కు విడిగా లాగ్‌లను వ్రాయడం.
డాకర్ కేవలం stdoutకి మాత్రమే కాకుండా, నేను పైన పేర్కొన్న గ్రేలాగ్ వంటి వాటికి కూడా లాగ్‌లను పంపగల సామర్థ్యాన్ని అందిస్తుంది. మరియు గ్రేలాగ్ లోపల, మనకు నచ్చిన విధంగా లాగ్‌లను ఆపరేట్ చేయవచ్చు మరియు మా అప్లికేషన్ దీన్ని ఏ విధంగానూ గమనించదు.
<span style="font-family: arial; ">10</span> అడ్మినిస్ట్రేషన్ పనులు — 12 ఫ్యాక్టర్ అప్లికేషన్ యొక్క సృష్టికర్తలు కోరుకునే విధంగానే ఆర్టిసాన్ టూల్‌కు ధన్యవాదాలు, అన్ని అడ్మినిస్ట్రేషన్ పనులు లారావెల్ ద్వారా పరిష్కరించబడతాయి.
ఉదాహరణగా, కొన్ని ఆదేశాలు ఎలా అమలు చేయబడతాయో నేను చూపిస్తాను.
మేము కంటైనర్లోకి వెళ్తాము.
docker-compose exec workspace bash
php artisan list
ఇప్పుడు మనం ఏదైనా ఆదేశాన్ని ఉపయోగించవచ్చు. (దయచేసి మేము డేటాబేస్ మరియు కాష్‌ను కాన్ఫిగర్ చేయలేదని గమనించండి, కాబట్టి సగం కమాండ్‌లు సరిగ్గా అమలు చేయబడవు, ఎందుకంటే అవి కాష్ మరియు డేటాబేస్‌తో పని చేయడానికి రూపొందించబడ్డాయి).
<span style="font-family: arial; ">10</span> ఆకృతీకరణలు మరియు 12. బిల్డ్, రిలీజ్, రన్
నేను ఈ భాగాన్ని బ్లూ-గ్రీన్ డిప్లాయ్‌మెంట్‌కి అంకితం చేయాలనుకున్నాను, కానీ అది ఈ కథనానికి చాలా విస్తృతమైనదిగా మారింది. దీని గురించి నేను ప్రత్యేక వ్యాసం వ్రాస్తాను.
క్లుప్తంగా చెప్పాలంటే, కాన్సెప్ట్ CI/CD సిస్టమ్‌లపై ఆధారపడి ఉంటుంది జెంకిన్స్ и గిట్లాబ్ సీఐ. రెండింటిలోనూ, మీరు నిర్దిష్ట వాతావరణంతో అనుబంధించబడిన పర్యావరణ వేరియబుల్‌లను సెట్ చేయవచ్చు. దీని ప్రకారం, ఈ పరిస్థితిలో, పాయింట్ సి నెరవేరుతుంది ఆకృతీకరణలు.
మరియు పాయింట్ గురించి బిల్డ్, రిలీజ్, రన్ పేరుతో అంతర్నిర్మిత ఫంక్షన్ల ద్వారా పరిష్కరించబడుతుంది పైప్లైన్.
పైప్లైన్ అసెంబ్లీ, విడుదల మరియు అమలు యొక్క దశలను హైలైట్ చేస్తూ, విస్తరణ ప్రక్రియను అనేక దశలుగా విభజించడానికి మిమ్మల్ని అనుమతిస్తుంది. పైప్‌లైన్‌లో కూడా, మీరు బ్యాకప్‌లను సృష్టించవచ్చు మరియు నిజానికి ఏదైనా చేయవచ్చు. ఇది అపరిమితమైన సంభావ్యత కలిగిన సాధనం.
అప్లికేషన్ కోడ్ వద్ద ఉంది .
ఈ రిపోజిటరీని క్లోనింగ్ చేసేటప్పుడు సబ్‌మాడ్యూల్‌ని ప్రారంభించడం మర్చిపోవద్దు.
PS: ఈ విధానాలన్నీ ఇతర వినియోగాలు మరియు ప్రోగ్రామింగ్ భాషలతో ఉపయోగించవచ్చు. ప్రధాన విషయం ఏమిటంటే సారాంశం భిన్నంగా లేదు.
మూలం: www.habr.com