チャプター1
紹介
Sitecore 10 のリリースでは、Docker コンテナー内での Sitecore の実行のサポートが導入されました。これにより、素晴らしい開発エクスペリエンスが実現し、ローカルマシンからSitecore環境全体をすばやく簡単に作成および削除できるようになりました。長く引き延ばされたインスタレーションの日々は、ついに過去のものとなりました。
開発コミュニティは、当然のことながら、Sitecoreとの連携に関するこの変更に興奮しています。しかし、開発を過ぎて、ノンプログラミング環境とプロダクション環境にソリューションをデプロイする場合はどうなるでしょうか。コンテナの外部で作業する場合と同様に、このプロセスを自動化するために継続的インテグレーション(CI)パイプラインを構成する必要があります。
この記事に付属するビデオでは、これらの概念のデモをDiscover Sitecore YouTube チャネル.
チャプター2
コンテナを使用する場合、CIはどのように異なりますか?
コンテナのCIパイプラインを設定する場合、設定方法は少し異なります。コンテナの外部で作業する場合は、通常、アプリケーションをビルドし、それらをホストしているIaaSまたはPaaSインスタンスに直接プッシュします。コンテナを使用すると、このプロセスが少し変わります。
コンテナを使用する場合、CI プロセスの目的は、新しいイメージのセットをビルドし、それらをコンテナレジストリにプッシュすることです。このアクションが完了すると、デプロイの CI フェーズが完了します。
チャプター3
Docker Compose を活用する
デプロイメントのこのCIフェーズの良いところは、ローカル開発セットアップに使用するDocker Composeを活用して、イメージのビルドも自動化できることです。これの優れた点は、開発マシンで使用したのと同じ命令を使用して、ノンプログラミングインスタンスとプロダクションインスタンスで使用されるイメージをビルドできることです。これにより、デプロイする内容に対する信頼性が高まり、誰もが知っている「私のマシンで動作する!」という問題が減少します。
チャプター4
画像のタグ付け
コンテナを使用する場合、イメージのタグ付けの概念は、アプリケーションのどのバージョンをどの環境にデプロイするかを制御できるため、重要です。コンテナを操作する場合、イメージタグには、Stable タグと Unique タグの 2 種類があります。
安定したタグ
安定したタグ, represented by the green boxes above, are primarily used for base images — you inherit from them to build your images, and they're rarely used for deployments themselves. The reason? They change over time. If you pull the same stable image tag today and then again next week, you could actually get two different images. This is because the images using these tags are re-issued over time to represent versions updates, or base image changes.
ユニークなタグ
ユニークなタグ, represented by the dark grey boxes above, are primarily used for deployments, especially in environments that scale to multiple nodes, or running inside of an orchestrator like Kubernetes. This is because the image behind a unique tag won't change, giving you confidence that the image you pull today is the same as the image you pulled at a previous time.
(さらに詳しく知りたい場合は、Microsoftがこれらのタイプのタグの違いについて優れた記事を書いていますここは.)
チャプター5
画像更新トリガー
イメージの更新はさまざまな理由でトリガーされますが、最も一般的な 2 つはコードの変更または基本イメージの更新です。コードを変更すると、コードベースに加えられた変更を含めるために、イメージを再構築する必要があります。
基本イメージの更新では、依存する基本イメージの 1 つが更新されている間、コードベースは変更されません。これは、Sitecore イメージの 1 つまたはベース MS イメージの 1 つである可能性があります。これには、バグ修正やセキュリティ更新などの重要な更新を含めるために、新しいイメージを公開する必要もあります。
チャプター6
コンテナレジストリ
イメージをビルドしたら、CI パイプラインで実行する必要がある最後のアクションは、Azure Container Registry などのコンテナー レジストリにイメージをプッシュすることです。これにより、チームの他の開発者がそれらを利用できるようになり、ノンプログラミング環境やプロダクション環境でも使用できるようになります。
チャプター7
MVP サイトで利用可能なパイプラインの例
このようなパイプラインの構成方法の例を確認したい場合は、MVP サイト プロジェクトをご覧ください。これには、完全に機能する CI/CD パイプラインがあり、独自のパイプラインをベースとすることができます。Azure DevOps で使用する YAML 構成を確認できますここは.