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?
I was trying to understand how the Sitecore 10.3
solr-init
image functions recently. I wanted to look at how it goes about creating the various Solr Collections required, because I'd been asked some questions about a client's DevOps release process. But when you fire up your Sitecore instance in Docker and try to look into the
solr-init
container you see this:
If the container isn't running you can't browse its filesystem. And that's an issue with a job image, which starts, does its job and stops again rapidly.
One fairly low-effort way to solve this issue is to start up the image yourself and get it to run your shell, rather than relying on
docker-compose
. My first thought was to try something like this:
docker run -it sitecore-xm1-solr-init powershell.exe
But that doesn't work here - the image has an entrypoint defined, which gets run whenever a container starts from this image. And because this is a job image, that process ends once it's done its work, and so does the container.
This command line is similar to using "Run Interactive" context menu option on an image from the Visual Studio Containers Window's Images tab. And using that context menu can point out another problem with this approach - most Sitecore containers have entrypoints which rely on environment variables, and using this approach may not start the image with the working directory set to a location with valid
.env
file. And in that sceniaro your container starts, errors and quits - which again means you can't easily browse the contents.
But a bit of digging in Google lead me to a subtle change of command:
docker run -it --entrypoint powershell.exe sitecore-xm1-solr-init
You can specify a replacement for the entrypoint, and if that is your shell then the container won't stop until you exit that shell. It won't do any of it's "proper" work, but it will leave you connected. But likely in the scenario where you just want to explore the contents that's fine - you'd don't need it to be running the code, just staying up so you can browse.
So you can explore the contents via the shell:
And you can also make use of Visual Studio's Containers window too:
And when you're finished, you can type
exit
in the shell window and it will shut down. Remember to delete the stopped container though - this won't do that automatically.