Sitecore Environment 10.1에서 비즈니스 엔진 및 Docker와 협력

최근 Docker에서 Sitecore를 사용하여 비즈니스를 체험한 개발자와 합작했다.현재 우리는 Docker와Sitecore 체험 플랫폼을 어떻게 사용하는지에 대한 예가 많다. 예를 들어 내가 앞서 언급한 MVP Site 구축 등이다.
비즈니스 체험에 대해 말하자면 우리는 설치 지침을 가지고 사람들에게 어떻게 응용 프로그램이 현지 개발자의 기계에서 실행되는지 보여 주었다. 그러나 나는 우리가 비즈니스 엔진을 구축하는 맞춤형 해결 방안을 용기화하는 좋은 예가 없다는 것을 곧 깨달았다.
그래서 나는 하나를 한데 놓고 간단한 예로 그것을 어떻게 배치하는지 설명하기로 결정했다.나는 처음에 적당한 해결 방안을 찾으려고 시도했다. 나는 곧 XC on prem을 탑재한 Customer.Sample.Solution.sln이 이런 상황에 매우 적합할 것이라고 결정했다.

솔루션 수정
내가 하는 첫 번째 일은 해결 방안을 XCDocker.Sample.Solution으로 바꾸는 것이다. 이렇게 하면 사람들이 그것을 원시 해결 방안과 구분할 수 있다.이어서 나는 docker-compose에 첨부된 .env과 Sitecore.Commerce.Container.SDK 파일을 가져왔다.이것은 나에게 상자를 열면 바로 사용할 수 있는 XC 10.1 docker 구조를 지원할 수 있는 해결 방안을 주었다. 나는 XC1-CXA 토폴로지를 선택했다. 왜냐하면 나도 가게를 테스트하고 싶기 때문이다.
이제 Sitecore에서 발표한 엔진이 아닌 이 버전의 엔진을 구축해야 합니다.새 용기부터 시작하든지,Sitecore에서 발표한 엔진 이미지에 이 엔진 코드를 층으로 나누든지 두 가지 선택이 있습니다.엔진을 구축할 때 완전한 응용 프로그램을 구축했기 때문에, 첫 번째 옵션이 처음에는 맞는 것 같습니다.그러나 Sitecore가 발표한 엔진 이미지는 엔진 코드만 포함하는 것이 아니라 LogViewer 입구점 같은 내용도 포함한다. 만약에 새로운 용기를 시작하면 내가 이 내용을 추가해야 하기 때문에 나의 두 번째 옵션을 사용하면 Sitecore가 발표한 엔진 이미지 위에 나의 엔진 코드를 층으로 나누는 간단한 선택이 된다.

Dockerfile 만들기
다음에 나는 반드시 실제적으로 Dockerfile을 만들어야 한다. 계획은 예전과 같이 multi-stage build을 설정해야 한다. 이것은 우리가 구축할 때 사용하는 이미지가 실행할 때와 다르다는 것을 의미한다.이것은 우리가 실행할 때 이미지를 가능한 한 간소화할 수 있다는 것을 의미한다.
Dockerfile을 보시면 출력 자산을 가져와 Sitecore 엔진 이미지로 나누기 전에 이미지를 구축할 수 있습니다.

# Args
ARG BUILD_IMAGE
ARG RUNTIME_IMAGE

# Build Stage
FROM ${BUILD_IMAGE} as Build
WORKDIR /app

COPY ./nuget.config ./nuget.config
COPY ./XCDocker.Sample.Solution.sln ./XCDocker.Sample.Solution.sln
COPY ./src/Plugin.Sample.AdventureWorks/Plugin.Sample.AdventureWorks.csproj ./src/Plugin.Sample.AdventureWorks/Plugin.Sample.AdventureWorks.csproj
COPY ./src/Plugin.Sample.Habitat/Plugin.Sample.Habitat.csproj ./src/Plugin.Sample.Habitat/Plugin.Sample.Habitat.csproj
COPY ./src/Plugin.Sample.Payments.Braintree/Plugin.Sample.Payments.Braintree.csproj ./src/Plugin.Sample.Payments.Braintree/Plugin.Sample.Payments.Braintree.csproj
COPY ./src/Sitecore.Commerce.Engine/Sitecore.Commerce.Engine.csproj ./src/Sitecore.Commerce.Engine/Sitecore.Commerce.Engine.csproj
RUN dotnet restore ./XCDocker.Sample.Solution.sln

COPY ./src ./src
RUN dotnet build ./XCDocker.Sample.Solution.sln -c Debug
RUN dotnet publish ./src/Sitecore.Commerce.Engine/Sitecore.Commerce.Engine.csproj -o /app/publish -c Debug

# Runtime Stage
FROM ${RUNTIME_IMAGE} as Runtime
WORKDIR C:/engine
COPY --from=Build /app/publish ./

USER ContainerUser
EXPOSE 5000

ENTRYPOINT ["C:\\LogMonitor\\LogMonitor.exe", "dotnet.exe", "Sitecore.Commerce.Engine.dll"]

마지막으로 Sitecore 엔진 이미지가 제공하는 표준 ENTRYPOINT을 사용합니다. 앞에서 언급한 바와 같이 이것은 우리가 실행할 때 이미지를 처음부터 굴리는 것을 피하는 주요한 장점 중 하나입니다.

Docker Compose 수정
현재 우리는 구축 이미지가 생겼습니다. 이 새 이미지를 사용하기 위해 docker compose를 업데이트해야 합니다.솔루션에 추가한 Docker Compose는 Sitecore에서 발표한 표준 xc1-cxa Compose 파일입니다.볼륨을 상대 볼륨으로 수정했지만 다른 변경 사항은 없습니다.
나는 이 파일을 가능한 한 Sitecore가 발표한 버전에 가깝게 하려고 한다. 그래서 이를 위해 나는 나의 변경 사항을 docker-compose.override.yml에 추가했다.이것은 docker-compose의 값을 덮어쓰는 데 사용됩니다.

version: "2.4"
services:

  engineBuild:
    container_name: xc-engine-custom
    image: xc-engine-custom:latest
    build:
      context: ./
      dockerfile: ./Docker/build/engine/Dockerfile
      args:
        BUILD_IMAGE: ${ENGINE_BUILD_IMAGE}
        RUNTIME_IMAGE: ${XC_SITECORE_DOCKER_REGISTRY}sitecore-xc-engine:${XC_PACKAGES_TAG}
    scale: 0

  engine-authoring:
    image: xc-engine-custom:latest
    depends_on:
      - engineBuild

  engine-shops:
    image: xc-engine-custom:latest
    depends_on:
      - engineBuild

  engine-minions:
    image: xc-engine-custom:latest
    depends_on:
      - engineBuild

  engine-ops:
    image: xc-engine-custom:latest
    depends_on:
      - engineBuild    

위의 파일을 보면 엔진 구축에 사용할 새로운 서비스를 먼저 소개한 것을 볼 수 있습니다.그리고 나는 기존의 4개의 엔진 서비스를 사용자 정의 이미지로 바꾸고 새로운 엔진 구축 서비스에 대한 의존을 도입했다.
현재 이 설정이 완료되었습니다. 새로운 그림을 만들기 위해 docker-compose build을 실행할 수 있습니다.구축이 완료되면 다음에 이 토폴로지를 시작할 때 Sitecore의 표준 이미지가 아닌 새 엔진 이미지를 사용합니다.

결론
docker 용기에서customer Sitecore 비즈니스 엔진을 실행하는 것이 얼마나 쉬운지 보여 주기를 바랍니다.만약 당신이 이 모든 것을 보고 싶다면, 당신은 이 GitHub Repository에서 볼 수 있습니다.
나는 일부러 이 예를 가능한 한 간단하게 했다. 단지 기존의 Customer.Sample.Solution을 도커 용기에 포장했을 뿐이다.저는 Helix 매뉴얼에 따라 해결 방안을 편집하지 않았고exist with XM과 같은 핫 코드 리셋을 처리한 적이 없습니다. 하지만 이것은 사람들이 Docker에서Sitecore를 사용하여 비즈니스를 체험하기 시작할 수 있기를 바랍니다!