5 ms·

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 pauci

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.

d33 10y ago
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.
- e12e 10y ago
  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).
k__ 10y ago
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.
- atemerev 10y ago
  NixOS is a whole another can of worms. Nix-env conflicting with system profile, lagging Python packages, etc etc.
  - k__ 10y ago
    Not a Python dev, so I don't know about that. But could you elaborate on the "Nix-env conflicting with system profile" thing? :)
    - atemerev 10y ago
      This, for example: https://github.com/NixOS/nixpkgs/issues/18778 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)
- Ixiaus 10y ago
  What's hilarious is that we use both nixos and docker...
  - atemerev 10y ago
    This is actually a good idea, they complement each other nicely.
    - Ixiaus 10y ago
      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.
      - 10y ago
adamwi 10y ago
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.
- hiou 10y ago
  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.
  - allochthon 10y ago
    > 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?
  - kossae 10y ago
    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.
beachstartup 10y ago
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.
hiou 10y ago
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.
- swap32 10y ago
  >> 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."
  - deleted 10y ago
    [deleted]
  - hiou 10y ago
    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.
- fapjacks 10y ago

d33 10y ago

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.

e12e 10y ago
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).

k__ 10y ago

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.

atemerev 10y ago
NixOS is a whole another can of worms. Nix-env conflicting with system profile, lagging Python packages, etc etc.
- k__ 10y ago
  Not a Python dev, so I don't know about that. But could you elaborate on the "Nix-env conflicting with system profile" thing? :)
  - atemerev 10y ago
    This, for example: https://github.com/NixOS/nixpkgs/issues/18778 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)
Ixiaus 10y ago
What's hilarious is that we use both nixos and docker...
- atemerev 10y ago
  This is actually a good idea, they complement each other nicely.
  - Ixiaus 10y ago
    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.
    - 10y ago

adamwi 10y ago

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.

hiou 10y ago
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.
- allochthon 10y ago
  > 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?
- kossae 10y ago
  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.

beachstartup 10y ago

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.

hiou 10y ago

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.

swap32 10y ago
>> 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."
- deleted 10y ago
  [deleted]
- hiou 10y ago
  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.
fapjacks 10y ago