Containerfile example

[VictoriaSexmer1]

I need to change a containerfile just to create a new-app. This containerfile is based in a Http Apache server. I know there is a example here (https://rol.redhat.com/rol/app/courses/do288-4.10/pages/ch02s04)

But i need more examples. Can anybody help me, please?

[Travis · Accepted solution]

@VictoriaSexmer1 -

I don't have a ton of containerfile examples for the DO288 course, but I do have some I can provide to you. You might need to rename the Dockerfile to Containerfile, but keep in mind those are the same things. Hope the examples attached here as Github links help. Keep in mind, containers on OCP are different as the SCCs can cause issues with containers and root users, so you need to make adjustments for containers that run rootless on OCP.

https://github.com/tmichett/AnsibleContainer

https://github.com/tmichett/OCP_Demos/tree/main/DO188_Containerfile

https://github.com/tmichett/OCP_Demos/tree/main

https://github.com/tmichett/DO188_Demo/tree/main/Demos/CH4 (These are probably the best examples).

[VictoriaSexmer1]

Hi Travis

I'm trying to understand how many layers have been created with your Containerfile 'Demos/CH4/OCP_ADV_Containerfile/Containerfile'. I think the number is 8, but I already built the container image with podman build, and when I inspected the number of layers created, I saw it was just 2. Can you explain why, please?

Thanks a lot

[Travis]

@VictoriaSexmer1 -

Can you provide the build command you used with Podman to build the container? This might give some insight to things.

$ podman build --help | grep squash
--squash squash newly built layers into a single new layer
--squash-all Squash all layers into a single layer

Things like squash can flatten container images into a single layer, so the build process is just as important as the containerfile itself.

[VictoriaSexmer1]

 Hi Travis

I use this command to build the container image:

$ podman build image_name --layers=false --format=docker .

I need to modify the Containerfile to obtain an image with a reduced number of layers, specifically just 7. I’m trying to understand how the number of layers is created with different Containerfiles and how to change them to obtain an image with only 7 layers. I already know I can join similar instructions (like RUN, ADD, etc.) with && \. Do you know another tricks?

Thanks for your help!

[Travis]

@VictoriaSexmer1 -

I'm not sure how I can explain things differently, but I will try and I will also share a few links I have with students in the past. I'm also not sure why you are insisting on having specifically 7 layers in the image. One thing you could do, but I don't know why is to have a flat container image, then use it to build a new image where you just add additional layers (with junk data) or just text so you have exactly seven layers, but not sure that would be very useful or have much of a point.

In general, guidance for images is to have a reduced number of layers to be more efficient and consise. So combining ADD commands (where you are adding files) or COPY commands (where you copy items) or RUN commands where you need to install software, build configurations, etc. makes sense.

When building images, you cannot use && with different upper-level containerfile instructions (COPY, RUN, ADD, USER, etc). Each upper-level instruction would be self-contained. Each line with an upper-level (containerfile) instruction that modifies the image would create a layer.

https://docs.docker.com/guides/docker-concepts/building-images/understanding-image-layers/

https://kenmuse.com/blog/understanding-container-image-layers/

https://kubebyexample.com/learning-paths/container-fundamentals/container-images/layers-repositories

https://kodekloud.com/blog/docker-image-layers/

Another thing to keep in mind is (since this is the DO288) we are talking about building container images for OpenShift (Kubernetes) and more advanced image building. In these instances, best practices dictate for compiling and building code, you generally want to have a builder image to build and compile your code, so this would be a multi-step/multi-build containerfile that would result in essentially some "throw-away" components (whatever happened in the build image that built/created/compiled your code) and then you would take those results and stuff them into a single layer of the actual desired production container image. This prevents unnecessary files and layers from entering into production container images and keeps compilers and code building tools out of the final image thereby reducing surface area of attack vectors by not having those packages and items present.

https://docs.docker.com/build/building/multi-stage/

https://docs.docker.com/guides/docker-concepts/building-images/multi-stage-builds/

https://overcast.blog/building-efficient-multi-stage-dockerfiles-for-production-055f34c4baed

https://medium.com/codex/a-guide-to-docker-multi-stage-builds-290ff7bd04ec

https://developers.redhat.com/articles/2023/05/17/build-lean-nodejs-container-images-ubi-and-podman#...

General Containerfile Doc: https://github.com/containers/common/blob/main/docs/Containerfile.5.md

The information above should provide more information and context around builds. Again, the DO188 we teach mainly about simple Containerfiles (Dockerfiles) on building simple images and understanding layers, but as you attempt to build more "production-ready" images (especially where code is being compiled) you should look into multi-stage builds where you end up with an optimized container image at the end of the build process with only the software needed to run your built and compiled application.

General rule of thumb ...

When installing packages and running things with the RUN command, if possible like with YUM do the cleanup and other commands on the same command line. That will create a single layer with only what you need. Alternatively, if it isn't combined with the && you end up with multiple RUN layers ... one where YUM installed all packages, but has the cache and temp files in it, and the next layer is actually removing those (so think image optimization - why have the junk in the first RUN layer when you can take all the items away).

Attempt to minimize the number of installed packages and files ... so if you are building or compiling an application, you should probably have a multi-stage file where it does the build and you just copy the needed assets in your final container image.

I suspect you are looking at an existing Containerfile and you were asked to reduce image layers to seven (7), so looking at that file, keep in mind you can only combine top-level directives RUN with multiple commands and stuff and you cannot use && to combine things like RUN and ADD. Again here, depending on what is happening, you might also need to break the Containerfile up into stages where you get a build image and then a production image.