{"id":33504,"date":"2019-10-31T21:52:58","date_gmt":"2019-10-31T18:52:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom\/"},"modified":"2019-10-31T21:52:58","modified_gmt":"2019-10-31T18:52:58","slug":"rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","title":{"rendered":"Gu\u00eda para principiantes: creaci\u00f3n de cadenas DevOps con herramientas de c\u00f3digo abierto.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Gu\u00eda
\nCreaci\u00f3n de la primera cadena DevOps en cinco pasos para principiantes.<\/em><\/p>\n

<\/p>\n

DevOps se ha convertido en la soluci\u00f3n para procesos de desarrollo demasiado lentos, desarticulados y otros problemas. Pero se necesitan conocimientos m\u00ednimos sobre DevOps. Se abordar\u00e1n conceptos como la cadena DevOps y c\u00f3mo crearla en cinco pasos. Esto no es una gu\u00eda completa, sino solo una 'base' que se puede expandir. Comencemos con la historia.<\/p>\n

<\/p>\n

Mi introducci\u00f3n a DevOps<\/h3>\n

<\/p>\n

En alg\u00fan momento trabaj\u00e9 con nubes en Citi Group y desarroll\u00e9 una aplicaci\u00f3n web IaaS para gestionar la infraestructura en la nube de Citi, pero siempre me interes\u00f3 c\u00f3mo optimizar la cadena de desarrollo y mejorar la cultura entre los desarrolladores. Greg Lavender, nuestro director t\u00e9cnico de arquitectura e infraestructura en la nube, me recomend\u00f3 un libro Proyecto 'F\u00e9nix'<\/a><\/noindex>. Explica perfectamente los principios de DevOps, y se lee como una novela.<\/p>\n

<\/a><\/noindex><\/p>\n

En la tabla del reverso se muestra con qu\u00e9 frecuencia las empresas lanzan nuevas versiones:<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

\u00bfC\u00f3mo logran Amazon, Google y Netflix lanzar tantas versiones? La respuesta es simple: entendieron c\u00f3mo crear una cadena DevOps casi perfecta.<\/p>\n

<\/p>\n

En Citi, la situaci\u00f3n era completamente diferente antes de adoptar DevOps. Mi equipo ten\u00eda diferentes entornos, pero la entrega al servidor de desarrollo la hac\u00edamos manualmente. Todos los desarrolladores ten\u00edan acceso solo a un servidor de desarrollo basado en IBM WebSphere Application Server Community Edition. Cuando intent\u00e1bamos hacer la entrega simult\u00e1neamente, el servidor 'ca\u00eda', y ten\u00edamos que negociar 'dolorosamente' cada vez. Adem\u00e1s, ten\u00edamos una cobertura de c\u00f3digo insuficiente en las pruebas, un proceso de entrega manual laborioso y ninguna forma de rastrear la entrega del c\u00f3digo con respecto a alguna tarea o requerimiento del cliente.<\/p>\n

<\/p>\n

Era evidente que necesit\u00e1bamos actuar de inmediato, as\u00ed que encontr\u00e9 a un colega af\u00edn. Decidimos juntos crear la primera cadena DevOps: \u00e9l configur\u00f3 una m\u00e1quina virtual y un servidor de aplicaciones Tomcat, mientras que yo me ocup\u00e9 de Jenkins, la integraci\u00f3n con Atlassian Jira y BitBucket, as\u00ed como de la cobertura de c\u00f3digo en las pruebas. El proyecto fue exitoso: automatizamos completamente la cadena de desarrollo, logramos casi un 100% de disponibilidad del servidor de desarrollo, pudimos rastrear y mejorar la cobertura de c\u00f3digo en las pruebas, y la rama de Git se pod\u00eda vincular a la entrega y a la tarea de Jira. Y casi todas las herramientas que usamos para construir la cadena DevOps eran de c\u00f3digo abierto.<\/p>\n

<\/p>\n

De hecho, la cadena fue simplificada, ya que ni siquiera utilizamos configuraciones avanzadas con Jenkins o Ansible. Pero nos funcion\u00f3. Quiz\u00e1s esto sea consecuencia del principio Pareto<\/a><\/noindex> (tambi\u00e9n conocido como regla 80\/20).<\/p>\n

<\/p>\n

Descripci\u00f3n breve de la cadena DevOps y CI\/CD<\/h3>\n

<\/p>\n

DevOps tiene varias definiciones. Al igual que Agile, DevOps incluye diferentes disciplinas. Pero la mayor\u00eda estar\u00e1 de acuerdo con la siguiente definici\u00f3n: DevOps es un m\u00e9todo, o ciclo de vida, de desarrollo de software, cuyo principio principal es crear una cultura donde los desarrolladores y otros empleados est\u00e9n 'en la misma sinton\u00eda', el trabajo manual est\u00e9 automatizado, cada uno se encargue de lo que mejor sabe hacer, aumente la frecuencia de entregas, mejore la productividad y aumente la flexibilidad.<\/p>\n

<\/p>\n

Y aunque solo los herramientas no son suficientes para crear un entorno DevOps, son indispensables. La m\u00e1s importante de ellas es la integraci\u00f3n continua y la entrega continua (CI\/CD). En la cadena, para cada entorno hay diferentes etapas (por ejemplo, DEV (desarrollo), INT (integraci\u00f3n), TST (pruebas), QA (control de calidad), UAT (pruebas de aceptaci\u00f3n por usuarios), STG (preparaci\u00f3n), PROD (uso)), las tareas manuales est\u00e1n automatizadas, los desarrolladores pueden escribir c\u00f3digo de calidad, entregarlo y pueden reestructurarse f\u00e1cilmente.<\/p>\n

<\/p>\n

Esta nota describe c\u00f3mo crear una cadena DevOps en cinco pasos, como se muestra en la imagen a continuaci\u00f3n, utilizando herramientas de c\u00f3digo abierto.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Vamos al grano.<\/p>\n

<\/p>\n

Paso 1: Plataforma CI\/CD<\/h3>\n

<\/p>\n

Primero, necesitas una herramienta CI\/CD. Jenkins es una herramienta de CI\/CD de c\u00f3digo abierto escrita en Java con licencia MIT, que inici\u00f3 la popularizaci\u00f3n del movimiento DevOps y que de facto se convirti\u00f3 en el est\u00e1ndar para CI\/CD.<\/p>\n

<\/p>\n

\u00bfY qu\u00e9 es Jenkins? Imagina que tienes un control remoto m\u00e1gico para una variedad de servicios y herramientas. La herramienta CI\/CD, como Jenkins, en s\u00ed misma es in\u00fatil, pero con diferentes herramientas y servicios se vuelve todopoderosa.<\/p>\n

<\/p>\n

Adem\u00e1s de Jenkins, hay muchas otras herramientas de c\u00f3digo abierto, elige cualquiera. <\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

As\u00ed es como se ve el proceso DevOps con una herramienta CI\/CD<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Tienes una herramienta CI\/CD en localhost, pero por ahora no hay mucho que hacer. Vamos al siguiente paso.<\/p>\n

<\/p>\n

Paso 2: gesti\u00f3n de versiones<\/h3>\n

<\/p>\n

La mejor (y quiz\u00e1s la m\u00e1s simple) manera de verificar la magia de la herramienta CI\/CD es integrarla con una herramienta de control de versiones (source control management, SCM). \u00bfPara qu\u00e9 sirve el control de versiones? Supongamos que est\u00e1s creando una aplicaci\u00f3n. La escribes en Java, Python, C++, Go, Ruby, JavaScript o en cualquier otro idioma, que son muchos. Lo que escribes se llama c\u00f3digo fuente. Al principio, especialmente si trabajas solo, puedes almacenar todo en un directorio local. Pero cuando el proyecto crece y se une m\u00e1s gente, necesitas una forma de compartir los cambios en el c\u00f3digo, pero al mismo tiempo evitar conflictos al fusionar cambios. Adem\u00e1s, necesitas alguna forma de restaurar versiones anteriores sin usar copias de seguridad y sin aplicar el m\u00e9todo de copiar y pegar en los archivos de c\u00f3digo.<\/p>\n

<\/p>\n

Y aqu\u00ed es donde no se puede prescindir del SCM. El SCM almacena el c\u00f3digo en repositorios, gestiona sus versiones y lo coordina entre los desarrolladores.<\/p>\n

<\/p>\n

Hay muchas herramientas de SCM, pero el est\u00e1ndar de facto se ha convertido merecidamente en Git. Te recomiendo usarlo, aunque hay otras alternativas.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/p>\n

<\/p>\n

As\u00ed es como se ve el pipeline de DevOps despu\u00e9s de a\u00f1adir el SCM.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

La herramienta CI\/CD puede automatizar la carga y descarga del c\u00f3digo fuente y la colaboraci\u00f3n en equipo. \u00bfNo est\u00e1 mal? Pero, \u00bfc\u00f3mo convertir esto en una aplicaci\u00f3n funcional, querida por miles de millones de usuarios?<\/p>\n

<\/p>\n

Paso 3: Herramienta de automatizaci\u00f3n de compilaci\u00f3n<\/h3>\n

<\/p>\n

Todo va como se esperaba. Puedes subir el c\u00f3digo y registrar cambios en el sistema de control de versiones, as\u00ed como invitar a amigos a trabajar contigo. Pero a\u00fan no tienes una aplicaci\u00f3n. Para que esto sea una aplicaci\u00f3n web, necesita ser compilada y empaquetada para su entrega o ejecutada como un archivo ejecutable. (No es necesario compilar un lenguaje de programaci\u00f3n interpretado, como JavaScript o PHP).<\/p>\n

<\/p>\n

Usa una herramienta de automatizaci\u00f3n de compilaci\u00f3n. Cualquiera que elijas, recoger\u00e1 el c\u00f3digo en el formato necesario y automatizar\u00e1 la limpieza, compilaci\u00f3n, prueba y entrega. Hay varias herramientas de compilaci\u00f3n dependiendo del lenguaje, pero generalmente se utilizan las siguientes opciones de c\u00f3digo abierto.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/p>\n

<\/p>\n

\u00a1Excelente! Ahora insertemos los archivos de configuraci\u00f3n de la herramienta de automatizaci\u00f3n de compilaci\u00f3n en el sistema de control de versiones para que la herramienta CI\/CD los recoja.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Parece que todo est\u00e1 bien. Pero, \u00bfd\u00f3nde vamos a desplegar todo esto ahora?<\/p>\n

<\/p>\n

Paso 4: Servidor de aplicaciones web<\/h3>\n

<\/p>\n

Entonces, tienes un archivo empaquetado que puede ser ejecutable o desplegable. Para que la aplicaci\u00f3n realmente sea \u00fatil, debe tener alg\u00fan servicio o interfaz, pero necesitas un lugar donde alojar todo esto.<\/p>\n

<\/p>\n

Una aplicaci\u00f3n web se puede alojar en un servidor de aplicaciones. Un servidor de aplicaciones proporciona el entorno para ejecutar la l\u00f3gica de programaci\u00f3n del paquete, realizar el rendering de la interfaz y abrir servicios web a trav\u00e9s de un socket. Necesitas un servidor HTTP y otros entornos (como una m\u00e1quina virtual, por ejemplo) para instalar el servidor de aplicaciones. Por ahora, supongamos que est\u00e1s manejando todo esto en el proceso (aunque hablar\u00e9 sobre contenedores m\u00e1s adelante).<\/p>\n

<\/p>\n

Existen varios servidores de aplicaciones web de c\u00f3digo abierto.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Ya hemos creado una cadena de DevOps casi funcional. \u00a1Gran trabajo!<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

En principio, aqu\u00ed se puede detener, luego te las arreglar\u00e1s solo, pero vale la pena hablar tambi\u00e9n sobre la calidad del c\u00f3digo.<\/p>\n

<\/p>\n

Paso 5: Cobertura de pruebas<\/h3>\n

<\/p>\n

Las pruebas consumen mucho tiempo y esfuerzo, pero es mejor encontrar errores y mejorar el c\u00f3digo de inmediato para complacer a los usuarios finales. Hay muchas herramientas de c\u00f3digo abierto para este prop\u00f3sito, que no solo prueban el c\u00f3digo, sino que tambi\u00e9n sugieren c\u00f3mo mejorarlo. La mayor\u00eda de las herramientas de CI\/CD pueden conectarse a estas herramientas y automatizar el proceso.<\/p>\n

<\/p>\n

Las pruebas se dividen en dos partes: marcos de pruebas para escribir y ejecutar pruebas, y herramientas con sugerencias para mejorar la calidad del c\u00f3digo.<\/p>\n

<\/p>\n

Marcos de pruebas<\/h3>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Herramientas con sugerencias sobre calidad<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

La mayor\u00eda de estas herramientas y marcos est\u00e1n escritos para Java, Python y JavaScript, porque C++ y C# son propietarios (aunque GCC tiene c\u00f3digo abierto).<\/p>\n

<\/p>\n

Hemos aplicado herramientas de cobertura de pruebas y ahora el pipeline de DevOps deber\u00eda lucir como en la imagen al inicio de la gu\u00eda.<\/p>\n

<\/p>\n

Pasos adicionales<\/h2>\n

<\/p>\n

Contenedores<\/h3>\n

<\/p>\n

Como mencion\u00e9, el servidor de aplicaciones se puede alojar en una m\u00e1quina virtual o un servidor, pero los contenedores son m\u00e1s populares.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 son los contenedores?<\/a><\/noindex>? \u0412\u043a\u0440\u0430\u0442\u0446\u0435, \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0435\u0441\u0442\u0430, \u0447\u0435\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0431\u0435\u0437 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u043d\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c, \u043d\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0432\u043c\u0435\u0449\u0430\u0435\u0442 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0438\u0445 \u0437\u0430\u0442\u0440\u0430\u0442.<\/p>\n

<\/p>\n

Para contenedores, generalmente se utiliza Docker y Kubernetes, aunque hay otras opciones.<\/p>\n

<\/p>\n

\"Gu\u00eda<\/a><\/noindex><\/p>\n

<\/p>\n

Lee los art\u00edculos sobre Docker y Kubernetes en Opensource.com<\/a><\/noindex>:<\/p>\n

<\/p>\n