6 ms·

Run ALL the distributions and versions in prod? :)

vidarh 12y ago
I'd rather have the opportunity to re-test and re-deploy one component at a time than be forced to do "big bang upgrades". In the long run I hope we start seeing distros or tools targeted specifically at building minimal Docker images. E.g. if I'm going to deploy a Ruby based web app in Docker, the stuff I need present in the container is _very_ limited.
PaulHoule 12y ago
No, if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Note docker isn't the only answer for this, for instance, you can use ordinary VMs with vagrant, but docker does it at ludicrous speed.
- octix 12y ago
  So, basically to achieve this you need to run production env using docker too? So that docket could match it. Also, production data has to be copied over separately? Are these correct assumptions? PS: I'm still trying to understand how docket/containers may fit in current process.
  - jayfehr 12y ago
    You don't have to, but it would probably be best to keep it consistent. You could run your live server on barebones OS as you normally would, then create a docker image to mirror that. However, as we all know, mirrors often get out of sync fairly quick. But if you use the same image and only update using a Fabric or Ansible script, then you can be pretty certain that all your environments are identical. Not to mention that any newly created environments will brought up to the same point in no time at all.
  - tlrobinson 12y ago
    If you don't want to use Docker in production you could use something like Packer to build Docker base images (http://www.packer.io/docs/builders/docker.html http://www.packer.io/docs/builders/docker.html) and VM images (AMIs, OpenStack, whatever) using the same templates. There would still be some differences, like if the kernel version on your local machine didn't match. Note: I haven't tried this. Maybe it's a bad idea.
- contingencies 12y ago
  if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Sounds a lot like FreeBSD's release process, though personally I find that limiting! The problem is of course that 'very close to' is not 'equal to'. My own thoughts in this space are detailed at http://stani.sh/walter/cims/ http://stani.sh/walter/cims/ and http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/

I'd rather have the opportunity to re-test and re-deploy one component at a time than be forced to do "big bang upgrades". In the long run I hope we start seeing distros or tools targeted specifically at building minimal Docker images. E.g. if I'm going to deploy a Ruby based web app in Docker, the stuff I need present in the container is _very_ limited.

PaulHoule 12y ago

No, if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Note docker isn't the only answer for this, for instance, you can use ordinary VMs with vagrant, but docker does it at ludicrous speed.

octix 12y ago
So, basically to achieve this you need to run production env using docker too? So that docket could match it. Also, production data has to be copied over separately? Are these correct assumptions? PS: I'm still trying to understand how docket/containers may fit in current process.
- jayfehr 12y ago
  You don't have to, but it would probably be best to keep it consistent. You could run your live server on barebones OS as you normally would, then create a docker image to mirror that. However, as we all know, mirrors often get out of sync fairly quick. But if you use the same image and only update using a Fabric or Ansible script, then you can be pretty certain that all your environments are identical. Not to mention that any newly created environments will brought up to the same point in no time at all.
- tlrobinson 12y ago
  If you don't want to use Docker in production you could use something like Packer to build Docker base images (http://www.packer.io/docs/builders/docker.html http://www.packer.io/docs/builders/docker.html) and VM images (AMIs, OpenStack, whatever) using the same templates. There would still be some differences, like if the kernel version on your local machine didn't match. Note: I haven't tried this. Maybe it's a bad idea.
contingencies 12y ago
if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Sounds a lot like FreeBSD's release process, though personally I find that limiting! The problem is of course that 'very close to' is not 'equal to'. My own thoughts in this space are detailed at http://stani.sh/walter/cims/ http://stani.sh/walter/cims/ and http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/