Storage archivos - CloudArch

Make our Docker images lighter

joaquinjimenezgarcia — Sun, 18 Aug 2024 10:12:59 +0000

Frequently, after we create our Docker image using Dockerfile, we get images heavier than we expected and this ends with fulling our file system and storage. So, how can we make our Docker containers images lighter?

We are not going to define and talk about what exactly are the layers but as a very basic notion, Docker images are built by layers and these layers are the instructions written in the Docker file. Every instruction (line in a Dockerfile) is a layer and it has some weight depending on what’s doing.

# One layer, which also contains layers since it's an image
FROM docker.io/fedora
# Another layer
RUN dnf install -y httpd
# Another layer
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

Layers are immutable and additive, meaning that once a Layer has done its job, it cannot be deleted or modified.

The main goal here would be to use a very minimal base image, that only contains what we need. Nothing else. Usually you won’t find a base image that contains everything, so probably you may end up by adding some extra layers like installing some packages like in the previous example.

Optimizing the layers to make our Docker images lighter

If we build the previous image, we would see how Docker is building layer by layer and storing in into the cache for its previous usage.

terrorsys@Andromeda:~/TestLayers$ docker build -t testlayers .
[+] Building 39.3s (6/6) FINISHED                                                         docker:default
 => [internal] load build definition from Dockerfile                                                0.0s
 => => transferring dockerfile: 124B                                                                0.0s
 => [internal] load metadata for docker.io/library/fedora:latest                                    3.2s
 => [internal] load .dockerignore                                                                   0.0s
 => => transferring context: 2B                                                                     0.0s
 => [1/2] FROM docker.io/library/fedora:latest@sha256:5ce8497aeea599bf6b54ab3979133923d82aaa4f6ca5  4.7s
 => => resolve docker.io/library/fedora:latest@sha256:5ce8497aeea599bf6b54ab3979133923d82aaa4f6ca5  0.0s
 => => sha256:5e22da79803c567fceb0e255f1168977259525a4279cb518016a60df025412fb 2.00kB / 2.00kB      0.0s
 => => sha256:d4df0db66c89d7e6225ce9d3597a045fb95c020f3174af1830df88a37a871db8 80.12MB / 80.12MB    3.7s
 => => sha256:5ce8497aeea599bf6b54ab3979133923d82aaa4f6ca5ced1812611b197c79eb0 1.25kB / 1.25kB      0.0s
 => => sha256:a0f4dffd30e0af6e53f57533e79a9e32699d37d8e850132ff89f612d6ea8a300 529B / 529B          0.0s
 => => extracting sha256:d4df0db66c89d7e6225ce9d3597a045fb95c020f3174af1830df88a37a871db8           1.0s
 => [2/2] RUN dnf install -y httpd                                                                 30.5s
 => exporting to image                                                                              0.7s
 => => exporting layers                                                                             0.7s
 => => writing image sha256:28bff713c5bc28c097fbae424ce9f4bb87226596736f04f7eb215aa92dbb4078        0.0s 
 => => naming to docker.io/library/testlayers                                                       0.0s

Finally we can see how the image is built and inspect the layers to see their weight.

terrorsys@Andromeda:~/TestLayers$ docker images | grep testlayer
testlayers                    latest    28bff713c5bc   8 seconds ago    386MB


terrorsys@Andromeda:~/TestLayers$ docker image history testlayers
IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
28bff713c5bc   16 seconds ago   CMD ["/usr/sbin/httpd" "-DFOREGROUND"]          0B        buildkit.dockerfile.v0
      16 seconds ago   RUN /bin/sh -c dnf install -y httpd # buildk…   164MB     buildkit.dockerfile.v0
      3 months ago     /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B        
      3 months ago     /bin/sh -c #(nop) ADD file:b8701dca3d7c8dad1…   222MB     
      11 months ago    /bin/sh -c #(nop)  ENV DISTTAG=f40container …   0B        
      3 years ago      /bin/sh -c #(nop)  LABEL maintainer=Clement …   0B

Basically, we can see there layers coming from the base image, and the layers we added. But how about if we decrease the size of it to make the image lighter?

As we can see, since we are using “dnf install”, we are also caching so many other data we don’t really need. Accordingly on Fedora configuration, we can simply remove it by running “dnf clean all”.

However, as we saw recently, layers are additive and immutable, meaning that once the layer has been written and cached, we cannot modify it. It won’t matter if we add a new layer with that step, it won’t make any change.

Nevertheless, we can squash these three steps in an unique layer, so when the step finishes and save on cache, the size will be much lower. We can do that by modifying our Dockerfile.

FROM docker.io/fedora
RUN dnf install -y httpd && \
        dnf clean all
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

Basically we can use “&&” to say “run this second command only if the first one was successfully done” and then by “\” we indicate a line jump, just to see our Dockerfile much more clear.

Once we have created again our image, we can see now that the size it’s 303 MB instead of 386 MB and the layer went from 164 MB to 81.3 MB. This may not seem like a huge improvement but take into consideration this two scenarios:

If we have multiple layers and we clean all of them, the final result will be a much lighter image. In a production environment where we cannot add space as we need, this is crucial if we multiply this for many different images. We can save our disk.
In environments where the network is congested, we need to reduce the size of our objects to allow a faster traffic.

Using the right base image

Another point here is the base image we are using to create our own. This one runs a Fedora-based image. But since we only want to run Apache, we can find in the Docker registry another lighter base image which already contains Apache: https://hub.docker.com/r/nimmis/alpine-apache This image for example is an Alpine (much lighter than Fedora) which already has the desired package.

So our Dockerfile would look like the following:

FROM nimmis/alpine-apache
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

Once we compiled it, we can see that the size of our image went from 303 MB to only 20.7 MB. This is much lighter size, which will improve our disk usage and network traffic to pull/push images. It’s ideal for production environments or other critical environments where we prioritize network and disk.

terrorsys@Andromeda:~/TestLayers$ docker images | grep testlayer
testlayers                    latest    311bb5eeeb68   2 years ago    20.7MB

If you liked this post, don’t forget to comment and read other posts regarding Docker.

La entrada Make our Docker images lighter se publicó primero en CloudArch.

Qué tipo de disco usar en GCP

joaquinjimenezgarcia — Tue, 23 Jan 2024 10:22:17 +0000

Cuando estamos diseñando la arquitectura de nuestros servicios en la nube, a menudo podemos encontrarnos con la pregunta de qué tipo de disco o almacenamiento usar. Google Cloud (GCP) nos ofrece diferente tipos dependiendo de nuestras necesidades. Es muy importante analizarlo y escoger el correcto, para evitar gastos innecesarios, pérdidas de datos y otros problemas relacionados con un mal almacenamiento.

Almacenamiento en Disco Persistente

Puede adjuntar bloques de almacenamiento HDD o SDD a instancias individuales de Compute Engine.
Dos características interesantes del almacenamiento en disco persistente son: Escalabilidad sin tiempo de inactividad. Cifrado automático.
Obtiene la tranquilidad de saber que sus datos están seguros en reposo, y puede agregar fácilmente más almacenamiento, si es necesario, sin interrumpir nada.

SSD Locales en GCP

Los SSD locales están conectados de manera física al servidor que aloja tu instancia de VM. Este acoplamiento alto ofrece un rendimiento superior, operaciones muy grandes de entrada y salida por segundo (IOPS) y una latencia muy baja en comparación con otras opciones de almacenamiento en bloque.

Los SSD locales se diseñaron para casos de uso de almacenamiento temporal, como almacenamiento en caché o espacio provisorio para el procesamiento. Por eso, son ideales para cargas de trabajo como renderización de contenido multimedia, análisis de datos o computación de alto rendimiento.

Es un almacenamiento efímero pero de muy alto rendimiento. En esta opción los datos siempre permanecen encriptados mediante una clave de cifrado efímera y solamente son los SSDs quiénes manejan y protegen las claves a nivel de dispositivo.

Cloud Storage

Almacenamiento en objetos para empresas de todos los tamaños. Almacena cualquier cantidad de datos y puedes recuperarlos las veces que quieras. Equivalente al S3 que ofrece AWS.

Se pueden almacenar los datos con varias opciones de redundancia, se puede personalizar dónde y cómo quieres almacenar tus datos.

Estos funcionan como buckets que se pueden crear desde la consola de GCP o desde la línea de comandos.

Se ofrecen diferentes clases de almacenamiento:

Standard Storage: ideal para datos activos a los que se accede con frecuencia.
Nearline Storage: de bajo costo e ideal para datos que se pueden almacenar por lo menos por 30 días, como copias de seguridad de datos y contenido multimedia.
Coldline Storage: almacenamiento de muy bajo costo e ideal para datos que se pueden almacenar por al menos 90 días como una recuperación de desastre, se podría comparar con la clase de almacenamiento Glacer de AWS.
Archive Storage: es el almacenamiento con costo más bajo en el que los datos tienen que estar al menos 1 año y sirve para guardar datos y conservación digital cuándo no se accede mucho a ellos.

Además ofrece todo tipo de configuración de seguridad; se puede integrar con las aplicaciones, se pueden crear de modo público, se pueden crear reglas complejas, etc.

Cloud Filestore

Este es un almacenamiento de archivos completamente administrado y de alto rendimiento.

Este es un tipo de almacenamiento conectado a la red (NAS).
Totalmente gestionado para instancias de Compute Engine y GKE.
Lo fundamental a considerar aquí es la latencia.
Filestore ofrece dos niveles de rendimiento distintos: Standard (HDD) Premium (SSD)
El nivel premium ofrece un rendimiento de lectura/escritura sustancialmente mayor.
Admite hasta 320TB de capacidad.

Cloud Storage para Firebase

Cloud Storage para Firebase es un servicio de almacenamiento de objetos potente, simple y rentable construido para el escalamiento de Google. Los SDKs de Firebase para Cloud Storage agregan la seguridad de Google a las operaciones de carga y descarga de archivos de tus apps de Firebase, sin importar la calidad de la red.

Cloud Storage para Firebase almacena tus archivos en un bucket de Google Cloud Storage y los hace accesibles a través de Firebase y Google Cloud, lo cual brinda flexibilidad para subir y descargar archivos a clientes móviles a través de los SDKs de Firebase para Cloud Storage.

Servicio de transferencia de almacenamiento a GCP

Servicios seguros y de bajo costo para transferir datos desde fuentes locales o en la nube de estos proveedores como AWS o Azure.

En el Servicio de transferencia de almacenamiento es posible importar datos en línea con rapidez en Cloud Storage desde otras fuentes externas a Google Cloud. También puedes configurar un programa de repetición para la transferencia de datos, además de transferir datos de un bucket a otro dentro de Cloud Storage. Te permite mover grandes cantidades de datos periódicamente como parte de una canalización de procesamiento de datos o de un flujo de trabajo analítico. El servicio de transferencia de almacenamiento proporciona opciones que facilitan la transferencia y sincronización de datos.

Si quieres leer más acerca de los tipos de discos, visita la documentación oficial en https://cloud.google.com/storage

Para más artículos relacionados con GCP, visita todos los posts de este apartado en nuestro blog GCP

La entrada Qué tipo de disco usar en GCP se publicó primero en CloudArch.