Desde unha "startup" ata miles de servidores nunha ducia de centros de datos. Como perseguimos o crecemento da infraestrutura de Linux

Se a túa infraestrutura de TI crece demasiado rápido, tarde ou cedo terás que escoller: aumentar linealmente os recursos humanos para apoiala ou iniciar a automatización. Ata algún momento, vivimos no primeiro paradigma, e entón comezou o longo camiño cara a Infraestrutura-como-Código.

Por suposto, NSPK non é unha startup, pero ese ambiente reinou na empresa nos primeiros anos da súa existencia, e aqueles foron anos moi interesantes. O meu nome é Kornyakov Dmitry, Levo máis de 10 anos apoiando infraestruturas Linux con requisitos de alta dispoñibilidade. Incorpórase ao equipo de NSPK en xaneiro de 2016 e, por desgraza, non viu o comezo da existencia da empresa, pero chegou nunha etapa de grandes cambios.

En xeral, podemos dicir que o noso equipo fornece 2 produtos para a empresa. O primeiro son as infraestruturas. O correo debería funcionar, o DNS debería funcionar e os controladores de dominio deberían permitirche entrar en servidores que non deberían fallar. O panorama informático da empresa é enorme! Estes son sistemas de negocio e misión crítica, os requisitos de dispoñibilidade para algúns son 99,999. O segundo produto son os propios servidores, físicos e virtuais. Hai que supervisar os existentes, e os novos deben entregarse regularmente aos clientes de moitos departamentos. Neste artigo quero centrarme en como desenvolvemos a infraestrutura responsable do ciclo de vida do servidor.

Inicio dunha xornada

Ao comezo da nosa viaxe, a nosa pila tecnolóxica tiña o seguinte aspecto:
OS CentOS 7
Controladores de dominio FreeIPA
Automatización - Ansible(+Tower), Cobbler

Todo isto estaba localizado en 3 dominios, repartidos en varios centros de datos. Nun centro de datos hai sistemas de oficina e sitios de probas, no resto hai PROD.

A creación de servidores nun momento foi así:

No modelo de VM, CentOS é mínimo e o mínimo necesario é como o /etc/resolv.conf correcto, o resto vén a través de Ansible.

CMDB - Excel.

Se o servidor é físico, en lugar de copiar a máquina virtual, o SO instalouse nel usando Cobbler: os enderezos MAC do servidor de destino engádense á configuración de Cobbler, o servidor recibe un enderezo IP a través de DHCP e, a continuación, o SO. engádese.

Ao principio ata intentamos facer algún tipo de xestión de configuración en Cobbler. Pero co paso do tempo, isto comezou a traer problemas coa portabilidade das configuracións tanto a outros centros de datos como ao código de Ansible para preparar máquinas virtuales.

Nese momento, moitos de nós percibimos Ansible como unha extensión conveniente de Bash e non escatimamos en deseños que usaban shell e sed. Bashsible en xeral. Isto finalmente levou ao feito de que se o playbook por algún motivo non funcionaba no servidor, era máis fácil eliminar o servidor, arranxar o playbook e executalo de novo. En esencia, non había versións de scripts, nin portabilidade das configuracións.

Por exemplo, queriamos cambiar algunha configuración en todos os servidores:

1. Cambiamos a configuración dos servidores existentes no segmento lóxico/centro de datos. Ás veces non nun día: os requisitos de accesibilidade e a lei de grandes números non permiten que todos os cambios se apliquen á vez. E algúns cambios son potencialmente destrutivos e requiren reiniciar algo, desde os servizos ata o propio sistema operativo.
2. Corrixíndoo en Ansible
3. Arranxámolo en Cobbler
4. Repita N veces para cada segmento lóxico/centro de datos

Para que todos os cambios saian sen problemas, foi necesario ter en conta moitos factores, e os cambios ocorren constantemente.

• Refactorización de código ansible, ficheiros de configuración
• Cambio de boas prácticas internas
• Cambios en función dos resultados da análise de incidencias/accidentes
• Cambiando os estándares de seguridade, tanto internos como externos. Por exemplo, PCI DSS actualízase con novos requisitos cada ano

Crecemento das infraestruturas e inicio da viaxe

Creceu o número de servidores/dominios lóxicos/centros de datos, e con eles o número de erros nas configuracións. Nalgún momento, chegamos a tres direccións nas que hai que desenvolver a xestión da configuración:

1. Automatización. O erro humano nas operacións repetitivas debe evitarse na medida do posible.
2. Repetibilidade. É moito máis doado xestionar a infraestrutura cando é previsible. A configuración dos servidores e ferramentas para a súa preparación debe ser a mesma en todas partes. Isto tamén é importante para os equipos de produtos: despois da proba, débese garantir que a aplicación remate nun ambiente de produción configurado de forma similar ao ambiente de proba.
3. Sinxeleza e transparencia para facer cambios na xestión da configuración.

Queda por engadir un par de ferramentas.

Escollemos GitLab CE como o noso repositorio de código, sobre todo polos seus módulos CI/CD integrados.

Bóveda dos segredos - Hashicorp Vault, incl. para a gran API.

Proba de configuracións e roles ansibles – Molecule+Testinfra. As probas van moito máis rápido se te conectas ao mitógeno ansible. Ao mesmo tempo, comezamos a escribir o noso propio CMDB e orquestrador para o despregamento automático (na imaxe superior de Cobbler), pero esta é unha historia completamente diferente, que o meu colega e o principal desenvolvedor destes sistemas contarán no futuro.

A nosa elección:

Molécula + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Desenvolvemento propio)
Zapateiro
Corredor de Gitlab + GitLab
Bóveda de Hashicorp

Por certo, sobre os roles ansibles. Ao principio só había un, pero despois de varias refactorizacións houbo 17. Recomendo encarecidamente dividir o monólito en roles idempotentes, que logo se poden lanzar por separado; ademais, pode engadir etiquetas. Dividimos os roles por funcionalidades: rede, rexistro, paquetes, hardware, molécula, etc. En xeral, seguimos a seguinte estratexia. Non insisto en que esta é a única verdade, pero funcionou para nós.

• Copiar servidores da "imaxe dourada" é malo!A principal desvantaxe é que non sabes exactamente en que estado están agora as imaxes e que todos os cambios chegarán a todas as imaxes de todas as granxas de virtualización.
• Use os ficheiros de configuración predeterminados ao mínimo e acorde con outros departamentos que vostede é responsable dos ficheiros principais do sistema, por exemplo:
  1. Deixa /etc/sysctl.conf baleiro, a configuración só debería estar en /etc/sysctl.d/. O teu predeterminado nun ficheiro, personalizado para a aplicación noutro.
  2. Use ficheiros de substitución para editar unidades systemd.
• Modele todas as configuracións e inclúeas por completo; se é posible, sen sed nin os seus análogos nos playbooks
• Refactorización do código do sistema de xestión de configuración:
  1. Divide as tarefas en entidades lóxicas e reescribe o monolito en roles
  2. Use linters! Ansible-lint, yaml-lint, etc
  3. Cambia o teu enfoque! Ningún bashsible. É necesario describir o estado do sistema
• Para todos os roles de Ansible, cómpre escribir probas en molécula e xerar informes unha vez ao día.
• No noso caso, despois de preparar as probas (das que hai máis de 100), atopáronse uns 70000 erros. Levou varios meses arranxalo.

A nosa implementación

Entón, os roles ansibles estaban listos, modelados e verificados por linters. E ata os gits son creados en todas partes. Pero a cuestión da entrega fiable de código a diferentes segmentos permaneceu aberta. Decidimos sincronizar con guións. Parece así:

Despois de que chega o cambio, lánzase CI, créase un servidor de proba, desprázanse os roles e a molécula probóase. Se todo está ben, o código vai á rama prod. Pero non aplicamos código novo aos servidores existentes na máquina. Este é un tipo de tapón que é necesario para a alta dispoñibilidade dos nosos sistemas. E cando a infraestrutura se fai enorme, entra en xogo a lei dos grandes números, aínda que estea seguro de que o cambio é inofensivo, pode levar a graves consecuencias.

Tamén hai moitas opcións para crear servidores. Acabamos elixindo scripts de Python personalizados. E para 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}}"

A iso chegamos, o sistema segue vivindo e desenvolvéndose.

• 17 roles Ansibles para configurar o servidor. Cada un dos roles está deseñado para resolver unha tarefa lóxica separada (rexistro, auditoría, autorización de usuarios, vixilancia, etc.).
• Proba de roles. Molécula + TestInfra.
• Desenvolvemento propio: CMDB + Orquestrator.
• O tempo de creación do servidor é de ~30 minutos, automatizado e practicamente independente da cola de tarefas.
• O mesmo estado/denominación da infraestrutura en todos os segmentos: playbooks, repositorios, elementos de virtualización.
• Comprobación diaria do estado do servidor con xeración de informes sobre discrepancias co estándar.

Espero que a miña historia sexa útil para aqueles que están no inicio da súa viaxe. Que pila de automatización usas?

Fonte: www.habr.com