4 ms·

It's exactly these kinds of issues that add to my impression that containerisation, and Docker in particular, is more of a religion than a solution. I don't ha

It's exactly these kinds of issues that add to my impression that containerisation, and Docker in particular, is more of a religion than a solution. I don't hate it per se, but I'm just a bit fed up of people telling me I should be using it without being able to articulate what problem it's going to solve for me. At the moment it feels like just one more thing to learn, and one more moving part, that isn't strictly necessary in order to achieve what I need, which is basically to deploy software without a heap of aggravation.

tracker1 10y ago
For me, with appropriate base containers, the real benefit is load time... booting a full VM has a lot of overhead, and takes quite a while. Loading a dockerized app is much faster. If you're extending this for your testing environment, that can be a huge win over a larger team. Being able to load more containers than VMs onto a server is another piece... Beyond that, it's not too much different than running VMs was earlier on, it took orchestration and tooling to get working and there were growing pains... much of that abstracted well before becoming popular. In the end, containers are just another step towards wherever we are going... I think it's pretty nice, but the tooling is just now starting to catch up.
- bartread 10y ago
  I think that's a legitimate argument but deployments to VMs that are already up and running can also be fast, and for me they are, so it's not overwhelming. My feeling is that one day I'll reach a level of complexity/deployment time where the benefits of containerisation become clear, but I'm not there yet, nor anywhere near it.
  - tracker1 10y ago
    That's a discipline issue though... shared nothing start from zero... The "docker" method doesn't upgrade an app already running in a container, it creates a new one.
koffiezet 10y ago
I wouldn't use it for everything, but whenever I encounter a problem where applications crash or behave weirdly - the problem is with the app, not the container technology. It's not because the problem only manifests itself in a container that the problem is suddenly "docker". And as with every technology, you have to understand it's strength and weaknesses. I use Docker internally and in production with very few issues other than it advancing way too fast at the moment, but am always amazed how many people dive in head-first into a Docker adventure without understanding what it is and how it actually works and it's limitations. This is from the perspective of a relatively small development company with applications where scaling is a non-issue. Our problem is that we have a ton of active projects. To give you an idea, our internal CI now still has over 500 active build jobs after a recent cleanup. This CI is the first thing where Docker shines, it was an absolute god-send. I got rid of tons of frankenstein build slaves with unpredictable configurations, and replaced them with one huge VM running docker, with build images per project. This made this massive mess suddenly perfectly manageable, documented and version controlled. Need to build something in a build configuration from 1 year ago? Not something I want to do every day, but not completely impossible either, since I still have the exact same docker image in our internal registry. Other than that, upgrading internal tools became a lot easier. Everything used internally (redmine, jenkins, ...) is containerized, which means it can easily be tested, migrated, cloned, ... It enforces data separation, which means it's clearer and easier to backup/restore and test these things. It means that now whenever a new version is released I can easily test this with our real data to see if there would be any problems in our configuration, and if not, quickly deploy a new version.
- alauda 10y ago
  Checkout https://github.com/jenkinsci/hyper-slaves-plugin https://github.com/jenkinsci/hyper-slaves-plugin. This plugin will launch your buildjobs as on-demand containers in Hyper.sh, then you don't even need the long-running huge VM!
- so0k 10y ago
  it would help these people to read http://docker-saigon.github.io/post/Docker-Caveats/ http://docker-saigon.github.io/post/Docker-Caveats/

tracker1 10y ago

For me, with appropriate base containers, the real benefit is load time... booting a full VM has a lot of overhead, and takes quite a while. Loading a dockerized app is much faster. If you're extending this for your testing environment, that can be a huge win over a larger team. Being able to load more containers than VMs onto a server is another piece... Beyond that, it's not too much different than running VMs was earlier on, it took orchestration and tooling to get working and there were growing pains... much of that abstracted well before becoming popular. In the end, containers are just another step towards wherever we are going... I think it's pretty nice, but the tooling is just now starting to catch up.

bartread 10y ago
I think that's a legitimate argument but deployments to VMs that are already up and running can also be fast, and for me they are, so it's not overwhelming. My feeling is that one day I'll reach a level of complexity/deployment time where the benefits of containerisation become clear, but I'm not there yet, nor anywhere near it.
- tracker1 10y ago
  That's a discipline issue though... shared nothing start from zero... The "docker" method doesn't upgrade an app already running in a container, it creates a new one.

koffiezet 10y ago

I wouldn't use it for everything, but whenever I encounter a problem where applications crash or behave weirdly - the problem is with the app, not the container technology. It's not because the problem only manifests itself in a container that the problem is suddenly "docker". And as with every technology, you have to understand it's strength and weaknesses. I use Docker internally and in production with very few issues other than it advancing way too fast at the moment, but am always amazed how many people dive in head-first into a Docker adventure without understanding what it is and how it actually works and it's limitations. This is from the perspective of a relatively small development company with applications where scaling is a non-issue. Our problem is that we have a ton of active projects. To give you an idea, our internal CI now still has over 500 active build jobs after a recent cleanup. This CI is the first thing where Docker shines, it was an absolute god-send. I got rid of tons of frankenstein build slaves with unpredictable configurations, and replaced them with one huge VM running docker, with build images per project. This made this massive mess suddenly perfectly manageable, documented and version controlled. Need to build something in a build configuration from 1 year ago? Not something I want to do every day, but not completely impossible either, since I still have the exact same docker image in our internal registry. Other than that, upgrading internal tools became a lot easier. Everything used internally (redmine, jenkins, ...) is containerized, which means it can easily be tested, migrated, cloned, ... It enforces data separation, which means it's clearer and easier to backup/restore and test these things. It means that now whenever a new version is released I can easily test this with our real data to see if there would be any problems in our configuration, and if not, quickly deploy a new version.

alauda 10y ago
Checkout https://github.com/jenkinsci/hyper-slaves-plugin https://github.com/jenkinsci/hyper-slaves-plugin. This plugin will launch your buildjobs as on-demand containers in Hyper.sh, then you don't even need the long-running huge VM!
so0k 10y ago
it would help these people to read http://docker-saigon.github.io/post/Docker-Caveats/ http://docker-saigon.github.io/post/Docker-Caveats/