2000 a 2007 Dicté cursos de CCNA/RedHat/Solaris/IRIX A partir de 2006 me aboqué al desarrollo web y coordinación de proyectos de software Empecé con Devops en 2012 Trabajos freelance de IT Capacitación sobre chef 2013
de chef Varias gemas de ruby Plugins para Symfony 1.x Github Ruby Scripting para Spoon de Pentaho chef-provisioning-vsphere chef-provisioning-fog Redmine SAML plugin Redmine per project sender plugin xmltv tv_grab_ar VDR - The Video Recorder Disk
y web en SMN (2005 al 2007) Consultoría en SENASA (2007 a la fecha) De nición e implementación de un LDAP replicado e integrado con AD Implementación de SSO Arquitectura, implementación y mantenimiento del email Portal del diario El Día (2012 a la fecha) Arquitectura y desarrollo del producto Diseño de la arquitectura inicial de su infraestructura
coincide que: Se conforman grupos de trabajo disjuntos para desarrollo e infraestructura Desarrollo es un cliente de infraestructura Infraestructura atiende cuestiones complejas que son críticas No hay diálogo uido entre las partes Desarrollo aplica metodologías ágiles, mientras que infraestructura lidia con problemas en los que es difícil seguir el ritmo que solicita desarrollo
de tres capas Las herramientas a utilizar ya no sólo se conforman de un lenguaje, una base de datos SQL y un framework Necesidad de ambientes independientes entre los desarrolladores Algunas organizaciones promueven un ambiente común de desarrollo donde toda la complejidad se concentra en un cluster compartido por N desarrolladores Di cultad para involucrar nuevos integrantes Exceso de tiempo para aprender a gestionar la infraestructura en vez de programar
y comercial hacemos hincapié en los procedimientos para trabajar Respetar estándares de codi cación Utilizar alguna herramienta de versionado de código: GIT : trabajo con estrategias de branches y manejo de releases Permisos sobre las branches: desarrolladores con más experiencia revisan el código de programadores con menos experiencia. Por ejemplo: git- ow ujo tipo GitHub
con los procedimientos/ ujos de nidos anteriormente Esto mismo sugiere git- ow con los Aplicar buenas prácticas de calidad TDD con alta cobertura Tests de aceptación Aspiraciones para alcanzar: Integración continua Delivery continuo Deployment continuo hot x branches
puede Ser simple si el ambiente ya existe y no requiere nuevas dependencias Ser complejo si el producto a instalar requiere nuevas dependencias Revisar si cada una de las dependencias satisfacen sus requerimientos ¿El código provee de ésta información? Automatizar los deployments simpli cando las tareas repetitivas Usar scripts caseros o herramientas de automatización como Capistrano, Ansible, Chef, Puppet, Salt, etc
e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Aplicando esta metodología se promueve lanzar nuevas versiones en períodos muy cortos de tiempo: Aparecen deployments diarios e incluso varias veces al día Responder a los requerimientos ágiles requiere una operatoria ágil desde IT Si esto no sucede se produce un cuello de botella mani esto ágil
de mergerarse si no pasan los test de unidad, funcionales e integración. Tampoco si el analizador de código no garantiza se respetan estándares Un release no pasa a producción si no pasa todos los tests de unidad, funcionales e integración Es importante poder aplicar . Sin embargo, armar un ambiente de éste tipo no es trivial y depende del área de IT Integración Continua
surfeen la cresta de las olas Utilizan versiones muy actuales de determinados productos que complican los ambientes Algunos lenguajes no permiten, de forma simple, tener en el sistema más de una versión de una misma librería o lenguaje. Por ejemplo PHP Esto crea diferencias entre el ambiente de desarrollo y producción Justamente, ésta es la brecha que debemos achicar
versiones y GIT/SVN mantiene una identi cación de cada commit, se necesita manejar un versionado de releases amigable contribuye a entender qué signi ca que 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 de datos respecto de las versiones de código? Semantic Versioning
un recurso en producción Acceso al dump o código completo El código no debería ser necesario si se utilizan versiones que respetan el versionado semver o desde un SCM Los datos de una aplicación en producción (no la base de datos) pueden ser necesarios para realizar una prueba A veces, por requerimientos de seguridad o legales, la información debe obtenerse ofuscada Otras veces, alcanza con un dato antiguo que puede extraerse desde un backup
al productivo tiene un valor muy grande para desarrollo dado que permite: Veri car problemas of ine Probar nuevos releases antes de pasarlos a producción Al cliente veri car en una instancia previa al pasaje a producción de un cambio Veri car tiempos de actualización etc
para conocer cómo se comporta un servidor o recurso Desde desarrollo hay varios aspectos que pueden medirse para luego ayudar a identi car problemas: Pro ling de cada middleware de una aplicación: ORM, servicios externos, renderizado, caching, tiempos de respuesta, etc Errores en la aplicación Contar con la información estadística nos permite conocer el comportamiento normal de nuestra aplicación Desconocer estos datos es manejar con el parabrisas lleno de barro
media o el desvío estándar por más de un tiempo aceptable, entonces podemos establecer una alerta Generalmente el monitoreo y las alertas se establecen sobre los servicios o sobre los recursos que son cruciales, y ante el mínimo problema se noti ca a determinados usuarios Esto produce innumerables alertas que terminan siendo ignoradas El monitoreo debería concentrase en lo que es de valor para el usuario que utiliza el recurso y no en las partes que constituyen el servicio
se consideran funcionales per se. En el caso del DNS, utilizar TTL pequeños promueve la resilencia Las organizaciones ya utilizan virtualización como una simpli cación de sus Datacenters, gestión de la infraestructura, snapshots de VMs y migraciones en caliente Algunas organizaciones desconfían de la virtualización para algunos servicios críticos para su negocio. Por ejemplo base de datos.
usuarios siga siendo una tarea más del área de infraestructura Mantener actualizadas las versiones de cada servicio crítico evitando posibles vulnerabilidades Atender a todas las cuestiones mencionadas demanda tiempo y esfuerzo que no dejan lugar para la investigación de nuevas tendencias, prácticas ágiles o automatización
de desarrollo, es habitual programar o automatizar cualquier paso repetible, pero no siempre aplica esto mismo en infraestructura Las tareas repetitivas se suelen automatizar con scripts en shell que utilizan herramientas auxiliares: awk, perl, python, sed, php, bc, etc Soluciones muy acopladas que no pueden reusarse en todos los casos
un área más a la que se le brinda servicio Entre los servicios ofrecidos, pueden mencionarse: Hosteo de aplicaciones: infraestructura deja un hueco donde desarrollo puede subir código. Se debe determinar la forma en que se dan los accesos y a qué se da acceso Virtualización: se ofrece un servicio de virtualización del tipo PAAS. Desarrollo gestiona su infraestructura Deploy de aplicaciones: Sería como el caso de hosteo de aplicaciones, pero además, es responsabilidad del área de infraestructura ejecutar el deployment en producción
se brinda a desarrollo: Gestión de ambientes: a medida que se van consolidando mejor los grupos de desarrollo e infraestructura, surge la posibilidad de aislar ambientes, como por ejemplo: pruebas, desarrollo, staging, QA, producción Servicios para la gestión de proyectos: es común que además de los servicios críticos, el área de infraestructura brinde servicios que permitan a los desarrolladores manejar tickets, versionado, chat, irc, integración continua, etc
la actualidad, existen organizaciones que siguen imponiendo la homogeneización de sus ambientes Los hechos demuestran que la homogeneización de herramientas informática fracasaron en pos de arquitecturas heterogéneas
Surgen nuevas tendencias que se convierten en requisitos para los nuevos desarrollos: Ruby, NodeJS, Erlang, Redis, Memcached, Websockets, MongoDB, Hadoop, Spark, etc Cómo conocer qué es lo mejor para cada caso: ¿Cómo monitorear? ¿Cómo backupear? ¿Es seguro?
hostean en servidores propios sin un conocimiento claro de cómo se realizó el desarrollo se corre un alto riesgo Se disponen de varias herramientas que permiten resguardar la seguridad general Asegurar estos ambientes complica la infraestructura Si el hosting es compartido en un mismo servidor, es necesario garantizar la independencia de los aplicativos
backups claras para sus servicios críticos Cuando se deben de nir para una aplicación, el área de desarrollo conoce mejor qué backupear Desconociendo este dato, generalmente se utilizan snapshots o backups de toda la aplicación Dependiendo del esquema de trabajo empleado para obtener el desarrollo, puede que se logre disponer de un versionado de la aplicación que garantice que el código completo puede obtenerse tal cual la copia está en producción En este caso, el backup se limita a las bases de datos empleadas y los datos generados
monitoreo se realiza sobre lo que es de su interés. Generalmente esto excluye las aplicaciones Conocer el comportamiento de una aplicación (estadística), nos permite tomar decisiones y ver cuál es el comportamiento normal de la misma. Sin embargo, para ello los desarrollos deben: Hacer buen uso y manejo de Logs Usar herramientas de pro ling que permitan recolectar datos útiles para evaluar el comportamiento de una aplicación
otras muchas cuestiones como por ejemplo: Vencimientos de certi cados Gestión de SPAM para evitar la llegada, así como el bloqueo de nuestros MTA para el envío de SPAM desde nuestros servidores Problemas de hardware habituales Pruebas de restauración de backups Migraciones de datos entre productos. Por ejemplo, una organización pudo haber utilizado en toda su historia, diferentes productos para su correo electrónico: uw- imap, cyrus, courier y dovecot
es el caso ideal donde se arranca sin historia previa Se deben estipular una serie de pasos que deben seguirse: La aplicación corre con un usuario determinado Se debe crear una estructura de directorio previa Instalación de servicios que son requeridos Rotación de logs Servicios asincrónicos Creación de usuarios y bases de datos necesarios Escalado de la aplicación De nir y aplicar las políticas de backups Estadísticas y monitoreo
considerados en el caso anterior varía Actualizar el código, preservando en lo posible la versión anterior Integrar de ser posible con algún esquema de proxy reverso que permita trabajar en caliente y realizar Relación con blue green deployments A/B Testing
de realizar un upgrade, se desea volver atrás Siempre que no se haya realizado algun cambio en la base de datos destructivo que no requiera restaurar la base de datos, entonces debería ser simple realizar un rollback Si se preserva el código de la versión anterior, entonces con link simbólicos se puede realizar un rollback rápidamente Si se utiliza blue green deployments, entonces sólo se cambia el proxy reverso
resuelve la simplicidad de actualizar y realizar rollbacks Con las bases de datos no sucede lo mismo Versionar la estructura de la base de datos con el código no aporta demasiado Necesitamos saber cómo aplicar un parche a un modelo en un momento y poder deshacerlo en caso de roolback Tratar que estos parches sean idempotentes No siempre sucede que un parche a una base de datos tenga vuelta atrás Algunos parches pueden ser costosos en bases de datos grandes
un cambio de versión es aconsejable noti car a los usuarios con anticipación de la interrupción del servicio Esto requiere conocer el dominio de usuarios afectados Programar el envío masivo de correos Plani car y noti car con anticipación mejoran la calidad del servicio Gestión de contratos Dependiendo de la relación comercial que exista con los clientes, el hosteo de una aplicación podrá tener un vencimiento que deberá deshabilitar el acceso hasta no regularizar la situación
no La única versión que es igual a producción, es la de producción Porque alguien cambió algo en producción que no funcionaba Porque luego de cambiar algo en producción, no se actualizó el código versionado Las pruebas se realizan en la pc del desarrollador o directamente en producción Pareciera ser imposible que esto suceda, pero muchas organizaciones siguen gestionando sus desarrollos de esta forma
organización: Desarrollo: el ambiente de desarrollo es en el cuál los desarrolladores construyen el software Testing: es el ambiente donde se publica el software en fase de pruebas para que sea probado por un grupo de nido de personas, entre las que se incluye el usuario nal o representantes del mismo
en un ambiente replicado e idéntico al productivo. En este entorno se veri ca el correcto funcionamiento de la aplicación y se realizan los ajustes necesarios en caso de no ser así, evitando que los problemas se descubran en el pasaje a producción Producción: es el ambiente que tiene todos los servicios productivos. Este ambiente cuenta con políticas estrictas en cuanto al acceso y la administración del mismo.
surgido para solucionar algunas de las necesidades mencionadas según la perspectiva de desarrollo e infraestructura Asimismo, mostraremos que estas soluciones introdujeron nuevos problemas
mejores que otras según la licencia disponible, las necesidades o contexto de uso El uso de cualquier herramientas disponible para virtualizar, ofrece mejoras substanciales para: Backup de VMs Simpli can la gestión de servidores, ahora virtuales, que cuando se realizaba físicamente Migraciones en caliente de VMs entre equipos físicos Mejor aprovechamiento de recursos de hardware Instalación de SO basada en templates que permite disponer rápidamente de servidores pre-instalados
es posible aprovechar muchas de las ventajas de éstas herramientas Generalmente la características más atractivas se proveen en versiones licenciadas La virtualización genera más servidores que cuando se utilizaban servidores físicos: Esto se debe a que un servicio aislado es más seguro e independiente, con lo cuál su reemplazo o actualización se simpli ca Por esta razón, crece el uso de VMs, di cultando el mantenimiento de su inventario que rápidamente se desactualiza
requerimientos, es tentador reutilizar el mismo servidor para hostear múltiples aplicaciones Se simpli ca la gestión del servidor Se compromete la seguridad de todas las aplicaciones instaladas Para determinar cómo compartir un mismo servidor entre aplicaciones, es conveniente realizar un análisis del que se obtenga una matriz de aplicaciones agrupadas según criticidad
puesta en producción nginx, HA-proxy, trae k, varnish Montar aplicaciones en lenguajes poco usuales Python, Ruby, Erlang, Node Bases de datos NoSQL MongoDB, Redis Sistemas de colas AMQP: RabbitMQ, Qpid
servicio determinado se compone de partes diferentes que podemos requerir garantizar alta disponibilidad y/o failover Actualizar un servicio es una tarea artesanal y costosa Sobre todo si es un servicio distribuido con muchas dependencias
diferentes movimientos: Las conferencias Velocity, en particular la presentación Los movimientos de: Infrastructure as code Agile infrastructure Agile system administration Integración y delivery continuo "10 deploys per day - Dev & Ops cooperation at Flickr" Lean Startup
ajusta perfectamente a las metodologías ágiles Extiende y completa el proceso de integración y deployment 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 deploy de las aplicaciones y operaciones de red y servicios Administradores que son apasionados por escribir código moviendo su foco hacia desarrollo, promoviendo incluso pruebas de su infraestructura como si fuesen código
se aprovisionan máquinas físicas (bare metal) o virtuales, así como sus con guraciones Este aprovisionamiento se realiza a través de archivos de con guración que son interpretados por alguna herramienta de gestión del aprovisionamiento Estos archivos de con guración de la infraestructura se versionan en un SCM
el trabajo diario de un equipo de desarrolladores Cada desarrollador trabaja en una rama determinada en el SCM Si varios desarrolladores trabajan sobre una rama diferente, se rami can las versiones produciéndose un problema a la hora de integrar ramas: Merge hell
Tratando así de minimizar el re-trabajo Se realizan múltiples merge diarios donde cada desarrollador se compromete a seguir un ujo de trabajo completo donde se debe correr y pasar todos los tests de unidad e integración Esto se automatiza con herramientas de CI que escuchan cada commit en el SCM
continuo Deployment continuo admite que cada cambio sea aplicado en producción Delivery continuo permitiría que cada cambio se prepare para estar disponible para producción, pero el paso de ponerlo en producción requiere de intervención humana
promueven la práctica DevOps, pero más importante aún, que simpli can tareas repetitivas y promueven el desempeño ágil de nuestra tarea Presentaremos entonces, herramientas que sirven: Desde la perspectiva de desarrollo Desde la perspectiva de infraestructura
un mundo diferente, trataremos de dar ejemplos que se dan en gran parte de los proyectos de desarrollo El primero considera el deploy automatizado Luego hablaremos de cómo simpli car el desarrollo en ambientes complejos: Usando Vagrant Usando Docker A su vez, trataremos de ir introduciendo el concepto de inmutabilidad
tarea de instalar/actualizar una aplicación en un servidor remoto teniendo en cuenta todas las consideraciones necesarias Incluso cuando la aplicación se compone de varias componentes distribuidas No todos los desarrollos tienen las mismas necesidades Realizar un build Publicar artefacto Instalar dependencias Subir/Descargar código/artefacto Correr scripts
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}" end end Ver ejemplo
T # Lista todas las posibles tareas disponibles Instaura la noción de ambientes Por defecto inicializa dos ambientes: production y staging Los ambientes con guran los accesos Las tareas son las mismas para cada ambiente EJEMPLO DE PRODUCTION.RB role :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' }
roles. Por ejemplo: web, app, db Un servidor tiene un rol En un server con un determinado rol, hay que realizar determinadas taras diferentes. Por ejemplo: assets en web, deploy en app, dump en db Además de las tareas prede nidas, permite extenderlo con tareas propias sean locales como remotas Las 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
generadores de sitios estáticos El website de fue desarrollado con jekyll Deployaremos en la VM el sitio usando jekyll. Para ello: El servidor debe tener instalado ruby Se debe desacargar el código del sitio desde Se debe correr el comando jekyll build Listo! Para probarlo: Jekyll Mikroways GitHub http://33.33.33.10 Ver el ejemplo
cap production deploy Remotamente ejecutamos jekyll build Localmente abrimos el navegador con al URL del sitio Probamos una nueva versión del sitio Hacemos un rollback: cap production deploy:rollback
existen archivos que deben mantenerse entre deploys Con guración de la base de datos o software Uploads o archivos generados por la aplicación Capistrano permite de nir qué archivos y qué directorios son compartidos De aquí la estructura propuesta por capistrano es: base_dir ├── current > /opt/sites/jekyll/releases/ 20160619173257 ├── releases │ └── YYYYMMDDHHmmii ├── repo └── shared
el wordpress local Instalamos wordpress con capitrano en el servidor remoto Será accesible vía Usamos tareas personalizadas para: Subir la base local a producción Subir el template y uploads a producción Trabajamos en producción Descargamos la base de producción a nuestra copia local http://33.33.33.10:81
ambientes sobre diferentes estándares industriales Controla estos ambientes mediante un simple work ow que maximiza la productividad y exibilidad Aisla las dependencias y sus con guraciones en un ambiente consistente y descartable Disponible para: Mac OS X Windows Linux
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
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
la portabilidad, permitiendo contenedores autosu cientes que son creados a partir de las necesidades de una aplicación Basados en el concepto de inmutabilidad Los contenedores usados en desarrollo pueden usarse en ambientes de testing y producción Minimiza la brecha entre desarrollo e infraestructura Puede utilizarse para aplicaciones grá cas docker run v ~/workspace/:/home/eclipse/workspace/ \ e DISPLAY v /tmp/.X11unix:/tmp/.X11unix:ro \ d leesah/eclipse
de herramientas de gestión del ambiente docker: servicio docker, contenedores, imagenes Docker hub/registry: repositorio de imágenes públicas o privadas a partir de donde creamos contenedores
guración funcional que permita: Replicar un ambiente Recuperación ante desastres Surge la posibilidad de versionar la infraestructura Esto implica poder repetir la instalación de un server Surgen nuevas necesidades: Orden en cuanto al inicio de servicios Cambios de plataformas de virtualización por costos o funcionalidad
aplicaciones como si fueran código No impone restricciones Permite describir y automatizar los procesos e infraestructura La consecuencia es que la infraestructura se vuelve: Versionable Testeable Replicable Idempotente
[: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
Basados en Probamos un test implementado con en plataformas Debian 7 y Ubuntu 14.04 kitchen test de unidad ChefSpec test de integración Test Kitchen ServerSpec
chef que simpli ca y uni ca las tareas de crear y bootstrapear un nodo Crearemos antes un rol que describe un web server. Esto nos 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
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
'web01' do run_list ['role[webserver]'] end machine 'web02' do run_list ['role[webserver]'] end end machine 'proxy' do run_list ['recipe[myhaproxy]'] end Corremos en nuestra PC chefclient z r 'myinfra::chef,myinfra::aws,myinfra'
muy importante, porque sólo cambiando el driver de aprovisionamiento, podemos reusar nuestra infraestructura de nida Podemos incluso tener un cluster con VMs de diferentes proveedores
ahora Mesos Los ambientes se componen de nodos Los contenedores se manejan con stacks Usan docker-compose v1 Provee un catálogo de aplicaciones Permite extender el catálogo con uno propio Simpli ca la integración con registries privadas Proxy reverso basado en service discovery Simple escalamiento de contenedores
es importante: nombre del stack Creamos Iniciamos el stack: rancher-compose up Veri camos Upgradeamos: rancher-compose up -u my-app Veri camos Realizamos un rollback docker-compose.yml
chrodriguez
ham0215
paraworld
meihei3
freee
emiki
kazuya_araki_tokyo
konifar
kentaitakura
ks91
bkuhlmann
blue_goheimochi
linyixian
lauravandoore
mraible
schacon
colly
mthomps
philhawksworth
dougneiner
addyosmani
bryan
jrom
![EJEMPLO chef_role 'webserver' do run_list ["recipe[apt]","recipe[webserver]"] end machine_batch do machine](https://files.speakerdeck.com/presentations/2371be7c69864839804d7ec00bfed41b/slide_118.jpg){kind=link}
![GRACIAS TOTALES Contacto [email protected] [email protected] @car_unlp](https://files.speakerdeck.com/presentations/2371be7c69864839804d7ec00bfed41b/slide_131.jpg){kind=link}