Esta es la primera de una serie de publicaciones sobre los cambios, mejoras y adiciones en la próxima actualización de la plataforma Red Hat OpenShift 4.0 que lo ayudarán a prepararse para la transición a la nueva versión.
Desde el momento en que la incipiente comunidad de Kubernetes se reunió por primera vez en la oficina de Google en Seattle en el otoño de 2014, quedó claro que el proyecto Kubernetes estaba destinado a revolucionar la forma en que se desarrolla e implementa el software en la actualidad. Al mismo tiempo, los proveedores de servicios de nube pública continuaron invirtiendo activamente en el desarrollo de infraestructura y servicios, lo que hizo que trabajar con TI y crear software fuera mucho más fácil y accesible, y los hizo increíblemente accesibles, lo que pocos podrían haber imaginado al comienzo de la década.
Por supuesto, el anuncio de cada nuevo servicio en la nube estuvo acompañado de numerosas discusiones entre expertos en Twitter, y se llevaron a cabo debates sobre una variedad de temas, incluido el fin de la era del código abierto, el declive de la TI local y la inevitabilidad. de un nuevo monopolio de software en la nube, y cómo el nuevo paradigma X reemplazará a todos los demás paradigmas.
No hace falta decir que todas estas disputas fueron muy estúpidas.
La realidad es que nada va a desaparecer, y hoy podemos ver un crecimiento exponencial en los productos finales y la forma en que se desarrollan, debido a la constante aparición de nuevo software en nuestras vidas. Y a pesar de que todo lo que nos rodea cambiará, al mismo tiempo, en esencia, todo permanecerá sin cambios. Los desarrolladores de software seguirán escribiendo códigos con errores, los ingenieros de operaciones y los especialistas en confiabilidad seguirán caminando con buscapersonas y recibiendo alertas automáticas en Slack, los gerentes seguirán operando en términos de OpEx y CapEx, y cada vez que ocurra una falla, el senior del desarrollador suspiro tristemente con las palabras: “Te lo dije”...
Ah, de verdad debe ser discutido, es qué herramientas podemos tener a nuestra disposición para crear mejores productos de software y cómo pueden mejorar la seguridad y hacer que el desarrollo sea más fácil y confiable. A medida que los proyectos se vuelven más complejos, surgen nuevos riesgos y hoy en día la vida de las personas depende tanto del software que los desarrolladores simplemente tienen que intentar hacer mejor su trabajo.
Kubernetes es una de esas herramientas. Se está trabajando para combinar Red Hat OpenShift con otras herramientas y servicios en una única plataforma que haría que el software sea más confiable, más fácil de administrar y más seguro para los usuarios.
Dicho esto, el equipo de OpenShift hace una pregunta sencilla:
¿Cómo puedes hacer que trabajar con Kubernetes sea más fácil y conveniente?
La respuesta es sorprendentemente obvia:
- automatizar aspectos complejos de la implementación en la nube o fuera de la nube;
- centrarse en la confiabilidad y ocultar la complejidad;
- continuar trabajando continuamente para publicar actualizaciones simples y seguras;
- lograr controlabilidad y auditabilidad;
- Esfuércese por garantizar inicialmente una alta seguridad, pero no a expensas de la usabilidad.
El próximo lanzamiento de OpenShift debería tener en cuenta tanto la experiencia de los creadores como la experiencia de otros desarrolladores que están implementando software a gran escala en las empresas más grandes del mundo. Además, debe tener en cuenta toda la experiencia acumulada de los ecosistemas abiertos que subyacen al mundo moderno actual. Al mismo tiempo, es necesario abandonar la vieja mentalidad del desarrollador aficionado y pasar a una nueva filosofía de futuro automatizado. Necesita cerrar la brecha entre las formas antiguas y nuevas de implementar software y aprovechar al máximo toda la infraestructura disponible, ya sea alojada en el proveedor de nube más grande o ejecutándose en sistemas pequeños en el borde.
¿Cómo lograr este resultado?
En Red Hat es costumbre realizar trabajos aburridos e ingratos durante mucho tiempo para preservar la comunidad establecida y evitar el cierre de proyectos en los que participa la empresa. La comunidad de código abierto contiene una gran cantidad de desarrolladores talentosos que crean las cosas más extraordinarias: entretenidas, educativas, que abren nuevas oportunidades y simplemente hermosas, pero, por supuesto, nadie espera que todos avancen en la misma dirección o persigan objetivos comunes. . A veces es necesario aprovechar esta energía y redirigirla en la dirección correcta para desarrollar áreas que beneficiarían a nuestros usuarios, pero al mismo tiempo debemos monitorear el desarrollo de nuestras comunidades y aprender de ellas.
A principios de 2018, Red Hat adquirió el proyecto CoreOS, que tenía visiones similares sobre el futuro: más seguro y confiable, creado según principios de código abierto. La empresa ha trabajado para seguir desarrollando estas ideas e implementarlas, poniendo en práctica nuestra filosofía: intentar garantizar que todo el software funcione de forma segura. Todo este trabajo se basa en Kubernetes, Linux, nubes públicas, nubes privadas y miles de otros proyectos que sustentan nuestro ecosistema digital moderno.
La nueva versión de OpenShift 4 será clara, automatizada y más natural
La plataforma OpenShift funcionará con los mejores y más confiables sistemas operativos Linux, con soporte de hardware básico, virtualización conveniente, programación automática de infraestructura y, por supuesto, contenedores (que son esencialmente solo imágenes de Linux).
La plataforma debe ser segura desde el principio, pero aún así permitir a los desarrolladores iterar fácilmente, es decir, ser lo suficientemente flexible y segura y al mismo tiempo permitir a los administradores auditarla y administrarla fácilmente.
Debería permitir que el software se ejecute “como un servicio” y no dar lugar a un crecimiento inmanejable de la infraestructura para los operadores.
Permitirá a los desarrolladores centrarse en la creación de productos reales para usuarios y clientes. No tendrá que atravesar la jungla de configuraciones de hardware y software, y todas las complicaciones accidentales serán cosa del pasado.
OpenShift 4: plataforma NoOps que no requiere mantenimiento
В describió aquellas tareas que ayudaron a dar forma a la visión de la empresa para OpenShift 4. El objetivo del equipo es simplificar las tareas diarias de operación y mantenimiento del software tanto como sea posible, para que estos procesos sean fáciles y relajados, tanto para los especialistas involucrados en la implementación como para los desarrolladores. Pero, ¿cómo puedes acercarte a este objetivo? ¿Cómo crear una plataforma para ejecutar software que requiera una mínima intervención? ¿Qué significa NoOps en este contexto?
Si intenta abstraerse, para los desarrolladores los conceptos "sin servidor" o "NoOps" significan herramientas y servicios que le permiten ocultar el componente "operativo" o minimizar esta carga para el desarrollador.
- No trabaje con sistemas, sino con interfaces de aplicaciones (API).
- No se moleste en implementar software: deje que el proveedor lo haga por usted.
- No se lance a crear un marco grande de inmediato; comience escribiendo piezas pequeñas que actuarán como "bloques de construcción", intente que este código funcione con datos y eventos, y no con discos y bases de datos.
El objetivo, como antes, es acelerar las iteraciones en el desarrollo de software, brindar la oportunidad de crear mejores productos y que el desarrollador no tenga que preocuparse por los sistemas en los que se ejecuta su software. Un desarrollador experimentado es muy consciente de que centrarse en los usuarios puede cambiar rápidamente la imagen, por lo que no debería esforzarse demasiado en escribir software a menos que esté absolutamente seguro de que es necesario.
Para los profesionales de mantenimiento y operaciones, la palabra "NoOps" puede parecer un poco aterradora. Pero al comunicarse con los ingenieros de campo, resulta obvio que los patrones y técnicas que utilizan para garantizar la confiabilidad y la confiabilidad (Site Reliability Engineering, SRE) tienen muchas similitudes con los patrones descritos anteriormente:
- No gestione sistemas: automatice sus procesos de gestión.
- No implemente software: cree una canalización para implementarlo.
- Evite agrupar todos sus servicios y permitir que la falla de uno provoque la falla de todo el sistema; distribúyalos en toda su infraestructura utilizando herramientas de automatización y conéctelos de manera que puedan monitorearse y monitorearse.
Los SRE saben que algo puede salir mal y tendrán que localizar y solucionar el problema, por lo que automatizan el trabajo de rutina y establecen presupuestos de errores con anticipación para estar listos para priorizar y tomar decisiones cuando surge un problema.
Kubernetes en OpenShift es una plataforma diseñada para resolver dos problemas principales: en lugar de obligarlo a comprender las máquinas virtuales o las API del equilibrador de carga, funciona con abstracciones de orden superior: procesos y servicios de implementación. En lugar de instalar agentes de software, puede ejecutar contenedores y, en lugar de escribir su propia pila de monitoreo, utilizar las herramientas que ya están disponibles en la plataforma. Entonces, la salsa secreta de OpenShift 4 realmente no es ningún secreto: es solo una cuestión de tomar los principios de SRE y los conceptos sin servidor y llevarlos a su conclusión lógica para ayudar a los desarrolladores e ingenieros de operaciones:
- Automatizar y estandarizar la infraestructura que utilizan las aplicaciones
- Vincular los procesos de implementación y desarrollo sin restringir a los propios desarrolladores
- Garantizar que lanzar, auditar y proteger el servicio, característica, aplicación o pila completa número XNUMX no sea más difícil que el primero.
Pero, ¿cuál es la diferencia entre la plataforma OpenShift 4 y sus predecesoras y con el enfoque "estándar" para resolver este tipo de problemas? ¿Qué impulsa la escala para los equipos de implementación y operaciones? Debido al hecho de que el rey en esta situación es el racimo. Entonces,
- Nos aseguramos de que el propósito de los clusters sea claro (Querida nube, elegí este cluster porque pude)
- Las máquinas y los sistemas operativos existen para servir al clúster (Su Majestad)
- Administre el estado de los hosts del clúster, minimice su reconstrucción (deriva).
- Para cada elemento importante del sistema, se necesita una niñera (mecanismo) que monitoreará y eliminará los problemas.
- La falla de *cada* aspecto o elemento de un sistema y los mecanismos de recuperación asociados son una parte normal de la vida.
- Toda la infraestructura debe configurarse vía API.
- Utilice Kubernetes para ejecutar Kubernetes. (Sí, sí, eso no es un error tipográfico)
- Las actualizaciones deben ser fáciles y sin complicaciones de instalar. Si se necesita más de un clic para instalar una actualización, es evidente que algo estamos haciendo mal.
- Monitorear y depurar cualquier componente no debería ser un problema y, por lo tanto, rastrear y generar informes en toda la infraestructura también debería ser fácil y conveniente.
¿Quiere ver las capacidades de la plataforma en acción?
Una versión preliminar de OpenShift 4 está disponible para los desarrolladores. Con un instalador fácil de usar, puede ejecutar un clúster en AWS sobre Red Had CoreOS. Para utilizar la vista previa, solo necesita una cuenta de AWS para aprovisionar la infraestructura y un conjunto de cuentas para acceder a las imágenes de vista previa.
- Para comenzar, vaya a y haga clic en "Comenzar".
- Inicie sesión en su cuenta de Red Hat (o cree una nueva) y siga las instrucciones para configurar su primer clúster.
Después de una instalación exitosa, consulte nuestros tutoriales. para obtener una comprensión más profunda de los sistemas y conceptos que hacen de la plataforma OpenShift 4 una forma tan fácil y conveniente de ejecutar Kubernetes.
Pruebe la nueva versión de OpenShift y comparta su opinión. Estamos comprometidos a hacer que trabajar con Kumbernetes sea lo más accesible y sencillo posible: el futuro de NoOps comienza hoy.
Y ahora atención!
En la conferencia El 20 de abril, uno de los desarrolladores de OpenShift, Vadim Rutkovsky, impartirá una clase magistral: romperá diez clústeres y los obligará a repararlos. La conferencia es paga, pero con el código promocional #RedHat obtienes un 37% de descuento
Clase magistral de 17:15 a 18:15 y el stand está abierto todo el día. Camisetas, gorras, pegatinas: ¡lo de siempre!
Salón #2
"Aquí es necesario cambiar todo el sistema: reparamos los grupos k8 rotos junto con mecánicos certificados".
Fuente: habr.com