Los ficheros de este proyecto son:
./
|-- nutch/
| |--nutch-site.xml
| |--regex-urlfilter.txt
| |--seed.txt
|-- solr/
| |--managed-schema
| |--solrconfig.xml
|-- docker-compose.yml
Es el fichero que configura el despliegue de los dos servicios: nutch
y solr
.
solr:
image: solr:6.6.0@sha256:e8f279c9ab594525ab0344c0cb44d5f2a2e308bec3e14a11648095af15cad90b
container_name: solr
volumes:
- ./solr/managed-schema:/opt/solr/server/solr/configsets/basic_configs/conf/managed-schema:ro
- ./solr/solrconfig.xml:/opt/solr/server/solr/configsets/basic_configs/conf/solrconfig:ro
command: solr-create -c nutch
ports:
- 8983:8983
-
image: Define la imagen base que se va a descargar y usar en ese servicio. Además se establece el
digest
, que garantiza que la versión descargada será la misma siempre. -
container_name: Fija el nombre del contenedor. Esto es importante para el routing interno ya que los contenedores dentro de una misma red se encuentran entre sí mediante su
container_name
gracias a un servicio interno dedns
de Docker. -
volumes: Define los puntos de montaje de
volúmenes
ybindings
. En este caso, sólo se han utilizado bindings para simplificar el fichero. Los bindings emparejan un directorio o fichero local delhost
y uno delcontainer
bajo unos permisospermissions
mediante la sintaxishost_dir:container_dir[:permissions]
. -
command: es el comando de entrada que se ejecutará. En este caso, es un parámetro que se pasa a otro script. más info sobre esto
-
port: Hace un
binding
de puertos delhost
a puertos delcontainer
mediante la sintaxyshost_port:container_port
El puerto no es necesario para comunicación, pero sí para acceder a la interfaz web http://localhost:8983/solr/
La clave del funcionamiento de éste contenedor radica en el binding
de los ficheros de configuración al lugar donde está la plantilla de configuración por defecto. Esto hace que al crearse el core
, se utilicen estos ficheros sumados al resto de ficheros por defecto.
nutch:
image: apache/nutch:release-1.13@sha256:270a933f2311f7f8b4d477139d72fcb95eec284903642c6515c279aafaa09e66
container_name: nutch
environment:
JAVA_HOME: /usr/lib/jvm/java-7-oracle/jre/
volumes:
- ./nutch/nutch-site.xml:/root/nutch/conf/nutch-site.xml:ro
- ./nutch/regex-urlfilter.txt:/root/nutch/conf/regex-urlfilter.txt:ro
- ./nutch/seed.txt:/root/nutch/urls/seed.txt:ro
#IMPORTANTE: Existen dos modos de ejecución: `interactivo` (tty) o `servicio` (command). Mantener uno de los dos comentado
tty: true
# command: /root/nutch/bin/crawl -i -D solr.server.url=http://solr:8983/solr/nutch /root/nutch/urls/seed.txt TestCrawl 2 #Ejecuta el crawling automáticamente
depends_on:
- solr
-
environment: Permite definir variables de entorno para el contenedor. Es muy últil en imágenes pensadas para explotar ésta funcionalidad. No es este el caso, ya que el uso de la misma se debe a una mala contrucción de la imagen, que hace imposible ejecutar el contenedor como un servicio.
-
depends_on: Define una relación de dependencia entre dos contenedores. Esto implica que hasta que un contenedor no ha arrancado correctamente, el otro no se inicia. No sólo sirve para esperar a otro contenedor, también permite propagar el arranque de los contenedores de los que uno depende cuando se hacen arranques individuales.
-
tty: Un contenedor de Docker está pensado para ejecutar un servicio y detenerse al finalizar el mismo. En ocasiones, el funcionamiento deseado es otro, y en esos casos hay que recurrir a algún
hack
o truco para adaptarlo a nuestras necesidades. En este caso,tty
hace que una vez haya terminado su proceso de arranque (o cuando el proceso de arranque no existe, como es el caso), el contenedor no se detenga, sino que siga en ejecución simulando tener una terminal abierta. Esto nos permitirá probar varios comandos del crawler sobre el mismo contenedor así como ejecutar cualquier otro comando dentro de él. -
command: Si por el contrario se quiere utilizar el contenedor como un servicio (tal y como Docker está pensado), este comando ejecutará el proceso de
crawling
definido en el enunciado de forma automática.
La ejecución canónica de un Docker Compose es docker-compose up -d
. No obstante, es una buena práctica acostumbrarse a desplegar sólo el servicio deseado (y sus dependencias). Por ello el comando aconsejado es:
docker-compose up -d nutch
Esto ejecutará ambos contenedores ya que, debido al parámetro depends_on
, nutch
no puede iniciarse sin solr
.
Independientemente del modo en el que lo estemos lanzamos, el comando docker-compose
terminará cuando ambos contenedores estén en marcha.
Si se está ejecutando el servicio en modo interactivo (con la línea de commad
del fichero docker-compose.yml
comentada), la forma de acceder a una consola dentro del contenedor es mediante:
docker exec \
-it \
nutch \
bash
- docker exec: Comando que ejecuta una terminal dentro de un contenedor en ejecución ya existente.
- -it: Activa el modo interactivo y vincula la consola actual a la nueva dentro del contenedor.
- nutch: Nombre del contenedor al que nos conectamos.
- bash: Comando que se ejecuta dentro de esa consola.
Otra opción es utilizar repetidamente docker exec -it nutch <COMANDO DESEADO>
lo que abrirá una temrinal con el comando ejecutado y saldrá de ella cuando el comando acabe.
En el modo servicio no veremos nada ya que ninguna de las dos temrinales de los contenedores está vinculada a la nuestra.
Una forma sencilla de consultar el estado de los procesos es mediante docker ps
que listará los contenedores activos y mediante docker logs nutch
o locker logs solr
que escribirá por pantalla lo último escrito por cada contenedor. Nota: Este último comando tan sólo hace un cat
. No muestra modificaciones en tiempo real.
Otra forma de vincular ambas terminales, de modo que veamos los cambios en tiempo real, es mediante docker attach nutch
o docker attach solr
. El punto negativo de este método es que una vez vinculadas, la única forma de desvincularlas es matando el proceso con Crtl-C
, lo que detendrá además el contenedor.
La mejor forma de consultar los resultados es accediendo al portal web de Solr en:
Existen dos formas de detener el sistema:
-
Mediante
docker-compose stop
: Detiene los contenedores, pero mantienen los cambios hechos y sus datos almacenados. La próxima vez que arranque el servicio conup -d
los contenedores se reiniciarán con normalidad. -
Mediante
docker-compose down
: Detiene los contenedores, los borra y borra toda la información almacenada en ellos así como las redes virtuales creadas para conectarlos. La próxima vez que arranque el servicio conup -d
los contenedores volverán a ser creados desde cero (fresh start). Nota: Este es el paso recomendado cuando se quiere garantizar que todo el proceso es automático y no hay dependencias extra como configuraciones manuales hechas sobre los contenedores.