DevOps: una breve introducción
-
Upload
christian-rodriguez -
Category
Technology
-
view
60 -
download
3
Transcript of DevOps: una breve introducción
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{srv01 srv02 srv03} 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/ubuntu14.04" config.vm.box_check_update = false config.vm.network "private_network", ip: "33.33.34.10"
config.vm.provision "shell", inline: <<SHELL sudo aptget update sudo aptget 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/ubuntu14.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/ubuntu14.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 vagrantaws
# Se usa un box dummy vagrant box add dummy \ https://github.com/mitchellh/vagrantaws/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 = "ami7747d01e" 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/.X11unix:/tmp/.X11unix: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 COMPOSEdockercompose up dockercompose ps dockercompose stop dockercompose rm dockercompose 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/sitesenabled/www.conf' do source 'nginxdefault.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 webserver knife role from file roles/webserver.rb # Crea dos nodos llamados web01 y web02 en amazon con el rol # webserver knife ec2 server create I amib1a652d1 f m1.small sshuser ubuntu \ N web01 r 'role[webserver]' knife ec2 server create I amib1a652d1 f m1.small sshuser ubuntu \ N web02 r 'role[webserver]' ## 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:web01 OR role:webserver)' knife ssh x ubuntu 'role:webserver' sudo service nginx stop knife exec E 'search(:node, "role:webserver").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:webserver") 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 amib1a652d1 f m1.small sshuser 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 'webserver' do run_list ["recipe[apt]","recipe[webserver]"] end
machine_batch do machine 'web01' do run_list ['role[webserver]'] end machine 'web02' do run_list ['role[webserver]'] endend
machine 'proxy' do run_list ['recipe[myhaproxy]'] end
Corremos en nuestra PCchefclient z r 'myinfra::chef,myinfra::aws,myinfra'
ELIMINANDO TODOchef_role 'webserver' do action :delete end
machine_batch do action :destroy machines 'web01', 'web02', 'proxy' end
Corremos en nuestra PCchefclient z r 'myinfra::chef,myinfra::aws,myinfra::delete'
Y AHORA CON VAGRANTchefclient z r 'myinfra::chef,myinfra::vagrant,myinfra'
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
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?