Containers Are Not VMs! Which Base Container (Docker) Images Should We Use? 

What do you use as base container images?

I surely would love to learn more about ephemeral containers :)

A demo on scratch image + ephemeral container to debug pod from scratch would be great. As tou proposed it 😊

I agree that many image come more bloated than they should, BUT scratch should be used with care. Scrtach images literally have nothing in them, but a lot of apps expects some things to exicts in certain places, and if they don't things tend to get wacky. Namely when you create a image from scrath you need to make sure that you have a valid /etc/passwd, a /tmp directory, a valid /etc/localtime and a ca-certificates (this one is only needed if you app make TLS connections, but most will). That's the bare minimum, on top of that you need to put all your app¡s dependecies. And you have to keep in mind that whatever your throw to your image, you have the sole resposability to keep it up-to-date, which can be no fun at all, and a lot of work. IMO the best you can do is just forget about all that and use Google's distroless. They have many flavours, do you have a statically linked app that have no depoendcies, not even libc? Use the static variant and you get basically what's an scratch image but with the must have that I commented earlier. What!? That you do need libc, and also libssl and openssl like 99.9% of the programs out there? Do not fret, just use the distrolless/base (or even /cc for libgcc support) mage and you are good to go (BTW, most of the time you should still use the "base" image for go apps, beacuase Go can use some libc functionality if present, giving slighly better performance and a behaviour more inline wiht the rest of apps). That you rather use Node or Java? Why of couse, just use the /nodexx or /javaxx images and you have everything you need. Python you say? Hmm, that's where it gets tricky, there is an /python3 image, you see. But I'm afraid that that's only experimental and using it on production is ill-advised. Ah, I must not forget to tell you that these images use glibc so no musl edgecases for you and if supply-chain security it's a must for you, you can easly check these images with cosing.

I'd definitely want to see a video on ephemeral containers!

Great content as always Viktor.I would really to get more insights into emphermal containers :)

A video on ephemeral containers would be great to see. Also, configuring k8s probes with scratch images in painful and we can't use alpine images in production.

Yes! Let's see more about ephemeral containers

I just cant appreciate you enough!

Universal Base Image (UBI) is a good choice if you like to go explore (free) mode then switch to enterprise mode with sla-backed support easily.

well, in Linux, Docker containers are not vms, in MacOS and Windows they are installed in a VM. sadly the industry has forgotten about chroot and vservers. and nixos does it better than docker, because all you need is the configuration file and your app, nothing more. Nixos can also use docker if you want to and it can create alpine images even smaller than with docker. I share this because well, is just amazingly productive and issue solver for my experience in the last 5 years of using docker in established teams.

Big Thank you @DevopsToolkit. I would love to see a demo on ephemeral containers. ❤

OMG, my head exploded. Where is your class to relearn all this stuff??? Good video, I would love to hear more!!!!

Ephemeral container attachment, plz!! Awesome video btw!

Yes, please create video about ephemeral containers.

Great insight for anyone who has drifted from the best practices. But most container based training videos don't focus on best practices either, as their objective to only successfully run their use cases limited to the video tutorials only. Having said that, how about a demo video on using scratch images for running binary application + ephemeral containers.

Debian, Ubuntu, and other Linux Docker images are perfect for their intended use case: Developer Containers. Specifically because you are attempting to replicate a local development environment across machines with zero friction; native support in VSCode, no learning curve for another technology like Vagrant, and identical development environment in Cloud-based code editors like Codespaces and Cloud9.

Excellent video thanks for doing such videos please keep contributing we wait for your such videos

Definitely want to here more about ephemeral containers

Thanks for another interesting video on an interesting subject 🎉 I totally agree on using multistage build images and avoid the unnecessary stuff in containers. For java we use azul jdk alpine based images even though tools like jlink exist to build a custom runtime image based on java modules for scratch. It's also worth mentioning distroless images which allows node and Java applications to run without extra dependencies, just google for them. Final note, I think that a video on ephemeral containers is a very good idea

Great video! As you mentioned, "from scratch" is good for binaries like Go, Rust, C, C++, etc. But what about dynamic languages like Java, DotNet, Python, JavaScript, and so on? Is it related to Google's "distroless" base images? And how about compiling Java apps using GraalVM to binaries? (maybe there are similar tools for other languages as well.)

I would greatly appreciate you covering Kubernetes device operators e.g. nvidia container toolkit or intel device plugin etc and how time slicing can be implemented using them.

Thanks it's a great topic. I think with source to image (S2I) & Buildh the process of creating image from scratch is simplified

Would love to go with any distroless image !

Great video as always :-) What container registry are you using?

ephemeral containers is a yes for me. would love a video!

Yes, please make a video about Ephemeral Containers!

This was a great video. Yes to a ephemeral containers video.

yes to ephemeral containers as a next video

Hi Viktor, yes plz, video on ephemeral contaners would be usefull.. tnx

Thanks for wolfi! Didn't know that one yet.

I think alpine in rootless and read-only mode containers are a good config to start with for nodejs/python based apps.

Excellent video 👏

Hi! Great content as always, I am using alpine as base image & using slim tool kit to reduce the size & image hardening, I would appreciate your opinion on slim 🔧 tool kit, can you please make 📹 video on slim toolkit, thanks ❤

Please a demo on scratch image but please use an interpreted language instead of compiled on ( because the compiled one are easy to deal with) Than a demo on using ephemeral container ( I would like to know if the ease a benefit of using them for me who uses docker-compose only for deployment). Thank you so much for your efforts.

Ephemeral contains are fantastic! Please make a post !!

The concept of it is more secure if you only include what you need reminded me of when you talked about Talos. Seems like using that for K8s would pair nicely with scratch-based containers.

Slow Jack Nicholson nod for the video on ephemeral containers!

Great video, well explained. What about those container images offered by Google - distroless ? I'm having difficulty understanding why to use them over scratch ? Is it just because of them being more debugable ? I know also there is a command kubectl debug which allows me to spin up a container like you mentioned inside the pods so I can troubleshoot networking issues. So I'm still confused why people still using those distroless container images from Google over scratch for compiled applications. Any other particular reasons you can think of ? Thanks!

A jewel video! Instant keeper

finally someone spoke my mind

That is very insightful. Does anyone have any experience with using nvidia CUDA drivers with scratch or alpine?

I use alpine small and light. And works great with Java Spring boot, rust bins, c/c++ bins, and even the horrible interpret scrap like NodeJS and Python.

What if some official approved containers use different distros as a base image? For instance, mysql uses debian, while mongodb uses ubuntu and I need both services in my network, so I will have extra overhead from both distros. Does it mean I should create my own containers for both services (from alpine) in sake of minimization?

yes, go for ephemeral containers!

updating my images 😅 grande!!

What tool/gui shows your registry/security scan/vulnerabilities? (THANKS!)

Big fan of distroless but not always the best fit.

one of the best videos

Thoughts on Rocky Linux? really liking it lately~

YESSS for ephemeral video :)

Great video. Yeah but...what if the underlying Linux OS is updated and breaks your App in your Docker container? I thought the whole idea of Docker was to prevent this.

if i understand correctly with scratch we cannot have dynamically linked executable? also, how does layering works here? i don't know much about the layering concept tbh. spring recommend putting dependencies in different layer. if you have done any video/blog on that can you link that also?

Me before starting the video: "The best base image is "scratch" Victor in the first 5 minutes: "The best base image is scratch "

Hey Victor what about "Distroless" Container Images for interpreted languages?

Yes on ephemeral containers

How do you avoid similar bloat in a VM, if running it using kubevirt or directly on hypervisor?

yes, I want to know about ephemeral containers.

With Java it's not so simple, and I think that alpine of similar (I use ubi on openshift) are ok. But I think that the ephemeral container point could be moreinteresting, Have you any plan to make a video about?

YES ephemeral containers!!11 now ;-)

Curious how you handle ca-certificates in scratch? Maybe its enough to install it from Alpine and copy it to the final image, or should they be mounted via volume in case they update?

12:21 yes please!

What about distroless images by Google, how do they compare to Scratch, Alpine and Wolfi?

You missed that glibc v.s musl as a reason to not-use a small or scratch image. Generally, not needed, but I've run into poorly behaving memory allocations resulting in truncated data.

Can ephemeral containers be used without kubernetes with just docker?

Yes for ephemerals containers . And how to debug outside k8 (plain docker)?

what do you say about devcontainer-images that is, VS Code development container image? these are used in github codespaces for doing development, not just _CI_ or _testing_ the default devcontainer supplied by github is based on ubuntu, which uses out of 32 GB: 46% (~14GB): huge.

Hey mate, I enjoy your videos! May I suggest doing one about VSCode DevContainers? I've been using them for the past year and they are very useful!

WASM Please take us to the next level already 🤘🤘🤘

I can agree with this but i must admit in large complex environment it is very difficult to do any real troubleshooting without having tools built into the image, network tools such as ping telnet ssh traceroute tcpdump and so on, i guess this is not a best practice but i find it easier when you have proper tools within images it speeds up troubleshooting.

In my case, my C binary uses a function available in a particular version of glibc. This is why I use Ubuntu 22.04 as even earlier versions of Ubuntu don't have a new enough glibc.

Alpine has pretty nasty downside. It's use musl instead of glibc which gives problems in very uncommon places

What about RHEL UBI images?

what distros should we use for VMs?

Yes

Real question is : How would I convince a project manager that existing images needs rework, especially when it is also running startup scripts which should be part of the build process 😅 This is the real tricky situation.

What you have not mentioned is that for running applications written in python or php you should use the php or python or whatever other language yoe are using base images instead of trying to install the interpreter into a alpine or debian based image

yes

yes please!!!

already using Alpine sooo

A video on Ephemeral Containers would be great.

yes, ephemeral containers. and yes, why are os images bad for VMs?

I understand the messages of knwow what you include, don't add extra stuff and most images are bloated. But there's some miss-information included that I doubt you are not aware of. I want to believe the push for views forces ppl to make controversial content. First, even binaries depend on OS libraries like glibc/musl. Go likes to say they generate fully static binaries, but it's not true, it's easy to check with `ldd`. Not addind those into the image means you'll be using the ones provided at the host which can make your app crash if there's any incompatibility (see glibc vs musl). That destroys the purpouse of generating images that are 100% assured to run. Then, that also means you are bound to host updates for CVEs. You won't see them in your scans but just because you are using the host libraries, so it's more like you don't see them.

Ubuntu4lyfe.

+1 on emphemeral containers

The video title is sort of misleading, indeed taking off the layers that are not needed using multi-stage builds to process building or even using a stage to pull e.g an artifact, extract it, and only keep in later stage the extracted part you need it does not mean you will not use a base image you are comfortable with through the build stages. :)

please, go ahead with ephemeral containers 🙏

Has Distroless fallen out of favour?

Aye aye captun.................

Containers are not VMs....... Then comes LXD/LXC :P

For once, I disagree with you: I've had issues with Alpine when running JVM. Either the container took very long to start (say 10 to 20 seconds) or worse, it was stuck and never started. I'll never trust Alpine again (and that's not even mentioning the glibc vs. musl gap)

Next breaking news: "Debian, Ubuntu and CentOS communities rise protests against Viktor Farcic" :DDD

# til

+1 for ephemeral containers

yes

Yes

yes

yes