User Tools

Site Tools


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/22 17:29] 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 573: Line 587:
  
 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. 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.1621697342.txt.gz · Last modified: 2021/05/22 17:29 by busindre