Cómo crear una imagen base segura de Docker
Cuando utilicé Docker por primera vez, todo el mundo hablaba de lo fácil que era de usar, de lo bueno que era su mecanismo interno y de cuánto tiempo nos ahorraba. Pero tan pronto como lo usé, descubrí que casi todas las imágenes estaban infladas y eran inseguras (sin usar firmas de paquetes, confiar ciegamente en la biblioteca de imágenes ascendente es
| sh & lt/code & gt; y, ningún espejo puede realizar la intención original de Docker: aislamiento, proceso único, fácil distribución, simplicidad.
La imagen de Docker no fue diseñada originalmente para reemplazar máquinas virtuales complejas. Tiene registro, monitoreo, alarmas y administración de recursos completos. módulos . Por otro lado, Docker tiende a explotar el kernel
una vez que el kernel se inicializa en un entorno de máquina física
Es por eso que cuando revisa su lista de procesos ahora. Úsalo
¿Cómo empezar?
La mayoría de las aplicaciones actuales son sistemas grandes y complejos, que generalmente requieren muchas bibliotecas dependientes, como programación, compilación y muchas otras aplicaciones relacionadas. Su arquitectura suele estar bien encapsulada y los detalles subyacentes están ocultos en capas e interfaces abstractas. Hasta cierto punto, esto también es un contenedor, pero desde la perspectiva de la arquitectura del sistema, necesitamos una solución más simple que el entorno virtual anterior. >
Tome Java como ejemplo.
Empiece desde cero y piense en el contenedor básico más común que desea crear. Piense en su aplicación en sí, ¿qué necesita para ejecutarse? p>Hay muchas posibilidades. Si desea ejecutar una aplicación Java, necesita un tiempo de ejecución de Java. Si desea ejecutar una aplicación Rails, necesita un intérprete Ruby, y lo mismo ocurre con las aplicaciones Python y Go. Los lenguajes compilados son un poco diferentes, lo cual mencionaré a continuación.
En el ejemplo de Java, el siguiente paso es considerar: ¿Qué dependencias necesita el JRE para ejecutarse ya que es el más importante? componente para ejecutar la aplicación. El siguiente paso natural es descubrir de qué depende JRE.
De hecho, JRE no tiene mucha dependencia. Originalmente es una capa de abstracción del sistema operativo. código para ejecutarse independientemente del sistema host, por lo que instalar JRE está básicamente listo
(De hecho, la independencia del sistema operativo no se da por sentado. Hay muchas API específicas del sistema y extensiones de sistema patentadas. pero a modo de ejemplo, nos centraremos en la simplicidad)
En Linux, la JVM llama principalmente a la biblioteca de lenguaje C del sistema, y el JRE oficial de Oracle usa libc, lo que significa que si desea ejecutar alguna. Programa Java, primero debe instalar glibc. Además, es posible que necesite algún tipo de shell para administrar el entorno y tener una interfaz para comunicarse con el mundo exterior, como interfaces de red y de recursos. Resuma la configuración mínima requerida para el ejemplo de aplicación Java:
p>En el ejemplo, utilizamos Oracle JRE.
Dependencias de Glibc, JRE
Entorno básico (que incluye red, memoria, sistema de archivos y otras herramientas de administración de recursos)
#Into Alpine Linux ##
Alpine Linux ha recibido mucha atención recientemente, principalmente porque incluye una serie de dependencias probadas y confiables y aún mantiene un tamaño de 2 MB. Al momento de publicación de este artículo, otras distribuciones de imágenes son las siguientes:
Ubuntu: más reciente: 66 MB (mucho más delgada, algunas versiones anteriores superaban los 600 MB)
Debian: más reciente: 55 MB (igual que el anterior, tenía más de 200 MB al principio)
arch: Latest: 145 MB
Busybox: Latest: 676 KB (¡sí! KB, lo discutiré más adelante) )
Alpine: Último: 2 MB (2 MB, sistema Linux con herramienta de administración de paquetes)
** ¿Es Busybox el competidor más pequeño? **
Como se puede ver en la comparación anterior, lo único que puede vencer a Alpine Linux en términos de tamaño es Busybox, por lo que ahora casi todos los sistemas integrados lo usan y se aplica a enrutadores. interruptores, cajeros automáticos o su tostadora. Como entorno más básico, proporciona una interfaz de shell fácil de mantener.
Hay muchos artículos en línea que explican por qué la gente elige Alpine Linux en lugar de Busybox. Permítanme resumir aquí:
Repositorio de paquetes de software abierto y activo: Alpine
Linux utiliza la herramienta de gestión de paquetes apk, integrada en la imagen de Docker, mientras que Busybox necesita instalar otra herramienta de gestión de paquetes. Dispositivo, como opkg. Más importante aún, es necesario encontrar un suministro estable de bienes de almacén (casi no existe tal suministro). El repositorio de paquetes de Alpine proporciona una gran cantidad de paquetes de dependencia de uso común. Por ejemplo, si necesita compilar código como Nodejs o Ruby en el contenedor, puede ejecutar directamente el apk para agregar NodeJS y Ruby.
El tamaño sí importa, pero cuando lo comparas entre funcionalidad, flexibilidad, facilidad de uso y 1,5 MB, el tamaño es menos importante. Los paquetes añadidos en Alpine mejoran enormemente estos aspectos.
Amplio soporte: Docker ha contratado al autor de Alpine Linux para el mantenimiento y todas las imágenes oficiales en el futuro se crearán en base a Alpine Linux. No hay razón más convincente para usarlo en sus propios contenedores.
Yunxi cSphere ha sido consciente durante mucho tiempo del problema cada vez más grave de la duplicación, por lo que lanzó microespejos el año pasado para guiar a todos sobre cómo construir y comprender mejor los espejos. Una imagen es solo un formato de paquete de software.
* *Crea una imagen de entorno basada en Java* *
Como acabo de explicar, Alpine Linux es una buena opción a la hora de crear tus propias imágenes, así que la usaremos aquí. una imagen de Docker simple y eficiente. ¡Empecemos!
Combinación: alpine + bash
La primera instrucción de cada Dockerfile es especificar su contenedor padre, que en nuestro caso se suele utilizar para herencia
Sh
Desde los Alpes: lo último
Mantenido por docker@csphere.cn
También declaramos quién es el responsable de la imagen y que esta información es útil para cargar una Es necesaria la imagen en Docker Hub.
De esta forma tendrás una base para la siguiente operación.
A continuación, instale un shell de nuestra elección y agregue el siguiente comando:
Sh
Ejecute apk add-no-cache-update-cache bash
CMD [ " /bin/bash"]
El archivo acoplable final tiene este aspecto:
``Shh
Desde los Alpes: lo último
Mantenido por cSphere & ltdocker@csphere.cn & gt;
Ejecutar apk add-no-cache-update-cache bash
CMD ["/bin/bash"]
```
Bien, ahora construyamos el contenedor:
Sh
$ docker build-t my-Java-base-image .
Enviar contexto de compilación al demonio Docker 2.048 kB
Paso 1: Desde Alps: Último
->2314ad3eeb90
Segundo paso: CSP mantenedor aquí docker@csphere.cn
-& gt;Ejecutar en 63433312d77e
-& gt;bfe94713797a
Derribar el contenedor central 63433312d77e
...Omita algunas líneas
Paso 4: CMD /bin/bash
-& gt; ejecutar en d2291684b797
-> ecc443d68f27
Desarmar el contenedor intermedio d2291684b797
Construir ecc443d68f27 correctamente
y ejecutarlo:
Sh
p>$ docker run-RM-ti mi-imagen-base-Java
bash-4.3#