ពី "ការចាប់ផ្តើម" ទៅម៉ាស៊ីនមេរាប់ពាន់នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យរាប់សិប។ របៀបដែលយើងដេញតាមកំណើននៃហេដ្ឋារចនាសម្ព័ន្ធលីនុច

ប្រសិនបើហេដ្ឋារចនាសម្ព័ន្ធ IT របស់អ្នករីកចម្រើនលឿនពេក អ្នកនឹងត្រូវប្រឈមមុខនឹងជម្រើសមួយ៖ បង្កើនធនធានមនុស្សជាជួរដើម្បីគាំទ្រវា ឬចាប់ផ្តើមស្វ័យប្រវត្តិកម្ម។ រហូតមកដល់ចំណុចខ្លះ យើងបានរស់នៅក្នុងគំរូទីមួយ ហើយបន្ទាប់មកផ្លូវដ៏វែងឆ្ងាយទៅកាន់ Infrastructure-as-Code បានចាប់ផ្តើម។

ជាការពិតណាស់ NSPK មិនមែនជាការចាប់ផ្តើមទេ ប៉ុន្តែបរិយាកាសបែបនេះបានគ្រប់គ្រងក្រុមហ៊ុននៅក្នុងឆ្នាំដំបូងនៃអត្ថិភាពរបស់វា ហើយទាំងនោះគឺជាឆ្នាំដែលគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់។ ឈ្មោះ​របស់ខ្ញុំ​គឺ Kornyakov Dmitryខ្ញុំបាននិងកំពុងគាំទ្រហេដ្ឋារចនាសម្ព័ន្ធលីនុចជាមួយនឹងតម្រូវការភាពអាចរកបានខ្ពស់អស់រយៈពេលជាង 10 ឆ្នាំមកហើយ។ គាត់បានចូលរួមជាមួយក្រុម NSPK ក្នុងខែមករា ឆ្នាំ 2016 ហើយជាអកុសល មិនបានឃើញការចាប់ផ្តើមដំបូងនៃអត្ថិភាពរបស់ក្រុមហ៊ុននោះទេ ប៉ុន្តែបានមកដល់ដំណាក់កាលនៃការផ្លាស់ប្តូរដ៏អស្ចារ្យ។

ជាទូទៅយើងអាចនិយាយបានថាក្រុមរបស់យើងផ្គត់ផ្គង់ផលិតផលចំនួន 2 សម្រាប់ក្រុមហ៊ុន។ ទីមួយគឺហេដ្ឋារចនាសម្ព័ន្ធ។ សំបុត្រគួរតែដំណើរការ DNS គួរតែដំណើរការ ហើយឧបករណ៍បញ្ជាដែនគួរតែអនុញ្ញាតឱ្យអ្នកចូលទៅក្នុងម៉ាស៊ីនមេដែលមិនគួរគាំង។ ទិដ្ឋភាព IT របស់ក្រុមហ៊ុនគឺធំធេងណាស់! ទាំងនេះគឺជាប្រព័ន្ធសំខាន់នៃអាជីវកម្ម និងបេសកកម្ម តម្រូវការសម្រាប់ភាពអាចរកបានសម្រាប់មួយចំនួនគឺ 99,999 ។ ផលិតផលទីពីរគឺម៉ាស៊ីនមេដោយខ្លួនឯង រូបវន្ត និងនិម្មិត។ វត្ថុដែលមានស្រាប់ត្រូវតែត្រូវបានត្រួតពិនិត្យ ហើយថ្មីត្រូវតែត្រូវបានចែកចាយជាទៀងទាត់ទៅកាន់អតិថិជនពីនាយកដ្ឋានជាច្រើន។ នៅក្នុងអត្ថបទនេះខ្ញុំចង់ផ្តោតលើរបៀបដែលយើងបង្កើតហេដ្ឋារចនាសម្ព័ន្ធដែលទទួលខុសត្រូវចំពោះវដ្តជីវិតរបស់ម៉ាស៊ីនមេ។

ការចាប់ផ្តើមនៃផ្លូវ

នៅដើមដំបូងនៃការធ្វើដំណើររបស់យើង ជង់បច្ចេកវិទ្យារបស់យើងមើលទៅដូចនេះ៖
ប្រព័ន្ធប្រតិបត្តិការ CentOS 7
FreeIPA Domain Controllers
ស្វ័យប្រវត្តិកម្ម - Ansible(+Tower), Cobbler

ទាំងអស់នេះមានទីតាំងនៅ 3 domains ដែលរីករាលដាលនៅទូទាំងមជ្ឈមណ្ឌលទិន្នន័យជាច្រើន។ នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមួយមានប្រព័ន្ធការិយាល័យ និងកន្លែងសាកល្បង ហើយនៅសល់មាន PROD ។

ការបង្កើតម៉ាស៊ីនមេនៅចំណុចមួយមើលទៅដូចនេះ៖

នៅក្នុងគំរូ VM CentOS គឺតិចតួចបំផុត ហើយអប្បបរមាដែលត្រូវការគឺដូចជា /etc/resolv.conf ត្រឹមត្រូវ ហើយនៅសល់មកតាមរយៈ Ansible ។

CMDB - Excel ។

ប្រសិនបើម៉ាស៊ីនមេមានលក្ខណៈរូបវន្ត នោះជំនួសឱ្យការចម្លងម៉ាស៊ីននិម្មិត ប្រព័ន្ធប្រតិបត្តិការត្រូវបានដំឡើងនៅលើវាដោយប្រើ Cobbler - អាសយដ្ឋាន MAC របស់ម៉ាស៊ីនមេគោលដៅត្រូវបានបន្ថែមទៅការកំណត់រចនាសម្ព័ន្ធ Cobbler ម៉ាស៊ីនមេទទួលបានអាសយដ្ឋាន IP តាមរយៈ DHCP ហើយបន្ទាប់មកប្រព័ន្ធប្រតិបត្តិការ ត្រូវបានបន្ថែម។

ដំបូងឡើយ យើងថែមទាំងព្យាយាមធ្វើការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធមួយចំនួននៅក្នុង Cobbler ។ ប៉ុន្តែយូរ ៗ ទៅនេះបានចាប់ផ្តើមនាំមកនូវបញ្ហាជាមួយនឹងការចល័តនៃការកំណត់រចនាសម្ព័ន្ធទាំងទៅមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀតនិងលេខកូដ Ansible សម្រាប់ការរៀបចំ VMs ។

នៅពេលនោះ ពួកយើងជាច្រើនបានយល់ថា Ansible ជាផ្នែកបន្ថែមដ៏ងាយស្រួលនៃ Bash ហើយមិនបានរំលងការរចនាដោយប្រើសែល និង sed ទេ។ Bashsible សរុប។ នេះនៅទីបំផុតនាំឱ្យការពិតដែលថាប្រសិនបើសៀវភៅលេងសម្រាប់ហេតុផលមួយចំនួនមិនដំណើរការលើម៉ាស៊ីនមេ វាកាន់តែងាយស្រួលក្នុងការលុបម៉ាស៊ីនមេ ជួសជុលសៀវភៅលេង ហើយដំណើរការវាម្តងទៀត។ សំខាន់មិនមានកំណែស្គ្រីប គ្មានការកំណត់រចនាសម្ព័ន្ធចល័តទេ។

ឧទាហរណ៍ យើងចង់ផ្លាស់ប្តូរការកំណត់មួយចំនួននៅលើម៉ាស៊ីនមេទាំងអស់៖

1. យើងផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធនៅលើម៉ាស៊ីនមេដែលមានស្រាប់នៅក្នុងផ្នែកឡូជីខល/មជ្ឈមណ្ឌលទិន្នន័យ។ ពេលខ្លះមិនមែនក្នុងមួយថ្ងៃទេ - តម្រូវការភាពងាយស្រួល និងច្បាប់នៃចំនួនច្រើនមិនអនុញ្ញាតឱ្យការផ្លាស់ប្តូរទាំងអស់ត្រូវបានអនុវត្តក្នុងពេលតែមួយនោះទេ។ ហើយការផ្លាស់ប្តូរមួយចំនួនមានសក្តានុពលបំផ្លិចបំផ្លាញ ហើយទាមទារឱ្យចាប់ផ្តើមអ្វីមួយឡើងវិញ - ពីសេវាកម្មទៅ OS ខ្លួនវាផ្ទាល់។
2. ជួសជុលវានៅក្នុង Ansible
3. យើងជួសជុលវានៅក្នុង Cobbler
4. ធ្វើម្តងទៀត N ដងសម្រាប់ផ្នែកឡូជីខល / មជ្ឈមណ្ឌលទិន្នន័យនីមួយៗ

ដើម្បីឱ្យការផ្លាស់ប្តូរទាំងអស់ដំណើរការទៅដោយរលូន ចាំបាច់ត្រូវគិតគូរពីកត្តាជាច្រើន ហើយការផ្លាស់ប្តូរកើតឡើងឥតឈប់ឈរ។

• ការ​កែ​សម្រួល​កូដ​ដែល​អាច​ប្រើ​បាន ឯកសារ​កំណត់​រចនាសម្ព័ន្ធ
• ការផ្លាស់ប្តូរការអនុវត្តល្អបំផុតផ្ទៃក្នុង
• ការផ្លាស់ប្តូរដោយផ្អែកលើលទ្ធផលនៃការវិភាគឧប្បត្តិហេតុ / គ្រោះថ្នាក់
• ការផ្លាស់ប្តូរស្តង់ដារសុវត្ថិភាពទាំងខាងក្នុង និងខាងក្រៅ។ ឧទាហរណ៍ PCI DSS ត្រូវបានធ្វើបច្ចុប្បន្នភាពជាមួយនឹងតម្រូវការថ្មីជារៀងរាល់ឆ្នាំ

កំណើនហេដ្ឋារចនាសម្ព័ន្ធ និងការចាប់ផ្តើមនៃការធ្វើដំណើរ

ចំនួនម៉ាស៊ីនមេ/ដែនឡូជីខល/មជ្ឈមណ្ឌលទិន្នន័យបានកើនឡើង ហើយជាមួយនឹងពួកគេចំនួននៃកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធ។ នៅចំណុចខ្លះ យើងបានមកដល់ទិសដៅបី ដែលការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធចាំបាច់ត្រូវបង្កើត៖

1. ស្វ័យប្រវត្តិកម្ម។ កំហុសរបស់មនុស្សក្នុងប្រតិបត្តិការដដែលៗគួរតែត្រូវបានជៀសវាងតាមដែលអាចធ្វើទៅបាន។
2. ភាពអាចធ្វើម្តងទៀត។ វាកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ នៅពេលដែលវាអាចព្យាករណ៍បាន។ ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ និងឧបករណ៍សម្រាប់ការរៀបចំរបស់ពួកគេគួរតែដូចគ្នានៅគ្រប់ទីកន្លែង។ នេះក៏សំខាន់ផងដែរសម្រាប់ក្រុមផលិតផល - បន្ទាប់ពីការធ្វើតេស្ត កម្មវិធីត្រូវតែត្រូវបានធានាថានឹងបញ្ចប់នៅក្នុងបរិយាកាសផលិតកម្មដែលបានកំណត់រចនាសម្ព័ន្ធស្រដៀងគ្នាទៅនឹងបរិយាកាសសាកល្បង។
3. ភាពសាមញ្ញ និងតម្លាភាពនៃការផ្លាស់ប្តូរការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ។

វានៅសល់ដើម្បីបន្ថែមឧបករណ៍ពីរបី។

យើងបានជ្រើសរើស GitLab CE ជាឃ្លាំងកូដរបស់យើង យ៉ាងហោចណាស់សម្រាប់ម៉ូឌុល CI/CD ដែលភ្ជាប់មកជាមួយរបស់វា។

តុដេកនៃអាថ៌កំបាំង - Hashicorp Vault, រួមទាំង។ សម្រាប់ API ដ៏អស្ចារ្យ។

ការធ្វើតេស្តការកំណត់រចនាសម្ព័ន្ធ និងតួនាទីដែលអាចមានបាន - ម៉ូលេគុល + តេស្តិនហ្វ្រា។ ការធ្វើតេស្តដំណើរការលឿនជាងប្រសិនបើអ្នកភ្ជាប់ទៅ ansible mitogen ។ ក្នុងពេលជាមួយគ្នានេះ យើងបានចាប់ផ្តើមសរសេរ CMDB និងអ្នករៀបចំកម្មវិធីផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ការដាក់ពង្រាយដោយស្វ័យប្រវត្តិ (ក្នុងរូបភាពខាងលើ Cobbler) ប៉ុន្តែនេះគឺជារឿងខុសគ្នាទាំងស្រុង ដែលសហសេវិករបស់ខ្ញុំនិងអ្នកអភិវឌ្ឍន៍សំខាន់នៃប្រព័ន្ធទាំងនេះនឹងប្រាប់នៅពេលអនាគត។

ជម្រើសរបស់យើង៖

ម៉ូលេគុល + តេស្តិនហ្វ្រា
Ansible + Tower + AWX
ពិភពនៃម៉ាស៊ីនមេ + DITNET (ការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួន)
ក្រុម Northampton
អ្នករត់ Gitlab + GitLab
តុដេក Hashicorp

ដោយវិធីនេះអំពីតួនាទី ansible ។ ដំបូងមានតែមួយប៉ុណ្ណោះ ប៉ុន្តែបន្ទាប់ពីការកែលម្អជាច្រើនដង មាន 17 ក្នុងចំណោមពួកវា។ ខ្ញុំសូមផ្តល់អនុសាសន៍យ៉ាងខ្លាំងឱ្យបំបែក monolith ទៅជាតួនាទី idempotent ដែលបន្ទាប់មកអាចត្រូវបានចាប់ផ្តើមដោយឡែកពីគ្នា លើសពីនេះទៀតអ្នកអាចបន្ថែមស្លាក។ យើងបានបែងចែកតួនាទីដោយមុខងារ - បណ្តាញ, កំណត់ហេតុ, កញ្ចប់, ផ្នែករឹង, ម៉ូលេគុលជាដើម។ ជាទូទៅ យើងធ្វើតាមយុទ្ធសាស្ត្រខាងក្រោម។ ខ្ញុំ​មិន​ទទូច​ថា​នេះ​គឺ​ជា​ការ​ពិត​តែ​មួយ​គត់​, ប៉ុន្តែ​វា​បាន​ធ្វើ​ការ​សម្រាប់​យើង​។

• ការចម្លងម៉ាស៊ីនមេពី "រូបភាពមាស" គឺអាក្រក់!គុណវិបត្តិចម្បងនោះគឺថាអ្នកមិនដឹងច្បាស់ថារូបភាពស្ថិតនៅក្នុងស្ថានភាពបែបណាទេ ហើយការផ្លាស់ប្តូរទាំងអស់នឹងកើតមានចំពោះរូបភាពទាំងអស់នៅក្នុងកសិដ្ឋាននិម្មិតទាំងអស់។
• ប្រើឯកសារកំណត់រចនាសម្ព័ន្ធលំនាំដើមឱ្យតិចបំផុត ហើយយល់ព្រមជាមួយនាយកដ្ឋានផ្សេងទៀតដែលអ្នកទទួលខុសត្រូវចំពោះឯកសារប្រព័ន្ធសំខាន់ៗឧទាហរណ៍:
  1. ទុកឱ្យ /etc/sysctl.conf ទទេ ការកំណត់គួរតែនៅក្នុង /etc/sysctl.d/ ប៉ុណ្ណោះ។ លំនាំដើមរបស់អ្នកនៅក្នុងឯកសារមួយ ផ្ទាល់ខ្លួនសម្រាប់កម្មវិធីនៅក្នុងមួយផ្សេងទៀត។
  2. ប្រើឯកសារបដិសេធដើម្បីកែសម្រួលឯកតាប្រព័ន្ធ។
• គំរូការកំណត់រចនាសម្ព័ន្ធទាំងអស់ និងរួមបញ្ចូលពួកវាទាំងស្រុង ប្រសិនបើអាចធ្វើបាន គ្មាន sed ឬ analogues របស់វានៅក្នុងសៀវភៅលេងទេ
• ការកែប្រែកូដប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធឡើងវិញ៖
  1. បំបែកភារកិច្ចទៅជាអង្គភាពឡូជីខល ហើយសរសេរឡើងវិញនូវ monolith ទៅជាតួនាទី
  2. ប្រើឡេ! Ansible-lint, yaml-lint, ល។
  3. ផ្លាស់ប្តូរវិធីសាស្រ្តរបស់អ្នក! គ្មានការប្រមាថ។ វាចាំបាច់ក្នុងការពិពណ៌នាអំពីស្ថានភាពនៃប្រព័ន្ធ
• សម្រាប់តួនាទី Ansible ទាំងអស់ អ្នកត្រូវសរសេរការធ្វើតេស្តនៅក្នុងម៉ូលេគុល និងបង្កើតរបាយការណ៍ម្តងក្នុងមួយថ្ងៃ។
• ក្នុងករណីរបស់យើងបន្ទាប់ពីរៀបចំការធ្វើតេស្ត (ដែលមានច្រើនជាង 100) ប្រហែល 70000 កំហុសត្រូវបានរកឃើញ។ វាត្រូវចំណាយពេលជាច្រើនខែដើម្បីជួសជុលវា។

ការអនុវត្តរបស់យើង។

ដូច្នេះ តួនាទី ANSI បានត្រៀមរួចរាល់ គំរូ និងពិនិត្យដោយ linters ។ ហើយសូម្បីតែ gits ត្រូវបានលើកឡើងនៅគ្រប់ទីកន្លែង។ ប៉ុន្តែសំណួរនៃការផ្តល់លេខកូដដែលអាចទុកចិត្តបានទៅកាន់ផ្នែកផ្សេងៗនៅតែបើកចំហ។ យើងបានសម្រេចចិត្តធ្វើសមកាលកម្មជាមួយស្គ្រីប។ មើលទៅដូចនេះ៖

បន្ទាប់ពីការផ្លាស់ប្តូរមកដល់ CI ត្រូវបានបើកដំណើរការ ម៉ាស៊ីនមេសាកល្បងត្រូវបានបង្កើត តួនាទីត្រូវបានដាក់ចេញ និងសាកល្បងដោយម៉ូលេគុល។ ប្រសិនបើអ្វីៗទាំងអស់មិនអីទេ លេខកូដទៅសាខាផលិតផល។ ប៉ុន្តែយើងមិនអនុវត្តកូដថ្មីទៅម៉ាស៊ីនមេដែលមានស្រាប់នៅក្នុងម៉ាស៊ីនទេ។ នេះគឺជាប្រភេទនៃ stopper ដែលចាំបាច់សម្រាប់ភាពអាចរកបានខ្ពស់នៃប្រព័ន្ធរបស់យើង។ ហើយនៅពេលដែលហេដ្ឋារចនាសម្ព័ន្ធក្លាយជាធំ ច្បាប់នៃចំនួនដ៏ច្រើនបានចូលជាធរមាន - ទោះបីជាអ្នកប្រាកដថាការផ្លាស់ប្តូរនេះគ្មានការបង្កគ្រោះថ្នាក់ក៏ដោយ វាអាចនាំឱ្យមានផលវិបាកធ្ងន់ធ្ងរ។

វាក៏មានជម្រើសជាច្រើនសម្រាប់បង្កើតម៉ាស៊ីនមេផងដែរ។ យើងបានបញ្ចប់ការជ្រើសរើសស្គ្រីប Python ផ្ទាល់ខ្លួន។ ហើយសម្រាប់ CI ANSI៖

- 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 តួនាទី Ansible សម្រាប់ការដំឡើងម៉ាស៊ីនមេ។ តួនាទីនីមួយៗត្រូវបានរចនាឡើងដើម្បីដោះស្រាយកិច្ចការឡូជីខលដាច់ដោយឡែកមួយ (ការកាប់ឈើ សវនកម្ម ការអនុញ្ញាតអ្នកប្រើប្រាស់ ការត្រួតពិនិត្យ។ល។)។
• ការធ្វើតេស្តតួនាទី។ ម៉ូលេគុល + TestInfra ។
• ការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួន៖ CMDB + Orchestrator ។
• ពេលវេលាបង្កើតម៉ាស៊ីនមេគឺ ~ 30 នាទី ស្វ័យប្រវត្តិ និងអនុវត្តដោយឯករាជ្យនៃជួរកិច្ចការ។
• ស្ថានភាពដូចគ្នា/ការដាក់ឈ្មោះនៃហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងផ្នែកទាំងអស់ - សៀវភៅលេង ឃ្លាំង ធាតុនិម្មិត។
• ការត្រួតពិនិត្យស្ថានភាពម៉ាស៊ីនមេប្រចាំថ្ងៃ ជាមួយនឹងការបង្កើតរបាយការណ៍ស្តីពីភាពមិនស្របគ្នាជាមួយនឹងស្តង់ដារ។

ខ្ញុំសង្ឃឹមថារឿងរបស់ខ្ញុំនឹងមានប្រយោជន៍សម្រាប់អ្នកដែលចាប់ផ្តើមដំណើររបស់ពួកគេ។ តើជង់ស្វ័យប្រវត្តិកម្មអ្វីដែលអ្នកប្រើ?

ប្រភព: www.habr.com