Docker Image BEST Practices - From 1.2GB to 10MB

[@betterstack]

Some fun corrections in this video: 1. I pronounce Alpine as "Al-peen" as that's how the Formula 1 team does 🤣 2. Nginx is "engine X".... I've just always said it this way 3. Alpine wasn't purpose built for containers but it works great with them! Also as I said in the video try not to use .env files in an image. Especially if you publish it!

[@tengun]

I always pronounce nginx as "Engine X". It sounds kinda cool.

[@sgenov]

@@tengun This is actually the correct way, as stated on their website: "nginx ("engine x") is an HTTP web server..."

[@sgenov]

It is also not written as "Nginx" - it is always all capital or lower letters: Nginx (pronounced "engine x"[8] /ˌɛndʒɪnˈɛks/ EN-jin-EKS, stylized as NGINX or nginx)

[@NathanChambers]

I almost threw up when you said nginx the way you did LLAL At least you know you're saying it wrong ha

[@rflsms]

I used to pronounce nginx just like you until I talked with the network admin of my college about it... she laughed a bit too much 😅😢

[@danielruiz2864]

Alpine is purpuse-build for containers, this is wrong, I think Alpine even exist before Docker.

[@cheebadigga4092]

yeah it's just a minimal general purpose Linux distro based on musl instead of glibc that's all - while it's a better fit for container environments when it comes to image size, it's wasn't "made for it"

[@ddksnitj]

But I think Containers also existed before docker !

[@cheebadigga4092]

@@ddksnitj Development of Docker at Docker Inc started before development of LXC, but LXC released first in terms of a complete set of kernel features used, tool availability and general support. In other words, LXC was was much more mature when it came out compared to where Docker was back then. But nowadays each of them have their own seperate use cases and limitations. Choose the right tool for the right job, as always.

[@betterstack]

You're right - I was oversimplifying. Alpine wasn't built for containers but it works great with them! - James

[@xanderplayz3446]

It actually was meant for routers, surprisingly enough.

[@AndrewAkaHrun]

Nice video. I recently tried “docker init” for a nextjs project and it pulled out not two- but three-stage Dockerfile - very optimized, but incomprehensible for an amateur. Your video allows me to understand better the rationale behind this modern tech. Thanks a lot!

[@VictorMongi]

Could you share your dockerfile? thank you

[@dputra]

Note that alpine use musl instead of glibc. For python based projects, you are generally advised to avoid it since many packages won't work.

[@guguludugulu]

Yeah, with python just don't bother.

[@pemessh]

Well, to be honest, Using non-alpine version in DEV and alpine in PROD does not sound like a good advice. Imagine everything works in DEV and you have to do a lot more to make it work in PROD. This would be a nightmare to manage. I would say use alpine in both. :) Thank you for your video :)

[@betterstack]

Fair point! You're right that using different base images between dev and prod could lead to frustrating "works on dev" issues. Though Alpine can make debugging trickier in the actual containers since it strips out things that may be useful. Overall find what works for you! - James

[@cn-ml]

@@betterstack I'd much rather debug in an alpine container than trying to find a bug caused by an entirely different development platform. Alpine has pretty good support for most major tools.

[@franciscopena7859]

Loved slim and dive. Been searching for something like dive for a LONG time

[@franciscopena7859]

Hadolint it's a must have. Also multi stage builds are great, just build your project on the intermediary container and import it into the final one

[@TheBill876]

5:05 how does it `build` before copying the app code?

[@gaming_troll]

Love this video, great stuff. Thanks. People tend to build containers as if they are VMs, but few simple reworks and they get lightning fast.

[@navidshm7424]

I've been trying to get my 2 GB image size down I the past week and couldn't get it under 270 MB. Thanks to you I now know the next step to minimize it 👍

[@neverping]

I wanted to comment out about the Alpine image, but then I saw the Senna car in the background and I prefer to say I love the Senna car in the background.

[@betterstack]

Haha thanks! Also seems like Formula 1 has changed how I say Alpine and some people dont like the F1 way 🤣 - James

[@ByteBite101]

You inspired me to make great explainers🔥

[@lonesomewalker]

First dev who is interested in optimization. Keep up the good work!

[@ashish_prajapati_tr]

great tutorial. learned a lot about optimizing the docker images.

[@Gaspa79]

Alpine was/is not made with containers in mind, but with embedded systems in mind instead. It was created in 2005 waay before containers started

[@betterstack]

You're right - I was oversimplifying. Alpine wasn't built for containers but it works great with them! - James

[@licokr]

Subscribed right away. This is why I like youube. High quaility video, it's super informative. Thanks a lot for making this video

[@techchrism]

Great video and presentation. Two things - nginx is pronounced "engine x" and you can use a tiny busybox httpd file server (154KB total image size before assets!) instead of nginx for a 118X size reduction

[@betterstack]

Yes seems a few are pointing out my pronunciation of that 🤦🏻‍♂️ I've just always said it that way and no one has corrected me until now! Cool tip on busybox httpd, I'll check it out! - James

[@alexflayz3600]

​@@betterstackoh, yes, giving into peer pressure of a random guy in KZbin comments. Engine X or nginx, it does not matter. And obviously busybox httpd supports http/3 just like nginx does and surely it has open_file_cache and everything else that nginx provides, suuuurely.

[@techchrism]

@@alexflayz3600 lol someone woke up on the wrong side of the bed. "peer pressure of a random guy"? Who cares what I have to say, look it up for yourself. Whether it matters or not is up to you of course but I challenge you to walk into your next meeting or technical interview mispronouncing every technology you mention. I personally don't think the pronunciation matters much, it was very clear what he was talking about, but this is a safe space for a correction in case he mispronounces it somewhere else where someone judges him more harshly for it. Of course httpd doesn't have http3 support at the moment but do you need that? Are you using that? There's quite a few hoops you have to jump through to enable the (experimental!) support for http3 in nginx. Me personally, I run just one nginx container instance and separate containers for project-specific static files so whether my application is a static webapp or a dynamic web server is irrelevant to my reverse proxy. But regardless, this isn't a video about memory file caching or http3, it's a video about reducing image size. And I shared a neat trick to reduce image size significantly. Wishing you a better night of sleep

[@tengun]

Tbh from 10MB to 154KB is just roughly 10MB storage saved. Personally I would keep nginx simply because I prefer its config format. I don't really need to overdo optimization for a few MB saved unless it's going to have a huge impact.

[@ДемьянКомаров-в8м]

Thank you a lot! Extremely useful, didn’t think of all those things except layer caching which seems minimal to all other (to my surprise EXTREMELY simple) things that you advised. Great job!

[@asksearchknock]

Two extra tips for your next video: firstly, never use the default user - always switch to a lesser privileged one unless absolutely necessary and second, a great trick to copying file is to use the RUN --mount=type=bind,source={localdir},target=/tmp - with this command you can copy data and perform other actions such as installing, uncompromising or anything else in a single layer and the residual size is only what happens at the end. Build layers are better but there are some cases where you can’t make this work and so this trick means you get the same size saving but in-line

[@abidkhairy..3863]

is there is any article / tutorial / documentation that i can read about that RUN command trick?

[@swastikgorai2332]

My go to way has been use a full image as a base image to create download build any dependency and use alpine as the final base image and copy the deps into it. Also, i wish Slim 🤝 windows but well.....

[@soosenschinder]

Shrinked my image from 3.2GB to 500mb, thanks!

[@ultraqq]

2:46 The 4th line does not utilize previous cache, because the 3rd line copies different things after your frontend code changes.

[@betterstack]

Good catch. Looks like I used the wrong code segment there. For anyone reading you need to COPY package*.json over first as seen at 4:26. Thanks! - James

[@shazzz_land]

for short it s a click bait vid

[@subz424]

​@@shazzz_land I wouldn't go as far as saying that it's clickbait. It's still useful/helpful info. He had some incorrect info, but he acknowledges them as they're brought up. And there's nothing wrong with making mistakes, that's normal.

[@developersteve1658]

​@shazzz_land I didn't know any of these things. Even if it's not perfectly correct, it still introduced me to the concepts, which I would argue is more important.

[@shazzz_land]

@developersteve1658 there is a limit to compression so u dont kill the system for active live files; it is never the compression problem it is the processing for live files like in live streaming of 4k and above when the device gets overheated due to decompression algos and decryption algos etc; high compression means high cpu load. Why do you think ps5 heated to infinity at launch? They have live decompression like streaming has live decoding and decompressing the stream

[@anon_y_mousse]

One of the best things about Alpine Linux is it doesn't use GNU software. I keep thinking about trying it out every time some dingus tells me that I should say GNU/Linux.

[@abdelrahmanhafez990]

Concise video, yet goes deep in the strategies. Good work!

[@ArtemKhodos]

Now I am interested in tutorial about how to use Dive and Slim while working with Docker

[@cheebadigga4092]

How exactly is Alpine "purpose built" for containers again? It sure came out way before anything container-related was implemented: - First release of Docker: version 0.1.0 on 2013-03-23 - First release of LXC (linux system containers): version 1 on 2014-02-20 - First release of Alpine: version 2.0 on 2010-08-16

[@betterstack]

You're right - I was oversimplifying. Alpine wasn't built for containers but it works great with them! - James

[@lctsi]

We were using/abusing cgroups long before 2014, try 07/08

[@guguludugulu]

OpenVZ was released in 2005, but I doubt alpine was made specifically for containers

[@cheebadigga4092]

@@guguludugulu yeah alpine is just a minimal Linux distro based on musl that's all

[@Z4KIUS]

Alpine can cause some issues, compatibility and performance aren't perfect but often you can just start with debian-slim version of a base image to get much smaller result

[@animeverse5912]

I spend day debugging nextjs standalone build because it was missing .env file during build time for public env vars. so i had to ship it in image. One command advice is a life changer. Thank you

[@betterstack]

Its still not entirely secure. I'd still highly recommend finding a way to not use .env in a dockerfile! This tip only works if you're creating and deleting the env in one line. - James

[@animeverse5912]

@@betterstack I know there’s no way around it also its just public var they viewable in JavaScript bundle. They were in .env for ease of producing production, stage and dev builds.

[@amgad_hasan]

Do you really need these env files at build time? If not, you can build the image without them, and then pass them to the docker run command for the container.

[@tengun]

If you only need them at build time, can't you do a multi-stage build for that? Build in one stage with environment variables or env file, and copy the dist to the final stage that doesn't contain that information? And if you only need them at runtime then get them from the environment at runtime.

[@zhalokrahman6654]

You can pass the envs while running the container You can also set the env file name at the docker compose

[@ahjsbkdjhavkcjhvac]

very insightful! ps. love the lego f1 models in the back!

[@wasinsilakong4912]

based on your background legos your alpine pronunciation is spot on🏎️🏎️🏎️

[@shateq]

This is quality content *My opinion may be subjective because I'm so on love with Docker

[@aj.arunkumar]

thanks for the video. im a software engineer and not a devops guy so didnt knew these stuff

[@ViktorKrejcir]

Think twice about choosing Alpine as a base image - it contains musl instead of glibc, which can cause issues if you have to deal with low-level code written in C. This also applies for stuff like native modules in Python or CGO in golang. There were also some issues with DNS, but hopefully that is already resolved in newer versions. Another consideration is, if you really need the shell at all. If you need some small distro with shell and glibc, I recommend good old busybox. :)

[@lulzmachineify]

I really prefer debian-slim. It is almost as small, and has better debugging stuff like curl, has tz builtin, and builds with glibc instead of musl, which makes it much easier for dependencies that need to build. Also has better compatibility with scanning like trivy/snyk

[@MasarJuraj]

Love it! Awesome tutorial!

[@dungva1505]

how container can run if you remove nodemodule in image?

[@RICHARDSON143]

Can you make a video on containerising chrome and chrome driver so that virtual Chrome instance will run in docker container with a virtual display.

[@ClaudioBalbin]

Anyone had luck with slim? Tried it on a few different imagens and it always seems do generate some empty containers.

[@freeideas]

Thank God I use VMs and don't have to worry about all this docker dicking around just to run an app. If anything I write gets more than 100 users, then I can ask someone like you guys to sort all of that out. ;)

[@alexflayz3600]

VPS gang > container wankers gang 🤣

[@ward7576]

Using alpine images come with security implications as these images cannot be scanned as easily by tools such as Docker Scout (by having a poor CVE database).

[@krellin]

at 2:47 RUN npm install will obviously install different shit depending on what you copied in previous step, so no it cannot possibly reuse previous layers cache unless it literally didn't change

[@waynelau3256]

I always find the pytorch containers the most difficult to deal with

[@Alexander-tl8uw]

Where did you get this racecars ?

[@nathansavage8692]

They are lego technic sets

[@florent3619]

great video! How do you create those animations? I would like to create similar ones for a college project

[@isameer3056]

Great 👍... Thanks for your content

[@knowledgedose1956]

python alpine is actually bad, it causes so much trouble when using some libraries, that it would be better if omitted. not sure about js/ts though

[@OnlinePseudonym]

Great video my man. What are you using to creat the code snippets graphics?

[@kaas99]

What's the best image to use when running a Nextjs app in standalone mode ? Currently I am using distroless nodejs which is ~130mb, any suggestions ?

[@plaintext7288]

rewrite it in rust to strip the whole nodejs environment and textual code

[@AshesWake-sf7uw]

Use anything for react but next, it's a hassle setting up without vercel.

[@cyrus01337]

Distroless was as good as I got personally even when I asked for recommendations in other communities on Discord. Because NextJS also distributes a server bundle, your final image must contain Node or a runtime that can run code originally meant for Node. If distroless images are larger than their Alpine variants, give Alpine a try.

[@betterstack]

Seems even the Next.js team recommend node alpine so not sure if theres a better choice. Have you tried minifying it with slim? - James

[@camcommute]

if the distroless are debian based then it'll be larger than anything alpine based. in my projects I used alpine and got around 86MB. Below is my repo, be sure to select the nextjs directory. david-randoll/docker-images-optomized

[@SnazzieTV]

Alpeen

[@heyitsmembermark]

😂

[@Fly16]

n jinx

[@betterstack]

You might be able to tell by my background that I'm a Formula 1 fan and thats how the Alpine team name is pronounced 🤣 - James

[@levshakor]

Amazing thanks!

[@oussamasadiki7377]

Great tips thnx man

[@ishaanmalhotra3008]

Whats your opinion on Podman? I was using WSL with Docker and it took an insane amount of storage on my C drive(which was already limited on space) like upto 80 GB! I then removed Docker and configured WSL with Podman and it took much less. Size of images was smaller as well as the client itself. Also with Docker I had to install Ubuntu on the WSL which was quite bloated but using Podman came with Fedora CoreOS which was a very light weight distro compared regular Fedora(or Ubuntu).

[@тимур_атмосферный]

You could just move WSL to another disk

[@ticua07]

You could move WSL to another disk using the "wsl --manage {distro} --move {path}" in wsl version 2.3+

[@marhensa]

Also, the operation you did on WSL2 is inflating your virtual disk size. For example, if you download or process huge files on your WSL up to 80 GB, even after deleting those files, the space stays inflated at 80 GB. The virtual disk doesn't automatically shrink after inflation. However, you can compact it to match the exact used size on WSL using PowerShell scripts to reclaim the unused space. Let me know if you're interested in this. The issue isn't Docker's fault. Your good experience (in terms of size) with Podman only seems better because you started fresh with it.

[@franciscopena7859]

Podman images and docker images are the same. It's just a matter which images you are using

[@cranberry888]

​@@marhensa can you please explain more about it, I didn't know about it

[@Abdulkhalek-Muhammad]

The best tip is multi-stage build

[@vojtasks]

pretty good, thanks

[@longnguyenkhanh7251]

Alpine purposely build for container? I'm not agreeing with that. And for using Alpine as base image actually trade off some performance as multi threading in musl is bad comparing to gcc. Because of that, mostly I choose minideb as base image more than alpine after my internship.

[@saiyyy]

great video!

[@minhhieple6483]

Can anyone explain to me why this guy runs npm install -production then he ends up deleting node_modules (rm -rf node_modules ) ?

[@Wayne_Mather]

Because he is building 2 containers. 1 takes the vite and builds it into js/html/css static files. Then he creates another container that installs a webserver and serves the generated app in the builder container. Then the builder container is destroyed only leaving the image for the webserver with a smaller footprint. The reason it's done this way is for CI builds. He can check in code to a git repository and have the CI server build the application and create the image that can then be used to host the application. Hope this makes more sense?

[@minhhieple6483]

@@Wayne_Mather Thanks for explain. Now I got it!

[@Wayne_Mather]

@@minhhieple6483 No worries - glad that made sense for you!

[@betterstack]

Really good explanation thanks! - James

[@zhalokrahman6654]

But if I ignore the node_modules folder i eventually am installing the packages inside which will be creating the node_modules right? So that should not shrink the size of the image And also if you think of a CD workflow it will fetch the source from a source control repo like github which already should not contain node_module So in an actual usecase mostly we are not even shipping the node_modules inside the image while we are building right?

[@rChaoz]

There are multiple reasons not to copy your node_modules and instead let it install them 1. there will be differences between a CI pipeline (doesn't copy) and locally (does copy), so it might work locally but not in CI, very hard to debug 2. if it is copied it likely contains more dependencies than needed (e.g. dev dependencies), so it increases the size/takes even more time than it should

[@juniper1312x]

You do seem to be missing node in the final image, you will need that to run your javascript project

[@camcommute]

the project he used in the video is a react vite. when you run npm run build it gets compiled down to static files i.e index.html. so all u need to do is serve the html file therefore no node needed

[@buger_od_ua]

There is also a whole world of native builds

[@randomgeocacher]

Dive is a nice command for visualizing layers/images. Also with Go, CGO_ENABLE=0 and some static linker commands, and you can throw away all dependencies. A single layer, your go-app, to run the entire containerized application. Could be done for other languages as well (e.g. C) but with less ease of use. GCT/Distroless contains a lot of dependencies, basically it is an OS-like environment but without any binaries; I.e. intended to be easy to use (no need to change how you compile) while providing a stripped down environment.

[@jaikansra2491]

If we have already added node_modules in .dockerignore file, why are we deleting it using rm -rf?

[@amgad_hasan]

Because it will be created inside the image at when installing dependencies, but it won't be needed later for serving.

[@timur2887]

blissful chebyshev? =)

[@JuanLiz]

Alpine images are flooded of critical vulnerabilities. I prefer using UBI images

[@mrrolandlawrence]

handy.

[@okoeroo]

Nice. insightful

[@balexandre]

Ayrton Senna ❤

[@pcnerd5994]

In my opinion delete the node_package is a bit over kill. It's just make it more complicated.

[@payton6_]

That step alone reduced the size of the docker image by half, I’d say it’s worth it

[@betterstack]

Multi-stage builds is still the best advice. I was going step by step as every case may not apply to everyone. - James

[@ordinarygg]

0mb just don’t use it in prod

[@cronosmain]

looks like something wrong with a technology in the first place if it produces 1.2gb images by default

[@thomas-sinkala]

Unless you understand distroless, don't bother with it.

[@mohamedmonem2645]

docker system prune -a

[@saeidex]

❤

[@tombyrer1808]

Very cool! BTW tried unikernels yet? kzbin.info/www/bejne/sIC2gGytZdpojaM

[@betterstack]

Not seen it yet, will take a look! - James

[@theperfguy]

Sorry, but how do you pronounce "pine" now just add "al" to it.. al-pine You should be jailed for that pronunciation of alpine.. 😂

[@FreakyRufus]

“N-jinx” got me too.

[@pugo-v4q]

i think he's pronouncing it 'al-peen' because he's an f1 fan, and there's a team named Alpine, which is pronounced 'al-peen' in french. m.kzbin.info/www/bejne/pn3InaN-i7GXrqs

[@betterstack]

@@pugo-v4q This is entirely the correct answer 🤣 I watch a lot of F1 so thats how I say Alpine now! - James

[@kairu_b]

Noice

[@ivanmaglica264]

nJinx 😀

[@TheOnlyJura]

or you could just use a vps run apt install nginx and copy over the files

[@teocardoso7237]

This video is pointless, so for a small image just use a small image???? Wat?

[@camcommute]

I wouldn't say it is pointless as there are many that don't know which images is small.

[@sxlg_32]

Its about best practices you donut.

[@PatPatych]

Docker best practice: do not use docker