Re:Kubernetes Production Patterns and Anti-Patterns
by majewsky on Saturday June 10, 2017 @11:55AM
(#14527779)
Depends on the tool in question. jq or awk are such common-place and light on dependencies that it's indeed unnecessarily complex.
The benefit is when a one-time tool is heavy on dependencies. For example, with OpenStack Swift (an S3-like object storage), a common one-time task is swift-ring-builder, which takes an inventory of available storage and creates a shared configuration file which describes how data is shared between storages. That's something you would run on a sysadmin's notebook, but it's included with Swift itself, so you would have to install a bunch of Python modules into a virtualenv.
In that case, it's probably easier to just use the Docker image for Swift that you have anyway, and run swift-ring-builder from there.
Re:Kubernetes Production Patterns and Anti-Patterns
by nunez on Saturday June 10, 2017 @10:15PM
(#14530274)
Thanks for the response. I agree that long-running or very heavily-polled services make the most sense for being containerised and that builtins usually don't.
The benefit is when a one-time tool is heavy on dependencies. For example, with OpenStack Swift (an S3-like object storage), a common one-time task is swift-ring-builder, which takes an inventory of available storage and creates a shared configuration file which describes how data is shared between storages. That's something you would run on a sysadmin's notebook, but it's included with Swift itself, so you would have to install a bunch of Python modules into a virtualenv.
In that case, it's probably easier to just use the Docker image for Swift that you have anyway, and run swift-ring-builder from there.