మీ IT ఇన్‌ఫ్రాస్ట్రక్చర్ చాలా త్వరగా పెరిగితే, మీరు త్వరగా లేదా తర్వాత ఎంపికను ఎదుర్కొంటారు: దానికి మద్దతు ఇవ్వడానికి మానవ వనరులను సరళంగా పెంచండి లేదా ఆటోమేషన్‌ను ప్రారంభించండి. కొంత సమయం వరకు, మేము మొదటి నమూనాలో జీవించాము, ఆపై ఇన్‌ఫ్రాస్ట్రక్చర్-కోడ్-కోడ్‌కు సుదీర్ఘ మార్గం ప్రారంభమైంది.
వాస్తవానికి, NSPK ఒక స్టార్టప్ కాదు, కానీ అటువంటి వాతావరణం దాని ఉనికి యొక్క మొదటి సంవత్సరాల్లో సంస్థలో పాలించింది మరియు అవి చాలా ఆసక్తికరమైన సంవత్సరాలు. నా పేరు , నేను 10 సంవత్సరాలుగా అధిక లభ్యత అవసరాలతో Linux మౌలిక సదుపాయాలకు మద్దతు ఇస్తున్నాను. అతను జనవరి 2016 లో NSPK బృందంలో చేరాడు మరియు దురదృష్టవశాత్తు, కంపెనీ ఉనికి యొక్క ప్రారంభాన్ని చూడలేదు, కానీ గొప్ప మార్పుల దశలో వచ్చాడు.
సాధారణంగా, మా బృందం కంపెనీకి 2 ఉత్పత్తులను సరఫరా చేస్తుందని మేము చెప్పగలం. మొదటిది మౌలిక సదుపాయాలు. మెయిల్ పని చేయాలి, DNS పని చేయాలి మరియు డొమైన్ కంట్రోలర్లు మిమ్మల్ని క్రాష్ చేయని సర్వర్‌లలోకి అనుమతిస్తాయి. కంపెనీ IT ల్యాండ్‌స్కేప్ చాలా పెద్దది! ఇవి బిజినెస్&మిషన్ క్రిటికల్ సిస్టమ్‌లు, కొన్నింటికి లభ్యత అవసరాలు 99,999. రెండవ ఉత్పత్తి సర్వర్లు, భౌతిక మరియు వర్చువల్. ఇప్పటికే ఉన్న వాటిని పర్యవేక్షించాల్సిన అవసరం ఉంది మరియు అనేక విభాగాల నుండి వినియోగదారులకు కొత్త వాటిని క్రమం తప్పకుండా పంపిణీ చేయాలి. ఈ వ్యాసంలో నేను సర్వర్ జీవిత చక్రానికి బాధ్యత వహించే మౌలిక సదుపాయాలను ఎలా అభివృద్ధి చేసాము అనే దానిపై దృష్టి పెట్టాలనుకుంటున్నాను.
మార్గం ప్రారంభం
మా ప్రయాణం ప్రారంభంలో, మా టెక్నాలజీ స్టాక్ ఇలా ఉంది:
OS CentOS 7
FreeIPA డొమైన్ కంట్రోలర్లు
ఆటోమేషన్ - అన్సిబుల్(+టవర్), చెప్పులు కుట్టేవాడు
ఇవన్నీ 3 డొమైన్‌లలో ఉన్నాయి, అనేక డేటా సెంటర్లలో విస్తరించి ఉన్నాయి. ఒక డేటా సెంటర్‌లో ఆఫీస్ సిస్టమ్‌లు మరియు టెస్ట్ సైట్‌లు ఉన్నాయి, మిగిలిన వాటిలో PROD ఉంది.
ఒక సమయంలో సర్వర్‌లను సృష్టించడం ఇలా కనిపిస్తుంది:
VM టెంప్లేట్‌లో, CentOS కనిష్టంగా ఉంటుంది మరియు అవసరమైన కనీసము సరైన /etc/resolv.conf లాగా ఉంటుంది, మిగిలినవి Ansible ద్వారా వస్తాయి.
CMDB - ఎక్సెల్.
సర్వర్ భౌతికంగా ఉంటే, వర్చువల్ మెషీన్‌ను కాపీ చేయడానికి బదులుగా, కోబ్లర్‌ని ఉపయోగించి దానిపై OS ఇన్‌స్టాల్ చేయబడింది - టార్గెట్ సర్వర్ యొక్క MAC చిరునామాలు కోబ్లర్ కాన్ఫిగరేషన్‌కు జోడించబడతాయి, సర్వర్ DHCP ద్వారా IP చిరునామాను అందుకుంటుంది, ఆపై OS జోడించబడింది.
మొదట మేము కోబ్లర్‌లో ఒకరకమైన కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ చేయడానికి కూడా ప్రయత్నించాము. కానీ కాలక్రమేణా, ఇది ఇతర డేటా సెంటర్‌లకు మరియు VMలను సిద్ధం చేయడానికి అన్సిబుల్ కోడ్‌కు కాన్ఫిగరేషన్‌ల పోర్టబిలిటీతో సమస్యలను తీసుకురావడం ప్రారంభించింది.
ఆ సమయంలో, మనలో చాలామంది అన్సిబుల్‌ను బాష్ యొక్క అనుకూలమైన పొడిగింపుగా భావించారు మరియు షెల్ మరియు సెడ్‌లను ఉపయోగించి డిజైన్‌లను తగ్గించలేదు. మొత్తంగా Bashsible. కొన్ని కారణాల వల్ల ప్లేబుక్ సర్వర్‌లో పని చేయకపోతే, సర్వర్‌ను తొలగించడం, ప్లేబుక్‌ను పరిష్కరించడం మరియు దాన్ని మళ్లీ అమలు చేయడం సులభం అనే వాస్తవం ఇది చివరికి దారితీసింది. తప్పనిసరిగా స్క్రిప్ట్‌ల సంస్కరణ లేదు, కాన్ఫిగరేషన్‌ల పోర్టబిలిటీ లేదు.
ఉదాహరణకు, మేము అన్ని సర్వర్‌లలో కొన్ని కాన్ఫిగరేషన్‌లను మార్చాలనుకుంటున్నాము:
- మేము లాజికల్ సెగ్మెంట్/డేటా సెంటర్‌లో ఇప్పటికే ఉన్న సర్వర్‌లలో కాన్ఫిగరేషన్‌ను మారుస్తాము. కొన్నిసార్లు ఒక రోజులో కాదు - ప్రాప్యత అవసరాలు మరియు పెద్ద సంఖ్యల చట్టం అన్ని మార్పులను ఒకేసారి వర్తింపజేయడానికి అనుమతించవు. మరియు కొన్ని మార్పులు వినాశకరమైనవి మరియు ఏదైనా పునఃప్రారంభించవలసి ఉంటుంది - సేవల నుండి OS వరకు.
- Ansible లో దాన్ని పరిష్కరించడం
- మేము దానిని కోబ్లర్‌లో పరిష్కరించాము
- ప్రతి లాజికల్ సెగ్మెంట్/డేటా సెంటర్ కోసం N సార్లు పునరావృతం చేయండి
అన్ని మార్పులు సజావుగా సాగడానికి, అనేక అంశాలను పరిగణనలోకి తీసుకోవడం అవసరం, మరియు మార్పులు నిరంతరం జరుగుతాయి.
- రీఫ్యాక్టరింగ్ అన్సిబుల్ కోడ్, కాన్ఫిగరేషన్ ఫైల్స్
- అంతర్గత ఉత్తమ పద్ధతులను మార్చడం
- సంఘటనలు/ప్రమాదాల విశ్లేషణ ఫలితాల ఆధారంగా మార్పులు
- అంతర్గత మరియు బాహ్య భద్రతా ప్రమాణాలను మార్చడం. ఉదాహరణకు, PCI DSS ప్రతి సంవత్సరం కొత్త అవసరాలతో నవీకరించబడుతుంది
మౌలిక సదుపాయాల పెరుగుదల మరియు ప్రయాణం ప్రారంభం
సర్వర్లు/లాజికల్ డొమైన్‌లు/డేటా సెంటర్‌ల సంఖ్య పెరిగింది మరియు వాటితో పాటు కాన్ఫిగరేషన్‌లలో ఎర్రర్‌ల సంఖ్య పెరిగింది. ఏదో ఒక సమయంలో, మేము కాన్ఫిగరేషన్ నిర్వహణను అభివృద్ధి చేయవలసిన మూడు దిశలకు వచ్చాము:
- ఆటోమేషన్. పునరావృతమయ్యే ఆపరేషన్లలో మానవ తప్పిదాలను వీలైనంత వరకు నివారించాలి.
- పునరావృతం. ఇది ఊహించదగినది అయినప్పుడు మౌలిక సదుపాయాలను నిర్వహించడం చాలా సులభం. సర్వర్లు మరియు వాటి తయారీ కోసం సాధనాల కాన్ఫిగరేషన్ ప్రతిచోటా ఒకే విధంగా ఉండాలి. ఇది ఉత్పత్తి బృందాలకు కూడా ముఖ్యమైనది - పరీక్ష తర్వాత, అప్లికేషన్ తప్పనిసరిగా పరీక్ష వాతావరణంలో కాన్ఫిగర్ చేయబడిన ఉత్పత్తి వాతావరణంలో ముగుస్తుందని హామీ ఇవ్వాలి.
- కాన్ఫిగరేషన్ నిర్వహణలో మార్పులు చేయడంలో సరళత మరియు పారదర్శకత.
ఇది కొన్ని సాధనాలను జోడించడానికి మిగిలి ఉంది.
మేము GitLab CEని మా కోడ్ రిపోజిటరీగా ఎంచుకున్నాము, దాని అంతర్నిర్మిత CI/CD మాడ్యూల్‌ల కోసం కాదు.
రహస్యాల వాల్ట్ - హాషికార్ప్ వాల్ట్, సహా. గొప్ప API కోసం.
టెస్టింగ్ కాన్ఫిగరేషన్‌లు మరియు అన్సిబుల్ రోల్స్ - మాలిక్యూల్+టెస్టిన్‌ఫ్రా. మీరు యాన్సిబుల్ మైటోజెన్‌కి కనెక్ట్ చేస్తే పరీక్షలు చాలా వేగంగా జరుగుతాయి. అదే సమయంలో, మేము స్వయంచాలక విస్తరణ కోసం మా స్వంత CMDB మరియు ఆర్కెస్ట్రేటర్‌ను వ్రాయడం ప్రారంభించాము (కాబ్లర్ పై చిత్రంలో), కానీ ఇది పూర్తిగా భిన్నమైన కథ, ఇది నా సహోద్యోగి మరియు ఈ సిస్టమ్‌ల యొక్క ప్రధాన డెవలపర్ భవిష్యత్తులో చెబుతారు.
మా ఎంపిక:
మాలిక్యూల్ + టెస్ఇన్‌ఫ్రా
అన్సిబుల్ + టవర్ + AWX
సర్వర్ల ప్రపంచం + DITNET (సొంత అభివృద్ధి)
చెప్పులు కుట్టేవాడు
Gitlab + GitLab రన్నర్
హాషికార్ప్ వాల్ట్
మార్గం ద్వారా, అసలైన పాత్రల గురించి. మొదట ఒకటి మాత్రమే ఉంది, కానీ అనేక రీఫ్యాక్టరింగ్‌ల తర్వాత వాటిలో 17 ఉన్నాయి. మోనోలిత్‌ను ఐడెంపోటెంట్ పాత్రలుగా విభజించాలని నేను గట్టిగా సిఫార్సు చేస్తున్నాను, దానిని విడిగా ప్రారంభించవచ్చు; అదనంగా, మీరు ట్యాగ్‌లను జోడించవచ్చు. మేము పాత్రలను కార్యాచరణ ద్వారా విభజించాము - నెట్‌వర్క్, లాగింగ్, ప్యాకేజీలు, హార్డ్‌వేర్, మాలిక్యూల్ మొదలైనవి. సాధారణంగా, మేము దిగువ వ్యూహాన్ని అనుసరించాము. ఇది మాత్రమే నిజం అని నేను పట్టుబట్టడం లేదు, కానీ ఇది మాకు పని చేసింది.
- "గోల్డెన్ ఇమేజ్" నుండి సర్వర్‌లను కాపీ చేయడం దుర్మార్గం!ప్రధాన ప్రతికూలత ఏమిటంటే, చిత్రాలు ఇప్పుడు ఏ స్థితిలో ఉన్నాయో మీకు ఖచ్చితంగా తెలియదు మరియు అన్ని వర్చువలైజేషన్ ఫారమ్‌లలోని అన్ని చిత్రాలకు అన్ని మార్పులు వస్తాయి.
- డిఫాల్ట్ కాన్ఫిగరేషన్ ఫైల్‌లను కనిష్టంగా ఉపయోగించండి మరియు ప్రధాన సిస్టమ్ ఫైల్‌లకు మీరు బాధ్యత వహించే ఇతర విభాగాలతో అంగీకరిస్తున్నారుఉదాహరణకు:
- /etc/sysctl.conf ఖాళీని వదిలివేయండి, సెట్టింగ్‌లు /etc/sysctl.d/లో మాత్రమే ఉండాలి. ఒక ఫైల్‌లో మీ డిఫాల్ట్, మరొక ఫైల్‌లో అప్లికేషన్ కోసం అనుకూలం.
- systemd యూనిట్‌లను సవరించడానికి ఓవర్‌రైడ్ ఫైల్‌లను ఉపయోగించండి.
- అన్ని కాన్ఫిగర్‌లను టెంప్లేట్ చేయండి మరియు వాటిని పూర్తిగా చేర్చండి; వీలైతే, ప్లేబుక్‌లలో సెడ్ లేదా దాని అనలాగ్‌లు లేవు
- కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సిస్టమ్ కోడ్‌ను రీఫ్యాక్టరింగ్ చేయడం:
- టాస్క్‌లను లాజికల్ ఎంటిటీలుగా విడగొట్టండి మరియు ఏకశిలా పాత్రలను తిరిగి వ్రాయండి
- లింటర్లు ఉపయోగించండి! Ansible-lint, yaml-lint, మొదలైనవి
- మీ విధానాన్ని మార్చుకోండి! బాష్‌సిబుల్ లేదు. వ్యవస్థ యొక్క స్థితిని వివరించడం అవసరం
- అన్ని అన్సిబుల్ పాత్రల కోసం మీరు అణువులో పరీక్షలు రాయాలి మరియు రోజుకు ఒకసారి నివేదికలను రూపొందించాలి.
- మా విషయంలో, పరీక్షలను సిద్ధం చేసిన తర్వాత (వీటిలో 100 కంటే ఎక్కువ ఉన్నాయి), సుమారు 70000 లోపాలు కనుగొనబడ్డాయి. దాన్ని సరిచేయడానికి చాలా నెలలు పట్టింది.
మా అమలు
కాబట్టి, అసలైన పాత్రలు సిద్ధంగా ఉన్నాయి, టెంప్లేట్ చేయబడ్డాయి మరియు లింటర్ల ద్వారా తనిఖీ చేయబడ్డాయి. మరియు గిట్లు కూడా ప్రతిచోటా పెంచబడతాయి. కానీ వివిధ విభాగాలకు విశ్వసనీయ కోడ్ డెలివరీ ప్రశ్న తెరిచి ఉంది. మేము స్క్రిప్ట్‌లతో సమకాలీకరించాలని నిర్ణయించుకున్నాము. అలా కనిపిస్తుంది:
మార్పు వచ్చిన తర్వాత, CI ప్రారంభించబడుతుంది, పరీక్ష సర్వర్ సృష్టించబడుతుంది, పాత్రలు రూపొందించబడతాయి మరియు అణువు ద్వారా పరీక్షించబడతాయి. ప్రతిదీ సరిగ్గా ఉంటే, కోడ్ ఉత్పత్తి శాఖకు వెళుతుంది. కానీ మేము మెషీన్‌లో ఇప్పటికే ఉన్న సర్వర్‌లకు కొత్త కోడ్‌ని వర్తింపజేయము. ఇది మా సిస్టమ్‌ల అధిక లభ్యత కోసం అవసరమైన ఒక రకమైన స్టాపర్. మరియు మౌలిక సదుపాయాలు భారీగా మారినప్పుడు, పెద్ద సంఖ్యల చట్టం అమలులోకి వస్తుంది - మార్పు ప్రమాదకరం కాదని మీకు ఖచ్చితంగా తెలిసినప్పటికీ, అది భయంకరమైన పరిణామాలకు దారి తీస్తుంది.
సర్వర్‌లను సృష్టించడానికి అనేక ఎంపికలు కూడా ఉన్నాయి. మేము అనుకూల పైథాన్ స్క్రిప్ట్‌లను ఎంచుకోవడం ముగించాము. మరియు CI అన్సిబుల్ కోసం:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"ఇది మేము వచ్చాము, వ్యవస్థ జీవించడం మరియు అభివృద్ధి చెందడం కొనసాగుతుంది.
- సర్వర్‌ని సెటప్ చేయడానికి 17 ముఖ్యమైన పాత్రలు. ప్రతి పాత్రలు ప్రత్యేక తార్కిక పనిని (లాగింగ్, ఆడిటింగ్, వినియోగదారు అధికారం, పర్యవేక్షణ మొదలైనవి) పరిష్కరించడానికి రూపొందించబడ్డాయి.
- పాత్ర పరీక్ష. మాలిక్యూల్ + టెస్ట్ఇన్‌ఫ్రా.
- స్వంత అభివృద్ధి: CMDB + ఆర్కెస్ట్రేటర్.
- సర్వర్ సృష్టి సమయం ~30 నిమిషాలు, ఆటోమేటెడ్ మరియు టాస్క్ క్యూ నుండి ఆచరణాత్మకంగా స్వతంత్రంగా ఉంటుంది.
- ప్లేబుక్‌లు, రిపోజిటరీలు, వర్చువలైజేషన్ ఎలిమెంట్‌లు - అన్ని విభాగాలలో మౌలిక సదుపాయాల యొక్క ఒకే స్థితి/పేరు.
- ప్రమాణంతో వ్యత్యాసాలపై నివేదికల ఉత్పత్తితో సర్వర్ స్థితిని రోజువారీ తనిఖీ చేయండి.
ప్రయాణం ప్రారంభంలో ఉన్న వారికి నా కథ ఉపయోగపడుతుందని ఆశిస్తున్నాను. మీరు ఏ ఆటోమేషన్ స్టాక్‌ని ఉపయోగిస్తున్నారు?
మూలం: www.habr.com