Is updating software in Docker containers useful? reddit / selfhosted ---------------------------------------------------------------------- LKS-Hunter · 2023-12-06 14:44 To keep my containers secure, I have a watchtower that keeps my containers up to date. For most of the services I host, it is enough for me to get an update about once a month. Unfortunately, I have a few containers that rarely get an update every six months or less. Is it sensible in such cases to update the packages within the containers? And if so, how often and with what tools do you do that? ---------------------------------------------------------------------- thekrautboy · 2023-12-06 14:47 > Is it sensible in such cases to update the packages within the containers? No. If you for whatever reasons what to update those, you would use a custom Dockerfile to build your own image. You dont install/update things inside a container, thats a bad practice. /r/Docker ---------------------------------------------------------------------- realorangeone · 2023-12-06 14:47 That's not really how containers work. As soon as you restart the container, any changes you made in the container are lost - which is by design. If you're using a container which hasn't been updated in a while, your best bet is to find an alternative which has been. If there's nothing else out there, and you really have to / want to update the inner software, you'll need to take the source `Dockerfile` and build it yourself. ---------------------------------------------------------------------- Justsomedudeonthenet · 2023-12-06 14:49 If there are security exploits in the software in the containers, and the person maintaining the containers isn't releasing new ones regularly, then either switch to something else or start creating your own containers with updated versions. Building docker containers isn't that hard, but it can be time consuming - that's one reason for using docker, someone else does that work for you. But just because there are updates available doesn't mean there are *security* updates. One of the other reasons for using containers is so that you have a stable set of libraries and software that doesn't change between releases, so doesn't break because some other library your software depends on changed it's API. ---------------------------------------------------------------------- terrorTrain · 2023-12-06 14:53 Your risking downtime, but there isn’t really any reason you can’t turn on unattended upgrades, however, when an upgrade happens, it might kill your main process, which docker would consider a crash. Then your container would likely be recreated, with no upgrades. IMO it would be better to make a docker file based on your image, upgrade the software and push a new image, on a cron job. Weekly or whatever ---------------------------------------------------------------------- LKS-Hunter · 2023-12-06 15:26 Okay thank you 👍 ---------------------------------------------------------------------- LKS-Hunter · 2023-12-06 15:30 For example I use a very specific version of mongo without replication and without the need of a AVX support CPU. To be honest I'm too lazy to build it by myself. But if I check the image with grype the CVE numbers make me a little bit nervous ---------------------------------------------------------------------- crazyflasher14 · 2023-12-06 15:30 Also, if you go down this path, you could also publish to a public container registry, and open source the dockerfile so that others can also contribute and help in keeping it up to date ---------------------------------------------------------------------- HTTP_404_NotFound · 2023-12-06 16:16 You can build a docker file, that takes an existing docker file, and produces your minor changes. Its a built-in, well supported feature. ---------------------------------------------------------------------- colin_colout · 2023-12-06 17:10 You CAN treat a docker container like a VM with fewer features, but you're making your life hard. Docker is meant for "immutable" infrastructure. Immutable in this context means you don't change it after it's built. If you need to change something, you replace the whole thing. The caveat is that most workloads require some form of persistent data (database, file storage, dynamic configuration files, etc). The way you deal with this in an immutable container is by mounting those paths as "volumes". Volumes persist when the container itself is destroyed. You should back them up regularly since this is where the data is. So if you want to upgrade your container, you can: * Stop the old container * Build a new image with new software versions if you have your own Dockerfile. If you're using a premade image, just deploy from an updated tag * When you spin up your updated container, you can mount your old volumes and everything should work. If it fails for whatever reason, you can always kill it and spin up your old image until you figure it out. ---------------------------------------------------------------------- borg286 · 2023-12-06 17:50 Embrace statelessness. State being stored outside the container forces the author of the service to think hard about how his service works and make it more resilient. If a service can't do it look elsewhere for one that does. It'll make your life easier in the long run. Relying on state in a container is a ticking time bomb. ---------------------------------------------------------------------- watchdog_timer · 2023-12-06 18:26 If you make your own image from a container's Dockerfile, how do you determine when any of it's underlying software has updates available and you need to rebuild the image? ---------------------------------------------------------------------- cheesecloth62026 · 2023-12-06 18:30 Dockerfile: ``` FROM {image} RUN {commands you would execute to update container} ``` Then in the same directory run ``` docker build -t {my image}/{my tag} . ``` ---------------------------------------------------------------------- ElevenNotes · 2023-12-06 18:41 Just because you can does not mean you should. You break the whole idea of an immutable container image. ---------------------------------------------------------------------- ElevenNotes · 2023-12-06 18:42 You mean like [this](https://hub.docker.com/u/11notes) (shameless self promoting). ---------------------------------------------------------------------- HoytAvila · 2023-12-06 18:45 Some comments here say “oh bro get that Dockerfile with a FROM then do the aptget update and push to a container repo like docker hub then create a policy to pull the latest tag etc etc” that is annoying to deal with and you are gonna do the work of the image maintainer, not for one image, but bunch of images. The easiest most forward solution is to do as you said, create a container from an image, update and upgrade things there, commit the image with a new tag and include the date in the tag, vowalah you are done. Even make it a cronjob if you want. In the event something broke, roll back to a working version. And if you want to make the container quickly secure without bloats, maybe give this a try https://github.com/slimtoolkit/slim Of course you can get your hand dirty by manually updating the dockerfiles and do a little of ci/cd and running bunch of scanners such as trivy, gravy, docker scout etc. But you will quickly face a vuln that is not resolved yet. What im trying to say, it might not be worth it to invest too much effort into updating the packages, limit the attack surface from above in the network level is much easier than dealing with packages that have a 9.9 score vuln with a dispute from the vendor and now you find your self checking the source code of the issue to judge whether it is worth investigating for. Edit: sorry for the rant, just a PTSD thing. ---------------------------------------------------------------------- terrorTrain · 2023-12-06 19:02 thats what the cron job is for, just pulls, installs updates (tests the image if your really on top of it) and pushes it to your server. ---------------------------------------------------------------------- LKS-Hunter · 2023-12-06 19:34 The few container I'm "nervous" about are maintained but unfortunately very slowly. I use docker now since a few years. Initial I started using it in 2019. But since I scan my less maintained containers in irregular periods with grype I recognize how much possible problems are in them. The whole idea should make me sleep better. But thanks for your input. At this point I'm not so happy with the idea of build my own images because of the invest of time. But it seems the best option to get more secure and without compromises. ---------------------------------------------------------------------- LKS-Hunter · 2023-12-06 19:37 Thanks 👍 Is it possible to automate it? Like when the new ubuntu or alpine image is released? Or should I use a specific service for that? Best case a self hosted service 😅 ---------------------------------------------------------------------- cheesecloth62026 · 2023-12-06 20:15 You would probably want to set up a webhook via the Watchtower container, although I imagine you could directly interact with the dockerhub API to check if you feel comfortable working with API requests ---------------------------------------------------------------------- Salzig · 2023-12-06 23:34 Even if the direction your intending is right, the message is technically wrong. Container FileSystem State is persistent as long as the container isn’t deleted. A „restart“ therefor still contains all the changes. It just happens that a lot of use Swarm or Kubernetes where we typically replace instead of restart. ---------------------------------------------------------------------- hyperactive2 · 2023-12-06 23:43 A lot of the tools we use are open source. I would encourage you to find the project source and offer a pull request to the stale containers that you may see needing some updates. This can be a pain to test and verify, but thos of us without the skill to do so would very much appreciate such effort. ---------------------------------------------------------------------- PaulEngineer-89 · 2023-12-07 01:50 Think about this. When you get an update message from Linux or Windows and you have critical work to do, do you let the install happen right then or click “maybe later”? Same thing. ---------------------------------------------------------------------- 2lach · 2023-12-07 08:03 I usually run an update on rebuild but very rarely inside a container, the only reason i would do that is if the container is never replaced, is system-critical and has known vulnerabilities. And if thats the case well then there are lots of other issues the company should focus on 😉 ---------------------------------------------------------------------- realorangeone · 2023-12-07 09:32 Good point, I mispoke. I've updated my comment. ---------------------------------------------------------------------- colin_colout · 2023-12-07 17:42 Yep, but just because you shouldn't doesn't mean they won't. Sometimes people do it. It's the way many newbie instinctively uses docker. Immutability is a lot for a new docker user to wrap their head around. It requires a deeper understanding of where persistent data is stored. The reward for understanding it is peace of mind and simplicity in making changes.