5 ms·

Ah, I think you're missing the point. What the OP was saying is that spending all that time to make docker work was a bit pointless. Especially as a VM makes n

Ah, I think you're missing the point. What the OP was saying is that spending all that time to make docker work was a bit pointless. Especially as a VM makes no real difference to the end user at this stage. Your points about DR and the like are valid, however if you are going to use puppet, the difference between deploying n docker instances (and keeping the state in the correct way) and VM instances are negligible. (yes, yes, docker is a chroot, so inherits the host's state, but you'll still need to control the docker environment.) I use cgroups everyday, to avoid memory exhaustion, (25k CPU render farm) and for that its grand. Running it on a public host? madness I say. For things that require high IO(even then its questionable, AUFS...), or low security perhaps.

vidarh 12y ago
> What the OP was saying is that spending all that time to make docker work was a bit pointless. Especially as a VM makes no real difference to the end user at this stage. I disagree. Given that you operate a 25k CPU render farm, perhaps you are no longer aware of how poorly devops tends to be managed in small shops. I'd argue Docker buys you more in those small environments, because in large environments you can build tools that works for your environment. In small environment, the traditional "solution" has been to brush these concerns under the carpet. Just getting repeatable builds of an environment so that you can ensure the dev, test, staging and live environments continue to bear a resemblance to each other is a massive improvement for many of this type of setups. That is, assuming that there are separate dev, test, staging and live environments - often you'll find all of it on a single server. Yes, really. Basically, people that think like OP terrify me, because too often we've taken over operations of applications from people who think like that, to find that the operational cost is staggering. We have one customer, for example, that have over the last few years easily paid several times what it would cost to properly re-engineer their application from scratch in time spent for us on operational issues because they've refused to accept that it's necessary. (EDIT: Said customer pays for this time, so on paper it works out well for us; in practice it's bad for us as it leads to lots of tension with the customer over all the issues, and we'd much rather have spent that time making their app better, and help them grow their revenue from it - long term that'd be far better for our customer relationship). This is a "simple PHP and MySQL" application. VMs aren't really a solution by themselves. It's not app-level isolation that "makes" Docker. It's the entire structure that encourages repeatable builds, a repository, and the light weight nature that encourages breaking things into smaller components. I agree that just Docker as isolation in a multi-tenant system is still scary. I'm currently working on deploying an application in VMs. With Docker in each VM. The VMs gives us the isolation we need in a multi-tenant system. Docker lets us ensure that dependencies between each component is well documented (or the components won't have access...), and that we have a decent image repository, and that we have ways of managing the entire lifecycle of each component. The two are complementary technologies. In a large enough environment you could solve the issues that Docker solves with process. In a small environment that process is usually non-existent or weak. > AUFS AUFS is not necessary. Btrfs or device mapper backends have been supported for a long time. And even then, for any data volums that needs high throughput you'd use a bind mount from the host.
viraptor 12y ago
He said "time to put everything on Docker and Puppet" - there are a few ways to understand it. Puppet could be used to only manage containers, or it could be used to deploy bare app containers and configure them. Docker work required would be different depending on where runtime and when prepare-time configs end, but it ties in with all of the points in my opinion and so I don't think it was pointless. If it's a part of a stable setup - that's great. (especially stuff like logging, backups, monitoring will usually affect your docker build to some degree and can be reused in other apps)

vidarh 12y ago

> What the OP was saying is that spending all that time to make docker work was a bit pointless. Especially as a VM makes no real difference to the end user at this stage. I disagree. Given that you operate a 25k CPU render farm, perhaps you are no longer aware of how poorly devops tends to be managed in small shops. I'd argue Docker buys you more in those small environments, because in large environments you can build tools that works for your environment. In small environment, the traditional "solution" has been to brush these concerns under the carpet. Just getting repeatable builds of an environment so that you can ensure the dev, test, staging and live environments continue to bear a resemblance to each other is a massive improvement for many of this type of setups. That is, assuming that there are separate dev, test, staging and live environments - often you'll find all of it on a single server. Yes, really. Basically, people that think like OP terrify me, because too often we've taken over operations of applications from people who think like that, to find that the operational cost is staggering. We have one customer, for example, that have over the last few years easily paid several times what it would cost to properly re-engineer their application from scratch in time spent for us on operational issues because they've refused to accept that it's necessary. (EDIT: Said customer pays for this time, so on paper it works out well for us; in practice it's bad for us as it leads to lots of tension with the customer over all the issues, and we'd much rather have spent that time making their app better, and help them grow their revenue from it - long term that'd be far better for our customer relationship). This is a "simple PHP and MySQL" application. VMs aren't really a solution by themselves. It's not app-level isolation that "makes" Docker. It's the entire structure that encourages repeatable builds, a repository, and the light weight nature that encourages breaking things into smaller components. I agree that just Docker as isolation in a multi-tenant system is still scary. I'm currently working on deploying an application in VMs. With Docker in each VM. The VMs gives us the isolation we need in a multi-tenant system. Docker lets us ensure that dependencies between each component is well documented (or the components won't have access...), and that we have a decent image repository, and that we have ways of managing the entire lifecycle of each component. The two are complementary technologies. In a large enough environment you could solve the issues that Docker solves with process. In a small environment that process is usually non-existent or weak. > AUFS AUFS is not necessary. Btrfs or device mapper backends have been supported for a long time. And even then, for any data volums that needs high throughput you'd use a bind mount from the host.

viraptor 12y ago

He said "time to put everything on Docker and Puppet" - there are a few ways to understand it. Puppet could be used to only manage containers, or it could be used to deploy bare app containers and configure them. Docker work required would be different depending on where runtime and when prepare-time configs end, but it ties in with all of the points in my opinion and so I don't think it was pointless. If it's a part of a stable setup - that's great. (especially stuff like logging, backups, monitoring will usually affect your docker build to some degree and can be reused in other apps)