Docker – Primeros Pasos

docker

En estos días estuve investigando un poco más como funciona Docker, tratando de entender la arquitectura y aprendiendo a usar los comandos de Docker.

Docker vs Maquinas Virtuales

El concepto de maquinas virtuales para desarrollar aplicaciones es bastante conocido. Desarrollamos una aplicación PHP en nuestra maquina (digamos que usamos Windows), pero nuestro server, el que va a hostear la aplicación, corre en Linux. Entonces creamos una maquina virtual en nuestra maquina para probar como funciona en ese sistema operativo.

Reproducir estos ambientes es pesado, ya que deberíamos armar una maquina virtual, exportarla y compartirla con el equipo de desarrollo. Imagínense el problema si somos un equipo de desarrollo en diferentes lugares del mundo y necesitamos compartirnos una VM que pesa 20 Gb, aún más si necesitamos hacer cambios a esos ambientes para replicar los cambios hechos en el ambiente de producción.

Algo un poco mas avanzado que podemos hacer es usar Vagrant para crear maquinas virtuales y Ansible, para provisionar maquinas virtuales instalando lo que necesitamos (dependencias y nuestra aplicación). De esta forma con unos pocos archivos en nuestro repositorio tenemos la configuración de nuestro ambiente reproducible por todo el equipo. El problema de mantener la misma configuración que el ambiente de producción sigue, pero un poco mas sencillo, es cuestión de modificar nuestros scripts de Ansible y todo debería seguir funcionando.

vagrant (1)Podemos ver en el gráfico como desde nuestros scripts de Ansible podemos tanto provisionar nuestra maquina virtual, como así también los ambientes de producción o staging.

El concepto de Docker va un poco mas allá. Que pasa si pudiésemos con un solo archivo crear una imagen que sea la misma que corra en nuestra VM de desarrollo, en staging, en producción, en la maquina de un tester, etc.

Acá entran en juego un poco de terminología de Docker:

Imagen: Es el conjunto de binarios, bibliotecas y mi aplicación. Todo esto se arma en un paquete que va a correr en un container.

Container: Es el lugar donde va a correr la aplicación con todas sus dependencias. Es un lugar aislado, nada de afuera lo modifica. Es decir, si corremos un container en un Linux Debian en producción, pero en nuestra máquina tenemos otra distribución va a funcionar igual, ya que todas las dependencias están dentro del container.

Dockerfile: Es el archivo que tiene la receta de como crear la imagen.

Docker Hub: Es el lugar donde se guardan las imágenes de Docker

docker vs vagrantTenemos un Dockerfile en nuestro proyecto, a partir de ese archivo creamos una imagen que publicamos en Docker Hub. Esta imagen tiene nuestra aplicación + dependencias.

Queremos instalar nuestra aplicación en producción, corremos un container con la imagen que esta en Docker Hub, lo mismo si queremos instalarla en staging o en un cluster.

Comandos Basicos de Docker

Los comandos que más vamos a utilizar en Docker son:

docker run <imagen>

Este comando nos permite correr un container con una imagen que tengamos localmente o que exista en Docker Hub.

docker start <nombre|id>

Nos permite arrancar un container que ya tengamos en nuestra maquina que este apagado, ya sea usando el nombre que le asignamos al crearlo, o el id autogenerado.

docker stop <nombre|id>

Nos permite parar un container que tengamos corriendo en nuestra maquina, nuevamente por nombre o id.

docker ps [-a incluye los containers apagados]

Este comando nos lista los containers que tengamos ejecutando en nuestra maquina, si agregamos la opción -a, nos muestra todos los containers que están en el registro, que alguna vez corrimos y nunca borramos.

Tengan cuidado porque cada vez que ejecutan docker run se genera un nuevo container y creanme que pueden llegar a tener muchísimos.

docker rm [nombre|id]

Este comando nos permite borrar los containers creados en nuestra maquina, tanto por nombre, como por id.

Manos a la obra

Vamos a empezar a  usar estos comandos y para esto vamos a usar una imagen que esta en Docker Hub que se llama tutum/hello-world .

Para ejecutar el container en nuestra maquina vamos a la consola de Docker y ejecutamos:

docker run -d tutum/hello-world

La opción -d nos crea pone a correr el container en background, si no ponemos esa opción nuestra consola va a quedar freezada y vamos a tener que abrir otra para interactuar con Docker.

Luego ejecutamos

docker ps

dockerps

Ya tenemos nuestro primer container corriendo :). Fíjense que dice Ports 80/tcp, entonces el container esta escuchando en ese puerto.

Esta imagen tiene una página donde nos muestra el nombre de nuestro container, intentemos entonces accederla.

Desde nuestro navegador ponemos en la URL a la IP de la maquina de Docker, en mi caso http://10.0.0.100.

Lo que nos va a pasar es que no vemos nada, el navegador nos dice ‘Connection Refused’.

Lo que nos pasa es que si bien el container esta escuchando al puerto 80, no tenemos un mapeo hecho de ese puerto del container, con el de la máquina de Docker. Para esto tenemos que agregar algunos parametros al comando run.

docker run -p 8080:80 tutum/hello-world

La opción -p nos permite mapear un puerto de la máquina de Docker, al container. En este caso, el puerto 8080 de la máquina de Docker se mapea al 80 del container.

Ahora si accedemos a la IP de la maquina de Docker, en mi caso http://10.0.0.100:8080 y vemos algo así:

Tutum-hello-world

Si ahora ejecutamos nuevamente docker ps vamos a ver lo siguiente

Dockerps

Vemos entonces que en la columna PORTS nuestro puerto esta mapeado.

Ahora vamos a parar el container.

docker stop 0bd2b89a3b5a

Cuando ejecutamos este comando el container se para, si queremos acceder en el navegador no vamos a ver nada y si ejecutamos nuevamente el comando docker ps, no vamos a ver nada.

La unica forma que podamos ver los contenedores parados es con el comando;

docker ps -a

dockerpsa

Ahora si quisieramos podriamos arrancar uno de estos containers apagados con el comando

docker start 0bd2b89a3b5a

Este comando pone en funcionamiento el container que habíamos apagado antes. Para ver si esta funcionando ejecutamos

docker ps

Vemos que todas los comandos los ejecutamos usando el id del container, sería mas cómodo usar el nombre. Para poder ponerle un nombre al container utilizamos la opción –name

docker run --name hello-world -p 8080:80 tutum/hello-world

Lo último que nos queda hacer es eliminar un container, para eso ejecutamos.

docker rm hello-world

Tengan en cuenta que para borrar un container antes tiene que estar parado.

Espero les sirva, nos leemos!

Qué es Docker?

dockerDocker es una plataforma para desarrollar, shippear y ejecutar aplicaciones utilizando la tecnología de virtualización de contenedores.

La idea es sencilla pero muy poderosa, todos sabemos que hace algunos años, para tener una aplicación corriendo en internet, necesitábamos un server exclusivo para esta. Es decir, así tuviéramos corriendo un servicio que atendia millones de requests por segundo o uno request por hora, teníamos un server para eso. Las contras de esto son conocidas, desperdicio masivo de recursos.

Un camino mas inteligente fue el de las maquinas virtuales, super utilizado actualmente, tenemos un solo server, que contiene varias maquinas virtuales corriendo en el. Es decir, que en lugar de tener una sola aplicación por server, ahora tenemos N aplicaciones en un server.  Sin embargo seguimos teniendo una desventaja, tenemos nuestro server con un sistema operativo + hypervisor. Y cada una de nuestras VMs tienen un sistema operativo y sobre este nuestra aplicación.

virtualizacion

Ahora si, que pasaría si en lugar de tener que instalar un sistema operativo en cada VM, podemos tener un contenedor que tenga nuestra aplicación y dependencias y que se comunique directamente con el kernel del sistema operativo del server.

Docker

Esta es la arquitectura de un server con Docker, tenemos el server con un sistema operativo, sobre este corre el Motor de Docker (Docker Engine) y sobre este cada uno de los container con la aplicación y sus dependencias.

Ventajas del uso de Docker

Ahorro de Recursos

Nuestros contenedores solo tienen nuestra aplicación y sus dependencias, no tenemos más un sistema operativo que consuma recursos.

Consistencia entre ambientes

Nuestro ambiente de desarrollo va a ser el mismo que en producción, no mas Infierno de Dependencias o En mi maquina funciona!. Si nuestra aplicación funciona dentro de un container de Docker, y en producción utilizamos Docker, estamos seguros de que la aplicación va a funcionar.

Compartir el ambiente de desarrollo

Ya no vamos a tener que gastar horas en armar ambientes de desarrollo para nuestro equipo, o intentar sincronizar los ambientes de desarrollo cuando por ejemplo cambiamos alguna version de interprete de Ruby. Simplemente compartimos en nuestro repositorio el Dockerfile, y cada desarrollador de nuestro equipo tiene una copia idéntica del ambiente de desarrollo en su maquina.

Escalabilidad

El tiempo que tarda un container en arrancar es mucho menor al de un sistema operativo, consume muchos menos recursos. En cuanto necesitemos mas instancias de nuestra aplicación, solo levantamos unos nuevos containers y listo. Esto también es una técnica utilizada con maquinas virtuales (AWS, Heroku, Azure, etc. lo hacen), pero el costo monetario y de tiempo de levantar una instancia de un container es muchísimo menor, según la web de Docker 7x mas rápido.

En el próximo posts voy a publicar un ejemplo de como usar Docker para una aplicación Ruby on Rails + Postgres.

 

 

Git – Comandos Básicos #1

Siguiendo con la serie de posts Git lo estas usando mal les voy a comentar los comando básicos y algunos conceptos que nos vas a ayudar a entender un poco más.

Lugares en GIT

Para comenzar con los comandos básicos tenemos que entender que en Git podemos distinguir 4 lugares.

lugaresGit

 

El primero es el directorio local de trabajo,  es donde se trabaja, se crean nuevas funcionalidades, se arreglan bugs, se crean archivos, etc.

Luego el area de cambios (Staging), en este lugar vamos a poner todas las cosas que queramos versionar con Git.

Una vez que estemos seguros de lo que queremos versionar, lo vamos a pasar al repositorio local.

El último lugar es el repositorio remoto, donde vamos a enviar los cambios que tengamos en nuestro repositorio local, para hacerlos públicos.

A medida que vayamos viendo los diferentes comandos vamos a ir refrescando estos lugares.

Comandos Básicos

Crear repositorio

Lo primero que vamos a hacer es crear un repositorio en Github. Un repositorio es el lugar donde vamos a guardar el código fuente de nuestra aplicación.

Desde la pagina de inicio podemos crear un repo haciendo click en “+ New Repository

Ponemos un nombre de repositorio y seleccionamos “Initialize this repository with a README

2015-02-09_20-57-59

Clone

En la página del repo nos va a indicar la dirección ssh.

2015-02-09_21-03-29

Una vez que la copiamos, vamos a la consola y ejecutamos

git clone [dirección ssh]

En mi caso es

git@github.com:ignaciojonas/test-git.git

Este comando nos va a crear una carpeta (Directorio de trabajo local) con le nombre del repo que tiene, el README.md y una capeta oculta que se llama .git

Status

Con este comando vamos a ver el estado actual de nuestro repositorio local. Es importante recalcar que en Git siempre vamos a ver el estado de nuestro repositorio en nuestra maquina, ya que Git guarda toda su información localmente y te permite seguir trabajando aunque estés desconectado de internet.

Dentro de la carpeta del repositorio ejecutamos

git status

Si no cambiamos nada nos debería mostrar algo como esto:

2015-02-09_21-13-24

  • En que branch estamos parados (Ya vamos a ver esto mas adelante)
  • Si nuestro branch esta sincronizado con el repositorio en Github (por defecto el repositorio de donde clonamos se llama origin)
  • Por ultimo que no tenemos ningún cambio, y que nuestro directorio esta limpio

Si ahora modificamos el archivo README.md y le agregamos por ejemplo

Este es un repositorio de prueba para comenzar a usar Git.

Una vez que grabamos el archivo y volvemos a ejecutar git status vamos a ver algo parecido a esto:

2015-02-09_21-19-05

Las primeras lineas son lo mismo que antes, pero vemos que ahora dice “Changes not staged for commit:” y nos da instrucciones para actualizar el archivo en el repo o rechazar los cambios. Por ultimo en rojo vemos el archivo que se modificó.

Add

Con el comando add vamos a indicarle a Git que queremos agregar algo al repositorio, ya sea algo nuevo o algo que modificamos.

Por ejemplo vamos a agregar el archivo README.md

git add README.md

Cuando tenemos muchos archivos y queremos agregar todos al area de stage podemos hacerlo con

git add .

Si tenemos archivos nuevos, tenemos que agregarlos por nombre (como lo hicimos con README.md) o bien agregando todo pero usando el siguiente comando.

git add -A

Ahora cuando ejecutamos git status vemos algo como esto:

gitadd

 

Vemos en la segunda linea, “Changes to be commited”, esto quiere decir que ya tenemos los achivos seleccionados para poder grabarlos en la historia.

Ahora nuestros archivos se encuentran en el segundo lugar de Git, el area de cambios (Staging). Para tener una imagen gráfica de esto es como poner las cosas arriba del mostrador, para que después alguien del otro lado lo guarde.

Commit

El comando commit nos va a permitir “grabar” en la historia los cambios que hicimos.

git commit -m "[mensaje representativo]"

Es muy importante que los mensajes de commit (Lo que esta entre comillas dobles) sean representativos. De nada sirve un mensaje muy genêrico, como por ejemplo “Cambios Varios”, siempre es mejor ser explícitos. Pensemos que lo que escribamos en la historia de git va a ser leído por todos los de mi equipo y cada uno le puede interesar ver donde se hizo un cambio especifico.

Por ejemplo en el ejemplo que estamos siguiendo en este post un buen mensaje sería

git commit -m "README.md - Agrego información de prueba"

Cuando ejecutamos este comando vamos a ver algo asi

gitcommit

Una vez ejecutado este comando, habremos agregado los archivos al repositorio local. Este commit queda grabado en la historia de Git en mi repositorio local hasta que lo subamos a un repositorio publico.

Ahora cuando ejecutamos git status, vamos a ver que nos da un mensaje que dice: Your branch is ahead ‘origin/master’ by 1 commit. Esto quiere decir que lo que esta en Github, esta “viejo”, ya que yo tengo un cambio en mi maquina que no esta en ese repositorio publico.

gitstatusaftercommit

En este punto nuestro archivos están en el tercel lugar de Git, el repositorio local, el cambio que hicimos a README.md esta grabado en la historia de Git.

En la próxima entrega de Git – Lo estas usando mal, vamos a ver como hacemos para que todos estos cambios que hicimos localmente, lo pueda ver otro miembro de nuestro equipo, como sincronizar nuestro repositorio local con el repositorio remoto y las primeras resoluciones de conflictos.

 

Configurar GIT

Siguiendo con la serie de post, hoy les voy a comentar como tengo configurado GIT en mi maquina.

Configuración basica

Identidad

Para empezar, tenemos que configurar el nombre de usuario y el mail. Para esto ejecutamos los siguientes comandos, reemplazando con nuestro nombre y nuestro email.

$ git config --global user.name "Ignacio Jonas"
$ git config --global user.email ignaciojonas@example.com

Editor de texto

Cuando queramos editar un mensaje de un commit o hacer un rebase o algunas otras cosas que vamos a ir viendo mas adelante, algo que vamos a necesitar es un editor de texto. El que más me gusta a mi es Vim, pero ustedes pueden usar el que quieran.

$ git config --global core.editor vim

Si no se sienten cómodos usando un editor de consola pueden incluso usar cualquier otro editor gráfico. Para configurar Atom por ejemplo:

git config --global core.editor "atom --wait"

El flag –wait hace que Git espere a que cerremos el editor para commitear.

AutoCRLF

Cuando estamos trabajando en diferentes plataformas (parte del equipo en Linux, otros en Mac OS y otros en Windows) es importante prestarle atención a cómo tenemos configurado Git con respecto a los fines de línea, ya que puede que tengamos algunos problemas.

Git nos ayuda a no tener estos problemas convirtiendo los fines de linea CRLF (Windows) en fines de linea LF (Unix).

Si usas Windows conviene tenerlo configurado en true, esto convierte los fines de linea LF en CRLF cuando hacemos checkout del código.

$ git config --global core.autocrlf true

Si estas trabajando en un sistema operativo Unix (Linux o MacOS), no es necesario que Git convierta los fines de linea, sin embargo, si por casualidad introducimos un fin de linea CRLF, conviene que Git se haga cargo por nosotros de convertirlo en LF. Para esto lo configuramos con el siguiente comando.

$ git config --global core.autocrlf input

Por último, si todo el equipo esta trabajando en Windows, haciendo un proyecto para funcionar solo en Windows.

$ git config --global core.autocrlf false

Como veo las configuraciones?

Para ver como tenemos configurado Git lo único que tenemos que hacer es ejecutar el siguiente comando

$ git config --list

Configurar la clave SSH

Para poder identificarnos contra un servidor que tenga una copia de el repositorio lo podemos hacer de diferentes maneras. La más común es conectarnos usando una clave SSH.

Para todos los ejemplos de esta serie de posts, vamos a usar GitHub. Si no tenés un usuario podes registrarte acá.

Crear una clave SSH

Si tenés una clave ssh creada, entonces podes ir a Configurar la clave SSH en Github.

Para generar una clave SSH basta ejecutar el siguiente comando.

$ ssh-keygen -t rsa -C "your_email@example.com"

Cuando ejecutamos, nos va a aparecer algo parecido a lo siguiente, apretamos enter. La clave SSH se va a guardar en una carpeta .ssh dentro de la carpeta de nuestro usuario.

Generating public/private rsa key pair.
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Apretar Enter]

Luego nos va a pedir que ingresemos un passphrase. Es recomendable que pongamos una buena frase, aunque no es obligatoria.

Una vez que hecho esto tenemos la clave SSH generada.

Configurar la clave SSH en GitHub

Para agregarla a Github, lo primero que hacemos en loguearnos con nuestro usuario.

Vamos a Settings->SSH Keys y hacemos click en Add SSH Key.

GitHubSSHKeys

Completamos un titulo (Para recordar donde tenemos configurada esa clave SSH) y en el campo Key ponemos el contenido de nuestro archivo ./ssh/id_rsa.pub.

Para copiar el contenido (al menos en Mac OS) podemos ejecutar

$ pbcopy < ~/.ssh/id_rsa.pub

Este comando nos copia el contenido de la clave publica en el portapapeles.

Por último hacemos click en Add Key.

sshKey

Con esto terminamos la configuración básica de Git. En los próximos posts les voy a contar como empezamos a usarlo.

Atom – El editor de @github

Hace un tiempo conocí Sublime Text, un genial editor de texto multi -plataforma en el cual podes escribir en cualquier lenguaje de programación y tenes muchísimos plugins que te facilitan la vida.

La única desventaja que le encontré es que es pago y para usarlo sin pagar hay que “aguantar” un cartel que aparece de vez en cuando.

Hace ya un tiempo la gente de GitHub crearon Atom, su propio editor de texto, que se parece muchísimo a Sublime.

Lo instale en mi maquina y el cambio a usar Atom fue automático, simplemente hay que acostumbrarse a los atajos de teclado.

Atom, Git y GitHub

Algo que es genial de éste editor es que podemos ver el estado de nuestro repositorio solo viendo el árbol de archivos a la izquierda de la pantalla. Como es esto?, con colores nos indica si tenemos un archivo que aun no esta en staging, o que fue modificado o que esta en su ultima version.

Por ejemplo, aun no hice ningún cambio en este proyecto, entonces en el árbol de archivos todo es gris.

AtomEditor-NoChangesSi creo un nuevo archivo este aparece de color verde y si modifico otro aparece de color naranja.

AtomEditedNewOtra cosa que es muy útil es la previsualización de archivos escritos en Markdown. Como seguramente vieron, los archivos Readme.md de todos (o gran mayoría) de los repositorios de GitHub están escritos en Markdown.

Para usarlo simplemente en un archivo markdown apretamos ⌘ + shit + p, buscamos markdown, apretamos enter y voila.

markdownrPreview

Packages

Hay montones de plugins (packages) que se pueden instalar desde el menu de settings (⌘ + ,).

Solo les voy a recomendar uno que me viene salvando mucho tiempo Pretty-JSON. Ejecutando este plugin en un archivo JSON nos lo indenta automaticamente, ideal cuando se esta trabajando con APIs que deveulven JSONs gigantescos (No se olviden de seleccionar el  lenguaje del archivo como JSON, abajo a la derecha).

JSONPretty

 

 

 

 

 

 

Instalar GIT

Empezando con esta serie de posts, les voy a contar como instalar GIT.

Hace muy poco me mude a trabajar en Mac OS Yosemite y un colega del trabajo me mostró iTerm2, es una consola mejorada para Mac OS. La verdad que es mejor que Terminal (Default en Mac OS). Así que te recomiendo que la instales porque mejora muchísimo la experiencia.

Si estas pensando usar GIT en Linux, la consola por default esta más que bien.

Si vas a usar Windows, te recomiendo que te instales cygwin, que es un emulador de la consola de Linux para Windows. Con esto tenes todo el poder de la consola de Linux, pero en Windows.

Si no sos muy amigo de las consolas, existen interfaces gráficas para GIT y en algún post voy a publicar algunas, pero para entender bien el funcionamiento de GIT lo mejor es la consola (@mrleinad dixit).

Instalación en Mac OS

En Mac OS, GIT, viene instalado por default, pero es recomendable que te instales la ultima version usando brew y algunos plugins más.

Antes de empezar podemos ver que GIT es el que tenes instalado, abrí iTerm y ejecutas

which git

Si la ruta de GIT es /usr/local/git entonces vamos a desinstalarlo haciendo lo siguiente (Usar sudo en los comandos cuando sea requerido).

rm -rf /usr/local/git
rm /etc/paths.d/git
rm /etc/manpaths.d/git
Ahora vamos a instalar brew con el siguiente comando:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Una vez instalado brew vamos a seguir con la instalación de GIT

brew install git
brew link git
Si el último comando produce un error podemos arreglarlo haciendo
brew update
brew upgrade
brew doctor
Por último instalamos git-completion que nos sirve para que la consola autocomplete los comandos de GIT cuando apretamos TAB.
brew install git bash-completion

Instalar GIT en Windows

Para empezar hay que bajarte la ultima versión de cygwin.
Ejecutas el instalador de cygwin y seleccionas todas las opciones por default hasta el menu de seleccionar paquetes (Select Package)
En ese menu hay que elegir:
  • git-gui
  • gitk
  • git-completion
  • openssh
  • vim (si no esta seleccionado por defecto)

Update: Un aporte del grande  de @andresgariglio

Instalar GIT en Linux (Ubuntu)

Simplemente

sudo apt-get install git-core git-completion

Con esto tenemos todo el ambiente funcional para empezar a aprender GIT.

Git – Lo estas usando mal

Git-Logo-1788C

Muchos sabemos que GIT es un “muy potente” sistema de control de versiones. Y también muchos pasamos horas/días tratando de entender que es lo que “esta haciendo”. Cuando me pasa eso, @falvarisqueta siempre me dice a tono de chiste “Los estas usando mal”, o también, “el problema esta entre la silla y el teclado; y no en GIT”.

En esta serie de posts (GIT – Lo estas usando mal) voy a ir publicando lo que fui aprendiendo en este último tiempo que comencé a usarlo de una forma un poco más intensiva y profesional.

Algunos de los tópicos que tengo planeados:

  • Instalar GIT
  • Configurar GIT
  • Comandos Básicos
  • Rebasing
  • Como hacer un merge
  • Re-escribir la historia
  • Workflows de Trabajos – Feature Branch

 

Git – Cómo poner el nombre del branch en la Consola

Para todos los usuarios de Git, algo importantísimo es saber donde uno esta parado, en que branch está. Hace unos meses estoy usando Ubuntu para el trabajo y modifique un poco la consola para que se vea el nombre del branch cuando estoy parado en un repositorio.

Para hacer esto hay que seguir los siguientes pasos:

  • Parados en el home de nuestro usuario ejecutamos: gedit .bashrc
  • Agregamos el siguiente código en el archivo (abajo del todo)
  • Guardamos y cerramos .bashrc
  • Ejecutamos: source .bashrc.  Esto recarga la configuración de la consola
  • Voila el nombre del branch va a aparecer en la consola cuando estemos dentro de un repositorio de Git.

GitBranchName

Debian + Jenkins + PHP + GitHub

Preparando una taller para unos alumnos sobre Integración Continua, configure un servidor utilizando Jenkins. A continuación los pasos que fui siguiendo para instalar las herramientas necesarias.

 

Herramientas que vamos a utilizar

Paso a Paso

Instalar Debian

Lo primero que tenemos que hacer es instalar Debian, en el cuadro de “Software Selection” elegimos:

  • Web Server
  • SSH Server
  • Mail Server

Software Selection

Instalar PHP y algo más…

Nota: Para los pasos que siguen, todos los comandos se ejecutan en una terminal como root.

Lo siguiente que vamos a hacer, como estamos creando un servidor de integración continua para PHP, es instalar PHP y Pear.

apt-get install php5 php5-dev php5-xdebug php-pear

Instalar Jenkins

Los siguientes pasos están tomados de la documentación oficial de Jenkins.

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
apt-get update
apt-get install jenkins

QA Tools

Para instalar las QA tools vamos a usar Pear.

pear upgrade PEAR
pear config-set auto_discover 1
pear install pear.phpqatools.org/phpqatools
pecl install xdebug

Instalar Apache Ant

Como nuestro template para contruir proyectos PHP va a utilizar Ant, vamos a instalarlo.

wget http://www.us.apache.org/dist/ant/binaries/apache-ant-1.9.2-bin.tar.gz
tar xvfvz apache-ant-1.9.2-bin.tar.gz -C /opt
ln -s /opt/apache-ant-1.9.2 /opt/ant

Configurar la variable de entorno para que podamos ejecutar Ant desde cualquier lugar

sh -c 'echo ANT_HOME=/opt/ant >> /etc/environment'
ln -s /opt/ant/bin/ant /usr/bin/ant

Para verificar que Ant se instalo bien, ejecutamos:

ant -version

Instalar Git

Por último, para que Jenkins pueda traer el código a integrar desde GitHub, necesitamos instalar git

apt-get install git-core

Luego tenemos que generar una RSA key para el usuario jenkins (el usuario que ejecuta jenkins). Para eso desde una consola de root, cambiamos el usuario a jenkins y generamos la key.

su - jenkins
ssh-keygen -t rsa -C "your_email@example.com"

Luego copiamos nuestra clave publica.

Para eso podemos hacer:

cat .ssh/id_rsa.pub

Copiamos la salida del comando cat y la pegamos en SSH keys en nuestro usuario de GitHub.

SSH Keys

 

Por último, con el usuario Jenkins, ejecutamos

ssh -T git@github.com

Y aceptamos github.com como parte de nuestros know hosts.

KnowHosts

Últimos detalles

Para poder acceder a Jenkins desde otra maquina, vamos a tener que configurar IP Tables para que nos permita acceder al puerto 8080, desde afuera. Para eso podemos ejecutar, nuevamente como root.

iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

Ahora ya tenemos Jenkins andando en nuestro Debian.

Jenkins Home Page

En proximos posts voy a mostrar como configurar un proyecto PHP en Jenkins.

MSIS7055: Not all SAML session participants logged out properly

Estuve trabajando con algunas aplicaciones SharePoint 2010, todas hosteadas en un mismo farm, pero en diferentes web applications.

Ambas aplicaciones están configuradas para usar ADFS como trusted issuer. Hay dos ADFS atendiendo los requests, y un proxy delante de ellos.

Cuando me autentico en una aplicación y luego, en otra instancia del navegador, abro otra aplicación, gracias al Single Sign-On en la segunda aplicación  no me pide credenciales.

Ahora cuando cierro una de las aplicaciones, mientras la otra está abierta en otro navegador, haciendo click en logout,  ADFS me muestra el siguiente error.

ADFS Error

Mirando el event viewer del proxy de ADFS, descubrí que la exception que generaba era:

Encountered error during federation passive sign-out. 
MSIS7055: Not all SAML session participants logged out properly

Si bien ADFS intenta deslogearse y borrar todas las cookies, no puede, porque hay otro navegador que esta usando la cookie.

Para arreglar este problema simplemente tenemos que ir a la carpeta de IIS de ADFS (En general se encuentra en C:\inetpub\wwwroot\adfs\ls) y editar el archivo error.aspx.cs. Al final de la función Page_Load agregamos la siguiente linea:

if (Exception.Message == "MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.")
{
Response.Redirect(System.Web.Configuration.WebConfigurationManager.AppSettings["signoutredirect"]);
}

view raw
SingleLogout-ADFS2.0
hosted with ❤ by GitHub