Our applications are based on tomcat, strictly speaking on tomcat base s2i image provided by RedHat. This is updated quite frequently, and we need to comply to some regulations and apply the updates. This basically means, that with every single update, we need to replace the base image of each of a few hundred ones deployed. There is about twenty something applications, each in a few different code versions, so cannot be simplified with tagging. I was thinking of extracting tomcat/JDK somehow to another supply chain, but there it gets complicated as well.
-
1It's not clear to me which problem you have and want to solve: is it that your images take up lots of storage space (I doubt this is it?), or that building all of your images simultaneously on top of the new parent s2i image takes lots of resources (& time), or that all of your applications need to be re-deployed (and lots may be re-deployed in parallel)?– grdrynAug 7, 2018 at 14:55
-
Well, having about 500 images rebuild does take time. It needs to be monitored for failures. Feels redundant too, as the resources used are far from modest, compared to the changes. All of the things you mentioned contribute to my overall feeling of extravagance.– ptrkAug 8, 2018 at 14:08
Add a comment
|
1 Answer
Get newest tag
How I mitigated it was by creating several bots. The first one uses dip to get the latest version of a specific docker image. E.g.:
go run main.go -image ubuntu -latest "xenial-\d.*"
to get the latest tag of Ubuntu Xenial. If the docker image does not exist in your local docker registry, then it will be pushed.
Update tag in several Dockerfiles
The second bot, updates the tags in the Dockerfiles. If the build is successful then it is merged. Currently an approval is always required, but if it works for a couple of months and the team has enough confidence then an auto merge can be done.
Update orchestration
The third bot updates the docker-compose.yml files, k8s files or whatever orchestration is used. If an approval is done then it will be merged into master. Again if there is enough confidence then this could be automated as well, but I always prefer some manual intervention if production is applicable. Then the team is aware that there was an update and could revert if needed. On the other hand if the monitoring works well then the team will be notified right a way and if updates are done frequently, i.e. at least once every two weeks then the team is trained and knows how to deal with this.