== What containers do and don't help you with In a comment on [[my entry on when to use upstream versions of software ../sysadmin/UseUpstreamWhenViews]], Albert suggested that containers can be used to solve [[the problems of using upstream versions ../sysadmin/BuildingPackagesFlaws]] and [[when you have to do this anyway ../sysadmin/UseUpstreamSometimes]]: > A lot of those issues become non-issues if you run the apps in > containers (for example Grafana). Unfortunately this is not the case, because of what containers do and don't help you with. What containers do is that they isolate the host and the container from each other and make the connection between them simple, [[legible https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/]], and generic. [[The practical Unix API is very big ../unix/UnixAPIMoreThanSyscalls]] and allows software to become quite entangled in the operating system and therefor dependent on specific things in unclear ways. Containers turn this into a narrow interface between the software and the host OS and make it explicit (a container has to say clearly at least part of what it wants from the host, such as what ports it wants connected). Containers have also created a social agreement that if you violate the container API, what happens next is your own fault. For example, there is usually nothing stopping you from trying to store persistent data within your theoretically ephemeral container, but if you do it and your container is restarted and you lose all the data, you get blamed, not the host operators. However, containers do not isolate software from itself and from its own flaws and issues. When you put software in a container, you still have to worry about choosing and building the right version of the software, keeping it secure and bug free, and whether or not to update it (and when). Putting Exim 4.93 in a container doesn't make it any better to use than if you didn't have it in a container. Putting Grafana or Prometheus Pushgateway in a container doesn't make it any easier to manage their upgrades, at least by itself. It can be that the difficulties of doing some things in a container setup drive you to [[solve problems in a different way https://grafana.com/docs/grafana/latest/administration/provisioning/]], but putting software in a container doesn't generally give it any new features so you could always have solved your problems in those different ways. Containers just gave you a push to change your other practices (or forced you to). Containers do make it easier to deal with software in one respect, which is that they make it easier to select and change where you get software from. If someone, somewhere, is doing a good job of curating the software, you can probably take advantage of their work. Of course this is just adding a level of indirection; instead of figuring out what version of the software you want to use (and then keeping track of it), you have to figure out which curator you want to follow and keep up with whether they're doing a good job. The more curators and sources you use, the more work this will be. (Containers also make it easier and less obvious to neglect or outright abandon software while still leaving it running. Partly this is because containers are deliberately opaque to limit the API and to create isolation. This does not magically cure the problems of doing so, it just sweeps them under the rug until things really explode.)