د "پیل" څخه په لسګونو ډیټا مرکزونو کې زرګونو سرورونو ته. څنګه موږ د لینکس زیربنا وده تعقیب کړه

که ستاسو د معلوماتي ټکنالوجۍ زیربنا خورا ګړندۍ وده وکړي ، نو تاسو به ژر یا وروسته د انتخاب سره مخ شئ: په منظم ډول د دې ملاتړ کولو لپاره بشري سرچینې زیات کړئ یا اتومات پیل کړئ. تر یو څه مودې پورې، موږ په لومړي تمثیل کې ژوند کاوه، او بیا د زیربنا په توګه کوډ ته اوږده لاره پیل شوه.

د "پیل" څخه په لسګونو ډیټا مرکزونو کې زرګونو سرورونو ته. څنګه موږ د لینکس زیربنا وده تعقیب کړه

البته، NSPK یو پیل نه دی، مګر دا ډول فضا د خپل شتون په لومړیو کلونو کې په شرکت کې واکمنه وه، او دا خورا په زړه پورې کلونه وو. زما نوم دی کورنیاکوف دیمیتري، زه د 10 کلونو راهیسې د لوړ شتون اړتیاو سره د لینکس زیربنا ملاتړ کوم. هغه د 2016 په جنورۍ کې د NSPK ټیم سره یوځای شو او له بده مرغه، د شرکت د شتون پیل یې ونه لید، مګر د سترو بدلونونو په مرحله کې راغی.

په عموم کې، موږ کولی شو ووایو چې زموږ ټیم د شرکت لپاره 2 محصولات چمتو کوي. لومړی زیربنا ده. میل باید کار وکړي، DNS باید کار وکړي، او د ډومین کنټرولر باید تاسو ته هغه سرورونو ته اجازه ورکړي چې باید ټکر نشي. د شرکت IT منظره خورا لویه ده! دا د سوداګرۍ او ماموریت مهم سیسټمونه دي، د ځینو لپاره د شتون اړتیاوې 99,999 دي. دوهم محصول پخپله سرورونه دي، فزیکي او مجازی. موجوده باید وڅارل شي، او نوي باید په منظمه توګه د ډیری څانګو پیرودونکو ته وسپارل شي. پدې مقاله کې زه غواړم تمرکز وکړم چې څنګه موږ زیربنا رامینځته کړې چې د سرور ژوند دورې لپاره مسؤل دي.

د سفر پیل

زموږ د سفر په پیل کې، زموږ د ټیکنالوژۍ سټیک داسې ښکاري:
OS CentOS 7
د FreeIPA ډومین کنټرولر
اتومات - ځواب ورکوونکی (+ برج)، موچی

دا ټول په 3 ډومینونو کې موقعیت لري، په ډیری ډیټا مرکزونو کې خپور شوی. په یو ډیټا مرکز کې د دفتر سیسټمونه او د ازموینې سایټونه شتون لري ، په پاتې برخه کې PROD شتون لري.

په یو وخت کې د سرورونو رامینځته کول داسې ښکاري:

د "پیل" څخه په لسګونو ډیټا مرکزونو کې زرګونو سرورونو ته. څنګه موږ د لینکس زیربنا وده تعقیب کړه

په VM ټیمپلیټ کې، CentOS لږترلږه دی او اړین لږترلږه د سم /etc/resolv.conf په څیر دی، پاتې نور د ځواب وړ له لارې راځي.

CMDB - Excel.

که سرور فزیکي وي، نو بیا د مجازی ماشین د کاپي کولو پرځای، OS د کوبلر په کارولو سره نصب شوی و - د هدف سرور MAC پتې د کوبلر ترتیب کې اضافه کیږي، سرور د DHCP له لارې IP پته ترلاسه کوي، او بیا د OS. اضافه کیږي

په لومړي سر کې موږ حتی هڅه وکړه چې په کوبلر کې یو ډول ترتیب مدیریت ترسره کړو. مګر د وخت په تیریدو سره ، دې د نورو ډیټا مرکزونو او د VMs چمتو کولو لپاره د ځواب وړ کوډ ته د تشکیلاتو پورټ وړتیا سره ستونزې رامینځته کول پیل کړل.

په هغه وخت کې، زموږ څخه ډیری د باش د مناسب تمدید په توګه ځواب ووایه او د شیل او سیډ په کارولو سره ډیزاینونو کې کمښت نه و. په ټولیز ډول د باشیبل. دا په نهایت کې د دې حقیقت لامل شوی چې که د کوم دلیل لپاره د لوبې کتاب په سرور کې کار نه کوي ، نو د سرور حذف کول اسانه وو ، د پلی بوک اصلاح کول او بیا یې چلول. په اصل کې د سکریپټونو نسخه نه وه، د تشکیلاتو هیڅ ډول وړتیا نه وه.

د مثال په توګه، موږ غوښتل چې په ټولو سرورونو کې یو څه ترتیب بدل کړو:

  1. موږ په منطقي برخه / ډیټا مرکز کې په موجوده سرورونو کې ترتیب بدلوو. ځینې ​​​​وختونه په یوه ورځ کې نه - د لاسرسي اړتیاوې او د لوی شمیر قانون اجازه نه ورکوي چې ټول بدلونونه په یوځل پلي شي. او ځینې بدلونونه احتمالي ویجاړونکي دي او د یو څه بیا پیل کولو ته اړتیا لري - له خدماتو څخه پخپله OS ته.
  2. په ځواب کې یې حل کول
  3. موږ دا په کوبلر کې حل کوو
  4. د هرې منطقي برخې / ډیټا مرکز لپاره N ځله تکرار کړئ

د دې لپاره چې ټول بدلونونه په اسانۍ سره پرمخ ولاړ شي، دا اړینه وه چې ډیری فکتورونه په پام کې ونیول شي، او بدلونونه په دوامداره توګه واقع کیږي.

  • د ځواب وړ کوډ بیاکتنه کول، د ترتیب کولو فایلونه
  • د داخلي غوره کړنو بدلول
  • د پیښو/حادثو د تحلیل د پایلو پر بنسټ بدلونونه
  • د امنیتي معیارونو بدلول، دواړه داخلي او بهرني. د مثال په توګه، PCI DSS هر کال د نوي اړتیاو سره تازه کیږي

د زیربنا وده او د سفر پیل

د سرورونو / منطقي ډومینونو / ډیټا مرکزونو شمیر وده کړې ، او د دوی سره په تشکیلاتو کې د غلطیو شمیر. په ځینو وختونو کې، موږ درې لارښوونو ته رسیدلي چې په کوم کې د ترتیب مدیریت ته اړتیا ده:

  1. اتوماتیک. په تکراري عملیاتو کې د انسان تېروتنې باید د امکان تر حده مخنیوی وشي.
  2. د تکرار وړتیا. د زیربنا اداره کول خورا اسانه دي کله چې د وړاندوینې وړ وي. د دوی چمتو کولو لپاره د سرورونو او وسیلو ترتیب باید هرچیرې ورته وي. دا د محصول ټیمونو لپاره هم مهم دی - د ازموینې وروسته ، غوښتنلیک باید تضمین شي چې د تولید چاپیریال کې پای ته ورسیږي چې د ازموینې چاپیریال ته ورته ترتیب شوی.
  3. د تشکیلاتو مدیریت کې د بدلونونو سادگي او روڼتیا.

دا د څو وسیلو اضافه کولو لپاره پاتې دي.

موږ GitLab CE زموږ د کوډ ذخیره کولو په توګه غوره کړی ، نه لږترلږه د دې جوړ شوي CI/CD ماډلونو لپاره.

د رازونو والټ - Hashicorp Vault, incl. د لوی API لپاره.

د ازموینې ترتیبونه او ځواب ورکوونکي رولونه - مالیکول + ټیسټینفرا. ازموینې خورا ګړندۍ کیږي که تاسو د ځواب وړ مایټوجن سره وصل شئ. په ورته وخت کې ، موږ د اتوماتیک ګمارنې لپاره خپل CMDB او آرکیسټرټر لیکل پیل کړل (د کوبلر پورته عکس کې) ، مګر دا یو بشپړ مختلف کیسه ده ، کوم چې زما همکار او د دې سیسټمونو اصلي پراختیا کونکی به په راتلونکي کې ووایی.

زموږ انتخاب:

مالیکول + Testinfra
ځواب وړ + برج + AWX
د سرورونو نړۍ + DITNET (خپل پرمختګ)
موچی
Gitlab + GitLab رنر
Hashicorp Vault

د "پیل" څخه په لسګونو ډیټا مرکزونو کې زرګونو سرورونو ته. څنګه موږ د لینکس زیربنا وده تعقیب کړه

په هرصورت، د ځواب وړ رولونو په اړه. په لومړي سر کې یوازې یو شتون درلود، مګر د څو بیاکتنې وروسته له دوی څخه 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 ځواب ورکوونکي رولونه. هر رول د جلا منطقي دندې حل کولو لپاره ډیزاین شوی (ننوتل، پلټنه، د کارونکي واک، څارنه، او نور).
  • د رول ازموینه. مالیکول + TestInfra.
  • خپل پراختیا: CMDB + آرکیسټرټر.
  • د سرور جوړولو وخت ~ 30 دقیقې دی، اتوماتیک او په عملي توګه د کاري کتار څخه خپلواک دی.
  • په ټولو برخو کې د زیربنا ورته حالت / نوم ورکول - د لوبو کتابونه، ذخیره، د مجازی کولو عناصر.
  • د معیار سره د توپیرونو په اړه د راپورونو تولید سره د سرور وضعیت ورځنی معاینه.

زه امید لرم چې زما کیسه به د هغه چا لپاره ګټوره وي چې د دوی د سفر په پیل کې وي. تاسو کوم اتوماتیک سټیک کاروئ؟

سرچینه: www.habr.com