DEVOPSUNA BREVE INTRODUCCIÓN

https://chrodriguez.github.io/devops-short-intro/

AGENDAPresentaciónInteracción entre infraestructura y desarrolloNecesidad de ambientes independientesSoluciones y más problemasDevOpsHerramientas

PRESENTACIÓN

PRESENTACIÓN PERSONALDocente en UNLPTrabajé en IT mayormente de 2000 a 2007Dicté cursos de CCNA/RedHat/Solaris/IRIXA partir de 2006 me aboqué al desarrollo web ycoordinación de proyectos de software

Empecé con Devops en 2012

Trabajos freelance de ITCapacitación sobre chef 2013

CONTRIBUCIONES AL SLMi per�l en

(Kettle)

Varias recetas de chefVarias gemas de rubyPlugins para Symfony 1.x

GithubRuby Scripting para Spoon de Pentahochef-provisioning-vspherechef-provisioning-fogRedmine SAML pluginRedmine per project sender pluginxmltv tv_grab_arVDR - The Video Recorder Disk

EXPERIENCIA RELEVANTE EN LA TEMÁTICAGestión de la infraestructura: email y web en SMN (2005 al2007)Consultoría en SENASA (2007 a la fecha)

De�nición e implementación de un LDAP replicado eintegrado con ADImplementación de SSOArquitectura, implementación y mantenimiento delemail

Portal del diario El Día (2012 a la fecha)Arquitectura y desarrollo del productoDiseño de la arquitectura inicial de su infraestructura

INTERACCIÓN ENTRE IT YDESARROLLO

INTRODUCCIÓNCada organización tiene sus particularidades, aunque envarios lugares coincide que:

Se conforman grupos de trabajo disjuntos paradesarrollo e infraestructuraDesarrollo es un cliente de infraestructuraInfraestructura atiende cuestiones complejas que soncríticasNo hay diálogo �uido entre las partesDesarrollo aplica metodologías ágiles, mientras queinfraestructura lidia con problemas en los que es difícilseguir el ritmo que solicita desarrollo

ANALIZAREMOS LA PROBLEMÁTICA DESDELa perspectiva de desarrolloLa perspectiva de infraestructuraLa puesta en producción: el momento en que desarrollo einfraestructura interactúan

LA PERSPECTIVA DEDESARROLLO

AMBIENTES COMPLEJOSLas aplicaciones ya no son las tradicionales arquitecturasde tres capasLas herramientas a utilizar ya no sólo se conforman de unlenguaje, una base de datos SQL y un frameworkNecesidad de ambientes independientes entre losdesarrolladores

Algunas organizaciones promueven un ambiente comúnde desarrollo donde toda la complejidad se concentra enun cluster compartido por N desarrolladores

Di�cultad para involucrar nuevos integrantesExceso de tiempo para aprender a gestionar lainfraestructura en vez de programar

GESTIÓN DE PROYECTOSIndependientemente de la gestión de proyectos teórica ycomercial hacemos hincapié en los procedimientos paratrabajarRespetar estándares de codi�caciónUtilizar alguna herramienta de versionado de código: GIT

: trabajo con estrategias de branches y manejo dereleasesPermisos sobre las branches: desarrolladores con másexperiencia revisan el código de programadores con menosexperiencia. Por ejemplo:

git-�ow

�ujo tipo GitHub

GESTIÓN DE PROYECTOSRelacionar los tickets/versiones del producto enproducción, con los procedimientos/�ujos de�nidosanteriormente

Esto mismo sugiere git-�ow con los Aplicar buenas prácticas de calidad

TDD con alta coberturaTests de aceptación

Aspiraciones para alcanzar:Integración continuaDelivery continuoDeployment continuo

hot�x branches

DEPLOYMENTSPoner una versión de un producto nuevo en producciónpuede

Ser simple si el ambiente ya existe y no requiere nuevasdependenciasSer complejo si el producto a instalar requiere nuevasdependencias

Revisar si cada una de las dependencias satisfacen susrequerimientos

¿El código provee de ésta información?Automatizar los deployments simpli�cando las tareasrepetitivas

Usar scripts caseros o herramientas de automatizacióncomo Capistrano, Ansible, Chef, Puppet, Salt, etc

como Capistrano, Ansible, Chef, Puppet, Salt, etc

METODOLOGÍAS ÁGILESEl hace énfasis en los siguientes valores:

Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan

Aplicando esta metodología se promueve lanzar nuevasversiones en períodos muy cortos de tiempo:

Aparecen deployments diarios e incluso varias veces aldíaResponder a los requerimientos ágiles requiere unaoperatoria ágil desde IT

Si esto no sucede se produce un cuello de botella

mani�esto ágil

TDDCuando deseamos apegarnos a los requisitos de QA esbueno aplicar testsLos tests deben controlarse por un área de QA en cadaetapa del desarrollo, estableciendo políticas de aceptaciónpara cada etapa

TDDEjemplos de políticas:

El código no es revisado antes de mergerarse si no pasanlos test de unidad, funcionales e integración. Tampoco siel analizador de código no garantiza se respetanestándaresUn release no pasa a producción si no pasa todos lostests de unidad, funcionales e integración

Es importante poder aplicar . Sinembargo, armar un ambiente de éste tipo no es trivial ydepende del área de IT

Integración Continua

VERSIONES DE LIBRERÍAS Y LENGUAJESEs común que los desarrolladores surfeen la cresta de lasolas

Utilizan versiones muy actuales de determinadosproductos que complican los ambientesAlgunos lenguajes no permiten, de forma simple, tener enel sistema más de una versión de una misma librería olenguaje. Por ejemplo PHP

Esto crea diferencias entre el ambiente de desarrollo yproducción

Justamente, ésta es la brecha que debemos achicar

GESTIÓN DE VERSIONESSi bien el código se maneja con versiones y GIT/SVNmantiene una identi�cación de cada commit, se necesitamanejar un versionado de releases amigable

contribuye a entender qué signi�caque un release 2.5.1 pase a la versión 2.5.2 o 2.6.0¿De qué forma es posible mantener la traza del modelo dedatos respecto de las versiones de código?

Semantic Versioning

ACCESO AL AMBIENTE DE PRODUCCIÓNSiempre es necesario acceder a un recurso en producciónAcceso al dump o código completo

El código no debería ser necesario si se utilizanversiones que respetan el versionado semver o desde unSCMLos datos de una aplicación en producción (no la base dedatos) pueden ser necesarios para realizar una prueba

A veces, por requerimientos de seguridad o legales, lainformación debe obtenerse ofuscadaOtras veces, alcanza con un dato antiguo que puedeextraerse desde un backup

REPLICA DEL AMBIENTE DE PRODUCCIÓNPoder obtener un ambiente similar al productivo tiene unvalor muy grande para desarrollo dado que permite:

Veri�car problemas of�ineProbar nuevos releases antes de pasarlos a producciónAl cliente veri�car en una instancia previa al pasaje aproducción de un cambioVeri�car tiempos de actualizaciónetc

ESTADÍSTICAS Y MONITOREOLas estadísticas generalmente se utilizan por IT paraconocer cómo se comporta un servidor o recursoDesde desarrollo hay varios aspectos que pueden medirsepara luego ayudar a identi�car problemas:

Pro�ling de cada middleware de una aplicación: ORM,servicios externos, renderizado, caching, tiempos derespuesta, etcErrores en la aplicación

Contar con la información estadística nos permite conocerel comportamiento normal de nuestra aplicación

Desconocer estos datos es manejar con el parabrisaslleno de barro

ESTADÍSTICAS Y MONITOREOCuando un valor se aleja de la media o el desvío estándarpor más de un tiempo aceptable, entonces podemosestablecer una alertaGeneralmente el monitoreo y las alertas se establecensobre los servicios o sobre los recursos que son cruciales, yante el mínimo problema se noti�ca a determinadosusuarios

Esto produce innumerables alertas que terminan siendoignoradas

El monitoreo debería concentrase en lo que es de valorpara el usuario que utiliza el recurso y no en las partes queconstituyen el servicio

LA PERSPECTIVA DEINFRAESTRUCTURA

SERVICIOS CRÍTICOSHoy día, servicios como el DNS o Mail se consideranfuncionales per se.En el caso del DNS, utilizar TTL pequeños promueve laresilenciaLas organizaciones ya utilizan virtualización como unasimpli�cación de sus Datacenters, gestión de lainfraestructura, snapshots de VMs y migraciones encaliente

Algunas organizaciones desconfían de la virtualizaciónpara algunos servicios críticos para su negocio. Porejemplo base de datos.

SERVICIOS CRÍTICOSEs común que la gestión de cuentas de usuarios siga siendouna tarea más del área de infraestructuraMantener actualizadas las versiones de cada serviciocrítico evitando posibles vulnerabilidades

Atender a todas las cuestiones mencionadas demanda tiempo y esfuerzo que no dejan lugar para lainvestigación de nuevas tendencias, prácticas ágiles o automatización

GESTIÓN MANUAL DE LOS SERVICIOS E INFRAESTRUCTURAEn los grupos de desarrollo, es habitual programar oautomatizar cualquier paso repetible, pero no siempreaplica esto mismo en infraestructuraLas tareas repetitivas se suelen automatizar con scripts enshell que utilizan herramientas auxiliares: awk, perl,python, sed, php, bc, etc

Soluciones muy acopladas que no pueden reusarse entodos los casos

EL CLIENTE MÁS DEMANDANTE: DESARROLLOEl área de desarrollo es un área más a la que se le brindaservicioEntre los servicios ofrecidos, pueden mencionarse:

Hosteo de aplicaciones: infraestructura deja un huecodonde desarrollo puede subir código. Se debedeterminar la forma en que se dan los accesos y a qué seda accesoVirtualización: se ofrece un servicio de virtualización deltipo PAAS. Desarrollo gestiona su infraestructuraDeploy de aplicaciones: Sería como el caso de hosteo deaplicaciones, pero además, es responsabilidad del áreade infraestructura ejecutar el deployment en producción

EL CLIENTE MÁS DEMANDANTE: DESARROLLOContinuando con los servicios que se brinda a desarrollo:

Gestión de ambientes: a medida que se vanconsolidando mejor los grupos de desarrollo einfraestructura, surge la posibilidad de aislar ambientes,como por ejemplo: pruebas, desarrollo, staging, QA,producciónServicios para la gestión de proyectos: es común queademás de los servicios críticos, el área deinfraestructura brinde servicios que permitan a losdesarrolladores manejar tickets, versionado, chat, irc,integración continua, etc

AMBIENTES HETEROGÉNEOSHasta no hace mucho tiempo e incluso en la actualidad,existen organizaciones que siguen imponiendo lahomogeneización de sus ambientesLos hechos demuestran que la homogeneización deherramientas informática fracasaron en pos dearquitecturas heterogéneas

AMBIENTES HETEROGÉNEOSLa heterogeneidad trae problemas al área deinfraestructura

Surgen nuevas tendencias que se convierten enrequisitos para los nuevos desarrollos: Ruby, NodeJS,Erlang, Redis, Memcached, Websockets, MongoDB,Hadoop, Spark, etcCómo conocer qué es lo mejor para cada caso:

¿Cómo monitorear?¿Cómo backupear?¿Es seguro?

COMPROMISO DE LA SEGURIDAD POR HOSTINGCuando las aplicaciones se hostean en servidores propiossin un conocimiento claro de cómo se realizó el desarrollose corre un alto riesgoSe disponen de varias herramientas que permitenresguardar la seguridad general

Asegurar estos ambientes complica la infraestructuraSi el hosting es compartido en un mismo servidor, esnecesario garantizar la independencia de los aplicativos

POLÍTICA DE BACKUPS PARA LAS APLICACIONESInfraestructura posee políticas de backups claras para susservicios críticosCuando se deben de�nir para una aplicación, el área dedesarrollo conoce mejor qué backupear

Desconociendo este dato, generalmente se utilizansnapshots o backups de toda la aplicación

Dependiendo del esquema de trabajo empleado paraobtener el desarrollo, puede que se logre disponer de unversionado de la aplicación que garantice que el códigocompleto puede obtenerse tal cual la copia está enproducción

En este caso, el backup se limita a las bases de datosempleadas y los datos generados

ESTADÍSTICAS Y MONITOREO DE APLICACIONESEn infraestructura, las estadísticas y monitoreo se realizasobre lo que es de su interés. Generalmente esto excluyelas aplicacionesConocer el comportamiento de una aplicación (estadística),nos permite tomar decisiones y ver cuál es elcomportamiento normal de la misma. Sin embargo, paraello los desarrollos deben:

Hacer buen uso y manejo de LogsUsar herramientas de pro�ling que permitan recolectardatos útiles para evaluar el comportamiento de unaaplicación

Y MUCHO MÁS...El área de infraestructura tiene que atender otras muchascuestiones como por ejemplo:

Vencimientos de certi�cadosGestión de SPAM para evitar la llegada, así como elbloqueo de nuestros MTA para el envío de SPAM desdenuestros servidoresProblemas de hardware habitualesPruebas de restauración de backupsMigraciones de datos entre productos. Por ejemplo, unaorganización pudo haber utilizado en toda su historia,diferentes productos para su correo electrónico: uw-imap, cyrus, courier y dovecot

PUESTA EN PRODUCCIÓNEL MOMENTO EN QUE DESARROLLO E INFRAESTRUCTURA

INTERACTÚAN

PUESTA EN PRODUCCIÓNDeben de�nirse procedimientos para:

Deploy de nuevas aplicacionesUpgrade de aplicaciones existentesRollback de aplicaciones actualizadas

Considerar la forma en que se actualizan bases de datos

DEPLOY DE NUEVAS APLICACIONESInstalar una nueva aplicación en producción es el caso idealdonde se arranca sin historia previaSe deben estipular una serie de pasos que deben seguirse:

La aplicación corre con un usuario determinadoSe debe crear una estructura de directorio previaInstalación de servicios que son requeridos

Rotación de logsServicios asincrónicosCreación de usuarios y bases de datos necesarios

Escalado de la aplicaciónDe�nir y aplicar las políticas de backupsEstadísticas y monitoreo

UPGRADE DE APLICACIÓN EXISTENTERevisar si alguno de los puntos considerados en el casoanterior varíaActualizar el código, preservando en lo posible la versiónanteriorIntegrar de ser posible con algún esquema de proxyreverso que permita trabajar en caliente y realizar

Relación con

bluegreen deployments

A/B Testing

ROLLBACK DE APLICACIÓN ACTUALIZADAAnte algún fallo inmediato detectado luego de realizar unupgrade, se desea volver atrásSiempre que no se haya realizado algun cambio en la basede datos destructivo que no requiera restaurar la base dedatos, entonces debería ser simple realizar un rollbackSi se preserva el código de la versión anterior, entonces conlink simbólicos se puede realizar un rollback rápidamenteSi se utiliza blue green deployments, entonces sólo secambia el proxy reverso

ACTUALIZACIONES DE LAS BASES DE DATOSEl versionado del código resuelve la simplicidad deactualizar y realizar rollbacks

Con las bases de datos no sucede lo mismoVersionar la estructura de la base de datos con el código noaporta demasiado

Necesitamos saber cómo aplicar un parche a un modeloen un momento y poder deshacerlo en caso de roolbackTratar que estos parches sean idempotentesNo siempre sucede que un parche a una base de datostenga vuelta atrás

Algunos parches pueden ser costosos en bases de datosgrandes

OTRAS CUESTIONES A CONSIDERAR EN LA PUESTA ENPRODUCCIÓN

Ante un cambio de versión es aconsejable noti�car a losusuarios con anticipación de la interrupción del servicio

Esto requiere conocer el dominio de usuarios afectadosProgramar el envío masivo de correosPlani�car y noti�car con anticipación mejoran la calidaddel servicio

Gestión de contratosDependiendo de la relación comercial que exista con losclientes, el hosteo de una aplicación podrá tener unvencimiento que deberá deshabilitar el acceso hasta noregularizar la situación

NECESIDAD DE AMBIENTESINDEPENDIENTES

INTRODUCCIÓNNo disponer de ambientes implicaría:

Tener código versionado o noLa única versión que es igual a producción, es la deproducción

Porque alguien cambió algo en producción que nofuncionabaPorque luego de cambiar algo en producción, no seactualizó el código versionado

Las pruebas se realizan en la pc del desarrollador odirectamente en producción

Pareciera ser imposible que esto suceda, pero muchas organizaciones siguen gestionando susdesarrollos de esta forma

AMBIENTESEs común ver alguno de estos ambientes en unaorganización:

Desarrollo: el ambiente de desarrollo es en el cuál losdesarrolladores construyen el softwareTesting: es el ambiente donde se publica el software enfase de pruebas para que sea probado por un grupode�nido de personas, entre las que se incluye el usuario�nal o representantes del mismo

AMBIENTESPre-producción: es la instancia previa a producción, yconsiste en un ambiente replicado e idéntico al productivo.En este entorno se veri�ca el correcto funcionamiento dela aplicación y se realizan los ajustes necesarios en caso deno ser así, evitando que los problemas se descubran en elpasaje a producciónProducción: es el ambiente que tiene todos los serviciosproductivos. Este ambiente cuenta con políticas estrictasen cuanto al acceso y la administración del mismo.

SOLUCIONES Y MÁSPROBLEMAS

INTRODUCCIÓNEn este apartado veremos qué metodologías y/o

herramientas han surgido para solucionar algunas de lasnecesidades mencionadas según la perspectiva de desarrollo

e infraestructura

Asimismo, mostraremos que estas soluciones introdujeronnuevos problemas

VIRTUALIZACIÓNExisten diferentes alternativas de virtualización, quepueden ser unas mejores que otras según la licenciadisponible, las necesidades o contexto de usoEl uso de cualquier herramientas disponible paravirtualizar, ofrece mejoras substanciales para:

Backup de VMsSimpli�can la gestión de servidores, ahora virtuales, quecuando se realizaba físicamenteMigraciones en caliente de VMs entre equipos físicosMejor aprovechamiento de recursos de hardwareInstalación de SO basada en templates que permitedisponer rápidamente de servidores pre-instalados

COMPLICACIONES CON LA VIRTUALIZACIÓNSin una solución de storage no es posible aprovecharmuchas de las ventajas de éstas herramientasGeneralmente la características más atractivas se proveenen versiones licenciadasLa virtualización genera más servidores que cuando seutilizaban servidores físicos:

Esto se debe a que un servicio aislado es más seguro eindependiente, con lo cuál su reemplazo o actualizaciónse simpli�caPor esta razón, crece el uso de VMs, di�cultando elmantenimiento de su inventario que rápidamente sedesactualiza

UN SERVIDOR QUE HOSTEA MÚLTIPLESAPLICACIONES

Cuando varias aplicaciones comparten requerimientos, estentador reutilizar el mismo servidor para hostearmúltiples aplicaciones

Se simpli�ca la gestión del servidorSe compromete la seguridad de todas las aplicacionesinstaladas

Para determinar cómo compartir un mismo servidor entreaplicaciones, es conveniente realizar un análisis del que seobtenga una matriz de aplicaciones agrupadas segúncriticidad

NUEVAS TENDENCIASSurgen herramientas que requieren investigación antes desu puesta en producción

nginx, HA-proxy, trae�k, varnishMontar aplicaciones en lenguajes poco usuales

Python, Ruby, Erlang, NodeBases de datos NoSQLMongoDB, RedisSistemas de colas AMQP: RabbitMQ, Qpid

ALTA DISPONIBILIDAD / FAILOVER /ACTUALIZACIONES

Los stacks de un servicio determinado se compone departes diferentes que podemos requerir garantizar altadisponibilidad y/o failoverActualizar un servicio es una tarea artesanal y costosa

Sobre todo si es un servicio distribuido con muchasdependencias

DEVOPS

DEFINICIÓNEl término DevOps tiene varias interpretaciones por ser relativamente nuevo y ciertamente amplio

Básicamente DevOps promueve:

Maximizar la colaboración entre las áreas de desarrollo einfraestructura

OBJETIVOAplicar metodologías ágiles tanto en desarrollo como eninfraestructuraLograr implementar �ujos rápidos de trabajo plani�cadoIncrementar la con�abilidad, estabilidad y seguridad de losambientes productivos

ORÍGENESAproximadamente en el año 2009 ante la convergencia dediferentes movimientos:

Las conferencias Velocity, en particular la presentación

Los movimientos de:Infrastructure as codeAgile infrastructureAgile system administration

Integración y delivery continuo

"10 deploys per day - Dev & Ops cooperation at Flickr"

Lean Startup

ORÍGENESLa global disponibilidad de tecnologías de cloud: PaaS/IasS

AWS EC2Google Compue EngineMicrosoft AzureHerokuDigital OceanBudgetVMSoftlayerRackspace

CARACTERIZACIÓNDevOps es un movimiento, �losofía o prácticaQue se ajusta perfectamente a las metodologías ágiles

Extiende y completa el proceso de integración ydeployment continuo asegurando que el código estélisto para producción agregando valor para los clientes

Un nuevo rol profesional que surge de:Desarrolladores que se interesan por demás en el deployde las aplicaciones y operaciones de red y serviciosAdministradores que son apasionados por escribircódigo moviendo su foco hacia desarrollo, promoviendoincluso pruebas de su infraestructura como si fuesencódigo

INFRAESTRUCTURE AS CODEIaC es el proceso por el cuál se aprovisionan máquinasfísicas (bare metal) o virtuales, así como sus con�guracionesEste aprovisionamiento se realiza a través de archivos decon�guración que son interpretados por algunaherramienta de gestión del aprovisionamientoEstos archivos de con�guración de la infraestructura seversionan en un SCM

HERRAMIENTASExisten diversos productos que promueven IaC

Chef

Puppet Labs

Ansible

SaltStack

TEST DE LA INFRAESTRUCTURACon las herramientas anteriores es posible realizar tests dela infraestructura:

Tests de unidad:

Tests de integración

rspec-puppetChefSpec

ServerSpec

CONCEPTOS RELACIONADOSA continuación describiremos brevemente los siguientesconceptos:

Integración ContinuaDelivery ContinuoDeployment Continuo

INTEGRACIÓN CONTINUAPara comprender bien este concepto, tenemos queconsiderar el trabajo diario de un equipo dedesarrolladoresCada desarrollador trabaja en una rama determinada en elSCMSi varios desarrolladores trabajan sobre una ramadiferente, se rami�can las versiones produciéndose unproblema a la hora de integrar ramas: Merge hell

PROYECTO CON VARIAS RAMAS

¿Cómo es posible garantizar un merge satisfactorio en todos los casos?

INTEGRACIÓN CONTINUAPromueve el frecuente merge con la rama principal

Tratando así de minimizar el re-trabajoSe realizan múltiples merge diarios donde cadadesarrollador se compromete a seguir un �ujo de trabajocompleto donde se debe correr y pasar todos los tests deunidad e integración

Esto se automatiza con herramientas de CI que escuchancada commit en el SCM

HERRAMIENTAS DE CITravisSemaphoreGitlab CIJenkins

DELIVERY Y DEPLOYMENT CONTINUOGeneralmente se confunden delivery y deploymentcontinuo

Deployment continuo admite que cada cambio seaaplicado en producciónDelivery continuo permitiría que cada cambio seprepare para estar disponible para producción, pero elpaso de ponerlo en producción requiere de intervenciónhumana

HERRAMIENTAS

INTRODUCCIÓNEn este apartado veremos ejemplos de algunas herramientas

que promueven la práctica DevOps, pero más importanteaún, que simpli�can tareas repetitivas y promueven el

desempeño ágil de nuestra tarea

Presentaremos entonces, herramientas que sirven:Desde la perspectiva de desarrolloDesde la perspectiva de infraestructura

DESDE LA PERSPECTIVADE DESARROLLO

DESDE LA PERSPECTIVA DE DESARROLLOSi bien cada proyecto es un mundo diferente, trataremosde dar ejemplos que se dan en gran parte de los proyectosde desarrollo

El primero considera el deploy automatizadoLuego hablaremos de cómo simpli�car el desarrollo enambientes complejos:

Usando VagrantUsando Docker

A su vez, trataremos de ir introduciendo el concepto deinmutabilidad

AUTOMATIZANDO LOSDEPLOYS

AUTOMATIZANDO LOS DEPLOYSEsta tarea tiene como objetivo automatizar la tarea deinstalar/actualizar una aplicación en un servidor remototeniendo en cuenta todas las consideraciones necesarias

Incluso cuando la aplicación se compone de variascomponentes distribuidas

No todos los desarrollos tienen las mismas necesidadesRealizar un buildPublicar artefactoInstalar dependenciasSubir/Descargar código/artefactoCorrer scripts

UN EJEMPLO: CAPISTRANOA remote server automation and deployment tool written in Ruby

role :demo, %w{srv­01 srv­02 srv­03} task :uptime do  on roles(:demo), in: :parallel do |host|     uptime = capture(:uptime)     puts "#{host.hostname} reports: #{uptime}"   endend

Ver ejemplo

USO DE CAPISTRANOcap install # Inicializa el directorio cap ­T # Lista todas las posibles tareas disponibles  

Instaura la noción de ambientesPor defecto inicializa dos ambientes: production y stagingLos ambientes con�guran los accesosLas tareas son las mismas para cada ambiente

EJEMPLO DE PRODUCTION.RBrole :demo, %w{localhost} 

server '33.33.33.10',    roles: %w(demo),    ssh_options: {      user: 'vagrant',      forward_agent: true,      auth_methods: %w(publickey password),      password: 'vagrant'    }

USO DE CAPISTRANOAdemás de los ambientes, capistrano de�ne roles. Porejemplo: web, app, db

Un servidor tiene un rolEn un server con un determinado rol, hay que realizardeterminadas taras diferentes. Por ejemplo: assets enweb, deploy en app, dump en db

Además de las tareas prede�nidas, permite extenderlo contareas propias sean locales como remotasLas tareas prede�nidas permiten realizar deploy y rollback

Veremos ejemplos de uso de capistrano deployando en un servidor virtual con IP 33.33.33.10

EJEMPLO DE CAPISTRANO Y JEKYLL es uno de los tantos generadores de sitios estáticos

El website de fue desarrollado con jekyllDeployaremos en la VM el sitio usando jekyll. Para ello:

El servidor debe tener instalado rubySe debe desacargar el código del sitio desde Se debe correr el comando jekyll buildListo!

Para probarlo:

JekyllMikroways

GitHub

http://33.33.33.10Ver el ejemplo

EJEMPLO DE CAPISTRANO Y JEKYLLCon capistrano:

Deployamos el sitio: cap production deployRemotamente ejecutamos jekyll buildLocalmente abrimos el navegador con al URL del sitio

Probamos una nueva versión del sitioHacemos un rollback: cap productiondeploy:rollback

CAPISTRANO Y DESARROLLOS DINÁMICOSEn sitios que no son estáticos, existen archivos que debenmantenerse entre deploys

Con�guración de la base de datos o softwareUploads o archivos generados por la aplicación

Capistrano permite de�nir qué archivos y qué directoriosson compartidosDe aquí la estructura propuesta por capistrano es:

  base_dir   ├── current ­> /opt/sites/jekyll/releases/ 20160619173257   ├── releases   │   └── YYYYMMDDHHmmii   ├── repo   └── shared 

CAPISTRANO Y WORDPRESSCreamos un wordpress que mantenemos localmente

Personalizamos el wordpress localInstalamos wordpress con capitrano en el servidor remoto

Será accesible vía Usamos tareas personalizadas para:

Subir la base local a producciónSubir el template y uploads a producción

Trabajamos en producciónDescargamos la base de producción a nuestra copia local

http://33.33.33.10:81

OTRAS HERRAMIENTASRUNDECKFabricRocketeerDeployer

VAGRANT

VAGRANTSimpli�ca la con�guración, reproducibilidad yportabilidad de ambientes sobre diferentes estándaresindustrialesControla estos ambientes mediante un simple work�owque maximiza la productividad y �exibilidadAisla las dependencias y sus con�guraciones en unambiente consistente y descartableDisponible para:

Mac OS XWindowsLinux

VAGRANT PROVIDERSVirtualboxHyper-VVMWareAWSDocker

VAGRANT PROVISIONERSFileShellAnsibleCFEngineChefPuppetDockerSalt

COMANDOS VAGRANTvagrant up vagrant destroy vagrant ssh vagrant provision vagrant reload [­­provision] vagrant box list 

MULTIMACHINEEsta funcionalidad permite iniciar varias VMs en un mismoVagrantfile permitiendo así simular ambientes complejos

EJEMPLOS VAGRANTshell provisioning

Vagrant.configure(2) do |config|   config.vm.box = "chef/ubuntu­14.04"   config.vm.box_check_update =  false   config.vm.network "private_network", ip: "33.33.34.10" 

  config.vm.provision "shell", inline: <<­SHELL      sudo apt­get update      sudo apt­get install ­y apache2    SHELLend

Ejemplo de un server con apache

EJEMPLOS VAGRANTMultimachine (4 vms) con docker y shell provisioning

Vagrant.configure(2) do |config|   config.vm.define 'master', primary: true do |app|     app.vm.box = "chef/ubuntu­14.04"     app.vm.network "private_network", ip: "33.33.35.10"     app.vm.provision "docker" do |d|       ...     end  end      (1..3).each do |num|    config.vm.define "node­#{num}" do |app|       app.vm.box = "chef/ubuntu­14.04"       app.vm.network "private_network", ip: "33.33.35.1#{num}"       app.vm.provision "docker" do |d|         ...       end    end  end

Ejemplo de un cluster de Docker Swarm

EJEMPLOS VAGRANTAWS provider con Chef

Antes de poder utilizar este provider es necesario instalar el plugin que provee esta funcionalidad

  vagrant plugin install vagrant­aws  

  # Se usa un box dummy   vagrant box add dummy \     https://github.com/mitchellh/vagrant­aws/raw/master/dummy.box  

  vagrant up ­­provider=aws 

EJEMPLO VAGRANT Y AWSVagrant.configure("2") do |config|   config.vm.box = "dummy"   config.vm.provider :aws do |aws,override|     aws.ami = "ami­7747d01e"     aws.access_key_id = ENV['AWS_ACCESS_KEY']     aws.secret_access_key = ENV['AWS_SECRET_KEY']     aws.keypair_name = 'car'     override.ssh.username = "ubuntu"     override.ssh.private_key_path =  "#{ENV['HOME']}/.ssh/id_rsa"   end  config.vm.provision :chef_solo do |chef|     chef.run_list = [       'recipe[apt]',       'recipe[my_rancher]'     ]  endend

vagrant rsync - Requiere este comando si algo se modi�ca - Ejemplo de servidor Rancher

DOCKER

DOCKERPermite correr contenedores linux aislados sólo en LinuxPromueve la portabilidad, permitiendo contenedoresautosu�cientes que son creados a partir de las necesidadesde una aplicaciónBasados en el concepto de inmutabilidadLos contenedores usados en desarrollo pueden usarse enambientes de testing y producción

Minimiza la brecha entre desarrollo e infraestructuraPuede utilizarse para aplicaciones grá�cas

docker run ­v ~/workspace/:/home/eclipse/workspace/ \    ­e DISPLAY ­v /tmp/.X11­unix:/tmp/.X11­unix:ro \    ­d leesah/eclipse 

CONCEPTOS DOCKERDocker funciona a partir de:

Docker engine: set de herramientas de gestión delambiente docker: servicio docker, contenedores,imagenesDocker hub/registry: repositorio de imágenes públicas oprivadas a partir de donde creamos contenedores

COMANDOS DOCKERdocker search docker images docker pull docker run docker ps docker diff docker commit docker inspect docker log 

EJEMPLOIniciamos una instancia de Mysql con docker

docker run ­p 33060:3306 ­e MYSQL_ROOT_PASSWORD=devops ­d mysql:5.7 

mysql ­u root ­h 127.0.0.1 ­­port 33060 ­pdevops 

¿Qué sucede si eliminamos el contenedor?

VOLUMENES EN DOCKERdocker volume  ls docker volume create docker volume rm docker volume inspect 

DOCKER COMPOSESe describe una aplicación compuesta por más de un

contenedor mediante un ymlversion: "2" services:   wordpress:     image: wordpress     links:       ­ db:mysql     ports:       ­ 8080:80   db:    image: mysql:5.7 

Ver ejemplo completo

COMANDOS DOCKER COMPOSEdocker­compose up docker­compose ps docker­compose stop docker­compose rm docker­compose scale 

DESDE LA PERSPECTIVADE INFRAESTRUCTURA

DESDE LA PERSPECTIVA DE INFRAESTRUCTURASe intenta capturar una con�guración funcional quepermita:

Replicar un ambienteRecuperación ante desastres

Surge la posibilidad de versionar la infraestructuraEsto implica poder repetir la instalación de un server

Surgen nuevas necesidades:Orden en cuanto al inicio de serviciosCambios de plataformas de virtualización por costos ofuncionalidad

HERRAMIENTASGestión de las con�guraciones usando ChefGestión de la infraestrcutura usando chef-provisioningDocker en producción con Rancher

CHEFChef permite modelar la evolución de nuestrainfraestructura y aplicaciones como si fueran códigoNo impone restriccionesPermite describir y automatizar los procesos einfraestructuraLa consecuencia es que la infraestructura se vuelve:

VersionableTesteableReplicableIdempotente

CONCEPTOS DE CHEFPara lograr su objetivo se utilizan de�niciones reutilizablesllamadas cookbooks y recipesSe programa en Ruby usando una DSL

ARQUITECTURA

ENTIDADES DE CHEFRolesNodos

AtributosData Bags

Además, es posible realizar búsquedas sobre estas entidades

EJEMPLO DE UNA RECETApackage 'nginx' 

service 'nginx' do   action [:enable, :start] end

template '/etc/nginx/sites­enabled/www.conf'  do   source 'nginx­default.conf.erb'   variables(     server_name: 'www.mikroways.net',     document_root: '/var/www'   )  notifies :restart, 'service[nginx]', :immediately end

Es posible probar las recetas con una versión de chef llamada chef-zero/chef-solo

Ver ejemplo completo

TDDEjemplo de

Basados en rspecrubocopfoodcritic

Ejemplo de Basados en Probamos un test implementado con enplataformas Debian 7 y Ubuntu 14.04kitchen

test de unidadChefSpec

test de integraciónTest Kitchen

ServerSpec

DESPLEGANDO EL POTENCIAL DE CHEFBootstrap de nodos

Usaremos knife-ec2BúsquedasAmbientesssh en paraleloBúsquedas en recetas

Ejemplo con ha-proxy

BOOTSTRAP DE NODOSUsaremos Amazon EC2 y un plugin de chef que simpli�ca yuni�ca las tareas de crear y bootstrapear un nodoCrearemos antes un rol que describe un web server. Estonos permitirá realizar búsquedas

# Crea/actualiza el rol web­server  knife role from file roles/web­server.rb  # Crea dos nodos llamados web­01 y web­02 en amazon con el rol  # web­server knife ec2 server create ­I ami­b1a652d1  ­f m1.small ­­ssh­user ubuntu \    ­N web­01 ­r 'role[web­server]' knife ec2 server create ­I ami­b1a652d1  ­f m1.small ­­ssh­user ubuntu \    ­N web­02 ­r 'role[web­server]' ## Listamos las instancias de Amazon EC2  knife ec2 server list 

Algunos detalles que se omiten se toman de la con�guración de knife

UN POCO DE KNIFEknife status knife role list knife node list knife search '*:*' knife search 'platform:ubuntu AND (name:web­01 OR role:web­server)'  knife ssh ­x ubuntu 'role:web­server' sudo service nginx stop knife exec ­E 'search(:node, "role:web­server").each do |node|     puts(    node.name => {       ip: node.cloud.public_ipv4,        mem: node.memory.total,        cpu: node.cpu.total     }  )end'

Lo interesante es que uno puede usar búsquedas en las recetas

CREAMOS UN PROXY REVERSOEsta receta utiliza búsquedas para con�gurar los backends de haproxy

all_web_servers = search(:node, "role:web­server") members = [] all_web_servers.each do |web|   members <<   {    "hostname"  => web['cloud']['public_hostname'],     "ipaddress" => web['cloud']['public_ipv4'],     "port"      => 80,     "ssl_port"  => 80   }endnode.default['haproxy']['members'] = members 

include_recipe 'haproxy' 

knife ec2 server create ­I ami­b1a652d1  ­f m1.small ­­ssh­user ubuntu \    ­N proxy ­r 'recipe[myhaproxy]' 

Probar con curl y eliminar con knife ec2 server delete <INSTANCE-ID> -P

CHEF NO ES EL ÚNICOY... ¿por qué chef?Hoy día Ansible es la alternativa más elegidaPuppet es la principal competencia

CHEF-PROVISIONING

INTRODUCCIÓNChef provisioning extiende chef permitiendo crear VMs endiferentes plataformas de virtualización

VagrantAWSAzureDigitalOceanVMWareXenServerGoogle Compute EngineIBM SoftLayerY varios más

¿QUÉ ES ENTONCES?Permite con�gurar nuestro cluster de máquinas de formaagnóstica de la plataformaEvita el uso reiterativo de knife para iniciar VMs

EJEMPLOchef_role 'web­server' do   run_list ["recipe[apt]","recipe[web­server]"] end

machine_batch do   machine 'web­01' do     run_list ['role[web­server]']   end  machine 'web­02' do     run_list ['role[web­server]']   endend

machine 'proxy' do   run_list ['recipe[myhaproxy]'] end

Corremos en nuestra PCchef­client ­z ­r 'my­infra::chef,my­infra::aws,my­infra'  

ELIMINANDO TODOchef_role 'web­server' do   action :delete end

machine_batch do   action :destroy   machines 'web­01', 'web­02', 'proxy' end

Corremos en nuestra PCchef­client ­z ­r 'my­infra::chef,my­infra::aws,my­infra::delete'  

Y AHORA CON VAGRANTchef­client ­z ­r 'my­infra::chef,my­infra::vagrant,my­infra'  

Esto es muy importante, porque sólo cambiando el driver deaprovisionamiento, podemos reusar nuestra infraestructura

de�nidaPodemos incluso tener un cluster con VMs de diferentes proveedores

TERRAFORM

La alternativa a chef-provisioning

CLUSTERS DECONTENEDORES

ALTERNATIVAS EN BOGADocker SwarmRancher CattleKubernetesMesos

ADEMÁS SE HABLA MUCHO DERancher OSCoreOSBoot2docker

CARACTERÍSTICASSchedulling de contenedores

Importancia de los labels en dockerService discovery

ZookeperConsulEtcd

Complicaciones:Volúmenes compartidosMonitoreo y Logs

RANCHER

RANCHERPermite con�gurar ambientes

Con Cattle, Swarm, Kubernetes y ahora MesosLos ambientes se componen de nodosLos contenedores se manejan con stacks

Usan docker-compose v1Provee un catálogo de aplicacionesPermite extender el catálogo con uno propio

Simpli�ca la integración con registries privadasProxy reverso basado en service discoverySimple escalamiento de contenedores

EJEMPLODeployamos un wordpress desde el catálogo

Fijamos que sólo corra la db en un nodo determinadoEscalamos el servicio

OTRO EJEMPLOCreamos una aplicacion propia

El nombre del directorio es importante: nombre delstackCreamos Iniciamos el stack: rancher-compose upVeri�camosUpgradeamos: rancher-compose up -u my-appVeri�camosRealizamos un rollback

docker-compose.yml

¿PREGUNTAS?

GRACIASTOTALES

Contacto

contacto@mikroways.net

christian.rodriguez@mikroways.net@car_unlp