3 ms·

To be fair, docker itself introduced no radical new technologies, but it did introduce a lot of convenience. Containers had been available for a long time, but

by gnur 8y ago

To be fair, docker itself introduced no radical new technologies, but it did introduce a lot of convenience. Containers had been available for a long time, but the convenience of a Dockerfile + docker hub made at accessible for the non hard code linux/bsd people. What other solution for the easy portability do you know? Or how would you propose to handle this? If it is easier then docker build && docker push and docker pull on the other side I'm all ears!

lmm 8y ago
> What other solution for the easy portability do you know? Or how would you propose to handle this? Puppet for the server-automation part. Languages that make it easy to produce a "fat binary" for the isolation part. Docker solves a real problem for languages where deployment is a mess, like Python. It just grates on me when the same people who spent the last 10 years mocking Java (which does essentially the useful parts of docker) are suddenly enthusiastic about the same kind of solution to the same kind of problem now that it has a trendy name.
e12e 8y ago
The main benefit docker introduced, was leading developers to at least consider "configuration injection" and "stateless installs" ("12 factor apps"). If upstream supplies a decent docker image, chances are that means the package is more amenable to scripting and running in a chroot/jail/container - and documents it dependencies somewhat. That said, snaphotting the "state" of your container/jail can be nice. Recently I used the official ruby images, and could build a custom image to use with our self-hosted gitlab (with built-in docker registry) that a) got a standard Debian based ruby image and applied updates, and b) built freetds for connecting to mssql. Now I can quickly update that base image as needed, while the CI jobs testing our rails projects "only" need a "bundle install" before running tests. And the scripts are largely reusable across heterogeneous ruby versions (yes I hope we can get all projects up on a recent ruby..).

by gnur 8y ago

lmm 8y ago

> What other solution for the easy portability do you know? Or how would you propose to handle this? Puppet for the server-automation part. Languages that make it easy to produce a "fat binary" for the isolation part. Docker solves a real problem for languages where deployment is a mess, like Python. It just grates on me when the same people who spent the last 10 years mocking Java (which does essentially the useful parts of docker) are suddenly enthusiastic about the same kind of solution to the same kind of problem now that it has a trendy name.

e12e 8y ago

The main benefit docker introduced, was leading developers to at least consider "configuration injection" and "stateless installs" ("12 factor apps"). If upstream supplies a decent docker image, chances are that means the package is more amenable to scripting and running in a chroot/jail/container - and documents it dependencies somewhat. That said, snaphotting the "state" of your container/jail can be nice. Recently I used the official ruby images, and could build a custom image to use with our self-hosted gitlab (with built-in docker registry) that a) got a standard Debian based ruby image and applied updates, and b) built freetds for connecting to mssql. Now I can quickly update that base image as needed, while the CI jobs testing our rails projects "only" need a "bundle install" before running tests. And the scripts are largely reusable across heterogeneous ruby versions (yes I hope we can get all projects up on a recent ruby..).