Шинэ жил ойртож байлаа. Улс даяар хүүхдүүд аль хэдийн Санта Клаус руу захидал илгээсэн эсвэл өөрсдөдөө зориулж бэлэг бэлдсэн байсан бөгөөд тэдний гол үүрэг гүйцэтгэгч, томоохон жижиглэнгийн худалдаачдын нэг нь борлуулалтын эсрэг тэмцэлд бэлтгэж байв. Арванхоёрдугаар сард түүний дата төвийн ачаалал хэд дахин нэмэгддэг. Тиймээс тус компани ашиглалтын хугацаа нь дуусч байгаа тоног төхөөрөмжийн оронд дата төвөө шинэчилж, хэдэн арван сервер шинээр ашиглалтад оруулахаар шийджээ. Энэ нь эргэлдэж буй цасан ширхгүүдийн дэвсгэр дээр үлгэр дуусч, триллер эхэлнэ.

Тоног төхөөрөмж борлуулалтын оргил үе болохоос хэдэн сарын өмнө сайтад ирсэн. Үйл ажиллагааны үйлчилгээ нь мэдээжийн хэрэг серверүүдийг үйлдвэрлэлийн орчинд оруулахын тулд хэрхэн, юуг тохируулахаа мэддэг. Гэхдээ үүнийг автоматжуулж, хүний ​​хүчин зүйлийг арилгах хэрэгтэй байсан. Нэмж дурдахад компанийн хувьд чухал ач холбогдолтой SAP системийг шилжүүлэхээс өмнө серверүүдийг сольсон.

Шинэ серверүүдийг ашиглалтад оруулах нь эцсийн хугацаатай хатуу холбоотой байв. Үүнийг шилжүүлэх нь тэрбум бэлэг тээвэрлэх, системийн шилжилт хөдөлгөөнд аюул учруулах гэсэн үг юм. Эцэг Фрост, Санта Клаус нараас бүрдсэн баг хүртэл огноог өөрчилж чадаагүй - та SAP системийг жилд нэг удаа агуулахын менежментэд шилжүүлэх боломжтой. 31-р сарын 1-ээс 20-р сарын 15 хүртэл жижиглэнгийн худалдааны томоохон агуулахууд, нийтдээ XNUMX хөлбөмбөгийн талбай XNUMX цагийн турш ажлаа зогсоодог. Энэ бол системийг шилжүүлэх цорын ганц хугацаа юм. Бид серверүүдийг нэвтрүүлэхэд алдаа гаргах зай байсангүй.

Би тодорхой хэлье: миний түүх манай багийн ашигладаг хэрэгсэл, тохиргооны удирдлагын үйл явцыг тусгасан болно.

Тохиргооны удирдлагын цогцолбор нь хэд хэдэн түвшнээс бүрдэнэ. Гол бүрэлдэхүүн хэсэг нь CMS систем юм. Аж үйлдвэрийн үйл ажиллагаанд аль нэг түвшин байхгүй байх нь зайлшгүй тааламжгүй гайхамшгийг дагуулна.

OS суулгах менежмент

Эхний түвшин нь физик болон виртуал сервер дээр үйлдлийн систем суурилуулах ажлыг удирдах систем юм. Энэ нь хүний ​​хүчин зүйлийг арилгах үндсэн үйлдлийн системийн тохиргоог бий болгодог.

Энэ системийг ашиглан бид цаашдын автоматжуулалтад тохиромжтой үйлдлийн системтэй стандарт серверийн жишээг хүлээн авсан. "Цутгах" явцад тэд хамгийн бага хэмжээний локал хэрэглэгчид болон нийтийн SSH түлхүүрүүдийг, түүнчлэн үйлдлийн системийн тогтвортой тохиргоог хүлээн авсан. Бид CMS-ээр дамжуулан серверүүдийг удирдах баталгаатай байсан бөгөөд үйлдлийн системийн түвшинд "доор" гэнэтийн зүйл байхгүй гэдэгт итгэлтэй байсан.

Суулгацын удирдлагын системийн "хамгийн их" ажил нь серверүүдийг BIOS/Firmware-ийн түвшнээс OS хүртэл автоматаар тохируулах явдал юм. Энд ихэнх зүйл нь тоног төхөөрөмж, тохируулгын даалгавраас хамаарна. Нэг төрлийн бус тоног төхөөрөмжийн хувьд та авч үзэж болно REDFISH API. Хэрэв бүх техник хангамжийг нэг үйлдвэрлэгчээс авсан бол бэлэн удирдлагын хэрэгслийг (жишээлбэл, HP ILO өсгөгч, DELL OpenManage гэх мэт) ашиглах нь илүү тохиромжтой байдаг.

Үйлдлийн системийг физик сервер дээр суулгахын тулд бид үйлдлийн үйлчилгээтэй тохиролцсон суулгах профайлын багцыг тодорхойлдог алдартай Cobbler-ийг ашигласан. Дэд бүтцэд шинэ сервер нэмэх үед инженер Cobbler-д серверийн MAC хаягийг шаардлагатай профайлтай холбосон. Сүлжээгээр анх удаа ачаалах үед сервер түр зуурын хаяг болон шинэ үйлдлийн системийг хүлээн авсан. Дараа нь үүнийг зорилтот VLAN/IP хаяглалт руу шилжүүлж, тэнд үргэлжлүүлэн ажиллав. Тиймээ, VLAN-г өөрчлөхөд цаг хугацаа шаардагдах бөгөөд зохицуулалт шаардлагатай боловч энэ нь серверийг үйлдвэрлэлийн орчинд санамсаргүй суулгахаас нэмэлт хамгаалалт болдог.

Бид HashiСorp Packer ашиглан бэлтгэсэн загварууд дээр үндэслэн виртуал серверүүдийг үүсгэсэн. Шалтгаан нь ижил байсан: үйлдлийн системийг суулгах үед хүний ​​​​болзошгүй алдаанаас урьдчилан сэргийлэх. Гэхдээ физик серверүүдээс ялгаатай нь Пакер нь PXE, сүлжээ ачаалах, VLAN-г өөрчлөх хэрэгцээг арилгадаг. Энэ нь виртуал сервер үүсгэхэд хялбар, хялбар болгосон.

Цагаан будаа. 1. Үйлдлийн систем суурилуулах ажлыг удирдах.

Нууцыг удирдах

Аливаа тохиргооны удирдлагын систем нь энгийн хэрэглэгчдээс нуугдах ёстой боловч системийг бэлтгэхэд шаардлагатай өгөгдлийг агуулдаг. Эдгээр нь орон нутгийн хэрэглэгчид болон үйлчилгээний дансны нууц үг, гэрчилгээний түлхүүр, төрөл бүрийн API токен гэх мэт. Тэдгээрийг ихэвчлэн "нууц" гэж нэрлэдэг.

Хэрэв та эдгээр нууцыг хаана, хэрхэн хадгалахаа эхнээс нь тодорхойлоогүй бол мэдээллийн аюулгүй байдлын шаардлагуудаас хамааран дараах хадгалалтын аргууд байж болно.

• тохиргооны хяналтын код эсвэл репозитор дахь файлуудад шууд;
• тусгай тохиргооны удирдлагын хэрэгсэлд (жишээлбэл, Ansible Vault);
• CI/CD системд (Jenkins/TeamCity/GitLab/гэх мэт) эсвэл тохиргооны удирдлагын системд (Ansible Tower/Ansible AWX);
• Нууцыг мөн "гараар" шилжүүлж болно. Жишээлбэл, тэдгээрийг тодорхой газар байрлуулж, дараа нь тохиргооны удирдлагын системд ашигладаг;
• дээр дурдсан янз бүрийн хослолууд.

Арга бүр өөрийн гэсэн сул талуудтай. Хамгийн гол нь нууцад нэвтрэх бодлого дутмаг: тодорхой нууцыг хэн ашиглаж болохыг тодорхойлох боломжгүй эсвэл хэцүү байдаг. Өөр нэг сул тал бол хандалтын аудит байхгүй, амьдралын бүрэн мөчлөг юм. Жишээлбэл, код болон холбогдох хэд хэдэн системд бичигдсэн нийтийн түлхүүрийг хэрхэн хурдан солих вэ?

Бид HashiCorp Vault төвлөрсөн нууц хадгалах санг ашигласан. Энэ нь бидэнд зөвшөөрсөн:

• нууцыг аюулгүй байлгах. Тэдгээр нь шифрлэгдсэн бөгөөд хэн нэгэн нь Vault мэдээллийн санд хандсан ч гэсэн (жишээлбэл, нөөцлөлтөөс сэргээх замаар) тэнд хадгалагдсан нууцыг унших боломжгүй болно;
• нууцад нэвтрэх бодлогыг зохион байгуулах. Зөвхөн тэдэнд "хуваарилагдсан" нууцыг хэрэглэгчид болон програмуудад ашиглах боломжтой;
• нууцад нэвтрэх аудит. Нууц бүхий аливаа үйлдлийг Vault аудитын бүртгэлд бүртгэдэг;
• нууцтай ажиллах бүрэн хэмжээний "амьдралын мөчлөг" -ийг зохион байгуулах. Тэдгээрийг үүсгэх, хүчингүй болгох, дуусах хугацааг тохируулах гэх мэт.
• нууцад нэвтрэх шаардлагатай бусад системтэй нэгтгэхэд хялбар;
• Мөн төгсгөл хоорондын шифрлэлт, үйлдлийн систем болон мэдээллийн санд зориулсан нэг удаагийн нууц үг, эрх бүхий төвүүдийн гэрчилгээ гэх мэтийг ашиглана.

Одоо төвлөрсөн баталгаажуулалт, зөвшөөрлийн систем рүү шилжье. Үүнгүйгээр хийх боломжтой байсан ч холбогдох олон системд хэрэглэгчдийг удирдах нь хэтэрхий энгийн зүйл биш юм. Бид LDAP үйлчилгээгээр дамжуулан баталгаажуулалт болон зөвшөөрлийг тохируулсан. Үгүй бол Vault хэрэглэгчдэд таниулах жетоныг тасралтгүй гаргаж, хянах шаардлагатай болно. Мөн хэрэглэгчдийг устгах, нэмэх нь "би энэ хэрэглэгчийн бүртгэлийг хаа сайгүй үүсгэсэн/устгсан уу?" гэсэн даалгавар болж хувирна.

Бид системдээ өөр нэг түвшинг нэмж өгдөг: нууцын удирдлага, төвлөрсөн баталгаажуулалт/зөвшөөрөл:

Цагаан будаа. 2. Нууц менежмент.

Тохиргооны удирдлага

Бид гол цөмд хүрсэн - CMS систем. Манай тохиолдолд энэ нь Ansible болон Red Hat Ansible AWX-ийн хослол юм.

Ansible-ийн оронд Chef, Puppet, SaltStack ашиглаж болно. Бид хэд хэдэн шалгуурыг үндэслэн Ansible-г сонгосон.

• Нэгдүгээрт, энэ нь олон талт байдал юм. Удирдлагын хувьд бэлэн модулиудын багц энэ нь гайхалтай юм. Хэрэв танд хангалттай зүйл байхгүй бол GitHub болон Galaxy дээр хайлт хийх боломжтой.
• Хоёрдугаарт, удирдлагатай тоног төхөөрөмж дээр агент суурилуулах, дэмжих, ачаалалд саад болохгүй гэдгийг нотлох, "хавчуурга" байхгүй гэдгийг батлах шаардлагагүй.
• Гуравдугаарт, Ansible-д ороход саад багатай. Чадварлаг инженер бүтээгдэхүүнтэй ажиллах эхний өдөр шууд утгаараа ажлын дэвтэр бичнэ.

Гэвч үйлдвэрлэлийн орчинд зөвхөн Ansible бидэнд хангалтгүй байсан. Тэгэхгүй бол хандалтыг хязгаарлах, админуудын үйлдлийг шалгах зэрэг олон асуудал үүснэ. Хандалтыг хэрхэн хязгаарлах вэ? Эцсийн эцэст хэлтэс бүр "өөрийн" серверүүдийг удирдах (унш: Ansible тоглоомын номыг ажиллуулах) шаардлагатай байсан. Зөвхөн тодорхой ажилчдад тодорхой Ansible тоглоомын ном ажиллуулахыг хэрхэн зөвшөөрөх вэ? Эсвэл Ansible ажиллуулж байгаа сервер, тоног төхөөрөмж дээр орон нутгийн мэдлэгийг тохируулалгүйгээр тоглоомын номыг хэн ажиллуулсныг хэрхэн хянах вэ?

Иймэрхүү асуудлын арслангийн хувийг Red Hat шийддэг Ansible Tower, эсвэл түүний нээлттэй эх сурвалжийн upstream төсөл Ansible AWX. Тийм учраас бид үйлчлүүлэгчдээ илүүд үзсэн.

Мөн манай CMS системийн хөрөг дээр дахин нэг мэдрэгчтэй. Ansible тоглоомын номыг кодын хадгалах удирдлагын системд хадгалах ёстой. Бидэнд байгаа GitLab CE.

Тиймээс тохиргоог өөрсдөө Ansible/Ansible AWX/GitLab-ийн хослолоор удирддаг (3-р зургийг үз). Мэдээжийн хэрэг, AWX/GitLab нь нэг баталгаажуулалтын системтэй, Ansible playbook нь HashiCorp Vault-тай нэгдсэн. Тохиргоонууд нь үйлдвэрлэлийн орчинд зөвхөн Ansible AWX-ээр дамжин ордог бөгөөд үүнд бүх "тоглоомын дүрэм"-ийг зааж өгсөн болно: хэн юуг тохируулах, CMS-ийн тохиргооны удирдлагын кодыг хаанаас авах гэх мэт.

Цагаан будаа. 3. Тохиргооны удирдлага.

Туршилтын менежмент

Бидний тохиргоог код хэлбэрээр үзүүлэв. Тиймээс бид програм хангамж хөгжүүлэгчидтэй адилхан дүрмээр тоглохоос өөр аргагүй болдог. Бид үйлдвэрлэлийн серверүүдэд тохиргооны кодыг боловсруулах, тасралтгүй турших, хүргэх, ашиглах үйл явцыг зохион байгуулах шаардлагатай байв.

Хэрэв үүнийг нэн даруй хийхгүй бол тохиргоонд зориулж бичсэн дүрүүд дэмжигдэхээ больж, өөрчлөх эсвэл үйлдвэрлэлд гарахаа болино. Энэ өвдөлтийг эмчлэх арга нь мэдэгдэж байгаа бөгөөд энэ төсөлд өөрийгөө нотолсон.

• үүрэг тус бүрийг нэгжийн туршилтанд хамруулсан;
• тохиргоог удирдаж буй кодонд ямар нэгэн өөрчлөлт гарсан тохиолдолд тестийг автоматаар ажиллуулдаг;
• тохиргооны удирдлагын кодын өөрчлөлтүүд нь бүх туршилт, кодын шалгалтыг амжилттай давсаны дараа л үйлдвэрлэлийн орчинд гарна.

Код боловсруулах болон тохиргооны удирдлага илүү тайван, урьдчилан таамаглах боломжтой болсон. Тасралтгүй туршилтыг зохион байгуулахын тулд бид GitLab CI/CD хэрэгслийг ашиглаж, авсан Ашигтай молекул.

Тохиргооны удирдлагын кодонд өөрчлөлт орох бүрд GitLab CI/CD нь молекулыг дууддаг:

• кодын синтаксийг шалгадаг,
• Docker савыг дээш өргөх,
• өөрчилсөн кодыг үүсгэсэн саванд хэрэглэх,
• үүрэг хариуцлагын чадваргүй эсэхийг шалгаж, энэ кодын тестийг ажиллуулдаг (энд тодорхой дүрийн түвшинд байна, Зураг 4-ийг үзнэ үү).

Бид Ansible AWX ашиглан тохиргоог үйлдвэрлэлийн орчинд хүргэсэн. Үйл ажиллагааны инженерүүд урьдчилан тодорхойлсон загваруудаар дамжуулан тохиргооны өөрчлөлтийг ашигласан. AWX нь GitLab мастер салбараас кодын хамгийн сүүлийн хувилбарыг ашиглах бүртээ бие даан "хүссэн". Ингэснээр бид үйлдвэрлэлийн орчинд туршиж үзээгүй эсвэл хуучирсан код ашиглахыг хассан. Мэдээжийн хэрэг, кодыг туршиж, хянаж, баталгаажуулсны дараа л мастер салбар руу орсон.

Цагаан будаа. 4. GitLab CI/CD дээрх үүргүүдийг автоматаар шалгах.

Үйлдвэрлэлийн системийн ажиллагаатай холбоотой асуудал бас бий. Бодит амьдрал дээр зөвхөн CMS кодоор тохиргооны өөрчлөлт хийх нь маш хэцүү байдаг. Код засварлах, турших, батлах гэх мэтийг хүлээхгүйгээр инженер "энд, одоо" тохиргоог өөрчлөх шаардлагатай үед онцгой нөхцөл байдал үүсдэг.

Үүний үр дүнд гарын авлагын өөрчлөлтийн улмаас ижил төрлийн тоног төхөөрөмжийн тохиргоонд зөрүү гарч ирдэг (жишээлбэл, sysctl тохиргоог HA кластерийн зангилаанууд дээр өөрөөр тохируулсан). Эсвэл төхөөрөмж дээрх бодит тохиргоо нь CMS кодонд заасан тохиргооноос ялгаатай байна.

Тиймээс бид тасралтгүй туршилтаас гадна үйлдвэрлэлийн орчны тохиргооны зөрүүг шалгадаг. Бид хамгийн энгийн сонголтыг сонгосон: CMS тохиргооны кодыг "хуурай ажиллуулах" горимд ажиллуулах, өөрөөр хэлбэл өөрчлөлт оруулахгүйгээр, гэхдээ төлөвлөсөн болон бодит тохиргооны хоорондох бүх зөрүүг мэдэгдэнэ. Бид үүнийг үйлдвэрлэлийн серверүүд дээр "-check" сонголттой бүх Ansible тоглоомын номыг үе үе ажиллуулж хэрэгжүүлсэн. Ердийнх шигээ Ansible AWX нь тоглоомын номыг эхлүүлэх, шинэчлэх үүрэгтэй (5-р зургийг үз):

Цагаан будаа. 5. Ansible AWX-ийн тохиргооны зөрүүг шалгана.

Шалгасны дараа AWX администраторуудад зөрчлийн тайланг илгээдэг. Тэд асуудалтай тохиргоог судалж, дараа нь тохируулсан тоглоомын номоор дамжуулан засдаг. Ийм байдлаар бид үйлдвэрлэлийн орчинд тохиргоогоо хадгалдаг бөгөөд CMS нь үргэлж шинэчлэгдэж, синхрончлогдсон байдаг. Энэ нь "үйлдвэрлэлийн" сервер дээр CMS кодыг ашиглах үед тааламжгүй "гайхамшгийг" арилгадаг.

Бид одоо Ansible AWX/GitLab/Molecule-ээс бүрдэх чухал туршилтын давхаргатай боллоо (Зураг 6).

Цагаан будаа. 6. Туршилтын менежмент.

Хэцүү үү? Би маргахгүй. Гэхдээ тохиргооны удирдлагын ийм цогцолбор нь серверийн тохиргоог автоматжуулахтай холбоотой олон асуултын цогц хариулт болсон юм. Одоо жижиглэнгийн худалдааны стандарт серверүүд нь үргэлж хатуу тодорхойлсон тохиргоотой байдаг. CMS нь инженерээс ялгаатай нь шаардлагатай тохиргоог нэмж, хэрэглэгчдийг үүсгэж, хэдэн арван эсвэл хэдэн зуун шаардлагатай тохиргоог хийхээ мартдаггүй.

Өнөөдөр сервер, орчны тохиргоонд "нууц мэдлэг" гэж байдаггүй. Шаардлагатай бүх шинж чанаруудыг тоглоомын дэвтэрт тусгасан болно. Бүтээлч байдал, тодорхой бус заавар байхгүй: "Энгийн Oracle шиг суулгаарай, гэхдээ та хэд хэдэн sysctl тохиргоог зааж, шаардлагатай UID-тэй хэрэглэгчдийг нэмэх хэрэгтэй. Ажиллаж байгаа залуусаас асуу, тэд мэднэ".

Тохиргооны зөрүүг илрүүлэх, тэдгээрийг идэвхтэйгээр засах чадвар нь сэтгэлийн амар амгаланг өгдөг. Тохиргооны удирдлагын системгүй бол энэ нь ихэвчлэн өөр харагддаг. Асуудал нэг л өдөр үйлдвэрлэл рүү “буудаж” хүртлээ хуримтлагддаг. Дараа нь дүгнэлт хийж, тохиргоог шалгаж, залруулна. Мөн мөчлөг дахин давтагдана

Мэдээжийн хэрэг, бид серверүүдийг ажиллуулах ажлыг хэдэн өдрөөс хэдэн цаг хүртэл хурдасгасан.

Шинэ жилийн баяраар хүүхдүүд баяр хөөртэйгөөр бэлэг задлан, томчууд хонх дуугарах үед хүслээ илэрхийлж байх үед манай инженерүүд SAP системийг шинэ серверүүд рүү шилжүүлсэн. Санта Клаус хүртэл сайн бэлтгэгдсэн гайхамшиг бол хамгийн сайн гайхамшгууд гэж хэлэх болно.

Жич: Үйлчлүүлэгчид тохиргооны менежментийн асуудлыг аль болох энгийн байдлаар шийдвэрлэхийг хүсдэгтэй манай баг байнга тулгардаг. Хамгийн тохиромжтой нь ид шид мэт - нэг хэрэгслээр. Гэхдээ амьдралд бүх зүйл илүү төвөгтэй байдаг (тиймээ, мөнгөн сум дахин ирээгүй): та үйлчлүүлэгчийн багт тохиромжтой хэрэгслийг ашиглан бүхэл бүтэн үйл явцыг бий болгох хэрэгтэй.

Зохиогч: Сергей Артемов, хэлтсийн архитектор DevOps шийдлүүд "Jet Infosystems"

Эх сурвалж: www.habr.com