Anyone else with experience or opinions on this topic? I know there are advice out there to always pin everything, i.e. A), to have a truly immutable deploy, but then you probably need to be very actively monitoring new releases, perhaps run "docker scan" to know when to upgrade etc.
So far I have been doing C) i.e. pinning minor version, but without the frequent pulling to look for updates. Is there a way to tell Kubernetes to auto poll for updated images in the background? Jan > 4. feb. 2022 kl. 15:06 skrev Jan Høydahl <jan....@cominvent.com>: > > Indeed, helm/solr-operator makes it very smooth to do those upgrades. > A thing worth noting is that if you have pinned, say 9.0, then you will > get 9.0.1, 9.0.2 etc, but once 9.1 is released, there will not be new Solr > bugfix releases for 9.0.x. So if you choose that route, you need to monitor > new releases[1] or new security announcements[2] closely in order to upgrade > manually. > > [1] https://solr.apache.org/feeds/solr/news.atom.xml > [2] https://solr.apache.org/feeds/solr/security.atom.xml > > Jan > >> 4. feb. 2022 kl. 03:13 skrev Steve Davids <sdav...@gmail.com>: >> >> Just as an FYI - it looks like the Solr Helm Chart >> <https://artifacthub.io/packages/helm/apache-solr/solr#running-solr> >> (Kubernetes installer) goes with A by default. Though, it does allow for >> easy configurability to go with other options: >> >> image.repository string "solr" The repository of the Solr image >> image.tag string "8.9" The tag/version of Solr to run >> image.pullPolicy string >> PullPolicy for the Solr image, defaults to the empty Pod behavior >> >> Those are the defaults, you can update the Image.pullPolicy to "Always" >> <https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy> >> which will then mimic option C, but would require the containers to >> "updated" in some capacity to trigger a re-pull/replace of that particular >> container. >> >> Having said all that, the joy of Helm templates is that you can easily >> update the Image.tag version to perform a `helm upgrade` which will then >> roll out the patched version you are trying to deploy out to your cluster. >> Users should be diligent with regularly updating their clusters and luckily >> Kubernetes/Helm makes that very easy to orchestrate >> <https://apache.github.io/solr-operator/docs/solr-cloud/solr-cloud-crd.html#update-strategy> >> . >> >> -Steve >> >> On 2022/02/03 14:40:40 Jan Høydahl wrote: >>> Hi, >>> >>> The project produces official Docker images for every release, including >> our own bugfix releases. >>> These images are based on an OpenJDK base image, which is again based on >> a Linux base image. >>> Once in a while, when there is a serious bugfix in either Linux or Java >> the Solr image gets re-built by Docker. >>> >>> I wanted to invite to a discussion on how you as users handle security >> patching in your Docker/k8s production environments. >>> >>> Do you: >>> >>> A) just pull the image once and let it sit there until next upgrade? >>> B) pin the exact version, e.g. solr:8.11.1 and pull routinely for Linux / >> JDK updates? >>> C) pin the minor version only, e.g. solr:8.1 and pull regularly for any >> new patch releases >>> D) pin the major oversion only, e.g. solr:8 and pull regularly for any >> new minor releases >>> E) make a custom Dockerfile FROM solr:8 and add "RUN apt upgrade" or >> similar to stay up to date? How often? >>> F) Neither of the above. Please share your best practice >>> >>> This thread was triggered from >> https://issues.apache.org/jira/browse/SOLR-15967, which is really about RPM >> but strayed into security patching in general. >>> >>> Thanks, >>> Jan >
