Hoy hablaremos sobre qué es SCM y contaremos algunas historias a través del prisma de las cuales consideraremos Ansible, SaltStack, Chef y Puppet, eligiendo la mejor opción para una tarea específica.
El material se basa en una transcripción de un
informe de Andrei Filatov , ingeniero jefe de sistemas de EPAM Systems, de nuestra conferencia DevOops 2017 de octubre.
¿Qué es SCM y con qué se come?
¿Qué es SCM? En primer lugar, es algo que permite que nuestra infraestructura del estado A ejecute el estado B mediante la ejecución de algún código. Muchos desarrolladores que no son ingenieros de DevOps en la práctica piensan que algo está sucediendo de alguna manera "automática". en infraestructura.
El método "automático" nos implementa SCM (System Configuration Management). ¿Para qué es esto? Principalmente para construir infraestructuras repetibles y consistentes. SCM extiende bien los procesos de CI / CD. Como se trata de código, puede almacenarse en cualquier sistema de control de versiones: Git, Mercurial. Es bastante simple de desarrollar y mantener.
El final es un ciclo de automatización cerrado: todo se puede hacer automáticamente, desde crear la infraestructura hasta implementarla e implementar el código.
Qué es SCM: Ansible
Considere a nuestros solicitantes. El primero es Ansible. Tiene una arquitectura sin agente, si estamos hablando de una versión de código abierto, está escrita en Python, tiene un DSL similar a Yaml, es fácilmente extensible debido a los módulos escritos en Python, es muy simple y liviano. Ansible tiene el umbral de entrada más bajo: puede enseñar a cualquiera.
Existe experiencia cuando una persona, sin conocer Python, sin saber nada sobre SCM, ingresó a Ansible en solo dos días y ya comenzó a hacer algo.
A continuación se muestra un ejemplo de ChatOps: un notificador en Slack. El código Ansible que vio a Yaml no es nada nuevo.
- block: - name: "SlackNotify : Deploy Start" local_action: module: slack token: "{{ slack_url }}" attachments: - title: "Deploy to {{ inventory_hostname }} has been Started" text: "<!here> :point_up_2:" color: "#551a8b" - include: configure.yml tags: - configure - include: remote-fetch.yml tags: - remote - include: assets.yml
Qué es SCM: Chef
Chef es una arquitectura cliente-servidor, hay un servidor Chef y un cliente Chef. La configuración basada en búsquedas, escrita en Ruby, tiene Ruby DSL. En consecuencia, dentro de sus libros de cocina y recetas puede usar todo el poder de Ruby, pero no le recomiendo hacerlo. Chef tiene una gran comunidad y el mayor conjunto de herramientas entre todos los SCM. Así es como se ve el código Chef, esta es la implementación de Jetty.
Qué es SCM: SaltStack
SaltStack tiene una arquitectura sin agente que funciona en modo push usando Salt-SSH, y una arquitectura cliente-servidor cuando hay Salt-master y Salt-minion. El énfasis está en la automatización en tiempo real, la ejecución paralela inmediata de todos los procesos y escrita en Python. También es un lenguaje similar a Yaml, el código es muy similar a Ansible.
#ntp-packages: pkg.installed: - pkgs: - ntp - ntpdate #/etc/ntp.conf: file: - managed - source: salt:
Qué es SCM: Puppet
El último de nuestros postores es Puppet. También tiene una arquitectura cliente-servidor, como Chef, la configuración no se basa en la búsqueda, sino en los "hechos" que vienen con el Puppet-master, escrito en Ruby, tiene un DSL similar a Ruby. Pero a los títeres no se les permite usar código Ruby puro en sus manifiestos. Esto es tanto un plus como un menos. Así es como se ve el código de manifiesto de Puppet:
class { 'mysql::server' : root_password => 'password' } mysql::db{ ['test', 'test2', 'test3']: ensure => present, charset => 'utf8', require => Class['mysql::server'], } mysql::db{ 'test4': ensure => present, charset => 'latin1', } mysql::db{ 'test5': ensure => present, charset => 'binary', collate => 'binary', }
SCM en la práctica
SaltStack en un ambiente desmilitarizado
En primer lugar, me gustaría compartir un proyecto escrito en SaltStack. Este es nuestro proyecto anterior y el dolor más fresco, y el dolor más fresco es siempre el más doloroso. Nuestro cliente se dedica al almacenamiento de datos: esta es la producción de servidores de hierro para almacenar datos en GPFS, GlusterFS, pero construcciones personalizadas. Él vino a nosotros con las siguientes tareas:
- Creación de un instalador USB / DVD. Debe crear un medio desde el que esté instalado todo. Esto se hace para clientes clientes que viven en áreas cerradas, donde los servidores con mayor frecuencia no tienen Internet. Necesitamos empacar en un ISO, enviar a ingenieros de campo que implementarán todo lo necesario en el sitio.
- Implemente un clúster de productos. Los clientes tienen varios productos grandes, debemos poder implementarlos en modo de clúster.
- Gestión, configuración y mantenimiento del clúster utilizando la utilidad CLI. Nuestro marco debería ayudar a los ingenieros de campo a administrar el clúster.
El cliente tenía varios requisitos. En primer lugar, tiene una gran experiencia en Python, de hecho, solo desarrolladores de C y Python. El cliente dijo de inmediato: "Queremos SaltStack", sin dejar otra opción.
¿A qué nos enfrentamos? El cliente tiene varios productos en la instalación, todos deben ser con Salt-Masters. Pero nos enfrentamos con el problema de escalar la configuración Multi-Master. Por ejemplo, en NODE Info (el estado de un servidor específico), seleccionamos milisegundos con una configuración de dos maestros, segundos con tres maestros y con cinco nunca esperamos que se complete la operación. MultiMaster es una buena característica, pero no escala bien.
El segundo problema que encontramos fue el trabajo en equipo: SaltStack tiene Runner y Módulo. El módulo es una extensión que se ejecuta en Salt Minion, en el lado de la máquina. El corredor se ejecuta en el lado del servidor. A menudo tuvimos batallas: qué hacer Runner y qué hacer Módulos.
Luego nos encontramos con una pequeña sorpresa de cache.mine:
ime = ImeActions() id = __grains__['id'] if id == ime.master_id: ret = __salt__['mine.get'](id, 'ime_actions.make_bfs_uuid') ime_dict = ret.get(id, None) if not ime_dict: try: result = __salt__['mine.send']('ime_actions.make_bfs_uuid') except Exeption, e: log.error("Failed to generate uuid: {0}.".format(str(e))) result = False else:
Tenemos una utilidad que está escrita en C. La ejecutamos, genera una identificación aleatoria. Debe ser único entre todos los participantes en el clúster, respectivamente, debemos hacer esto una vez en el maestro y luego distribuirlo entre las máquinas. Usamos cache.mine para esto. Al final resultó que, él no está experimentando un reinicio.
"Condición de carrera". La paralelización es buena, pero en la configuración básica state.orchestrate entra en state.sls se está ejecutando si se producen procesos largos. Por tiempo de espera, él cree que el Estado ya se ha completado, aunque todavía se está ejecutando, y está tratando de comenzar el próximo. Se produce un error Y este problema aún no se ha solucionado.
Puedes
mirar GitHub .
¿Qué podríamos usar además de SaltStack?
SaltStack en un entorno DMZ
- DMZ Chef es genial, Puppet también. Y con Ansible, el problema es que, si no hay Torre, no hay forma de iniciar la configuración en modo Pull desde nuestros nodos, lo que debe hacerse en la zona desmilitarizada.
- Marco para CLI (en Python). Chef y Puppet no son muy adecuados, pero si no tiene restricciones para usar solo Python, puede escribir en Ruby y usar las API Chef o Puppet. Ansible toolkit no es compatible con esto.
- Gestión de clústeres. Chef es muy adecuado para administrar clústeres, Puppet también, y Ansible se escribió originalmente para administrar clústeres en Amazon.
Chef en un ambiente amplio y dinámico.
Al cliente se le ocurrió la tarea de consolidar todos los recursos en una nube: era Openstack. Antes de eso, todo estaba disperso: algo en Rackspace Cloud, algo en servidores dedicados o sus centros de datos privados.
Querían una gestión de recursos totalmente dinámica, y también para que sus aplicaciones pudieran agregar capacidad para sí mismos si fuera necesario. Es decir, necesitamos una infraestructura dinámica completa y un entorno totalmente dinámico tanto hacia arriba como hacia abajo.
Para construir correctamente el proceso de CD, necesita un entorno totalmente automatizado. Creamos SDLC - Ciclo de vida de desarrollo de software para ellos, y lo aplicamos, incluso para SCM. Pasan pruebas de integración no solo de aplicaciones, sino también de infraestructura.
En consecuencia, cuando algo va mal con nosotros, nosotros, como los chicos de Netflix, deberíamos ser capaces de matar recursos defectuosos y restaurar a los trabajadores frescos y garantizados a su lugar.
¿Qué problemas encontramos?
- Era 2013, utilizaba Chef 10, en el que una búsqueda lenta. Comenzamos la búsqueda, recorriendo todos los autos, y nos llevó una eternidad. Intentamos resolver el problema con la convención de nomenclatura, así como con la selección y búsqueda de fqdn. Esto redujo el alcance de la búsqueda, debido a que se aceleró.
Pero algunas operaciones deben hacerse en todo el entorno. En consecuencia, la búsqueda se ejecutó una vez al principio, el resultado se almacenó en el atributo y, utilizando Ruby, filtramos los resultados: analizamos las piezas que necesitábamos e hicimos lo que era necesario.
if !Chef::Config[:solo] search(:node, "fqdn:*metro-#{node[:env]}-mongodb*").each do |mongo| @mongodbs << mongo.fqdn end else @mongodbs = ["lvs-metro-#{node[:env]}-mongodb3001.qa.example.com"] end
En pocas palabras: use convenciones de nomenclatura, ejecute la búsqueda una vez, use Ruby para filtrar los resultados deseados.
- Usar "node.save" no es seguro, tenga cuidado y cuidado. Encontramos este problema al implementar clústeres MySQL y utilizamos node.save dentro de la receta en un nodo MySQL configurado de forma incompleta. Y en el momento de la ampliación, algunas aplicaciones dieron un error 500. Resultó que estábamos guardando el nodo en el momento equivocado: va al servidor Chef, allí mismo, el cliente Chef en la interfaz de usuario recoge un nuevo nodo que no estaba configurado antes del modo operativo.
- La falta de "splay" puede matar al servidor del chef. Splay es un parámetro del cliente Chef que le permite establecer el rango cuando el cliente va al servidor para la configuración. Con una carga pesada, cuando necesita implementar muchos nodos al mismo tiempo, esto no matará al servidor.
¿Qué podemos usar en lugar de chef?
- Aprovisionamiento dinámico SaltStack es perfecto porque tiene SaltCloud que se integra perfectamente en cualquier lugar. Puppet tiene una funcionalidad similar, pero solo está disponible en Puppet Enterprise, por dinero. Ansible es muy adecuado si la empresa "vive" en Amazon, si es algo más: puede vincularlo con alternativas, pero no es tan conveniente.
- SDLC Chef tiene todo, desde Test Kitchen hasta la elección de herramientas para las pruebas de integración. SaltStack tiene todas las herramientas de Python disponibles, ahora Puppet lo tiene todo. Ansible tiene una especificación de rol, puede usar Chef's Test Kitchen, pero no es una herramienta nativa.
- Reemplazo de recursos. Todo está bien en Chef, en SaltStack puedes terminar SaltCloud al estado deseado, en Puppet las herramientas solo están en la versión Enterprise, y Ansible funciona bien solo con Amazon.
EPAM Private Cloud con Chef
Un año y medio antes del advenimiento de AWS OpsWorks, queríamos crear un Amazon CloudFormation avanzado integrando Chef para que los recursos no solo se implementaran, sino que también se configuraran.
La segunda tarea global es crear un catálogo de servicios para que los clientes y usuarios puedan usar la CLI para implementar una pila LAMP completamente lista para usar, por ejemplo.
Elegimos Chef, pero el proyecto tenía que soportar diferentes SCM. Comenzamos con el Chef-Server incorporado, y los usuarios también podrían usar su propio Chef-Server, que está alojado en algún lugar con ellos. Es decir, no obtuvimos acceso a los recursos de los usuarios y las computadoras portátiles, pero funcionó de todos modos.
Se puede usar cualquier SCM para implementar CloudFormation + OpsWork, todos son adecuados. Para crear un catálogo, todos, excepto SaltStack, lo harán bien. SaltStack tiene sus matices: es extremadamente difícil encontrar un especialista que conozca bien a SaltStack y pueda crear un servicio y llenar el catálogo.
La popularidad de SCM en EPAM
Estas son estadísticas de popularidad de SCM dentro de EPAM. SaltStack está muy lejos. En primer lugar Ansible, es el más simple y con un umbral de entrada bajo. Cuando tratamos de encontrar a alguien en el mercado con conocimiento de SCM, el mercado se ve casi igual.
Trabaja con Ansible
Consejos que puedo dar al trabajar con Ansible:
- Use 'acelerar', implementa configuraciones 2-6 veces más rápido que SSH (para el6). Para todos los demás, hay 'canalización'. Está desactivado por compatibilidad con versiones anteriores, pero volver a activar la canalización es muy fácil, recomiendo hacerlo.
- Use 'with_items'
- name: project apt dependencies installed apt: name: "{{ item }}" become: yes with_items: - build-essential - acl - git - curl - gnupg2 - libpcre3-dev - python-apt - python-pycurl - python-boto - imagemagick - libmysqlclient-dev
En este ejemplo, instalamos paquetes, este esquema se puede utilizar para crear usuarios y operaciones similares.
- Utilice con cuidado 'local_action' y 'delegated'. El primero le permite obtener algo similar al SaltStack Runner, el segundo puede delegar tareas a máquinas específicas.
- name: create postgresql database postgresql_db: name: "{{ database_name }}" login_host: "{{ database_host }}" login_user: "{{ database_master_user }}" login_password: "{{ database_master_password }}" encoding: "UTF-8" lc_collate: "en_US.UTF-8" lc_ctype: "en_US.UTF-8" template: "template0" state: present delegate_to: "{{ groups.pg_servers|random}}"
Esta es una pieza de creación de base de datos. Sin la última línea, la operación se realizaría varias veces y recaería en el segundo intento de crear la misma base de datos.
- Optimice sus roles y rendimiento con etiquetas. Esto puede reducir significativamente el tiempo de entrega.
Conclusiones
Para mí, Ansible es un favorito. SaltStack es muy bueno, muy flexible, pero requiere conocimiento de Python, sin ellos es mejor no usar SaltStack. Chef es una bala de plata universal para cualquier tarea y cualquier escala, pero requiere más conocimiento que Ansible. Y quién usa Puppet, no lo sé. En principio, es muy similar al Chef, pero con sus propios matices.
Minuto de publicidad. Si le gustó este informe de la conferencia DevOops , tenga en cuenta que el 14 de octubre se llevará a cabo el nuevo DevOops 2018 en San Petersburgo, habrá muchas cosas interesantes en su programa. El sitio ya tiene los primeros oradores e informes.