En otra entrada del blog se explicó, de modo general, qué era Docker, un programa de virtualización muy ligero que se maneja sólo con comandos.
En esta entrada se hablará de un excelente método de instalación de imágenes en Docker: el archivo de Docker ("Dockerfile", en inglés).
Básicamente, se trata de un archivo de configuración que se utiliza para crear imágenes donde el usuario que lo crea indica qué es lo que desea que tenga la imagen, y los distintos comandos para instalar las herramientas, que deben ir junto al archivo (correspondiendo con la ruta especificada en este) cuando sea necesario.
El archivo en sí es un archivo de texto plano sin extensión alguna, pero que siempre debe llamarse "Dockerfile", escrito con un código muy similar al JavaScript Object Notation (JSON; código fuente que describe los datos con una sintaxis dedicada que se usa para identificar y gestionar estos). Para revisarlo y/o editarlo correctamente, es conveniente utilizar un programa de edición de textos compatible con el formato de código antes mencionado (Notepad++, Sublime Text, o Brackets, por ejemplo).
La sintaxis básica de un archivo de Docker es:
# Comentarios
INSTRUCCIÓN argumentos
Aunque la instrucción no distingue entre mayúsculas y minúsculas, es conveniente escribirla en mayúsculas para distinguirla de los argumentos.
Docker ejecuta instrucciones de un archivo de Docker en orden. El archivo de Docker debe comenzar con una instrucción "FROM", que especifica la imagen base de la que está construyendo, y que sólo puede estar precedida por una o más instrucciones "ARG", que declaran los argumentos que se utilizan en las líneas "FROM" del archivo de Docker.
Cualquier línea que comience por "#" se considera un comentario (excepto las directivas de sintaxis válidas). Si "#" aparece en cualquier otra parte de la línea se considerará un argumento. Por otra parte, los comentarios no soportan los caracteres de continuación de línea.
ADD <origen>... <destino>
o
ADD ["<origen>",... "<destino>"] (Esta forma es necesaria para las rutas que contienen espacios en blanco).
La instrucción "ADD" hace copias de nuevos archivos, directorios o URL de archivos remotos desde <origen> y las agrega al sistema de archivos de la imagen en la ruta de acceso <destino>.
Se pueden especificar varios <origen> de recursos, pero si son archivos o directorios, deben ser relativos al directorio de origen que se está construyendo (el contexto de la compilación).
Cada <origen> puede contener caracteres comodín y la coincidencia se realizará usando las reglas de la función "match" de "filepath" de Go (un lenguaje de programación).
El <destino> es una ruta absoluta, o una ruta de acceso relativa a la instrucción "WORKDIR", en la que se copiará el origen dentro del contenedor de destino.
Cuando se agregan archivos o directorios que contienen caracteres especiales (como "&"), se deben evitar las rutas que siguen las reglas de Golang (Go) para evitar que se traten como un patrón coincidente.
Todos los archivos y directorios nuevos se crean con un UID (nº de identificación de usuario en Linux) y GID (nº de identificación de grupo en Linux) de 0.
En el caso en que <origen> sea una URL de archivo remota, el destino tendrá permisos de 600. Si el archivo remoto que se está recuperando tiene un encabezado HTTP Last-Modified, se utilizará la marca de tiempo de ese encabezado para establecer el comando mtime en el archivo de destino. Sin embargo, al igual que cualquier otro archivo procesado durante un "ADD", mtime no se incluirá en la determinación de si el archivo ha cambiado y la memoria caché debe ser actualizada.
El uso de "ADD" sigue las siguientes normas:
ARG
ARG <nombre>[=<valor predeterminado>]
La instrucción "ARG" define una variable que los usuarios pueden pasar en el tiempo de construcción al constructor con el comando de creación docker build mediante el parámetro "--build-arg <nombre de variable> = <valor>". Si un usuario especifica un argumento de construcción que no estaba definido en el archivo de Docker, la construcción genera una advertencia.
Un archivo de Docker puede incluir una o más instrucciones "ARG".
Una instrucción "ARG" puede incluir opcionalmente un valor predeterminado. Si este es el caso, y si no hay ningún valor pasado en el tiempo de construcción, el generador utiliza el valor predeterminado.
Una definición de variable "ARG" entra en vigor a partir de la línea en la que se define en el archivo de Docker, no del uso del argumento en la línea de comandos o en otro lugar.
Una instrucción "ARG" sale del alcance al final de la etapa de construcción donde se definió. Para usar una variable arg en múltiples etapas, cada etapa debe incluir la instrucción "ARG".
Es posible utilizar una instrucción "ARG" o "ENV" para especificar variables que están disponibles para la instrucción "RUN". Las variables de entorno definidas mediante la instrucción "ENV" siempre anulan una instrucción "ARG" del mismo nombre.
Docker tiene un conjunto de variables "ARG" predefinidas que puede utilizar sin una instrucción "ARG" correspondiente en el archivo de Docker:
De forma predeterminada, estas variables predefinidas se excluyen de la salida del comando docker history. Su exclusión reduce el riesgo de filtrar accidentalmente información de autenticación sensible en una variable HTTP_PROXY.
Si se necesita anular este comportamiento, se puede agregar una instrucción "ARG" en el archivo de Docker.
Las variables "ARG" no son persistentes en la imagen construida como variables "ENV". Sin embargo, las variables "ARG" afectan la caché de generación de manera similar. Si un archivo de Docker define una variable "ARG" cuyo valor es diferente de una compilación anterior, entonces una "falta de caché" ocurre en su primer uso, no su definición. En particular, todas las instrucciones "RUN" que siguen una instrucción "ARG" utilizan implícitamente la variable ARG (como variable de entorno), por lo que pueden producirse fallos en la memoria caché. Todas las variables "ARG" predefinidas están exentas de almacenamiento en caché a menos que exista una declaración "ARG" coincidente en el archivo de Docker.
CMD
CMD ["ejecutable","param1","param2"] (forma ejecutable)
o
CMD ["param1","param2"] (como los parámetros predeterminados de "ENTRYPOINT")
o
CMD comando param1 param2 (forma de intérprete de comandos).
Sólo puede haber una instrucción "CMD" en un archivo de Docker. En el caso de haber más de uno, sólo entrará en vigor el último.
El objetivo principal de un "CMD" es proporcionar valores predeterminados para un contenedor en ejecución. Estos valores por defecto pueden incluir un ejecutable, o pueden omitir el ejecutable, en cuyo caso también se debe especificar una instrucción "ENTRYPOINT".
Cuando se utiliza en los formatos de intérprete de comandos o de ejecutable, la instrucción "CMD" establece el comando a ejecutar al ejecutar la imagen.
Si se utiliza la forma de intérprete de comandos del CMD, el <comando> se ejecutará en "/ bin / sh -c".
Si se desea ejecutar su <comando> sin intérprete de comandos, se debe expresar el comando como una matriz JSON y darle la ruta completa al ejecutable. Esta forma de matriz es el formato preferido de "CMD". Cualquier parámetro adicional se debe expresar individualmente como cadenas en la matriz.
Si se desea que un contenedor ejecute el mismo ejecutable cada vez, deberá considerarse utilizar "ENTRYPOINT" en combinación con "CMD".
COPY
COPY <origen>... <destino>
o
COPY ["<origen>",... "<destino>"] (esta forma se utiliza cuando hay espacios en blanco en la ruta).
La instrucción "COPY" copia archivos nuevos o directorios de <origen> y los agrega al sistema de archivos del contenedor en la ruta de acceso <destino>.
Pueden especificarse varios <origen> de recursos pero deben ser relativos al directorio de origen que se está construyendo (el contexto de la compilación).
Cada <origen> puede contener caracteres comodín y la coincidencia se realizará usando las reglas de la función "match" de "filepath" de Go.
El <destino> es una ruta absoluta, o una ruta de acceso relativa a la intrucción "WORKDIR", en la que se copiará el origen dentro del contenedor de destino.
Cuando se agregan archivos o directorios que contienen caracteres especiales (como "&"), se deben evitar las rutas que siguen las reglas de Golang para evitar que se traten como un patrón coincidente.
Todos los archivos y directorios nuevos se crean con un UID y GID de 0.
Opcionalmente, "COPY" acepta un parámetro "--from = <nombre | índice>" que se puede utilizar para establecer la ubicación de origen en un estado de creación anterior (creado con "FROM .. AS <nombre>") que se utilizará en lugar de un contexto de compilación enviado por el usuario. El indicador también acepta un índice numérico asignado para todas las etapas de construcción anteriores iniciadas con la instrucción "FROM". En caso de que no se pueda encontrar una etapa de construcción con un nombre especificado, se intentará utilizar una imagen con el mismo nombre.
El uso de esta instrucción se rige por las siguientes reglas:
ENTRYPOINT
ENTRYPOINT ["ejecutable", "param1", "param2"] (forma ejecutable, preferred)
o
ENTRYPOINT comando param1 param2 (forma de intérprete de comandos).
Esta instrucción permite configurar un contenedor que se ejecutará como un ejecutable.
Los argumentos de la línea de comandos para la ejecución del comando docker run <imagen> se añadirán después de todos los elementos en una forma ejecutable de "ENTRYPOINT" y anularán todos los elementos especificados mediante "CMD". Esto permite que los argumentos se pasen al punto de entrada, por ejemplo, la ejecución de docker run <imagen> -d pasará el argumento "-d" al punto de entrada. Es posible sobrescribir la instrucción "ENTRYPOINT" utilizando el parámetro "--entrypoint" en el comando docker run.
La forma de intérprete de comandos evita que se utilice cualquier instrucción "CMD" o comando run, pero tiene la desventaja de que el "ENTRYPOINT" se iniciará como un subcomando de "/ bin / sh -c", que no pasa señales. Esto significa que el ejecutable no será el PID (nº de identificación de proceso) 1 del contenedor (y no recibirá señales de Unix), por lo que su ejecutable no recibirá un "SIGTERM" desde el comando docker stop <contenedor>.
Sólo la última instrucción "ENTRYPOINT" del archivo de Docker tendrá efecto.
ENV
ENV <clave> <valor>
o
ENV <clave>=<valor> ...
La instrucción "ENV" establece la variable de entorno <clave> en el valor <valor>. Este valor estará en el entorno de todos los comandos de un archivo de Docker "descendente" y puede ser reemplazado en línea en muchos también.
La instrucción "ENV" tiene dos formas. La primera de ellas, "ENV <clave> <valor>", establecerá una variable única en un valor. Toda la cadena tras el primer espacio será tratada como el <valor> (incluyendo caracteres como espacios y comillas).
La segunda forma, "ENV <clave> = <valor> ...", permite que se establezcan varias variables al mismo tiempo. Obsérvese que la segunda forma utiliza el signo igual (=) en la sintaxis, mientras que la primera forma no. Al igual que en la sintaxis de la línea de comandos, las comillas y las barras invertidas se pueden utilizar para incluir espacios dentro de valores.
Las variables de entorno establecidas con "ENV" se mantendrán cuando se ejecute un contenedor a partir de la imagen resultante.
EXPOSE
EXPOSE <puerto> [<puerto>...]
La instrucción "EXPOSE" informa a Docker que el contenedor escucha en los puertos de red especificados mientras se ejecuta. "EXPOSE" no hace accesibles los puertos del contenedor al anfitrión. Para ello, debe utilizar el parámetro "-p" para publicar un rango de puertos o el parámetro "-P" para publicar todos los puertos expuestos. Se puede exponer un número de puerto y publicarlo externamente bajo otro número.
Es posible configurar la redirección de puertos en el sistema anfitrión mediante el uso del parámetro "-P". La función de red de Docker admite la creación de redes sin necesidad de exponer puertos dentro de la red.
FROM
FROM <imagen> [AS <nombre>]
o
FROM <imagen>[:<etiqueta>] [AS <nombre>]
o
FROM <imagen>[@<código>] [AS <nombre>].
La instrucción "FROM" inicializa una nueva etapa de compilación y establece la imagen base para las instrucciones posteriores. Como tal, un archivo de Docker válido debe comenzar con una instrucción "FROM" (o con "ARG"). La imagen puede ser cualquier imagen válida; es especialmente fácil empezar tirando de una imagen de los repositorios públicos.
"FROM" puede aparecer varias veces dentro de un mismo archivo de Docker para crear varias imágenes o utilizar una etapa de creación como una dependencia para otra. Simplemente se debe tomar nota de la última salida de ID (número de identificación) de imagen por el comando commit antes de cada nueva instrucción "FROM". Cada instrucción "FROM" borra cualquier estado creado por instrucciones anteriores.
Opcionalmente, se puede asignar un nombre a una nueva etapa de compilación añadiendo "AS nombre" a la instrucción "FROM". El nombre se puede utilizar en las siguientes instrucciones "FROM" y "COPY --from = <nombre | index>" para referirse a la imagen construida en esta etapa.
Los valores de etiqueta o resumen son opcionales. Si se omite cualquiera de ellos, el constructor asume una etiqueta más reciente de forma predeterminada. El constructor devuelve un error si no puede encontrar el valor de la etiqueta.
HEALTHCHECK
HEALTHCHECK [OPCIONES] CMD comando (Verifica la salud del contenedor ejecutando un comando dentro del contenedor)
o
HEALTHCHECK NONE (Deshabilita cualquier verificación de salud heredada de la imagen base).
La instrucción "HEALTHCHECK" le indica a Docker cómo probar un contenedor para comprobar que todavía está funcionando. Esto puede detectar casos como un servidor web que está atrapado en un bucle infinito y no puede manejar nuevas conexiones, aunque el proceso del servidor todavía se está ejecutando.
Cuando un contenedor tiene una verificación de salud especificada, tiene un estado de salud además de su estado normal. Este estado se inicia inicialmente. Cada vez que pasa un examen de salud, se vuelve saludable (cualquiera que sea el estado en el que se encontraba anteriormente). Después de un cierto número de fracasos consecutivos, se vuelve insalubre.
Las opciones que pueden aparecer antes de CMD, en la primera forma, son:
Si una sola ejecución de la comprobación toma más tiempo que los segundos de tiempo de espera, se considera que la comprobación ha fallado.
Lleva varios reintentos fracasados consecutivos del chequeo de salud para que el contenedor sea considerado insalubre.
El período de inicio proporciona el tiempo de inicialización para los contenedores que necesitan tiempo para arrancar. La falla de la prueba durante ese período no se contará hacia el número máximo de reintentos. Sin embargo, si un chequeo de salud tiene éxito durante el período de inicio, el contenedor se considera iniciado y todos los fallos consecutivos se contarán hacia el número máximo de reintentos.
Sólo puede haber una instrucción "HEALTHCHECK" en un archivo de Docker. Si se escribe más de una, entonces sólo entrará en vigor la última "HEALTHCHECK".
El comando después de la palabra clave CMD de la primera forma puede ser un comando de intérprete de comandos (por ejemplo, "HEALTHCHECK CMD / bin / check-running") o una matriz ejecutable.
El estado de salida del comando indica el estado de salud del contenedor. Los valores posibles son:
LABEL
LABEL <clave>=<valor> <clave>=<valor> <clave>=<valor> ...
La instrucción "LABEL" añade metadatos a una imagen. Un "LABEL" es un par clave-valor. Para incluir espacios dentro de un valor de "LABEL" se usan comillas y barras invertidas como se haría en el análisis de línea de comandos.
Una imagen puede tener más de una etiqueta. Para especificar varias etiquetas, Docker recomienda combinar varias etiquetas en una sola instrucción "LABEL" siempre que sea posible. Cada instrucción "LABEL" produce una nueva capa que puede resultar en una imagen ineficaz si se usan muchas etiquetas.
Las etiquetas son aditivas incluyendo etiquetas en las imágenes. Si Docker encuentra una etiqueta/clave que ya existe, el nuevo valor anula las etiquetas anteriores con claves idénticas.
MAINTAINER
MAINTAINER <nombre>
Aunque ya obsoleta, la instrucción "MAINTAINER" establece el campo "Autor" de las imágenes generadas. La instrucción "LABEL" es una versión mucho más flexible para realizar una acción parecida y se debería usar en su lugar, ya que permite establecer cualquier metadato que se necesite, y se puede ver fácilmente.
ONBUILD
ONBUILD [INSTRUCCIÓN]
La instrucción "ONBUILD" agrega a la imagen una instrucción desencadenante que se ejecutará en un momento posterior, cuando la imagen se utiliza como base para otra compilación. El desencadenador se ejecutará en el contexto de la compilación descendente, como si se hubiera insertado inmediatamente después de la instrucción "FROM" en el archivo de Docker descendente.
Cualquier instrucción de compilación se puede registrar como un desencadenante.
Esto es útil si el usuario está construyendo una imagen que se utilizará como base para construir otras imágenes, por ejemplo, un entorno de creación de aplicaciones o un demonio que se puede personalizar con la configuración específica del usuario.
Lógicamente, el encadenamiento de las instrucciones de "ONBUILD" mediante "ONBUILD ONBUILD" no está permitido. Además, la instrucción "ONBUILD" no puede desencadenar las instrucciones "FROM" o "MAINTAINER".
RUN
RUN <comando> (forma de intérprete de comandos; el comando se ejecuta en un intérprete de comandos, los predeterminados son: "/bin/sh -c" en Linux, "cmd /S /C" en Windows)
o
RUN ["ejecutable", "param1", "param2"] (forma ejecutable).
La instrucción RUN ejecutará cualquier comando en una nueva capa en la parte superior de la imagen actual y confirmará los resultados. La imagen confirmada resultante se utilizará para el siguiente paso en el archivo de Docker.
Estratificando las instrucciones RUN y generando mediante comandos commit conforme a los conceptos básicos de Docker, donde el uso de commit es barato y los contenedores pueden ser creados desde cualquier punto en el historial de una imagen, al igual que el control de origen.
La forma ejecutable permite evitar el maquillaje de las cadenas de intérprete de comandos y ejecutar comandos utilizando una imagen de base que no contiene el ejecutable de intérprete de comandos especificado.
El intérprete de comandos predeterminado para la forma de intérprete de comandos se puede cambiar usando la instrucción "SHELL".
En la forma de intérprete de comandos se puede usar una "\" (barra invertida) para continuar con una sola instrucción "RUN" en la siguiente línea.
La caché para las instrucciones "RUN" no se invalida automáticamente durante la siguiente compilación. La caché de una instrucción como "RUN apt-get dist-upgrade -y" será reutilizada durante la siguiente compilación. La caché para las instrucciones "RUN" puede ser invalidada usando el parámetro "--no-cache".
SHELL
SHELL ["executable", "parameters"]
La instrucción "SHELL" permite que el intérprete de comandos predeterminado utilizado para la forma del intérprete de comandos de los comandos sea sobreescrita. El intérprete de comandos por defecto en Linux es ["/ bin / sh", "-c"], mientras que en Windows es ["cmd", "/ S", "/ C"]. La instrucción "SHELL" debe escribirse en forma JSON en un archivo de Docker.
La instrucción "SHELL" es particularmente útil en Windows, donde hay dos intérpretes de comandos nativos comúnmente utilizados y bastante diferentes: cmd y powershell, así como intérpretes de comandos alternativos disponibles incluyendo sh.
La instrucción "SHELL" puede aparecer varias veces. Cada instrucción "SHELL" anula todas las instrucciones anteriores de "SHELL", y afecta a todas las instrucciones posteriores.
Las siguientes instrucciones pueden verse afectadas por la instrucción "SHELL" cuando se usa la forma de intérprete de comandos de ellas en un archivo de Docker: "RUN", "CMD" y "ENTRYPOINT".
Esta instrucción también podría usarse para modificar la forma en que un intérprete de comandos opera. Por ejemplo, utilizando "SHELL cmd / S / C / V: ON | OFF" en Windows, se podría modificar la semántica de expansión de variables de entorno diferido. Además, la instrucción "SHELL" también se puede usar en Linux si se requiere un intérprete de comandos alternativo como zsh, csh, tcsh y otros.
STOPSIGNAL
STOPSIGNAL señal
La instrucción "STOPSIGNAL" establece la señal de llamada del sistema que se enviará al contenedor para salir. Esta señal puede ser un número sin signo válido que coincida con una posición en la tabla de llamadas del sistema del núcleo, por ejemplo 9, o un nombre de señal en el formato "SIGNOMBRE", por ejemplo SIGKILL.
USER
USER <usuario>[:<grupo>]
o
USER <UID>[:<GID>]
La instrucción "USER" establece el nombre de usuario (o UID) y, opcionalmente, el grupo de usuarios (o GID) que se usará al ejecutar la imagen y para cualquier instrucción "RUN", "CMD" y "ENTRYPOINT" que lo sigan en el archivo de Docker.
Sin embargo, si el usuario no tiene un grupo principal, entonces la imagen (o las siguientes instrucciones) se ejecutará con el grupo raíz (root).
VOLUME
VOLUME ["/datos"]
La instrucción "VOLUME" crea un punto de montaje con el nombre especificado y lo marca como la celebración de volúmenes montados externamente desde el anfitrión nativo u otros contenedores. El valor puede ser una matriz JSON, "VOLUME ["/ var / log /"]", o una cadena simple con varios argumentos, como "VOLUME / var / log" o "VOLUME / var / log / var / db".
El comando docker run inicializa el volumen recién creado con cualquier dato que exista en la ubicación especificada dentro de la imagen de base.
Cuando se emplean volúmenes en un archivo de Docker se debe tener en cuenta lo siguiente:
En esta entrada se hablará de un excelente método de instalación de imágenes en Docker: el archivo de Docker ("Dockerfile", en inglés).
Básicamente, se trata de un archivo de configuración que se utiliza para crear imágenes donde el usuario que lo crea indica qué es lo que desea que tenga la imagen, y los distintos comandos para instalar las herramientas, que deben ir junto al archivo (correspondiendo con la ruta especificada en este) cuando sea necesario.
El archivo en sí es un archivo de texto plano sin extensión alguna, pero que siempre debe llamarse "Dockerfile", escrito con un código muy similar al JavaScript Object Notation (JSON; código fuente que describe los datos con una sintaxis dedicada que se usa para identificar y gestionar estos). Para revisarlo y/o editarlo correctamente, es conveniente utilizar un programa de edición de textos compatible con el formato de código antes mencionado (Notepad++, Sublime Text, o Brackets, por ejemplo).
La sintaxis básica de un archivo de Docker es:
# Comentarios
INSTRUCCIÓN argumentos
Aunque la instrucción no distingue entre mayúsculas y minúsculas, es conveniente escribirla en mayúsculas para distinguirla de los argumentos.
Docker ejecuta instrucciones de un archivo de Docker en orden. El archivo de Docker debe comenzar con una instrucción "FROM", que especifica la imagen base de la que está construyendo, y que sólo puede estar precedida por una o más instrucciones "ARG", que declaran los argumentos que se utilizan en las líneas "FROM" del archivo de Docker.
Cualquier línea que comience por "#" se considera un comentario (excepto las directivas de sintaxis válidas). Si "#" aparece en cualquier otra parte de la línea se considerará un argumento. Por otra parte, los comentarios no soportan los caracteres de continuación de línea.
INSTRUCCIONES DEL ARCHIVO
ADDADD <origen>... <destino>
o
ADD ["<origen>",... "<destino>"] (Esta forma es necesaria para las rutas que contienen espacios en blanco).
La instrucción "ADD" hace copias de nuevos archivos, directorios o URL de archivos remotos desde <origen> y las agrega al sistema de archivos de la imagen en la ruta de acceso <destino>.
Se pueden especificar varios <origen> de recursos, pero si son archivos o directorios, deben ser relativos al directorio de origen que se está construyendo (el contexto de la compilación).
Cada <origen> puede contener caracteres comodín y la coincidencia se realizará usando las reglas de la función "match" de "filepath" de Go (un lenguaje de programación).
El <destino> es una ruta absoluta, o una ruta de acceso relativa a la instrucción "WORKDIR", en la que se copiará el origen dentro del contenedor de destino.
Cuando se agregan archivos o directorios que contienen caracteres especiales (como "&"), se deben evitar las rutas que siguen las reglas de Golang (Go) para evitar que se traten como un patrón coincidente.
Todos los archivos y directorios nuevos se crean con un UID (nº de identificación de usuario en Linux) y GID (nº de identificación de grupo en Linux) de 0.
En el caso en que <origen> sea una URL de archivo remota, el destino tendrá permisos de 600. Si el archivo remoto que se está recuperando tiene un encabezado HTTP Last-Modified, se utilizará la marca de tiempo de ese encabezado para establecer el comando mtime en el archivo de destino. Sin embargo, al igual que cualquier otro archivo procesado durante un "ADD", mtime no se incluirá en la determinación de si el archivo ha cambiado y la memoria caché debe ser actualizada.
El uso de "ADD" sigue las siguientes normas:
- La ruta <origen> debe estar dentro del contexto de la construcción; no se puede escribir algo como "ADD ../algo / algo", porque el primer paso de un comando docker build es enviar el directorio de contexto (y subdirectorios) al demonio docker.
- Si <origen> es una URL y <destino> no termina con una barra diagonal final, se descarga un archivo de la URL y se copia en <destino>.
- Si <origen> es una URL y <destino> termina con una barra diagonal final, el nombre del archivo se deduce de la URL y el archivo se descarga en <destino> / <nombre de archivo> (ejemplo: "ADD http://example.com/foobar/" creará el archivo "/ foobar"). La URL debe tener una ruta no trivial para que se pueda descubrir un nombre de archivo apropiado en este caso ("http://example.com" no funcionará).
- Si <origen> es un directorio, se copia todo el contenido del directorio, incluidos los metadatos del sistema de archivos.
- Si <origen> es un archivo tar local en un formato de compresión reconocido (identidad, gzip, bzip2 o xz), se descomprime como un directorio. Los recursos de las URL remotas no se descomprimen. Cuando se copia o descomprime un directorio, tiene el mismo comportamiento que tar -x (comando de descompresión de archivos de Linux), el resultado es la unión de cualquiera que haya existido en la ruta de destino y el contenido del árbol de origen, con los conflictos resueltos en favor de este último sobre una base de archivo por archivo.
- Si <origen> es cualquier otro tipo de archivo, se copiará individualmente junto con sus metadatos. En este caso, si <destino> termina con una barra inclinada "/", se considerará un directorio y el contenido de <origen> se escribirá en "<destino> / base (<origen>)".
- Si se especifican varios recursos de <origen>, ya sea directamente o debido al uso de un comodín, entonces <destino> debe ser un directorio y debe finalizar con una barra "/".
- Si <destino> no termina con una barra diagonal, se considerará un archivo normal y el contenido de <origen> se escribirá en <destino>.
- Si <destino> no existe, se crea junto con todos los directorios que faltan en su ruta de acceso.
ARG
ARG <nombre>[=<valor predeterminado>]
La instrucción "ARG" define una variable que los usuarios pueden pasar en el tiempo de construcción al constructor con el comando de creación docker build mediante el parámetro "--build-arg <nombre de variable> = <valor>". Si un usuario especifica un argumento de construcción que no estaba definido en el archivo de Docker, la construcción genera una advertencia.
Un archivo de Docker puede incluir una o más instrucciones "ARG".
Una instrucción "ARG" puede incluir opcionalmente un valor predeterminado. Si este es el caso, y si no hay ningún valor pasado en el tiempo de construcción, el generador utiliza el valor predeterminado.
Una definición de variable "ARG" entra en vigor a partir de la línea en la que se define en el archivo de Docker, no del uso del argumento en la línea de comandos o en otro lugar.
Una instrucción "ARG" sale del alcance al final de la etapa de construcción donde se definió. Para usar una variable arg en múltiples etapas, cada etapa debe incluir la instrucción "ARG".
Es posible utilizar una instrucción "ARG" o "ENV" para especificar variables que están disponibles para la instrucción "RUN". Las variables de entorno definidas mediante la instrucción "ENV" siempre anulan una instrucción "ARG" del mismo nombre.
Docker tiene un conjunto de variables "ARG" predefinidas que puede utilizar sin una instrucción "ARG" correspondiente en el archivo de Docker:
- HTTP_PROXY
- http_proxy
- HTTPS_PROXY
- https_proxy
- FTP_PROXY
- ftp_proxy
- NO_PROXY
- no_proxy
De forma predeterminada, estas variables predefinidas se excluyen de la salida del comando docker history. Su exclusión reduce el riesgo de filtrar accidentalmente información de autenticación sensible en una variable HTTP_PROXY.
Si se necesita anular este comportamiento, se puede agregar una instrucción "ARG" en el archivo de Docker.
Las variables "ARG" no son persistentes en la imagen construida como variables "ENV". Sin embargo, las variables "ARG" afectan la caché de generación de manera similar. Si un archivo de Docker define una variable "ARG" cuyo valor es diferente de una compilación anterior, entonces una "falta de caché" ocurre en su primer uso, no su definición. En particular, todas las instrucciones "RUN" que siguen una instrucción "ARG" utilizan implícitamente la variable ARG (como variable de entorno), por lo que pueden producirse fallos en la memoria caché. Todas las variables "ARG" predefinidas están exentas de almacenamiento en caché a menos que exista una declaración "ARG" coincidente en el archivo de Docker.
CMD
CMD ["ejecutable","param1","param2"] (forma ejecutable)
o
CMD ["param1","param2"] (como los parámetros predeterminados de "ENTRYPOINT")
o
CMD comando param1 param2 (forma de intérprete de comandos).
Sólo puede haber una instrucción "CMD" en un archivo de Docker. En el caso de haber más de uno, sólo entrará en vigor el último.
El objetivo principal de un "CMD" es proporcionar valores predeterminados para un contenedor en ejecución. Estos valores por defecto pueden incluir un ejecutable, o pueden omitir el ejecutable, en cuyo caso también se debe especificar una instrucción "ENTRYPOINT".
Cuando se utiliza en los formatos de intérprete de comandos o de ejecutable, la instrucción "CMD" establece el comando a ejecutar al ejecutar la imagen.
Si se utiliza la forma de intérprete de comandos del CMD, el <comando> se ejecutará en "/ bin / sh -c".
Si se desea ejecutar su <comando> sin intérprete de comandos, se debe expresar el comando como una matriz JSON y darle la ruta completa al ejecutable. Esta forma de matriz es el formato preferido de "CMD". Cualquier parámetro adicional se debe expresar individualmente como cadenas en la matriz.
Si se desea que un contenedor ejecute el mismo ejecutable cada vez, deberá considerarse utilizar "ENTRYPOINT" en combinación con "CMD".
COPY
COPY <origen>... <destino>
o
COPY ["<origen>",... "<destino>"] (esta forma se utiliza cuando hay espacios en blanco en la ruta).
La instrucción "COPY" copia archivos nuevos o directorios de <origen> y los agrega al sistema de archivos del contenedor en la ruta de acceso <destino>.
Pueden especificarse varios <origen> de recursos pero deben ser relativos al directorio de origen que se está construyendo (el contexto de la compilación).
Cada <origen> puede contener caracteres comodín y la coincidencia se realizará usando las reglas de la función "match" de "filepath" de Go.
El <destino> es una ruta absoluta, o una ruta de acceso relativa a la intrucción "WORKDIR", en la que se copiará el origen dentro del contenedor de destino.
Cuando se agregan archivos o directorios que contienen caracteres especiales (como "&"), se deben evitar las rutas que siguen las reglas de Golang para evitar que se traten como un patrón coincidente.
Todos los archivos y directorios nuevos se crean con un UID y GID de 0.
Opcionalmente, "COPY" acepta un parámetro "--from = <nombre | índice>" que se puede utilizar para establecer la ubicación de origen en un estado de creación anterior (creado con "FROM .. AS <nombre>") que se utilizará en lugar de un contexto de compilación enviado por el usuario. El indicador también acepta un índice numérico asignado para todas las etapas de construcción anteriores iniciadas con la instrucción "FROM". En caso de que no se pueda encontrar una etapa de construcción con un nombre especificado, se intentará utilizar una imagen con el mismo nombre.
El uso de esta instrucción se rige por las siguientes reglas:
- La ruta <origen> debe estar dentro del contexto de la construcción; no se puede escribir algo como "COPY ../algo / algo", porque el primer paso de un comando docker build es enviar el directorio de contexto (y subdirectorios) al demonio docker.
- Si <origen> es un directorio, se copia todo el contenido del directorio, incluidos los metadatos del sistema de archivos.
- Si <origen> es cualquier otro tipo de archivo, se copiará individualmente junto con sus metadatos. En este caso, si <destino> termina con una barra inclinada "/", se considerará un directorio y el contenido de <origen> se escribirá en "<destino> / base (<origen>)".
- Si se especifican varios <origen> de recursos , ya sea directamente o debido al uso de un caracter comodín, <destino> debe ser un directorio y debe finalizar con una barra "/".
- Si <destino> no termina con una barra diagonal, se considerará un archivo normal y el contenido de <origen> se escribirá en <destino>.
- Si <destino> no existe, se crea junto con todos los directorios que faltan en su ruta de acceso.
ENTRYPOINT
ENTRYPOINT ["ejecutable", "param1", "param2"] (forma ejecutable, preferred)
o
ENTRYPOINT comando param1 param2 (forma de intérprete de comandos).
Esta instrucción permite configurar un contenedor que se ejecutará como un ejecutable.
Los argumentos de la línea de comandos para la ejecución del comando docker run <imagen> se añadirán después de todos los elementos en una forma ejecutable de "ENTRYPOINT" y anularán todos los elementos especificados mediante "CMD". Esto permite que los argumentos se pasen al punto de entrada, por ejemplo, la ejecución de docker run <imagen> -d pasará el argumento "-d" al punto de entrada. Es posible sobrescribir la instrucción "ENTRYPOINT" utilizando el parámetro "--entrypoint" en el comando docker run.
La forma de intérprete de comandos evita que se utilice cualquier instrucción "CMD" o comando run, pero tiene la desventaja de que el "ENTRYPOINT" se iniciará como un subcomando de "/ bin / sh -c", que no pasa señales. Esto significa que el ejecutable no será el PID (nº de identificación de proceso) 1 del contenedor (y no recibirá señales de Unix), por lo que su ejecutable no recibirá un "SIGTERM" desde el comando docker stop <contenedor>.
Sólo la última instrucción "ENTRYPOINT" del archivo de Docker tendrá efecto.
ENVENV <clave> <valor>
o
ENV <clave>=<valor> ...
La instrucción "ENV" establece la variable de entorno <clave> en el valor <valor>. Este valor estará en el entorno de todos los comandos de un archivo de Docker "descendente" y puede ser reemplazado en línea en muchos también.
La instrucción "ENV" tiene dos formas. La primera de ellas, "ENV <clave> <valor>", establecerá una variable única en un valor. Toda la cadena tras el primer espacio será tratada como el <valor> (incluyendo caracteres como espacios y comillas).
La segunda forma, "ENV <clave> = <valor> ...", permite que se establezcan varias variables al mismo tiempo. Obsérvese que la segunda forma utiliza el signo igual (=) en la sintaxis, mientras que la primera forma no. Al igual que en la sintaxis de la línea de comandos, las comillas y las barras invertidas se pueden utilizar para incluir espacios dentro de valores.
Las variables de entorno establecidas con "ENV" se mantendrán cuando se ejecute un contenedor a partir de la imagen resultante.
EXPOSE
EXPOSE <puerto> [<puerto>...]
La instrucción "EXPOSE" informa a Docker que el contenedor escucha en los puertos de red especificados mientras se ejecuta. "EXPOSE" no hace accesibles los puertos del contenedor al anfitrión. Para ello, debe utilizar el parámetro "-p" para publicar un rango de puertos o el parámetro "-P" para publicar todos los puertos expuestos. Se puede exponer un número de puerto y publicarlo externamente bajo otro número.
Es posible configurar la redirección de puertos en el sistema anfitrión mediante el uso del parámetro "-P". La función de red de Docker admite la creación de redes sin necesidad de exponer puertos dentro de la red.
FROM
FROM <imagen> [AS <nombre>]
o
FROM <imagen>[:<etiqueta>] [AS <nombre>]
o
FROM <imagen>[@<código>] [AS <nombre>].
La instrucción "FROM" inicializa una nueva etapa de compilación y establece la imagen base para las instrucciones posteriores. Como tal, un archivo de Docker válido debe comenzar con una instrucción "FROM" (o con "ARG"). La imagen puede ser cualquier imagen válida; es especialmente fácil empezar tirando de una imagen de los repositorios públicos.
"FROM" puede aparecer varias veces dentro de un mismo archivo de Docker para crear varias imágenes o utilizar una etapa de creación como una dependencia para otra. Simplemente se debe tomar nota de la última salida de ID (número de identificación) de imagen por el comando commit antes de cada nueva instrucción "FROM". Cada instrucción "FROM" borra cualquier estado creado por instrucciones anteriores.
Opcionalmente, se puede asignar un nombre a una nueva etapa de compilación añadiendo "AS nombre" a la instrucción "FROM". El nombre se puede utilizar en las siguientes instrucciones "FROM" y "COPY --from = <nombre | index>" para referirse a la imagen construida en esta etapa.
Los valores de etiqueta o resumen son opcionales. Si se omite cualquiera de ellos, el constructor asume una etiqueta más reciente de forma predeterminada. El constructor devuelve un error si no puede encontrar el valor de la etiqueta.
HEALTHCHECK
HEALTHCHECK [OPCIONES] CMD comando (Verifica la salud del contenedor ejecutando un comando dentro del contenedor)
o
HEALTHCHECK NONE (Deshabilita cualquier verificación de salud heredada de la imagen base).
La instrucción "HEALTHCHECK" le indica a Docker cómo probar un contenedor para comprobar que todavía está funcionando. Esto puede detectar casos como un servidor web que está atrapado en un bucle infinito y no puede manejar nuevas conexiones, aunque el proceso del servidor todavía se está ejecutando.
Cuando un contenedor tiene una verificación de salud especificada, tiene un estado de salud además de su estado normal. Este estado se inicia inicialmente. Cada vez que pasa un examen de salud, se vuelve saludable (cualquiera que sea el estado en el que se encontraba anteriormente). Después de un cierto número de fracasos consecutivos, se vuelve insalubre.
Las opciones que pueden aparecer antes de CMD, en la primera forma, son:
- --interval=DURACIÓN (predeterminada: 30s).
- --timeout=DURACIÓN (predeterminada: 30s).
- --start-period=DURACIÓN (predeterminada: 0s).
- --retries=Nº (default: 3).
Si una sola ejecución de la comprobación toma más tiempo que los segundos de tiempo de espera, se considera que la comprobación ha fallado.
Lleva varios reintentos fracasados consecutivos del chequeo de salud para que el contenedor sea considerado insalubre.
El período de inicio proporciona el tiempo de inicialización para los contenedores que necesitan tiempo para arrancar. La falla de la prueba durante ese período no se contará hacia el número máximo de reintentos. Sin embargo, si un chequeo de salud tiene éxito durante el período de inicio, el contenedor se considera iniciado y todos los fallos consecutivos se contarán hacia el número máximo de reintentos.
Sólo puede haber una instrucción "HEALTHCHECK" en un archivo de Docker. Si se escribe más de una, entonces sólo entrará en vigor la última "HEALTHCHECK".
El comando después de la palabra clave CMD de la primera forma puede ser un comando de intérprete de comandos (por ejemplo, "HEALTHCHECK CMD / bin / check-running") o una matriz ejecutable.
El estado de salida del comando indica el estado de salud del contenedor. Los valores posibles son:
- 0: Éxito, el recipiente está sano y listo para su uso.
- 1: Poco saludable, el contenedor no funciona correctamente.
- 2: Reservado, no se debe utilizar este código de salida.
LABEL
LABEL <clave>=<valor> <clave>=<valor> <clave>=<valor> ...
La instrucción "LABEL" añade metadatos a una imagen. Un "LABEL" es un par clave-valor. Para incluir espacios dentro de un valor de "LABEL" se usan comillas y barras invertidas como se haría en el análisis de línea de comandos.
Una imagen puede tener más de una etiqueta. Para especificar varias etiquetas, Docker recomienda combinar varias etiquetas en una sola instrucción "LABEL" siempre que sea posible. Cada instrucción "LABEL" produce una nueva capa que puede resultar en una imagen ineficaz si se usan muchas etiquetas.
Las etiquetas son aditivas incluyendo etiquetas en las imágenes. Si Docker encuentra una etiqueta/clave que ya existe, el nuevo valor anula las etiquetas anteriores con claves idénticas.
MAINTAINER
MAINTAINER <nombre>
Aunque ya obsoleta, la instrucción "MAINTAINER" establece el campo "Autor" de las imágenes generadas. La instrucción "LABEL" es una versión mucho más flexible para realizar una acción parecida y se debería usar en su lugar, ya que permite establecer cualquier metadato que se necesite, y se puede ver fácilmente.
ONBUILD
ONBUILD [INSTRUCCIÓN]
La instrucción "ONBUILD" agrega a la imagen una instrucción desencadenante que se ejecutará en un momento posterior, cuando la imagen se utiliza como base para otra compilación. El desencadenador se ejecutará en el contexto de la compilación descendente, como si se hubiera insertado inmediatamente después de la instrucción "FROM" en el archivo de Docker descendente.
Cualquier instrucción de compilación se puede registrar como un desencadenante.
Esto es útil si el usuario está construyendo una imagen que se utilizará como base para construir otras imágenes, por ejemplo, un entorno de creación de aplicaciones o un demonio que se puede personalizar con la configuración específica del usuario.
Lógicamente, el encadenamiento de las instrucciones de "ONBUILD" mediante "ONBUILD ONBUILD" no está permitido. Además, la instrucción "ONBUILD" no puede desencadenar las instrucciones "FROM" o "MAINTAINER".
RUN
RUN <comando> (forma de intérprete de comandos; el comando se ejecuta en un intérprete de comandos, los predeterminados son: "/bin/sh -c" en Linux, "cmd /S /C" en Windows)
o
RUN ["ejecutable", "param1", "param2"] (forma ejecutable).
La instrucción RUN ejecutará cualquier comando en una nueva capa en la parte superior de la imagen actual y confirmará los resultados. La imagen confirmada resultante se utilizará para el siguiente paso en el archivo de Docker.
Estratificando las instrucciones RUN y generando mediante comandos commit conforme a los conceptos básicos de Docker, donde el uso de commit es barato y los contenedores pueden ser creados desde cualquier punto en el historial de una imagen, al igual que el control de origen.
La forma ejecutable permite evitar el maquillaje de las cadenas de intérprete de comandos y ejecutar comandos utilizando una imagen de base que no contiene el ejecutable de intérprete de comandos especificado.
El intérprete de comandos predeterminado para la forma de intérprete de comandos se puede cambiar usando la instrucción "SHELL".
En la forma de intérprete de comandos se puede usar una "\" (barra invertida) para continuar con una sola instrucción "RUN" en la siguiente línea.
La caché para las instrucciones "RUN" no se invalida automáticamente durante la siguiente compilación. La caché de una instrucción como "RUN apt-get dist-upgrade -y" será reutilizada durante la siguiente compilación. La caché para las instrucciones "RUN" puede ser invalidada usando el parámetro "--no-cache".
SHELL
SHELL ["executable", "parameters"]
La instrucción "SHELL" permite que el intérprete de comandos predeterminado utilizado para la forma del intérprete de comandos de los comandos sea sobreescrita. El intérprete de comandos por defecto en Linux es ["/ bin / sh", "-c"], mientras que en Windows es ["cmd", "/ S", "/ C"]. La instrucción "SHELL" debe escribirse en forma JSON en un archivo de Docker.
La instrucción "SHELL" es particularmente útil en Windows, donde hay dos intérpretes de comandos nativos comúnmente utilizados y bastante diferentes: cmd y powershell, así como intérpretes de comandos alternativos disponibles incluyendo sh.
La instrucción "SHELL" puede aparecer varias veces. Cada instrucción "SHELL" anula todas las instrucciones anteriores de "SHELL", y afecta a todas las instrucciones posteriores.
Las siguientes instrucciones pueden verse afectadas por la instrucción "SHELL" cuando se usa la forma de intérprete de comandos de ellas en un archivo de Docker: "RUN", "CMD" y "ENTRYPOINT".
Esta instrucción también podría usarse para modificar la forma en que un intérprete de comandos opera. Por ejemplo, utilizando "SHELL cmd / S / C / V: ON | OFF" en Windows, se podría modificar la semántica de expansión de variables de entorno diferido. Además, la instrucción "SHELL" también se puede usar en Linux si se requiere un intérprete de comandos alternativo como zsh, csh, tcsh y otros.
STOPSIGNAL
STOPSIGNAL señal
La instrucción "STOPSIGNAL" establece la señal de llamada del sistema que se enviará al contenedor para salir. Esta señal puede ser un número sin signo válido que coincida con una posición en la tabla de llamadas del sistema del núcleo, por ejemplo 9, o un nombre de señal en el formato "SIGNOMBRE", por ejemplo SIGKILL.
USER
USER <usuario>[:<grupo>]
o
USER <UID>[:<GID>]
La instrucción "USER" establece el nombre de usuario (o UID) y, opcionalmente, el grupo de usuarios (o GID) que se usará al ejecutar la imagen y para cualquier instrucción "RUN", "CMD" y "ENTRYPOINT" que lo sigan en el archivo de Docker.
Sin embargo, si el usuario no tiene un grupo principal, entonces la imagen (o las siguientes instrucciones) se ejecutará con el grupo raíz (root).
VOLUME
VOLUME ["/datos"]
La instrucción "VOLUME" crea un punto de montaje con el nombre especificado y lo marca como la celebración de volúmenes montados externamente desde el anfitrión nativo u otros contenedores. El valor puede ser una matriz JSON, "VOLUME ["/ var / log /"]", o una cadena simple con varios argumentos, como "VOLUME / var / log" o "VOLUME / var / log / var / db".
El comando docker run inicializa el volumen recién creado con cualquier dato que exista en la ubicación especificada dentro de la imagen de base.
Cuando se emplean volúmenes en un archivo de Docker se debe tener en cuenta lo siguiente:
- Volúmenes en contenedores basados en Windows: Al utilizar contenedores basados en Windows, el destino de un volumen dentro del contenedor debe ser uno de los siguientes: un directorio no existente o vacío, o una unidad distinta de "C:".
- Cambiar el volumen desde dentro del archivo de Docker: Si cualquier paso de compilación cambia los datos dentro del volumen después de haber sido declarado, esos cambios se descartarán.
- Formato JSON: La lista se analiza como una matriz JSON. Debe incluir palabras con comillas dobles (") en lugar de comillas simples (').
- El directorio del anfitrión se declara en tiempo de ejecución de contenedor: El directorio del anfitrión (el punto de montaje) es, por su naturaleza, dependiente del anfitrión. Esto es para preservar la portabilidad de la imagen. Ya que no se puede garantizar que un directorio del anfitrión determinado esté disponible en todos los anfitriones. Por este motivo, no puede montar un directorio de anfitrión desde dentro del archivo de Docker. La instrucción "VOLUME" no admite la especificación de un parámetro "host-dir". Debe especificar el punto de montaje al crear o ejecutar el contenedor.
WORKDIR
WORKDIR /ruta/al/directorio de trabajo
La instrucción "WORKDIR" establece el directorio de trabajo para cualquier instrucción "RUN", "CMD", "ENTRYPOINT", "COPY" y "ADD" que lo sigan en el archivo de Docker. Si "WORKDIR" no existe, se creará aunque no se utilice en ninguna instrucción posterior del archivo de Docker.
La instrucción "WORKDIR" se puede utilizar varias veces en un archivo de Docker. Si se proporciona una ruta relativa, será relativa a la ruta de acceso de la instrucción "WORKDIR" anterior.
La instrucción "WORKDIR" se puede utilizar varias veces en un archivo de Docker. Si se proporciona una ruta relativa, será relativa a la ruta de acceso de la instrucción "WORKDIR" anterior.
Esta instrucción puede resolver las variables de entorno previamente establecidas mediante "ENV", pero sólo puede utilizar variables de entorno establecidas explícitamente en el archivo de Docker.
USO DEL ARCHIVO DE DOCKER
Una vez creado el archivo de Docker, u obtenido de algún otro modo, es el momento de utilizarlo. Evidentemente, sólo se puede activar este archivo si se tiene instalado Docker en el sistema.
Para emplear un archivo de Docker hay que posicionarse en la ruta donde este se encuentra y utilizar el comando docker build -t (nombre de la imagen a crear) . para ejecutarlo (se deben tener permisos de administrador). En el siguiente ejemplo, se puede ver el resultado de la ejecución de un archivo de Docker que crea una imagen (que se llamará "nginx_elb") con el servidor Nginx y una página web de prueba que servirá.
Instalada la imagen en Docker, se creará y ejecutará su correspondiente contenedor para que funcionen tanto el servidor como su página web. Es posible comprobar sus detalles en Docker.
Si se abre un navegador de red en la dirección indicada al crear el contenedor de antes (localhost:8080), puede verse perfectamente la página web servida por el servidor instalado con el archivo de Docker.
Aquí se han mostrado las generalidades del archivo de Docker, pero si el lector quiere profundizar más sobre este tema, puede acudir al siguiente enlace de la página oficial de Docker. Además, el lector puede encontrar más información todavía sobre el uso de los archivos de Docker, sin desestimar la del enlace anterior, en este enlace de la página oficial de Docker.
No hay comentarios:
Publicar un comentario
Deje aquí su comentario, si no puede comentar, pruebe a hacerlo desde otro navegador de red u otro equipo.