07. Infraestructura àgil. Docker i DevOps.pdf

Tema 7 Infraestructura àgil i desplegament d’aplicacions amb Docker i DevOps. DevOps DevOps és un mot creuat de “desenvolupament” i "operacions" (Development-Operations) és un mètode de desenvolupament del programari que accentua la comunicació, la col·laboració (compartició d'informació i utilitz...

Tema 7 Infraestructura àgil i desplegament d’aplicacions amb Docker i DevOps. DevOps DevOps és un mot creuat de “desenvolupament” i "operacions" (Development-Operations) és un mètode de desenvolupament del programari que accentua la comunicació, la col·laboració (compartició d'informació i utilització del servei web), la integració, l'automatització i la mesura del nivell de cooperació entre desenvolupadors de programari i altres professionals de tecnologies de la informació. La metodologia DevOps reconeix la interdependència entre el desenvolupament de programari, l'assegurament de qualitat i les operacions TIC, i té com a objectiu ajudar una organització a produir ràpidament productes de programari i serveis, millorant l'eficiència de l’organització a l’hora d’entregar nous desenvolupaments de programari amb més qualitat i amb una major freqüència. DevOps és especialment útil en el nou entorn de la transformació digital i el desenvolupament de productes digitals, per a què els usuaris finals i/o el client intern de negocio demanda TTM (time-to-market), més flexibilitat, més qualitat, menys cost i una altíssima freqüència de releases. DevOps no es en sí una cultura, però es requereix d’un fort canvi cultural i organitzatiu per a la seva implementació. Un canvi cultural cap a la col·laboració, la comunicació, i en últim terme la completa integració entre les antigues àrees (habitualment estanques) de desenvolupament i sistemes. Este canvi cultural és tan complicat d’aconseguir en algunes organitzacions, que son molts els que l’identifiquen directament amb DevOps, però recordem: DevOps és una metodologia de desenvolupament de software, i un canvi de cultura no és en sí mateix una forma de desenvolupar software. Què aporta DevOps a una organització? Solucions més ràpides Augment eficiència Millora contínua Millor l’experiència de l’usuari Reducció dels errors i rollbacks El ROI es més aviat Desenvolupar un producte (MVP) de valor per a l'usuari final 1  Respondre de forma més àgil a les necessitats i canvis Feedback i millora contínua Més qualitat a les entregues (releases) Mes predictibilitat Infraestructura àgil Les metodologies àgils promouen la creació incremental dels productes i no esperar fins a les fases finals del projecte per a posar en producció el software (com es faria generalment amb waterfall). Per exemple, Scrum (Tema 06), parla de la creació a cada Sprint d’un increment de software que pot ser potencialment desplegat a producció. Aquesta pràctica de crear increments potencialment desplegables a producció a cada sprint, provoca la necessitat de tenir una base tecnològica i organitzativa per poder portar-se a terme. Això vol dir que cal dissenyar una infraestructura àgil que permeti aquests desplegaments continuats de forma automatitzada assegurant la qualitat i seguretat dels desplegaments. Es pot considerar que DevOps juga un paper fonamental precisament a la creació d’aquesta infraestructura, ja que no deixa de ser la unió (col·laboració) entre el àrea de desenvolupament, l'àrea d’operacions i l’àrea de qualitat. Per fer-nos una idea de quants de desplegaments a producció es fan diàriament a algunes empreses, es pot veure la següent taula: Què inclou una infraestructura àgil per a desplegaments d’aplicacions Ja hem vist perquè és necessària una infraestructura àgil i que aquesta ens ajuda a posar a producció el programari que anem desenvolupant. Al dibuix que hi ha a continuació, es pot veure algunes de les eines/productes (Open i/o privatius) que formen part generalment d’aquesta infraestructura àgil: 2  Ref.: https://intland.com/devops-it-operations/ No podem entrar amb detall a cada una de les eines ja que l’abast és massa gran, però explicarem 5 elements bàsics que generalment conté una infraestructura àgil, l’elecció de l’eina concreta dependrà de cada cas. 1. Sistema d’Integració continua / Desplegament continu. 2. El sistema de control de codi font (SCM). 3. Eina de construcció automàtica [Build automation tool] 4. Servidor d’aplicacions web. 5. Testeig de codi automatitzat Sistema d’integració continua / desplegament continu (CI/CD framework) El primer element d’una infraestructura àgil /devOps es tenir una eina d’integració i de desplegament continu. L’eina més utilitzada per a fer això es el Jenkins, que es Opensource i basada amb Java. És l’eina estàndard de facto. CI: integració continua [Continuous integration] és una pràctica de desenvolupament de programari on els membres d'un equip integren sovint el seu treball (per exemple, diàriament), donant lloc a múltiples integracions. La integració consisteix en la compilació i execució de les proves de tot el projecte. A cada integració es verifica per generació automatitzada (incloent proves) per detectar errors d'integració al més ràpidament possible. En l'enginyeria de programari, integració contínua significa l'aplicació contínua dels processos de control de qualitat, en les petites unitats d'esforç, aplicades sovint. CD: entrega continua [Continuous Delivery] és un enfoc de la enginyeria del software en que los equips de desenvolupament produeixen software en cicles curts, garantint que el software pot ser alliberat en qualsevol moment, de forma confiable. Apunta a la construcció, prova, y alliberament del software de forma més ràpida y més freqüent. Aquest enfoc ajuda en la reducció del costo, temps, y risc de l’alliberament de versions a través de l’alliberament de versions més incrementals a aplicacions en producció. Un procés directe i repetible d’alliberament és important para una entrega continua. Altres eines alternatives Open source per a construir un “pipeline” de CD/CI: 3  Nom Llicència Jenkins Creative Commons and MIT Travis CI MIT CruiseControl BSD Buildbot GPL Apache Gump Apache 2.0 Cabie GNU El que farà l’eina de CI/CD es orquestrar i executar els anomenats treballs [jobs] programats per tal d’executar diferents part del procés (amb l’objectiu, per exemple, de portar el codi a producció o al entorn desitjat). Sistema de control de codi font [Source control management (SCM)] El sistema de control de codi font gestiona els fitxers del projecte que contenen el codi font i també gestiona com es comparteixen aquests fitxers entre els diferents col·laboradors del projecte. El SCM ajuda als programadors a treballar junts de forma col·laborativa sobre el mateix projecte, i també ofereix opcions per poder restablir versions anteriors del codi Amb el que hem vist fins ara (eina de CD i CI + el SCM) el pipeline quedaria com al dibuix següent: Hi ha un gran nombre d’eines que es poden utilitzar com a SCM, encara que el estàndard actual de facto es el Git, a la següent taula veiem diferents SCM open source: Name License Git GPLv2 & LGPL v2.1 Subversion Apache 2.0 Concurrent Versions System (CVS) GNU Vesta LGPL 4  Mercurial GNU GPL v2+ Eina de construcció automàtica [Build automation tool] Fins aquí, els programadors ja poden pujar el codi al SCM, però encara no hem construït l’aplicació. Per a poder tenir una aplicació, ha d’estar compilada i posada a un paquet que es pugui desplegar o executar. Ens cal per a això una eina de construcció automàtica. Independentment de l’eina que decidim utilitzar, totes tenen el mateix objectiu: automatitzar la construcció d’un paquet a partir del codi font, netejar fitxer intermedis, compilar, fer el testeig i desplegar aquest paquet a una determinada ruta. L’eina de construcció, dependrà del llenguatge de programació utilitzat. A la següent taula hi ha uns exemples d’eines de construcció automàtica: Name License Programming Language Maven Apache 2.0 Java Ant Apache 2.0 Java Gradle Apache 2.0 Java Bazel Apache 2.0 Java Make GNU N/A Grunt MIT JavaScript Gulp MIT JavaScript Buildr Apache Ruby Rake MIT Ruby A-A-P GNU Python SCons MIT Python BitBake GPLv2 Python Cake MIT C# ASDF Expat (MIT) LISP Cabal BSD Haskell Ara ja podem posar els fitxers de configuració de l’eina de construcció automàtica dintre del SCM, i dir-li a l’eina de CI/CD que comenci la construcció de la aplicació! 5 Servidor d’aplicacions web [Web application server] Fins aquí, hem aconseguit empaquetar el fitxer i fer-lo executable o desplegable. Però per a que una aplicació tingui realment sentit, ha de proveir alguna mena de servei o tenir alguna interfície, per això normalment necessitarem allotjar-la a un servidor d’aplicacions o servidor d’aplicacions web, alguns dels més utilitzats: Name License Programming Language Tomcat Apache 2.0 Java Jetty Apache 2.0 Java WildFly GNU Lesser Public Java GlassFish CDDL & GNU Less Public Java Django 3-Clause BSD Python Tornado Apache 2.0 Python Gunicorn MIT Python Python Paste MIT Python Rails MIT Ruby Node.js MIT Javascript Quedaria llavors així (posant un server per a cada entorn: Desenvolupament, Integració, Testing, QA, Staging, Producció): 6 Testeig de codi automatitzat (Code Testing) Implementar les diferents parts del codi pot ser un requeriment molt complicat, i els desenvolupadors necessiten trobar qualsevol error a l’aplicació quan més aviat millor per millorar la qualitat del codi. Hi ha moltes eines per a fer el testing i suggerir millores a la qualitat del codi. De fet, aquestes eines de testeig, es poden incloure com a part de les CI/CD per assegurar-nos que es comprova la qualitat del codi contínuament. Hi ha 2 tipus d’eines principalment: Frameworks de testing per executar els test del codi. Eines de suggeriments de qualitat del codi. Frameworks de testing (errors de codi): Name License Programming Language JUnit Eclipse Public License Java EasyMock Apache Java Mockito MIT Java PowerMock Apache 2.0 Java Pytest MIT Python Hypothesis Mozilla Python Tox MIT Python Eines de suggeriments de qualitat del codi: Name License Programming Language Cobertura GNU Java CodeCover Eclipse Public (EPL) Java Coverage.py Apache 2.0 Python 7  Emma Common Public License Java JaCoCo Eclipse Public License Java Hypothesis Mozilla Python Tox MIT Python Jasmine MIT JavaScript Karma MIT JavaScript Mocha MIT JavaScript Jest MIT JavaScript Amb el que hem vist, ja tindrem una pipeline completa (falta explicar la part de Docker del següent apartat): Resumint: Podem anomenar pipeline al conjunt dels passos automatitzats que es realitzen des de el moment que un desenvolupador puja el seu codi al SCM (mitjançant el que s’anomena un “commit o Check in”) fins que es desplega l’aplicació al servidor d’aplicacions o web configurat. Aquesta automatització permet entrega contínua de software assegurant qualitat i seguretat. Aquests treballs seran per exemple: Compilar el codi integrant-lo amb els altres projectes que tinguin dependències amb aquest. Executar els tests inclosos a aquest codi (test unitaris, tests d’integració, etc..) Executar eines de comprovació i suggeriment de qualitat del codi. Fer la construcció (build) d’un fitxer binari i guardar-lo a un repositori de versions de binaris. Copiar aquest paquet al servidor d’aplicacions del entorn corresponent i desplegar-lo. Nota: Tots aquests passos, no es que els faci directament l’eina de CI/CD, sinó que farà les crides necessàries a les eines específiques que faran cada l’acció concreta. 8 Docker La idea darrere de Docker és crear contenidors lleugers i portables per a que las aplicacions software pugin executar-se en qualsevol màquina amb Docker instal·lat, independentment del sistema operatiu que la màquina tingui per sota, facilitant així també els desplegaments. Concepte de contenidor Per fer un símil amb el mon real, imagina un contenidor dels que porten els vaixells amb mercaderies, que contenen diferents productes dintre. Es auto contingut, es pot portar d’un lloc a un altre de manera independent, és portable. Tornant al software, per a que els usuaris normals puguem accedir a una aplicació, dita aplicació necessita estar executant-se a una màquina, a un ordinador. Però a més a més, aquest ordinador necessita tenir instal·lades una sèrie de coses per a que l’aplicació s’executi correctament: per exemple una certa versió de Java, un servidor d’aplicacions (i.e: Tomcat), doncs bé, Docker, ens permet ficar dintre d’un contenidor, totes aquelles coses que la meva aplicació necessita per a ser executada (Maven, Java, Tomcat…) i la pròpia aplicació. D’aquesta manera, ens podem portar aquest contenidor a qualsevol màquina que tingui instal·lat Docker i executar l’aplicació sense haver de fer res més, sempre i quan tingui tots els elements necessaris per a la meva aplicació. És a dir, executarem l’aplicació dintre del contenidor docker, i dintre d’aquest contenidor, hi seran totes les llibreries “i coses” que necessita aquesta aplicació per a funcionar correctament. Quina diferència hi ha respecte una màquina virtual? El concepte és quelcom similar, però un contenidor no és el mateix que una màquina virtual. Un contenidor és més lleuger, ja que mentre que a una màquina virtual necessites instal·lar-li un sistema operatiu per a funcionar, un contenidor de Docker funciona utilitzant el sistema operatiu que te la màquina en la que s’executa el contenidor. Diguem que el contenidor de Docker pren els recursos més bàsics, que no canvien d’un ordinador a altre del sistema operatiu de la màquina en la que s’executa. I els aspectes més específics del sistema que poden donar més problemes a l’hora de portar el software d’un lloc a altre, s’introdueixen en l’interior del contenidor. El següent gràfic ens pot ajudar a visualitzar les diferències entre màquines virtuals (VM) i Dockers (Containers), veiem que el contingut dels contenidors es menor que el que ha de suportar una VM: 9  Avantatges i inconvenients d’utilitzar docker: Per això Docker també és molt bo per al testing, per a tenir entorns de proves. Per un costat, és molt senzill crear i esborrar un contenidor, a més de que són molt lleugers, pel que podem executar diferents contenidores en una mateixa màquina (on aquest contenidor tindria l’entorn de la nostra aplicació: base de dades, servidor, llibreries…). Per altra, un mateix contenidor funcionarà en qualsevol màquina Linux: un portàtil, el ordenador de la teva casa, màquines allotjades en Amazon, el teu propi servidor… Això a més beneficia a la part de sistemes, ja com que els contenidores son més lleugers que les màquines virtuals, es redueix el nombre de màquines necessàries per a tenir un entorn. I el millor és que Docker és open source. Altres avantatges: Separació de preocupacions ○ Desenvolupadors/Arquitectes ○ Administradors de sistemes Agilitza el cicle de desenvolupament i proves: Contenidors lleugers i per tant més ràpids Portabilitat d’aplicacions: Construcció/Desplegament en diferents entorns fent servir els mateixos contenidors. Escalabilitat: Creació de nous contenidors en cas necessari La pregunta del test és sobre la infraestructura àgil DevOps. TEST 7. La tècnica del pipeline, en l’àmbit de la cultura DEVOPS, ens facilita la implementació de: 10 A. Les proves d’acceptació dels usuaris. B. Els contenidors d’aplicacions independents. C. L’arquitectura de les aplicacions basada en microserveis. D. El concepte d’entrega contínua de software. 13. Per al Lot 2 ateses unes expectatives de canvi evolutiu molt elevades es decideix aplicar una sistemàtica DevOps per a actualització constant del programari que asseguri una posada en producció el més ràpid possible. Quin component dels següents NO estaria directament implicat en aquesta sistemàtica? A. Repositori de versions del codi font. B. Eina de gestió de projectes amb mètodes àgils. C. Quadre de comandament amb indicadors de rendiment de l’aplicació en producció. D. Sistema de test unitari i d’integració. BIBLIOGRAFIA Introducció: https://ca.wikipedia.org/wiki/DevOps https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es-devops/ https://theagileadmin.com/what-is-devops/ https://www.linkedin.com/learning/devops-foundations Concepte de desplegament: https://opensource.com/article/19/4/devops-pipeline https://en.wikipedia.org/wiki/Software_deployment https://jenkins.io/doc/ Integració continua: https://ca.wikipedia.org/wiki/Integraci%C3%B3_cont%C3%ADnua Entrega continua https://es.wikipedia.org/wiki/Entrega_continua https://codingpotions.com/jenkins-integracion-continua/ Elements bàsics i funcionament d’una Infraestructura àgil https://content.intland.com/blog/sdlc/source-control-management-best-practices ockers: https://www.javiergarzas.com/2015/07/que-es-docker-sencillo.html URLS Internes IMI http://confluence.ajuntament.bcn/pages/viewpage.action?pageId=561091938 Llibres tècnics de DevOps: http://llocs.ajuntament.bcn/llocs/ComInterna/GovernSeguretat/Qualitat/Pagines/Metodologia/Espai%20Agi le/6.Recursos-Agile.aspx ANNEX Informació addicional Dockers 11 Docker és un projecte open-source que proporciona un mode per automatizar el desplegament d’aplicacions dintre de contenidors de software. El nucli de Linux, que es troba al contenidor, permet un aïllament de recursos (CPU, memòria, E / S, xarxa, etc.) i no requereix iniciar cap màquina virtual. Docker amplia un format de contenidor comú anomenat Linux Containers (LXC), amb una API d'alt nivell que proporciona una solució de virtualització lleugera que executa processos de manera aïllada. Docker també proporciona espais de noms per aïllar completament la vista de l’aplicació de l’entorn operatiu, incloent arbres de procés, xarxa, identificadors d’usuari i sistemes de fitxers. La capacitat de proporcionar una abstracció de plataforma lleugera dins del contenidor Docker, sense utilitzar la virtualització, és molt més eficient per crear paquets de càrrega de treball transportables entre els núvols que l’ús de màquines virtuals. Per tant, els contenidors proporcionen una base real per moure les càrregues de treball en entorns híbrids o multi-núvols sense haver de modificar gaire o res de les aplicacions. Això implica que és possible i fàcil aconseguir un dels punts principals de la infraestructura àgil, l’escalabilitat. Docker ha compilat un registre públic d'aplicacions disponibles com a imatges Docker i la comunitat proporciona molts punts de salt per construir i executar les vostres pròpies aplicacions basades en contenidors. Un cop Docker està instal·lat i executant-se, es pot llençar una imatge d’aplicació Docker entrant: sudo docker run --rm -p 3000:300 image_name On el nom de la imatge és image_name, i estem mapejant el port 3000 de la màquina al port 300 publicat del contenidor. Hi ha alguns detalls més, però simplificant és així. S’ha de tenir en compte que el command "docker run" anterior executa una imatge anomenada nom_imatge. Si no troba la imatge al sistema local, comprovarà el registre públic de Docker i el cridarà, si es troba. El contenidor Docker és simplement una instància d’una imatge Docker, de la mateixa manera que les aplicacions són instàncies d’executables que existeixen a la memòria. Per tant, es poden llançar diverses instàncies aïllades de l’aplicació com a contenidors a un únic host. Si s’afegeix "-rm" a la comanda, com s'ha fet anteriorment, se li ordena a Docker que elimini el contenidor de la memòria un cop hagi completat la seva tasca. Això té l’efecte de suprimir els canvis a l’entorn local que l’aplicació pot haver realitzat, però manté la imatge cachejada. La creació d’una imatge Docker per a una aplicació requereix començar amb una imatge base del SO principal, que s’executa en Docker. Instal·la i configureu les eines necessàries i, a continuació, utilitza el "commit" de Docker per desar el contenidor com a imatge. Finalment, es fa un push al registre d’imatges del Docker públic o és manté privat. 12 Una altra manera de crear una imatge és tenir en compte els passos necessaris per construir la imatge en un fitxer Dockerfile preparat. Això automatitza el procés d’instal·lació i configuració de l’aplicació, creant un procés repetible. 13