Jeremy Davis
Sitecore, C# and web development
Sometimes things you think you know turn out not to be right. I got bitten by this issue recently, and it seemed like something to write down. Because being wrong is fine, as long as you learn something...
I had another "things work differently in containers" moment recently. One of the fun points of changing the approach to your deployments is that sometimes you have to look differently at how some core configuration issues too. And this seems like an issue others will encounter too:
To customise a very old joke, there are only two difficult issues in IT: Naming things, Time calculations, and off-by-one errors. And adding containers into the mix raises even more fun. I recently hit an issue where containerised Sitecore needed to use a different time zone to the physical servers it was hosted on. So what can be done to configure this? Here's two things that can help:
A while back I wrote up some notes on a problem some people were seeing with Sitecore's SolrCloud developer container that I'd been unable to fix. It was the worst sort of technical problem, happening irregularly on some computers, but never rearing its head on others. So it's taken me a while to get around to coming up with a fix for this. But if you've suffered from the problems described in my previous post, this is an option for you:
Most of the time when I want to explore the filesystem of a Sitecore container, it's pretty easy. I can use Visual Studio's container browser. But that only works when a container is running - and if it's based on a job image this may be a very brief window - too brief to find and explore the file in question. So what can I do?
The other day my copy of Docker Desktop on two different work laptops prompted me to update. And neither would work properly after the update completed. In case this issue is affecting others, here's the saga of what I saw and two ways it can be fixed:
Usually with these blog posts, I find a problem, I fight with it for a bit, and then I solve the problem. But this post has been sitting half-written in my publishing queue since May (!) this year, and I have entirely failed to solve this issue. So I'm admitting defeat, and publishing this anyway because maybe one of you knows the answer. Or at least it might serve as a warning...
My issue is that I've been working through some really odd and annoying Solr issues which only manifest in Docker on one laptop. I'm really not sure if these are issues that others might see, or if this is a problem that's entirely down to this laptop's setup. But they're definitely a problem...
One thing we don't seem to be short of these days is options for deploying Solr. I've had to do a bit of thinking about this recently, as I draw up plans for a work project. So I figured I'd write a bit of it down because if I'm having to explain it to people, then chances are there are plenty of others out there in Internet Land who are finding themselves having to think about these issues too:
If you're part of the Sitecore Partner or MVP community then you probably watched some of the content from their "Global Sales Kick-off" recently. They talked about product roadmap and strategy stuff for the coming year, especially the new XM Cloud product. But something else which Dave O'Flanagan called out in his session is of interest to us in the community too: Sitecore's new internal demo portal.
The need to spin up a demo instance of Sitecore has been a common challenge for me over the time I've worked with the product. There have been various ways to do this - some very manual, and some involving a bit more automation. Different organisations and people all had their own approaches to how best to do this - but it's now being looked at centrally. I was lucky enough to get a sneak-peak of their new approach to this problem. And now it's been launched it seemed like something worth writing up, to make more Partners and MVPs aware of the tools at their disposal.
One of the recurring themes of deploying Sitecore over the last few years has been "how do I deal with Solr?". It's a question with many valid answers... I've been doing some research for a client recently, because they wanted to run their own SolrCloud instances in Kubernetes - and I came across the Apache Foundation's "Solr Operator" project. It's an interesting shortcut to efficient containerised deployments of Solr, and it might help you too...
