debian

Google es satán o regenerar el directorio de data de postgreSQL sin reinstalar

Una hora buscando una chorrada que, porque hoy tenía el cuerpo así, no conseguía recordar. Y nada, buscando:

Regenerate data folder on postgresql, corrupted postgresql data directory fix, how to restore a corrupted postgresql installation… y así innumerables veces. El PUTO google me llevaba todo el rato a páginas de LUSERS de mierda cuya magnifica solución para el asunto era un apt-get –purge remove.

Aplausos, campeones.

Pues bien, para aquellos a los que también os irrita el auge de los retrasados mentales en internet y tengáis mala memoria como yo, aquí os recuerdo como se practica algo tan sencillo:

Asumo que hacéis backups de vuestras bases de datos. Y que sois limpios y aseados.

Copiáis vuestros scripts maravillosos que podáis (o no) tener en vuestro data de postgres para no perderlos en otra parte. Ejecutáis:

rm -rf <VUESTRO DIRECTORIO DE POSTGRES DATA>/*

En mi caso:

rm -rf /var/lib/postgresql/9.3/main/*

Lo dejáis limpito como una patena. Y ahora ejecutais:

<PATH DE VUESTRO BIN DE POSTGRES>/initdb <VUESTRO DIRECTORIO DE POSTGRES DATA>

En mi caso:

/usr/lib/postgresql/9.3/bin/initdb /var/lib/postgresql/9.3/main/

Y ya está, ya tenéis un data fresquito y limpito para volver a hacer el punki. Ya váis restaurando vuestros backups y, por vuestro bien, espero que esto solo os pase en entornos de testing, como a mi.

Anuncios
nginx

Docker y Nginx

Previously, on eltioe1000…

DOCKER. CONTENEDORES LIGEROS PARA LEVANTAR APLICACIONES EN SEGUNDOS.

Os contaba un poco sobre la existencia de Docker, no sé si os interesa, no sé si alguien me lee… ¿hola?, ¿hay alguien ahí?, ¿no?, bueno… seguiré hablando solo, tampoco pasa nada.

Hoy, incautos amigos, os voy a contar un poco sobre como levantar un contenedor en docker, con sus comanditos y sus pasitos uno por uno. Y cómo llegar hasta el servicio con la ayuda de nginx. Cosa facilonga para todos los públicos, incluido yo mismo.

Al lío.

Se me antoja, como ejemplo, así a bolapie; levantar un sphinx en docker por el puerto 3312. ¿Vale tetes?

Pues bien, empecemos.

Antes que nada, docker está en pañalitos. Acaba de empezar a andar, como quien dice. Por tanto todavía hay unas consideraciones previas sobre estabilidad que yo creo que, con el tiempo, desaparecerán. Se puede instalar en cualquier distribución siempre y cuando se respeten unos requisitos de versión de kernel, etc. Pero lo ideal, para que funcione guay, guay; es ponerlo en Ubuntu Server 13.10. Así que eso he hecho yo y va bien, no he visto todavía errores. Aquí podéis leer sobre cómo instalar docker en una Ubuntu, pero es tan sencillo como:

Añadimos con un editor el repositorio a nuestro sources.list:

deb http://get.docker.io/ubuntu docker main

Añadimos la clave para el repositorio de docker y actualizamos apt:

sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9

sudo apt-get update

sudo apt-get install lxc-docker

Opcionalmente, podemos verificar que todo ha funcionado poniendo en marcha un contenedor con bash:

sudo docker run -i -t ubuntu /bin/bash

Con estos simples pasos tendremos docker funcionando. Vamos al nginx.

En Ubuntu, oh, sorpresa:

sudo apt-get install nginx

Y YA ESTA. Ya tenemos un nginx funcionando.

La mandanguilla: Aquí tenéis un Dockerfile del repositorio oficial de docker con el que tenéis un primer pasito para poner sphinx en docker. Pero en realidad no hay que instalar tantas cosas como las que dice ahí para hacerlo funcionar. Por otro lado, ese Dockerfile es interactivo y el que os voy a enseñar yo es no interactivo.

¿Que, qué es esto?, me alegra que me hagáis esta pregunta.

“Grosso modo”, el modo interactivo es lo que hemos hecho antes para comprobar que docker funcionaba. Levantar un contenedor (con o) sin Dockerfile con “algo” (/bin/bash) con lo que podamos utilizar el contenedor como si fuera una máquina virtual. De modo que una vez ahí podemos utilizar apt, instalarnos vim, top, htop, etc y montarnos la máquina que queramos nosotros. Ojo, que docker es no persistente y en cuanto la paréis todos los cambios desaparecerán en la nada. Para hacer los cambios persistentes hay que currárselo, hablaremos de eso otro día, o no, porque me da mucha pereza el tema. La verdad. El modo no interactivo es aquel en el que escribiremos nuestra recetita en el Dockerfile, le diremos que no es interactivo y le daremos un punto de entrada (en el caso de sphinx, le diremos que lo arranque). Con lo cual, en cuanto levantemos el contenedor, empezará a correr sin tener nosotros que entrar a levantarlo o gestionarlo de manera alguna. Esta es la gracia del asunto, amigos.

Inciso hecho. Haré otro inciso.

Existe el comando “docker attach <CONTAINER ID>” con el que podéis entrar dentro de un contenedor y gestionarlo. Ojo con poner “exit” para salir. A colación de lo que os he contado anteriormente. Imaginad que entráis, os ponéis a tirar comandos como si no hubiera un mañana y os montáis ahí la rehostia de contenedor que hace virguerías. Pagados de vosotros mismos, una vez habéis terminado decidís que es buena idea salir del contenedor con el comando “exit“. Error. Con eso pararéis el contenedor y, como no es persistente, todo el trabajo se perderá en el limbo. Para salir de un contenedor al que nos hemos enganchado usaremos Ctrl+P+Q. Esto es, mantener control y pulsar la P y la Q sin soltarlo. Con esto haremos un deattach y no se parará el contenedor. Lo podéis comprobar con el comando “docker ps” que os muestra todos los contenedores que tenéis corriendo y, ya que estoy, con “docker ps -a” veis todos los contenedores corriendo y sus estados por si os da por arrancar uno en algún estado previo a una cagadita, Emilconsejo©.

A partir de este punto os recomiendo que os leáis un poco la documentación sobre buenas prácticas de docker. Pero bueno, sin entrar en detalles tendréis que decidir un lugar donde poner los ficheros de configuración que queráis pasarle al contenedor y los lugares donde queráis que el contenedor os deje ficheros que no queráis perder. Por ejemplo, un sphinx (o un elasticsearch) suele tener un directorio donde guardan todos los índices de búsqueda. Del mismo modo suelen requerir unos ficheros de configuración con vuestra configuración particular para funcionar. Lo normal es usar /var/docker para crear dentro vuestro árbol de directorios para cada contenedor que uséis. En el caso de sphinx es buena idea crear /var/docker/sphinxsearch y dentro el siguiente árbol:

.
├── etc-sphinxsearch
│       └── sphinx.conf
└── var
├── lib
├── log
│      ├── query.log
│      └── searchd.log
└── www
└── sphinx

Como veis tenemos un directorio para guardar la configuración de sphinx en etc, un directorio var con su espacio para lib y con su espacio para logs. Un directorio www requerido por sphinx donde él ya dentro creará los índices y todo lo que necesita. ¿Y cómo sabe el contenedor que tiene que guardar las cosas aquí?, eso lo explicaremos dentro de un momento. Pero primero, el Dockerfile (que estará en el directorio del usuario con el que ejecutemos docker, en la carpeta que hemos creado previamente llamada sphinx, originalidad al poder). Un ejemplo sería:

###  DockerFile for sphinx

FROM debian
MAINTAINER Joh Doe (johndoe@whatever.com)

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && apt-get –yes upgrade
RUN apt-get install –yes libpq5 unixodbc sphinxsearch

ADD sphinx.conf /etc/security/limits.d/sphinx.conf
ADD sphinxsearch /etc/default/sphinxsearch

ENTRYPOINT [“/usr/bin/searchd”]

# docker run -p 3312:3312 -d -v /var/docker/sphinxsearch/etc-sphinxsearch:/etc/sphinxsearch -v /var/docker/sphinxsearch/var/log:/var/log/sphinxsearch -v /var/docker/sphinxsearch/var/lib:/var/lib/sphinxsearch -v /var/docker/sphinxsearch/var/www:/var/www debian/sphinx

Es fácil. Se ve que lo que hacemos es simplemente decirle lo que os he comentado antes, que no es interactivo. Instalar lo necesario para sphinx y luego veis que añadimos ficheros de configuración (que deben de estar en el mismo directorio que el Dockerfile) a los lugares típicos donde deberán estar, solo que personalizados. Esta parte ya dependerá de vosotros. Y le decimos, por último, el punto de entrada que será, precisamente, el demonio de sphinx.

Podéis extrapolar este ejemplo a cualquier otra cosa que no sea sphinx. Es exactamente igual solo que con las particularidades de lo que sea que tratéis de instalar.

El último comando viene comentado, no vale para el Dockerfile, es un mero recordatorio del comando que hay que lanzar para levantar este contenedor. Ahí, si os fijáis, le decimos que ejecute docker abriendo el puerto 3312, el -d significa “no interactivo” y las -v sirven para indicarle a docker dónde están los directorios donde queremos que guarde y encuentre cosas. Lo que os he comentado antes. Le diremos todos esos directorios y esto nos levantará un contenedor con sphinx con nuestra configuración adaptada a nuestras necesidades.

Añadiremos también un fichero llamado sphinxsearch en el que debemos de indicar lo siguiente:

START=yes

Esto es una particularidad de sphinx, sin más, para que arranque solo.

Por tanto si ejecutamos el comando que viene al final del Dockerfile tendremos nuestro contenedor con sphinx funcionando y listo.

Vamos con la parte de nginx.

Acordaros que antes hemos instalado nginx. Bien, en /etc/nginx/ es donde se encuentra todo lo bueno. Profundizar en el maravilloso mundo de nginx puede ser algo arduo que os dejo para vuestros ratos libres entre paja y paja. Aquí solamente os voy a decir como exponemos el puerto 3312, ¿os suena, verdad? para que se pueda acceder a nuestro sphinx desde fuera.

En el directorio de nginx tenemos un par de carpetas peculiares (en las nuevas versiones, en las viejas la cosa es distinta y desordenada, pero eso ya os lo miráis vosotros). Una se llama “sites-available” y la otra “sites-enabled”. Si sabéis usar apache, ya sabéis de que va. Si no, es tan simple como que en la primera se generan los ficheros de configuración de los diferentes sitios que vayamos creando y en la segunda se enlazan simbólicamente para indicar a nginx que están activos. Tan fácil como eso. Pues bien, vamos a “sites-available” y creamos el fichero llamado “sphinx” en otro alarde de originalidad por nuestra parte. Y lo rellenamos así:

server {
    server_name sphinx.vuestrodominio.com;
    listen 80;

    # keep logs in these files (¿os acordáis del directorio de logs?
    access_log /var/log/nginx/sphinx.access.log;
    error_log /var/log/nginx/sphinx.error.log;

    location / {
        proxy_pass http://localhost:3312;
        proxy_redirect off;

        proxy_read_timeout 5m;

        # make sure these HTTP headers are set properly
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Con esto le diremos a la máquina de docker que cuando alguien venga preguntando a un CNAME llamado sphinx.vuestrodominio.com (que apunta a la máquina de docker y habéis creado como os de la gana, en mi caso con bind) por el puerto 3312 le tenemos que mandar a localhost:3312. Tan simple como eso. Es un proxy. Ya está. No tiene misterio. Fin.

Crearemos el enlace simbólico en la carpeta “sites-enabled” y recargaremos sphinx. Suponiendo que estamos en “sites-enabled

ln -s ../sites-available/sphinx

Ya tenemos sphinx en docker con un proxy nginx, amigas. Hasta la próxima. Besitos.

www.docker.io

Docker. Contenedores ligeros para levantar aplicaciones en segundos.

Hola chicas, hoy os voy a hablar de Docker. Aunque todavía no lo conozco mucho ya lo he usado para algún servicio pequeño. Pero para entender bien de que va, echadle un vistazo a estas diapositivas tan majas que se han currado los desarrolladores. (En general el sitio web de Docker es bastante bueno, tiene tutoriales interactivos y el tutorial normal, de toda la vida, tiene un auto test al final para comprobar que has entendido bien el concepto. Tiene un aire educativo muy, muy currado.)

Bien, ahora que habéis entendido un poco de que va os cuento un poco la idea que yo he cogido de todo esto.

Para un administrador de sistemas, en ocasiones, se presenta la necesidad de tener muchos servicios pequeños distintos, o el mismo pero repetido muchas veces. Por ejemplo en un entorno de pruebas, donde los developers necesitan cada uno su chiringuito y quieren ir probando cositas. Lo normal era levantarle una máquina virtual a cada uno con sus necesidades, o varias máquinas virtuales con diferentes versiones del mismo servicio, etc. El gasto de recursos de una máquina virtual, para según que cosas, era desmesurado. Te podías meter perfectamente en decenas de Gigas de disco y ocupar un entorno virtual casi al completo. Para este tipo de situaciones Docker puede resultar útil.

Por ejemplo, levantar un contenedor en Docker que simule un servicio de mysql en un Ubuntu server puede pasar de ocupar varios Gigas en una máquina virtual completa (que no vas a usar entera) a solamente 400 MEGAS en un contenedor de Docker. Porque Docker solamente te va a levantar lo estrictamente necesario (para que os hagáis una idea de lo que significa “lo necesario”, Docker no os va a instalar ni tan si quiera top, ni vim, ni vi ni leches… ¿para qué?). Además, si lo hacéis bien, tampoco vais a saber ni cómo se llama ese host, ni dónde está, ni nada de nada. De nuevo, ¿para qué?. Solo vais a saber que tenéis un contenedor con mysql dentro, con vuestra configuración personal, y punto pelota. Eso sí, vais a necesitar tener una forma de llegar a ella, puesto que Docker (si os leéis la documentación) dice claramente que los contenedores son para usar dentro de Docker. Que es mentira, pero verdad al mismo tiempo. Os montáis un proxy en Docker, por ejemplo Nginx. Y ya en el proxy le decís que cuando alguien venga a Docker preguntando por un puerto, vaya al localhost a ese puerto y engancháis ahí el contenedor para que sea visible desde fuera. Ya os pondré ejemplos de esto.

La gracia es que, cuando tengáis la recetita hecha (Dockerfile) y vuestros ficheros de configuración customizados, podréis lanzar un contenedor o setecientos en cuestión de segundos. Por ejemplo, levantar un contenedor de mysql sobre Debian tarda exactamente 30 segundos. Si vuestra conexión de internet es más lenta, tardará algo más (porque tardará más en bajarse los paquetes de mysql, básicamente). Pero la cuestión es que no tardará más de unas cuantas decenas de segundos. Y tendréis un contenedor que parecerá una Debian a todos los efectos, con vuestro mysql customizado (o vuestro cluster de mysql, que también se puede, amigos). De repente tenéis un racimo de mysql’s en lo que tardáis en ir a por un café y volver, y configurados como queréis.

¿Qué pasa si cambiais algo en el Dockerfile?, ¿volverá a descargarse todo de cero y montarlo limpio?

No, o no necesariamente. Dependerá de vosotros.

El Dockerfile es lineal, se ejecuta desde arriba hacia abajo por ese orden estricto (por eso tenéis que pensar bien los pasos al confeccionarlo, pero no pasa nada, es la forma natural humana de hacer las cosas. Una lista de pasos a seguir, básicamente, ordenados del primero al último). De repente, en el paso 5 se os ha olvidado añadir una instrucción. La añadís y volvéis a lanzar el contenedor. Él mirará qué pasos antes del 5 están hechos ya y en el orden correcto y no los repetirá. Empezará a partir del nuevo paso que, y aquí viene lo bonito de Docker, se comporta como Git. Sí, amigos. Se registran los cambios como los “commits” de Git y podéis resetear al gusto, volver atrás, etc. Como veis, Docker mantiene una filosofía de ahorrar tiempo en los procesos. ¿Que de repente has metido la pata?, no pasa nada, vuelves al punto previo antes de meterla y continúas. No tienes que empezar de cero. Y además se puede considerar esto auditoría (aunque anónima), y ver qué cambios se han hecho en un contenedor cuando las cosas no funcionan como deben.

Otra cosa que no os he contado sobre Docker que está muy bien es que Docker dispone de un repositorio de contenedores genéricos. Por ejemplo, si quieres una Ubuntu limpia, solo tienes que ejecutar:

docker pull ubuntu

Se descargará una lista de contenedores de Ubuntu por versiones, para que dispongáis de la versión que necesitéis en cada momento. Si ejecutáis el comando “docker images” podréis ver los contenedores disponibles:

root@docker:~$ docker images
REPOSITORY        TAG        IMAGE ID              CREATED       VIRTUAL SIZE
ubuntu                       13.10      9f676bd305a4     3 weeks ago     178 MB
ubuntu                       saucy      9f676bd305a4     3 weeks ago     178 MB
ubuntu                       13.04      eb601b8965b8    3 weeks ago     166.5 MB
ubuntu                       raring     eb601b8965b8    3 weeks ago     166.5 MB
ubuntu                       12.10       5ac751e8d623      3 weeks ago     161 MB
ubuntu                       quantal  5ac751e8d623      3 weeks ago     161 MB
ubuntu                       10.04      9cc9ea5ea540      3 weeks ago     180.8 MB
ubuntu                       lucid        9cc9ea5ea540      3 weeks ago     180.8 MB
ubuntu                       12.04      9cd978db300e    3 weeks ago     204.4 MB
ubuntu                       latest      9cd978db300e    3 weeks ago     204.4 MB
ubuntu                       precise   9cd978db300e    3 weeks ago     204.4 MB

Pero no solamente existe el repositorio oficial. En esta web tenéis un índice de contenedores Docker de todo tipo, hechos por usuarios o bien desde cero o bien usando los oficiales, etc.

Podéis jugar con el tutorial de la propia web, que está muy bien. En el próximo post hablaré de cómo configurar Nginx para acceder a los contenedores desde fuera.

Recursos: