5 ms·
That's a rather bold claim, care to elaborate?
by ianseyer 8y ago
That's a rather bold claim, care to elaborate?
- auslander 8y agoYes, happy to. Which claim you would like to focus on?
- ianseyer 8y agoContainers not being good for production.
- auslander 8y agoExcellent point :) So. First of all, you'd not have to worry about following, if you don't use containers. If your app, running in Docker container, is compromised, like PHP webshell, it might try to escape the container. What capabilities you granted for your containers? CAP_SYS_ADMIN, CAP_NET_ADMIN or you have no idea? This is just one example of escaping https://www.twistlock.com/2017/12/27/escaping-docker-container-using-waitid-cve-2017-5123 https://www.twistlock.com/2017/12/27/escaping-docker-contain... and lets talk about namespaces, like user namespace. Is root inside container is a root user on host system? Does it feels like production ready system?
- thinkmassive 8y agoIf the same compromised app is running natively then the entire system is now compromised. Capabilities and namespaces can be used with or without containers.
- auslander 8y ago1. You may have different apps, owned by different owners, running as containers on same underlying host machine. 2. Not running docker means you can lock your httpd by chroot, FreeBSD jail or OpenBSD pledge.
- ianseyer 8y agoYes, it does. 1. Every system has vulnerabilities. You can defend against them. 2. Any improperly configured system can be abused. In particular, the exploit you linked can be completely stopped with a litany of ways. https://news.ycombinator.com/item?id=16030107 https://news.ycombinator.com/item?id=16030107 Your argument going from "containers are unfit for production, you'll mature out of them one day" to "here's a small, preventable vulnerability" seems more like a security non-sequiter than an actual argument against containerization. Further, claiming containers are not production ready is empirically and literally negated by them used, in production, by the largest tech companies that have ever existed.
- jacques_chester 8y agoMost operators lock down to the runtime pretty tightly, leaving very few capabilities enabled. If that's not enough, it's easy enough to ensure that a Pod is scheduled to run by itself in an otherwise unoccupied VM. If that's not enough, the IaaS providers can be paid extra to ensure yours is the only VM on the physical machine. You can have the same expensive guarantees, if you need them, but with a uniform control plane for all workloads. That's pretty attractive.
- gilbetron 8y agoNot the person that originally asked you, but I'm interested in hearing why ditching docker is needed for high volume production. First, what do you consider high volume? After that, what's wrong with docker within that definition?
- auslander 8y agoMaxing out your CPU and networking. If you're there, you'll be running many hosts under load balancers. Be it cloud instances or physical machines. Here you have no need for containers. Web servers and backend apps are capable of multi threading.
- ianseyer 8y agoYou can't just "enable multi threading" in a varietal ecology of software applications and contexts. Also, this is not an argument _against_ containerization. You make no argument or show any evidence of performance benefits bare v. docker.
- barrkel 8y agoWe max out our compute about 3% of the time, and run at about 10% load the rest of the time. It's a similar story for memory consumption. And we run this multitenanted, where the max doesn't overlap for different tenants. And we can't move our customer data out of our data centre, so we can't use cloud elastic compute. It's in this kind of a world that elastic compute provided by a cluster scheduler with efficient packing looks really appealing. And our jobs, while meaty in time and space, are stateless once the initial data is poured in, up until the results pop out - they are big functions, basically. Good match for a stateless container. So k8s looks quite attractive.
- gilbetron 8y agoThat's ... not even wrong.