It’s a perfectly normal day, you’re working on a new feature, things are going well. You finish making your change, build your solution, start your docker containers…
You’ve got the dreaded “Unhealthy”, spelled out in red just for extra dread. What do you do? First, don’t panic. It was working yesterday, or earlier today, you know there’s nothing wrong with your Sitecore or Docker setup itself. It has to be in the changes you just made, or some other local state. Since the Sitecore setup depends on CM, and your code changes get deployed there, let’s use that as our example. Of course, if your problem is the CD container, the same method will work.
Second, let’s make absolutely sure the regular logs aren’t working. Even if the containers show up as unhealthy, the logs could be there and have useful information. Open Docker Desktop and find your container, then click on its name to open the log. This method works fine for the containers that aren’t Sitecore instances, like rendering or solr, too.
In this case, cm-1 is my Sitecore CM container, second from the bottom. Click on the name right next to the green box, and you might get a view like this:
If you do, you’ve got the logs ready and you can download it, search for exceptions, and do your normal debugging.
That didn’t work! Or worse, it says “error” instead of “running” and nothing happens at all. What now? This is where the fancy trick comes in. First, run docker ps
from Powershell. This will give you a list of all your containers, and you can grab the ID of your container for the next step.
In this case, the id of my cm container is 24a6e1eee158
. Next, run docker inspect 24a6e1eee158
. That will give you a long chunk of data, but the part you are looking for says “IPAddress” near the very end.
Take that IP address, and go to your browser, and load up http://ipaddress/healthz/ready, like this: http://172.27.248.45/healthz/ready
Well, knowledge at least. It’s our old friend, the Yellow Screen. In this case, I’m missing a file, or have changed the wrong section of the web config. You might have a null reference exception, or a missing dll, or any of the usual cases. So you might not be better off, technically, but now you know what the problem is and can solve it the normal way.