<p><strong>Get newest tag</strong></p>

<p>How I mitigated it was by creating several bots. The first one uses <a href="https://github.com/030/dip" rel="nofollow noreferrer">dip</a> to get the latest version of a specific docker image. E.g.:</p>

<pre><code>go run main.go -image ubuntu -latest "xenial-\d.*"
</code></pre>

<p>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.</p>

<p><strong>Update tag in several Dockerfiles</strong></p>

<p>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.</p>

<p><strong>Update orchestration</strong></p>

<p>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. </p>

CC BY-SA 4.0
2019-12-24T13:19:14.003Z
2019-12-24T13:19:14.003Z
030
<p>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.</p>

CC BY-SA 4.0
2018-08-07T14:55:40.780Z
It'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)?
grdryn
CC BY-SA 4.0
2018-08-08T14:08:06.450Z
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.
ptrk
<security><openshift><tomcat><images>
How to avoid an avalanche of images in Openshift when security patches keep coming in?
ptrk
# How to avoid an avalanche of images in Openshift when security patches keep coming in?

(Asked by: username_0 on 2018-07-30)

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.

**Tags:** security, openshift, tomcat, images

> **Comments:**
> **username_1**: It'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)?  
> **username_0**: 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.  

---

## 1 answers

### Answer by username_2 on 2019-12-24. Score: 0

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.


---

