Esta es la primera de una serie de nuestras publicaciones dedicadas a mejoras y adiciones en la próxima actualización de la plataforma Red Hat OpenShift a la versión 4.0, que lo ayudará a prepararse para la transición a la nueva versión.
¿Qué herramientas puede tener a su disposición para crear mejores productos de software y cómo mejorarán la seguridad y harán que el desarrollo sea más fácil y confiable?
Desde el momento en que los representantes de la comunidad Kubernetes recién formada se reunieron por primera vez en el otoño de 2014 en la oficina de Google en Seattle, ya se podría decir que el proyecto Kubernetes estaba destinado a cambiar fundamentalmente los enfoques modernos para el desarrollo y la implementación de software. Al mismo tiempo, los proveedores de servicios de nube pública continuaron invirtiendo activamente en el desarrollo de infraestructura y servicios, lo que facilitó enormemente y simplificó el trabajo con TI y la creación de software, y los hizo increíblemente asequibles, lo que pocos podrían haber imaginado al comienzo de la década.
Por supuesto, el anuncio de cada nuevo servicio en la nube fue acompañado por numerosas discusiones de expertos en Twitter, y se mantuvieron disputas sobre una variedad de temas, incluido el final de la era del código abierto, el declive de la TI en el lado del cliente (TI local), 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.
Sin embargo, la realidad es que nada desaparece, y hoy se puede observar el crecimiento exponencial de los productos finales y los métodos de su desarrollo, que se asocia con la aparición constante de un nuevo software en nuestras vidas. Y a pesar del hecho de que todo a su alrededor cambiará, al mismo tiempo, en esencia, todo permanecerá sin cambios. Los desarrolladores de software continuarán escribiendo código con errores, los ingenieros de mantenimiento y los especialistas en confiabilidad continuarán caminando con los buscapersonas y recibirán alertas automáticas en Slack, los gerentes seguirán operando con los conceptos de OpEx y CapEx, y cada vez que ocurra una falla, el senior el desarrollador suspirará tristemente con las palabras: "dije" ...
Con la creciente complejidad de los proyectos, aparecen nuevos riesgos, y hoy la vida de las personas depende tanto del software que los desarrolladores simplemente están obligados a intentar hacer mejor su trabajo.
Kubernetes es una de esas herramientas. Se está trabajando para integrarlo con otras herramientas y servicios en una sola plataforma dentro del marco de Red Hat OpenShift, lo que haría que el software sea más confiable, fácil de administrar y seguro para los usuarios.
Dicho esto, surge la pregunta: ¿cómo hacer que trabajar con Kubernetes sea más fácil y más conveniente?La respuesta puede parecer sorprendentemente simple:
- Automatice momentos complejos cuando se implementa en la nube o fuera de la nube
- centrarse en la confiabilidad mientras se oculta la complejidad
- Continuar trabajando en el lanzamiento de actualizaciones simples y seguras
- lograr capacidad de control y auditoría;
- Esforzarse por proporcionar 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 implementan software a gran escala en las empresas más grandes del mundo. Además, es necesario tener en cuenta toda la experiencia acumulada de los ecosistemas abiertos que hoy forman la base del mundo moderno. En este caso, es necesario abandonar la vieja mentalidad de un desarrollador aficionado y pasar a una nueva filosofía de un futuro automatizado. Debería ser un "puente" entre las formas antiguas y nuevas de implementar software y hacer uso completo de toda la infraestructura disponible; no importa si es atendida por el proveedor de nube más grande o si se ejecuta en sistemas pequeños en la periferia.
¿Cómo lograr tal resultado?
En Red Hat, es costumbre realizar un trabajo aburrido y desagradecido 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 consta de una gran cantidad de desarrolladores talentosos que crean las cosas más extraordinarias: entretenidas, educativas, descubriendo nuevas oportunidades y simplemente hermosas, pero, por supuesto, nadie espera que todos los participantes se muevan en la misma dirección o persigan objetivos comunes. El uso de esta energía, su redireccionamiento en la dirección correcta, a veces es necesario para el desarrollo de áreas que serían útiles para 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 opiniones similares sobre el futuro: un enfoque de código abierto más seguro y confiable. La compañía trabajó en el desarrollo de estas ideas y su implementación, implementando nuestra filosofía, tratando de lograr la operación segura de todo el software. Todo este trabajo se basa en Kubernetes, Linux, nubes públicas, nubes privadas y los miles de otros proyectos que subyacen a nuestro ecosistema digital moderno.
La nueva versión de OpenShift 4 será comprensible, 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 la infraestructura y, por supuesto, contenedores (que son esencialmente imágenes de Linux).
La plataforma debe estar segura desde el principio, pero al mismo tiempo ofrecer la posibilidad de iteraciones convenientes para los desarrolladores, es decir, tener suficiente flexibilidad y confiabilidad, al tiempo que permite a los administradores auditar y facilitar la administración.
Debería permitirle ejecutar el software "en forma de servicio" y no conducir a una expansión incontrolada de la infraestructura para los operadores.
Permitirá a los desarrolladores centrarse en crear productos reales para usuarios y clientes. No es necesario atravesar la jungla de configuraciones de hardware y software, y todas las complicaciones aleatorias serán cosa del pasado.
OpenShift 4: la plataforma NoOps no requiere mantenimiento
Esta publicación describió las tareas que ayudaron a dar forma a la visión de la compañía para OpenShift 4. El equipo tiene la tarea de simplificar al máximo las tareas diarias de operación y mantenimiento de software, haciendo que estos procesos sean fáciles y sin esfuerzo, tanto para especialistas en implementación como para desarrolladores Pero, ¿cómo puede uno acercarse a este objetivo? ¿Cómo crear una plataforma para lanzar software que requiera una intervención mínima? ¿Qué significa NoOps en este contexto?
Si intenta ignorarlo, para los desarrolladores, los conceptos de "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 implemente software; deje que un proveedor haga esto en su lugar.
- No debe comenzar de inmediato la creación de un gran marco: comience escribiendo pequeños fragmentos que actúen como "bloques de construcción", intente hacer que este código funcione con datos y eventos, y no con discos y bases de datos.
La tarea, como antes, es acelerar las iteraciones en el desarrollo de software, proporcionar una oportunidad para crear mejores productos y para que el desarrollador no pueda preocuparse por los sistemas en los que se ejecuta su software. Un desarrollador experimentado es consciente de que si se enfoca en los usuarios, la imagen puede cambiar rápidamente, por lo que no debe esforzarse demasiado en escribir software si no tiene absoluta confianza en su necesidad.
Para los profesionales involucrados en el mantenimiento y la operación, la palabra "NoOps" puede sonar algo intimidante. Pero al comunicarse con los ingenieros de operaciones, se hace evidente que los patrones y métodos utilizados por ellos para garantizar la confiabilidad de la confiabilidad (Site Reliability Engineering, SRE) tienen mucho en común con los patrones descritos anteriormente:
- No gestione sistemas: automatice sus procesos de gestión.
- No implemente software: cree una canalización para su implementación.
- Intente no combinar todos sus servicios y no permita que la falla de uno de ellos conduzca a la falla de todo el sistema: dispersarlos por toda la infraestructura utilizando herramientas de automatización y conectarlos, brindando la posibilidad de control y monitoreo.
Los especialistas en SRE saben que algo puede salir mal y tendrán que rastrear y solucionar el problema; por lo tanto, automatizan la rutina y determinan por adelantado las tolerancias de error para estar listos para priorizar y tomar decisiones cuando se produce un problema. .
Kubernetes de OpenShift es una plataforma diseñada para resolver dos tareas principales: en lugar de obligarlo a manejar máquinas virtuales o API de equilibrador de carga, trabajar con abstracciones de orden superior, con 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, use las herramientas que ya están disponibles en la plataforma. Por lo tanto, el ingrediente secreto de OpenShift 4 realmente no representa ningún secreto: solo necesita tomar los principios de SRE y los conceptos sin servidor como base, y llevarlos a su conclusión lógica, para ayudar a los desarrolladores e ingenieros de mantenimiento:
- Automatizar y estandarizar la infraestructura utilizada por las aplicaciones.
- Reúna los procesos de implementación y desarrollo sin limitar a los propios desarrolladores.
- Garantizar que el lanzamiento, la auditoría y la seguridad de un centésimo servicio, función, aplicación o pila completa no sea más difícil que el primero.
Pero, ¿cuál es la diferencia entre la plataforma OpenShift 4 y sus predecesoras y el enfoque "estándar" para resolver tales problemas? ¿Cómo se logra el escalado para los equipos de implementación y operación? Debido al hecho de que el rey en esta situación es un grupo. Entonces
- Hacemos que el propósito de los grupos sea comprensible (Querida nube, levanté este grupo porque pude)
- Existen máquinas y sistemas operativos para servir al clúster (Su Majestad)
- Administre el estado de los hosts desde el clúster, minimice su reconstrucción (deriva).
- Para cada elemento importante del sistema, se necesita una niñera (mecanismo) que rastree y solucione problemas
- Falla * de cada * aspecto o elemento del sistema; los mecanismos de recuperación correspondientes son una parte ordinaria de la vida
- Toda la infraestructura debe configurarse a través de la API.
- Usa Kubernetes para lanzar Kubernetes. (Sí, sí, esto no es un error tipográfico)
- Las actualizaciones deben instalarse fácil y naturalmente. Si se necesita más de un clic para instalar la actualización, entonces obviamente \ estamos haciendo algo mal.
- El monitoreo y la depuración de cualquier componente no deberían ser un problema y, en consecuencia, el seguimiento y la generación de informes en toda la infraestructura también deberían ser simples y convenientes.
¿Quieres 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 de AWS sobre Red Had CoreOS. Para usar la versión de vista previa, solo necesita una cuenta de AWS para proporcionar la infraestructura y un conjunto de cuentas para acceder a las imágenes de la versión de vista previa.
- Para comenzar, vaya a try.openshift.com 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 de
capacitación de OpenShift para obtener una comprensión más profunda de los sistemas y conceptos que hacen de la plataforma OpenShift 4 una herramienta tan simple y conveniente para lanzar Kubernetes.
Y en la conferencia DevOpsForum 2019 , uno de los desarrolladores de OpenShift, Vadim Rutkovsky, impartirá una clase magistral "Aquí debe cambiar todo el sistema: reparar grupos de k8s rotos junto con cerrajeros certificados": romperá diez grupos y mostrará cómo repararlos.La entrada a la conferencia se paga, pero utilizando el código de promoción #RedHat: 37% de descuento.
Te esperamos el 20 de abril en una clase magistral en el Pabellón # 2 a las 17:15, y en nuestro stand, todo el día. Información útil del producto, reuniones con expertos, camisetas, sombreros, calcomanías de Red Hat: ¡todo está como siempre! :-)