Sitecore xp 10 running in Docker Containers (xp0 topology)

This blog follows the Installation Guide for Developer Workstation with Containers  apart from the excellent Sitecore documentation to Run your first Sitecore instance and the best part is the init.ps1 in the examples github repo that does the pesky job of filling the environment variables.

1. Used a Windows 10 Pro Azure VM. Note that if you are using your physical machine, the following ports need to be free as per the documentation -

Note that Traefik expects port 443 rather than the highlighted 433 in the documentation.

2. While creating the VM ensure that port 443 is left unused:

3. Ensure to select a vm size (Standard D8s V3) that supports hyper-v selection as part of programs and features:

Note that IIS must also be selected.

If using a physical machine, ensure to configure virtualization as part of initial BIOS setup as  per this link

4. Download and install Docker Desktop for windows

Note that Windows 10 is a pre-requisite to run Docker Desktop.

5. After installation and a vm restart, docker desktop must be available in the taskbar as an (whale) icon and should start automatically.

6. Right click the whale icon and must be able to access the dashboard -

Note the option to switch to windows containers in the above context menu

7. Also, from the cmd prompt (administrator), docker commands are recognizable:

8. Clone examples github repo to your disk

9. Copy over the getting-started folder and rename it as sitecore10-instn1 since the files in this folder will be used for installation

10. Also, copy over the Sitecore license file to c:\license folder.

11. Modify the init.ps1 script to reflect the host names for cert generation and host file entry:



12. Open the env file and ensure the variables listed below point to correct host names for cm and id servers:


13. Next, the init.ps1 script must be executed passing the license file path as parameter. The script will populate all the blank values here in this env file:

14. Execute init.ps1 providing the path to the license file as a parameter. The PS script will create and install SSL certificates for the domain names and update the env variable values:

15. Right click the docker (whale) icon and switch to windows containers before next step. If this is not done, the next step will throw a "x509 certificate signed by unknown authority" error while accessing the container registry

16. All set now, run the docker-compose up -d command in cmd prompt opened in administrator mode:

The images listed in the docker-compose.yml get pulled for the first time from the container registry. So, will take sometime to complete.

17. Next, the containers automatically start running one after another in the docker desktop dashboard

18. Wait for the cmd prompt to comeback

19. Run docker-compose ps command to check if all containers are healthy. 

Note that it is ok for solr to be just Up status as far as i checked. Its still considered healthy. The most important aspect is all urls must be accessible as per point 21 below.

20. One common reason for a container to return unhealthy status is the port blocked by another service. Before running the docker-compose up command. you can use this PS Script to check if a port is blocked by another process (thanks to stackoverflow):

Get-Process -Id (Get-NetTCPConnection -LocalPort YourPortNumberHere).OwningProcess

In case if you have a solr service already running in port 8984, ensure to stop the concerned service before running docker-compose up -d.

21. If you made changes to the host names alone(as outlined in points 11 and 12), then all the following urls must respond:

a. Sitecore Content Management (cm): https://sc10-instn1cm.localhost (changes based on the domain name chosen in steps 11 and 12)


b. Sitecore Identity Server (id): https://sc10-instn1id.localhost (changes based on the domain name chosen in steps 11 and 12)


c. Sitecore xConnect Server (xconnect): http://localhost:8081

d. Apache Solr (solr): http://localhost:8984


e. Microsoft SQL Server (mssql): localhost,14330

Login to SQL Server with localhost, 14330 as server and provide sa as username and password: Password12345 if you haven't changed the defaults in the env file. But, I didn't install SQL Server in this VM to check how docker treats this scenario. Silly me!

f. Traefik: http://localhost:8079

 

Content Editor:

Note that the default password (set in env file) is Password12345 and not b!

22. If ever one or more of the containers look red in the dashboard and you are sure you didn't make any changes to the compose file, Execute docker-compose down to remove all containers followed by docker-compose up -d for a fresh start.

Note that i didn't install SQL Server or setup SOLR in my vm environment, its all taken care by docker-compose file. I even didn't access inetmgr.

That's it... Happy Dockering while Sitecoring!

------

Common Errors:

Error:

Update-Module : Module 'SitecoreDockerTools' was not updated because no valid module was found in the module

directory. Verify that the module is located in the folder specified by $env:PSModulePath.

At line:1 char:1

+ Update-Module -Name SitecoreDockerTools -RequiredVersion 10.0.5

Solution

1. Install-Module -Name SitecoreDockerTools

2. Update-Module -Name SitecoreDockerTools -RequiredVersion 10.0.5

Also, install latest version of powershell from here and restart the powershell prompt

Error:

ERROR: for xdbautomationworker  Cannot start service xdbautomationworker: container 0c5334985b611ec62748ccf57612c14de1c65c9ab0bfe34d1b2dee271b94f906 encountered an error during hcsshim::System::Start: context deadline exceeded

ERROR: Encountered errors while bringing up the project.

Context and Solution: This happens when you docker-compose up. I suspect this is due to some kind of locking or a race condition. Frankly, need to understand the cause better since this can happen with any of the services. I follow this as a temporary solution:

Perform docker-compose down, ensure Docker dashboard is clear. Delete msql-data and solr-data folder contents. Restart machine and retry docker-compose up. I do this when the concerned service has run fine in the past but didn't go through this time and I'm sure my env variable values (and, the docker compose file) are correct and unhampered.

Error:

ERROR: for sitecore-xp0_solr_1  container 1ef15fc659816f21e105b214f88eaab2cc529e726ebab26adcc50f019a39262c: driver "windowsfilter" failed to remove root filesystem: failed to detach VHD: The device is not ready.: rename C:\ProgramData\Docker\windowsfilter\1ef15fc659816f21e105b214f88eaab2cc529e726ebab26adcc50f019a39262c C:\ProgramData\Docker\windowsfilter\1ef15fc659816f21e105b214f88eaab2cc529e726ebab26adcc50f019a39262c-removing: Access is denied.

Removing network sitecore-xp0_default

Solution: This is a common error applicable for all containers when running docker-compose down. I manually delete the concerned container in the dashboard and ensure the state is dead in the dashboard and restart  Docker to see the container cleared, restart the machine. Clear the solr-data folder contents before next docker-compose up.

Error:

ERROR: for sitecore-xp0_mssql_1  container 26a4e4d6816c13799eb5f66e9e1aee039d61d143889823ed54fde6ad52638fe7: driver "windowsfilter" failed to remove root filesystem: failed to detach VHD: The device is not ready.: rename C:\ProgramData\Docker\windowsfilter\26a4e4d6816c13799eb5f66e9e1aee039d61d143889823ed54fde6ad52638fe7 C:\ProgramData\Docker\windowsfilter\26a4e4d6816c13799eb5f66e9e1aee039d61d143889823ed54fde6ad52638fe7-removing: Access is denied.

Removing network sitecore-xp0_default

Solution: This is a common error applicable for all containers when running docker-compose down. I manually delete the concerned container in the dashboard and ensure the state is dead in the dashboard and restart  Docker to see the container cleared, restart the machine. Clear the mssql-data folder contents before next docker-compose up.

Error:

ERROR: for xdbsearchworker  Container "ea3c1c3ae196" is unhealthy.

ERROR: for cortexprocessingworker  Container "ea3c1c3ae196" is unhealthy.

ERROR: for xdbautomationworker  Container "ea3c1c3ae196" is unhealthy.

ERROR: for traefik  Container "9fea49907d2e" is unhealthy.

ERROR: Encountered errors while bringing up the project.

ERROR: for id  Container "621154deaf50" is unhealthy.

ERROR: for xconnect  Container "621154deaf50" is unhealthy.

ERROR: Encountered errors while bringing up the project.

Solution: This is a common error applicable for all containers when running docker-compose up -d. If I'm sure there was no change made to the compose file, I docker-compose down and then try docker-compose up -d. 

I also suspect that most of the above errors relate to service dependencies listed in the docker-compose file. In other words, services supposed to complete before dependent services don't complete on time due to the machine RAM processing power. So, I switched to a RAM with higher configuration like, Standard D8s v3 (32 GB RAM) from D4s_v3 (16 GB RAM) and that seemed to help.

Further Update: The timeout issue happens even with 32 GB RAM and what works is docker-compose down, clear container from docker dashboard,  delete contents of mssql-data and solr-data folders, restart machine and retry docker-compose up -d.

Comments

Popular Posts