Aprovisionar o instalar docker en una máquina remota utilizando docker-machine

Docker Logo

Para la elaboración del artículo hemos utilizado docker 1.12 y dos equipos ubuntu 16.04.1 LTS virtualizados con Virtualbox

Guía rápida de aprovisionamiento de una máquina remota utilizando docker-machine y el driver genérico. Se trata por tanto de instalar de docker forma remota desde un equipo local.

Para el artículo vamos a suponer que

  • la máquina remota se llama remotehost
  • la cuenta del usuario del equipo remoto es udocker
  • la maquina local donde ejecutamos docker-machine es sourcehost

Sigue leyendo

Anuncios

Docker cookbook. Subir una imagen a nuestro Docker Registry privado

Docker Logo

La versión de docker utilizada para ejecutar los comandos de este artículo ha sido docker 1.12.0 en un sistema Ubuntu 16.04.1 LTS

Cuando empezamos a trabajar con Docker una de las primeras cosas que utilizaremos es el Docker Resgitry proporcionado por la gente de Docker y publicado en Docker Hub.

Como sabemos es la imagen utilizada para crear un contenedor donde subiremos nuestras imágenes de nuestros proyectos de forma privada. Eso si, con algunas limitaciones en cuanto a seguridad etc.

Como toda imagen subida a Docker Hub podemos disponer de ella y arrancar nuestro contenedor con un simple comando:

$ docker run -d -p 5000:5000 --name registry registry:2

Los pasos a seguir una vez tenemos nuestra imagen son muy sencillos. Basta con etiquetarla indicando el host del Docker Registry donde tiene que subir:

$ docker tag 5f7ca7e96e33 my-registry:5000/my-image:0.0.1-SNAPSHOT
$ docker push my-registry:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
Get https://my-registry.com:5000/v1/_ping:http: server gave HTTP response to HTTPS client

En este momento es cuando nos encontramos con la primera limitación de este Registry. No soporta la seguridad por SSL, y por lo tanto debemos decir a nuestro docker daemon que debe poder comunicarse con my-registry.com de forma no segura.

La configuración que debemos hacer es muy sencilla. Indicar el host de nuestro Registry, reiniciar el daemon y volver a subir la imagen

$ echo '{ "insecure-registries":["my-registry.com:5000"] }' > /etc/docker/daemon.json
$ sudo systemctl restart docker
$ docker push  my-registry.com:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
0d84ae38f138: Pushed
c18156f94ccc: Pushed
...
...
0.0.1-SNAPSHOT: digest: sha256:fceb6ceb9277761036ec670c1e23f30a3667441f98c54b4253c94737abb0b418 size: 4482

Montar un entorno con Zookeeper, Kafka y Yahoo Kafka Manager utilizando Docker

Docker Logo

Construir la imagen de “kafka manager docker” para kafka 0.9

Los pasos son los siguiente:

Clonar el repositorio

git clone https://github.com/DockerKafka/kafka-manager-docker.git

Crear un nuevo branch a partir del tag 1.2.7

git checkout -b 1.2.7.mylocal 1.2.7

Modificar el Dockerfile para utilizar los fuentes de Yahoo Kafka Manager con soporte a Kafka 0.9

Editamos el fichero Dockerfile y modificamos

KM_VERSION=1.2.7

por

KM_VERSION=1.3.1.6

Construimos la imagen

docker build -t my-kafka-manager .

Levantar Zookeeper, Kafka y Kafka Manager

docker run -d --name kafkadocker_zookeeper_1  dockerkafka/zookeeper
docker run -d --name kafkadocker_kafka_1 --link kafkadocker_zookeeper_1:zookeeper dockerkafka/kafka
docker run -it --rm --link kafkadocker_zookeeper_1:zookeeper --link kafkadocker_kafka_1:kafka -p 9000:9000 -e ZK_HOSTS=zookeeper:2181 my-kafka-manager

Acceder a Kafka Manager y dar de alta los cluster que queremos gestionar

Accedemos a la interface web en http://host:9000 y damos de alta el cluster que queremos gestionar.

Para ello debemos saber el host y puerto del Zookeeper que estamso utilizando. Si nos hemos fijado en los pasos anteriores el zookeeper es:

Host:puerto = zookeeper:2181

Yahoo Kafka Manager

Urls

docker Cookbook, la resolución de nombres de dominio DNS en la red por defecto bridge

Docker Logo

Como ya sabemos en el fichero /etc/resolv.conf de nuestra máquina tenemos la configuración de los DNS de nuestra organización o empresa, y es lo que nos permite poder resolver los nombres de dominio y máquinas tanto de internet como de nuestra intranet.

Cuando trabajamos con contenedores docker se encarga de configurar estos ficheros en nuestros contenedores.

Comportamiento por defecto

Lo que hace por defecto si no le decimos nada es copiar el fichero /etc/resolv.conf de nuestra máquina en el nuevo contenedor, pero filtrando o eliminando todas las IPs locales.

Una vez realizado el filtrado de todas las IPs locales (es decir, ips como 127.0.1.1), si no queda ninguna entrada de un DNS válido, crea el fichero /etc/resolv.conf con las IPs de los DNS públicos de Google.

Por lo tanto seremos capaces de resolver cualquier nombre de dominio de internet, pero nunca seremos capaces de resolver los nombres de dominio de las máquinas de nuestra intranet.

Así pues si nos encontramos en esta situación, para poder resolver los nombres de dominio o nombres de máquinas de nuestra intranet dentro de un contenedor de docker debemos revisar que exista una IP válida de un DNS de nuestra organización.

Por ejemplo, si tenemos el siguiente /etc/resolv.conf

Sigue leyendo

docker Cookbook, borrar todas las imagenes en estado dangling

Docker Logo

Cuando utilizamos docker terminaremos viendo imágenes que no están siendo utilizadas y que terminan ocupando espacio.

Al principio no tendremos este tipo de imágenes, pero según vayamos utilizando imágenes de docker o creando imágenes propias terminaremos viéndolas. Estas imágenes las identificaremos por el nombre del repositorio y del tag, que serán

<none>:<none>

y que las veremos lanzando el comando docker images.

$ docker images
REPOSITORY                                         TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
...
<none>                                             <none>              47a4e50d9b35        18 hours ago        669.6 MB
<none>                                             <none>              8e2393b52fd9        18 hours ago        669.6 MB
<none>                                             <none>              8fb173d5c23c        18 hours ago        669.6 MB
<none>                                             <none>              19cb9c21f160        21 hours ago        669.5 MB
<none>                                             <none>              9cf1c0068503        21 hours ago        669.5 MB
<none>                                             <none>              27c02a9fda80        21 hours ago        669.5 MB
<none>                                             <none>              b2d384eb6f23        6 days ago          669.5 MB
<none>                                             <none>              ae0dbc713400        6 days ago          669.5 MB
...

Como vemos por el nombre del repository y del tag tenemos imágenes en estado dangling.

Listado de todas la imágenes en estado dangling

Si queremos ver solamente las imágenes en estado danglin lo podemos hacer con un simple comando.

$ docker images -f "dangling=true"

Borrar todas las imágenes en estado dangling

Y para liberar y recuperar el espacio ocupado por esta imágenes lo haremos igualmente con un comando de docker.

$ docker rmi $(docker images -f "dangling=true" -q)

Referencia

Este artículo lo hemos basado en What are Docker : images?

Como configurar nginx como proxy reverso en un contenedor de docker

Docker Logo

Vamos a configurar un contenedor de docker basado en nginx para que funcione como un proxy reverso contra un contenedor de Kibana y otro de elasticsearch.

Para facilitar la creación y gestión de todos los contenedores vamos a utilizar docker compose.

El acceso a Kibana y a elasticsearch desde el host se realizará siempre desde el contenedor de nginx.

La topología de este sistema es:

  • el host accede a nginx
  • nginx accede a kibana y a elasticseach
  • kibana accede a elasticsearch

Desde nuestro host solo tendremos acceso al contenedor de nginx, ya que el resto de contenedores no van a tener expuestos los puertos de cada servicio.

Sigue leyendo

Utilizar docker compose para gestionar y administrar varios contenedores

Docker Logo

En el anterior artículo Preparar un entorno de desarrollo basado docker con elasticseach, kibana y sense vimos como preparar dos contenedores docker, uno basado en elasticsearch y otro basado en kibana.

Lo que vamos a ver en este pequeño artículo es una guía de como preparar los mismos contenedores pero utilizando docker compose. Como sabemos docker compose es una herramienta de docker con la que nos permiten manejar varios contenedores con un solo comando.

Utilizando docker compose nos evitamos la tediosa tarea de tener que crear, arrancar, parar y borrar cada uno de los contenedores por separado utilizados en nuestro proyecto.

docker-compose.yml

Es el fichero donde le decimos a docker compose los contenedores que tiene que gestionar y administrar.

Vamos a crear nuestro entorno de desarrollo basado en un contenedor de elasticsearch y otro de kibana.

El contenedor de Kibana

  • se encontrará lincado al contenedor de elasticsearch
  • dejaremos su puerto disponible en el host, en el primer puerto libre que tenga la máquina

El contenedor de elasticsearch

  • dejaremos sus puertos disponible en el host, en el primer puerto libre que tenga la máquina, por si fuera necesario acceder directamente por el API Rest a elasticsearch.

El primer paso será crear un directorio y dentro de él creamos el fichero docker-compose.yml.

$ mkdir test-elasticsearch-kibana
$ cd test-elasticsearch-kibana
$ touch docker-compose.yml

Y editamos el fichero docker-compose-yml

elasticsearch:
  image: elasticsearch:2.1.1
  container_name: test-elasticsearch-2.1.1
  ports:
    - "9200"
    - "9300"
  expose:
    - "9200"
    - "9300"

kibana:
  image: kibana:4.3.1
  container_name: test-kibana-4.3.1
  links:
    - elasticsearch
  ports:
    - "5601"

donde,

  • image. Indicamos la imagen a partir de la cual queremos crear el contenedor.
  • container_name: El nombre del contenedor. Es opcional y si no le ponemos uno docker compose le asignará un nombre por defecto.
  • ports: Los puertos que queremos tener disponible en la maquina host.
  • expose: Los puertos que deben ser expuestos para otros contenedores (links).
  • links: Creamos un link con el contenedor de elasticsearch desde el contenedor de kibana.

Operaciones principales

Una vez tenemos el fichero creado, procederemos como siempre.

Arrancamos los dos contenedores

$ docker-compose up -d

Paramos los dos contenedores

$ docker-compose stop

Borramos los dos contenedores

$ docker-compose rm

Ver los puertos mapeados de uno de los contenedores

$ docker-compose port elasticsearch 9200

Instalar el plugin sense en Kibana

docker exec test-kibana-4.3.1 /opt/kibana/bin/kibana plugin --install elastic/sense

etc