Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-24T13:19:14.003Z
Answers: 2019-12-24T13:19:14.003Z
Answers: 030
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2018-08-07T14:55:40.780Z
Comments: 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)?
Comments: grdryn
Comments: CC BY-SA 4.0
Comments: 2018-08-08T14:08:06.450Z
Comments: 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.
Comments: ptrk
Tags: <security><openshift><tomcat><images>
Title: How to avoid an avalanche of images in Openshift when security patches keep coming in?
UserDisplayName: ptrk
ThreadText: # 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](https://github.com/030/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.
  
  
  ---
  
  