Sitecore 10 Working with Docker – Using the Getting Started template

Sitecore provides a Getting Started template for Sitecore developers.

https://doc.sitecore.com/en/developers/100/developer-tools/walkthrough–using-the-getting-started-template.html

In the Developer’s Fundamentals 10 Collection training you are asked to use this this template.

I want to share with you my experience working with the Getting Started template.

After checking the prerequisites:

  • .NET Core 3.1 SDK
  • .NET Framework 4.8 SDK 
  • Visual Studio 2019
  • Docker for Windows
  • PowerShell 5.1 

We have to install the template by calling

dotnet new -i Sitecore.DevEx.Templates --nuget-source https://sitecore.myget.org/F/sc-packages/api/v3/index.json

To check if the installation was successful you need to check the templatelist for sitecore.aspnet.gettingstarted

After a successful installation check blocking if IIS is blocking port 443 by using:

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

The result should look like:

If not you can use the command

iisreset /stop

to stop the running IIS.

Afterwards it is again needed to check your system for a process blocking port 8984. You can again do this by using this command.

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

The result should look similar to the first one:

Otherwise you have to stop the service.

Now we are ready to call

dotnet new sitecore.aspnet.gettingstarted -n MyProject

A new folder with our MyProject solution will be created.

I placed the license file in the parentfolder, but it can be placed anyware on your file system.

We can now call the init file in the MyProject Folder with the parameters for the license path and the sitecore admin password to prepare our container environment.

.\init.ps1 -InitEnv -LicenseXmlPath "E:\gettingstarted\license.xml" -AdminPassword "admin123"

Now we are ready to run

.\up.ps1

Sounds great? Yes, BUT…

When the containers were starting i faced my first issue solr-init Container “*” is unhealthy.

I knew this one from previous trys with other docker containers and know that it is not alway very obvious from where this is comming.

When i looked into Docker Desktop i saw that myproject_mssql-init_1 has exited.

After looking into the logs i faced the issue:

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Named Pipes Provider: Could not open a connection to SQL Server [53]. .

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Login timeout expired.

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..

Where-Object : You cannot call a method on a null-valued expression.

At C:\StartInit.ps1:34 char:29

+ ...                Where-Object { $serverDatabases.Contains($_.BaseName)}

+                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [Where-Object], RuntimeExc 

   eption

    + FullyQualifiedErrorId : InvokeMethodOnNull,Microsoft.PowerShell.Commands 

   .WhereObjectCommand

It seemed that the containers could not find each other.

Editing the docker-compose.yml file and adding a hostname to the mssql service fixed this issue.

You have to add following statement:

 mssql:
    hostname: mssql
    isolation: ${ISOLATION}

Anyway the solr-init Container remained unhealthy.

After again looking into the logs, i saw another error:

2021-11-06 21:45:43.038 WARN  (main) [   ] o.e.j.u.s.S.config Trusting all certificates configured for Client@619bfe29[provider=null,keyStore=null,trustStore=null]
2021-11-06 21:45:43.038 WARN  (main) [   ] o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for Client@619bfe29[provider=null,keyStore=null,trustStore=null]
2021-11-06 21:45:43.257 WARN  (main) [   ] o.e.j.u.s.S.config Trusting all certificates configured for Client@4ef27d66[provider=null,keyStore=null,trustStore=null]
2021-11-06 21:45:43.257 WARN  (main) [   ] o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for Client@4ef27d66[provider=null,keyStore=null,trustStore=null]
2021-11-06 21:45:43.319 INFO  (main) [   ] o.a.s.c.SolrZkServerProps Reading configuration from: c:\data\zoo.cfg
2021-11-06 21:45:43.335 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
2021-11-06 21:45:43.335 WARN  (main) [   ] o.a.s.c.SolrZkServer Embedded Zookeeper is not recommended in production environments. See Reference Guide for details.
2021-11-06 21:45:43.835 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper client=localhost:9983
2021-11-06 21:45:44.413 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
2021-11-06 21:45:44.413 WARN  (Thread-12) [   ] o.a.z.s.ServerCnxnFactory maxCnxns is not configured, using default value 0.
2021-11-06 21:45:44.443 WARN  (NIOWorkerThread-1) [   ] o.a.z.s.NIOServerCnxn Close of session 0x0 => java.io.IOException: ZooKeeperServer not running
        at org.apache.zookeeper.server.NIOServerCnxn.readLength(NIOServerCnxn.java:544)
java.io.IOException: ZooKeeperServer not running

I spend again a lot of time figuring out how to solve this issue and came acrossfollowing discussion: https://github.com/docker-solr/docker-solr/issues/180

You have to add the Zookeeperport into docker-compose.yml

    isolation: ${ISOLATION}
    image: ${SITECORE_DOCKER_REGISTRY}nonproduction/solr:8.8.2-${SITECORE_VERSION}
    ports:
      - "8984:8983"
      - "9983:9983"

Afterwards the solr-init container started successfully, BUT now i faced the issue:

ERROR: for traefik  Container "62f910a2d439" is unhealthy

Looking in the logs again:

Message: The remote name could not be resolved: 'xconnect'

Again the containers could not reach each other.

If you are facing this issue you have to do the same as before and add a hostname to the service in docker-compose.yml :

  xconnect:
    hostname: xconnect

Voi lá it worked

Conclusion:

It might be that not everybody is facing the same issues, but i think it is helpful to know how to solve them, without googling around and spending hours in fixing similar problems.

Cheers,

Phil

Leave a Comment

Your email address will not be published. Required fields are marked *