Related: I recently wrote a blog post about using docker to containerize my ML research dev environments -- I've never found another way to make properly reproducible dev environments.
http://vedder.io/misc/research_dev_env.html
Ignore the sour grapes. Yes, Docker is constantly evolving. But the title does say "in 2023."
I, for one, need tutorials like this, and I am grateful for it. Devs who have been using Docker for a while have forgotten how intimidating it is for those of us who have our entire dev tooling built around VMs (orchestrated with vagrant in my case). You need just enough hand holding to get you up and running efficiently, and this tutorial does exactly that. It gets you over the hump a lot faster than trying to follow years-old and incomplete advice from Googling.
Yes, a thing or two may be deprecated. So what? We are used to that. But 99% of it still applies.
I've only read the first chapter, which is the general presentation of Docker, and it's awful. First of all, it's very long, with many words and a very low ratio of signal to noise.
Many texts look like they were copied from a Docker commercial. For instance the mention of Docker Swarm won't mean anything to someone that doesn't already know Swarm. And there's no distinction of main components against optional components like Swarm.
The final comparison to other container systems is pure junk. It should at least mention when the containers are compatible (like Podman) or not (like LXC).
I'm sorry for the harsh words. I wondered if I should keep silent or prevent other people from wasting their time with this. The low quality had me annoyed enough to opt for the latter.
Seems like I need to improve more on my storytelling skills hahaha
The concept of "Definitive Guide" on my blog is not to write "How to" guides or general overview articles.
It's to use personal experience and storytelling to write articles that are personalized and interesting to read while tackling difficult concepts like Containerization and Docker.
I could understand for the length. But if it's interest and you're getting value, length won't really matter, will it?
I may have gone off point at some point but of course, I'm always learning and improving and your feedback has been helpful.
However, I don't think asking people to avoid the piece is a good idea. If you notice a few mistake based on your level of knowledge on Docker doesn't mean others do.
They need grassroot beginners content to get them started.
> I'm sorry for the harsh words. I wondered if I should keep silent or prevent other people from wasting their time with this. The low quality had me annoyed enough to opt for the latter.
The harshness of your words don't really have much to do with the information you were trying to convey. You could have made the same point -- perhaps more convincingly -- if you had avoided phrases like "awful" and "pure junk."
Agreed, at best this is a beginner's guide, and a bad one at that.
I only skimmed it, but it doesn't even mention:
- user IDs, dropping root privileges and why you want to do that
- barely scratches the surface with volumes,
- commands like `docker ps` and `docker logs` which are essential for monitoring and debugging
- the common pitfall of exposing ports - the fact that Docker Engine binds on 0.0.0.0 by default. I've seen so many newcomers get their servers pwned because they accidentally exposed a database to the internet (and said database has weak/no auth by default)
Worse yet, it encourages terrible practices like storing secrets in files that are going to be committed in git. I find this surprising, because the author clearly uses `env_file` in docker-compose.yml, but then at the same time they're also hard-coding some secrets in the YAML and copying local `.env` file into the built image - it's all over the place, I don't think the author has a very firm grasp on Docker.
Thank you very much for taking your time to review the article.
Some of the things you listed as things I didn't touch on the article is true. I didn't cover those.
But this article is for beginners and I also indicate that there's an advanced content coming up on it.
For example, when I mentioned Volumes in Chapter 4, I added this "We haven’t discussed Docker Volumes in this guide but you can visit the Docker Content Hub for more advanced topics like Volumes."
To let readers know that there's an advanced topic that covers other concepts.
I even indicated it at the beginning of chapter 4 "Let me know in the comments section. I will share it with you."
Talking about common pitfalls for exposing ports. I didn't go in depth into PORTS because that knowledge will be too overwhelming at that point. At least, you should know how to dockerize an application before trying to secure it.
I have an Advanced Docker content coming up that covers Docker Security, that's where your feedback will be very help which I appreciate by the way.
Lastly, I never encourage storing secrets openly and committing it to git. That is a bad practice in software engineering.
In development, we all store our secrets in an .env file (if you use JavaScript) that is the standard but when deploying or on production, you move your secret to somewhere safe.
So that's the same concept for the article, while building your dockerized app in development I created the common.env file to hold the secrets in my development. During production, It will be secured according to standards and best practices.
I may not have indicated it like this doesn't mean I'm encourage the wrong thing. Beside for a developer to consider learning and using Docker, the developer must have been developing and deploying apps for a while and should know the best practices with SECRETS.
Next time, I will consider indicating it, Thanks to your feedback.
I took an issue with the post primarily because it's misrepresented as "A definitive guide [...]" which sets high expectations in terms of depth and quality of information. It's not even close to living up to those expectations, but I wouldn't have any problem with it had the post been more truthfully titled as "Beginners guide to Docker in 2023" or similar.
> Nevertheless, Docker runs flawlessly on all major operating systems such as Mac, Windows, and Linux with Mac being the easiest.
Careful, this gives a false impression. Docker is a Linux tool. Windows and Mac docker are indirections, but you're still running the commands on Linux. It's Linux that's the simplest easiest and most straightforward.
There is also the abomination which is Windows container “support” which works perfectly as long as you sacrifice a small fuzzy animal on a granite block at exactly midnight. Use a copper blade though, not bronze! Rookie mistake…
Thanks for your feedback. It's Solomon Eseme, the author of the piece.
Honestly, I don't see any wrong with the statement "Nevertheless, Docker runs flawlessly on all major operating systems such as Mac, Windows, and Linux with Mac being the easiest."
Docker runs perfectly in Windows, Mac, and Linux
Maybe I could have been more clear here "...Mac being the easiest."
The installation of Docker is more easy than other OS, that's what I wanted to communicate there.
I have personally installed Docker in all 3 OS and I discovered Mac to be the easiest. If you think otherwise. Then I respect your opinion.
When it comes to using Docker, of course, every developer should enjoy using it in Linux since it all command and the Terminal is Number one tool for developers.
When you say the first two paragraph. I'm hoping you mean:
"This is the most comprehensive guide on Docker online.
In this docker tutorial, you will learn docker from scratch to an advanced level starting from the concept of containerization to Docker Compose in Docker."
1. "This is the most comprehensive guide on Docker online.
This is how I start all my Definitive guides and it gives you a sense that I will try to make the guide understandable and easy to read by using the word "comprehensive"
2. "In this docker tutorial, you will learn docker from scratch to an advanced level starting from the concept of containerization to Docker Compose in Docker."
This is me letting you know that article is a journey from "Beginner" to "Advanced" meaning, it's long and you can skip to any point. That's why I separate them into chapters.
The title, introduction, and length certainly are misleading.
It’s incomplete even by it’s own promises, failing to touch many of the topics it lists in the beginning of chapters.
It’s most advanced feature is compose, which is by all means as basic as docker features get nowadays. Yet it fails to detail other essential features such as networking.
Usually, I would just ignore posts that aren’t thorough or are inconsistent, but by naming it the “definitive guide” it sets itself as a beginner’s trap, possibly pushing away, or worse - misleading, beginners who could benefit the most from clear guides in todays SEO-centric Ad-filled AI-generated world.
Steer clear from this one folks. Docker’s official docs are still the way to go.
I don't think it's entirely through that the article is misleading.
The article intention it to take readers through a journey from beginners to advanced level, using storytelling to explain technical concepts like containerization and Docker.
If you get to chapter 4, Look the brief where you see the image, You will see all the listed topics that will be covered in the Advanced Part of the article and It will be too long to include them there.
I even indicated with "Let me know in the comments section. I will share it with you."
Then I moved to discussing "Docker Compose" the next topic will continue in the advanced guide.
Docker documentation is great. But it's not every beginner or even advanced developers that understands Documentation at first introduction to a technology.
Thanks for your feedback anyways. I'm still learning and will improve as I write more.
31 comments
[ 4.2 ms ] story [ 84.5 ms ] threadDocker compose versioning was deprecated a long time ago.
It's just optional to add it or not.
https://docs.docker.com/compose/compose-file/03-compose-file...
By the way, this is an easy fix and thanks for pointing it out.
It's Solomon Eseme, the author of the piece
I, for one, need tutorials like this, and I am grateful for it. Devs who have been using Docker for a while have forgotten how intimidating it is for those of us who have our entire dev tooling built around VMs (orchestrated with vagrant in my case). You need just enough hand holding to get you up and running efficiently, and this tutorial does exactly that. It gets you over the hump a lot faster than trying to follow years-old and incomplete advice from Googling.
Yes, a thing or two may be deprecated. So what? We are used to that. But 99% of it still applies.
Honestly, I'm short of words to express how grateful I am for your feedback and encouraging others.
I'm glad you found the content useful.
It's Solomon Eseme, the author of the piece.
Many texts look like they were copied from a Docker commercial. For instance the mention of Docker Swarm won't mean anything to someone that doesn't already know Swarm. And there's no distinction of main components against optional components like Swarm.
The final comparison to other container systems is pure junk. It should at least mention when the containers are compatible (like Podman) or not (like LXC).
I'm sorry for the harsh words. I wondered if I should keep silent or prevent other people from wasting their time with this. The low quality had me annoyed enough to opt for the latter.
Large parts of it are long winding without getting to the point and then it suddenly moves to using terms that haven't been introduced.
Avoid this piece.
I'm Solomon Eseme, the author of the piece.
Seems like I need to improve more on my storytelling skills hahaha
The concept of "Definitive Guide" on my blog is not to write "How to" guides or general overview articles.
It's to use personal experience and storytelling to write articles that are personalized and interesting to read while tackling difficult concepts like Containerization and Docker.
I could understand for the length. But if it's interest and you're getting value, length won't really matter, will it?
I may have gone off point at some point but of course, I'm always learning and improving and your feedback has been helpful.
However, I don't think asking people to avoid the piece is a good idea. If you notice a few mistake based on your level of knowledge on Docker doesn't mean others do.
They need grassroot beginners content to get them started.
Found this to be pretty helpful.
The harshness of your words don't really have much to do with the information you were trying to convey. You could have made the same point -- perhaps more convincingly -- if you had avoided phrases like "awful" and "pure junk."
I only skimmed it, but it doesn't even mention:
- user IDs, dropping root privileges and why you want to do that
- barely scratches the surface with volumes,
- commands like `docker ps` and `docker logs` which are essential for monitoring and debugging
- the common pitfall of exposing ports - the fact that Docker Engine binds on 0.0.0.0 by default. I've seen so many newcomers get their servers pwned because they accidentally exposed a database to the internet (and said database has weak/no auth by default)
Worse yet, it encourages terrible practices like storing secrets in files that are going to be committed in git. I find this surprising, because the author clearly uses `env_file` in docker-compose.yml, but then at the same time they're also hard-coding some secrets in the YAML and copying local `.env` file into the built image - it's all over the place, I don't think the author has a very firm grasp on Docker.
Some of the things you listed as things I didn't touch on the article is true. I didn't cover those.
But this article is for beginners and I also indicate that there's an advanced content coming up on it.
For example, when I mentioned Volumes in Chapter 4, I added this "We haven’t discussed Docker Volumes in this guide but you can visit the Docker Content Hub for more advanced topics like Volumes."
To let readers know that there's an advanced topic that covers other concepts.
I even indicated it at the beginning of chapter 4 "Let me know in the comments section. I will share it with you."
Talking about common pitfalls for exposing ports. I didn't go in depth into PORTS because that knowledge will be too overwhelming at that point. At least, you should know how to dockerize an application before trying to secure it.
I have an Advanced Docker content coming up that covers Docker Security, that's where your feedback will be very help which I appreciate by the way.
Lastly, I never encourage storing secrets openly and committing it to git. That is a bad practice in software engineering.
In development, we all store our secrets in an .env file (if you use JavaScript) that is the standard but when deploying or on production, you move your secret to somewhere safe.
So that's the same concept for the article, while building your dockerized app in development I created the common.env file to hold the secrets in my development. During production, It will be secured according to standards and best practices.
I may not have indicated it like this doesn't mean I'm encourage the wrong thing. Beside for a developer to consider learning and using Docker, the developer must have been developing and deploying apps for a while and should know the best practices with SECRETS.
Next time, I will consider indicating it, Thanks to your feedback.
> This is the most comprehensive guide on Docker online.
Careful, this gives a false impression. Docker is a Linux tool. Windows and Mac docker are indirections, but you're still running the commands on Linux. It's Linux that's the simplest easiest and most straightforward.
Thanks for your feedback. It's Solomon Eseme, the author of the piece.
Honestly, I don't see any wrong with the statement "Nevertheless, Docker runs flawlessly on all major operating systems such as Mac, Windows, and Linux with Mac being the easiest."
Docker runs perfectly in Windows, Mac, and Linux
Maybe I could have been more clear here "...Mac being the easiest."
The installation of Docker is more easy than other OS, that's what I wanted to communicate there.
I have personally installed Docker in all 3 OS and I discovered Mac to be the easiest. If you think otherwise. Then I respect your opinion.
When it comes to using Docker, of course, every developer should enjoy using it in Linux since it all command and the Terminal is Number one tool for developers.
Thanks for your feedback.
It's Solomon Eseme, the author of the piece.
When you say the first two paragraph. I'm hoping you mean:
"This is the most comprehensive guide on Docker online.
In this docker tutorial, you will learn docker from scratch to an advanced level starting from the concept of containerization to Docker Compose in Docker."
1. "This is the most comprehensive guide on Docker online.
This is how I start all my Definitive guides and it gives you a sense that I will try to make the guide understandable and easy to read by using the word "comprehensive"
2. "In this docker tutorial, you will learn docker from scratch to an advanced level starting from the concept of containerization to Docker Compose in Docker."
This is me letting you know that article is a journey from "Beginner" to "Advanced" meaning, it's long and you can skip to any point. That's why I separate them into chapters.
Thanks for your feedback.
Usually, I would just ignore posts that aren’t thorough or are inconsistent, but by naming it the “definitive guide” it sets itself as a beginner’s trap, possibly pushing away, or worse - misleading, beginners who could benefit the most from clear guides in todays SEO-centric Ad-filled AI-generated world.
Steer clear from this one folks. Docker’s official docs are still the way to go.
I'm Solomon Eseme, the author of the piece.
I don't think it's entirely through that the article is misleading.
The article intention it to take readers through a journey from beginners to advanced level, using storytelling to explain technical concepts like containerization and Docker.
If you get to chapter 4, Look the brief where you see the image, You will see all the listed topics that will be covered in the Advanced Part of the article and It will be too long to include them there.
I even indicated with "Let me know in the comments section. I will share it with you."
Then I moved to discussing "Docker Compose" the next topic will continue in the advanced guide.
Docker documentation is great. But it's not every beginner or even advanced developers that understands Documentation at first introduction to a technology.
Thanks for your feedback anyways. I'm still learning and will improve as I write more.