4. PRESENTACIÓN PERSONAL
Docente en UNLP
Trabajé en IT mayormente de 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
5. CONTRIBUCIONES AL SL
Mi per l en
(Kettle)
Varias recetas 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
6. EXPERIENCIA RELEVANTE EN LA TEMÁTICA
Gestión de la infraestructura: email 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
8. INTRODUCCIÓN
Cada organización tiene sus particularidades, aunque en
varios lugares 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
9. ANALIZAREMOS LA PROBLEMÁTICA DESDE
La perspectiva de desarrollo
La perspectiva de infraestructura
La puesta en producción: el momento en que desarrollo e
infraestructura interactúan
11. AMBIENTES COMPLEJOS
Las aplicaciones ya no son las tradicionales arquitecturas
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
12. GESTIÓN DE PROYECTOS
Independientemente de la gestión de proyectos teórica 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
13. GESTIÓN DE PROYECTOS
Relacionar los tickets/versiones del producto en
producción, 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
14. DEPLOYMENTS
Poner una versión de un producto nuevo en producción
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
15. METODOLOGÍAS ÁGILES
El hace énfasis en los siguientes valores:
Individuos 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
16. TDD
Cuando deseamos apegarnos a los requisitos de QA es
bueno aplicar tests
Los tests deben controlarse por un área de QA en cada
etapa del desarrollo, estableciendo políticas de aceptación
para cada etapa
17. TDD
Ejemplos de políticas:
El código no es revisado antes 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
18. VERSIONES DE LIBRERÍAS Y LENGUAJES
Es común que los desarrolladores 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
19. GESTIÓN DE VERSIONES
Si bien el código se maneja con 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
20. ACCESO AL AMBIENTE DE PRODUCCIÓN
Siempre es necesario acceder a 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
21. REPLICA DEL AMBIENTE DE PRODUCCIÓN
Poder obtener un ambiente similar 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
22. ESTADÍSTICAS Y MONITOREO
Las estadísticas generalmente se utilizan por IT 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
23. ESTADÍSTICAS Y MONITOREO
Cuando un valor se aleja de la 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
25. SERVICIOS CRÍTICOS
Hoy día, servicios como el DNS o Mail 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.
26. SERVICIOS CRÍTICOS
Es común que la gestión de cuentas de 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
27. GESTIÓN MANUAL DE LOS SERVICIOS E INFRAESTRUCTURA
En los grupos 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
28. EL CLIENTE MÁS DEMANDANTE: DESARROLLO
El área de desarrollo es 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
29. EL CLIENTE MÁS DEMANDANTE: DESARROLLO
Continuando con los servicios que 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
30. AMBIENTES HETEROGÉNEOS
Hasta no hace mucho tiempo e incluso en 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
31. AMBIENTES HETEROGÉNEOS
La heterogeneidad trae problemas al área de
infraestructura
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?
32. COMPROMISO DE LA SEGURIDAD POR HOSTING
Cuando las aplicaciones se 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
33. POLÍTICA DE BACKUPS PARA LAS APLICACIONES
Infraestructura posee políticas de 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
34. ESTADÍSTICAS Y MONITOREO DE APLICACIONES
En infraestructura, las estadísticas y 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
35. Y MUCHO MÁS...
El área de infraestructura tiene que atender 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
37. PUESTA EN PRODUCCIÓN
Deben de nirse procedimientos para:
Deploy de nuevas aplicaciones
Upgrade de aplicaciones existentes
Rollback de aplicaciones actualizadas
Considerar la forma en que se actualizan bases de datos
38. DEPLOY DE NUEVAS APLICACIONES
Instalar una nueva aplicación en producción 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
39. UPGRADE DE APLICACIÓN EXISTENTE
Revisar si alguno de los puntos 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
40. ROLLBACK DE APLICACIÓN ACTUALIZADA
Ante algún fallo inmediato detectado luego 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
41. ACTUALIZACIONES DE LAS BASES DE DATOS
El versionado del código 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
42. OTRAS CUESTIONES A CONSIDERAR EN LA PUESTA EN
PRODUCCIÓN
Ante 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
44. INTRODUCCIÓN
No disponer de ambientes implicaría:
Tener código versionado o 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
45. AMBIENTES
Es común ver alguno de estos ambientes en una
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
46. AMBIENTES
Pre-producción: es la instancia previa a producción, y
consiste 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.
48. INTRODUCCIÓN
En este apartado veremos qué metodologías y/o
herramientas han surgido para solucionar algunas de las
necesidades mencionadas según la perspectiva de desarrollo
e infraestructura
Asimismo, mostraremos que estas soluciones introdujeron
nuevos problemas
49. VIRTUALIZACIÓN
Existen diferentes alternativas de virtualización, que
pueden ser unas 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
50. COMPLICACIONES CON LA VIRTUALIZACIÓN
Sin una solución de storage no 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
51. UN SERVIDOR QUE HOSTEA MÚLTIPLES
APLICACIONES
Cuando varias aplicaciones comparten 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
52. NUEVAS TENDENCIAS
Surgen herramientas que requieren investigación antes de
su 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
53. ALTA DISPONIBILIDAD / FAILOVER /
ACTUALIZACIONES
Los stacks de un 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
55. DEFINICIÓN
El 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 e
infraestructura
56. OBJETIVO
Aplicar metodologías ágiles tanto en desarrollo como en
infraestructura
Lograr implementar ujos rápidos de trabajo plani cado
Incrementar la con abilidad, estabilidad y seguridad de los
ambientes productivos
57. ORÍGENES
Aproximadamente en el año 2009 ante la convergencia de
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
58. ORÍGENES
La global disponibilidad de tecnologías de cloud: PaaS/IasS
AWS EC2
Google Compue Engine
Microsoft Azure
Heroku
Digital Ocean
BudgetVM
Softlayer
Rackspace
59. CARACTERIZACIÓN
DevOps es un movimiento, losofía o práctica
Que se 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
60. INFRAESTRUCTURE AS CODE
IaC es el proceso por el cuál 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
62. TEST DE LA INFRAESTRUCTURA
Con las herramientas anteriores es posible realizar tests de
la infraestructura:
Tests de unidad:
Tests de integración
rspec-puppet
ChefSpec
ServerSpec
64. INTEGRACIÓN CONTINUA
Para comprender bien este concepto, tenemos que
considerar 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
65. PROYECTO CON VARIAS RAMAS
¿Cómo es posible garantizar un merge satisfactorio en todos los casos?
66. INTEGRACIÓN CONTINUA
Promueve el frecuente merge con la rama principal
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
68. DELIVERY Y DEPLOYMENT CONTINUO
Generalmente se confunden delivery y deployment
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
70. INTRODUCCIÓN
En este apartado veremos ejemplos de algunas herramientas
que 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
72. DESDE LA PERSPECTIVA DE DESARROLLO
Si bien cada proyecto es 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
74. AUTOMATIZANDO LOS DEPLOYS
Esta tarea tiene como objetivo automatizar la 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
75. UN EJEMPLO: CAPISTRANO
A 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}"
end
end
Ver ejemplo
76. USO DE CAPISTRANO
cap install # Inicializa el directorio
cap 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'
}
77. USO DE CAPISTRANO
Además de los ambientes, capistrano de ne 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
78. EJEMPLO DE CAPISTRANO Y JEKYLL
es uno de los tantos 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
79. EJEMPLO DE CAPISTRANO Y JEKYLL
Con capistrano:
Deployamos el sitio: 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
80. CAPISTRANO Y DESARROLLOS DINÁMICOS
En sitios que no son estáticos, 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
81. CAPISTRANO Y WORDPRESS
Creamos un wordpress que mantenemos localmente
Personalizamos 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
84. VAGRANT
Simpli ca la con guración, reproducibilidad y
portabilidad de 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
90. EJEMPLOS VAGRANT
Multimachine (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
91. EJEMPLOS VAGRANT
AWS 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
92. EJEMPLO VAGRANT Y AWS
Vagrant.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]'
]
end
end
vagrant rsync - Requiere este comando si algo se modi ca -
Ejemplo de servidor Rancher
94. DOCKER
Permite correr contenedores linux aislados sólo en Linux
Promueve 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
95. CONCEPTOS DOCKER
Docker funciona a partir de:
Docker engine: set 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
97. EJEMPLO
Iniciamos 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?
99. DOCKER COMPOSE
Se describe una aplicación compuesta por más de un
contenedor mediante un yml
version: "2"
services:
wordpress:
image: wordpress
links:
db:mysql
ports:
8080:80
db:
image: mysql:5.7
Ver ejemplo completo
102. DESDE LA PERSPECTIVA DE INFRAESTRUCTURA
Se intenta capturar una con 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
103. HERRAMIENTAS
Gestión de las con guraciones usando Chef
Gestión de la infraestrcutura usando chef-provisioning
Docker en producción con Rancher
104.
105. CHEF
Chef permite modelar la evolución de nuestra
infraestructura y 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
106. CONCEPTOS DE CHEF
Para lograr su objetivo se utilizan de niciones reutilizables
llamadas cookbooks y recipes
Se programa en Ruby usando una DSL
109. EJEMPLO DE UNA RECETA
package '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
111. DESPLEGANDO EL POTENCIAL DE CHEF
Bootstrap de nodos
Usaremos knife-ec2
Búsquedas
Ambientes
ssh en paralelo
Búsquedas en recetas
Ejemplo con ha-proxy
112. BOOTSTRAP DE NODOS
Usaremos Amazon EC2 y un plugin de 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
113. UN POCO DE KNIFE
knife 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
114. CREAMOS UN PROXY REVERSO
Esta 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
}
end
node.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
115. CHEF NO ES EL ÚNICO
Y... ¿por qué chef?
Hoy día Ansible es la alternativa más elegida
Puppet es la principal competencia
117. INTRODUCCIÓN
Chef provisioning extiende chef permitiendo crear VMs en
diferentes plataformas de virtualización
Vagrant
AWS
Azure
DigitalOcean
VMWare
XenServer
Google Compute Engine
IBM SoftLayer
Y varios más
118. ¿QUÉ ES ENTONCES?
Permite con gurar nuestro cluster de máquinas de forma
agnóstica de la plataforma
Evita el uso reiterativo de knife para iniciar VMs
121. Y AHORA CON VAGRANT
chefclient z r 'myinfra::chef,myinfra::vagrant,myinfra'
Esto es 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
128. RANCHER
Permite con gurar ambientes
Con Cattle, Swarm, Kubernetes y 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
129. EJEMPLO
Deployamos un wordpress desde el catálogo
Fijamos que sólo corra la db en un nodo determinado
Escalamos el servicio
130. OTRO EJEMPLO
Creamos una aplicacion propia
El nombre del directorio 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