Autor invitado del blog: Stefan Scharlott, arquitecto de soluciones de DevOps y automatización, Erik Sterck GmbH
Erik Sterck GmbH siempre ha sido una "casa de sistemas" muy exitosa, como la llamamos en Alemania, principalmente centrada en la reventa de productos y software de los grandes proveedores de hardware y software. Hace unos años, esto empezó a cambiar. Creo que la mayoría de la gente es consciente del cambio de un enfoque basado en el hardware o incluso en un hipervisor a un enfoque más basado en las aplicaciones. Y de repente, todo el mundo es bombardeado con términos como DevOps, DevSecOps, Dev Ops, ágil, lean, etc. Todo esto con el propósito de acelerar el tiempo de comercialización y acortar el ciclo de retroalimentación de los clientes porque la venta de aplicaciones que la gente quiere mientras se adapta al mercado en una cantidad de tiempo razonable es donde está el dinero. ¿Derecha?
Con esto, el enfoque se desplaza cada vez más hacia los desarrolladores y la entrega de las herramientas que necesitan, al tiempo que elimina la consideración de qué hardware o hipervisor se ejecuta el software ... siempre que sea rápido y puedan consumirlo sobre la marcha, hemos acertado la marca. Supongo que esta es la razón por la que a la mayoría de ellos les encantan las nubes, que les brindan todas las herramientas que necesitan y recursos ilimitados. Por supuesto, tampoco ven la factura que llega al final de cada mes.
Aquí es donde Erik Sterck GmbH se dio cuenta de que también debemos cambiar si queremos mantener el éxito.
Necesitábamos no solo hablar con los "chicos de la infraestructura", sino también hablar con los desarrolladores y comprender lo que quieren, cómo operan y cómo podemos hacerlos más exitosos. Aquí identificamos un cambio muy fuerte hacia el desarrollo basado en contenedores y las cargas de trabajo de aplicaciones, ya que esto proporciona la agilidad y la velocidad que los desarrolladores estaban buscando.
Esto también significa que una vez que la infraestructura basada en contenedores está en funcionamiento, los desarrolladores pueden consumirla sin tener que lidiar con el sistema operativo, el hipervisor o los silos de la infraestructura (los equipos multifuncionales también son una de esas nuevas palabras elegantes que vale la pena mencionar aquí). Sin embargo, esos silos de repente tuvieron que lidiar con un mundo completamente nuevo: proporcionar una infraestructura escalable basada en contenedores para desarrolladores y evaluadores, manteniéndola segura, actualizada y también manteniendo todas las nuevas herramientas requeridas. Esto es completamente diferente de lo que se requiere para el modelo de hipervisor / máquina virtual más tradicional y probablemente pueda adivinar cuántas personas experimentadas hay disponibles en este espacio.
Aquí es donde entra Erik Sterck GmbH. Desarrollamos una sólida asociación con Rancher Labs y utilizamos nuestra asociación existente con Nutanix para lanzar FramES 0.9, un producto basado en Nutanix CALM para implementar los clústeres de Rancher HA con solo hacer clic en un botón (desde un el punto de vista del cliente de todos modos). También desarrollamos nuestro propio “contenedor de gestión de ganaderos” interno para atender las operaciones del día 2 como la actualización de RKE o Rancher, todo esto para habilitar a los equipos más tradicionales y darles la herramienta para atender las nuevas demandas.
Una vez que se implementó el clúster de Rancher HA, los apoyamos en la configuración de plantillas, nodos y controladores CSI para que puedan implementar clústeres de Kubernetes según sea necesario. Bastante bien, ¿verdad? En cierto modo, todavía vimos muchos procesos manuales y a nadie le gustan, especialmente una vez que crece la base de clientes. Necesitábamos cambiar nuestra solución de las plantillas específicas del cliente, los marcos con un bloqueo de proveedor y las configuraciones estáticas, a un enfoque mucho más genérico que admita todas las plataformas y esté completamente controlado por variables.
Este fue el momento en el que nació FramES 1.0, o al menos la idea para ello.
Nos reunimos todos, cerramos la puerta con llave y decidimos encontrar una solución que resolviera todos nuestros problemas actuales ... después de mucha buena comida de panadería alemana, un almuerzo griego y unos litros de café, se nos ocurrió un camino a seguir.
Decidimos crear nuestro propio aparato. Al hacerlo, pudimos reutilizar los componentes existentes que nos gustaban y trabajamos, mientras que al mismo tiempo cambiamos las partes con las que no estábamos contentos. La idea era alejarse del marco actual y admitir múltiples plataformas usando Terraform para eliminar la administración de múltiples conjuntos de API y solo preocuparse por los proveedores de Terraform mantenidos por otros: ¡gane, gane! Creamos nuestro propio front y backend que se ejecutan en contenedores. Esto hace que el proceso de actualización sea muy sencillo. Cerramos un asistente de configuración en la parte superior del electrodoméstico y ¡nos fuimos! Ja, me gustaría ... escribir su propio dispositivo no es tan fácil como parece y tomó muchas pruebas con diferentes entornos de clientes antes de que tuviéramos una versión 1.0 estable, ¡pero llegamos allí!
Ahora estamos usando canalizaciones internas de GitLab para construir nuestros contenedores FramES en el cambio de código e incluso compilar el dispositivo automáticamente en las actualizaciones. La canalización luego publica la nueva versión en un servidor web para que esté disponible para su descarga. El dispositivo también es tan genérico que todos los clientes pueden descargar la misma versión y el asistente de configuración hace el resto de la configuración una vez que se ha importado el archivo OVA del dispositivo. Incluso logramos agregar soporte para cosas sofisticadas como proxies, CA raíz, repositorios, registros de Docker y más. Una vez configurada, toda la magia ocurre al hacer clic en "Iniciar FramES" y el cliente puede configurar las claves SSH y los proveedores que cargan dinámicamente todas las configuraciones específicas del punto final. ¡Unos pocos campos de entrada, menús desplegables y clics más y el cliente puede implementar un clúster Rancher HA completamente funcional!
Espere, se pone aún mejor: los clústeres de Rancher se pueden cargar y ajustar, y también implementamos operaciones del Día 2 como RKE o actualizaciones de Rancher, todo presionando un solo botón en la GUI.
Decidimos que esto no era suficiente porque nadie quiere administrar las plantillas del sistema operativo para los nodos de Rancher o Kubernetes. Quiero decir, ¿por qué lo harías? Parchear e iniciar sesión en Linux son cosa del pasado, ¿verdad? Cargamos automáticamente la última imagen de la nube de Linux que estamos usando en Nutanix Image Services o en la biblioteca de contenido de VMware, que se actualiza automáticamente a través del dispositivo cada dos semanas (no mencionemos los entornos del lado oscuro ... precargamos la imagen en el dispositivo, pero la actualización se vuelve un poco más complicado aquí). Esto garantiza que todos los clústeres de Kubernetes usen una imagen estándar que es probada por una comunidad bastante grande.
Y aquí estamos, FramES 1.0 ya se está ejecutando en dos clientes bastante grandes y los dos siguientes han programado su instalación. Nuestra hoja de ruta ... bueno, digamos que probablemente nos dure hasta mediados del próximo año. Trabajamos arduamente para mantenernos a la vanguardia del mercado y hacer evolucionar FramES de una manera que lo mantenga único.
También fue sorprendente ver cómo una pequeña empresa puede pasar de ser un revendedor a crear y administrar repentinamente su propio producto. ¡Yo llamaría a esto agilidad adecuada!
Para obtener más información, visite: https://www.eriksterck.de/it-infrastruktur/
Bio : Stefan Scharlott - Arquitecto de soluciones de DevOps y automatización
Linware Panamá ⯈