Networking 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.

Ver IP pública que estamos usando

joaquinjimenezgarcia — Tue, 23 Jan 2024 10:19:32 +0000

A menudo nos podemos encontrar con el problema de querer saber cuál es nuestra IP pública, ya que es un dato que no nos devolverá el comando ifconfig.

Para lograr saber cuál es, haremos uso del comando dig

Dig (domain information groper) es una herramienta flexible para interrogar servicios de DNS. Este lleva a cabo búsquedas de DNS y muestra las respuestas devueltas por el servidor.

En este caso utilizaremos el servidor de resolver1.opendns.com para averiguar cuál es la IP desde la que hacemos la petición. También especificaremos con +short que estamos esperando una respuesta breve; ya que no nos interesa datos de tiempo ni de consulta, solamente nuestra IP:

dig +short myip.opendns.com @resolver1.opendns.com

Guardar la IP en una variable de entorno.

En el caso de que estemos trabajando con el entorno y necesitemos tener la IP seteada para poder utilizarla como variable sin tener que estar usando el comando anterior, podríamos guardarla para usarla múltiple veces luego.

myip="$(dig +short myip.opendns.com @resolver1.opendns.com)"
echo "My WAN/Public IP address: ${myip}"

Si quieres saber más sobre el comando, no dudes en consultar la documentación oficial.

La entrada Ver IP pública que estamos usando se publicó primero en CloudArch.

Comprobar conexiones remotas con Netcat

joaquinjimenezgarcia — Mon, 22 Jan 2024 19:48:07 +0000

Netcat es un comando disponible en todas las plataformas (Windows, Linux y MacOS) con el que podremos establecer conexiones entre dos máquinas, tras especificar una IP y un puerto.

Gracias a Netcat podremos comprobar si nuestro host A tiene acceso al host B antes de empezar a desplegar nuestros servicios, de forma que podamos solicitar al equipo de administración que habilite puertos o escriba las reglas de firewall necesarias para realizar nuestras tareas. En esta sencilla práctica vamos a utilizar el comando nc (que proviene de “netcat”) en dos máquinas diferentes para realizar dos tareas:

Host A: Obtendrá un puerto escuchando.
Host B: Enviará un requesto al host A en el puerto recién abierto.

Abriendo el puerto a escuchar en nuestra máquina A

Para ello vamos a utilizar el comando nc ya mencionado anteriormente, pero con dos opciones diferentes: -v para añadir más verbosidad y -l para indicar que vamos a configurar el puerto para escuchar conexiones entrantes.

La utilización de este comando sería: comando + opciones + IP desde la que admitiremos conexiones + puerto que queremos abrir. Para este caso, la IP será 0.0.0.0 ya que eso admitirá cualquier IP, pero no es buena práctica. Si vamos a hacer esto en entornos de producción se recomienda escuchar solamente la IP deseada.

En conclusión, este comando pone a escuchar el puerto X para los conexiones entrantes desde la IP Y.

Podemos ejecutarlo del siguiente modo:

nc -lv 0.0.0.0 445

P.D: En este caso permitimos todas las conexiones entrantes desde cualquier IP al puerto 445.

Conectar con el puerto remoto desde la máquina B

En este caso usaremos las opciones -z (que dirá a netcat que vamos a escanear un puerto) y -w (que indicará un timeout para no tener el servicio itentando conectar indefinidamente).

La utilización en este caso sería: comando + opciones + IP de destino + puerto de destino. Y podemos ejecutarlo del siguiente modo:

nc -zvw 3 192.168.1.110 445

P.D: Esta vez hemos supuesto que la IP de la máquina A era 192.168.1.110 y que el puerto abierto era el 445.

Resumen

Primero debemos de abrir el puerto en la máquina A, pero si obtenemos un error puede que sea que ese puerto ya esté en uso. Para comprobar esto, podemos usar el comando lsof -i -P -n | grep LISTEN y ver si efectivamente dicho puerto ya está en uso.

En el caso de haber abierto el puerto correctamente, si luego no tenemos acceso desde la máquina B puede deberse a un error de red, y que no tengamos acceso a la máquina A. Para comprobar esto, podríamos hacer uso del comando ping seguido de la IP deseada (ej: ping 192.168.1.110 y comprobar si efectivmamente tenemos o no acceso).

Si quieres saber más sobre el comando, no dudes en consultar la documentación oficial.

También puedes ver el video demo de este artículo en mi canal de YouTube.

La entrada Comprobar conexiones remotas con Netcat se publicó primero en CloudArch.