4 ms·

You're giving the credit of automation to docker, which isn't where the credit belongs. It's pretty easy to get the same portability and testing without contain

You're giving the credit of automation to docker, which isn't where the credit belongs. It's pretty easy to get the same portability and testing without containers (this is what was happening long before docker was launched). Not to say that the OP shouldnt have done it, but I'm kind of tired of seeing the whole portability thing still being put up as if it's only viable with containerised solutions.

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..).
hoffs 8y ago
Care to expand on the portability and testing without containers?
- elbear 8y ago
  You get portability by using any provisioning system: Ansible, Puppet, Chef. Although, it's not exactly the same thing, because with Docker you have everything already installed in the image. I've only used Ansible and I was never happy with its dynamic nature.
  - viraptor 8y ago
    You don't get portability from chef and others. You get a framework where you can implement your deployment with a case for each system you want to target. Past some toy examples, it's on you to make it "portable".
    - elbear 8y ago
      By portability I was referring to being able to move your application to different servers by running your provisioning system.
    - larrywright 8y ago
      This is 100% correct. If you go look at the Chef cookbooks for any popular piece of software, say Apache or MySQL, the code is littered with conditional logic and attributes for different Linux distributions (not even considering entirely different operating systems). Every distro has different packages as dependencies, install locations, configuration file locations, service management, etc. Docker (all container solutions really) aren't a panacea, but they solve a very real problem.
  - flossyspeaker 8y ago
    What do you mean by dynamic nature? Because how I've been using it it's very much static to what I have defined in my inventory.
michaelcampbell 8y ago
> portability thing still being put up as if it's only viable with containerised solutions. You're arguing a point never made. That containers make things portable is not saying that's the ONLY thing that makes things portable. I find using containers a lot easier to be portable when I have multiple apps that bizarrely require different versions of, say, python, or python libs and the same version of python.

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..).

hoffs 8y ago

Care to expand on the portability and testing without containers?

elbear 8y ago
You get portability by using any provisioning system: Ansible, Puppet, Chef. Although, it's not exactly the same thing, because with Docker you have everything already installed in the image. I've only used Ansible and I was never happy with its dynamic nature.
- viraptor 8y ago
  You don't get portability from chef and others. You get a framework where you can implement your deployment with a case for each system you want to target. Past some toy examples, it's on you to make it "portable".
  - elbear 8y ago
    By portability I was referring to being able to move your application to different servers by running your provisioning system.
  - larrywright 8y ago
    This is 100% correct. If you go look at the Chef cookbooks for any popular piece of software, say Apache or MySQL, the code is littered with conditional logic and attributes for different Linux distributions (not even considering entirely different operating systems). Every distro has different packages as dependencies, install locations, configuration file locations, service management, etc. Docker (all container solutions really) aren't a panacea, but they solve a very real problem.
- flossyspeaker 8y ago
  What do you mean by dynamic nature? Because how I've been using it it's very much static to what I have defined in my inventory.

michaelcampbell 8y ago

> portability thing still being put up as if it's only viable with containerised solutions. You're arguing a point never made. That containers make things portable is not saying that's the ONLY thing that makes things portable. I find using containers a lot easier to be portable when I have multiple apps that bizarrely require different versions of, say, python, or python libs and the same version of python.