You usually want to prioritize changing the container’s build config instead of getting into them and modifying them. Much better to get into the mindset of them not being pets you have to nurture.
Separating the different services into containers is overall a good practice but having the DB in one can be a pain as it’s easier to work with stateless applications. The isolation aspect is very valuable as its easier to debug a problem. I would look into container orchestration if there isn’t already and making sure logs are centralized first.
okay, that makes a lot of sense. I can’t see any immediate orchestration, but maybe I’m looking in the wrong place. would the logs go to /var/log on the main system? just realized I haven’t looked for those (d’oh!)
Terny has the correct answer here OP. While I have never used Docker in an enterprise environment (manufacturing applications aren’t known for supporting any technology from the last decade at least), I have used Docker extensively in my home lab. You don’t want to modify the container itself, but the image it was created from. The data doesn’t reside in the container itself anyway, but typically a volume attached to the container (assuming it stores anything in the first place). Your best bet will be to figure out what image the container was created from, and modify the image. From there, you can update the existing containers to use the new image, or move them elsewhere if you like.
You mentioned these VM’s are in the cloud. Depending on the hyperscaler, it is likely that you could migrate these to a native container service to save on cost since you wouldn’t have to pay for the overhead of a VM.