Busindre

User Tools

Site Tools

Trace:
guia_rapida_de_dockerfile

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
guia_rapida_de_dockerfile [2021/02/21 01:37] – [Consejos / Buenas prácticas] busindreguia_rapida_de_dockerfile [2021/05/22 17:16] (current) – [Directivas de un fichero Dockerfile] busindre
Line 22: Line 22:
 <code bash>ARG DEBIAN_FRONTEND=noninteractive</code> <code bash>ARG DEBIAN_FRONTEND=noninteractive</code>
  
-Con ARG no deben usarse credenciales ni llaves criptográficas ya que estas estarían visibles al ejecutar "docker history". Las variables son únicamente validas en el momento de definirse. La última definición de la variable en el Dockerfile será la que puede ser sobrescrita desde la linea de comandos. Si se usan múltiples FROM (multi-stage builds), ARG debe estar también definida en cada stage. La [[#construccion_de_imagenes_docker_multietapas_multi-stage|construcción por etapas]] se explica más adelante.+Con ARG no deben usarse credenciales ni llaves criptográficas ya que estas estarían visibles al ejecutar "docker history". Las variables son únicamente validas en el momento de definirse. La última definición de la variable en el Dockerfile será la que puede ser sobrescrita desde la linea de comandos. Si se usan múltiples FROM (multi-stage builds), ARG debe estar también definida en cada stage. La [[#construccion_de_imagenes_docker_mediante_etapas_multi-stage|construcción por etapas]] se explica más adelante.
  
 Las variables definidas von ARG pueden ser sobrescritas siempre con ENV (se verá más adelante), haciendo inútil por tanto el uso de la sustitución por linea de comando de variables definidas mediante ARG. Ejemplo de sustitución de variable definida con ARG. Las variables definidas von ARG pueden ser sobrescritas siempre con ENV (se verá más adelante), haciendo inútil por tanto el uso de la sustitución por linea de comando de variables definidas mediante ARG. Ejemplo de sustitución de variable definida con ARG.
Line 40: Line 40:
 </code> </code>
  
-**EXPOSE** define el puerto expuesto por el comando ejecutado, es solo informativo para que el usuario que use la imagen utilice las opciones de mapeo de puertos que quiera. El mapeo, al igual que con los volúmenes de Docker, no pueden ser mapeados desde le fichero Dockerfile y se hace siempre desde la linea de comano u otras aplicaciones externas de gestión de contenedores.+**EXPOSE** define el puerto expuesto por el comando ejecutado, es solo informativo para que el usuario que use la imagen utilice las opciones de mapeo de puertos que quiera. El mapeo, al igual que con los volúmenes de Docker, no pueden ser mapeados desde le fichero Dockerfile y se hace siempre desde la linea de comando u otras aplicaciones externas de gestión de contenedores.
 <code bash>EXPOSE 80/tcp</code> <code bash>EXPOSE 80/tcp</code>
  
Line 112: Line 112:
  
  
-**ADD** permite copiar ficheros del host a la imagen y los contenedores dispondrán de esos ficheros, permite configurar propietario y grupo. Si se especifica el nombre de usuario, este debe estar en "/etc/passwd" y "/etc/group". Se debe de usar siempre rutas relativas al directorio donde creemos la imagen con el Dockerfile. Para el destino sí se deben usar rutas absolutas. Se pueden especificar varios origenes pero NO sin son remotos.+**ADD** permite copiar ficheros del host a la imagen y los contenedores dispondrán de esos ficheros, permite configurar propietario y grupo. Si se especifica el nombre de usuario, este debe estar en "/etc/passwd" y "/etc/group". Se debe de usar siempre rutas relativas al directorio donde creemos la imagen con el Dockerfile. Para el destino sí se deben usar rutas absolutas. Se pueden especificar varios orígenes pero NO sin son remotos.
  
 La diferencia con COPY es que ADD descomprime automáticamente ficheros comprimidos y permite descargar de internet archivos. Los permisos predeterminados son 600 para los ficheros obtenidos remotamente con ADD. La diferencia con COPY es que ADD descomprime automáticamente ficheros comprimidos y permite descargar de internet archivos. Los permisos predeterminados son 600 para los ficheros obtenidos remotamente con ADD.
-<code bash>ADD --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codicoalpine+<code bash>ADD --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codigoalpine
 # ADD decomprimirá el tar.gz en /opt/codigoalpine, si no se desea la descompresión automática se debe usar COPY. # ADD decomprimirá el tar.gz en /opt/codigoalpine, si no se desea la descompresión automática se debe usar COPY.
 # La aplicación de permisos en este caso no se aplican a los ficheros descomprimidos.</code> # La aplicación de permisos en este caso no se aplican a los ficheros descomprimidos.</code>
  
-ADD no es compatible con procesos de autenticación cuando usamos origenesremotos. En esos casos se puede usar RUN von wget o cualquier otro software que permite descargar mediante autenticación.+ADD no es compatible con procesos de autenticación cuando usamos orígenes remotos. En esos casos se puede usar RUN von wget o cualquier otro software que permite descargar mediante autenticación.
 <code bash>ADD https://freetsa.org/files/cacert.pem /opt/</code> <code bash>ADD https://freetsa.org/files/cacert.pem /opt/</code>
  
 **COPY** no permite usar ficheros remotos y no descomprime los ficheros de manera automáticamente como si hace ADD. **COPY** no permite usar ficheros remotos y no descomprime los ficheros de manera automáticamente como si hace ADD.
-<code bash>COPY --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codicoalpine +<code bash>COPY --chown=XXXX:XXXX "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/codigoalpine 
-# El propietario de /opt/codicoalpine/alpine-minirootfs-3.13.0-x86_64.tar.gz sera XXXX.</code>+# El propietario de /opt/codigoalpine/alpine-minirootfs-3.13.0-x86_64.tar.gz sera XXXX.</code>
 La ruta origen es relativa siempre al directorio de trabajo donde estemos (PWD).  La ruta origen es relativa siempre al directorio de trabajo donde estemos (PWD). 
-<code>COPY directorio_local/ /opt/codicoalpine/</code>+<code>COPY directorio_local/ /opt/codigoalpine/</code>
  
 NOTA: Si en el destino se usa una ruta relativa, será en base al WORKDIR usado por la imagen. Si se copia un directorio del anfitrión (host) los permisos son también copiados (no así el propietario). NOTA: Si en el destino se usa una ruta relativa, será en base al WORKDIR usado por la imagen. Si se copia un directorio del anfitrión (host) los permisos son también copiados (no así el propietario).
  
-**VOLUME** permite crear volumenes al arrancar el contenedor. En este ejenplo se crearán dos volúmenes para esos directorios del contenedor (Para montar directorios del host se usa "-v" en linea de comandos, no es posible definir eso desde el Dockerfile). Esto se debe a que podría provocar problemas al cambiar de host si este no tiene la misma carpeta.+**VOLUME** permite crear volúmenes al arrancar el contenedor. En este ejemplo se crearán dos volúmenes para esos directorios del contenedor (Para montar directorios del host se usa "-v" en linea de comandos, no es posible definir eso desde el Dockerfile). Esto se debe a que podría provocar problemas al cambiar de host si este no tiene la misma carpeta.
 <code bash>VOLUME /opt/volumen1 /opt/volumen2 <code bash>VOLUME /opt/volumen1 /opt/volumen2
 COPY "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/volumen2/</code> COPY "alpine-minirootfs-3.13.0-x86_64.tar.gz" /opt/volumen2/</code>
  
 +Si se quiere controlar el montaje de volúmenes con un determinado usuario que no sea root, este puede ser primeramente definido en el fichero Dockerfile. Una vez se monte el volumen, heredará los permisos y propietario definidos previamente en la imagen. En el ejemplo se crea una imagen docker llamada alpine_volumen que usará un usuario no privilegiado "testuser".
 +
 +<code bash>ARG USR=testuser
 +FROM alpine
 +RUN addgroup -S $USR && adduser -S $USR -G $USR           # Se crea el usuario y el grupo para luego aplicarlo al punto de montaje del volumen.
 +RUN mkdir /DIR_testuser && chown $USR:$USR /DIR_testuser  # Se crea el directorio donde será montado el volumen y su propietario
 +VOLUME /DIR_testuser                                      # Se hace una referencia al volumen que será montado desde linea de comando o docker-compose.
 +USER $USR                                                 # Usuario del proceso.</code>
 +
 +Linea de comando (se creará el volumen XXXX si no existe).
 +<code bash>docker run --rm -it -v XXXX:/DIR_testuser alpine_volumen</code>
 +
 +Montar el volumen desde docker-compose, el volumen se crea automáticamente si no existe. El contenedor creado solo ejecutará una shell.
 +<code>version: "3"
 +services:
 +  web:
 +    image: alpine_volumen  # Imagen creada a partir del Dockerfile mostrado anteriormente.
 +    stdin_open: true # docker run -i
 +    tty: true        # docker run -t
 +    command: /bin/sh
 +    volumes:
 +      - XXXX:/DIR_testuser  # El volumen será montado como el usuario testuser.
 +volumes:
 +    XXXX:</code>
 +NOTA: El traspaso automático de la configuración de usuario y permisos al montar el volumen sucede únicamente, cuando el volumen no ha sido usado previamente por otro contenedor. Esto es solo aplicable a volúmenes, NO a directorios (bind mounts) del host. Para cpntrolar los permisos de "bind mounts" con aplicaciones como docker-compose, habría que usar en ENTRYPOINT comandos chmod / chown para adaptar los permisos a las necesidades o bien adaptarlos en el anfitrión manualmente ([[permisos_y_propietarios_en_volumenes_con_docker-compose|leer]]).
  
 **WORKDIR** configura el directorio de trabajo, sencillamente es la carpeta donde ejecutaran RUN, CMD, ENTRYPOINT, COPY y ADD sus instrucciones. Si no existe el directorio es creado automáticamente. Puede usarse varias veces y puede ampliarse múltiples veces si la primera inicialización usa una ruta directa y las siguientes relativas. También puede interactuar con  ENV.  Los WORKDIR no crean nuevas capas a la hora de crear imágenes. **WORKDIR** configura el directorio de trabajo, sencillamente es la carpeta donde ejecutaran RUN, CMD, ENTRYPOINT, COPY y ADD sus instrucciones. Si no existe el directorio es creado automáticamente. Puede usarse varias veces y puede ampliarse múltiples veces si la primera inicialización usa una ruta directa y las siguientes relativas. También puede interactuar con  ENV.  Los WORKDIR no crean nuevas capas a la hora de crear imágenes.
Line 169: Line 194:
     --retries=N</code>     --retries=N</code>
  
-===== Construcción de imágenes Docker mediante eatapas (multi-stage) =====+===== Construcción de imágenes Docker mediante etapas (multi-stage) =====
  
-Para poder disponer de imágenes pequeñas se necesita que estas tengan el mínimo indispensables de ficheros para correr la aplicación deseada. Para ello en los Dockerfiles es posible utilizar y trabajar sobre varias imágenes base para que al final, una última imagen pueda copiar los ficheros ya construidos en esas etapas de construcción anteriores (imágenes temporales). Esas imágenes intermedias (etapas de construcción) se reerencian mediante la instrucción **AS** y desaparecen al terminar el proceso de construcción.+Para poder disponer de imágenes pequeñas se necesita que estas tengan el mínimo indispensables de ficheros para correr la aplicación deseada. Para ello en los Dockerfiles es posible utilizar y trabajar sobre varias imágenes base para que al final, una última imagen pueda copiar los ficheros ya construidos en esas etapas de construcción anteriores (imágenes temporales). Esas imágenes intermedias (etapas de construcción) se reerencian mediante la instrucción **AS** y desaparecen al terminar el proceso de construcción.  
 + 
 +Otro uso que se le suele dar a los Dockerfile con multi-stage es el de definir diferentes construcciones de imágenes en un solo Dockerfile y usar "%%--%%target" en el proceso de creación para especificar una contrucción en concreto. Normalmente se usar para tener varias versiones de una misma imagen, pero variando la cantidad de cosas instaladas en ellas. Por ejemplo la primera construcción de imagen podría ser la versión liviana, luego una normal basada en la anterior y la completa (siendo esta ultima la suma de las otras dos).
  
 El proceso es simple, cada etapa empieza con FROM, se asigna mediante AS un nombre que luego es referenciado mediante **COPY %%--%%from** en la imagen final. "COPY %%--%%from=0" Permite referenciar la etapa anterior y no necesita definir nombres de etapas mediante AS. El proceso es simple, cada etapa empieza con FROM, se asigna mediante AS un nombre que luego es referenciado mediante **COPY %%--%%from** en la imagen final. "COPY %%--%%from=0" Permite referenciar la etapa anterior y no necesita definir nombres de etapas mediante AS.
  
-En este ejemplo se crea una imagen a partir de apine:latest, la cual copia sin sentido contenido de dos distros diferentes. Estas son debian:latest (referenciada como "busi") y "nginx:latest" (Al no estar definidia definida en el Dockerfile, usará Dockerhub o cualquier otro repositorio remoto configurado).+En este ejemplo se crea una imagen a partir de apine:latest, la cual copia sin sentido contenido de dos distros diferentes. Estas son debian:latest (referenciada como "busi") y "nginx:latest" (Al no estar definida definida en el Dockerfile, usará Dockerhub o cualquier otro repositorio remoto configurado).
  
 <code bash> <code bash>
Line 190: Line 217:
  
 <code bash>docker build -t alpine_multistage .</code> <code bash>docker build -t alpine_multistage .</code>
-Cuando se tiene más de una etapa definida con AS, es posible parar a partir de una determinada etapa e ignorar el resto. Para ello se debe suar "%%--%% docker build --target" y referenciar qué etapa.+Cuando se tiene más de una etapa definida con AS, es posible parar a partir de una determinada etapa e ignorar el resto. Para ello se debe usar "%%--%% docker build --target" y referenciar qué etapa.
 <code bash>docker build --target builder -t nombre_imagen .</code> <code bash>docker build --target builder -t nombre_imagen .</code>
  
Line 230: Line 257:
  
 Si se puede evitar el uso de root (usuario predeterminado) mejor. Si se puede evitar el uso de root (usuario predeterminado) mejor.
 +
 +Utilizar algún sistema de escaneo de vulnerabilidades por ejemplo [[https://github.com/quay/clair|Clair]] o [[https://github.com/docker/docker-bench-security|Docker Bech Security]] pero cada día salen nuevas herramientas / Plugins de Frameworks para dicha finalidad y otras son consideradas "deprecated".
 +
 +Nunca debe cambiarse el propietario del socket de docker. Si un usuario no root necesita hacer uso de comandos docker, simplemente se agrega el grupo "docker" al usuario pertinente.
 +
 +<code bash>usermod -aG docker ${USER}</code>
 +
 +Evitar la activación del modo privilegiado de docker (por defecto desactivado). De necesitarlo deben usarse imágenes oficiales en la medida de lo posible. El uso de la opción "no-new-privileges:true" en estos casos puede ser de interés.
 +
 +Para tareas de autenticación, autorización, cifrado,etc es recomendable usar "secretos". Esto permite gestionar ese tipo de información que se necesita en tiempo de ejecución pero que no se quiere almacenar en la imagen de Docker o en el repositorio de código fuente.
  
 **Crear una imagen con nombre personalizado**. **Crear una imagen con nombre personalizado**.
 <code bash> docker build -t alpine_busi .</code> <code bash> docker build -t alpine_busi .</code>
guia_rapida_de_dockerfile.1613867873.txt.gz · Last modified: 2021/02/21 01:37 by busindre