into the wild today and it comes with a refined developer experience that includes official container support. This is super exciting and really helps solidify my thoughts around Docker and its role in the Sitecore developer ecosystem.
Well, I jumped right in and, while things appeared to be going smoothly (all images downloaded successfully), I stumbled on this error when composing the container up:
At first glance, this looked like a collision issue with some existing Docker NAT network residual from my other Docker containers.
I tried:
- Pruning the Networks using the VS Code Docker Extension:
- Stopping all Docker processes and its relevant services, and restarting:
- Restarting my machine
None of these attempts helped, unfortunately.
If we look at how Solr is defined in the docker-compose.yml file, we'll see that the port is set to map to :8984 on your local machine to :8983 on the running Solr container.
In my case, I have multiple Solr instances running on my machine from previously installed Sitecore instances:
Whenever I installed new Solr instances, avoiding using ports that were already being used for existing Solr instances was a prerequisite (eg. if I have one version of Solr running on 8983, for the new version of Solr I'd use 8984. If I needed another version of Solr, that one would use 8985, etc). The same applies in this case.
Because the default Sitecore 10 Docker Compose is trying to use port 8984, it must be available.
I navigated to each Solr installation on the filesystem and confirmed that port 8984 was in fact mapped to my local 5.4.1 Solr instance.
By stopping the running 5.1.4 Solr service on my local machine, I was able to free up the port 8984, allowing the Solr instance in the Docker container to occupy it:
Happy Sitecore Release Day! 👍