4 ms·

I would rather say "goodbye docker", period. Having used it a bit, I have concluded that it is just not a very good or mature tool. Once you scratch under the s

by diebir 11y ago

I would rather say "goodbye docker", period. Having used it a bit, I have concluded that it is just not a very good or mature tool. Once you scratch under the surface, things cease to be easy or stop working at all. It makes you wonder how it's been this long and nobody stumbled upon an issue that you uncover 30 minutes into tool's use. Docker does have it's uses, but in the majority of cases you are better off using native OS package and dependency management (RPM/YUM in the case on Redhat-based distros). One very obvious thing is that package managers usually track versions and dependencies and allow for install actions to happen based on the versions delta. With Docker you just replace the whole environment, which is fine, unless some of the data context is outside of Docker. I think the majority of Docker uses are of a class "I can't figure out how to manage dependencies for a given OS, so I am going to skirt the issue by using Docker".

meddlepal 11y ago
Well... that might be a reason why it's popular. I think the very snappy boot up process for a container is also very appealing. For example, t2.micro's on AWS seem to take at least 30 seconds which is frustratingly slow if you're changing stuff often but only touching application/service dependencies.
- creshal 11y ago
  It's not "docker or VMs", it's "docker or other container frameworks". Compared to those, Docker seems to come with a ludicrous list of caveats and workarounds.
  - meddlepal 11y ago
    Good point. I haven't kept up with the maturity status of other container frameworks though so I'm not sure how prevalent stuff like Rocket is in the wild.
s986s 11y ago
You say that as if its a bad thing. Isnt the evolution in development within making it more intuitive? I love the 10,000 line man page as much as the next dev, except I Dont. Docker solves a problem, standizing scalability and microservices without the need to think about whether its on the same or diff machines from developing the application. Honestly, I think it could be better. I wouldnt mind if the volume concept was easier for me to wrap my head around. I would like the cleanup process to be less worrysome. But thet have built an awesome solution and it opensource. What more can you ask for?
- voidr 11y ago
  Have you tried Chef, Puppet, Ansible etc?
szastupov 11y ago
>I can't figure out how to manage dependencies for a given OS It's actually: "Distro-provided dependencies are two-three years old and I don't want to deal with backports, ppas or whatever to get a fresh stable version of Python, Node or anything else."
volent 11y ago
"It makes you wonder how it's been this long and nobody stumbled upon an issue that you uncover 30 minutes into tool's use." Either you're doing something wrong or everybody's extremely lucky. If you've used Docker for 30 minutes I would bet on the former :)
- zimbatm 11y ago
  Or everyone got used to it and don't consider it being an issue. I believe that the filesystem layering feature in Docker is an anti-feature. It depends on unstable kernel features to work properly and doesn't really address the caching issues properly. Dependencies are usually in a tree, not linear like presented in a Dockerfile.
- rajeevk 11y ago
  Exactly! My company is extensively using docker. It has made deployment and maintaining different versions too smooth.
piva00 11y ago
Having worked for some time with configuration management and backend development and seeing the growing pains that happen after any "non-trivial" use case of it like: obscure declarative languages/DSLs, tangled messes of declarative vs scripted configurations, inter-dependencies that are not so obvious until you hit a corner case, etc., I can say that Docker has been a breeze, even when I encounter a breaking bug in a new release that breaks it somehow. It's easier to get our devs wrapping all of their dependencies in a container, it's easier to just deploy the container, it's easier to separate what's "state" and "data" that should be maintained from the application and what's throwable. Docker helps a lot to get away from the snowflake-machine mentality, everything is ephemeral so think carefully what you really need not to be like that and treat those cases like they should. I do understand a lot of criticism about Docker but having worked with almost every mainstream configuration management tool (CFEngine, Puppet, Chef and Ansible) I can say I truly prefer to only have to care about Docker (or containers, I'm taking a look at other solutions atm) than the tangled mess that every single of them become later on. And I'm sorry, only using "package managers" don't cut for the vast majority of deployments, you still have to manage configuration files, env vars and all of the other ugly mess. How long have you worked with a scale of hundreds to thousands of automated servers?
- voidr 11y ago
  > Having worked for some time with configuration management and backend development and seeing the growing pains that happen after any "non-trivial" use case of it like: obscure declarative languages/DSLs, tangled messes of declarative vs scripted configurations, inter-dependencies that are not so obvious until you hit a corner case, etc., I can say that Docker has been a breeze, even when I encounter a breaking bug in a new release that breaks it somehow. I don't really see how the Docker model is better. I wouldn't trust a person who wrote a terrible Puppet file to work on a Docker container. I can understand that from a Devops point a view, it's more convenient, however you can easily just build a VM image with Puppet and deploy that to your billions of servers.

by diebir 11y ago

meddlepal 11y ago

Well... that might be a reason why it's popular. I think the very snappy boot up process for a container is also very appealing. For example, t2.micro's on AWS seem to take at least 30 seconds which is frustratingly slow if you're changing stuff often but only touching application/service dependencies.

creshal 11y ago
It's not "docker or VMs", it's "docker or other container frameworks". Compared to those, Docker seems to come with a ludicrous list of caveats and workarounds.
- meddlepal 11y ago
  Good point. I haven't kept up with the maturity status of other container frameworks though so I'm not sure how prevalent stuff like Rocket is in the wild.

s986s 11y ago

You say that as if its a bad thing. Isnt the evolution in development within making it more intuitive? I love the 10,000 line man page as much as the next dev, except I Dont. Docker solves a problem, standizing scalability and microservices without the need to think about whether its on the same or diff machines from developing the application. Honestly, I think it could be better. I wouldnt mind if the volume concept was easier for me to wrap my head around. I would like the cleanup process to be less worrysome. But thet have built an awesome solution and it opensource. What more can you ask for?

voidr 11y ago
Have you tried Chef, Puppet, Ansible etc?

szastupov 11y ago

>I can't figure out how to manage dependencies for a given OS It's actually: "Distro-provided dependencies are two-three years old and I don't want to deal with backports, ppas or whatever to get a fresh stable version of Python, Node or anything else."

volent 11y ago

"It makes you wonder how it's been this long and nobody stumbled upon an issue that you uncover 30 minutes into tool's use." Either you're doing something wrong or everybody's extremely lucky. If you've used Docker for 30 minutes I would bet on the former :)

zimbatm 11y ago
Or everyone got used to it and don't consider it being an issue. I believe that the filesystem layering feature in Docker is an anti-feature. It depends on unstable kernel features to work properly and doesn't really address the caching issues properly. Dependencies are usually in a tree, not linear like presented in a Dockerfile.
rajeevk 11y ago
Exactly! My company is extensively using docker. It has made deployment and maintaining different versions too smooth.

piva00 11y ago

Having worked for some time with configuration management and backend development and seeing the growing pains that happen after any "non-trivial" use case of it like: obscure declarative languages/DSLs, tangled messes of declarative vs scripted configurations, inter-dependencies that are not so obvious until you hit a corner case, etc., I can say that Docker has been a breeze, even when I encounter a breaking bug in a new release that breaks it somehow. It's easier to get our devs wrapping all of their dependencies in a container, it's easier to just deploy the container, it's easier to separate what's "state" and "data" that should be maintained from the application and what's throwable. Docker helps a lot to get away from the snowflake-machine mentality, everything is ephemeral so think carefully what you really need not to be like that and treat those cases like they should. I do understand a lot of criticism about Docker but having worked with almost every mainstream configuration management tool (CFEngine, Puppet, Chef and Ansible) I can say I truly prefer to only have to care about Docker (or containers, I'm taking a look at other solutions atm) than the tangled mess that every single of them become later on. And I'm sorry, only using "package managers" don't cut for the vast majority of deployments, you still have to manage configuration files, env vars and all of the other ugly mess. How long have you worked with a scale of hundreds to thousands of automated servers?

voidr 11y ago
> Having worked for some time with configuration management and backend development and seeing the growing pains that happen after any "non-trivial" use case of it like: obscure declarative languages/DSLs, tangled messes of declarative vs scripted configurations, inter-dependencies that are not so obvious until you hit a corner case, etc., I can say that Docker has been a breeze, even when I encounter a breaking bug in a new release that breaks it somehow. I don't really see how the Docker model is better. I wouldn't trust a person who wrote a terrible Puppet file to work on a Docker container. I can understand that from a Devops point a view, it's more convenient, however you can easily just build a VM image with Puppet and deploy that to your billions of servers.