It's not so much about upgrading docker, but more about reinstalling the app if the container has to change.
Like, if I need to run pip install again, it may break for various reasons 6 years from now.
I could also install everything in the dockerized app, including everything related to pip modules, python version, etc. So that nothing has to be installed again, even if I spawn a new docker container.
Ok, well, I assumed by "dockerizing" you would put all the dependencies into the image along with the app. IOW you'd end up with a self-contained image. Then you deploy it in, say, AWS ECS Fargate. As long as ECS can provision the required computing resources (CPUs, memory, etc.), you wouldn't have to worry about AWS switching hosts from underneath. If you just put the app itself in the image, but leave the dependencies on, say, a host volume, of course it's liable to break at some point, but that's kind of defeating the purpose of containerization, isn't it?
Yes, you're right, it could work if the container itself is frozen (everything already installed), so that nothing changes even if it's needed to launch a new container at some point.
Only temporary files would be a concern, like logs and so. (if transitioning)
For files produced by the app, if you need to post-process/archive them, perhaps consider the Sidecar Pattern. Basically you keep the main app container frozen, and put the post-processing logic in a separate container - it could be as simple as backing up the log files to S3.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's not so much about upgrading docker, but more about reinstalling the app if the container has to change.
Like, if I need to run
pip installagain, it may break for various reasons 6 years from now.I could also install everything in the dockerized app, including everything related to pip modules, python version, etc. So that nothing has to be installed again, even if I spawn a new docker container.
Ok, well, I assumed by "dockerizing" you would put all the dependencies into the image along with the app. IOW you'd end up with a self-contained image. Then you deploy it in, say, AWS ECS Fargate. As long as ECS can provision the required computing resources (CPUs, memory, etc.), you wouldn't have to worry about AWS switching hosts from underneath. If you just put the app itself in the image, but leave the dependencies on, say, a host volume, of course it's liable to break at some point, but that's kind of defeating the purpose of containerization, isn't it?
Yes, you're right, it could work if the container itself is frozen (everything already installed), so that nothing changes even if it's needed to launch a new container at some point.
Only temporary files would be a concern, like logs and so. (if transitioning)
For files produced by the app, if you need to post-process/archive them, perhaps consider the Sidecar Pattern. Basically you keep the main app container frozen, and put the post-processing logic in a separate container - it could be as simple as backing up the log files to S3.