Esta es la primera publicación de una serie de materiales dedicados a los cambios, mejoras y adiciones en la próxima actualización de la plataforma Red Hat OpenShift a 4.0, que ayudarán a prepararse para la transición a la nueva versión.
Desde el momento en que los representantes de la comunidad de Kubernetes, aún en formación, se reunieron por primera vez en otoño de 2014 en la oficina de Google en Seattle, ya se podía predecir que el proyecto Kubernetes estaba destinado a cambiar radicalmente los enfoques modernos para el desarrollo y la implementación de software. Al mismo tiempo, los proveedores públicos de servicios en la nube continuaron invirtiendo activamente en el desarrollo de la infraestructura y los servicios, lo que facilitó y simplificó significativamente el trabajo con TI y la creación de software, haciéndolos increíblemente accesibles, algo que pocos habrían imaginado a comienzos de la década.
Por supuesto, el anuncio de cada nuevo servicio en la nube fue acompañado de numerosas discusiones entre expertos en Twitter, con debates sobre una variedad de temas, incluidos el fin de la era del código abierto, el ocaso de TI del lado del cliente (on-premises IT), la inevitabilidad de un nuevo monopolio de software en la nube y cómo un nuevo paradigma X reemplazará a todos los demás.
No hace falta decir que todas estas discusiones fueron bastante estúpidas.
La realidad es que nada se pierde y hoy en día se puede observar un crecimiento exponencial en los productos finales y en las formas de desarrollarlos, lo cual está relacionado con la aparición constante de nuevo software en nuestras vidas. Y a pesar de que todo a nuestro alrededor va a cambiar, en esencia, todo seguirá siendo igual. Los desarrolladores de software seguirán escribiendo código con errores, los ingenieros de operaciones y especialistas en fiabilidad seguirán utilizando pagers y recibiendo alertas automáticas en Slack, los gerentes seguirán operando con los conceptos de OpEx y CapEx, y cada vez que ocurra un fallo, un desarrollador senior suspirará con tristeza diciendo: 'Yo lo dije...'
Lo que realmente debería discutirse, así que son las herramientas que podemos tener a nuestra disposición para crear productos de software de mayor calidad, y cómo nos permiten aumentar la seguridad y hacer que el desarrollo sea más fácil y confiable. Con el aumento de la complejidad de los proyectos también surgen nuevos riesgos, y hoy las vidas de las personas dependen tanto del software que los desarrolladores deben esforzarse por hacer su trabajo mejor.
Kubernetes es una de esas herramientas. Se está trabajando para integrar en Red Hat OpenShift con otras herramientas y servicios en una única plataforma que permita que el software sea más confiable, fácil de gestionar y seguro para los usuarios.
Con lo dicho, el equipo de OpenShift se hace una simple pregunta:
¿Cómo podemos hacer que trabajar con Kubernetes sea más fácil y conveniente?
La respuesta es sorprendentemente obvia:
- automatizar los aspectos complejos del despliegue en la nube o fuera de ella;
- focalizarse en la fiabilidad, ocultando la complejidad;
- continuar trabajando constantemente en la emisión de actualizaciones simples y seguras;
- lograr control y capacidad de auditoría;
- procurar garantizar alta seguridad desde el principio, pero sin sacrificar la usabilidad.
La próxima versión de OpenShift debe tener en cuenta tanto la experiencia de los creadores como la de otros desarrolladores que implementan software a gran escala en las empresas más grandes del mundo. Además, debe considerar toda la experiencia acumulada de los ecosistemas abiertos que hoy sustentan el mundo moderno. Al mismo tiempo, es necesario renunciar a la mentalidad de desarrollador aficionado anterior y adoptar una nueva filosofía de futuro automatizado. Debe ser un 'puente' entre las antiguas y nuevas formas de desplegar software y aprovechar plenamente toda la infraestructura disponible, sin importar si es atendida por un gran proveedor de nube o ejecutada en diminutos sistemas periféricos.
¿Cómo lograr tal resultado?
En Red Hat es habitual realizar trabajos tediosos y a menudo ingratos durante largo tiempo con el fin de mantener la comunidad establecida y evitar el cierre de proyectos en los que la empresa participa. En la comunidad de código abierto hay una gran cantidad de desarrolladores talentosos que crean cosas extraordinarias: entretenidas, educativas, que abren nuevas oportunidades y simplemente bellas. Sin embargo, por supuesto, nadie espera que todos los participantes avancen en la misma dirección o persigan objetivos comunes. A veces es necesario utilizar esta energía y redirigirla hacia caminos que puedan ser útiles para nuestros usuarios, pero al mismo tiempo debemos estar atentos al desarrollo de nuestras comunidades y aprender de ellas.
A principios de 2018, Red Hat adquirió el proyecto CoreOS, que compartía visiones similares sobre el futuro: un entorno más seguro y confiable, creado sobre principios de código abierto. La empresa trabajó en el desarrollo posterior de estas ideas y su implementación, dando vida a nuestra filosofía: esforzándose por lograr un funcionamiento seguro de todo el software. Todo este trabajo se basa en Kubernetes, Linux, nubes públicas, nubes privadas y miles de otros proyectos que constituyen nuestra moderna ecosistema digital.
La nueva versión de OpenShift 4 será comprensible, automatizada y más intuitiva.
La plataforma OpenShift funcionará con los sistemas operativos Linux más eficientes y confiables, con soporte de hardware bare-metal, virtualización conveniente, programación automática de infraestructura y, por supuesto, contenedores (que son, en esencia, solo imágenes de Linux).
La plataforma debe ser segura desde el principio, pero también permitir iteraciones cómodas para los desarrolladores, lo que significa que debe tener suficiente flexibilidad y confiabilidad, a la vez que permite a los administradores realizar auditorías y mantener la facilidad de gestión.
Debe permitir la ejecución de software 'como servicio' y no conducir a un crecimiento descontrolado de la infraestructura para los operadores.
Esto permitirá a los desarrolladores concentrarse en crear productos reales para los usuarios y clientes. No tendrán que lidiar con un sinfín de configuraciones de hardware y software, y todas las complicaciones inesperadas quedarán atrás.
OpenShift 4: Plataforma NoOps que no requiere mantenimiento
En se describieron las tareas que ayudaron a configurar la visión de la empresa respecto a OpenShift 4. El equipo tiene como objetivo simplificar al máximo las tareas cotidianas de operación y mantenimiento del software, haciendo que estos procesos sean sencillos y fluidos, tanto para los especialistas en implementación como para los desarrolladores. Pero, ¿cómo se puede acercar a este objetivo? ¿Cómo crear una plataforma para ejecutar software que requiera la mínima intervención? ¿Qué significa realmente NoOps en este contexto?
Si tratamos de abstraernos, para los desarrolladores los conceptos de «serverless» o «NoOps» significan herramientas y servicios que permiten ocultar el componente de «operación» o minimizar esta carga para el desarrollador.
- Trabaja no con sistemas, sino con interfaces de programación (API).
- No te ocupes de la implementación del software; deja que el proveedor lo haga por ti.
- No intentes crear de inmediato un gran marco; comienza escribiendo fragmentos pequeños que actúen como «bloques de construcción», tratando de que este código trabaje con datos y eventos, y no con discos y bases de datos.
La tarea, como antes, consiste en acelerar las iteraciones en el desarrollo de software, garantizar la capacidad de crear productos de mayor calidad y permitir que el desarrollador no se preocupe por los sistemas en los que se ejecuta su software. Un desarrollador experimentado entiende que si se concentra en los usuarios, la situación puede cambiar rápidamente, por lo que no debe invertir demasiados esfuerzos en escribir software si no tienes una confianza absoluta en su necesidad.
Para los especialistas encargados del soporte 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 metodologías que utilizan para garantizar la fiabilidad (Site Reliability Engineering, SRE) a menudo resuenan con los patrones descritos anteriormente.
- No gestione los sistemas, automatice los procesos de gestión.
- No se dedique a implementar software, cree un pipeline para su despliegue.
- Intente no agrupar todos sus servicios y evite que la falla de uno de ellos provoque la falla de todo el sistema: distribuya estos servicios por toda la infraestructura utilizando herramientas de automatización y conéctelos, asegurando la posibilidad de control y monitoreo.
Los especialistas en SRE saben que algo puede salir mal y que deberán rastrear y resolver problemas, por lo que automatizan el trabajo rutinario y definen de antemano los márgenes de error (error budgets) para estar listos para priorizar y tomar decisiones cuando surja un problema.
Kubernetes en OpenShift es una plataforma diseñada para abordar dos tareas principales: en lugar de obligarlo a lidiar con máquinas virtuales o API de equilibradores de carga, se trabaja con abstracciones de mayor nivel: procesos de despliegue y servicios. En lugar de instalar agentes de software, se pueden ejecutar contenedores, y en lugar de crear su propia pila de monitoreo, se pueden utilizar las herramientas ya disponibles en la plataforma. Así, el ingrediente secreto de OpenShift 4 no es en realidad un misterio: simplemente hay que basarse en los principios de SRE y conceptos sin servidor, y llevarlos a su culminación, en apoyo a desarrolladores e ingenieros de operaciones.
- Automatizar y estandarizar la infraestructura utilizada por las aplicaciones.
- Unir los procesos de despliegue y desarrollo sin restringir a los propios desarrolladores.
- Lograr que el lanzamiento, auditoría y aseguramiento de la seguridad del centésimo servicio, función, aplicación o pila completa no sea más complicado que el primero.
¿Pero en qué se diferencia la plataforma OpenShift 4 de sus predecesoras y del enfoque "convencional" para abordar problemas similares? ¿Cómo se logra la escalabilidad para los equipos que se encargan de su implementación y operación? La respuesta es que aquí, el rey es el clúster. Así que,
- Hagamos que la finalidad de los clústeres sea clara (Querido cloud, levanté este clúster porque pude)
- Las máquinas y los sistemas operativos existen para servir al clúster (Su Majestad)
- Administra el estado de los hosts desde el clúster y minimiza su deriva.
- Para cada elemento crítico del sistema se necesita un cuidador (mecanismo) que supervise y solucione problemas.
- La falla de *cada* aspecto o elemento del sistema requiere que los mecanismos de recuperación actúen; esto es parte de la rutina.
- Toda la infraestructura debe configurarse a través de API.
- Usa Kubernetes para ejecutar Kubernetes. (Sí, no es un error tipográfico)
- Las actualizaciones deben instalarse de manera sencilla y fluida. Si se necesita más de un clic del ratón para instalar una actualización, evidentemente, algo no estamos haciendo bien.
- La monitorización y depuración de cualquier componente no deberían ser un problema, y por ende, rastrear y reportar sobre toda la infraestructura también debe ser simple y accesible.
¿Quieres ver las capacidades de la plataforma en acción?
La versión preliminar de OpenShift 4 ya está disponible para desarrolladores. Con un instalador fácil de usar, puedes iniciar un clúster en AWS sobre Red Hat CoreOS. Solo necesitas una cuenta de AWS para proveer la infraestructura y un conjunto de cuentas para acceder a las imágenes de la versión preliminar.
- Para comenzar, dirígete a y haz clic en “Get Started”.
- Inicia sesión en tu cuenta de Red Hat (o crea una nueva) y sigue las instrucciones para configurar tu primer clúster.
Una vez que la instalación sea exitosa, consulta nuestros materiales de capacitación , para obtener una visión más profunda de los sistemas y conceptos que hacen de la plataforma OpenShift 4 una herramienta tan simple y accesible para ejecutar Kubernetes.
Prueba la nueva versión de OpenShift y comparte tu opinión. Nos esforzamos por hacer que trabajar con Kubernetes sea lo más accesible y sin esfuerzo posible: el futuro de NoOps comienza hoy.
¡Ahora atención!
En la conferencia El 20 de abril, uno de los desarrolladores de OpenShift, Vadim Rutkovski, realizará un taller: romperá diez clústeres y nos guiara en su reparación. La entrada es de pago, pero con el código promocional #RedHat obtienes un 37% de descuento.
El taller será de 17:15 a 18:15, y el stand estará abierto todo el día. ¡Camisetas, gorras, calcomanías — como de costumbre!
Sala #2
«Aquí hay que cambiar todo el sistema: arreglamos clústeres k8s rotos junto con cerrajeros certificados».
Fuente: habr.com
