3 ms·

"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a mat

by vacri 11y ago

"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches." FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a similar time to build as a normal package (.deb) using an up-to-date base image, but is actually slower to deploy, since now my servers have to download a stupidly large container with build-essential (npm doesn't really survive without it), python (because npm maintainers use python frequently), and graphicsmagick (for the in-house app), instead of 'just the app' that's in a normal package. If your environment is simple enough that you don't have to be concerned with testing in 'staging' against staging databases or similar, then you're definitely not saving 'days', because your env just isn't that complicated.

justingood 11y ago
"The technology of deployment does not change 'minutes or hours' into 'days or months'" I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well. That's not to say Docker doesn't require the same attention to security as other options. This seems to me akin to running a downloaded base VM image without first doing updates.
- danieldk 11y ago
  Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well. Yes, and now you have to tailor the distribution in the container to the new language. Of course, the impact is smaller than changing one system that contains everything. However, this problem was long-solved before containers (as in OS-level virtualization) as well in virtualization (Xen, KVM, etc.). (Of course, FreeBSD had containers for ages, but they were largely ignored.)
- KaiserPro 11y ago
  Or, you could do what HPC has been doing for years and seperate the config from the machine. What do I mean by that? shared drives. Seriously, install python$ver plus dependenceies into /mnt/bin add it into your path. You now have a single source of (readonly optional) each binary version. this means that you can have many versions of the same software all compiled in a different way. But because they are in the path, they can be transparently managed. Also it means that much of the config management is now in one place, making joining nodes super simple.
  - DannoHung 11y ago
    We do this at my company and it is a fucking nightmare. Why? Because there are like 4 different operating environments and there isn't an official way to do installations and you also have to manage site installations of various packages for each version of each language dependency. And god forbid some environment variable is pointing to the wrong version of something because it's not just as simple as setting PATH and LD_LIBRARY_PATH when every thing and its mother tries to set its own fucking environment variables all pointing to wherever they think they were compiled at. No, it is much much MUCH better to actually have an application build with its dependencies and deploy with its dependencies. And you know how you fix issues with security patches? You have a real build system that rebuilds your binaries and you redeploy regularly.

by vacri 11y ago

justingood 11y ago

"The technology of deployment does not change 'minutes or hours' into 'days or months'" I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well. That's not to say Docker doesn't require the same attention to security as other options. This seems to me akin to running a downloaded base VM image without first doing updates.

danieldk 11y ago
Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well. Yes, and now you have to tailor the distribution in the container to the new language. Of course, the impact is smaller than changing one system that contains everything. However, this problem was long-solved before containers (as in OS-level virtualization) as well in virtualization (Xen, KVM, etc.). (Of course, FreeBSD had containers for ages, but they were largely ignored.)
KaiserPro 11y ago
Or, you could do what HPC has been doing for years and seperate the config from the machine. What do I mean by that? shared drives. Seriously, install python$ver plus dependenceies into /mnt/bin add it into your path. You now have a single source of (readonly optional) each binary version. this means that you can have many versions of the same software all compiled in a different way. But because they are in the path, they can be transparently managed. Also it means that much of the config management is now in one place, making joining nodes super simple.
- DannoHung 11y ago
  We do this at my company and it is a fucking nightmare. Why? Because there are like 4 different operating environments and there isn't an official way to do installations and you also have to manage site installations of various packages for each version of each language dependency. And god forbid some environment variable is pointing to the wrong version of something because it's not just as simple as setting PATH and LD_LIBRARY_PATH when every thing and its mother tries to set its own fucking environment variables all pointing to wherever they think they were compiled at. No, it is much much MUCH better to actually have an application build with its dependencies and deploy with its dependencies. And you know how you fix issues with security patches? You have a real build system that rebuilds your binaries and you redeploy regularly.