W10 - Accediendo a la docker-machine (¿?)

Según nos habían dicho, en W10 docker era nativo, a la manera de linux.

Pero no, al final la docker-machine de toda la vida en w7 no se llama docker-machine en W10, pero no deja de ser una máquina virtual.

En W10 usa Hyper-V, esa es la diferencia. En W7 se usaba VirtualBox como driver por defecto cuando creábamos dicha docker-machine. En W10 parece que el hipervisor por defecto (y único diría yo) es Hyper-V.

Aquí tenemos nuestro docker "nativo":

Antes, para acceder a la máquina virtual docker simplemente hacíamos

docker-machine ssh nombre (o bien vía VirtualBox)

 En la actual no parece tan sencillo. Veamos un posible procedimiento (puede haber otros)

Lancemos los siguientes comandos:

docker run --privileged -it -v /var/run/docker.sock:/var/run/docker.sock docker

Aquí ya nos encontramos en un contenedor docker, con root (--privileged), con docker instalado ( con solo ver el nombre de la imagen....). No obstante lo dicho, funciona igualmente sin elevación de privilegios (sin el --privileged). Si queremos obtener datos internos podemos lanzar algunos comandos dentro:

Por consiguiente podemos levantar de nuevo un contenedor (dentro del contenedor, la locura, vaya!!!) a partir del siguiente comando:

docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh

Estamos incumpliendo varias normas de seguridad, como usar la red "host", que nos da acceso total  a los recursos de la máquina, pero recordad que estamos en un contenedor.

Ahora si que estamos en la máquina virtual visible desde Hyper-V. Esta es nuestra docker-machine oculta tras el supuesto docker nativo de W10.



Y diréis, ¿y esto qué me aporta? Bueno, básicamente información, conocimiento, que ya de por sí mola!!!

Pero veamos, pregunta, cuando en, por ejemplo, un docker-compose.yml creamos un volumen con el formato

volumes:
      - oracle19_data:/opt/oracle/oradata

volumes:
  oracle19_data:
    driver: local

Tal como hicimos en la anterior entrada "Oracle 19 - docker", ¿dónde se están persistiendo los datos del contenedor (/opt/oracle/oradata)?

Ha!!!!

Pues eso, se están guardando en la MV docker. ¿Y dónde podemos encontrarlos?
Veamos. Primero, fuera, en una consola cmd o PowerShell nueva veamos ese volumen:

docker volume ls
DRIVER              VOLUME NAME
...
local                     oracle_oracle19_data

En el nombre del volumen aparece un prefijo "oracle" añadido por ser el nombre del directorio donde tengo el docker-compose.yml. Veamos la ruta del volumen dentro de la MV docker.

Claro, si en nuestro W10 quisiesemos encontrar esa ruta veríamos que nos sería imposible. Esa ruta no es de nuestro W10.

Ahora es cuando se enlaza todo, si volvemos al último contenedor levantado más arriba y cambiamos el directorio root a /host

chroot /host

 y hacemos un ls, bingo!!!

 

que es justo lo que hay en el mismo contenedor Oracle levantado. Para acabar de validarlo (para los que no se fien) entremos al contenedor Oracle

docker ps
CONTAINER ID      IMAGE   ......
c86159e64799        oracle/database:19.3.0-ee     .......

y hagamos un ls el directorio persistido según la configuración del docker-compose.yml:

Por tanto, de alguna forma es interesante/importante poder verificar o conocer estos detalles, para un conocimiento y control más profundo de docker sobre Windows.

Oracle 19 - docker

Os dejo la forma de crear una BDD Oracle 19.3.0 en local con docker.
Lo primero es descargarse de github todos los ficheros necesarios:

• git init
• git remote add origin https://github.com/oracle/docker-images.git
• git fetch origin
• git checkout origin/master -- OracleDatabase/SingleInstance

A continuación nos descargamos el zip con el binario de la versión que queramos, en nuestro caso la 19.3.0 Una vez descargado (alrededor de 3Gb) movemos el zip a la carpeta dockerfiles/versión (en nuestro caso a dockerfiles/19.3.0).

Nos movemos a la carpeta "dockerfiles" y lanzamos (en W10 habiendo habilitado WSL hacedlo con un debian o ubuntu - la carpeta /mnt mapea vuestro W10, pudiendo acceder a la unidad C:)

• ./buildDockerImage.sh -e -i -v 19.3.0

Es posible que debamos pasarle el dos2unix de forma recursiva desde la carpeta actual.
Esperamos a que acabe, tras lo cual tendremos la imagen generada "oracle/database:19.3.0-ee".
Por último, creamos un "docker-compose.yml" para facilitar el run de la imagen

version: '3.5'
services:
  oracle19:
    container_name: oracle19
    image: oracle/database:19.3.0-ee
    ports:
      - "1521:1521"
      - "5500:5500"
    environment:
      ORACLE_SID: docker19sid
      ORACLE_PDB: docker19pdb
      ORACLE_PWD: dockerpass
      ORACLE_CHARACTERSET: AL32UTF8
    volumes:
      - oracle19_data:/opt/oracle/oradata

volumes:
  oracle19_data:
    driver: local

Ya sólo quedará lanzar el comando "docker-compose up -d" desde la ubicación del yaml anterior. El primer lanzamiento tarda un poco, paciencia. Si véis que le cuesta mucho o véis en el log del contenedor warnings por escasez de memoria, aumentar a 6 Gb la memoria asignada a Docker (en W10 acceded al dasboard, opción Resources)

Como consejo, si creáis un Tablespace, hacedlo indicando la ruta del datafile explicitamente, y dentro del directorio persistido vía volumen. Si no indicáis ruta lo crea en una por defecto que cae fuera de dicho volumen (¿?). En el siguiente run de la imagen obtendréis un catastrófico error al no encontrar dicho datafile no pudiendo arrancar la instancia.

Por ejemplo:

• CREATE TABLESPACE T_MYTABLESPACE DATAFILE '/opt/oracle/oradata/datafiles/T_MYTABLESPACE.dbf' SIZE 1000M AUTOEXTEND ON ONLINE;
• CREATE USER MYUSER IDENTIFIED BY "MYUSER" DEFAULT TABLESPACE T_MYTABLESPACE TEMPORARY TABLESPACE temp;
• GRANT ALL PRIVILEGES TO "MYUSER";

Y listos!!!