Live data from Hacker News

The Ultimate Docker Cheat Sheet

devopscycle.com

11–20 of 27 posts

Re: The Ultimate Docker Cheat Sheet

#11
post #6

I think Docker has a fairly well designed CLI and I don't find myself having to Google commands for it often. It follows a few pretty consistent patterns that I wish git had tried to stick with rather than the concoction of words and flags for common actions it ended up with.

Agree. Kubectl's more prose like style seems harder to remember.

Re: The Ultimate Docker Cheat Sheet

#15
post #8
post #7

Please add - Security warnings: like: Note that ports which are not bound to the host (i.e., -p 5432:5432 instead of -p 127.0.0.1:5432:5432) will be accessible from the outside. This also applies if you configured UFW to block this specific port, as Docker manages its own iptables rules. https://docs.docker.com/network/packet-filtering-firewalls/ - using trivy scanner: "trivy image --ignore-unfixed ... " ------------…

Author here. This is actually a good point, we will add this in the near future. Thanks for your input.

I'd also fix the very first example. Stuff like LABEL, ENV, EXPOSE, CMD or ENTRYPOINT that rarely ever changes should be at the top, followed by ARG, prior to the first ADD/COPY/RUN statements. That way, you can re-use layer caching more efficiently.

In general, I think it's also a good general idea to keep yourself to one, maximum two RUN statements per image - I've seen it way too many times that some junior writes RUN apt update, RUN apt install -yf foo, RUN apt clean... which will leave all the intermediate crap from apt still part of the final image as the third command (the apt clean) will just set tombstone files [1][2] in the layer's overlay image.

(Side note, it boggles my mind why you can't tell Docker to flatten multiple subsequent "metadata only" layers like LABEL/ENV/CMD/ENTRYPOINT/ARG into one single one)

Additionally, I'd add a warning for multi-stage builds that ARG needs to be redeclared in following stages (a simple ARG xyz is sufficient, no need to repeat a default value), and that CMD/ENTRYPOINT set in the first stage for some reason tend to be overwritten in a stage that is FROM first-stage.

[1] https://github.com/aws-samples/linux-container-primitives-pr...

[2] https://jvns.ca/blog/2019/11/18/how-containers-work--overlay...

Re: The Ultimate Docker Cheat Sheet

#18

> What Is The Difference Between A Dockerfile, An Image And A Container? I would like to know what the difference is between a stopped container and an image.

If you're familiar with OOP/language with classes, a fitting analogy could be that a container is an instance of a image, just like you can create instances of classes. The image is the "template" so to say, and the container is the executing of that "template".

So a stopped container could have stuff in it that doesn't exist in the image, as the container has gone through the states of "created > running > stopped" and during the running, you can mutate stuff in the container.

On the other hand, an image never actually runs, only containers created from that image.

I guess you could compare it to VMs as well, where you can have templates/other instances, and clone new instances from that template/other instance. Kind of the same too.

Post reply on HN