11 ms·

I find it extremely useful. It's really easy to use, and after years of inactivity - I can reanimate projects "just like that" by running a single command. Use

by 2easy 5y ago

I find it extremely useful. It's really easy to use, and after years of inactivity - I can reanimate projects "just like that" by running a single command. Use docker-compose to your advantage and create a simple set of deployments locally - in the same way you would on a VM for "prod". Can't stress how useful it is if you ever want to give it to somebody else, or hire a dev. "docker-compose up" and your dev is set up.

2easy 5y ago
That being said some things to consider to answer your question: - complexity: not the easiest thing to learn - work overhead: you'll need to set this up for the first time - linux is best: I don't use much of docker outside of linux, it get's even more complicated on Mac and Windows - deployment: learn how to deploy your images to prod, there are multiple ways and can be hard to decide what to use
onli 5y ago
I kinda doubt that. You would need to update the components inside the docker container, right? If you simply activate the container after years of inactivity you will have a complete insecure setup, as there would be no security updates applied. That's not even acceptable for side projects.
- outsomnia 5y ago
  Dunno why you got downvoted, you are exactly correct. Another thing that rots when it's "years" is the trusted CA bundle, so you cannot even talk to remote peers until you update it.
  - xyzzy123 5y ago
    The usual trick is to mount /etc/ssl/certs from the host. This also means stuff like "extra" CAs can be configured at host level. The packaging issues... 99% of all CVEs are junk, in context - not reachable except in exotic configurations, component not used in container, kernel bugs reported against kernel headers package in the container because of course no docker scanner filters those out, cve is actually misreported, tons of "locally" (aka not) exploitable issues esp privesc... but yeah, ok, it's the 1/100 that gets you.
- evilduck 5y ago
  I know for solo-founder discussions about cut-throat effort expenditure judgements in the here and now don't really need to consider their project being shuttered and later revived, but the first step of reviving old projects is never "put it on a public server" or "update all the packages to ensure the security patches are up to date", it's always just getting it running again. I've been in scenarios where that effort alone was significant.
- imhoguy 5y ago
  Good luck updating old and hand-configured VM. Most of the time running Docker image is just invoking one app without entire system services (except host system), then securing is often just bumping base image version to some recent one.
  - purerandomness 5y ago
    You don't hand configure VMs, just like you don't hand configure containers. You use packer and vagrant for that, and you bump base image versions, just like in Dockerfiles.

by 2easy 5y ago

2easy 5y ago

That being said some things to consider to answer your question: - complexity: not the easiest thing to learn - work overhead: you'll need to set this up for the first time - linux is best: I don't use much of docker outside of linux, it get's even more complicated on Mac and Windows - deployment: learn how to deploy your images to prod, there are multiple ways and can be hard to decide what to use

onli 5y ago

I kinda doubt that. You would need to update the components inside the docker container, right? If you simply activate the container after years of inactivity you will have a complete insecure setup, as there would be no security updates applied. That's not even acceptable for side projects.

outsomnia 5y ago
Dunno why you got downvoted, you are exactly correct. Another thing that rots when it's "years" is the trusted CA bundle, so you cannot even talk to remote peers until you update it.
- xyzzy123 5y ago
  The usual trick is to mount /etc/ssl/certs from the host. This also means stuff like "extra" CAs can be configured at host level. The packaging issues... 99% of all CVEs are junk, in context - not reachable except in exotic configurations, component not used in container, kernel bugs reported against kernel headers package in the container because of course no docker scanner filters those out, cve is actually misreported, tons of "locally" (aka not) exploitable issues esp privesc... but yeah, ok, it's the 1/100 that gets you.
evilduck 5y ago
I know for solo-founder discussions about cut-throat effort expenditure judgements in the here and now don't really need to consider their project being shuttered and later revived, but the first step of reviving old projects is never "put it on a public server" or "update all the packages to ensure the security patches are up to date", it's always just getting it running again. I've been in scenarios where that effort alone was significant.
imhoguy 5y ago
Good luck updating old and hand-configured VM. Most of the time running Docker image is just invoking one app without entire system services (except host system), then securing is often just bumping base image version to some recent one.
- purerandomness 5y ago
  You don't hand configure VMs, just like you don't hand configure containers. You use packer and vagrant for that, and you bump base image versions, just like in Dockerfiles.