Ikiwa miundombinu yako ya TEHAMA itakua haraka sana, hivi karibuni utakabiliwa na chaguo: ongeza rasilimali watu ili kuunga mkono au kuanzisha otomatiki. Hadi wakati fulani, tuliishi katika dhana ya kwanza, na kisha njia ndefu ya Miundombinu-kama-Kanuni ilianza.
Kwa kweli, NSPK sio mwanzo, lakini hali kama hiyo ilitawala katika kampuni hiyo katika miaka ya kwanza ya uwepo wake, na hiyo ilikuwa miaka ya kupendeza sana. Jina langu ni , Nimekuwa nikisaidia miundombinu ya Linux yenye mahitaji ya juu ya upatikanaji kwa zaidi ya miaka 10. Alijiunga na timu ya NSPK mnamo Januari 2016 na, kwa bahati mbaya, hakuona mwanzo wa uwepo wa kampuni hiyo, lakini alikuja katika hatua ya mabadiliko makubwa.
Kwa ujumla, tunaweza kusema kwamba timu yetu hutoa bidhaa 2 kwa kampuni. Ya kwanza ni miundombinu. Barua inapaswa kufanya kazi, DNS inapaswa kufanya kazi, na vidhibiti vya kikoa vinapaswa kukuruhusu kuingia kwenye seva ambazo hazipaswi kuanguka. Mazingira ya IT ya kampuni ni makubwa! Hii ni mifumo muhimu ya biashara na dhamira, mahitaji ya upatikanaji kwa baadhi ni 99,999. Bidhaa ya pili ni seva zenyewe, za kimwili na za kawaida. Zilizopo zinahitaji kufuatiliwa, na mpya lazima ziwasilishwe mara kwa mara kwa wateja kutoka idara nyingi. Katika makala hii nataka kuzingatia jinsi tulivyotengeneza miundombinu ambayo inawajibika kwa mzunguko wa maisha ya seva.
Mwanzo wa safari
Mwanzoni mwa safari yetu, safu yetu ya teknolojia ilionekana kama hii:
OS CentOS 7
FreeIPA Domain Controllers
Automation - Ansible(+Tower), Cobbler
Yote hii ilikuwa iko katika vikoa 3, vilivyoenea katika vituo kadhaa vya data. Katika kituo kimoja cha data kuna mifumo ya ofisi na tovuti za majaribio, kwa wengine kuna PROD.
Kuunda seva wakati mmoja ilionekana kama hii:
Katika kiolezo cha VM, CentOS ni ndogo na kima cha chini kinachohitajika ni kama sahihi /etc/resolv.conf, iliyobaki inakuja kupitia Ansible.
CMDB - Excel.
Ikiwa seva ni ya mwili, basi badala ya kunakili mashine ya kawaida, OS iliwekwa juu yake kwa kutumia Cobbler - anwani za MAC za seva inayolengwa huongezwa kwenye usanidi wa Cobbler, seva inapokea anwani ya IP kupitia DHCP, na kisha OS. imeongezwa.
Mara ya kwanza tulijaribu hata kufanya aina fulani ya usimamizi wa usanidi katika Cobbler. Lakini baada ya muda, hii ilianza kuleta matatizo na kubebeka kwa usanidi kwa vituo vingine vya data na kwa nambari ya Ansible ya kuandaa VM.
Wakati huo, wengi wetu tuliona Ansible kama kiendelezi rahisi cha Bash na hatukuruka miundo kwa kutumia shell na sed. Kwa ujumla Bashsible. Hii hatimaye ilisababisha ukweli kwamba ikiwa kitabu cha kucheza kwa sababu fulani haikufanya kazi kwenye seva, ilikuwa rahisi kufuta seva, kurekebisha kitabu cha kucheza na kuiendesha tena. Kimsingi hapakuwa na matoleo ya hati, hakuna kubebeka kwa usanidi.
Kwa mfano, tulitaka kubadilisha usanidi fulani kwenye seva zote:
- Tunabadilisha usanidi kwenye seva zilizopo katika sehemu ya mantiki/kituo cha data. Wakati mwingine si kwa siku moja - mahitaji ya upatikanaji na sheria ya idadi kubwa hairuhusu mabadiliko yote kutumika mara moja. Na mabadiliko mengine yanaweza kuharibu na yanahitaji kuanzisha tena kitu - kutoka kwa huduma hadi kwa OS yenyewe.
- Kuirekebisha katika Ansible
- Tunatengeneza kwenye Cobbler
- Rudia mara N kwa kila sehemu ya kimantiki/kituo cha data
Ili mabadiliko yote yaende vizuri, ilikuwa ni lazima kuzingatia mambo mengi, na mabadiliko hutokea daima.
- Inarekebisha msimbo unaowezekana, faili za usanidi
- Kubadilisha mbinu bora za ndani
- Mabadiliko kulingana na matokeo ya uchambuzi wa matukio/ajali
- Kubadilisha viwango vya usalama, vya ndani na nje. Kwa mfano, PCI DSS inasasishwa na mahitaji mapya kila mwaka
Ukuaji wa miundombinu na mwanzo wa safari
Idadi ya seva/vikoa vya kimantiki/vituo vya data ilikua, na pamoja nao idadi ya makosa katika usanidi. Wakati fulani, tulifika kwa pande tatu ambazo usimamizi wa usanidi unahitaji kuendelezwa:
- Otomatiki. Hitilafu ya kibinadamu katika shughuli za kurudia inapaswa kuepukwa iwezekanavyo.
- Kuweza kurudiwa. Ni rahisi zaidi kusimamia miundombinu inapotabirika. Usanidi wa seva na zana za utayarishaji wao zinapaswa kuwa sawa kila mahali. Hili pia ni muhimu kwa timu za bidhaa - baada ya majaribio, ni lazima programu ihakikishwe ili kuishia katika mazingira ya uzalishaji yaliyosanidiwa sawa na mazingira ya majaribio.
- Urahisi na uwazi wa kufanya mabadiliko kwenye usimamizi wa usanidi.
Inabakia kuongeza zana kadhaa.
Tulichagua GitLab CE kama hazina yetu ya msimbo, sio kwa uchache kwa moduli zake zilizojengewa ndani za CI/CD.
Vault ya siri - Hashicorp Vault, incl. kwa API kubwa.
Mipangilio ya kupima na majukumu yanayofaa - Molekuli+Testinfra. Majaribio huenda kwa kasi zaidi ukiunganisha kwenye mitojeni inayotumika. Wakati huo huo, tulianza kuandika CMDB yetu wenyewe na orchestrator kwa kupelekwa moja kwa moja (katika picha hapo juu Cobbler), lakini hii ni hadithi tofauti kabisa, ambayo mwenzangu na msanidi mkuu wa mifumo hii watasema katika siku zijazo.
Chaguo letu:
Molekuli + Testinfra
Ansible + Tower + AWX
Ulimwengu wa Seva + DITNET (Maendeleo ya kibinafsi)
Mtengenezaji
Gitlab + GitLab mkimbiaji
Hashicorp Vault
Kwa njia, kuhusu majukumu yanayofaa. Mara ya kwanza kulikuwa na moja tu, lakini baada ya marekebisho kadhaa kulikuwa na 17. Ninapendekeza sana kuvunja monolith katika majukumu ya ujinga, ambayo yanaweza kuzinduliwa tofauti; kwa kuongeza, unaweza kuongeza vitambulisho. Tuligawanya majukumu kwa utendakazi - mtandao, ukataji miti, vifurushi, maunzi, molekuli n.k. Kwa ujumla, tulifuata mkakati ulio hapa chini. Sisisitiza kwamba hii ndiyo ukweli pekee, lakini ilitufanyia kazi.
- Kuiga seva kutoka kwa "picha ya dhahabu" ni mbaya!Hasara kuu ni kwamba hujui ni hali gani hasa picha ziko sasa, na kwamba mabadiliko yote yatakuja kwa picha zote katika mashamba yote ya virtualization.
- Tumia faili za usanidi chaguo-msingi kwa kiwango cha chini na ukubaliane na idara zingine kuwa unawajibika kwa faili kuu za mfumo, kwa mfano:
- Ondoka /etc/sysctl.conf tupu, mipangilio inapaswa kuwa katika /etc/sysctl.d/. Chaguo-msingi yako katika faili moja, maalum kwa programu katika nyingine.
- Tumia kubatilisha faili kuhariri vitengo vya mfumo.
- Onyesha usanidi wote na ujumuishe kabisa; ikiwezekana, hakuna sed au analogi zake kwenye vitabu vya kucheza.
- Kuunda upya msimbo wa mfumo wa usimamizi wa usanidi:
- Gawanya majukumu katika huluki zenye mantiki na uandike upya monolith kuwa majukumu
- Tumia linters! Ansible-lint, yaml-lint, nk
- Badilisha mtazamo wako! Hakuna bashsible. Inahitajika kuelezea hali ya mfumo
- Kwa majukumu yote yanayostahili unahitaji kuandika majaribio katika molekuli na kutoa ripoti mara moja kwa siku.
- Kwa upande wetu, baada ya kuandaa vipimo (ambayo kuna zaidi ya 100), kuhusu makosa 70000 yalipatikana. Ilichukua miezi kadhaa kurekebisha.
Utekelezaji wetu
Kwa hivyo, majukumu yanayofaa yalikuwa tayari, yameonyeshwa na kuangaliwa na linters. Na hata gits huinuliwa kila mahali. Lakini swali la utoaji wa kanuni za kuaminika kwa sehemu tofauti lilibaki wazi. Tuliamua kusawazisha na maandishi. Inaonekana hivyo:
Baada ya mabadiliko kufika, CI inazinduliwa, seva ya mtihani huundwa, majukumu yanatolewa, na kujaribiwa na molekuli. Ikiwa kila kitu kiko sawa, msimbo huenda kwenye tawi la prod. Lakini hatutumii nambari mpya kwa seva zilizopo kwenye mashine. Hii ni aina ya kizuizi ambacho ni muhimu kwa upatikanaji wa juu wa mifumo yetu. Na wakati miundombinu inakuwa kubwa, sheria ya idadi kubwa huanza kutumika - hata kama una uhakika kwamba mabadiliko hayana madhara, inaweza kusababisha matokeo mabaya.
Pia kuna chaguzi nyingi za kuunda seva. Tulimaliza kuchagua maandishi maalum ya Python. Na kwa CI inayowezekana:
- 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}}"Hivi ndivyo tumekuja, mfumo unaendelea kuishi na kuendeleza.
- 17 Majukumu yanayofaa ya kusanidi seva. Kila moja ya majukumu imeundwa kutatua kazi tofauti ya kimantiki (ukataji miti, ukaguzi, idhini ya mtumiaji, ufuatiliaji, nk).
- Mtihani wa jukumu. Molekuli + TestInfra.
- Ukuzaji mwenyewe: CMDB + Orchestrator.
- Muda wa kuunda seva ni ~ dakika 30, imejiendesha kiotomatiki na haitegemei foleni ya kazi.
- Hali sawa / jina la miundombinu katika sehemu zote - vitabu vya kucheza, hazina, vipengele vya uboreshaji.
- Ukaguzi wa kila siku wa hali ya seva na utoaji wa ripoti juu ya kutofautiana na kiwango.
Natumai hadithi yangu itakuwa muhimu kwa wale ambao wako mwanzoni mwa safari yao. Je, unatumia mrundikano gani wa kiotomatiki?
Chanzo: mapenzi.com