Esta é a primeira dunha serie de publicacións sobre os cambios, melloras e engadidos na próxima actualización 4.0 da plataforma Red Hat OpenShift que che axudará a prepararte para a transición á nova versión.
Desde o momento no que a nova comunidade de Kubernetes se reuniu na oficina de Google en Seattle no outono de 2014, estaba claro que o proxecto Kubernetes estaba destinado a revolucionar a forma en que se desenvolve e se implanta o software na actualidade. Ao mesmo tempo, os provedores públicos de servizos na nube continuaron investindo activamente no desenvolvemento de infraestruturas e servizos, o que fixo que traballar con TI e a creación de software fose moito máis fácil e accesible, e facíaos incriblemente accesibles, cousa que poucos poderían imaxinar a principios de a década.
Por suposto, o anuncio de cada novo servizo na nube estivo acompañado de numerosas discusións entre expertos en Twitter e realizáronse debates sobre unha variedade de temas, incluído o final da era do código aberto, o declive da TI local e a inevitabilidade. dun novo monopolio de software na nube, e como o novo paradigma X substituirá a todos os outros paradigmas.
Nin que dicir ten que todas estas disputas foron moi estúpidas
A realidade é que nada vai desaparecer, e hoxe podemos ver un crecemento exponencial dos produtos finais e da forma en que se desenvolven, debido á constante aparición de novo software nas nosas vidas. E a pesar de que todo cambiará ao seu redor, ao mesmo tempo, en esencia, todo permanecerá inalterado. Os desenvolvedores de software seguirán escribindo código con erros, os enxeñeiros de operacións e os especialistas en fiabilidade seguirán camiñando con buscapersonas e recibirán alertas automáticas en Slack, os xestores seguirán operando en termos de OpEx e CapEx, e cada vez que se produza un fallo, o programador será maior. suspira tristemente coas palabras: "Eu díxencho"...
de veras debe ser discutido, é as ferramentas que podemos ter á nosa disposición para crear mellores produtos de software, e como poden mellorar a seguridade e facer que o desenvolvemento sexa máis fácil e fiable. A medida que aumenta a complexidade do proxecto, tamén aumentan os novos riscos, e hoxe a vida das persoas depende tanto do software que os desenvolvedores simplemente teñen que tentar facer mellor o seu traballo.
Kubernetes é unha destas ferramentas. Estase traballando para combinar Red Hat OpenShift con outras ferramentas e servizos nunha única plataforma que faría o software máis fiable, máis fácil de xestionar e máis seguro para os usuarios.
Dito isto, o equipo de OpenShift fai unha simple pregunta:
Como podes facer que traballar con Kubernetes sexa máis sinxelo e cómodo?
A resposta é sorprendentemente obvia:
- automatizar aspectos complexos da implantación na nube ou fóra da nube;
- céntrase na fiabilidade mentres oculta a complexidade;
- seguir traballando continuamente para lanzar actualizacións sinxelas e seguras;
- conseguir controlabilidade e auditabilidade;
- esforzarse por garantir inicialmente unha alta seguridade, pero non a costa da usabilidade.
A próxima versión de OpenShift debería ter en conta tanto a experiencia dos creadores como a experiencia doutros desenvolvedores que están implementando software a gran escala nas empresas máis grandes do mundo. Ademais, debe ter en conta toda a experiencia acumulada dos ecosistemas abertos que subxace ao mundo moderno actual. Ao mesmo tempo, é necesario abandonar a vella mentalidade do desenvolvedor afeccionado e pasar a unha nova filosofía dun futuro automatizado. Necesita salvar a brecha entre as antigas e as novas formas de implementar software e aproveitar ao máximo toda a infraestrutura dispoñible, xa sexa aloxada polo maior provedor de nube ou funcionando en pequenos sistemas na periferia.
Como conseguir este resultado?
En Red Hat adoita facer un traballo aburrido e ingrato durante moito tempo para preservar a comunidade establecida e evitar o peche dos proxectos nos que participa a empresa. A comunidade de código aberto contén un gran número de desenvolvedores talentosos que crean as cousas máis extraordinarias: entretidas, educativas, que abren novas oportunidades e simplemente fermosas, pero, por suposto, ninguén espera que todos se movan na mesma dirección ou persigan obxectivos comúns. . Aproveitar esta enerxía e redirixila na dirección correcta ás veces é necesario para desenvolver áreas que beneficiarían aos nosos usuarios, pero ao mesmo tempo debemos supervisar o desenvolvemento das nosas comunidades e aprender delas.
A principios de 2018, Red Hat adquiriu o proxecto CoreOS, que tiña visións similares sobre o futuro: máis seguro e fiable, creado con principios de código aberto. A compañía traballou para desenvolver aínda máis estas ideas e implementalas, poñendo en práctica a nosa filosofía: intentando garantir que todo o software funcione de forma segura. Todo este traballo está construído en Kubernetes, Linux, nubes públicas, nubes privadas e outros miles de proxectos que sustentan o noso ecosistema dixital moderno.
A nova versión de OpenShift 4 será clara, automatizada e máis natural
A plataforma OpenShift funcionará cos mellores e máis fiables sistemas operativos Linux, con soporte de hardware simple, virtualización cómoda, programación automática de infraestruturas e, por suposto, contedores (que son esencialmente só imaxes de Linux).
A plataforma debe ser segura desde o principio, pero aínda así permitir que os desenvolvedores poidan iterar facilmente, é dicir, ser o suficientemente flexible e segura mentres permite aos administradores auditala e xestionala facilmente.
Debería permitir que o software se execute "como un servizo" e non levar a un crecemento incontrolable da infraestrutura para os operadores.
Permitirá aos desenvolvedores centrarse na creación de produtos reais para usuarios e clientes. Non terás que atravesar a selva de configuracións de hardware e software, e todas as complicacións accidentais serán cousa do pasado.
OpenShift 4: plataforma NoOps que non require mantemento
В describiu aquelas tarefas que axudaron a dar forma á visión da empresa para OpenShift 4. O obxectivo do equipo é simplificar o máximo posible as tarefas diarias de operación e mantemento do software, para que estes procesos sexan sinxelos e relaxados, tanto para os especialistas implicados na implementación como para os desenvolvedores. Pero como podes achegarte a este obxectivo? Como crear unha plataforma para executar software que require unha intervención mínima? Que significa NoOps neste contexto?
Se tentas abstraer, entón para os desenvolvedores os conceptos de "sen servidor" ou "NoOps" significan ferramentas e servizos que che permiten ocultar o compoñente "operativo" ou minimizar esta carga para o desenvolvedor.
- Non traballa con sistemas, senón con interfaces de aplicacións (API).
- Non te molestes en implementar software: deixa que o provedor o faga por ti.
- Non te lances a crear un marco grande de inmediato: comeza por escribir pequenas pezas que actuarán como "bloques de construción", intenta que este código funcione con datos e eventos, e non con discos e bases de datos.
O obxectivo, como antes, é acelerar as iteracións no desenvolvemento de software, ofrecer a oportunidade de crear mellores produtos e para que o programador non teña que preocuparse polos sistemas nos que se executa o seu software. Un desenvolvedor experimentado é ben consciente de que centrarse nos usuarios pode cambiar rapidamente a imaxe, polo que non deberías esforzarche moito en escribir software a menos que esteas absolutamente seguro de que é necesario.
Para os profesionais de mantemento e operacións, a palabra "NoOps" pode soar un pouco asustado. Pero ao comunicarse con enxeñeiros de campo, faise obvio que os patróns e técnicas que usan destinados a garantir a fiabilidade e a fiabilidade (Site Reliability Engineering, SRE) teñen moitas semellanzas cos patróns descritos anteriormente:
- Non xestiones sistemas: automatiza os seus procesos de xestión.
- Non implementes software, crea unha canalización para implantalo.
- Evite agrupar todos os seus servizos e permita que o fallo dun deles cause un fallo en todo o sistema; dispáreos por toda a súa infraestrutura mediante ferramentas de automatización e conécteos dun xeito que estea supervisado e supervisado.
Os SRE saben que algo pode saír mal e terán que rastrexar e solucionar o problema, polo que automatizan o traballo rutineiro e establecen orzamentos de erros con antelación para estar preparados para priorizar e tomar decisións cando xurda un problema. .
Kubernetes en OpenShift é unha plataforma deseñada para resolver dous problemas principais: en lugar de obrigarche a comprender as máquinas virtuais ou as API de balance de carga, funciona con abstraccións de orde superior: procesos e servizos de despregamento. En lugar de instalar axentes de software, pode executar contedores e, en lugar de escribir a súa propia pila de seguimento, utilizar as ferramentas xa dispoñibles na plataforma. Entón, a salsa secreta de OpenShift 4 non é ningún segredo: é só cuestión de tomar os principios SRE e os conceptos sen servidor e levalos á súa conclusión lóxica para axudar aos desenvolvedores e enxeñeiros de operacións:
- Automatizar e estandarizar a infraestrutura que utilizan as aplicacións
- Vincula os procesos de implantación e desenvolvemento sen restrinxir aos propios desenvolvedores
- Asegurar que lanzar, auditar e protexer o servizo, función, aplicación ou pila completa número XNUMX non sexa máis difícil que o primeiro.
Pero cal é a diferenza entre a plataforma OpenShift 4 e os seus predecesores e do enfoque "estándar" para resolver tales problemas? Que impulsa a escala para os equipos de implementación e operacións? Debido ao feito de que o rei nesta situación é o cluster. Entón,
- Asegurámonos de que o propósito dos clusters estea claro (Querida nube, collín este cluster porque puiden)
- Existen máquinas e sistemas operativos para servir ao clúster (A Súa Maxestade)
- Xestiona o estado dos hosts desde o clúster, minimiza a súa reconstrución (deriva).
- Para cada elemento importante do sistema, necesítase unha babá (mecanismo) que supervisará e eliminará os problemas
- A falla de *todos* aspectos ou elementos dun sistema e os mecanismos de recuperación asociados son unha parte normal da vida
- Toda a infraestrutura debe configurarse mediante API.
- Usa Kubernetes para executar Kubernetes. (Si, si, non é un erro de ortografía)
- As actualizacións deben ser fáciles e sen complicacións de instalar. Se é necesario máis dun clic para instalar unha actualización, é obvio que estamos a facer algo mal.
- O seguimento e a depuración de calquera compoñente non debería ser un problema e, polo tanto, o seguimento e informes en toda a infraestrutura tamén deberían ser sinxelos e cómodos.
Queres ver as capacidades da plataforma en acción?
Unha versión preliminar de OpenShift 4 está dispoñible para os desenvolvedores. Cun instalador fácil de usar, pode executar un clúster en AWS enriba de Red Had CoreOS. Para utilizar a vista previa, só precisa unha conta de AWS para aprovisionar a infraestrutura e un conxunto de contas para acceder ás imaxes de vista previa.
- Para comezar, vai a e fai clic en "Comezar".
- Inicie sesión na súa conta de Red Hat (ou cree unha nova) e siga as instrucións para configurar o seu primeiro clúster.
Despois da instalación exitosa, consulta os nosos tutoriais para obter unha comprensión máis profunda dos sistemas e conceptos que fan da plataforma OpenShift 4 un xeito tan sinxelo e cómodo de executar Kubernetes.
Proba a nova versión de OpenShift e comparte a túa opinión. Comprometémonos a que o traballo con Kumbernetes sexa o máis accesible e sen esforzo posible: o futuro de NoOps comeza hoxe.
E agora atención!
Na conferencia O 20 de abril, un dos desenvolvedores de OpenShift, Vadim Rutkovsky, realizará unha clase maxistral: romperá dez clústeres e obrigaráos a solucionalos. A conferencia é de pago, pero co código promocional #RedHat tes un desconto do 37%.
Clase maxistral de 17:15 a 18:15, e o stand está aberto todo o día. Camisetas, sombreiros, adhesivos - o de sempre!
Salón #2
"Aquí hai que cambiar todo o sistema: reparamos os clústeres de k8s rotos xunto con mecánicos certificados".
Fonte: www.habr.com