Sean Kane

Congratulations to the winners, and thank you, Tim, for donating your copy to another community member!

It was fun hanging out and talking with you all for a few days!

Sean

Yes, in general, you can install and use them side-by-side.

Sean

With the docker container run command, you can pass in things like:

docker container run --cpus="2" --memory="500m" ...

and in a docker-compose.yaml file you can do something like this:


services:  my-api-service:    image: my-api-service:latest    deploy:      resources:        limits:          cpus: '1.50'          memory: 512M        reservations:          cpus: '1'          memory: 256M

https://docs.docker.com/compose/compose-file/compose-file-v3/#resources

We detail these general steps in the book but don't cover image scanners specifically.

The overall advice here is the same as other downloaded code, doing your own due diligence is wise, even if the source is trusted, simply to lower risk and hopefully catch anything odd before it bites you.

I agree with Karl here.

The only thing that I might add is that if you truly need cross-cloud failover, then you should probably investigate whether Kubernetes would be worth adopting. It is not a simple tool, but it is powerful and provides an excellent standardized interface for deploying containers in any environment (cloud or datacenter).

In general, it mostly just depends on what works for you.

For development environments, Docker has much better cross-platform support (Linux, Windows, macOS) in general and provides an API, but podman is simpler overall. Podman Desktop is improving the support of podman on non-Linux systems, but it is still pretty rough.

Rancher Desktop is another option if you are looking for a solution more directly focused on Kubernetes.

I'd recommend starting by figuring out what features you need and what operating systems you need to support and then do some testing, etc. And the end of the day, and OCI image and Linux container should work with anything, so the tools are mostly there to make the process easier for you, your peers, and your organization.

Tim Holloway wrote:So you need to map its port 9230 to a port on the container host. You can do that with the "-p 9230:9230" Docker run command-line option.

That should do it.

You can find some more details about this here:

https://docs.docker.com/engine/reference/commandline/run/#publish

Yes, the book does cover this. We discuss using the "docker buildx build" command to build container images for multiple architectures.

Also, note that this is not really a Docker issue and is usually more of an image maintenance issue. Sometimes you can solve this issue by simply re-building the image yourself on the appropriate architecture, other times, you need to kindly but persistently convince the project maintainers to update their release workflow, and sometimes you are simply out of luck because the code inside the image is simply too old and won't compile on another architecture like arm64 without significant updates and effort.

The 3rd edition includes one completely new chapter, three important new sections covering buildkit, buildx, and rootless containers, and major updates to all of the original chapters. The book coverage has been updated from Docker Engine 18.09 to Docker Engine 20.10, covering all the important changes in between.

Docker: Up and Running primarily focuses on Linux containers and Docker, although we provide some light coverage of Kubernetes. If you need something that goes into more depth on Kubernetes, then I would recommend the most recent edition of Kubernetes: Up and Running.

https://www.oreilly.com/library/view/kubernetes-up-and/9781098110192/

You can see the Table of Contents for the 3rd edition on this page (you'll need to expand the tab):

https://www.oreilly.com/library/view/docker-up/9781098131814/

Looking at Chapters 9-11 will give you some idea of the topics we cover, which directly relate to production concerns.

Shaik Ashish wrote:If containers are doing the job so quickly by launching the Operating System why still there are people who are using VMware Virtual machines?

In addition to Karl's great answer, there are many blog posts and articles about this online if you want to dig into this some more. Searching for "containerization versus virtualization" should get you a lot of results like the one below:


https://www.ibm.com/cloud/blog/containers-vs-vms

Stephen Morris wrote:Any thoughts concerning escape from a container as a root user? Is this addressed in the book?

Escaping the container as root, is indeed something that should be considered.

Docker has a rootless mode nowadays, which can be used to prevent root-privileged containers.

https://docs.docker.com/engine/security/rootless/

in addition to the normal ability to simply change the UID that is used inside the container.

https://docs.docker.com/engine/reference/builder/#user
https://docs.docker.com/engine/reference/commandline/run/  (see: --user)

General recommendations and things to consider:

- Read the Dockerfile
- Build the image from the Dockerfile yourself
- If you're using Docker Hub, prefer Official images - https://hub.docker.com/search?q=&image_filter=official
- If you're using Docker Hub, take note of the stars that have been given to an image (not a guarantee of anything, but a good indicator)
- Scan the images you download and use - https://geekflare.com/container-security-scanners/

The Docker shim was specifically a component of Kubernetes that provided a bridge between Kubernetes and the underlying Docker daemon.

If you are unfamiliar with it, it is probably pretty safe to ignore it. This caused a bit of a panic among folks when Kubernetes first announced that they were deprecating the Docker shim, but in most cases, it was really a minor change that simply required some migration steps to be performed when the change actually went into effect. This was not a statement about Docker but simply a way for the Kubernetes team to simplify their codebase, very similar to when Docker moved away from the underlying LXC tooling early on in its development.

https://kubernetes.io/blog/2022/02/17/dockershim-faq/
https://docs.docker.com/engine/deprecated/#lxc-built-in-exec-driver