Running Sitecore on Docker (fully supported) is relatively new (as of version 10.0+), and there is fantastic documentation available on the internet for getting started.
The goal of this post is not to re-document installation steps, but to cover the less-documented issues you may encounter during installation (and after) with your Sitecore Docker containers. Personally, I experienced numerous issues when getting started locally. It was a bit discouraging to be honest, but after getting through the weeds, the benefits began to show their true colors. If I can help ease said “weeds,” this post will have served its purpose!
Note: There are various scenarios and issues you may encounter depending on your version of Sitecore, developer workstation OS, selected topology, etc. For the sake simplicity and focus (and not trying to solve all the world’s problems) we will be focusing on Docker-related issues encountered while installing and running Sitecore 10.2 XP0 on Windows 10.
If you do need a recap on the installation process, here is Sitecore’s documentation for setup with Docker containers.
Issues I Encountered While Installing/Running Sitecore on Docker
Index
- CoreContainer Is either Not Initialized or Shutting Down
- A Parameter Cannot Be Found That Matches Parameter Name ‘AllowPrerelease’
- Cannot Start Service
- Container Cannot Connect to SQL Server
- Changes Are Not Reflected After builds/deploys
- Error Occurred During POST to Remote Rendering Host JSS-Render
- Multiple Powershell Commands Not Recognized
- The Remote Name Could Not Be Resolved
- Default/Fallback Things You Can Try
CoreContainer Is either Not Initialized or Shutting Down
This issue manifested itself with errors related Solr being unable to connect to ZooKeeper
Sample logs:
javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down. ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home property and the logs ERROR (main) [ ] o.a.s.c.SolrCore null:org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper localhost:9983 within 30000 ms
Additionally, the Solr dashboard would display this error in the web browser:
HTTP ERROR 404 javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down. URI: /solr/ STATUS: 404 MESSAGE: javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down. SERVLET: default CAUSED BY: javax.servlet.ServletException: javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down. CAUSED BY: javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down.
Things you can try:
- Restart your Docker container for Solr. If the container comes up, try accessing your Solr dashboard in the browser. If the issue is resolved, it should come up with no errors.
- Try a docker-compose restart
- When running Sitecore’s “MyProject” samples, the above did not work for me. That said, I tried deleting my source files and starting from scratch. For some reason or another, the issue did not come back after that. Perhaps a configuration setting or installation value was changed from my first install.
A Parameter Cannot Be Found That Matches Parameter Name ‘AllowPrerelease’
This may mean your PowerShellGet Module needs updating
Try running:
Update-Module PowerShellGet -Force
If you get: “Module ‘PowerShellGet’ was not installed by using Install-Module”
Then try running:
Install-Module PowerShellGet -Force
Cannot Start Service
I randomly started getting this error after installing Windows updates and rebooting my PC. Docker-compose up -d would result in multiple “ERROR … Cannot start service for ____”
What worked, and what is good default/fallback troubleshooting:
In Powershell, run “docker-compose down” to remove containers and network settings. After this, rebuild your containers with “docker-compose up -d”
Container Cannot Connect to SQL Server
You might see some generic “container is unhealthy” errors in your Traefik logs, but you may also see more specific errors related to connectivity to SQL in Xdb and Cortex logs. Like:
ERR Health check "marketing automation sql" completed after 691.437ms with status Unhealthy and '"Error message: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"'
Make sure you port 14330 is available. You can also run a command in Powershell to check your container’s connectivity to the port like so:
docker run --rm mcr.microsoft.com/windows/servercore:1903 powershell -Command echo ((new-object Net.Sockets.TcpClient).Client.Connect('127.0.0.1', 14330)) 'success'
Changes Are Not Reflected After builds/deploys
I experienced a scenario where configuration changes and code changes were not being reflected in my rendering host site. Builds and publishes were successful with no errors, however, no changes.
What my issue was: The sitecore-docker-tools-assets image was missing in Docker, therefore the deployment scripts were not available and running … I had to download the docker image(s) from https://github.com/Sitecore/docker-tools/, switch to the 10.2 version specific branch at the time, and run the docker-compose build command.
What it could also be: You might see an error in your logs like, “Could not copy … being used by another process.” I did have an issue sometimes where I would have to stop my containers before performing a build/publish in Visual Studio. This is because Docker had a lock on files being accessed by VS, so it caused a collision. After the build was done, I started the containers and everything was deployed. Of course, this is not an ideal workflow and was extremely irritating. The fix for this issue will have to be a post for another day!
Error Occurred During POST to Remote Rendering Host JSS-Render
This error occurred when trying to open my headless ASP.NET Core site with Experience Editor. I was using the ASP.NET Core Rendering Host sample project from Sitecore.
Errors in the logs may look like:
Error occurred during POST to remote rendering host "rendering/jss-render" Error Rendering Sitecore.JavaScriptServices.ViewEngine.Presentation.JsLayoutRenderer: The remote server returned an error: (404) Not Found.
Thankfully, I was able to find this same issue reported (and resolved) by Rob Earlam. Check out his post, “.NET Core Rendering Host – Experience Editor 404 error.”
To summarize, there were two environment variables I needed to add to my rendering host in the docker-compose.override.yml file.
Sitecore__RenderingHostUri: "https://${RENDERING_HOST}" Sitecore__EnableExperienceEditor: "true"
Multiple Powershell Commands Not Recognized
For some reason or another, PS custom commands in the Sitecore Docker Tools were not recognized when running the compose-init.ps1.
This of course is not the ideal solution, but to get past it without too much fuss, I merely included the ps1 files that contained the missing commands. For example, I received this error, “The term ‘Create-RSAKey’ is not recognized as the name of a cmdlet.” I found the function “Create-RSAKey” in the “Get-SitecoreSelfSignedCertificate.ps1” file. Thus, simply including this file in my compose-init.ps1 made the function available.
You can include it like so:
. "C:\<your-folder-path>\Get-SitecoreSelfSignedCertificate.ps1"
Repeat this as-needed for any other missing commands.
The Remote Name Could Not Be Resolved
I experienced this issue in Powershell when docker-compose was trying to reach out to api.nuget.org to download packages. I believe this can generally occur when your containers are needing to reach out to the internet.
Sitecore has some helpful documentation about this: https://doc.sitecore.com/xp/en/developers/100/developer-tools/troubleshooting-docker.html#windows-containers-cannot-access-the-internet_body
They suggest running a PS command to update the InterfaceMetric value for your active network adapter. Try this, it should work. Unfortunately for me, I ran into a permissions issue where this was not allowed on my PC. Access Denied.
What worked: I was working on Wi-Fi, but my InterfaceMetric for the active connection was not the connection with the lowest metric. What I ended up doing was plugging in an ethernet cable to my PC. Luckily, my now active connection had the lowest metric with the ethernet adapter. It worked now! (I went back to Wi-Fi after this step.)
At the Last – Default/Fallback Things to Try
You will find issues that aren’t in this post, or you may not have any luck with my suggestions. That being the case, there are a few things you can always try when nothing else does. Sometimes they do the trick.
- Restart Containers – Occasionally, restarting a container will correct whatever services or issues are occurring in that container. You can restart a container by running this command: docker restart <name of container>
- “Down” then “Up” – Sometimes data gets stale/cached/corrupted in the containers and it needs to be purged. Run the “docker-compose down” command to remove containers. Follow-up by rebuilding them with “docker-compose up -d”
- If you don’t want to purge all containers, you can “down” a single container. To do so, run:
- docker stop <container name> #you have to stop the container first
- docker rm <container name> #removes the container
- docker-compose up -d #rebuilds the containers that aren’t up to date
- If you don’t want to purge all containers, you can “down” a single container. To do so, run:
- Run “docker-compose up -d” – Sometimes a required configuration or setting gets removed. Running the up-d will rebuild your containers as specified in your docker-compose configurations.
- Stop IIS – iisreset /stop – You’ll run into multiple scenarios where you cannot have IIS running (like a port collision.)
- Logs – Check your various containers’ logs. Also check your Docker engine (daemon) logs – C:\Users\%USERNAME%\AppData\Local\Docker
- Restart Docker Desktop – You can restart from the Docker “whale” icon in your Windows system tray.
- Reboot – Sometimes a good ol’ reboot does the trick!
I hope this post has proven helpful to you. Getting started with Docker can sometimes be troublesome—albeit discouraging—at first, but don’t let that stop you. The benefits of leveraging Docker outweigh the initial hurdles!
If you would like more information on Sitecore + Docker solutions, we’d love to help.
Reach out to me on LinkedIn or fill out our contact form.
Subscribe to our weekly blog digest to get notifications when each part is published and drop comments below with any questions.