Se es novo en DevOps, bótalle un ollo a esta guía de cinco pasos para crear o teu primeiro pipeline.
DevOps converteuse na solución estándar para arranxar procesos de desenvolvemento de software lentos, desarticulados ou rotos. O problema é que se es novo en DevOps e non sabe por onde comezar, é posible que non entenda estas técnicas. Este artigo analizará a definición dunha canalización de DevOps e tamén proporcionará instrucións de cinco pasos para creala. Aínda que este tutorial non é exhaustivo, debería darche unha base para comezar a túa viaxe e ampliar os teus coñecementos no futuro. Pero comecemos pola historia.
A miña viaxe de DevOps
Anteriormente traballei no equipo na nube de Citi Group desenvolvendo unha aplicación web de Infraestrutura como servizo (IaaS) para xestionar a infraestrutura na nube de Citi, pero sempre estiven interesado en como facer o proceso de desenvolvemento máis eficiente e levar un cambio cultural positivo ao equipo de desenvolvemento. Atopei a resposta nun libro recomendado por Greg Lavender, CTO de Cloud Architecture and Infrastructure en Citi. O libro chamábase The Phoenix Project (), e explica os principios de DevOps, pero le como unha novela.
A táboa ao final do libro mostra a frecuencia coa que diferentes empresas implantan os seus sistemas nun ambiente de lanzamento:
Amazon: 23 por día
Google: 5 por día
Netflix: 500 por día
Facebook: Unha vez ao día
Twitter: 3 veces por semana
Empresa típica: Unha vez cada 9 meses
Como son posibles as frecuencias de Amazon, Google e Netflix? Isto débese a que estas empresas descubriron como crear unha canalización DevOps case perfecta.
Estivemos lonxe diso ata que implementamos DevOps en Citi. Daquela, o meu equipo tiña diferentes ambientes, pero a implantación no servidor de desenvolvemento era completamente manual. Todos os desenvolvedores tiñan acceso só a un servidor de desenvolvemento baseado en IBM WebSphere Application Server Community Edition. O problema era que o servidor apagaba cada vez que varios usuarios tentaban implementarse ao mesmo tempo, polo que os desenvolvedores tiveron que comunicarse entre si as súas intencións, o que era bastante doloroso. Ademais, houbo problemas coa cobertura de código de proba de baixo nivel, procesos de despregamento manual engorrosos e a incapacidade de rastrexar o despregamento de código asociado a unha tarefa ou historia de usuario específica.
Decateime de que había que facer algo e atopei un colega que me parecese. Decidimos colaborar na construción do pipeline DevOps inicial: el creou unha máquina virtual Tomcat e un servidor de aplicacións mentres eu traballaba en Jenkins, integraba Atlassian Jira e BitBucket e traballaba na cobertura do código de proba. Este proxecto paralelo tivo moito éxito: automatizamos case por completo moitos procesos, conseguimos case o 100 % de tempo de actividade no noso servidor de desenvolvemento, proporcionamos un seguimento e unha cobertura de proba mellorada do código e engadimos a posibilidade de vincular ramas de Git a problemas ou despregamentos de Jira. A maioría das ferramentas que utilizamos para construír o noso pipeline DevOps eran de código aberto.
Agora entendo o sinxelo que era o noso pipeline DevOps: non usamos extensións como ficheiros Jenkins ou Ansible. Non obstante, esta sinxela canalización funcionou ben, quizais debido ao principio de Pareto (tamén coñecido como regra 80/20).
Unha breve introdución ao DevOps e ao pipeline CI/CD
Se preguntas a varias persoas: "Que é DevOps?", probablemente obterás varias respostas diferentes. DevOps, como Agile, evolucionou para abarcar moitas disciplinas diferentes, pero a maioría da xente estará de acordo nalgunhas cousas: DevOps é unha práctica de desenvolvemento de software ou ciclo de vida de desenvolvemento de software (SDLC) cuxo principio central é cambiar a cultura na que desenvolven e non os desenvolvedores existen nun ambiente no que:
Automatizáronse as operacións que antes se realizaban manualmente;
Cada un fai o que mellor sabe;
O número de implementacións durante un determinado período de tempo aumenta; Aumenta o rendemento;
Aumento da flexibilidade de desenvolvemento.
Aínda que ter as ferramentas de software adecuadas non é o único que necesitas para crear un ambiente DevOps, algunhas ferramentas son esenciais. Unha ferramenta clave é a integración continua e o despregamento continuo (CI/CD). Neste pipeline, os ambientes teñen diferentes etapas (por exemplo, DEV, INT, TST, QA, UAT, STG, PROD), moitas operacións están automatizadas e os desenvolvedores poden escribir código de alta calidade, acadar axilidade de desenvolvemento e altas taxas de implantación.
Este artigo describe un enfoque en cinco pasos para crear unha canalización de DevOps como a que se mostra no seguinte diagrama utilizando ferramentas de código aberto.
Paso 1: Métodos CI/CD
O primeiro que necesitas é unha ferramenta CI/CD. Jenkins, unha ferramenta de código aberto baseada en Java e licenciada baixo a licenza MIT, é a ferramenta que popularizou DevOps e converteuse no estándar de facto.
Entón, que é Jenkins? Pense nel como unha especie de control remoto universal máxico que pode falar e organizar varios servizos e ferramentas. Por si só, unha ferramenta CI/CD como Jenkins é inútil, pero faise máis poderosa a medida que se conecta a diferentes ferramentas e servizos.
Jenkins é só unha das moitas ferramentas CI/CD de código aberto que podes usar para crear o teu pipeline DevOps.
Jenkins: Creative Commons e MIT
Travis CI: MIT
Control de crucero: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Gabinete: GNU
Este é o aspecto dos procesos DevOps cunha ferramenta CI/CD:
Tes unha ferramenta CI/CD en execución no teu localhost, pero non hai moito que poidas facer neste momento. Pasemos á seguinte etapa da viaxe de DevOps.
Paso 2: xestionar os sistemas de control de fontes
A mellor forma (e quizais a máis sinxela) de verificar que a súa ferramenta CI/CD pode facer a súa maxia é integrarse cunha ferramenta de control de código fonte (SCM). Por que necesitas o control de fontes? Digamos que está a desenvolver unha aplicación. Sempre que creas unha aplicación, estás programando, e non importa se usas Java, Python, C++, Go, Ruby, JavaScript ou calquera dos millóns de linguaxes de programación. O código que escribe chámase código fonte. Ao principio, especialmente cando traballas só, probablemente estea ben poñer todo nun directorio local. Pero a medida que o proxecto se fai máis grande e invitas a outras persoas a colaborar, necesitas un xeito de evitar conflitos mentres compartes modificacións de forma eficaz. Tamén precisa un xeito de restaurar versións anteriores, porque a creación de copias de seguridade e copiar/pegar nelas está quedando obsoleto. Ti (e os teus compañeiros) necesitas algo mellor.
Aquí é onde o control do código fonte faise case unha necesidade. Esta ferramenta almacena o teu código en repositorios, fai un seguimento das versións e coordina o traballo dos participantes do proxecto.
Aínda que hai moitas ferramentas de control de fontes, Git é o estándar, e con razón. Recomendo encarecidamente usar Git, aínda que hai outras opcións de código aberto se o prefires.
Git: GPLv2 e LGPL v2.1
Subversión: Apache 2.0
Sistema de versións simultáneas (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Este é o aspecto dunha canalización de DevOps coa adición de controis de código fonte.
Unha ferramenta de CI/CD pode automatizar os procesos de revisión, adquisición de código fonte e colaboración entre os membros. Non está mal? Pero como se converte nunha aplicación que funcione para que miles de millóns de persoas poidan usala e apreciala?
Paso 3: crea unha ferramenta de automatización de construción
Genial! Podes revisar o código e facer cambios no control de fontes e invitar aos teus amigos a colaborar no desenvolvemento. Pero aínda non creaches unha aplicación. Para facer unha aplicación web, debe compilarse e empaquetar nun formato por lotes despregable ou executarse como ficheiro executable. (Ten en conta que non é necesario compilar unha linguaxe de programación interpretada como JavaScript ou PHP).
Use unha ferramenta de automatización de construción. Non importa a ferramenta de automatización de compilación que decidas usar, todas teñen o mesmo obxectivo: construír o código fonte nalgún formato desexado e automatizar a tarefa de limpeza, compilación, proba e implantación nun ambiente específico. As ferramentas de construción variarán dependendo da súa linguaxe de programación, pero aquí tes algunhas opcións comúns de código aberto.
nome
Licenza
Linguaxe de programación
Maven
Apache 2.0
Java
Última
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Facer
GNU
N / A
Gruñón
MIT
JavaScript
Trago
MIT
JavaScript
Construtor
Apache
Rubio
Rastrillo
MIT
Rubio
AAP
GNU
Pitão
SCons
MIT
Pitão
BitBake
GPLv2
Pitão
Bolo
MIT
C#
ASDF
Expatriado (MIT)
LISP
Exacto
BSD
Haskell
Genial! Podes poñer os ficheiros de configuración da ferramenta de automatización de compilación no teu sistema de control de fonte e deixar que a túa ferramenta CI/CD o xunte todo.
Todo está ben, non? Pero onde implementar a túa aplicación?
Paso 4: Servidor de aplicacións web
Polo momento, tes un ficheiro empaquetado que pode ser executable ou instalable. Para que calquera aplicación sexa realmente útil, debe proporcionar algún tipo de servizo ou interface, pero necesitas un contenedor para aloxar a túa aplicación.
Un servidor de aplicacións web é só un contedor deste tipo. O servidor proporciona un ambiente no que se pode definir a lóxica do paquete que se está a implementar. O servidor tamén ofrece unha interface e ofrece servizos web expoñendo sockets ao mundo exterior. Necesitas un servidor HTTP, así como algún ambiente (como unha máquina virtual) para instalalo. Polo momento, supoñamos que aprenderá máis sobre isto (aínda que cubrirei os contedores a continuación).
Hai varios servidores de aplicacións web de código aberto.
nome
Licenza
Linguaxe de programación
Tomcat
Apache 2.0
Java
Embarcadero
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
Glassfish
CDDL e GNU Less Public
Java
Django
3-Cláusula BSD
Pitão
Tornado
Apache 2.0
Pitão
Gunicornio
MIT
Pitão
Pitão
MIT
Pitão
Rails
MIT
Rubio
Nodo.js
MIT
Javascript
A túa canalización de DevOps está case lista para usar. Bo traballo!
Aínda que podes parar aí e xestionar a integración por ti mesmo, a calidade do código é algo importante polo que se preocupe un desenvolvedor de aplicacións.
Paso 5: Cobertura das probas de código
A implementación de probas pode ser outro requisito complicado, pero os desenvolvedores deben detectar calquera erro na aplicación antes de tempo e mellorar a calidade do código para garantir que os usuarios finais estean satisfeitos. Afortunadamente, hai moitas ferramentas de código aberto para probar o teu código e facer recomendacións para mellorar a súa calidade. O que é aínda mellor é que a maioría das ferramentas CI/CD poden conectarse a estas ferramentas e automatizar o proceso.
A proba de código consta de dúas partes: marcos de proba de código que che axudan a escribir e executar probas e ferramentas de suxestión que che axudan a mellorar a calidade do teu código.
Sistemas de proba de código
nome
Licenza
Linguaxe de programación
JUnit
Licenza pública de eclipse
Java
EasyMock
Apache
Java
mockito
MIT
Java
PowerMock
Apache 2.0
Java
Pytest
MIT
Pitão
Hipótese
Mozilla
Pitão
tox
MIT
Pitão
Sistemas de recomendación para a mellora do código
nome
Licenza
Linguaxe de programación
Cuberta
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Cobertura.py
Apache 2.0
Pitão
Emma
Licenza Pública Común
Java
XaCoCo
Licenza pública de eclipse
Java
Hipótese
Mozilla
Pitão
tox
MIT
Pitão
xasmín
MIT
JavaScript
Carma
MIT
JavaScript
Mocha
MIT
JavaScript
ten
MIT
JavaScript
Teña en conta que a maioría das ferramentas e marcos mencionados anteriormente están escritos para Java, Python e JavaScript, xa que C++ e C# son linguaxes de programación propietarias (aínda que GCC é de código aberto).
Agora que implementou ferramentas de cobertura de probas, a súa canalización de DevOps debería parecerse ao diagrama que se mostra ao comezo deste tutorial.
Pasos adicionais
Contenedores
Como dixen, pode aloxar o seu servidor nunha máquina virtual ou nun servidor, pero os contedores son unha solución popular.
Que son os contedores? A pequena explicación é que unha máquina virtual necesita unha gran cantidade de memoria do sistema operativo, que supera o tamaño da aplicación, mentres que un contedor só necesita unhas poucas bibliotecas e configuracións para executar a aplicación. Obviamente, aínda hai usos importantes para unha máquina virtual, pero un contedor é unha solución lixeira para hospedar unha aplicación, incluíndo un servidor de aplicacións.
Aínda que hai outras opcións de contedores, as máis populares son Docker e Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Ferramentas de automatización intermedias
O noso pipeline DevOps céntrase principalmente na creación e implantación de aplicacións colaborativas, pero hai moitas outras cousas que se poden facer coas ferramentas DevOps. Unha delas é o uso de ferramentas de Infraestrutura como Código (IaC), tamén coñecidas como ferramentas de automatización de middleware. Estas ferramentas axudan a automatizar a instalación, a xestión e outras tarefas do middleware. Así, por exemplo, unha ferramenta de automatización pode extraer aplicacións como un servidor de aplicacións web, unha base de datos e unha ferramenta de monitorización coas configuracións correctas e implementalas no servidor de aplicacións.
Aquí tes algunhas ferramentas de automatización de middleware de código aberto:
Ansible: GNU Public
SaltStack: Apache 2.0
Xefe: Apache 2.0
Títeres: Apache ou GPL
Descubra detalles sobre como conseguir unha profesión demandada desde cero ou subir de nivel en termos de habilidades e salario facendo cursos en liña pagos de SkillFactory:
- (12 meses)
máis cursos
- (12 semanas)
- (12 meses)
- (9 meses)
- (9 meses)
Útil
Fonte: www.habr.com