4.2 La tubería de despliegue

Transcripción

1 4.2 Tema 4: Continuous delivery

2 Índice Gestión de configuraciones Construcción de builds Integración continua Gestión de entornos de prueba 2

3 (versión sencilla) John Ferguson Smart - Real-World Strategies for Continuous Delivery with Maven and Jenkins 3

4 Principios de automatización John Ferguson Smart - Real-World Strategies for Continuous Delivery with Maven and Jenkins 4

5 Sólo compilar una vez John Ferguson Smart - Real-World Strategies for Continuous Delivery with Maven and Jenkins 5

6 Elementos de una tubería de despliegue Sistema de control de versiones Compilación y construcción de binarios (builds) Repositorio de artefactos Renombrado de versiones (de builds y releases) Análisis de código Configuración de entornos Despliegue de binarios Ejecución de tests: unitarios, aceptación, funcionales, capacidad Monitorización de datos y publicación de informes 6

7 Tubería de despliegue (versión completa - Jez Humble) 7

8 Gestión de la configuración Configuration managent Configuration management refers to the process by which all artifacts relevant to your project, and the relationships between them, are stored, retrieved, uniquely identified and modified Jez Humble - Continuous Delivery En metodologías tradicionales la gestión de la configuración es un proceso costoso en el que hay que desarrollar una gran cantidad de documentación que asegure que todos los ítems de configuración del sistema y sus relaciones están identificados, registrados y monitorizados. En un enfoque ágil la gestión de la configuración tiene que ver además con la gestión del cambio y de la evolución del software y con su desarrollo incremental. 8

9 Objetivos de la gestión de la configuración Una buena gestión de la configuración permitirá: Reproducir cualquiera de nuestros entornos, incluyendo la versión del sistema operativo instalada, la configuración de la red, el stack de software, las aplicaciones instaladas y su configuración Realizar fácilmente un cambio incremental a cualquiera de estos ítems y desplegar el cambio en algunos o todos los entornos Comprobar el cambio que ha ocurrido en un entorno particular y recuperar el origen del mismo: quién lo ha hecho, qué se ha hecho y cuando se ha hecho Hacer posible que cualquier miembro del equipo obtenga la información necesaria y pueda realizar los cambios necesarios El elemento central de la gestión de la configuración es el sistema de control de versiones: Subversion, Mercurial o Git Permite acceder a cualquier versión de cualquier fichero almacenado Permite la colaboración de equipos distribuidos en el tiempo y el espacio 9

10 Cómo utilizar bien un sistema de control de versiones 1. Mantén absolutamente todo bajo el control de versiones Código fuente, tests, scripts de base de datos, scripts de construcción y despliegue, documentación, ficheros de configuración, librerías, etc. Información requerida para recrear los entornos de pruebas y producción en los que corre la aplicación: configuración de servidores, redes, sistemas operativos Debe ser posible recrear cualquier versión de cualquier entorno en el que corren las aplicaciones y analizar la historia de cambios 2. Sube diariamente los cambios al repositorio De esta forma se hacen públicos y todos los miembros del equipo pueden conocerlos Dos enfoques (no demasiado distintos) Una única rama de desarrollo con ramas de features de vida corta GitFlow con la rama master y la develop que hace de rama de integración continua 3. Utiliza mensajes de commit que tengan sentido 10

11 Aplicación = Configuración + Binarios + Datos Podemos cambiar una aplicación modificando cualquiera de los siguientes elementos que la constituyen: Ficheros de configuración que pueden cambiar el comportamiento de la aplicación en tiempo de construcción (build time), de despliegue (deploy time) o de ejecución (run time) Binarios obtenidos a partir del código fuente Datos (guardados en la BD, imágenes, vídeos, etc.) Aplicación Ficheros de configuración Binarios Datos Todos los elementos deben estar en el sistema de control de versiones y debemos poder recuperar una versión determinada Ficheros de configuración: Determinan valores necesarios para ejecutar y probar la aplicación: URL de servicios, URL del sistema de base de datos, etc. Modifican la aplicación: mensajes de error, imágenes e incluso su comportamiento (no recomendable) 11

12 Tipos de configuración La información de la configuración puede ser inyectada en la aplicación en bastantes puntos en el proceso de construcción, despliegue, test y lanzamiento Los scripts de build pueden obtener la configuración e incorporarla en los binarios en tiempo de construcción El software de empaquetado puede inyectar configuración en tiempo de empaquetamiento Los scripts de despliegue o instaladores pueden obtener la información necesaria o preguntar al usuario y pasarla a la aplicación en tiempo de despliegue o como parte del proceso de instalación La aplicación misma puede conseguir la configuración en tiempo de arranque (startup time) o en tiempo de ejecución Mala práctica, porque los binarios deberían ser los mismos en todos los entornos 12

13 Ejemplo de gestión de configuraciones en Java Conjunto de tuplas (propiedades) Se definen en ficheros de propiedades Formas de gestionar distintas configuraciones: Distintos ficheros: myapp/config/dev-application.properties myapp/config/test-application.properties myapp/config/uat-application.properties myapp/config/prod-application.properties En el proceso de despliegue el fichero correcto se coloca en /home/myapp/config/application.properties firstname=lokesh lastname=gupta blog= technology=java Configuration Management With RESTful Git 13

14 En cada entorno se deben copiar ficheros específicos Desarrollo UAT Producción ToDoList v 2.1 Develop Conf ToDoList v2.1 Develop Binarios ToDoList v2.1 Datos ToDoList v2.1 Develop ToDoList v 2.1 UAT Conf ToDoList v2.1 UAT Binarios ToDoList v2.1 Datos ToDoList v2.1 UAT ToDoList v 2.1 Prod Conf ToDoList v2.1 Prod Binarios ToDoList v2.1 Datos ToDoList v2.1 Prod 14

15 Variables de entorno Otra forma de gestionar la configuración es hacer que el proceso de despliegue inicialice variables de entorno y obtener sus valores en los binarios Sistema usando en Heroku (ver Configuration and Config Vars) Heroku también permite gestionar distintas configuraciones remotas de una misma aplicación La aplicación lee los valores de las variables del entorno. Por ejemplo, en Java: String databaseuser = System.getenv( DB_USER ); String databasepasswd = System.getenv("DB_PASSWORD")) 15

16 Gestión de configuración en Play En Play Framework se definen las variables de configuración en el fichero application.conf : # Database configuration # ~~~~~ # You can declare as many datasources as you want. # By convention, the default datasource is named `default` # db.default.driver=org.h2.driver db.default.url="jdbc:h2:mem:play" # db.default.user=sa # db.default.password="" Se pueden cargar otros ficheros de configuración usando el comando start start -Dconfig.file $ start -Dconfig.file=/opt/conf/prod.conf $ start -Dconfig.url= En la aplicación se pueden obtener los valores de las variables declaradas val configuration = Configuration.load() val isenabled = configuration.getstring("engine.isenabled") 16

17 Gestión de configuración en Play Otra opción: definir ficheros alternativos y cargarlos de forma explícita Se puede usar una variable de entorno en la que guardamos el tipo de entorno (dev, test, prod) para cargar el fichero correspondiente: application.dev.conf, application.test.conf, application.dev.conf object Global extends GlobalSettings { override def onloadconfig(config: Configuration, path: File, classloader: ClassLoader, mode: Mode.Mode): Configuration = { val appmode = configuration.getstring("application.mode") val modespecificconfig = config ++ Configuration(ConfigFactory.load( application. +appmode+".conf")) super.onloadconfig(modespecificconfig, path, classloader, mode) } } 17

18 Tubería de despliegue (versión completa - Jez Humble) 18

19 Construcción de builds Verbo to build : construir un sistema (fichero o conjunto de ficheros) que se van a desplegar (copiar) en un entorno (computador o conjunto de servidores) Entendemos por build el conjunto de ficheros (binarios y de configuración) obtenidos a partir de la compilación del código fuente de un proyecto y su configuración para ser desplegado y lanzado en un entorno Un elemento fundamental son las dependencias: Entre ficheros compilados y ficheros de configuración Entre ficheros compilados y paquetes externos Entre ficheros compilados y entornos en los que se van a desplegar Fundamental la automatización y no depender del IDE 19

20 Tareas comunes en el build Compilación (java ->.class) Selección de ficheros de configuración (XML o.properties) Lanzamiento de pruebas unitarias Empaquetado (construcción de JARs) y copia en repositorio de artefactos Despliegue 20

21 Automatización del build Lenguajes y herramientas de build Make (C, Unix) Ant y Maven (Java) Rake (Ruby) - Buildr (Scala) Gradle (Java, Scala, etc.) sbt (Scala, Play Framework) 21

22 Gestión de las dependencias Tanto Maven como sbt utilizan un sistema similar para definir las dependencias de la aplicación con otras librerías. Está basado en el proyecto Ivy de Apache. Es posible definir dependencias distintas para tests Es posible definir dependencias basadas basadas en el número de versión: latest.integration, o [1.0,) Documentación Play Framework - Managing library dependencies Apache Ivy - Dependencies 22

23 Build en Play (1) Fichero project/build.scala object ApplicationBuild extends Build { val appname = "todolist" val appversion = " val appdependencies = Seq( // Add your project dependencies here, jdbc, anorm, "postgresql" % "postgresql" % " jdbc4" ) } val main = play.project(appname, appversion, appdependencies).settings( // Add your own project settings here ) 23

24 Build en Play (2) Comando para compilar y preparar para su ejecución una aplicación play $ play clean compile stage 1. Descarga todas las dependencias al directorio target/staged 2. Empaqueta los fuentes en target/scala-2.10/todolist_ sources.jar 3. Crea y empaqueta la documentación en target/scala-2.10/todolist_ javadoc.jar 4. Compila y empaqueta los binarios en target/scala-2.10/todolist_ jar 5. Copia el JAR con el binario al directorio target/staged 6. Crea el comando target/start con el que arrancar la aplicación 24

25 Build en Play (3) Comando para empaquetar una aplicación Play $ play clean compile dist 1. Hace todo lo que stage 2. Crea el fichero ZIP dist/todolist zip con todos los JARS de los que depende la aplicación 3. Dentro del ZIP guarda el comando start Ejemplo práctico sobre cómo poner en producción una aplicación Play (Alvin Alexander) 25

26 Número de versión del build en Play Para crear el número de versión a partir de una variable de entorno: $ export BUILD_NUMBER=203 $ play clean compile stage object ApplicationBuild extends Build { val appname val appversion = "todolist" = "1.0." + System.getenv( BUILD_NUMBER") Para crear el número de versión a partir de una propiedad especificada en línea de comando: $ play -Dbuild.number=203 clean compile stage object ApplicationBuild extends Build { val appname val appversion = "todolist" = "1.0." + System.getProperty( build.number ) 26

27 Repositorio local de artefactos Ya está Maven bajándose todo Internet Es conveniente mantener las dependencias con JAR externos en un repositorio local de artefactos Maven (o sbt) busca en el repositorio local antes de ir al repositorio Maven 2 estándar Dejamos también ahí los builds compilados de nuestros proyectos y librerías de utilidad Aplicaciones que gestionan el repositorio local y lo mantienen sincronizado con los repos remotos: artifactory, Nexus 27

28 Pruebas unitarias y de integración Cada desarrollador debe probar los tests unitarios en sus máquinas locales antes de hacer un push Diariamente el servidor de Integración Continua: Ejecuta todos los tests unitarios en la rama principal y genera el build Despliega en el entorno de integración para ejecutar los tests de integración Es conveniente separar los tests unitarios de los tests de integración y poder ejecutarlos unos independientemente de otros 28

29 Tests de integración y ramas de características Un problema cuando se trabaja con ramas de características es que es difícil automatizar los tests de integración Algunos servidores de IC permiten definir estrategias automáticas de build para cada rama (por ejemplo, Atlassian Bamboo) Solución simple: Hacer los tests de integración en la rama principal Desarrollar en la rama principal usando interruptores de características que son activados por los tests unitarios y de integración Si se crean ramas de características que sean short-lived de verdad y que no duren más de dos o tres días. Mezclar tras ese tiempo en la rama principal y pasar los tests de integración. 29

30 Calidad de código Herramientas para el análisis de código estático en Java: PMD, Findbugs, Checkstyle (análisis en RebelLabs) Hay que tomarse la calidad del código en serio Integrarlo en el servidor de CI para que si no se pasan las reglas, falle el build Es mejor definir pocas reglas y ser estrictos que definir muchas reglas y no cumplirlas Importante para la calidad del código: dominar el IDE Uno de los menos conocidos y mejores IDE para Java (y Scala): IntelliJ IDEA (disponible versión gratuita) 30

31 Integración continua Diariamente la aplicación se integra y se ejecutan las pruebas unitarias y de integración Proceso automático: Se baja la última versión del control de versiones Se lanza el script de build Se publican los resultados de los tests en una página web accesible a todo el equipo Herramientas Bamboo Cruise Control Jenkins Go TravisCI 31

32 Ejemplo de integración continua con Jenkins Tomado de John Ferguson Smart - Real-World Strategies for Continuous Delivery with Maven and Jenkins 32

33 33

34 34

35 35

36 36

37 37

38 38

39 39

40 40

41 41

42 42

43 43

44 44

45 45

46 46

47 47

48 48

49 49

50 50

51 51

52 52

53 53

54 54

55 55

56 56

57 57

58 58

59 Tubería de despliegue Domingo Gallardo, DCCIA, Univ. Alicante 59

60 Entornos de prueba La última parte de la tubería de despliegue consiste en probar los builds compilados en distintos entornos de prueba Distintos entornos Tests de integración y aceptación UAT Tests de capacidad Producción A su vez, cada uno de ellos puede tener distintas configuraciones y estar formado por múltiples máquinas Pruebas con distintos clientes y navegadores Pruebas con distintas bases de datos y servicios (si se va a desplegar la aplicación en distintos entornos de producción) 60

61 Desplegar de la misma forma Es esencial usar el mismo proceso para desplegar en los distintos entornos Características diferentes de los entornos en ficheros de configuración, no en el script de despliegue Distintas IP (como mínimo) Distintos sistemas operativos Distinta configuración del middleware (localización de las bases de datos y servicios externos) El script de despliegue debería ser el mismo en todos los entornos: 1. Configurar el entorno 2. Desplegar los binarios 3. Poner en marcha las aplicaciones y comprobar que funcionan (pruebas de humo) 61

62 Gestión de entornos de prueba y producción Cuanto menos control tenemos sobre el entorno en el que el código se ejecuta, más probabilidades hay de comportamientos no esperados Nos interesa tener control sobre todos y cada uno de los bits del entorno en el que se despliega nuestra aplicación Los cambios en los entornos deben realizarse sólo mediante procesos automatizados y registrados En cada entorno se debe definir claramente (y guardar en el control de versiones): Configuración Software que se despliega Topología de la red Estado El objetivo final es necesitar solo dos parámetros para realizar el despliegue: Identificador del entorno de despliegue Identificador del build a desplegar 62

63 Herramientas de empaquetado En cada entorno hay que desplegar: Conjunto de ficheros binarios Ficheros de configuración Ficheros estáticos en el control de versiones Es muy recomendable utilizar un sistema de empaquetado para desplegar la aplicación en el entorno: RPMs en el mundo Linux Cada release se empaqueta y se sube a un repositorio Las herramientas de gestión de entornos se encargan de instalar el paquete de la misma forma que instalan el resto de software 63

64 Virtualización de entornos La virtualización permite crear y configurar distintos entornos en una única máquina física Muy económico Entornos controlables Ejecuciones repetibles Software más popular VirtualBox (Oracle) vsphere Hypervisor (VMware) 64

65 Vagrant Software open source, creado por Mitchel Hashimoto Escrito en Ruby Permite automatizar la creación, puesta en marcha, configuración y aprovisionamiento de entornos virtuales Vagrant web site 65

66 Instalación de Vagrant Funciona inicialmente con VirtualBox Fácil instalación mediante paquetes nativos del SO Se instala el comando vagrant Posibles comandos: 66

67 Inicializando y descargando una box Se crea un directorio y se ejecuta el comando vagrant init para crear un fichero Vagrantfile que contiene una configuración por defecto $ mkdir prueba-vagrant $ cd prueba-vagrant $ vagrant init Se descarga una máquina virtual vacía (box) de una URL con el comando vagrant box add nombre URL $ vagrant box add precise32 Downloading box from URL: Extracting box...te: 568k/s, Estimated time remaining: 0:00:02)) Successfully added box 'database' with provider 'virtualbox'! 67

68 Boxes Las boxes son esqueletos de máquinas virtuales de la plataforma de virtualización con la que Vagrant esté trabajando Lista de boxes oficiales: Lista de boxes de la comunidad: Contienen lo básico para poder poner en marcha Vagrant: Gestor de paquetes ssh Usuario ssh Chef o Puppet (aunque no es necesario, lo veremos después) Se guardan en el directorio ~/.vagrant.d/boxes 68

69 Cómo usar una box Un primer ejemplo Fichero Vagrantfile Vagrant.configure("2") do config config.vm.box = "precise32" end Para poner en marcha la máquina virtual y conectarse por ssh: $ vagrant up $ vagrant ssh 69

70 Carpeta compartida Vagrant comparte automáticamente el directorio de la máquina host (el directorio con el fichero Vagrantfile) en el directorio /vagrant de la máquina virtual $ vagrant up Bringing machine 'default' up with 'virtualbox' provider... [default] Booting VM... [default] Waiting for machine to boot. This may take a few minutes... [default] Machine booted and ready! [default] Mounting shared folders... [default] -- /vagrant [default] VM already provisioned. Run `vagrant provision` or use `--provision` to force it $ vagrant ssh Welcome to Ubuntu LTS (GNU/Linux generic-pae i686) * Documentation: Welcome to your Vagrant-built virtual machine. Last login: Fri Sep 14 06:22: from vagrant@precise32:~$ pwd /home/vagrant vagrant@precise32:~$ ls /vagrant Vagrantfile 70

71 Aprovisionamiento Es posible automatizar la instalación de software en las máquinas virtuales definiendo un script en el fichero bootstrap.sh en el mismo directorio del Vagrantfile: #!/usr/bin/env bash apt-get update apt-get install -y apache2 rm -rf /var/www ln -fs /vagrant /var/www Y añadiendo una instrucción en Vagrantfile: Vagrant.configure("2") do config config.vm.box = "precise32" config.vm.provision :shell, :path => "bootstrap.sh" end 71

72 Puesta en marcha El comando vagrant reload --provision vuelve a lanzar la máquina virtual y ejecuta el aprovisionamiento: $ vagrant reload -provision... se ejecuta el script bootstrap.sh $ echo "Hola mundo" > hola.txt $ vagrant ssh vagrant@precise32:~$ wget -qo /hola.txt Hola mundo 72

73 Configuración de la red El fichero Vagrantfile permite también configurar la red de la máquina virtual con distintas opciones Reenvío de puertos Asignación de dirección IP estática Definición de redes privadas entre máquinas (documentación de Vagrant) Ejemplo de reenvío de puertos Vagrant.configure("2") do config config.vm.box = "precise32" config.vm.provision :shell, :path => "bootstrap.sh" config.vm.network :forwarded_port, host: 4567, guest: 80 end Si hacemos vagrant reload podremos acceder en la máquina host al servidor web en :

74 Múltiples máquinas Es posible controlar distintas máquinas con un único Vagrantfile Vagrant.configure("2") do config config.vm.provision "shell", inline: "echo Hello" config.vm.define "web" do web web.vm.box = "apache" end config.vm.define "db" do db db.vm.box = "mysql" end end Es posible arrancar, conectarse, etc. a cualquier máquina con vagrant up <machine-name> Es posible comunicar una máquina con otra a través de la red privada 74

75 Otros comandos vagrant halt: para la máquina vagrant destroy: elimina el estado de la máquina (no borra la box) vagrant status: muestra el estado de las máquinas 75

76 Herramientas de gestión de entornos Por defecto la configuración (aprovisionamiento) de la máquina Vagrant se hace con un script de shell Es posible utilizar otras herramientas de mayor nivel, independientes del shell y del SO usado, como Puppet o Chef Vagrant.configure("2") do config config.vm.provision "puppet_server" do puppet puppet.puppet_server = "puppet.example.com" puppet.puppet_node = "node.example.com" puppet.options = "--verbose --debug" end end 76

77 Introducción a Puppet Permite automatizar la gestión toda la infraestructura de máquinas de una empresa Terminología: Nodo: máquina que mantiene una configuración determinada Puppet master: servidor de Puppet que chequea la configuración de los nodos cada 30 minutos Puppet agent: agente de Puppet que se ejecuta en cada nodo y se comunica con el Puppet master Estado deseado: Configuración definida para cada uno de los nodos Cada nodo envía al Puppet master datos sobre su estado actual Si un nodo no se encuentra en la configuración deseada, el maestro le envía detalles de su configuración y el agente realiza los cambios necesarios en el nodo para volver al estado deseado 77

78 Introducción a Puppet 78

79 Introducción a Puppet 79

80 Descripción de la configuración de un nodo La configuración de un nodo se describe mediante la definición de recursos Cada recurso es una instancia de un tipo de recurso, tiene un nombre, unos atributos (definidos por el tipo) y unos valores para cada atributo Puppet usa su propio lenguaje para definir los recursos user { 'dave': ensure => present, uid => '507', gid => 'admin', shell => '/bin/zsh', home => '/home/dave', managehome => true, } En los recursos se define el estado deseado 80

81 Tipos de recursos Es conveniente tener a mano la chuleta de tipos de recursos The Trifecta file package service Otros importantes notify exec cron user group 81

82 Consola de administración La versión enterprise de Puppet (gratuita hasta 10 nodos) tiene herramientas y utilidades para simplificar la gestión, como la consola de administración 82

83 Vídeo de Puppet enterprise 83

84 Bibliografía de ampliación Martin Fowler - Continuous Integration Jez Humble, Continuous Delivery, Addison Wesley 2011 Web y blogs de Thoughtworks sobre Continuous Delivery 84