A (potentially inefficient) strategy that I use from time to time is to start with some kind of quick start (a hello world container), dive into a basic project with the new tool (what could go wrong if I wrapped up arcanist with Docker?), use that experience to give some context to a moderately in-depth perusal of the docs, and either research or explicitly test (or both) anything that seems unclear. Write any such things down because they're prone to turning into rabbit holes, and you want to cover all of them.
With that as a foundation you'll still only know enough to get yourself into trouble, but you'll have the vocabulary and background to be able to find more tailored resources, to immediately reject a lot of articles and guides, to form your own opinions about lists if best practices, and to continue learning via hands-on experience.
The underlying assumption is that there are nuggets of wisdom here and there which mostly add up to the knowledge you're looking for, but that they aren't all in the same place and that they're buried under a deluge of inapplicable, SEO'd garbage. I think that's a decent model for thinking about Docker, but other topics like learning most mainstream spoken languages might have more dedicated resources which will serve you better.