Busindre

User Tools

Site Tools

Trace:
guia_rapida_de_la_linea_de_comandos_de_docker

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_la_linea_de_comandos_de_docker [2021/05/15 01:23] – busindreguia_rapida_de_la_linea_de_comandos_de_docker [2022/04/20 10:53] (current) – [SBOM de las imagenes de Docker] busindre
Line 1: Line 1:
 ====== Docker: guía rápida de iniciación a la linea de comandos de Docker ====== ====== Docker: guía rápida de iniciación a la linea de comandos de Docker ======
  
-Manual rápido y completo de Dockerfile: [[guia_rapida_de_dockerfile]]+Manual rápido y completo de Dockerfile:[[guia_rapida_de_dockerfile]]\\ 
 +Manual rápido y completo de Docker Swarm: [[guia_rapida_de_docker_swarm]]
  
 Esta guía muestra los comandos más útiles para iniciarte con Docker por linea de comandos. Esta guía muestra los comandos más útiles para iniciarte con Docker por linea de comandos.
Line 239: Line 240:
  
  
-**TMPFS** (mount tmpfs filesystems) +**TMPFS** (mount tmpfs filesystems). 
-<code bash># Los parámetros usna la misma sintaxis que 'mount -t tmpfs -o' + 
-docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image</code>+Se utiliza para almacenar información en memoria. Sólo mantiene la información mientras el contenedor esté en ejeución, práctico para almacenar información sensible no cifrada. A diferencia de volúmenes y bind mounts, donde es posible compartir la información entre contenedores, con tmpfs no lo es. 
 +<code bash># Los parámetros usan la misma sintaxis que 'mount -t tmpfs -o' 
 +docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image 
 +# Usando la sintaxis de mount. 
 +docker run -d --mount type=tmpfs,destination=/run my_image 
 +</code>
  
 **USER**: Seleccionar el UID/GID del proceso ejecutado dentro del contenedor. **USER**: Seleccionar el UID/GID del proceso ejecutado dentro del contenedor.
Line 249: Line 255:
 <code bash>-w="", --workdir=""</code> <code bash>-w="", --workdir=""</code>
  
-**VOLUME** : El tema de los volúmenes es muy amplio, se mostrará simplemente lo más básico. El volumen montado no es eliminado junto con al contenedor. Desde el contenedor y el anfitrión se pueden editar los permisos (los IDs deben existir en ambos naturalmente).+**VOLUME** : El tema de los volúmenes es muy amplio, se mostrará simplemente lo más básico. Los volúmenes se recomiendan frente a los bind mounts a la hora de almacenar datos. El volumen montado no es eliminado junto con al contenedor. Desde el contenedor y el anfitrión se pueden editar los permisos (los IDs deben existir en ambos naturalmente).
  
 <code bash> <code bash>
Line 261: Line 267:
  
 **Montar una carpeta del host mediante "bind mount"** **Montar una carpeta del host mediante "bind mount"**
 +
 +Los bind mounts es la forma antigua de guardar datos generados por contenedores, han existido desde los primeros días de Docker y desde hace ya mucho tiempo se recomienda no usarlos y usar los volúmenes. Actualmente están regelados a entornos donde sea necesario acceder a determinada información del host anfitrión. Los bind mounts tienen una funcionalidad limitada y diferente en comparación con los volúmenes. Una limitación de los bind mounts es que NO pueden definir un propietario del directorio montado dentro del contenedor. Es decir, siempre se montará con el UID/GUIs del directorio del host. Eso en cambio si es algo configurable con los volúmenes. Siempre se puede usar desde la linea de comandos la opción %%--%%user para arrancar el contenedor con un determinado usuario del host y así poder tener acceso al bind mount desde el contenedor ([[permisos_y_propietarios_en_volumenes_con_docker-compose|leer]]) .
 +
 +Una diferencia con los volúmenes es que los montajes sobre directorios no vacíos, queda oculto el contenido previamente existente, cosa que no sucede al utilizar los volúmenes.
 +
 +Cuando se utiliza un bind mount, un archivo o directorio en la máquina anfitriona se monta en un contenedor. El archivo o directorio es referenciado por su ruta absoluta en el host (máquina anfitriona). Por el contrario, cuando se utiliza un volumen, se crea una nueva carpeta dentro del directorio de almacenamiento de Docker en la máquina anfitriona, y Docker gestiona el contenido de ese directorio.
 +
 +No es necesario que el archivo o directorio ya exista en el host de Docker. Se crea bajo demanda si aún no existe. Los bind mounts son muy eficaces, pero dependen de que el sistema de archivos de la máquina anfitriona tenga una estructura de directorios específica disponible.
  
 <code bash> <code bash>
Line 284: Line 298:
 </code> </code>
  
-**ARG**: Al contruir imágenes las variables pueden ser sobrescirtas siempre que haya sido definida en el Dockerfile o bien sea una de las variables estándar.+**ARG**: Al contruir imágenes las variables pueden ser sobrescritas siempre que haya sido definida en el Dockerfile o bien sea una de las variables estándar.
 <code bash>docker build --build-arg some_variable_name=a_value</code> <code bash>docker build --build-arg some_variable_name=a_value</code>
  
Line 457: Line 471:
  
 ===== Tipos de redes en Docker ===== ===== Tipos de redes en Docker =====
 +
 +Por defecto, todas las instalaciones de Docker vienen con tres redes creadas por defecto, bridge, host y none.
  
 **bridge**: Si no especifica un controlador, la red predeterminada bridge es el tipo de red usado. Las redes puente se utilizan normalmente cuando sus aplicaciones se ejecutan en contenedores independientes que necesitan comunicarse. Son las recomendadas cuando se necesita que varios contenedores se comuniquen en el mismo host Docker. Por defecto en entornos Docker siempre hay una red bridge considerada la predeterminada.Esta red bridge predeterminada no tiene tantas opciones como las redes bridge creadas explícitamente por el usuario, las cuales disfrutan de resolución DNS, conexión / desconexión a otras redes en caliente y otra serie de ventajas. Para eliminar un contenedor de la red puente predeterminada, es necesario detener el contenedor y volver a crearlo con diferentes opciones de red. La configuración de la red puente por defecto ocurre fuera de Docker mismo, y requiere un reinicio del servicio. **bridge**: Si no especifica un controlador, la red predeterminada bridge es el tipo de red usado. Las redes puente se utilizan normalmente cuando sus aplicaciones se ejecutan en contenedores independientes que necesitan comunicarse. Son las recomendadas cuando se necesita que varios contenedores se comuniquen en el mismo host Docker. Por defecto en entornos Docker siempre hay una red bridge considerada la predeterminada.Esta red bridge predeterminada no tiene tantas opciones como las redes bridge creadas explícitamente por el usuario, las cuales disfrutan de resolución DNS, conexión / desconexión a otras redes en caliente y otra serie de ventajas. Para eliminar un contenedor de la red puente predeterminada, es necesario detener el contenedor y volver a crearlo con diferentes opciones de red. La configuración de la red puente por defecto ocurre fuera de Docker mismo, y requiere un reinicio del servicio.
Line 464: Line 480:
 **overlay**: Las redes superpuestas (overlay) conectan varios demonios Docker juntos y permiten que los servicios del enjambre se comuniquen entre sí. También puede utilizar las redes superpuestas para facilitar la comunicación entre un servicio de enjambre y un contenedor autónomo, o entre dos contenedores autónomos en diferentes daemons Docker. Esta estrategia elimina la necesidad de realizar un enrutamiento a nivel de sistema operativo entre estos contenedores. **overlay**: Las redes superpuestas (overlay) conectan varios demonios Docker juntos y permiten que los servicios del enjambre se comuniquen entre sí. También puede utilizar las redes superpuestas para facilitar la comunicación entre un servicio de enjambre y un contenedor autónomo, o entre dos contenedores autónomos en diferentes daemons Docker. Esta estrategia elimina la necesidad de realizar un enrutamiento a nivel de sistema operativo entre estos contenedores.
  
-**macvlan**: Este tipo de redes permiten asignar una dirección MAC a un contenedor, haciéndolo aparecer como un dispositivo físico en su red. El demonio Docker enruta el tráfico a los contenedores por sus direcciones MAC. El uso del controlador macvlan es a veces la mejor opción cuando se trata de aplicaciones heredadas que esperan estar directamente conectadas a la red física, en lugar de ser enrutadas a través de la pila de red del host. Son las recomendadas cunado se necesita que los contenedores parezcan hosts físicos en la red, cada uno con una dirección MAC única.+**macvlan**: Este tipo de redes permiten asignar una dirección MAC a un contenedor, haciéndolo aparecer como un dispositivo físico en su red. Se usan para comunicar el mundo docker con cualquier otra red / dispositivo externo, por ejemplo que los contenedores estén dentro de la misma red que el host. El demonio Docker enruta el tráfico a los contenedores por sus direcciones MAC. El uso del controlador macvlan es a veces la mejor opción cuando se trata de aplicaciones heredadas que esperan estar directamente conectadas a la red física, en lugar de ser enrutadas a través de la pila de red del host. Son las recomendadas cunado se necesita que los contenedores parezcan hosts físicos en la red, cada uno con una dirección MAC única. Para que este tipo de redes funcione necesitamos que la tarjeta de red del host esté en modo promiscuo,
  
-**ninguno**:Desactiva todas las redes en el contenedor. Normalmente se utiliza junto con un controlador de red personalizado. none no está disponible para los servicios de enjambre..+**ninguno**:Desactiva todas las redes en el contenedor, los contenedores no tendrá interfaz de red, solo loopback. Normalmente se utiliza junto con un controlador de red personalizado. none no está disponible para los servicios de enjambre.
  
 **Plugins de red**: Los complementos de red de terceros permiten integrar Docker con pilas de red especializadas. Puedes instalar y utilizar plugins de red de terceros con Docker. Estos plugins están disponibles en Docker Hub o en proveedores de terceros. **Plugins de red**: Los complementos de red de terceros permiten integrar Docker con pilas de red especializadas. Puedes instalar y utilizar plugins de red de terceros con Docker. Estos plugins están disponibles en Docker Hub o en proveedores de terceros.
Line 485: Line 501:
  
  
-**Entendiendo la red bridge y su relación con las interfaces del host**+**Entendiendo el funcionamiento de la red bridge y su relación con las interfaces del host**
  
 La interfaz docker0 hace referencia a esa red puente predeterminada de la que se hablo anteriormente. Cada contenedor tiene una interfaz que se conectada a esa red y es por tanto accesible desde el host en el que se ejecuta el contenedor. El contenedor o contenedores usan dicha interfaz docker0 como ruta predeterminada para salir a internet. Veamos un ejemplo práctico para entender mejor como funciona. La interfaz docker0 hace referencia a esa red puente predeterminada de la que se hablo anteriormente. Cada contenedor tiene una interfaz que se conectada a esa red y es por tanto accesible desde el host en el que se ejecuta el contenedor. El contenedor o contenedores usan dicha interfaz docker0 como ruta predeterminada para salir a internet. Veamos un ejemplo práctico para entender mejor como funciona.
Line 502: Line 518:
        valid_lft forever preferred_lft forever        valid_lft forever preferred_lft forever
  
 +# La puerta de enlace predeterminada del contenedor coincidirá con la IP que tiene la interfaz puente docker0.
 / # ip route / # ip route
-default via 172.31.0.1 dev eth0    <----- Coincidirá con la IP que tiene la interfaz puente docker0.+default via 172.31.0.1 dev eth0    
 172.31.0.0/24 dev eth0 scope link  src 172.31.0.2 172.31.0.0/24 dev eth0 scope link  src 172.31.0.2
  
  
 # Sobre el mismo host donde corre el contenedor creado anteriormente se visualizan los espacios de nombres de red. # Sobre el mismo host donde corre el contenedor creado anteriormente se visualizan los espacios de nombres de red.
 +# El espacio cd13b758f285 se creó al momento de crear el contenedor.
 cd /var/run cd /var/run
 ln -s /var/run/docker/netns netns ln -s /var/run/docker/netns netns
 ip netns ip netns
  
-cd13b758f285 (id: 0) <------ Este espacio se creó al momento de crear el contenedor.+cd13b758f285 (id: 0) 
 default default
  
  
-# Se consulta la configuración de interfaces del espacio de red que está usando el contenedor: cd13b758f285. Como se puede apreciar es la misma salida que al ejecutar ip addr sobre el contenedor.+# Se consulta la configuración de interfaces del espacio de red que está usando el contenedor: cd13b758f285.  
 +# Como se puede apreciar es la misma salida que al ejecutar ip addr sobre el contenedor.
 ip netns exec cd13b758f285 ip addr ip netns exec cd13b758f285 ip addr
  
Line 529: Line 548:
  
  
-# Se consultan las instancias de puentes en el host. En este caso el puente docker0 está conectado con la interfaz veth47cd93c+# Se consultan las instancias de puentes en el host. En este caso la interfaz puente docker0 está conectada con la interfaz virtual veth47cd93c.
 brctl show brctl show
  
 bridge name bridge id STP enabled interfaces bridge name bridge id STP enabled interfaces
-docker0 8000.0242cb1bbacf no veth47cd93c  <--- La interfaz puente docker0 está conectada a la interfaz virtual veth47cd93c.+docker0 8000.0242cb1bbacf no veth47cd93c  veth47cd93c.
  
  
Line 553: Line 572:
 15: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default  15: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
     link/ether 02:42:cb:1b:ba:cf brd ff:ff:ff:ff:ff:ff     link/ether 02:42:cb:1b:ba:cf brd ff:ff:ff:ff:ff:ff
-    inet 172.31.0.1/24 brd 172.31.0.255 scope global docker0    <---- Ruta predeterminada en el contenedor para salir a internet.+    inet 172.31.0.1/24 brd 172.31.0.255 scope global docker0
        valid_lft forever preferred_lft forever        valid_lft forever preferred_lft forever
     inet6 fe80::42:cbff:fe1b:bacf/64 scope link      inet6 fe80::42:cbff:fe1b:bacf/64 scope link 
        valid_lft forever preferred_lft forever        valid_lft forever preferred_lft forever
-68308: veth47cd93c@if68307: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default  <---- eth0 del contenedor.+68308: veth47cd93c@if68307: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
     link/ether 76:10:01:2f:12:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0     link/ether 76:10:01:2f:12:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
     inet6 fe80::7410:1ff:fe2f:128d/64 scope link      inet6 fe80::7410:1ff:fe2f:128d/64 scope link 
Line 567: Line 586:
 De no usarse la red puente predeterminada de Docker y haber creado redes puente explícitamente, la interfaz docker0 no se usaría, si no que se crearía una interfaz puente con nombre "br-xxxxx". Las redes virtuales veth siempre serían creadas ya que coincidirían con las interfaces de los contenedores creados en dicha red, las cuales conectan a la interfaz puente "br-xxxxx". De no usarse la red puente predeterminada de Docker y haber creado redes puente explícitamente, la interfaz docker0 no se usaría, si no que se crearía una interfaz puente con nombre "br-xxxxx". Las redes virtuales veth siempre serían creadas ya que coincidirían con las interfaces de los contenedores creados en dicha red, las cuales conectan a la interfaz puente "br-xxxxx".
  
-Por lo tanto una red puente unicamente tendrá una interfaz "br-xxxx" en el host, pero el host tendrá tantas interfaces veth como contenedores se tengan en dicha red (suponiendo que solo tienen una interfaz).+Por lo tanto una red puente unicamente tendrá una interfaz "br-xxxx" en el host, pero el host tendrá tantas interfaces veth como contenedores se tengan en dicha red (suponiendo que solo tienen una interfaz). Las interfaces virtuales en el host, el espacio de red y la conexión con la interfaz puente docker0 o br-XXXXX desparecen cuando el contenedor deja de estar activo. 
 + 
 +===== SBOM de las imagenes de Docker ===== 
 + 
 +Una lista de materiales de software (SBOM) enumera todos los componentes que conforman un software (o que se utilizaron para construirlo). En el caso de imágenes de contenedores, esto incluye paquetes instalados (por ejemplo la bash, los certificados ca, git, etc) junto con sus dependencias, por ejemplo, Log4j. Cada herramienta SBOM puede incluir en su salida diferentes subconjuntos de esta información o incluso más detalles, como versiones de los componentes y su fuente. En Docker se puede usar el siguiente plugin para generar reportes [[https://github.com/docker/sbom-cli-plugin|sbom]], muy utiles a la hora de buscar aplicaciones vulnerables. Aunque si se quiere obtener más información se recomienda el uso de [[https://github.com/anchore/syft|syft]] directamente. 
 + 
 + 
 +<code bash>curl -sSfL https://raw.githubusercontent.com/docker/sbom-cli-plugin/main/install.sh | sh -s -- 
 +docker sbom  XXXX</code> 
 + 
 + 
 +Ejemplo. 
 +<code bash> 
 +docker sbom zricethezav/gitleaks 
 +Syft v0.43.0 
 + ✔ Loaded image             
 + ✔ Parsed image             
 + ✔ Cataloged packages      [49 packages] 
 +NAME                                VERSION                             TYPE       
 +alpine-baselayout                   3.2.0-r16                           apk         
 +alpine-keys                         2.3-r1                              apk         
 +apk-tools                           2.12.7-r0                           apk         
 +bash                                5.1.4-r0                            apk         
 +brotli-libs                         1.0.9-r5                            apk         
 +busybox                             1.33.1-r3                           apk         
 +ca-certificates                     20191127-r5                         apk         
 +ca-certificates-bundle              20191127-r5                         apk         
 +expat                               2.4.1-r0                            apk         
 +git                                 2.32.0-r0                           apk         
 +github.com/fsnotify/fsnotify        v1.4.9                              go-module   
 +github.com/gitleaks/go-gitdiff      v0.7.4                              go-module   
 +github.com/hashicorp/hcl            v1.0.0                              go-module   
 +github.com/magiconair/properties    v1.8.5                              go-module   
 +</code> 
 + 
 +Usando diferentes opciones de formato de salida se puede obtener más información, por ejemplo nombre, licencia, referencias externas, autor, etc. 
 +<code bash> 
 +docker sbom --format spdx zricethezav/gitleaks 
 +Syft v0.43.0 
 + ✔ Loaded image             
 + ✔ Parsed image             
 + ✔ Cataloged packages      [49 packages] 
 +SPDXVersion: SPDX-2.2 
 +DataLicense: CC0-1.0 
 +SPDXID: SPDXRef-DOCUMENT 
 +DocumentName: zricethezav/gitleaks-latest 
 +DocumentNamespace: https://anchore.com/syft/image/zricethezav/gitleaks-latest-cafe4ad2-56b1-4618-8193-3c159f5832de 
 +LicenseListVersion: 3.16 
 +Creator: Organization: Anchore, Inc 
 +Creator: Tool: syft-[not provided] 
 +Created: 2022-04-20T08:48:22Z 
 + 
 +##### Package: alpine-baselayout 
 + 
 +PackageName: alpine-baselayout 
 +SPDXID: SPDXRef-Package-apk-alpine-baselayout-ed18f2a986e77aab 
 +PackageVersion: 3.2.0-r16 
 +PackageDownloadLocation: NOASSERTION 
 +FilesAnalyzed: false 
 +PackageLicenseConcluded: GPL-2.0-only 
 +PackageLicenseDeclared: GPL-2.0-only 
 +PackageCopyrightText: NOASSERTION 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine_baselayout:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine_baselayout:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:* 
 +ExternalRef: PACKAGE_MANAGER purl pkg:alpine/alpine-baselayout@3.2.0-r16?arch=x86_64&upstream=alpine-baselayout&distro=alpine-3.14.2 
 +...</code>
guia_rapida_de_la_linea_de_comandos_de_docker.1621034619.txt.gz · Last modified: 2021/05/15 01:23 by busindre