Zip and remove folder to reduce a Docker layer of a Dockerfile

Considering I have a huge Docker Image and that I don't have the time to dig into all the best Docker pratices for image reduction techniques and that I am aware of the specifically huge part of the Docker image.

I wanted to zip the huge folder, delete original folder and simply unzip the folder when the image boot.

...
RUN cd /mypath/ && <COMMAND_THAT_GENERATE_HUGE_DIR_BOB> && zip -r bob.zip bob &&  rm -rd bob
...

In some way this is working since my bob.zip is about 60% of the original bob dir. However, probably due to the way Docker handles layer in the background. Even tough bob.zip is smaller, the docker layer appears to be:

(bob.zip size) + (original bob dir size)

instead of simply:`

(bob.zip size)

Is there a flag or something I can use to get the expected layer size?

A Dockerfile RUN line always makes the image larger. A Docker image is built from layers, and what a RUN line does is start from a previous layer, run a command, and remember the filesystem changes as a new layer. As an extreme example, RUN rm -rf / will actually result in an image somewhat larger than the preceding step, even though there are no files left in the image.

You hint at a multi-stage build and that's one valid approach here. The important thing is to compress the data in a separate stage from the final runtime stage:

FROM ubuntu AS data
# RUN apt-get update && apt-get install ...
WORKDIR /app
COPY ./ ./
RUN ./command_that_generate_huge_dir_bob
RUN zip -r bob.zip bob  # I might use `tar czf bob.tar.gz bob`

FROM ...
...
COPY --from=data /app/bob.zip ./
...

The important detail here is that the uncompressed data never actually exists in the final image; you're only copying in the zipped file.

The approach you show in the question of generating the data, compressing it, and then deleting the raw data all inside a single RUN command should work as well, though it can be a little more finicky.

If you do COPY in the entire host directory tree (as I've done in this example) one thing to check is that this isn't accidentally including a copy of the uncompressed data. You can include the data directory in a .dockerignore file to ensure this.

If this data really is static data, one other option is to supply it to the container at run time. I've used this approach in the past with a very large NLP model that simply didn't fit in an image. This makes distributing and deploying the application more complex, but it does make the image size more reasonable (I've found a practical limit for an image is about 1 GB, otherwise things like docker pull start spontaneously failing). Make sure your image doesn't contain the data directory at all, then bind-mount it when you run the container

# on the host
./command_that_generate_huge_dir_bob
docker run ... -v "$PWD/bob:/app/bob" ...