6 ms·

> AWS wrote Firecracker to run Fargate thank you for mention that. Which projects like Firecracker, it really doesn't make sense to have Docker.

krageon 5y ago
Given that this directly precedes the sentence you rewrote: > I don't think you can reasonably host general-purpose applications on a multi-tenant basis on shared hardware using container systems I'm really not sure what point you're trying to make
- dsr_ 5y ago
  I interpreted this as: "don't think you can reasonably host" => I encourage our competitors to do this "general-purpose applications on a multi-tenant basis" => any program a black hat who signed up with our automated system wants to run, next to all the other programs random people want to run "on shared hardware" => one lump of iron owned by Fly "using container systems" => containers vs VMs, in this case, and especially a VM manager that pays some attention to security.
- acdha 5y ago
  I think the important part is immediately after what you quoted: “using directly shared kernels” If you’re running dockerd on one big server, you’re a single bug in either the kernel or dockerd away from someone in account A being able to attack account B. This is also true about Firecracker or another VM approach but look at the relative exposed attack surface: if we’re on the same kernel, there are tons of different modules which I can attack — maybe even obscure ones you don’t or barely use - and if any of them allow me to run code, alter or leak memory, etc. mayhem ensues. Running a VM reduces that risk because you’re sharing much less code & data but they traditionally added more overhead and startup delay, and if you’re deploying a traditional OS there’s a lot of management overhead. You’d see this as a security precaution but many people weren’t willing to pay for it. Firecracker changes that calculation because creating a VM is fast enough and Docker means that you don’t need to support a full Linux distribution, just enough to launch the container image.
  - krageon 5y ago
    > many people weren’t willing to pay When most people don't understand the implications, offering a cheaper option that's almost guaranteed to inconvenience them (or be a catastrophe, depending on what they're doing) is not a fault that should be attributed directly (and certainly not solely) to them.
toyg 5y ago
Docker nowadays is more valuable as a configuration standard "primitive" than as an actual tool.
- fireflash38 5y ago
  It's super convenient in that it should eliminate the "runs on my box" sort of errors. You should be able to run the same OCI image in Docker, FC, and kata and not worry about that. Really opens you up to freedom of where you dev.
  - toyg 5y ago
    Well, kinda. It’s still “you can use any OS as long as it’s Linux”. If you like the BSDs, forget it.
  - patrick451 5y ago
    Sort of. Docker makes external dependencies management better, but it's an abstraction that leaks like a sieve when it comes to networking. If your /etc/docker/daemon.json file isn't set up just so, or your iptables are a bit off, or your vpn client is a bit too aggressive (e.g., Cisco VPN), the whole thing blows up. Personally, I would rather manage dependencies than iptables rules.
imtringued 5y ago
This is like saying thanks to car company with X security feature, it really doesn't make sense to have competitor without security feature. Why eliminate your options? You don't gain anything.

krageon 5y ago

Given that this directly precedes the sentence you rewrote: > I don't think you can reasonably host general-purpose applications on a multi-tenant basis on shared hardware using container systems I'm really not sure what point you're trying to make

dsr_ 5y ago
I interpreted this as: "don't think you can reasonably host" => I encourage our competitors to do this "general-purpose applications on a multi-tenant basis" => any program a black hat who signed up with our automated system wants to run, next to all the other programs random people want to run "on shared hardware" => one lump of iron owned by Fly "using container systems" => containers vs VMs, in this case, and especially a VM manager that pays some attention to security.
acdha 5y ago
I think the important part is immediately after what you quoted: “using directly shared kernels” If you’re running dockerd on one big server, you’re a single bug in either the kernel or dockerd away from someone in account A being able to attack account B. This is also true about Firecracker or another VM approach but look at the relative exposed attack surface: if we’re on the same kernel, there are tons of different modules which I can attack — maybe even obscure ones you don’t or barely use - and if any of them allow me to run code, alter or leak memory, etc. mayhem ensues. Running a VM reduces that risk because you’re sharing much less code & data but they traditionally added more overhead and startup delay, and if you’re deploying a traditional OS there’s a lot of management overhead. You’d see this as a security precaution but many people weren’t willing to pay for it. Firecracker changes that calculation because creating a VM is fast enough and Docker means that you don’t need to support a full Linux distribution, just enough to launch the container image.
- krageon 5y ago
  > many people weren’t willing to pay When most people don't understand the implications, offering a cheaper option that's almost guaranteed to inconvenience them (or be a catastrophe, depending on what they're doing) is not a fault that should be attributed directly (and certainly not solely) to them.

toyg 5y ago

Docker nowadays is more valuable as a configuration standard "primitive" than as an actual tool.

fireflash38 5y ago
It's super convenient in that it should eliminate the "runs on my box" sort of errors. You should be able to run the same OCI image in Docker, FC, and kata and not worry about that. Really opens you up to freedom of where you dev.
- toyg 5y ago
  Well, kinda. It’s still “you can use any OS as long as it’s Linux”. If you like the BSDs, forget it.
- patrick451 5y ago
  Sort of. Docker makes external dependencies management better, but it's an abstraction that leaks like a sieve when it comes to networking. If your /etc/docker/daemon.json file isn't set up just so, or your iptables are a bit off, or your vpn client is a bit too aggressive (e.g., Cisco VPN), the whole thing blows up. Personally, I would rather manage dependencies than iptables rules.

imtringued 5y ago

This is like saying thanks to car company with X security feature, it really doesn't make sense to have competitor without security feature. Why eliminate your options? You don't gain anything.