I recently had the experience of trying to learn ( from scratch) how to use Docker containers.
I chose to do this with Docker in Void Linux, because I wanted to learn from the command line. Doing it the hard way is often the best way to gain an understanding.
I can report that it takes about 2 weeks of trial and error, that the online documentation is not up to scratch, but that docker itself performs well, as expected given its major use by software developers.
What I plan to do next is explore
using a docker container for a large software build in my own work
can we use docker containers in itsFOSS to share things
If anyone is interested in my learning path, there is a document on my Github site
You should click on the file voiddocker.pdf , and if it does not automatically download, click the download button.
Be warned, it is all command line stuff.
I support our Kubernetes clusters at work and use Docker quite a bit, but would still not consider myself an expert. I tend to use Podman rather than Docker. It’s a command line tool that is compatible with Docker, but is daemonless. I think it started life at Red Hat.
Thanks, I will have a look at Podman. I found the learning curve rather steep.
My understanding is Kubernetes is just for managing lots of containers. Is that right?
A reasonable explanation of what docker is and how it works is given in this
tutorial [2]. In one sentence docker is like a VM , but it only containerizes a
selected part of user space. It was originally intended to be used for providing
an isolated environment for software development. Other uses have developed.
On point and absolutely correct.
Two key concepts are images and containers. A docker image is the software
which is containerised. There is a registry of useful images called Docker Hub [4].
A docker container a copy of an image, along with some organization which
allows it to be moved, installed, modified and run.
Not entirely correct or at least confusing.
The Docker Image is the unborn Docker container. It is declaratively designed through a Dockerfile.
It does not have a “running” state, as it is more like a cake, which never goes bad, but also isn’t baked, yet.
Creating a container of an image is like taking that cake and actually baking it. You do something with it.
A container has a “running” state, because you do something in it. For example, you run software inside that container.
While images and containers are different in that regard, it’s usually best to keep the container as close as possible to the initial image design by Dockerfile, because this way you keep the designing possibilities on the image, i.e. Dockerfile level.
In other words, the Dockerfile is the declarative “recipe” and the image is the result of that recipe in perfect form.
Then, this perfect form is taken and used in real life, i.e. in a container.
I can see that I only had a half-correct view of what these entities are
and how they interact.
Now that you have enlightened me, I need to go and read the documentation again.
Learning involves repetition
Regards
Neville
I learned the most by just doing it, not reading the documentation. I read only the most basic parts of the documentation, plus whatever documentation is available for docker-compose. Yet, I’d say I have a pretty thorough understanding of Docker. It’s because I have used it tons of times for years in a variety of manners.
Correct. Kubernetes is a “scheduler” for lots of pods. It also has facilities for ingress/load balancing. Another big advantage would be high availability.
But not worth it unless you have lots of workload for it or cost of downtime is high or you just want to learn something valuable for a new career phase.
If someone is interested in Kubernetes a nice way to experiment with it is by installing MICROK8S on Ubuntu. It’s a snap that performs like a one node Kubernetes cluster.
I understand, this post was intended to summarize the meaning for beginners, however even then I find this part of the description too limiting, which is why it might leave the wrong impression on readers.
I would recommend using the official word used, whenever something like Kubernetes is described – it’s “orchestrator”.
Scheduling is just one little part of the whole orchestration process. Kubernetes is huge and makes developers and administrators think completely differently, which is better.
Additionally, it’s not just about “managing” lots of containers. From a very narrow perspective, one could describe it like that, but I think it’s described the wrong way around. It’s not like random developers put their stuff in Docker images, because everyone does it and then you have so many, that you need something like Kubernetes for it. That’s not the case.
The reality is, that Kubernetes is currently the best software deployment technology & strategy available. As of now, there is no better technology that fits our current time & its requirements better.
So, Kubernetes is not a “solution” to a “problem” with “managing” Docker containers. Having software architectured in a way that fits Kubernetes is actually desired!
Up to date developers and DevOps engineers strive to have their deployments work according to how the Kubernetes strategy recommends & demands it.
That means in practice, that software, which works well and is very compatible with containerisation technologies (Docker is not even the main kid for Kubernetes, anymore) running in Kubernetes is highly sought after and influences architectural design decisions.
Kubernetes revolutionised the deployment and system administration world in a very positive way.
But I think in the meantime you´ve acquired such a profound knowledge you won´t need such a help anymore. Sorry for the bother.
Well, I thought I might mention it anyway.
Hi Rosika,
My knowledge of this topic is nowhere near what you seem to think.
I think that book is for Java programmers. I dont use Java.
Everyone has their limitations. Thank you for mentioning it. I do need some better documentation
Regards
Neville
So sorry for having bothered you.
I think I got carried away by the sub-title Hot Recipes for Docker Automation
This is a closer description:
Docker is the world’s leading software containerization platform.
Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server.
This guarantees that the software will always run the same, regardless of its environment. Docker provides an additional layer of abstraction and automation of operating-system-level virtualization on Linux.
Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent “containers” to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.
In this eBook, we provide a compilation of Docker examples that will help you kick-start your own automation projects. We cover a wide range of topics, from installation and configuration, to DNS and commands. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time.
As there´s no mentioning “java” in here I didn´t realize the “problem”.
It seems like it’s released by Java code geeks, so it may contain examples using Java.
However, when it comes to using & learning Docker, it does not matter what runs in it. It just about deploying something and that means, if you learn how to deploy some Java program, you can easily learn, with little adjustments, how to deploy programs written in R, Rust, other JVM based languages, etc…
It’s not like you need Java. It’s just an example, using the one of the most popular languages in the entire world.
No apologies needed.
In fact that sounds a lot better than my first impression. I shall download it.
It is actually a good statemet of what docker containers are used for.
Regards
Neville
