3 ms·

Did you have to change anything during the implementation? What about habits compared to deploy on VMs/DSs? What's you experience regarding a long running? Did

by bontoJR 12y ago

Did you have to change anything during the implementation? What about habits compared to deploy on VMs/DSs? What's you experience regarding a long running? Did you face any issue?

piva00 12y ago
We had to change how we managed services, I think it was for a better way, we were too much reliant on instances being available all the time, although I tried to always think with an HA/redundancy mind most of our team failed to do that. We're now using Docker with CoreOS (and fleet), so it has not been without headaches (mostly in part from CoreOS and btrfs and fleet scheduling going afoul), but we're much more resilient. Compared to VMs we adopted a lot more of a "this is disposable" mindset, we persist any data that must not be destroyed in a failure in an external volume and treat the instance and service as something unreliable, pretty much it's always "Game Day", before deploying something we've already tried to cover the basics of HA (what happens if this service suddenly stops? How is the rest of the system behave? How do we make it automatically restart or reprovision?). As I said, most of our issues regarded CoreOS (especially running with btrfs, getting out of space for metadata was a pain in the ass for months) but right now, after moving to ext4 + overlayfs we've been running without issues for a combined 28,800 hours of instance time (roughly NO issue in half a month in an environment running 30+ deploys a day). I've not stated that we're perfect, very far from it, but Docker itself has not been a pain in production. Our private registry is currently running in an Ubuntu-based instance for more than 6 months non-stop (and we push/pull a lot of data from it everyday).
- vacri 12y ago
  Compared to VMs we adopted a lot more of a "this is disposable" mindset There is nothing particularly magical about Docker that means you can't consider VMs equally as disposable. It's a mindset change about how you build your product, not something inherent to Docker. It's the original concept behind AWS's EC2 - treat your VMs as disposable, and store state elsewhere.
  - Huggernaut 12y ago
    You are correct of course but in my experience with Docker so far, it's much easier to get into this mindset, the more ephemeral your "disposable unit" is insomuch as VMs tend to stick around longer than Docker containers and occasionally you might find yourself saying, "this is ok for now" but your barrier for that is higher if you have to deal with things more often in flux.

by bontoJR 12y ago

Did you have to change anything during the implementation? What about habits compared to deploy on VMs/DSs? What's you experience regarding a long running? Did you face any issue?

piva00 12y ago

We had to change how we managed services, I think it was for a better way, we were too much reliant on instances being available all the time, although I tried to always think with an HA/redundancy mind most of our team failed to do that. We're now using Docker with CoreOS (and fleet), so it has not been without headaches (mostly in part from CoreOS and btrfs and fleet scheduling going afoul), but we're much more resilient. Compared to VMs we adopted a lot more of a "this is disposable" mindset, we persist any data that must not be destroyed in a failure in an external volume and treat the instance and service as something unreliable, pretty much it's always "Game Day", before deploying something we've already tried to cover the basics of HA (what happens if this service suddenly stops? How is the rest of the system behave? How do we make it automatically restart or reprovision?). As I said, most of our issues regarded CoreOS (especially running with btrfs, getting out of space for metadata was a pain in the ass for months) but right now, after moving to ext4 + overlayfs we've been running without issues for a combined 28,800 hours of instance time (roughly NO issue in half a month in an environment running 30+ deploys a day). I've not stated that we're perfect, very far from it, but Docker itself has not been a pain in production. Our private registry is currently running in an Ubuntu-based instance for more than 6 months non-stop (and we push/pull a lot of data from it everyday).

vacri 12y ago
Compared to VMs we adopted a lot more of a "this is disposable" mindset There is nothing particularly magical about Docker that means you can't consider VMs equally as disposable. It's a mindset change about how you build your product, not something inherent to Docker. It's the original concept behind AWS's EC2 - treat your VMs as disposable, and store state elsewhere.
- Huggernaut 12y ago
  You are correct of course but in my experience with Docker so far, it's much easier to get into this mindset, the more ephemeral your "disposable unit" is insomuch as VMs tend to stick around longer than Docker containers and occasionally you might find yourself saying, "this is ok for now" but your barrier for that is higher if you have to deal with things more often in flux.