4 ms·

> See, the expensive part? it's not the ram, it's sysadmin time. And that's why I like containers, because the sysadmin time of updating and patching all VMs I

by porker 13y ago

> See, the expensive part? it's not the ram, it's sysadmin time. And that's why I like containers, because the sysadmin time of updating and patching all VMs I own (and manage for friends/clients) is huge. Yes, I should probably use chef/puppet. The potential incompatibility issues with automated VM upgrades are probably the same as upgrading the container's OS. But mentally it feels more risky.

dspillett 13y ago
> because the sysadmin time of updating and patching all VMs I own There is a key difference between your circumstance the person you are replying to: you are managing a farm of your own VMs so that admin time is your's to find. If the VMs are sold to thers so you are just hosting them, then the VM updates are someone else's problem and the admin time that becomes your problem is dealing with people whose VMs that are (accidentally usually, but not always) abusing shared resources. This is something you don't have as much hassle with when all the VMs are your's: you have presumably planned the likely resource needs carefuly and if something out of the ordinary happens you won't answer back to yourself like someone who has bought a cheap VM would answer back to you when you tell them they seem to be doing something wrong. Selling containers/VMs to others is a very different kettle of fish to running you own private farm.
- davidgerard 13y ago
  If you buy a VM on Amazon, you get to do your apt-get updates yourself. And yes, managing it is a PITA.
  - susi22 13y ago
    Shouldn't be a PITA. Look into Vagrant, ansible, salt stack, chef, puppet etc.
    - porker 13y ago
      Does vagrant apply in this situation? I thought it was only for dev machines
      - Flying_Dwarf 13y ago
        Assuming you're aware of the Vagrant AWS provider plug-in, it can be valid as a means for AWS deployment.
      - wahnfrieden 13y ago
        Flying_Dwarf: Your account is hellbanned (seems to be for talking about hipsters in SF), just FYI. How does salt compare with puppet?
    - bmullan 13y ago
      Fabric also works great. If you ice ubuntu... JuJu is terrific for either VM or container use. I have used it to deploy all of open stack services into a single "super size" AWS EC2 VM where the open stack was configured to use LXC as its virtualization. Worked fine for what I wanted. To back up or clone that open stack cloud only required me to snapshot that single EC2 instance.
  - gwgarry 13y ago
    apt-get update; apt-get upgrade after you try that on a clone machine. it's not a PITA unless you're super lazy which apparently many people are.
    - fragmede 13y ago
      Easy for one machine. Now do it for 5, or 10, or 100. Remember that those machines all have slightly different software on them, so it's not simple to automate. Unless you're manage systems with something (eg puppet) it's not just a PITA or a question of laziness - it's a real task that takes up hours, not a quick 15-minute job you run over a coffee break, and that's assuming no breakage.
      - Flying_Dwarf 13y ago
        The parent was referring to a single machine though. Anyone using AWS and potentially spinning up N instances should absolutely be using configure management software, or at least professionally contract devops.
    - bmullan 13y ago
      And at least with ubuntu you can pass user data to a new container just like on AWS EC2 to initialize a new container with specific apt-get installs etc
    - porker 13y ago
      That's fine so long as you have a full test suite to exercise the app - catch small mail server configuration changes, apparmor and MySQL (we got bitten by that when upgrading to MySQL 5.5 from 5.1) et al - it's not a matter of saying "hey this looks like it's running" but verifying there's no regressions either. Mind you containers don't help with this either...
  - hoov 13y ago
    Roll your servers more often. If you have autoscaling set up, you should be good to go. Yes, this is harder for infrastructure servers, but you should automate the creation of those as well.
  - Theory5 13y ago
    Not really. I don't do any customer-oriented things on EC2 so my experience may differ, but to manage my VM's I just setup a bunch of cronjobs to update everything, reboot every so often and start my programs and services after each reboot.

by porker 13y ago

dspillett 13y ago

> because the sysadmin time of updating and patching all VMs I own There is a key difference between your circumstance the person you are replying to: you are managing a farm of your own VMs so that admin time is your's to find. If the VMs are sold to thers so you are just hosting them, then the VM updates are someone else's problem and the admin time that becomes your problem is dealing with people whose VMs that are (accidentally usually, but not always) abusing shared resources. This is something you don't have as much hassle with when all the VMs are your's: you have presumably planned the likely resource needs carefuly and if something out of the ordinary happens you won't answer back to yourself like someone who has bought a cheap VM would answer back to you when you tell them they seem to be doing something wrong. Selling containers/VMs to others is a very different kettle of fish to running you own private farm.

davidgerard 13y ago
If you buy a VM on Amazon, you get to do your apt-get updates yourself. And yes, managing it is a PITA.
- susi22 13y ago
  Shouldn't be a PITA. Look into Vagrant, ansible, salt stack, chef, puppet etc.
  - porker 13y ago
    Does vagrant apply in this situation? I thought it was only for dev machines
    - Flying_Dwarf 13y ago
      Assuming you're aware of the Vagrant AWS provider plug-in, it can be valid as a means for AWS deployment.
    - wahnfrieden 13y ago
      Flying_Dwarf: Your account is hellbanned (seems to be for talking about hipsters in SF), just FYI. How does salt compare with puppet?
  - bmullan 13y ago
    Fabric also works great. If you ice ubuntu... JuJu is terrific for either VM or container use. I have used it to deploy all of open stack services into a single "super size" AWS EC2 VM where the open stack was configured to use LXC as its virtualization. Worked fine for what I wanted. To back up or clone that open stack cloud only required me to snapshot that single EC2 instance.
- gwgarry 13y ago
  apt-get update; apt-get upgrade after you try that on a clone machine. it's not a PITA unless you're super lazy which apparently many people are.
  - fragmede 13y ago
    Easy for one machine. Now do it for 5, or 10, or 100. Remember that those machines all have slightly different software on them, so it's not simple to automate. Unless you're manage systems with something (eg puppet) it's not just a PITA or a question of laziness - it's a real task that takes up hours, not a quick 15-minute job you run over a coffee break, and that's assuming no breakage.
    - Flying_Dwarf 13y ago
      The parent was referring to a single machine though. Anyone using AWS and potentially spinning up N instances should absolutely be using configure management software, or at least professionally contract devops.
  - bmullan 13y ago
    And at least with ubuntu you can pass user data to a new container just like on AWS EC2 to initialize a new container with specific apt-get installs etc
  - porker 13y ago
    That's fine so long as you have a full test suite to exercise the app - catch small mail server configuration changes, apparmor and MySQL (we got bitten by that when upgrading to MySQL 5.5 from 5.1) et al - it's not a matter of saying "hey this looks like it's running" but verifying there's no regressions either. Mind you containers don't help with this either...
- hoov 13y ago
  Roll your servers more often. If you have autoscaling set up, you should be good to go. Yes, this is harder for infrastructure servers, but you should automate the creation of those as well.
- Theory5 13y ago
  Not really. I don't do any customer-oriented things on EC2 so my experience may differ, but to manage my VM's I just setup a bunch of cronjobs to update everything, reboot every so often and start my programs and services after each reboot.