Hacker News Reader

Comment by gvb | Hacker News Reader

"Corgibytes often introduces new clients to Docker, making it much easier and faster to set up new developer environments." (emphasis mine)

She isn't advocating using Docker for the target environment, she is advocating using Docker to set up a standard development environment that allows the developers to be productive[1] in 10 minutes rather than 10 hours.

I've been in the situation where the development environment is a poorly documented, massively multi-step steaming pile. The result is I spent a lot of time chasing down those responsible for the steaming pile (the "rockstar" in the department) asking them how to get the development environment working. Typically they pull the keyboard away from me, type a bunch, and then say "there, it works." Which it does. For a while.

Rinse and repeat for every developer. Regularly.

[1] Well, at least building the system rather than staring at mysterious very broken error messages.

View on HN

> Typically they pull the keyboard away from me, type a bunch, and then say "there, it works." Which it does. For a while.

This would happen if they distributed Docker environments, too. Your setup process would be to download a Dockerfile, crank up everything you need, discover it doesn't work, call the Rockstar over, have him or her explain that there's a few manual steps that they haven't yet added to the codebase (or to the wiki), and then you rinse and repeat that process, instead.

No, because once your Dockerfile works, it works fucking everywhere.

Oh wait, you need to configure your networking bridge differently ... oh wait, the DNS needs this little tweak ... oh wait, you still use this old version from your distros repo? ... oh wait, you must give it this docker volume ...

I can tell you're frustrated from too much yak shaving. But once you become more experienced with systems in general, you'll feel much more comfortable around Docker.

You have to set up docker first.

Which is great if you're the person in charge of distributing it, but if the person in charge keeps giving out the "slightly broken" version, everyone will keep fixing it.

Or, and I'm not sure if this is worse, a few people will fix it in slightly different ways, and start distributing those, leading to a weird ecosystem of competing Dockerfiles none of which are quite correct.

Well, what I mean is that once you get your Dockerfile to the point where it works, it will work literally anywhere you've got Docker installed. That is one of Docker's core value propositions. It's very hard to get something "halfway working" in Docker, because you've either got a process running containerized, or you don't have anything at all. "Slightly broken" in the context of Docker isn't really something you run into very often.

You know what else happens in that situation?

Nobody will volunteer to help you fix an obscure bug that only happens reliably in your version. Because it's too painful for them to shelve their local configuration and grab yours. And once people have that hesitation, 'all hands on deck' emergency fixes become window dressing, because only a few people can actually participate in tracking down and triaging the bug. Everyone else is sitting around waiting to be needed for the two minutes that they can contribute.

And really, the fact that we're caught up on this at all is concerning. It was one small suggestion in a sea of rather intelligent discourse mostly on team environments, structures, and management. Not technology.

Isn't "setting up your environment" pretty much a one time cost, though? In my head at least, losing a couple days up front doesn't matter as much, it's the time after that the needs to be optimized. But maybe that's just my work place where people tend to stay on the same team for years...

Shouldn't be.

When you automate "setting up your environment", you are able to switch between several of them, create new ones for forks or extra tests, and roll back to debug production issues.

Ignoring the one time aspect. It's the standardization that is important. Docker environments enforce uniformity that are beneficial for testing. No more of the "it works on my machine" excuses. Although the article mentioned development environment specifically, there is recurring benefit in being able to power up a Docker VM for testing purposes.

While I agree this sort of thing can be frustrating when starting a new company, I find that it is useful. If i can't get the system working on my dev machine, how can I be expected to debug the production site when there are problems?

Hum...

You are trading an opaque irreproducible environment for another opaque environment that you reproduce by copying verbatim.

Technically, it's progress. But I can't imagine how people get satisfied by this.

I'm not too experienced with Docker, but aren't Docker images built using Dockerfiles, which are essentially glorified shell scripts?

In that case, wouldn't the Dockerfile be a relatively transparent way to see what's needed to reproduce an environment?

Yes, yes they are.

And they're written down where you can read them yourself. And maybe even version controlled!

On the other hand, tracing back a dockerfile that pulls in an obscure one-off base image, then repeating that all the way up the chain, you can find yourself left with a dozen Dockerfiles that you need to read in the right order to know what you have.

That's if you can even find the original Dockerfiles - I recently ran into a situation where a container image was in the registry, but the original Dockerfile was completely lost.

Docker/containers in general move the complexity to a different plane, but they only move it - they don't eliminate it. Care needs to be taken to avoid situations just like the one above - or any of a number of other pitfalls - or you end up with an environment that's far more complex to understand than a VM housing a monolithic dev environment.

Reply on news.ycombinator.com