4 ms·

I deploy big complex projects this way. I've built sophisticated automation to achieve this, so it's all reproducible. I just don't use Docker that's all. It

I deploy big complex projects this way. I've built sophisticated automation to achieve this, so it's all reproducible. I just don't use Docker that's all. It doesn't bring anything to the able that I can't achieve more simply some other way. And it has it's own problems. I've been a sysadmin for 25+ years and I've administered production DNS server, mailservers, web server, app servers, routers, switches ... I think stuff like docker and k8 appeals to people today because it promises that you don't have t understand any of that old stuff. But to me it just makes my life harder because I don't need the underlying tech abstracted away. If anything it makes my life harder to add an unfamiliar layer on top. I'm not worried, there will always be market for guys like me. When the fancy new stuff stops working, someone has to fix it.

Xelbair 7y ago
You know why docker is being used instead of this approach? Because your automation is made by you, and for you, no one else can take it over if you leave. And even if they can take it over, they will have way higher salary - compared to the container based system.
- scaryclam 7y ago
  To be fair, pretty much every single place I've seen docker in use there have been custom automation systems in place. Docker creates artifacts, not automation, so it really doesn't help solve that problem. Kubernetes on the other hand, does help, though you'll never get away from some custom parts in a delivery system, as all systems are different. That's not a bad thing.
acdha 7y ago
I've also been doing that for about 25 years, with a similar list, and full automation since ~2001 or so. I haven't found that approach to scale very well because it requires a much higher level of sysadmin skill & application-level knowledge, maintaining a somewhat extensive list of backports or custom builds, and the ability to customize each application to work with a filesystem layout which avoids the conflicts which inevitably arise. Automation is important to making that work at all but it still means that any time things change hands there's a non-trivial amount of code to review before you are confident about making changes and it tends to require elevated privileges or greater levels of coordination between the developers and operators. The reason why containers are popular is that you get a simple way to manage all of that and it's completely standard on every project. App A doesn't need to be modified to coexist with App B because they're running in an isolated environment, the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances, builds are much faster because of the layering model, you can deploy a single tested image with no chance of differences creeping into your automated deployments in testing & production, etc. All of that is something which you can achieve with other tools but there's a huge win to not having to reinvent each wheel when you encounter it and being able to reuse other people's work easily. Note also that I said “containers” instead of Docker — some people might prefer, say, podman / buildah but the key concepts of having a clear support boundary with an isolated-by-default filesystem model are really more important than the implementation.
- gerbilly 7y ago
  > the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances I disagree on that point. Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break? If a sysadmin gets a say in how the container images are configured, it usually works out much better. Also partitioning the filesystem to avoid dependency clashes used to be more important when I used rack mounted servers. Now it's easy enough to deploy separate cloud instances to partition things. And it's a real VM with real tools on it so I can diagnose problems if they arise.
  - acdha 7y ago
    > Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break? In my experience, that's been about the same for any mode of deployment by a developer without ops experience. The main thing Docker added was standardizing the mechanics and avoiding certain classes of errors like not having reproducible builds or deploying local artifacts inconsistently.

Xelbair 7y ago

You know why docker is being used instead of this approach? Because your automation is made by you, and for you, no one else can take it over if you leave. And even if they can take it over, they will have way higher salary - compared to the container based system.

scaryclam 7y ago
To be fair, pretty much every single place I've seen docker in use there have been custom automation systems in place. Docker creates artifacts, not automation, so it really doesn't help solve that problem. Kubernetes on the other hand, does help, though you'll never get away from some custom parts in a delivery system, as all systems are different. That's not a bad thing.

acdha 7y ago

I've also been doing that for about 25 years, with a similar list, and full automation since ~2001 or so. I haven't found that approach to scale very well because it requires a much higher level of sysadmin skill & application-level knowledge, maintaining a somewhat extensive list of backports or custom builds, and the ability to customize each application to work with a filesystem layout which avoids the conflicts which inevitably arise. Automation is important to making that work at all but it still means that any time things change hands there's a non-trivial amount of code to review before you are confident about making changes and it tends to require elevated privileges or greater levels of coordination between the developers and operators. The reason why containers are popular is that you get a simple way to manage all of that and it's completely standard on every project. App A doesn't need to be modified to coexist with App B because they're running in an isolated environment, the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances, builds are much faster because of the layering model, you can deploy a single tested image with no chance of differences creeping into your automated deployments in testing & production, etc. All of that is something which you can achieve with other tools but there's a huge win to not having to reinvent each wheel when you encounter it and being able to reuse other people's work easily. Note also that I said “containers” instead of Docker — some people might prefer, say, podman / buildah but the key concepts of having a clear support boundary with an isolated-by-default filesystem model are really more important than the implementation.

gerbilly 7y ago
> the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances I disagree on that point. Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break? If a sysadmin gets a say in how the container images are configured, it usually works out much better. Also partitioning the filesystem to avoid dependency clashes used to be more important when I used rack mounted servers. Now it's easy enough to deploy separate cloud instances to partition things. And it's a real VM with real tools on it so I can diagnose problems if they arise.
- acdha 7y ago
  > Just taking a docker image from a developer and deploying that to production does not work to well in my experience, and guess who gets the support calls when things break? In my experience, that's been about the same for any mode of deployment by a developer without ops experience. The main thing Docker added was standardizing the mechanics and avoiding certain classes of errors like not having reproducible builds or deploying local artifacts inconsistently.