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/03 22:43] – [Tipos de redes en Docker] 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 458: Line 472:
 ===== Tipos de redes en Docker ===== ===== Tipos de redes en Docker =====
  
-**bridge**: Si no especifica un controlador, este es el tipo de red que está creando. 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, 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.
  
 **host**: En el caso de los contenedores autónomos, elimina el aislamiento de red entre el contenedor y el host Docker, y utiliza la red del host directamente. Se recomienda su uso cuando la pila de red no debe estar aislada del host Docker, pero se quiere que otros aspectos del contenedor estén aislados. **host**: En el caso de los contenedores autónomos, elimina el aislamiento de red entre el contenedor y el host Docker, y utiliza la red del host directamente. Se recomienda su uso cuando la pila de red no debe estar aislada del host Docker, pero se quiere que otros aspectos del contenedor estén aislados.
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 483: Line 499:
                                  # Sí se muestran la IP de los nodos (Peers) que implementan dicha red.                                  # Sí se muestran la IP de los nodos (Peers) que implementan dicha red.
 </code> </code>
 +
 +
 +**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.
 +
 +<code bash>
 +# Se crea un contenedor y se consultan sus interfaces: eth0@if68308 coincidirá con alguna interfaz de red creada en el host.
 +docker run -it alpine sh
 +/ # ip addr
 +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +       valid_lft forever preferred_lft forever
 +68307: eth0@if68308: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
 +    link/ether 02:42:ac:1f:00:02 brd ff:ff:ff:ff:ff:ff
 +    inet 172.31.0.2/24 brd 172.31.0.255 scope global eth0
 +       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
 +default via 172.31.0.1 dev eth0    
 +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.
 +# El espacio cd13b758f285 se creó al momento de crear el contenedor.
 +cd /var/run
 +ln -s /var/run/docker/netns netns
 +ip netns
 +
 +cd13b758f285 (id: 0) 
 +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.
 +ip netns exec cd13b758f285 ip addr
 +
 + 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +       valid_lft forever preferred_lft forever
 +68307: eth0@if68308: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
 +    link/ether 02:42:ac:1f:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
 +    inet 172.31.0.2/24 brd 172.31.0.255 scope global eth0
 +       valid_lft forever preferred_lft forever
 +
 +
 +# 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
 +
 +bridge name bridge id STP enabled interfaces
 +docker0 8000.0242cb1bbacf no veth47cd93c  veth47cd93c.
 +
 +
 +# Se consulta las interfaces e IPs del host para poder ver la relación entre la nueva interfaz virtual veth47cd93c y la interfaz eth0 del contenedor.
 +ip addr
 +
 +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +       valid_lft forever preferred_lft forever
 +    inet6 ::1/128 scope host 
 +       valid_lft forever preferred_lft forever
 +2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
 +    link/ether 00:50:56:af:69:96 brd ff:ff:ff:ff:ff:ff
 +    inet 10.0.201.26/21 brd 10.0.207.255 scope global ens160
 +       valid_lft forever preferred_lft forever
 +    inet6 fe80::250:56ff:feaf:6996/64 scope link 
 +       valid_lft forever preferred_lft forever
 +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
 +    inet 172.31.0.1/24 brd 172.31.0.255 scope global docker0
 +       valid_lft forever preferred_lft forever
 +    inet6 fe80::42:cbff:fe1b:bacf/64 scope link 
 +       valid_lft forever preferred_lft forever
 +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
 +    inet6 fe80::7410:1ff:fe2f:128d/64 scope link 
 +       valid_lft forever preferred_lft forever
 +</code>
 +
 +La interfaz eth0@if68308, del contenedor se refiere a la interfaz virtual del host veth47cd93c@if68307, la cual fue creada al arrancar el contenedor en la red predeterminada. A su vez, como vimos con el comando brctl, está conectada a la interfaz bridge docker0 para poder comunicarse con el host y salir a internet.
 +
 +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). 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.1620074636.txt.gz · Last modified: 2021/05/03 22:43 by busindre