Stephen Kuenzli

I do not have any significant experience using other container runtimes (systemd nspawn is kind of neat in a pinch), though LXD looks interesting to me.

I would stick to Docker at least through 'intermediate' phase of expertise.  

There are systems like Rancher that use containerd + runc directly.  Containerd + runc were extracted from Docker and (still) used by Docker.  Some people are very excited about podman since it does not require access to a daemon running as root.

I'm not aware of any commercially-supported systems such as a managed Kubernetes service or k8s distribution that default to CRI-O.  So... if/when you try them, I would keep in mind that it's not a well-trodden path.  But could be fun!

You could design your image layers such that files that changed frequently were in specific layers with the same change lifecycle.  Then when those layers files changed, only the updates would be transferred.

I believe the finest granularity you're going to get with standard image management tools is a layer with a single file.  The most popular form of are Docker images built from 'scratch' that contain a single executable.

If you're looking to patch e.g. a binary where only 100 bytes have changed, you'll probably need another distribution mechanism.

Hi Miroslav,
There are definitely folks using Swarm in production.

We recommend learning the fundamental concepts of Orchestration using a simple and effective UX of Swarm and then taking the next step to whatever your team is using: Kubernetes, ECS, Nomad, etc.

I wrote a series of blog posts contextualizing container orchestration selection at:
https://nodramadevops.com/2019/10/container-orchestrators-are-the-same-but-different-swarm/

The image update question has a straightforward answer that's explained in detail in Chapter 8 and Chapter 9.  

Docker and the Open container image format support highly efficient and customizable distribution models.  Only the layers that have changed within an image or are not currently present on the host will be retrieved from the registry.  Each layer will be stored once on the host.  Each image and layer within the image is identified cryptographically so the client can be sure it has what it is supposed to have.

This distribution mechanism is probably about as efficient as you'll find in an out of the box software distribution solution that isn't specialized for IoT.  I expect you know better than me on this point.

Now... it may make sense to use containerd/runc/podman tooling to launch and manage containers rather than having dockerd do it.  In that case you will need to integrate that with your devices existing process management model, which I would expect to be viewed as a feature.

The general answer to that question is that a program running inside a container on a Linux container host will observe:

* no cpu and memory access overhead
* potentially measurable, but low networking overhead on the order of 1% or lower for throughput heavy applications
* significant storage write throughput performance impact if using an overlay filesystem... but you probably shouldn't do that because it sounds like you're storing data inside an ephemeral container filesystem; you should probably take a look at Chapter 4 and bind-mount a directory from the host or use a volume instead

Yes, Orchestration can and does fill entire books.  And if you're using Kubernetes, that book will age quickly.

I specialize in AWS and my preferred container orchestrator is ECS & Lambda.  

I wrote a whole series of blog posts contextualizing container orchestrator selection with the intent of helping people select the orchestrator that is right for them, starting with:
https://nodramadevops.com/2019/10/container-orchestrators-are-the-same-but-different-swarm/

That series covers Swarm, Kubernetes, ECS, and a general orchestrator selection strategy.

There are many use cases for the portability, isolation, and repeatable runtime that Docker images and containers provide.  These use cases are primarily important to software engineers, build & release engineers, platform engineers, and systems engineers.

Software engineers interested in keeping their local development environment clean, avoiding 'works on my machine' problems, and publishing software that can be operated in production easily should find the concepts and practices of containerization useful.

Hi Will,
You've asked a great question.

Short answer: No, you don't need Kubernetes to learn about Docker or containers in general.

Long answer:
In fact, the Docker in Action authors recommend that you learn about containers and Docker first, then move on to learn about container orchestration systems.

Container orchestration systems are tools designed to help people run containerized applications across multiple hosts.  Kubernetes, Swarm, and AWS Elastic Container Service are all container orchestrators.  Container orchestrators, especially Kubernetes, tend to be complex machines and you'll want a solid foundation in standalone containers first.  Docker in Action, 2ed builds this foundation in the first two thirds of the book.

Docker in Action 2ed covers the core concepts of container orchestration such as "Services" and running services modeled in Swarm in the final third of the book.  These concepts and exercises should provide useful context when moving to Kubernets or ECS, should you choose to do that.

The Docker in Action authors agree with the sentiments in this thread.  Especially in mid-2019, Docker for Windows was a promising, but quickly changing target -- so we did not try to support it within the book directly.

That said, the following have been good options for Windows users over the years:

* a virtual machine running whatever Linux distribution you are comfortable with, e.g. Ubuntu on whichever hypervisor is already enabled: often Hyper-V or Virtualbox
* a cloud hosted virtual machine
* Play with Docker: https://labs.play-with-docker.com/

I'm hopeful that both Docker for Windows and WSL2 will improve the local Docker user experience for Windows to make it more accessible.

Marina,
We definitely intend for the book to be accessible to those who are comfortable:

* in a Unix-shell such as bash on Linux or OSX
* running and reading simple programs
* with the concepts and some light usage of virtual machines

Joe - we're very happy to hear you thought it was a good introduction.

Hi Ci-Ci,
Chapter 6 will introduce and show you how to use the fundamental resource usage and access controls that containers are built from.  These tools include:

* cpu and memory resource limits
* running containers with low(er) privileged users and groups
* filesystem access controls

If you apply the concepts in that chapter in your own work, you should quickly be able to run your containers very securely.

Now... Snyk is tool that can scan images for vulnerabilities.  We cover production-class image building workflows in Chapter 10.  We integrate Google's Container Structure Test tool to show how you can assert many things about the structure of the image filesystem, default user, etc.  We also describe the features you will likely want in a vulnerability scanning and remediation workflow.  However, because the major image vulnerability scanning systems were commercial or were too difficult to set up at the time, we did not work through any specific examples with Snyk, Aqua, Twistlock, etc in the book.

If you have any specific questions, feel free to ask.  I have direct experience with several of those systems.

Stephen