Sitecore, Docker und Continuous Integration

Mit der Veröffentlichung von Sitecore 10 haben wir die Unterstützung für die Ausführung von Sitecore in Docker-Containern eingeführt. Dies ermöglichte eine fantastische Entwicklung Erlebnis/Erfahrung, die es Ihnen ermöglichte, ganze Sitecore-Umgebungen schnell und einfach von Ihrem lokalen Computer zu erstellen und zu entfernen. Die Zeiten langer, langwieriger Installationen gehören endlich der Vergangenheit an!

Die Entwicklung Community freut sich verständlicherweise über diese Änderung der Zusammenarbeit mit Sitecore. Aber was passiert, wenn Sie die Entwicklungen hinter sich lassen und mit der Bereitstellung Ihrer Lösung in Ihren Nicht-Produktions und Produktionen beginnen möchten? Nun, genau wie bei der Arbeit außerhalb von Containern sollten Sie eine CI-Pipeline (Continuous Integration) konfigurieren, um diesen Prozess für Sie zu automatisieren.

Sehen Sie sich das Video zu diesem Artikel an, das Demos dieser Konzepte auf unserer Entdecken Sie Sitecore YouTube Kanal.

Bei der Konfiguration einer CI-Pipeline für Container werden die Dinge etwas anders eingerichtet. Wenn Sie außerhalb von Containern arbeiten, erstellen Sie Ihre Anwendung in der Regel und übertragen sie dann direkt an die IaaS- oder PaaS-Instanzen, auf denen sie gehostet werden. Durch die Verwendung von Containern ändert sich dieser Prozess geringfügig.

Wenn Sie mit Containern arbeiten, besteht das Ziel Ihres CI-Prozesses darin, einen neuen Satz von Images zu erstellen und diese in Ihre Container Registry zu übertragen. Wenn diese Aktion abgeschlossen ist, ist die CI-Phase Ihrer Bereitstellung abgeschlossen.

Das Gute an dieser CI-Phase der Bereitstellung ist, dass wir die Docker Compose, die wir für unser lokales Entwicklungs verwenden, nutzen können, um auch unsere Image-Builds zu automatisieren. Das Tolle daran ist, dass wir die gleichen Anweisungen verwenden können, die wir auf unserem Entwicklungs verwendet haben, um die Images zu erstellen, die in unseren Nicht-Produktion und Produktion verwendet werden. Dies erhöht das Vertrauen, das Sie in das haben, was Sie bereitstellen, und verringert gleichzeitig die "Es funktioniert auf meinem Computer!"-Probleme, die wir alles kennen.

Bei der Arbeit mit Containern ist das Konzept des Image-Taggings von entscheidender Bedeutung, da Sie damit steuern können, welche Version Ihrer Anwendung in welcher Umgebung bereitgestellt wird. Bei der Arbeit mit Containern gibt es zwei verschiedene Arten von Bild-Tags: Stabile Tags und eindeutige Tags.

Stabile Tags

Stabile Tags, dargestellt durch die grünen Kästchen oben, werden in erster Linie für Basisimages verwendet – Sie erben von ihnen, um Ihre Images zu erstellen, und sie werden selten für Bereitstellungen selbst verwendet. Der Grund? Sie verändern sich im Laufe der Zeit. Wenn Sie heute und nächste Woche dasselbe stabile Tage ziehen, können Sie tatsächlich zwei verschiedene Bilder erhalten. Dies liegt daran, dass die Images, die diese Tags verwenden, im Laufe der Zeit erneut ausgegeben werden, um Versionsaktualisierungen oder Basisimageänderungen darzustellen.

Eindeutige Tags

Eindeutige Tags, die durch die dunkelgrauen Kästchen oben dargestellt werden, werden in erster Linie für Bereitstellungen verwendet, insbesondere in Umgebungen, die auf mehrere Knoten skaliert werden oder in einem Orchestrator wie Kubernetes ausgeführt werden. Dies liegt daran, dass sich das Bild hinter einem eindeutigen Tage nicht ändert, sodass Sie sicher sein können, dass das Bild, das Sie heute ziehen, mit dem Bild übereinstimmt, das Sie zu einem früheren Zeitpunkt gezogen haben.

(Wenn Sie nach mehr suchen, hat Microsoft einen guten Artikel über den Unterschied zwischen diesen Arten von Tags hier.)

Image-Updates können aus verschiedenen Gründen ausgelöst werden, aber die beiden häufigsten sind eine Code-Änderung oder eine Basis-Image-Aktualisierung. Bei einer Codeänderung müssten die Images neu erstellt werden, um die an der Codebasis vorgenommenen Änderungen einzuschließen. 

Bei Basisimageaktualisierungen hat sich Ihre Codebasis nicht geändert, während eines der Basisimages, von denen Sie abhängig sind, aktualisiert wurde. Dies kann eines der Sitecore-Images oder eines der MS-Basis-Images sein. Dazu muss auch ein neues Image veröffentlicht werden, das wichtige Updates enthält, z. B. Fehlerbehebungen und Sicherheitsupdates.

Nachdem Sie Ihre Images erstellt haben, besteht die letzte Aktion, die Sie in Ihrer CI-Pipeline ausführen müssen, darin, sie per Push an eine Containerregistrierung wie Azure Container Registry zu übertragen. Dadurch stehen sie anderen Entwicklern in Ihrem Team zur Verfügung und können auch in Ihren Nicht-Produktions und Produktionen verwendet werden.

Wenn Sie ein Beispiel für die Konfiguration einer solchen Pipeline sehen möchten, können Sie einen Blick auf das MVP-Site-Projekt werfen. Dies verfügt über eine voll funktionsfähige CI/CD-Pipeline, auf der Sie Ihre eigene aufbauen können. Sie können die YAML-Konfiguration für die Verwendung in Azure DevOps hier sehen.