Si la vostra infraestructura informàtica creix massa ràpidament, tard o d'hora us trobareu davant d'una opció: augmentar linealment els recursos humans per donar-hi suport o iniciar l'automatització. Fins a algun moment, vam viure en el primer paradigma, i després va començar el llarg camí cap a la infraestructura com a codi.
Per descomptat, NSPK no és una startup, però aquest ambient va regnar a l'empresa en els primers anys de la seva existència, i aquells van ser anys molt interessants. El meu nom és , porto més de 10 anys donant suport a la infraestructura de Linux amb requisits d'alta disponibilitat. Es va incorporar a l'equip de NSPK el gener de 2016 i, malauradament, no va veure el començament de l'existència de l'empresa, però va arribar en una etapa de grans canvis.
En general, podem dir que el nostre equip subministra 2 productes per a l'empresa. El primer és la infraestructura. El correu hauria de funcionar, el DNS hauria de funcionar i els controladors de domini us haurien de permetre entrar en servidors que no haurien de fallar. El panorama informàtic de l'empresa és enorme! Aquests són sistemes crítics per al negoci i la missió, els requisits de disponibilitat per a alguns són 99,999. El segon producte són els propis servidors, físics i virtuals. S'han de controlar els existents i els nous s'han de lliurar regularment als clients de molts departaments. En aquest article vull centrar-me en com hem desenvolupat la infraestructura responsable del cicle de vida del servidor.
A partir d'un viatge
Al principi del nostre viatge, la nostra pila tecnològica tenia aquest aspecte:
OS CentOS 7
Controladors de domini FreeIPA
Automatització - Ansible(+Tower), Cobbler
Tot això es trobava en 3 dominis, repartits en diversos centres de dades. En un centre de dades hi ha sistemes d'oficina i llocs de proves, a la resta hi ha PROD.
La creació de servidors en un moment va semblar així:
A la plantilla de VM, CentOS és mínim i el mínim requerit és com el /etc/resolv.conf correcte, la resta arriba a través d'Ansible.
CMDB - Excel.
Si el servidor és físic, en comptes de copiar la màquina virtual, el sistema operatiu s'hi va instal·lar mitjançant Cobbler: les adreces MAC del servidor de destinació s'afegeixen a la configuració de Cobbler, el servidor rep una adreça IP mitjançant DHCP i, a continuació, el sistema operatiu. s'afegeix.
Al principi, fins i tot vam intentar fer algun tipus de gestió de configuració a Cobbler. Però amb el temps, això va començar a comportar problemes amb la portabilitat de les configuracions tant a altres centres de dades com al codi Ansible per preparar les VM.
En aquell moment, molts de nosaltres vam percebre Ansible com una extensió convenient de Bash i no vam escatimar els dissenys amb shell i sed. Bashsible en general. Finalment, això va provocar que si el llibre de jugades per algun motiu no funcionava al servidor, era més fàcil suprimir el servidor, arreglar el llibre de jocs i tornar-lo a executar. Bàsicament no hi havia versions de scripts, ni portabilitat de configuracions.
Per exemple, volíem canviar alguna configuració a tots els servidors:
- Canviem la configuració dels servidors existents al segment lògic/centre de dades. De vegades no en un dia: els requisits d'accessibilitat i la llei del gran nombre no permeten aplicar tots els canvis alhora. I alguns canvis són potencialment destructius i requereixen reiniciar alguna cosa, des dels serveis fins al propi sistema operatiu.
- Arreglant-ho a Ansible
- Ho arreglem a Cobbler
- Repetiu N vegades per a cada segment lògic/centre de dades
Perquè tots els canvis anessin sense problemes, calia tenir en compte molts factors, i els canvis es produeixen constantment.
- Refactorització de codi ansible, fitxers de configuració
- Canvi de bones pràctiques internes
- Canvis basats en els resultats de l'anàlisi d'incidències/accidents
- Canvi dels estàndards de seguretat, tant interns com externs. Per exemple, PCI DSS s'actualitza amb nous requisits cada any
Creixement de les infraestructures i inici del viatge
El nombre de servidors/dominis lògics/centres de dades va créixer, i amb ells el nombre d'errors en les configuracions. En algun moment, vam arribar a tres direccions en les quals cal desenvolupar la gestió de la configuració:
- Automatització. S'ha d'evitar tant com sigui possible l'error humà en les operacions repetitives.
- Repetibilitat. És molt més fàcil gestionar la infraestructura quan és previsible. La configuració dels servidors i les eines per a la seva preparació hauria de ser la mateixa a tot arreu. Això també és important per als equips de producte: després de la prova, s'ha de garantir que l'aplicació acabi en un entorn de producció configurat de manera similar a l'entorn de prova.
- Simplicitat i transparència per fer canvis en la gestió de la configuració.
Queda per afegir un parell d'eines.
Vam triar GitLab CE com el nostre dipòsit de codi, sobretot pels seus mòduls CI/CD integrats.
Volta dels secrets - Hashicorp Vault, incl. per a la gran API.
Prova de configuracions i rols ansibles – Molècula+Testinfra. Les proves són molt més ràpides si us connecteu a un mitogen ansible. Al mateix temps, vam començar a escriure el nostre propi CMDB i orquestrador per al desplegament automàtic (a la imatge de dalt de Cobbler), però aquesta és una història completament diferent, que explicaran el meu col·lega i el desenvolupador principal d'aquests sistemes en el futur.
La nostra elecció:
Molècula + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Desenvolupament propi)
Cobridor
Gitlab + corredor de GitLab
Volta Hashicorp
Per cert, sobre rols ansibles. Al principi només n'hi havia un, però després de diverses refactoritzacions n'hi havia 17, recomano encaridament dividir el monòlit en rols idempotents, que després es poden llançar per separat, podeu afegir etiquetes. Hem dividit els rols per funcionalitat: xarxa, registre, paquets, maquinari, molècula, etc. En general, hem seguit l'estratègia següent. No insisteixo que aquesta sigui l'única veritat, però ens va funcionar.
- Copiar servidors de la "imatge daurada" és dolent!El principal desavantatge és que no sabeu exactament en quin estat es troben ara les imatges i que tots els canvis arribaran a totes les imatges de totes les granges de virtualització.
- Utilitzeu els fitxers de configuració predeterminats al mínim i acordeu amb altres departaments que sou responsable dels fitxers principals del sistema, per exemple:
- Deixeu /etc/sysctl.conf buit, la configuració només hauria d'estar a /etc/sysctl.d/. El vostre predeterminat en un fitxer, personalitzat per a l'aplicació en un altre.
- Utilitzeu fitxers de substitució per editar unitats systemd.
- Plantilla totes les configuracions i inclou-les completament, si és possible, sense sed ni els seus anàlegs als llibres de jugades
- Refactorització del codi del sistema de gestió de configuració:
- Descompondre les tasques en entitats lògiques i reescriure el monòlit en rols
- Utilitza linters! Ansible-lint, yaml-lint, etc
- Canvia el teu enfocament! Sense cap mena. Cal descriure l'estat del sistema
- Per a tots els rols d'Ansible, cal escriure proves en molècula i generar informes un cop al dia.
- En el nostre cas, després de preparar les proves (de les quals n'hi ha més de 100), s'han trobat uns 70000 errors. Va trigar uns quants mesos a arreglar-ho.
La nostra implementació
Per tant, els rols ansibles estaven preparats, modelats i verificats per linters. I fins i tot els gits es plantegen a tot arreu. Però la qüestió del lliurament de codi fiable a diferents segments va romandre oberta. Vam decidir sincronitzar-nos amb scripts. Sembla així:
Després que arribi el canvi, es llança CI, es crea un servidor de prova, es desenvolupen rols i la molècula prova. Si tot està bé, el codi va a la branca prod. Però no apliquem codi nou als servidors existents a la màquina. Es tracta d'una mena de tap que és necessari per a l'alta disponibilitat dels nostres sistemes. I quan la infraestructura es fa enorme, entra en joc la llei dels grans nombres, fins i tot si esteu segurs que el canvi és inofensiu, pot tenir conseqüències nefastes.
També hi ha moltes opcions per crear servidors. Vam acabar escollint scripts Python personalitzats. I per a CI ansible:
- 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}}"Això és al que hem arribat, el sistema continua vivint i desenvolupant-se.
- 17 rols Ansible per configurar el servidor. Cadascun dels rols està dissenyat per resoldre una tasca lògica independent (registre, auditoria, autorització d'usuaris, supervisió, etc.).
- Prova de rol. Molècula + TestInfra.
- Desenvolupament propi: CMDB + Orchestrator.
- El temps de creació del servidor és d'aproximadament 30 minuts, automatitzat i pràcticament independent de la cua de tasques.
- El mateix estat/denominació de la infraestructura en tots els segments: llibres de jugades, dipòsits, elements de virtualització.
- Comprovació diària de l'estat del servidor amb generació d'informes de discrepàncies amb l'estàndard.
Espero que la meva història sigui útil a aquells que estan al començament del seu viatge. Quina pila d'automatització fas servir?
Font: www.habr.com