ડઝન ડેટા સેન્ટર્સમાં "સ્ટાર્ટઅપ" થી હજારો સર્વર્સ સુધી. અમે કેવી રીતે લિનક્સ ઈન્ફ્રાસ્ટ્રક્ચરની વૃદ્ધિનો પીછો કર્યો

જો તમારું IT ઈન્ફ્રાસ્ટ્રક્ચર ખૂબ ઝડપથી વધે છે, તો તમારે વહેલા કે પછી એક પસંદગીનો સામનો કરવો પડશે: તેને ટેકો આપવા અથવા ઓટોમેશન શરૂ કરવા માટે માનવ સંસાધનોમાં એકસરખી વધારો કરો. અમુક બિંદુ સુધી, અમે પ્રથમ દૃષ્ટાંતમાં રહેતા હતા, અને પછી ઇન્ફ્રાસ્ટ્રક્ચર-એઝ-કોડનો લાંબો રસ્તો શરૂ થયો.

અલબત્ત, NSPK એ સ્ટાર્ટઅપ નથી, પરંતુ તેના અસ્તિત્વના પ્રથમ વર્ષોમાં કંપનીમાં આવા વાતાવરણનું શાસન હતું, અને તે વર્ષો ખૂબ જ રસપ્રદ હતા. મારું નામ કોર્ન્યાકોવ દિમિત્રી, હું 10 વર્ષથી વધુ સમયથી ઉચ્ચ ઉપલબ્ધતા આવશ્યકતાઓ સાથે Linux ઈન્ફ્રાસ્ટ્રક્ચરને સમર્થન આપું છું. તે જાન્યુઆરી 2016માં NSPK ટીમમાં જોડાયો અને કમનસીબે, કંપનીના અસ્તિત્વની શરૂઆત જ જોઈ ન હતી, પરંતુ તે મોટા ફેરફારોના તબક્કે આવ્યો હતો.

સામાન્ય રીતે, અમે કહી શકીએ કે અમારી ટીમ કંપની માટે 2 પ્રોડક્ટ્સ સપ્લાય કરે છે. પ્રથમ ઇન્ફ્રાસ્ટ્રક્ચર છે. મેઇલે કામ કરવું જોઈએ, DNS કામ કરવું જોઈએ અને ડોમેન નિયંત્રકોએ તમને એવા સર્વર્સમાં જવા દેવા જોઈએ જે ક્રેશ ન થાય. કંપનીનું આઇટી લેન્ડસ્કેપ વિશાળ છે! આ બિઝનેસ એન્ડ મિશન ક્રિટિકલ સિસ્ટમ્સ છે, કેટલાક માટે ઉપલબ્ધતાની જરૂરિયાતો 99,999 છે. બીજું ઉત્પાદન એ સર્વરો પોતે છે, ભૌતિક અને વર્ચ્યુઅલ. હાલના લોકો પર દેખરેખ રાખવાની જરૂર છે, અને નવા ઘણા વિભાગોના ગ્રાહકોને નિયમિતપણે પહોંચાડવા જોઈએ. આ લેખમાં હું સર્વર જીવન ચક્ર માટે જવાબદાર એવા ઈન્ફ્રાસ્ટ્રક્ચરને આપણે કેવી રીતે વિકસાવ્યું તેના પર ધ્યાન કેન્દ્રિત કરવા માંગુ છું.

પ્રવાસની શરૂઆત

અમારી મુસાફરીની શરૂઆતમાં, અમારી ટેક્નોલોજી સ્ટેક આના જેવો દેખાતો હતો:
OS CentOS 7
ફ્રીઆઈપીએ ડોમેન કંટ્રોલર્સ
ઓટોમેશન - જવાબી (+ટાવર), મોચી

આ બધું 3 ડોમેન્સમાં સ્થિત હતું, જે ઘણા ડેટા સેન્ટરોમાં ફેલાયેલું હતું. એક ડેટા સેન્ટરમાં ઓફિસ સિસ્ટમ્સ અને ટેસ્ટ સાઇટ્સ છે, બાકીનામાં PROD છે.

એક સમયે સર્વર બનાવવું આના જેવું દેખાતું હતું:

VM ટેમ્પલેટમાં, CentOS ન્યૂનતમ છે અને જરૂરી ન્યૂનતમ યોગ્ય /etc/resolv.conf જેવું છે, બાકીનું જવાબ Ansible દ્વારા આવે છે.

CMDB - એક્સેલ.

જો સર્વર ભૌતિક છે, તો વર્ચ્યુઅલ મશીનની નકલ કરવાને બદલે, કોબ્બલરનો ઉપયોગ કરીને તેના પર OS ઇન્સ્ટોલ કરવામાં આવ્યું હતું - લક્ષ્ય સર્વરના MAC સરનામાંઓ Cobbler રૂપરેખામાં ઉમેરવામાં આવે છે, સર્વર DHCP દ્વારા IP સરનામું મેળવે છે, અને પછી OS ઉમેરવામાં આવે છે.

પહેલા તો અમે Cobbler માં અમુક પ્રકારનું રૂપરેખાંકન વ્યવસ્થાપન કરવાનો પ્રયાસ પણ કર્યો. પરંતુ સમય જતાં, આનાથી અન્ય ડેટા સેન્ટરો અને VM તૈયાર કરવા માટેના જવાબી કોડ બંનેમાં રૂપરેખાંકનની પોર્ટેબિલિટીમાં સમસ્યા આવવા લાગી.

તે સમયે, આપણામાંના ઘણાએ બાશના અનુકૂળ વિસ્તરણ તરીકે Ansible સમજ્યું હતું અને શેલ અને સેડનો ઉપયોગ કરીને ડિઝાઇનમાં કંજૂસાઈ નહોતી કરી. એકંદરે Bashsible. આ આખરે એ હકીકત તરફ દોરી ગયું કે જો કોઈ કારણોસર પ્લેબુક સર્વર પર કામ કરતું ન હતું, તો સર્વરને કાઢી નાખવું, પ્લેબુકને ઠીક કરવું અને તેને ફરીથી ચલાવવું સરળ હતું. ત્યાં અનિવાર્યપણે સ્ક્રિપ્ટ્સનું કોઈ સંસ્કરણ નહોતું, રૂપરેખાંકનોની કોઈ પોર્ટેબિલિટી નહોતી.

ઉદાહરણ તરીકે, અમે બધા સર્વર્સ પર અમુક રૂપરેખા બદલવા માંગીએ છીએ:

1. અમે લોજિકલ સેગમેન્ટ/ડેટા સેન્ટરમાં હાલના સર્વર્સ પર ગોઠવણી બદલીએ છીએ. કેટલીકવાર એક દિવસમાં નહીં - ઍક્સેસિબિલિટી આવશ્યકતાઓ અને મોટી સંખ્યામાં કાયદો બધા ફેરફારોને એક જ સમયે લાગુ કરવાની મંજૂરી આપતા નથી. અને કેટલાક ફેરફારો સંભવિત રૂપે વિનાશક છે અને તેને કંઈક પુનઃપ્રારંભ કરવાની જરૂર છે - સેવાઓથી લઈને OS સુધી.
2. જવાબમાં તેને ઠીક કરી રહ્યા છીએ
3. અમે તેને મોચીમાં ઠીક કરીએ છીએ
4. દરેક લોજિકલ સેગમેન્ટ/ડેટા સેન્ટર માટે N વખત પુનરાવર્તન કરો

બધા ફેરફારો સરળતાથી થાય તે માટે, ઘણા પરિબળોને ધ્યાનમાં લેવું જરૂરી હતું, અને ફેરફારો સતત થાય છે.

• રિફેક્ટરિંગ એન્સિબલ કોડ, રૂપરેખાંકન ફાઇલો
• આંતરિક શ્રેષ્ઠ પ્રથાઓ બદલવી
• ઘટનાઓ/અકસ્માતોના વિશ્લેષણના પરિણામો પર આધારિત ફેરફારો
• આંતરિક અને બાહ્ય બંને સુરક્ષા ધોરણો બદલતા. ઉદાહરણ તરીકે, PCI DSS દર વર્ષે નવી જરૂરિયાતો સાથે અપડેટ થાય છે

ઈન્ફ્રાસ્ટ્રક્ચર વૃદ્ધિ અને પ્રવાસની શરૂઆત

સર્વર/લોજિકલ ડોમેન્સ/ડેટા કેન્દ્રોની સંખ્યામાં વધારો થયો છે અને તેમની સાથે રૂપરેખાંકનમાં ભૂલોની સંખ્યા વધી છે. અમુક સમયે, અમે ત્રણ દિશાઓ પર આવ્યા જેમાં રૂપરેખાંકન વ્યવસ્થાપન વિકસાવવાની જરૂર છે:

1. ઓટોમેશન. પુનરાવર્તિત કામગીરીમાં માનવીય ભૂલ શક્ય તેટલી ટાળવી જોઈએ.
2. પુનરાવર્તિતતા. જ્યારે તે અનુમાનિત હોય ત્યારે ઈન્ફ્રાસ્ટ્રક્ચરનું સંચાલન કરવું ખૂબ સરળ છે. સર્વર અને તેમની તૈયારી માટેના સાધનોનું રૂપરેખાંકન દરેક જગ્યાએ સમાન હોવું જોઈએ. ઉત્પાદન ટીમો માટે પણ આ મહત્વપૂર્ણ છે - પરીક્ષણ કર્યા પછી, એપ્લિકેશનને પરીક્ષણ પર્યાવરણની જેમ જ ગોઠવેલા ઉત્પાદન વાતાવરણમાં સમાપ્ત થવાની ખાતરી આપવી આવશ્યક છે.
3. રૂપરેખાંકન વ્યવસ્થાપનમાં ફેરફાર કરવાની સરળતા અને પારદર્શિતા.

તે કેટલાક સાધનો ઉમેરવાનું બાકી છે.

અમે GitLab CE ને અમારા કોડ રિપોઝીટરી તરીકે પસંદ કર્યું છે, ઓછામાં ઓછા તેના બિલ્ટ-ઇન CI/CD મોડ્યુલો માટે નહીં.

રહસ્યોની વૉલ્ટ - હાશિકોર્પ વૉલ્ટ, સહિત. મહાન API માટે.

પરીક્ષણ રૂપરેખાંકનો અને જવાબદાર ભૂમિકાઓ - મોલેક્યુલ+ટેસ્ટિનફ્રા. જો તમે અન્સિબલ મિટોજન સાથે કનેક્ટ થાઓ તો ટેસ્ટ વધુ ઝડપથી થાય છે. તે જ સમયે, અમે સ્વચાલિત જમાવટ માટે અમારા પોતાના CMDB અને ઓર્કેસ્ટ્રેટરને લખવાનું શરૂ કર્યું (કોબ્લર ઉપરના ચિત્રમાં), પરંતુ આ એક સંપૂર્ણપણે અલગ વાર્તા છે, જે મારા સાથીદાર અને આ સિસ્ટમ્સના મુખ્ય વિકાસકર્તા ભવિષ્યમાં કહેશે.

અમારી પસંદગી:

મોલેક્યુલ + ટેસ્ટિનફ્રા
જવાબી + ટાવર + AWX
સર્વર્સની દુનિયા + DITNET (પોતાનો વિકાસ)
મોચી
Gitlab + GitLab રનર
હાશિકોર્પ વૉલ્ટ

માર્ગ દ્વારા, જવાબદાર ભૂમિકાઓ વિશે. શરૂઆતમાં ત્યાં ફક્ત એક જ હતું, પરંતુ ઘણા રિફેક્ટરિંગ પછી તેમાંના 17 હતા. હું ભારપૂર્વક ભલામણ કરું છું કે મોનોલિથને ઇમ્પોટેન્ટ ભૂમિકાઓમાં તોડવો, જે પછીથી અલગથી શરૂ કરી શકાય છે; વધુમાં, તમે ટૅગ્સ ઉમેરી શકો છો. અમે ભૂમિકાઓને કાર્યક્ષમતા દ્વારા વિભાજિત કરી છે - નેટવર્ક, લોગીંગ, પેકેજો, હાર્ડવેર, મોલેક્યુલ વગેરે. સામાન્ય રીતે, અમે નીચેની વ્યૂહરચનાનું પાલન કર્યું. હું આગ્રહ કરતો નથી કે આ એકમાત્ર સત્ય છે, પરંતુ તે આપણા માટે કામ કરે છે.

• "ગોલ્ડન ઇમેજ" માંથી સર્વરની નકલ કરવી એ દુષ્ટ છે!મુખ્ય ગેરલાભ એ છે કે તમે બરાબર જાણતા નથી કે છબીઓ અત્યારે કઈ સ્થિતિમાં છે, અને બધા ફેરફારો બધા વર્ચ્યુઅલાઈઝેશન ફાર્મમાં બધી છબીઓમાં આવશે.
• ડિફોલ્ટ રૂપરેખાંકન ફાઇલોનો ઓછામાં ઓછો ઉપયોગ કરો અને અન્ય વિભાગો સાથે સંમત થાઓ કે તમે મુખ્ય સિસ્ટમ ફાઇલો માટે જવાબદાર છો, ઉદાહરણ તરીકે:
  1. /etc/sysctl.conf ખાલી છોડો, સેટિંગ્સ ફક્ત /etc/sysctl.d/ માં હોવી જોઈએ. એક ફાઇલમાં તમારું ડિફોલ્ટ, બીજી ફાઇલમાં એપ્લિકેશન માટે કસ્ટમ.
  2. સિસ્ટમ્ડ એકમોને સંપાદિત કરવા માટે ઓવરરાઇડ ફાઇલોનો ઉપયોગ કરો.
• તમામ રૂપરેખાઓને ટેમ્પલેટ કરો અને તેનો સંપૂર્ણ સમાવેશ કરો; જો શક્ય હોય તો, પ્લેબુકમાં કોઈ સેડ અથવા તેના એનાલોગ નથી
• રૂપરેખાંકન વ્યવસ્થાપન સિસ્ટમ કોડ રિફેક્ટીંગ:
  1. કાર્યોને તાર્કિક એકમોમાં વિભાજીત કરો અને મોનોલિથને ભૂમિકાઓમાં ફરીથી લખો
  2. લિન્ટર્સનો ઉપયોગ કરો! જવાબી-લિન્ટ, યામલ-લિન્ટ, વગેરે
  3. તમારો અભિગમ બદલો! આ બોલ પર કોઈ રન નોંધાયો નહીં. સિસ્ટમની સ્થિતિનું વર્ણન કરવું જરૂરી છે
• તમામ જવાબી ભૂમિકાઓ માટે તમારે પરમાણુમાં પરીક્ષણો લખવાની અને દિવસમાં એકવાર રિપોર્ટ્સ બનાવવાની જરૂર છે.
• અમારા કિસ્સામાં, પરીક્ષણો તૈયાર કર્યા પછી (જેમાંથી 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