7 ms·
> each and every single one of them has to be maintained, updated for security fixes... No, of course not. No single container should have a lifetime greater
by sagichmal 11y ago
> each and every single one of them has to be maintained, updated for security fixes...
No, of course not. No single container should have a lifetime greater than a day or two. "Maintenance" is deploying the latest, integration- and end-to-end-tested version of the software, as part of a continuous build pipeline.
- hueving 11y agoSo you depend on every application company to update their containers for every library vulnerability that emerges that they embed? Good luck with that.
- nmjohn 11y ago> their containers Build your own images, problem solved. (Albeit creating a whole host of other problems in place of it, but those are no worse than a world without containers.) No one relying on third party images beyond an OS can claim that they _really_ care about security or vulnerabilities anyway.
- sagichmal 11y agoI build all of my own containers.
- modoc 11y agoSo your haproxy, nginx, ldap, dns, nagios, sftp, ELK, imap, etc... services don't live more than a day or two? Interesting.....
- nbaksalyar 11y agoWhy not? It helps to think that containers are immutable. The actual data can be stored in either separate bare containers or on the host file system. In this case the application containers themselves can perfectly live less than a day.
- freebullets 11y agoWhen you run fully redundant services behind a load balancer, you don't need to worry about taking down one instance of a service for maintenance.
- toomuchtodo 11y agoGood luck with your services that need to maintain state. Not everything is a stateless microservice.
- sagichmal 11y agoIf they are containerized, no, they don't.
- yo-code-sucks 11y agoGlad someone here has half a fucking brain! All this shit about keeping them up to date. These are the morons that insist on running ssh in the container and run an init inside it too.