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
