Docker is an open platform for developing, shipping, and running applications.
We have introduced the procedure for deploying Sitecore on the Azure Kubernetes Service. This time, we will check the procedure for setting up an environment that enables the same process on macOS.
We have introduced Sitecore on Azure Kubernetes Service in two parts as a preparation for deploying Sitecore on Azure Kubernetes Service. This time, we are ready to deploy Sitecore on Azure.
Regarding the setup procedure for deploying Sitecore using AKS, we will now create the data in the various configuration files. The data in the configuration files will be used as the data for the actual deployment.
Docker is a convenient mechanism for running Sitecore at hand, but when it comes to using containers for operations, it is more convenient to use Azure Kubernetes. Kubernetes is a convenient way to deploy containers.
We've covered how to run Sitecore in Docker containers locally. However, these steps differ from those for deploying to cloud services. For actual operations, Sitecore is combined with Azure Kubernetes Service (AKS).
This page lists the most common points that are caught when using Sitecore containers. We will add more as we find them in the future.
Previously, we installed Sitecore Management Services. Now, we will install the Sitecore Headless Services module. Additionally, since the SXA module is included by default and won't be used, we will remove it.
To enable working with custom images using the Sitecore CLI, we need to add Sitecore Management Services. Without this on the CM server, the CLI won't function. This guide covers container setup, while for other environments, please install via package.
We have been able to create a custom image, but the administration screen, etc., is still in English. This section introduces the procedure for adding Japanese resources and settings so that Japanese language can be handled.
Since we were able to start using the sample custom image, we will now introduce some unnecessary parts and points that need to be changed for future use.
So far, we have been testing the operation by launching a sample Docker image, but in reality, we will be creating an image that contains the modules we will need. This time, we will create a custom image that you want to use yourself from the sample.
In the previous article, we only prepared the environment and did not start the container. This time, we will check how the container will be started by referring to the script up.ps1 to run the sample.