Хэрэв таны мэдээллийн технологийн дэд бүтэц хэт хурдан хөгжвөл эрт орой хэзээ нэгэн цагт та үүнийг дэмжих хүний нөөцийг шугаман нэмэгдүүлэх эсвэл автоматжуулалтыг эхлүүлэх гэсэн сонголттой тулгарах болно. Хэзээ нэгэн цагт бид эхний парадигмаар амьдарч, дараа нь Дэд бүтэц-код руу хүрэх урт зам эхэлсэн.
Мэдээжийн хэрэг, NSPK бол стартап биш, гэхдээ ийм уур амьсгал компани байгуулагдсаны эхний жилүүдэд ноёрхсон бөгөөд тэдгээр нь маш сонирхолтой жилүүд байсан. Миний нэр , Би 10 гаруй жилийн турш өндөр хүртээмжтэй байх шаардлагатай Линуксийн дэд бүтцийг дэмжиж ирсэн. Тэрээр 2016 оны XNUMX-р сард NSPK-ийн багт элссэн бөгөөд харамсалтай нь компанийн оршин тогтнох эхлэлийг хараагүй ч томоохон өөрчлөлтийн үе шатанд ирсэн.
Ерөнхийдөө манай хамт олон компанид 2 бүтээгдэхүүн нийлүүлдэг гэж хэлж болно. Эхнийх нь дэд бүтэц. Мэйл ажиллах ёстой, DNS ажиллах ёстой бөгөөд домэйн хянагч нь таныг гацах ёсгүй серверт оруулахыг зөвшөөрөх ёстой. Компанийн мэдээллийн технологийн ландшафт асар том юм! Эдгээр нь бизнесийн болон даалгаварт чухал системүүд бөгөөд заримынх нь бэлэн байдлын шаардлага 99,999 байна. Хоёрдахь бүтээгдэхүүн нь серверүүд өөрсдөө, физик болон виртуал. Байгааг нь хянаж, шинийг олон хэлтсээс хэрэглэгчдэд тогтмол хүргэж байх шаардлагатай. Энэ нийтлэлд би серверийн амьдралын мөчлөгийг хариуцдаг дэд бүтцийг хэрхэн хөгжүүлсэн талаар анхаарлаа хандуулахыг хүсч байна.
Аялалын эхлэл
Аялалын эхэнд бидний технологийн стек дараах байдалтай байсан.
OS CentOS 7
FreeIPA домэйн хянагч
Автоматжуулалт - Ansible(+Tower), Гуталчин
Энэ бүхэн хэд хэдэн мэдээллийн төвд тархсан 3 домэйнд байрладаг байв. Нэг мэдээллийн төвд оффисын систем, туршилтын сайтууд байдаг бол бусад хэсэгт PROD байдаг.
Нэгэн цагт сервер үүсгэх нь дараах байдалтай байв.
VM загварт CentOS нь хамгийн бага бөгөөд шаардлагатай доод хэмжээ нь зөв /etc/resolv.conf шиг, бусад нь Ansible-ээр дамждаг.
CMDB - Excel.
Хэрэв сервер нь физик бол виртуал машиныг хуулахын оронд OS-ийг Cobbler ашиглан суулгасан - зорилтот серверийн MAC хаягуудыг Cobbler тохиргоонд нэмж, сервер DHCP-ээр дамжуулан IP хаягийг хүлээн авч, дараа нь үйлдлийн систем нэмэгдсэн байна.
Эхлээд бид Cobbler-д ямар нэгэн тохиргооны менежмент хийхийг оролдсон. Гэвч цаг хугацаа өнгөрөхөд энэ нь бусад өгөгдлийн төвүүд болон VM бэлтгэх Ansible код руу тохиргоог зөөвөрлөхөд асуудал үүсгэж эхэлсэн.
Тэр үед бидний олонхи нь Ansible-ийг Bash-ийн тохиромжтой өргөтгөл гэж ойлгодог байсан бөгөөд shell болон sed-ийг ашиглан дизайн хийхээс татгалздаггүй байв. Ерөнхийдөө Bashsible. Энэ нь эцэст нь тоглоомын дэвтэр ямар нэг шалтгаанаар сервер дээр ажиллахгүй бол серверийг устгаж, тоглуулах номыг засаад дахин ажиллуулахад хялбар болсон. Үндсэндээ скриптүүдийн хувилбар байхгүй, тохиргоог зөөвөрлөх боломжгүй байсан.
Жишээлбэл, бид бүх сервер дээрх зарим тохиргоог өөрчлөхийг хүссэн:
- Бид логик сегмент/өгөгдлийн төвд байгаа серверүүдийн тохиргоог өөрчилдөг. Заримдаа нэг өдрийн дотор биш - хүртээмжтэй байдлын шаардлага, олон тооны хууль нь бүх өөрчлөлтийг нэг дор хэрэглэхийг зөвшөөрдөггүй. Мөн зарим өөрчлөлтүүд нь хор хөнөөл учруулж болзошгүй тул үйлчилгээнээс эхлээд үйлдлийн систем хүртэл ямар нэг зүйлийг дахин эхлүүлэхийг шаарддаг.
- Үүнийг Ansible дээр засаж байна
- Бид үүнийг Cobbler дээр засдаг
- Логик сегмент/өгөгдлийн төв бүрийн хувьд N удаа давтана
Бүх өөрчлөлтүүд жигд явагдахын тулд олон хүчин зүйлийг харгалзан үзэх шаардлагатай байсан бөгөөд өөрчлөлтүүд байнга гардаг.
- Боломжит код, тохиргооны файлуудыг дахин засварлах
- Дотоод шилдэг туршлагыг өөрчлөх
- Осол / ослын шинжилгээний үр дүнд үндэслэн өөрчлөлт
- Дотоод болон гадаад аюулгүй байдлын стандартыг өөрчлөх. Жишээлбэл, PCI DSS нь жил бүр шинэ шаардлагаар шинэчлэгддэг
Дэд бүтцийн өсөлт, аялалын эхлэл
Сервер/логик домэйн/өгөгдлийн төвүүдийн тоо нэмэгдэж, тэдгээрийг дагаад тохиргооны алдааны тоо нэмэгдэв. Хэзээ нэгэн цагт бид тохиргооны удирдлагыг хөгжүүлэх шаардлагатай гурван чиглэлд хүрсэн:
- Автоматжуулалт. Дахин давтагдах үйл ажиллагаанд хүний алдаа гарахаас аль болох зайлсхийх хэрэгтэй.
- Дахин давтагдах чадвар. Урьдчилан таамаглах боломжтой бол дэд бүтцийг удирдах нь илүү хялбар байдаг. Серверүүдийн тохиргоо, тэдгээрийг бэлтгэх хэрэгслүүд нь хаа сайгүй ижил байх ёстой. Энэ нь бүтээгдэхүүний багуудад бас чухал ач холбогдолтой - туршилт хийсний дараа програм нь туршилтын орчинтой адил тохируулагдсан үйлдвэрлэлийн орчинд дуусах баталгаатай байх ёстой.
- Тохиргооны удирдлагад өөрчлөлт оруулах энгийн бөгөөд ил тод байдал.
Хэд хэдэн хэрэгслийг нэмэхэд л үлддэг.
Бид GitLab CE-г өөрийн кодын агуулах болгон сонгосон бөгөөд үүнд суулгасан CI/CD модулиудын хувьд ч биш.
Нууц хадгалах сан - Hashicorp Vault, incl. гайхалтай API-ийн хувьд.
Туршилтын тохиргоо ба гүйцэтгэх үүрэг – Молекул+Тестинфра. Хэрэв та боломжит митогентэй холбогдвол шинжилгээнүүд илүү хурдан явагдана. Үүний зэрэгцээ бид автоматаар байрлуулах CMDB болон найруулагчийг бичиж эхэлсэн (дээрх Cobbler дээрх зурган дээр), гэхдээ энэ нь миний хамтран зүтгэгч болон эдгээр системийн гол хөгжүүлэгч ирээдүйд хэлэх тэс өөр түүх юм.
Бидний сонголт:
Молекул + тестинфра
Ansible + Tower + AWX
Серверүүдийн ертөнц + DITNET (Өөрийн хөгжүүлэлт)
Гуталчин
Gitlab + GitLab гүйгч
Hashicorp Vault
Дашрамд хэлэхэд, боломжит дүрүүдийн тухай. Эхэндээ ганц л байсан, гэхдээ хэд хэдэн дахин боловсруулсны дараа 17 болсон. Би цул хэсгийг idempotent үүрэг болгон хуваахыг зөвлөж байна, дараа нь тусад нь ажиллуулж болно, нэмэлтээр та шошго нэмж болно. Бид үүргүүдийг функцээр нь хуваасан - сүлжээ, бүртгэл, багц, техник хангамж, молекул гэх мэт. Ерөнхийдөө бид доорх стратегийг баримталсан. Энэ бол цорын ганц үнэн гэж би шаардахгүй, гэхдээ энэ нь бидний төлөө ажилласан.
- "Алтан дүрс" -ээс серверүүдийг хуулбарлах нь муу зүйл юм!Гол сул тал нь та яг одоо зургууд ямар байдалд байгааг мэдэхгүй байгаа бөгөөд бүх өөрчлөлт нь виртуалчлалын бүх фермд байгаа бүх зурагт хийгдэх болно.
- Анхдагч тохиргооны файлуудыг хамгийн бага хэмжээнд ашиглаж, системийн үндсэн файлуудыг хариуцах бусад хэлтэстэй санал нийлнэ үүЖишээ нь:
- /etc/sysctl.conf-г хоосон орхи, тохиргоо нь зөвхөн /etc/sysctl.d/ дотор байх ёстой. Таны нэг файлд өгөгдмөл, нөгөө файл дахь аппликешнд тохируулсан.
- Системийн нэгжийг засварлахын тулд хүчингүй болгох файлуудыг ашиглана уу.
- Бүх тохиргоог загварчилж, тэдгээрийг бүхэлд нь оруулах; боломжтой бол тоглоомын номонд sed эсвэл түүний аналогийг оруулахгүй.
- Тохиргооны удирдлагын системийн кодыг дахин засварлах:
- Даалгавруудыг логик хэсгүүдэд хувааж, цул хэсгийг дүрд дахин бич
- Линтер ашигла! Ansible-lint, yaml-lint гэх мэт
- Өөрийн арга барилаа өөрчил! Муухай биш. Системийн төлөв байдлыг тайлбарлах шаардлагатай
- Бүх Ansible дүрд та молекулаар тест бичиж, өдөрт нэг удаа тайлан гаргах хэрэгтэй.
- Манай тохиолдолд тестийг бэлтгэсний дараа (түүнээс 100 гаруй байдаг) 70000 орчим алдаа илэрсэн. Үүнийг засах гэж хэдэн сар зарцуулсан.
Бидний хэрэгжилт
Тиймээс, дүрүүд бэлэн болсон, загварчлагдсан, линтерээр шалгагдсан. Тэгээд ч хаа сайгүй гитүүдийг өсгөдөг. Гэхдээ кодыг өөр өөр сегментүүдэд найдвартай хүргэх асуудал нээлттэй хэвээр байв. Бид скриптүүдтэй синхрончлохоор шийдсэн. Ийм харагдаж байна:
Өөрчлөлт ирсний дараа CI-г ажиллуулж, туршилтын сервер үүсгэн, үүрэг ролийг гаргаж, молекулаар шалгана. Хэрэв бүх зүйл хэвийн байвал код үйлдвэрлэлийн салбар руу очно. Гэхдээ бид машинд байгаа серверүүдэд шинэ код хэрэглэхгүй. Энэ бол манай системийг өндөр хүртээмжтэй байлгахад шаардлагатай нэг төрлийн бөглөө юм. Дэд бүтэц асар том болоход олон тооны хууль хэрэгжиж эхэлдэг - өөрчлөлт нь хор хөнөөлгүй гэдэгт итгэлтэй байсан ч энэ нь аймшигтай үр дагаварт хүргэж болзошгүй юм.
Мөн сервер үүсгэх олон сонголт байдаг. Бид тохируулсан Python скриптүүдийг сонгож дууслаа. Мөн 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 + Orchestrator.
- Сервер үүсгэх хугацаа нь ~30 минут, автоматжуулсан бөгөөд даалгаврын дарааллаас бараг хамааралгүй.
- Бүх сегмент дэх дэд бүтцийн ижил төлөв / нэршил - тоглоомын дэвтэр, хадгалах газар, виртуалчлалын элементүүд.
- Стандартын зөрүүтэй байдлын талаар тайлан гаргах замаар серверийн статусыг өдөр бүр шалгаж байна.
Миний түүх аялалынхаа эхэнд байгаа хүмүүст хэрэг болно гэж найдаж байна. Та ямар автоматжуулалтын стек ашигладаг вэ?
Эх сурвалж: www.habr.com