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.
My name is Solomon Eseme and I'm the author of the "Docker: The Definitive Guide in 2023"
First, I want to personally thank you "Idoubtit" for reading through the piece and sharing your personal review.
I will only try to share my views here and hope it helps clarify things a little.
Firstly, the intention of target audience of the book is for beginners to Docker and as your progress in the chapters, you can see some other concepts that intermediate can benefit from.
Secondly, I also understand that the book is long and a lengthy book sometimes could contain unwanted parts or noise but this is because of my style of writing. I want to tell a story when I'm writing a "Definitive Guide". I don't want it to be like an "How to" guide or "Overview of" kind of article.
Thirdly, when you say "copying from Docker commercial" that's not entirely true because you could see that I give proper credit to every source and I didn't go in-depth into some topics because at that stage in the reader's mind, It will be confusing since the target is beginners there's no need talking about Docker Swarm or Networks at that point.
Next, the comparison part is simple and straightforward, my intention wasn't to show comparison but to inform the reader that there are other containerization implementation out there and these are their market share. Coming from the point where I said that Docker is the most popular, the Market share diagram helps compliment that.
Of course, I understand that the article can be improved, It could be made better and also, I could be better in writing and passing points across.
I also, I understand that the title "Docker: The Definitive Guide in 2023" could be misleading. But if you look at the chapter 4. I indicated that there is an Advanced Copy of this book.
I even said "Let me know in the comments section. I will share it with you."
I'm currently working on the Advanced part that will include everything I have listed in the chapter 4.
I hope this helps clarify somethings. I'm still learning, I'm still improving and I really appreciate you for giving these feedbacks.
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.