Hacker News Reader

Comment by lizxrice | Hacker News Reader

I'm a big Docker fan, but this is interesting to me mostly because it shows how it's hard to get started, particularly the opening few sentences about the paucity of documentation for helping you get going from scratch. There have been good guides, but they go out of date quickly! There's so much change (because it's still very much under development) that it's hard for someone coming to it fresh to figure out what's up-to-date and what isn't. For those of us working in container tech and tools this is a good lesson about making sure the entry curve isn't too steep.

View on HN

I'd argue that it wouldn't be that steep if Docker wasn't trying to do too much. There's so many moving parts - apart from regular process isolation, you've got to manage storage (which can be a pain in the ass) and firewall configuration (which is another very complicated and not well documented topic). In any non-trivial setup those two topics are already big.

Now add container management - understanding the split between images and containers, then how to publish and download images (which IMHO should be a completely separate project), how caching works so you could write a decent Dockerfile... And then there are features like Docker Swarm which I never touched and seem particularly complex to me.

It's way too many projects stuffed into one thing.

The feeling you describe reminds me of how I felt evaluating puppet and chef some years back - with a particular view to running the open source parts (not being dependent on third party support).

It felt like every other link led back to the various sales teams for the enterprise solutions, and there existed no page with a straightforward overview of all the components and what puppet / chef actually did.

Ansible was a breath of fresh air - as well as saltstack (but at the time it had too many holes in its security/transport story).

What resources would you recommend to get started for someone new to Docker? Given that it changes quickly it would be great to have recommendations from someone working with it.

I would strongly recommend first making sure you are comfortable with the concepts and architecture of decoupled systems and services. The biggest pain I see in practice are groups that come from monolithic software development backgrounds.

This article is a great example where in using docker for the first time they chose to attempt to run the state layer(database) in a container. State layers tend to be always available and difficult to scale horizontally anyway. This cancels out a decent chunk of the benefits of containers in production. If that team had more experience with service based architecture they would have known to use an third party database service provider(RDS) or host their own on a persistent server. Especially on their first experience with containers.

Echoing the above, this is extremely important. Before jumping into any of the container orchestration tools you should familiarize yourself with terminology of Docker and it's concepts. I made the mistake of jumping in to Swarm (still unstable IMO) and Docker Compose before fully grasping how containers talked to each other, along with many other concepts I should have read up on first. (Un)fortunately, Docker is changing rapidly and the documentation doesn't always keep up. If something in the official docs doesn't make sense, Google around to gain better context.

> This article is a great example where in using docker for the first time they chose to attempt to run the state layer(database) in a container.

One question I've had as I evaluate moving a Rails/Postgres app to GKE is whether I should abandon the thought and go with AWS/RDS, or containerize Postgres on GKE, or some third option. Has anyone else been part of a similar migration onto GKE, and how did it go?

On the other hand, which alternatives are easier?

I'm a NixOS fan, but have to use Docker at work occasionally and I have the feeling they are both difficult, but in "their" ways.

NixOS is a whole another can of worms. Nix-env conflicting with system profile, lagging Python packages, etc etc.

Not a Python dev, so I don't know about that.

But could you elaborate on the "Nix-env conflicting with system profile" thing? :)

This, for example: https://github.com/NixOS/nixpkgs/issues/18778

I support the idea of declarative configuration and dependencies, but I also realize that this is a very very hard thing to do, when each language have its own preferred package manager and they all expect a mutable environment.

(I tried NixOS for 2 months and switched back to Ubuntu. The issues are too numerous so far, despite heroic work of NixOS dev team)

What's hilarious is that we use both nixos and docker...

Why not?

I the configuration.nix of NixOS is a nice, small way to get your dev machines configured and installed with the stuff you like. Just copy it on your new machine and off you go :)

I don't know if I would ever use Nix instead of the more language specific packet managers.

Nix derivation and nix store managed artifacts is a superior model to many language specific package managers (though the learning curve is non-trivial), we use it with Haskell extensively, for instance.

I can't wait for someone to write a great book on Nix. I was so lost in it. I had it running on my home server, and needing to compile my own things because of what Nixpkgs lacked was a constant struggle.

It was a very frustrating experience. A frustration which was led by the fact that i could tell how powerful Nixos was - if only i could grok it.

Yeah a book on nixos would be valuable I think. Understanding nixos really comes down to reading all the docs then trying to accomplish what you need to do, learning by doing and reading source code.

I love nix, my biggest gripe would be that the Nix language is dynamically typed...

This is actually a good idea, they complement each other nicely.

No. They do not. Docker wants to manage containers but nix wants them in the store. I went so far as writing a derivation and tool for pulling a container into the nix store without docker so it could be docker loaded.

I really don't like docker.

At the very least Nix would make your Docker builds more reliable. Granted, you could then start making arguments for "why use Docker at all", but i can't answer that.

I hate to say it but this article sounds like it was written by your typical one trick pony, technology averse client services agency.

They are the last to adopt new things as they tend to be the lowest on the talent chain as meeting estimates, often via client coercion or moving goalposts, is much more important than successful solutions over the mid-ling term.

For anyone reading this that is part of that group, leave stuff like containers to outside organizations with stronger engineering talent and focus on what ultimate makes you money which is client networking and sales.

>> written by your typical one trick pony, technology averse client services agency.

You can be forgiven to have that perception. Sorry, but that's not true.

>> They are the last to adopt new things

Are you actually complaining about this? Well it just shows your immaturity as an engineer and your lack of understanding of how tech startups are run. This is something my very first manager drilled into me on my first job a decade ago, as should yours have - not to use any v1.0 software for ANY CLIENT PROJECT, but only for your hobby projects. Wait atleast for a v1.1

>> as they tend to be the lowest on the talent chain as meeting estimates

Please don't embarrass yourself. There are comments on this thread from the maintainers of both docker and kubernetes projects as well as people who have been running docker in production for much longer than us. None of them think that this article is stupid. Now, if you think you're more talented than us and all of them combined, just tell us why?

Your comments would be much more useful if you could say something like - "They are so stupid because they couldn't figure out X which was as easy as doing Y."

Anytime you want to go toe to toe let me know. Being cheaper and more predictable is so different from actually having to make the best possible product.

This is absolutely the truth. Docker isn't something you can get an afternoon briefing on in a meeting room and then kinda wing it on implementation. How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

>> afternoon briefing on in a meeting room and then kinda wing it on implementation

I don't know where did you get that impression from. The article clearly states we ran docker in PRODUCTION for 6 months. The article wasn't written after a docker trial over a weekend.

>> How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

Pretty much everyone who's commented here and have had docker experience in production, agrees that a docker documentation sucks. Maintainers of the dockers project have already conceded that this is an issue so I don't why you're saying this.

That you're making this claim is an almost comically ironic indicator to me that you are exactly what was described.

every time i've had to touch docker, i've had to sit down and figure it all out my self. this includes strace and gdb and tcpdump.

not a fan.

Reply on news.ycombinator.com