search

galterlibrary / InvenioRDM-at-NU

Next generation repository for health science
MIT License
9 stars 0 forks source link

Cronify removal of containers #276

Open fenekku opened 5 years ago

fenekku commented 5 years ago

Docker leaves a lot of containers lying around. Making a cron job using docker container prune to remove them will keep our machines free of old containers.

sharpattack commented 5 years ago

Is the plan to remove all the old containers? Would keeping "n" number of containers be considered a plan for keeping back ups?

fenekku commented 5 years ago

@sharpattack

I don't foresee us needing container backups, because they can be spun up in seconds and although rolllbacks are great in theory I have never seen them work well in practice e.g., web projects were never rolled back in my government work because of the data store inconsistencies with rolled back code and the added overhead of going back and forth. Patches seemed to work better.

More to your point, images are kept as code backup though. Containers are spun up from them. IMHO, this is one of the biggest issue with the IT "container" industry: the wording used in the analogy is broken. People don't transfer around Docker containers, like the shipping industry in the 20th century started transporting around shipping containers. People transfer around images and then those images are spun to life into what is then called a Docker "container" on the machine. (＞﹏＜)

Images do have the same issue of littering the file system and taking space. I don't know a good policy around them, because I just don't have enough experience with them. My inclination now would actually be to delete those as well, so even they wouldn't be kept up as "backups" for the same rollback argument as above. However I think (to be tested) it would affect new image build time. We would need to keep the service images (db, queue, cache,...) around for sure.

Finally, and to be clear, the above is all "code" backup discussion. The data itself is stored in a third Docker construct, volumes. We have other issues that deal with making sure those work appropriately. (#91 , #200 )