spryker demoshop
1.0.0
docker-compose 의 인터페이스요구 사항 : Linux 또는 MacOS 시스템에서 최근의 안정적인 Docker 및 Docker-Compose (Docker-Compose.yml 3.4 지원).
이 스택은 완전히 비행 된 ES를 포함하여 상당히 복잡하기 때문에 최소 4GB의 메모리가 필요합니다. Windows/MacOS에서 Docker를 실행중인 경우 그에 따라 설정을 조정하십시오.
필수 조건이 충족되면 상점을 운영하는 것은 매우 쉽습니다. 이 단계를 입력하기 만하면됩니다.
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
이렇게하면 Docker 이미지를 당기고, 네트워크를 생성하고, 모든 컨테이너를 생성하고, 로컬 코드를 컨테이너에 바인딩하여 외부에서 라이브 편집하고 컨테이너를 서로 연결하고 공공 서비스를 노출시킵니다. Yves, Zed, Jenkins-Master, Postgresql 및 Elasticsearch와 마찬가지로.
Spryker 스택이 생성되는 동안 인내심을 가지십시오. 초기화 루틴은 모든 데이터가 데이터베이스로 가져온 다음 Redis 및 Elasticsearch로 내보내는 데 꽤 시간이 걸리므로 인내심을 갖도록하십시오. 현재 약 10 분이 걸립니다.
초기화가 완료되면 브라우저를 다음 URL에 가리킬 수 있습니다.
이것은 Spryker Demoshop의 공식 참조 구현의 dockerized 버전입니다. 필요한 모든 종속성을 자동으로 끌어 당기고 PostgreSQL, Redis, Elasticsearch 및 Jenkins로 구성된 스택을 만들어 박스를 실행할 준비가되었습니다. 런타임 동안 각 서비스는 초기화됩니다.
이 저장소를 Spryker Commerce OS를 기반으로하는 패러다임 상점의 데모 또는 Demoshop의 포크로 시작하는 자신의 구현 개발을위한 시작점으로 사용할 수 있습니다.
추가 툴링과 함께 빌드 및 시작 절차는 Claranet/PHP 이미지에서 상속됩니다. 거기 에서이 dockerization의 기술 디자인 아이디어와 다음과 같은 추가 요점에 대한 답변을 찾을 수 있습니다.
docker/ 파일 시스템 구조컨테이너화의 이점 :
Docker-Compose Stack에 의해 여러 서비스가 노출되고 있습니다. 스택을 병렬로 실행하고 포트 충돌을 방지하려면 포트 할당을 정렬해야합니다.
따라서 다음 체계가 구현되었습니다. 포트 번호는 다음과 같이 인코딩됩니다. ECCDD
따라서 Yves de는 http : // localhost : 20100/및 http : // localhost : 20102를 통해 연락 할 수 있습니다.
통지 : 항만 별 상점/도메인의 차별화는 로컬 개발 환경에만 적용됩니다. Claranet이 제공하는 실제 생산 등급 스택은 실제 도메인 이름을 기반 으로이 차이를 수행하고 있습니다.
중심 전제는 -이 스택에 대한 이해에 중요합니다. 개발 및 생산 환경에서 통합 된 이미지 하나를 구축하는 것이 중요합니다. 이는 Spryker 앱 자체에 의해 평가되는 APPLICATION_ENV 의 사용에 영향을 미칩니다.
이 변수는 다음과 같은 영향을 미칩니다.
로컬 구성 파일 및 외부 리소스의 위치는 컨테이너화 된 환경에서 추가로 고려해야 할 것이 아닙니다. 모든 스택은 어쨌든 분리되기 때문입니다. 따라서 ./config/Shared/ 의 구성 명령문 APPLICATION_ENV 없음을 확인하십시오.
우리는 구별할만한 가치가있는 지점 1.1 만 고려합니다. 그리고 이것은 효과적인 컨테이너에 적절한 VAR을 주입하여 달성 될 수 있으므로 이미지를 구축하는 동안 환경을 구별하지 않습니다. 지점 1.1은 일반적으로 더 많은 종속성을 해결해야하므로 APPLICATION_ENV development 에 설정된 상태에서 항상 이미지를 빌드합니다. 그러나 응용 프로그램이 실제로 실행되는 모드는 그와 독립적입니다.
이는 생산 컨테이너조차도 개발 의존성을 포함한다는 것을 의미합니다. 이에 대한 주요 이유는 컨테이너가 모든 단계와 모든 환경에서 정확히 동일하게 작동하도록하기 위해 Dev/Test/Prod Parity의 요구 사항 때문입니다. 이 전제를위한 트레이드 오프는 다시 더 큰 효과적인 이미지입니다.
런타임 동안 Spryker 응용 프로그램의 동작은 development 또는 production 수용하는 APPLICATION_ENV 설정하여 제어 할 수 있습니다. ./docker/run 스크립트를 사용하면이 변수가 자동으로 설정됩니다.
./docker/run 통해 제공된 래퍼 스크립트의 아이디어는 devel 과 prod 환경의 기본 차이입니다. docker-compose 측면에서 해당 환경의 주요 차이점은 개발자가 컨테이너 내의 백그라운드에서 코드를 실행하면서 외부에서 코드 기반을 편집 할 수있는 Devel 모드에서 바인드 마운트를 고용하는 것입니다.
이 설정은 수동 노력을 줄이기 위해 노력하기 때문에 필요한 논리를 렌더링하고 이미지 구축 또는 컨테이너 설정을 생성하거나 찢어내는 것과 같은 가장 일반적인 작업을 위해 필요한 논리를 렌더링하고 단축키로 지원하는 쉘 스크립트를 준비했습니다. ./docker/run help 확인하십시오
prod 환경은 가까운 환경에서 작업 결과를 테스트하기위한 것이므로 로컬 리포지토리와 컨테이너 사이에 공유 데이터가 설정되지 않습니다. 또한 응용 프로그램은 개발 특정 확장을 비활성화하는 APPLICTION_ENV=production 세트와 함께 실행됩니다.
대형 환경에서 외부 서비스는 코드가 실행되는 환경에 따라 다른 주소에서 도달 할 수 있으므로 환경 변수를 통해 컨테이너/이미지를 외부에서 구성 할 수 있어야합니다. Spryker 앱에서 소비해야합니다. 따라서이 이미지는 docker env vars로 주입 된 특정 환경 변수를 기대하고 있으며 준비된 config_local.php 를 통해 콘서트가 진행되고 있습니다.
우리는 순서, 우선 순위 및 구성 파일로 간주 될 계획을 정의하는 구성 파일 계층의 Spryker 기본 메커니즘을 활용하고 있습니다. 이 이미지는이 저장소에서 docker/config_local.php 에서 찾을 수 있고 config/Shared/config_local.php 에서 결과 Docker 이미지에서 찾을 수있는 자체 사이트 로컬 구성 파일을 제공합니다. 이 파일은 다른 모든 파일을 무시하는 파일이므로.
구성 순서는 다음과 같습니다 (마지막 오버 사이드 Prio Ones) :
config_default.php 기본 구성config_default-development.php 개발 모드와 관련된 구성 ( APPLICATION_ENV 참조)config_local.php 사이트 로컬 구성; 이 경우 컨테이너화 된 환경에 대한 구성입니다.이 순서를 사용하면 상점이 실행할 효과적인 환경과 독립적으로 구성 파일을 사용할 수 있습니다. 환경 간의 다른 동작조차 제어 할 수도 있습니다. 우리는 단지 SO Say Site Local 설정을 상체합니다.이 아이디어는 시작됩니다.
현재 두 환경 모두 일시적인 환경의 가정에 기인 한 이름없는 볼륨을 사용하여 devel 하고 prod . 즉, 전체 스택이 코드 기반을 확인할 목적으로만 생성됩니다. 그것은 일부 생산 등급 설정과 같은 상황에서는 컨테이너의 레크리에이션을 통해 데이터가 지속되어야합니다 !!!
가정 된 워크 플로는 다음과 같이 설명 할 수 있습니다.
docker-compose(1) 쉘 스크립트 ./docker/run 을 통해 포장되었습니다. 이 스크립트는 대부분의 일반적인 작업에 대한 바로 가기를 제공하면서 로컬 리포지토리 및 구성에주의를 기울입니다.
Docker 이미지 사용을 구축하려면 : ./docker/run build
둘 다 동일한 이미지를 기반으로하므로 두 환경 모두에 적용됩니다. Spryker-Demoshop 이미지의 주요 Jenkins-Slave 풍미뿐만 아니라 주요 Spryker-Demoshop 이미지를 구축합니다.
실제로 2 개의 이미지가 제작되고 있으며, 이는 YVE와 ZED 층 모두에서 NGINX 및 PHP 컨테이너에 사용되는 실제 상점 이미지 및 Jenkins 슬레이브 컨테이너에 사용됩니다. 후자는 Jenkins Slave/Worker를 만들기 위해 필요한 모든 Jenkins 구성 요소에 의해서만 상점 이미지를 확장합니다. 실제 상점 이미지 에서이 작업을 수행하는 이유는 Jenkins를 통해 실행되는 모든 백엔드 작업에 전체 Spryker 코드 기반이 필요하기 때문입니다.
SSD가 내장 된 일반 워크 스테이션의 빌드 시간은 현재 두 이미지 모두에 대해 10 분이 걸립니다.
Demoshop을 기반으로 자신의 작업을 시작하려면 지역 개발 환경이 흥미로울 수 있습니다. 이 설정을 통해 로컬 코드 기반을 실행중인 컨테이너에 장착하고 코드 기반의 변경 사항이 즉시 적용됩니다.
그냥 실행 ./docker/run devel up 거기에 간다.
할당되지 않은 모든 이름을 포함하여 Devel 스택을 파괴하십시오 ./docker/run devel down -v
다음 경로는 컨테이너에 바인딩됩니다.
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
상점 이미지를 재건하고 모든 데이터 컨테이너 (Redis, ES, PSQL)를 실행하는 동안 Yves 및/또는 Zed 컨테이너를 재현 해야하는 경우 : ./docker/run devel rebuild
컨테이너를 재건하지 않고 해당 컨테이너를 재현하고 싶다면 : ./docker/run devel recreate
디버깅하는 동안 /entrypoint.sh 컨테이너를 초기화 하여이 단계를 건너 뛰고 직접 확인하는 대신 유용 할 수 있습니다. 컨테이너 to command: sleep 1w : docker-compose-devel.yml 의 command: run-zed 지시문을 변경 하여이 작업을 수행 할 수 있습니다 ./docker/run devel recreate zed .
docker-compose 의 인터페이스 이 모든 것이 docker-compose(1) 예를 들어 Shell을 통해 컨테이너에 들어가려면 직접 호출해야 할 수도 있습니다. ./docker/run devel compose exec yves bash
빌드의 출력이 그 말을하지 않고 더 깊은 디버그 세션이 필요한 경우 죽은 중간 빌드 컨테이너를 부활시키기 위해 다음 단계를 고려하십시오.
./docker/run build
# assumed that the last created container is the failed intermediate build container
docker commit $(docker ps -lq) debug
docker run --rm --it debug /bin/sh
그리고 여기에서 당신은 빌드 고장의 원인을 조사합니다.
우리는 Spryker 설치 프로그램의 사용을 도입했습니다. 이 버전 전에는 기본 및 Spryker 이미지에있는 쉘 스크립트에서 전체 Sprykwer 빌드, 설치 및 프로비저닝 프로세스를 렌더링했습니다. 이는 애플리케이션과 인프라 간의 계약에 지나지 않는 새로운 Spryker 설치 프로그램에 유리하게 떨어졌습니다. 이 계약은 상점을 건설하기 위해 필요한 모든 조치를 명시 적으로 휘젓습니다. config/installer/claranet.yml 통해 설치 루틴 계약을 준비했습니다.
우리는 데비안 스트레치에 찬성하여 알파인 지원을 떨어 뜨 렸습니다! Alpine이 필요한 경우 2.28.0 이전 버전을 사용하십시오. 그러나 더 이상 Alpine을 지원하지 않습니다.
또한 참고 : claranet/spryker-base 에서 claranet/php 로 전환 한 부모 이미지는 이전 docker/ FileSystem 구조를 깨뜨립니다! 이전 기본 이미지가 Spryker 요구 사항뿐만 아니라 PHP 기반 애플리케이션 요구 사항과 일치하도록 더욱 일반화 될 수 있기 때문에이 경로를 선택했습니다.
여기에 나열되지 않은 버그를 찾으면보고하십시오!
우리는 https://bugs.php.net/bug.php?id=76029가 수정 될 때까지 Demoshop을 배송하지 않으며 Opcache를 활성화 할 수 있습니다. Opcache는 Prod 환경에서 필수적이며 DEV에서 7.2를 사용하고 생산에서 7.1을 사용하는 것은 의미가 없습니다.
Spryker Demoshop 2.32 이후, Opcache가 예외를 던지는 버그가있는 것 같습니다. 그래서 우리는 opcache를 비활성화해야했습니다.
