Basic Docker Commands for Beginners(codeopolis.com)
codeopolis.com
Basic Docker Commands for Beginners
https://codeopolis.com/posts/25-basic-docker-commands-for-beginners
4 comments
Somewhat related to this: although I like to imagine I'm still young (hah!), dynamic and open, I'm quite set in my ways and conservative with software (Debian is my distro of choice on any computer). There's two particular areas where I've tried to learn newfangled stuff over the past few years: deep learning frameworks (because I find the field interesting) and Docker (because it does seem very practical in some circumstances). I feel exhausted by how hard it can be to find good information on either one! Everything I need is usually out there, but it's buried in pages upon pages of google hits that are short recipes or "tutorials" that involve sequencing a bunch of runes without communicating any understanding of what's going on.
Does anyone have a good strategy when approaching such hyped up topics (not in particular the aforementioned ones) where almost all sources seem to focus on "just getting it working" and lowering the barrier to entry? I don't mean to promote gatekeeping here, it's just that I personally can't learn from the "just do this then this" style.
Does anyone have a good strategy when approaching such hyped up topics (not in particular the aforementioned ones) where almost all sources seem to focus on "just getting it working" and lowering the barrier to entry? I don't mean to promote gatekeeping here, it's just that I personally can't learn from the "just do this then this" style.
I just had the same experience digging into Oauth2 and user authentication. Everything “guide” in google search is trying to sell you something, so it just “gets you up and running” with their proprietary software. (Auth0, Google, etc) The Orielly-esque books on the topic are terrible, with terrible explanations paired with terrible code.
I’m dying for like a full 100% deep dive on secure, modern web authentication and authorized, with matching code examples, just because I’m so curious about the subject.
The best I’ve done so far is to read some open source Oauth code like fosite- but this still doesn’t cover user authentication, or key signing best practices, or secret management or (all the other things I don’t know about but could contribute to an insecure implementation).
I feel like I’m at best getting 10% of the picture.
I’m dying for like a full 100% deep dive on secure, modern web authentication and authorized, with matching code examples, just because I’m so curious about the subject.
The best I’ve done so far is to read some open source Oauth code like fosite- but this still doesn’t cover user authentication, or key signing best practices, or secret management or (all the other things I don’t know about but could contribute to an insecure implementation).
I feel like I’m at best getting 10% of the picture.
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.
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.
If you don't want to discover things through small steps you practice yourself, you might just want a book on the topic.
Any recommendations for better learning resources?
When I picked up Docker, I had already been using other container technologies for several years so I personally don't know of any modern or complete learning resources that I can recommend. However I would recommend starting out by understanding what namespaces are, i.e. how container isolation works. You should also be aware of what cgroups are and how they are used, but you won't need profound knowledge of them when starting out. The man pages [1] [2] might be a good place to start.
[1] http://man7.org/linux/man-pages/man7/namespaces.7.html
[2] http://man7.org/linux/man-pages/man7/cgroups.7.html
[1] http://man7.org/linux/man-pages/man7/namespaces.7.html
[2] http://man7.org/linux/man-pages/man7/cgroups.7.html
I prefer Docker Compose to script all my docker tasks. It's easy, requires some understanding first (ie: environment variables) but after that you have reusable recipes.
Shameless plug time! I made https://composerize.com/ for exactly this - converting all the docker run commands from tutorials and such into reusable compose files :)
This is actually one of my largest struggles with docker currently. Thanks for linking your tool!
Absolutely, one of the things I find very frustrating about Docker is that for the situations I need it it's never sufficient in itself, you still need to be mapping ports and volumes and setting variables- and that's all done in terminal commands which I have to remember or store somewhere and if I get something wrong it all falls apart. With docker-compose I've actually got a single file that I an use to make sure the container actually is reproducible. I'm willing to accept that maybe I just have weird requirements though.
I'm definitely not arguing about the advantages that docker-compose can bring (for me: readability & multiple containers easily connected), but aren't port mapping (-p) and env. variables (-e) and volumes (-v) simple with a docker command?
See https://docs.docker.com/engine/reference/commandline/run/
See https://docs.docker.com/engine/reference/commandline/run/
They're simple, but what I want is a file I can point to and say "This is how we do things", to me that's a large part of what docker-compose brings.
I personally find the interactive switch very useful to actually control the container. You can use "-it" flag for this.
docker run -it [IMAGE_NAME] [ENTRYPOINT] docker run -it ubuntu:xenial /bin/bashI would recommend adding "--rm", to avoid leaving leftovers when the container exits:
https://docs.docker.com/engine/reference/run/#clean-up---rm
https://docs.docker.com/engine/reference/run/#clean-up---rm
The problem with these kind of Docker "recipe books" is users very quickly build up an unmanageable number of containers, images, networks, volumes etc. on their Docker hosts. When these users inevitably run into unexpected behaviour (or run out of disk space) their only solution is to "destroy the world" with some other recipe like a "docker prune".
I see similar things with git users who only learn recipes. I die a little inside every time I see someone fix their problems by deleting and recloning the repo because that's what it says to do on "ohshitgit.com".
I see similar things with git users who only learn recipes. I die a little inside every time I see someone fix their problems by deleting and recloning the repo because that's what it says to do on "ohshitgit.com".
Ok, so the dev who knows 5 languages, a bit about database, git and sysadmin has been hired to do one job. On this job, one must learn the entire stack, including docker, in a few months, while still reaching the deadline.
The dev won't be paid more.
The company won't spend more resources.
Time is short, talent scarce, customers in a hurry.
What do you think will happen?
This is the software industry in a nutshell.
The dev won't be paid more.
The company won't spend more resources.
Time is short, talent scarce, customers in a hurry.
What do you think will happen?
This is the software industry in a nutshell.
Backtracking to a known working state is a legit troubleshooting strategy. Have you tried turning it off and on again?
Yeah this is really low-effort spam, there's no reasoning, no explanation, nothing here will help somebody understand how to use Docker properly.
It's a shame, but this kind of SEO obviously works.
It's a shame, but this kind of SEO obviously works.
I think you are confusing dev and prod. Who cares how I got local kafka running?
Your coworker who doesn't know what the fuck Kafka is or why you need it to get the system online.
assuming my coworker is burrowing my laptop? I will reiterate, docker is amazing for setting up and tearing down complex software locally for dev. Productialization is a whole different story. For example, in case of kafka or kdb or scylla I would not even run them in docker to begin with.
This is completely the wrong way to go about learning Docker. The biggest problem with Docker is that there are too many people using it who claim they know Docker because they learnt a few commands they read on the internet, but they don't actually understand what a container is. In reality, this leads to all sorts of problems, like the deployment of insecure containers in the wild. Guides like this are recipe for disaster.