3 ms·

FROM scratch COPY hello / CMD ["/hello"] This just raises the question of what the point of containerisation for applications with no dependancies.

raesene9 5y ago
There's a couple that spring to mind - Consistent packaging/execution environment. containers are delivered and executed in a standard way regardless of target env. - A level of sandboxing from the underlying host. Things like automatically applied Linux namespaces and dropped capabilities if you use Docker/runc, and then more sandboxing automatically applied if you use things like gVsior or firecracker.
- megous 5y ago
  1) Is not needed if your app has no dependencies (otherwise it would not work in an empty "container") 2) Sandboxing can be done using a systemd service configuration to a large extent.
  - raesene9 5y ago
    1) I was more thinking of the delivery mechanism via centralized registries (i.e. Docker pull works for anything) 2) Sure in theory, you can totally replicate docker's sandboxing with Linux security principles, however containerized deployment gives you an easy to use sensible starting point :)
dimes 5y ago
Genuinely curious about alternatives. I have a simple node application that all I really need to do is run npm install and node index.js. Even with such a simple setup, provisioning hosts was a huge pain. Each one needed node installed on it, and I had to deploy the app to each new host. With k8s, I just change the number of hosts I want in a config file and everything just works.
majewsky 5y ago
The main appeal of containerisation is not security, the main appeal is having a deployment process that's consistent across the entire team/org/company. Sure, if all you have are Go binaries, you can just run those directly, but if you have some Go binaries and also some Python applications and also some Java beans, you stuff them all into containers and then they can be deployed with the same tooling.

raesene9 5y ago

There's a couple that spring to mind - Consistent packaging/execution environment. containers are delivered and executed in a standard way regardless of target env. - A level of sandboxing from the underlying host. Things like automatically applied Linux namespaces and dropped capabilities if you use Docker/runc, and then more sandboxing automatically applied if you use things like gVsior or firecracker.

megous 5y ago
1) Is not needed if your app has no dependencies (otherwise it would not work in an empty "container") 2) Sandboxing can be done using a systemd service configuration to a large extent.
- raesene9 5y ago
  1) I was more thinking of the delivery mechanism via centralized registries (i.e. Docker pull works for anything) 2) Sure in theory, you can totally replicate docker's sandboxing with Linux security principles, however containerized deployment gives you an easy to use sensible starting point :)

dimes 5y ago

Genuinely curious about alternatives. I have a simple node application that all I really need to do is run npm install and node index.js. Even with such a simple setup, provisioning hosts was a huge pain. Each one needed node installed on it, and I had to deploy the app to each new host. With k8s, I just change the number of hosts I want in a config file and everything just works.

majewsky 5y ago

The main appeal of containerisation is not security, the main appeal is having a deployment process that's consistent across the entire team/org/company. Sure, if all you have are Go binaries, you can just run those directly, but if you have some Go binaries and also some Python applications and also some Java beans, you stuff them all into containers and then they can be deployed with the same tooling.