spryker base
1.0.0
중요한 참고 :이 프로젝트는 더 이상 사용되지 않습니다! 보다 일반적인 PHP 사용 사례를 위해 claranet/spryker-demoshop 부트 스트랩 참조 또는 claranet/php 학부모 이미지로 사용하십시오! 우리는 더 이상이 프로젝트를 유지하지 않습니다.
이 이미지는 Yves와 Zed의 기본 인프라를 제공하는 목적으로 사용됩니다. 빌드/초기 스크립트 및 상점 자체 주변의 추가 툴링 측면에서 인프라. 이 이미지는 사용할 준비가되어 있지 않습니다! 여기에 구현 된 기능을 사용하려면 Spryker 상점의 실제 구현을 따라이 기본 이미지를 사용하여 상속받은 자체 Dockerfile 작성하십시오.
이 프로젝트는 여전히 베타 버전에 있으며 가능한 중단 변경을 겪을 것입니다!
그래서 우리는 당신에게서 피드백을 받고 싶어합니다! 이것은 Spryker 상점을 가능한 한 쉽게 만들기 위해 노력하는 진행중인 노력입니다. 이 목표를 성공적으로 달성하려면 일반화 하고이 기본 이미지에 넣을 가치가있는 일반적인 단계를 식별해야합니다. 그러니 당신의 필요와 경험에 대해 알려주십시오.
이 이미지를 실제로 보려면 컨테이너화 된 Spryker Demoshop을 확인하십시오. 이 Demoshop은 기본 이미지에 대한 참조 구현 역할을합니다. Spryker와 마찬가지로 Bundles를 진행하고 Demoshop이 우리가 Demoshop을 사용하는 변경 사항을 정확히 같은 방식으로 반영하는 Demoshop을 만들고 있습니다.
핵심 특성은 다음과 같습니다.
ONBUILD 트리거 기능을 사용하여 자식 이미지 빌드 프로세스에 연결하고 제어합니다.컨테이너화의 이점 :
첫 번째 전제는 우리가 하나의 이미지에서 Yves와 Zed 컨테이너를 제공하기로 결정했다는 것입니다. 이점은 항상 전체 클러스터에서 공유 코드베이스를 지속적으로 업그레이드하는 것입니다. 두 구성 요소의 요구 사항이 포함되어야하므로 트레이드 오프는 약간 더 큰 이미지입니다.
또 다른 전제는 -이 스택에 대한 이해에 중요하다는 것입니다. 개발 및 생산 환경에서 통합 된 이미지 하나를 구축하는 것이 중요합니다. 이는 Spryker 앱 자체에 의해 평가되는 APPLICATION_ENV 의 사용에 영향을 미칩니다.
이 변수는 다음과 같은 영향을 미칩니다.
로컬 구성 파일 및 외부 리소스의 위치는 컨테이너화 된 환경에서 추가로 고려해야 할 것이 아닙니다. 모든 스택은 어쨌든 분리되기 때문입니다. 따라서 ./config/Shared/ 의 구성 명령문 APPLICATION_ENV 없음을 확인하십시오.
우리는 구별할만한 가치가있는 지점 1.1 만 고려합니다. 그리고 이것은 효과적인 컨테이너에 적절한 VAR을 주입하여 달성 될 수 있으므로 이미지를 구축하는 동안 환경을 구별하지 않습니다. 지점 1.1은 일반적으로 더 많은 종속성을 해결해야하므로 APPLICATION_ENV development 에 설정된 상태에서 항상 이미지를 빌드합니다. 그러나 응용 프로그램이 실제로 실행되는 모드는 빌드와 독립적입니다.
이는 생산 컨테이너조차도 DEV 의존성이 포함되어 있음을 의미합니다. 이에 대한 주요 이유는 컨테이너가 모든 단계와 모든 환경에서 정확히 동일하게 작동하도록하기 위해 Dev/Test/Prod Parity의 요구 사항 때문입니다. 이 전제를위한 트레이드 오프는 다시 더 큰 효과적인 이미지입니다. 런타임 동안 Spryker 응용 프로그램의 동작은 development 또는 production 수용하는 APPLICATION_ENV 설정하여 제어 할 수 있습니다. ./docker/run 스크립트를 사용하면이 변수가 자동으로 설정됩니다.
이 ./shop/docker subfolder에 제공된 스크립트의 아이디어는 devel 과 prod 환경의 기본 구별을 따릅니다. docker-compose 측면에서 해당 환경의 주요 차이점은 개발자가 컨테이너 내의 백그라운드에서 코드를 실행하면서 외부에서 코드 기반을 편집 할 수있는 Devel 모드에서 바인드 마운트를 고용하는 것입니다.
이 설정은 수동 노력을 줄이기 위해 노력하기 때문에 필요한 논리를 렌더링하고 이미지 구축 또는 컨테이너 설정을 생성하거나 찢어내는 것과 같은 가장 일반적인 작업을 위해 필요한 논리를 렌더링하고 단축키로 지원하는 쉘 스크립트를 준비했습니다. ./docker/run help 확인하십시오
prod 환경은 가까운 환경에서 작업 결과를 테스트하기위한 것이므로 로컬 리포지토리와 컨테이너 사이에 공유 데이터가 설정되지 않습니다. 또한 응용 프로그램은 개발 특정 확장을 비활성화하는 APPLICTION_ENV=production 세트와 함께 실행됩니다.
이 기본 이미지에 의해 소개 된 개념은 결과 상점 이미지를 3 개의 별개의 레이어로 나누는 것입니다 ( Dockerfile 의 각 명령문은 새로운 레이어를 초래하기 때문에 3 개 이상의 레이어가 있습니다. 그러나 3 개의 별개의 레이어에 대한 아이디어는 Onbuild Trigger Logic을보다 쉽고 이해할 수 있기 때문입니다). 여기에는 몇 가지 이유가 있습니다.
먼저, Docker 캐시를 활용하고 상점 이미지의 반복적 인 재건 속도를 높여야합니다. 이 레이어는 일반에서 구체적으로 주문되므로 실제 상점 구현의 코드 기반에서 반복적으로 작업하면서 전체 스택의 재건축이 필요합니다.
둘째, 이미지를 당기면서 다른 층을 병렬로 검색 할 수 있으며, 이는 지역 개발뿐만 아니라 생산 설정의 배포와 관련된 컨테이너 생성 시간의 속도를 높입니다. 또한, 일반 레이어는 종종이를 바꾸지 않기 때문에 재건에 대한 필요성뿐만 아니라 전체 이미지를 다시 설정해야합니다.
불행히도 이것은 비용이 들지 않으며, 유효 이미지 크기는 하나의 레이어만으로 구성되는 것보다 약간 높습니다. 지금은 이것이 허용되는 트레이드 오프 인 것 같습니다.
해당 레이어의 책임은 무엇이며 어디에 위치하고 있으며 언제 건축 될 예정입니까?
claranet/spryker-base (이 이미지) :claranet/spryker-demoshop (다운 스트림 상점 이미지, 예 : Demoshop) :spryker-base 이미지에서베이스 레이어를 재정의합니다 ( $REBUILD_BASE_LAYER 빌드 변수) PHP 또는 노드 종속성을 개인 저장소에서 가져와야하는 경우 ~/.netrc 제공하면됩니다. 이 파일은 적절한 저장소를 클로닝하는 데 사용하는 Docker Build Arg에 주입 된 Docker Build Arg가 자동으로 감지되고 일시적으로 일시적으로 발생하며, 그 후에 레이어가 닫히기 직전에 Resuilting 레이어를 닦아 냈습니다.
$HOME/.netrc 의 형식은 다음과 같습니다.
machine git.company.local
login my_user_name
password my_private_token
적용하려면 모든 주어진 종속성은 http url로 주어 지거나 git config --global "url.https://".insteadof "git://git@ 통해 이미 전환되어야합니다.
보다 구체적인 규칙을 추가하려면 종속성 해상도 프로세스 전에 실행되는 종속성 계층에서 빌드 스크립트를 작성하십시오.
vi docker/build.d/deps/300_private_repo_override.sh
#!/bin/sh
sectionText "Diverting git transport from SSH to HTTPS: https://git.company.local"
git config --global "url.https://git.company.local/".insteadof "[email protected]:"
git config --global "url.https://git.company.local".insteadof "ssh://[email protected]"
git URL은 임의의 조합으로 제공 될 수 있으므로 이것은 어떤 상황에서는 필요합니다.
Docker는 빌드 시간 볼륨을 구현하지 않기 때문에이 프로세스가 더 쉬워지기 때문에이 모든 것이 필요합니다. 그러나 Dockerfile 건축의 유일한 소스가 아니기 때문에 그러한 기능이 재현성이 위험 할 수 있기 때문에 실제로 놀라운 이유를 얻었습니다. 그것은 어떤 기술 논쟁과 마찬가지로 - 절대적인 진실도없고, 트레이드 오프 만.
환경에서 외부 서비스는 환경에 따라 다른 주소에서 도달 할 수 있으므로 코드가 실행중인 환경에 따라 도달 할 수 있습니다. 조정하려면 일부 구성이 필요합니다. 따라서 사이트 로컬 구성 파일 config/Shared/config_local.php 통해 구성을 주입하기 위해 Spryker 기본 구성 파일 우선 메커니즘을 사용합니다. 이 파일은 다른 모든 파일을 무시하는 파일이므로.
구성 순서는 다음과 같습니다.
config_default.php 기본 구성config_default-development.php 개발 모드와 관련된 구성 ( APPLICATION_ENV 참조)config_local.php 사이트 로컬 구성; 이 경우 컨테이너화 된 환경에 대한 구성입니다.이 순서를 사용하면 상점이 실행할 효과적인 환경과 독립적으로 구성 파일을 사용할 수 있습니다. 환경 간의 다른 동작조차 제어 할 수도 있습니다. 우리는 단지 SO Say Site Local 설정을 상체합니다.이 아이디어는 시작됩니다.
이를 위해 .gitignore 목록에서 config/Shared/config_local.php 제거해야했습니다.
현재 두 환경 모두 일시적인 환경의 가정에 기인 한 이름없는 볼륨을 사용하여 devel 하고 prod . 즉, 전체 스택이 코드 기반을 확인할 목적으로 유일한 목적으로 생성됩니다. 그것은 일부 생산 등급 설정과 같은 상황에서는 컨테이너의 레크리에이션을 통해 데이터가 지속되어야합니다 !!!
가정 된 워크 플로는 다음과 같이 설명 할 수 있습니다.
여기에 구현 된 기능을 재사용하려면 다음 측면을 기본 이미지와 정렬해야합니다.
./src/Pyz 상점 구현./config 구성./public/{Yves,Zed} - enterctoints to you 응용 프로그램 (문서 루트)composer.json 및 composer.lockpackages.json , packages.lock 및 yarn.lock./docker/build.conf 를 통해./docker/build.d/ 아래에 사용자 정의 빌드 스크립트를 배치하여 이미지의 빌드 프로세스를 제어하십시오../docker/init.d/ 아래에 스크립트를 배치하여 설정의 초기화 프로세스를 제어하십시오.이 이미지를 여기에서 사용하기 위해 준비한 Demoshop을 확인하십시오. 이것은 당신이 가질 수있는 모든 질문에 대답해야합니다.
참조 구현은 우리가 유지 관리하는 데모 콥이기 때문에 이것은 꽤 좋은 스타터입니다. 이 저장소를 포킹하여 또는 처음부터 시작하여.
처음부터 시작하려면 Demoshop에서 필요한 유일한 유물은 다음과 같습니다.
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.php이를 통해 코드로 저장소를 채우고 개별 요구 사항에 맞게 사용자 정의 할 준비가되었습니다.
이것만큼 깨끗하게 보이는 Dockerfile 염두에 두십시오.
FROM claranet/spryker-base:latest
이것은 재사용 성 같은 냄새가납니다. :)
Shop Skeleton과 Demoshop과 Demoshop은 ./docker/run 아래에 쉘 스크립트를 얻었으며 가장 일반적인 작업에 대한 바로 가기를 제공합니다. 자세한 내용은 readme.md를 확인하십시오.
# Build the image
./docker/run build
# Run the demoshop in development mode
./docker/run devel up
# Stop all the containers of the demoshop including their artifacts
./docker/run devel down -v
이러한 변수는 컨테이너 생성 중에 환경 변수로 제공됩니다.
config/Shared/config_local.php 파일에 의해 소비되는 대부분의 변수 :
APPLICATION_ENV="production"SPRYKER_SHOP_CC="DE"ZED_HOST="zed"YVES_HOST="yves"ES_HOST="elasticsearch"ES_PROTOCOL="http"ES_PORT="9200"REDIS_STORAGE_PROTOCOL="tcp"REDIS_STORAGE_HOST="redis"REDIS_STORAGE_PORT="6379"REDIS_STORAGE_PASSWORD=""REDIS_SESSION_PROTOCOL="tcp"REDIS_SESSION_HOST="redis"REDIS_SESSION_PORT="6379"REDIS_SESSION_PASSWORD=""ZED_DB_USERNAME="postgres"ZED_DB_PASSWORD=""ZED_DB_DATABASE="spryker"ZED_DB_HOST="database"ZED_DB_PORT="5432"JENKINS_URL="http://jenkins:8080/"RABBITMQ_HOST="rabbitmq"RABBITMQ_PORT="5672"RABBITMQ_USER="spryker"RABBITMQ_PASSWORD=""YVES_SSL_ENABLED="false"YVES_COMPLETE_SSL_ENABLED="false"ZED_SSL_ENABLED="false"ZED_API_SSL_ENABLED="false"초기화 후크에 의해 소비 :
ZED_ADMIN_PASSWORD [email protected]의 기본 비밀번호를 설정하면 사용자가 재설정됩니다.ENABLE_XDEBUG PHP 모듈 xdebug 활성화되고 구성됩니다.ENABLE_OPCACHE PHP 모듈 opcache 활성화되고 구성됩니다. 이러한 변수는 프로젝트 별 ./docker/build.conf 를 통해 제공됩니다.
PROJECT (필수) docker-compose 생성 된 서비스의 이름 접두사를 제어합니다.IMAGE (필수) - 결과 도커 이미지의 이름은 무엇입니까?VERSION (필수) - 우리는 어떤 버전의 Docker Image에서 작업하고 있습니까?BUILD_DEPENDENCIES 배포 (데비안) 패키지가 빌드 시간 동안 설치할 패키지BASE_DEPENDENCIES 배포 (데비안) 패키지를 추가로 설치할 수 있습니다PHP_EXTENSIONS 설치할 PHP 확장 목록 공간 분리 된 목록NPM_DEPENDENCIES DEPS 레이어에서 NPM 처리 전에 강화 될 배포 패키지KEEP_DEVEL_TOOLS (기본값 : false) - 개발 도구를 설치하고 빌드 너머로 유지해야합니까?SKIP_CLEANUP (default : false) - 각 레이어 빌드 스테이지에서 청소 단계를 건너 뛰십시오. 이는 문제를 디버깅하는 데 도움이됩니다. 자격 증명도 닦아내는 것을 건너 뜁니다! 그러니 그런 이미지를 야생으로 풀지 마십시오 !!!CRONJOB_HANDLER Cronjobs를 등록 해야하는 위치를 정의합니다. 현재 Jenkins와 Crond가 지원됩니다.REBUILD_BASE_LAYER 이 빌드 var가 제공되면 다운 스트림 상점 이미지 빌드 중에 기본 레이어가 재건됩니다. nginx, php-fpm 또는 php의 동작을 제어하기 위해 컨테이너 외부에서 바인드 마운트로 구성 또는 하위 상점 이미지의 Dockerfile 통해 구성을 주입 할 수 있습니다.
서비스 구성은 효과적인 구성을 구성하는 여러 파일을 포함 할 준비가되어 있습니다.
모든 관련 파일이있는 특정 디렉토리에서 모든 구성이 예상되도록 준비됩니다.
예상 위치는 다음과 같습니다.
/etc/nginx/spryker/yves.conf.d/*.conf/etc/nginx/spryker/zed.conf.d/*.conf/etc/php/fpm/yves.conf.d/*.conf/etc/php/fpm/zed.conf.d/*.conf/etc/php/ini/*.ini .기본 구성은 다음과 같습니다.
/etc/php/fpm/zed.conf.d/100_base.conf
/etc/php/fpm/zed.conf.d/200_pm.conf
/etc/php/fpm/zed.conf.d/300_php.conf
/etc/php/fpm/yves.conf.d/100_base.conf
/etc/php/fpm/yves.conf.d/200_pm.conf
/etc/php/fpm/yves.conf.d/300_php.conf
/etc/php/ini/xdebug.ini
/etc/php/ini/opcache.ini
/etc/nginx/spryker/zed.conf.d/500-default.conf
/etc/nginx/spryker/yves.conf.d/500_default.conf
완전한 디렉토리를 컨테이너에만 장착 할 수있는 환경에서는 /mnt/configs 에서 디렉토리 계층을 기대하는 메커니즘을 준비했으며 컨테이너 생성에서는이 위치의 모든 파일을 /etc/ 의 해당 위치로 상징합니다.
# For example:
/mnt/configs/nginx/zed.conf.d/600-custom-headers.conf --> /etc/nginx/zed.conf.d/600-custom-headers.conf
/mnt/configs/php/fpm/yves.conf.d/500-raise-processes.conf --> /etc/php/fpm/yves.conf.d/500-raise-processes.conf
계층화 된 파일 시스템의 특성으로 인해이 기본 이미지에서 상속되는 하위 이미지는 해당 서비스의 원하는 동작을 달성하기 위해 단순한 구성을 구성 할 수 있습니다.
Dockerfile 을 통해 구성 파일을 직접 공급하여 쉽게 사용자 지정할 수 있습니다.
FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf
Onbuild 트리거가 실행되는 Child Dockerfile 의 첫 번째 지시문이 되므로이 재정의 파일은 컨테이너 런타임 중에 먼저 사용할 수 있습니다.
기본 이미지에서 내린 대부분의 설계 결정은 사용자 정의 성과 확장 성 아이디어에 의해 관리됩니다. 개별 상점 이미지에 한 번만 사용할 수있는 기본 이미지는 쓸모가 없으며 기본이라는 것과 멀리 떨어져 있습니다.
빌드 프로세스는 이름이 나중에 런타임 동안 모든 파생 된 컨테이너가 공유하는 이미지를 생성하는 프로세스를 제안하는 것과 거의 같습니다.
일부 빌드 스크립트는 ./docker/build.conf 로 설정할 수있는 매개 변수를 고려합니다.
위의 참조를 참조하십시오 ..
후크 디르 : ./docker/build.d/
기본 이미지에서 상속 된 빌드 단계를 확장하거나 비활성화하려면 ./docker/build.d/ 아래에 사용자 정의 빌드 스크립트를 배치해야합니다. 거기에 각 단계/레이어를 반영하는 3 개의 디렉토리가 있습니다.
./docker/build.d/base/ 기본 OS 레벨 설치./docker/build.d/deps/ 상점 특정 PHP/노드 종속성을 다루십시오./docker/build.d/shop/ 실제 상점 코드 기반의 코드 생성과 관련각 서브 디르의 스크립트는 어휘 주문을 실행합니다 (Actuall 소스).
예를 들어, 기본 이미지에 의해 탐색 캐시가 구축되는 방식을 변경하려면 ./docker/build.d/shop/650_build_navigation_cache.sh 의 기본 이미지에서 제공하는 동일한 위치에 스크립트를 제공해야합니다. 결과 이미지와 컨테이너는 Union 파일 시스템을 사용하기 때문에 Shop 이미지에서 제공하는 파일은 BAS 이미지에서 제공 한 파일보다 우선합니다. 이 메커니즘을 통해 아무것도하지 않는 스크립트를 제공하거나 다른 또는 추가로 수행하는 스크립트를 추가하여 동작을 변경할 수있는 스크립트를 제공하여 기능을 비활성화 할 수 있습니다.
위에서 설명한 동일한 메커니즘은 Spryker 컨테이너의 초기화를 변경하고 전체 설정이 실행되는 방식을 변경하기 위해 사용될 수 있습니다. 기본 이미지에는 일반적인 환경에 유효한 의미있는 기본값이 제공되지만 적절한 위치에 사용자 정의 스크립트를 배치하여 무시할 수 있습니다.
기본 이미지는 각 컨테이너의 초기화 및 전체 설정 초기화를위한 후크를 제공합니다.
후크 디르 : ./docker/entry.d/
런타임 EntryPoint 인수 ( run-yves , run-zed , run-yves-and-zed , run-cron )는이 실제 컨테이너가 어떤 역할을하는지,이 후크 디렉토리에 나열된 모든 파일을 소스합니다. 변수를 통해 스크립트는 런타임 중에 활성화하고 시작할 서비스를 결정합니다.
일반적인 작업은 컨테이너 생성에 대한 ENV var var ENABLE_XDEBUG 통해 요청 된 xdebug 활성화하는 것입니다.
특성으로 인해 각 컨테이너 시작에서 모든 후크가 실행됩니다.
후크 디르 : ./docker/init.d/
일반적으로 각 상점 인스턴스는 이러한 상점을 초기화하기 위해 초기 단계를 수행해야합니다. 이 설정 중에 광범위한 초기화 훅 디스크 아래의 모든 쉘 스크립트가 실행되고 있습니다. 예를 들어 Demoshop과 같은 더미 데이터로 데이터베이스를 초기화하려면 ./docker/init.d/500_import_demo_data.sh 아래에 스크립트를 배치합니다.
이것은 암시 적으로 수행되지 않으며, 별도의 컨테이너는 EntryPoint arg init 와 함께 스폰되어야합니다.
후크 디르 : ./docker/deploy.d/
시작 절차는 배포 절차입니다. 이 절차는 배포 중에 수행됩니다. 수명주기 개념은 이러한 2 개의 후크로 구성됩니다. Init는 처음으로 호출되며 새 버전의 이미지가 수행 될 때마다 배포됩니다.
이것은 암시 적으로 수행되지 않으며, 별도의 컨테이너는 EntryPoint Arg가 deploy 상태에서 스폰되어야합니다.
이미 언급했듯이 매우 맞춤형 빌드 및 이니스 단계를 자유롭게 추가 할 수 있습니다. ./docker/common.inc.sh 스크립트는 몇 가지 유용한 기능을 도와줍니다. 직접 확인하십시오.
준비된 출력 기능을 사용하여 빌드 단계를 알려줍니다.
errorText 오류를 높이십시오successText 성공을 다시 보냅니다sectionHead - 작업 그룹의 헤드 라인을 인쇄하십시오sectionText 인쇄 중간 빌드 단계 정보 포함 된 모든 빌드 단계에 대한 install_packages 기능을 제공합니다. 당신이 그것을 사용하고 있는지 확인하십시오! 패키지를 "빌드"종속성으로 플래그 할 수있는 가능성이 있습니다. 레이어 빌드가 마감되면 빌드 의존성으로 표시된 패키지가 제거됩니다. 빌드 의존성으로 패키지를 플래그하는 경우 방금 설정 --build 첫 번째 인수로 건축됩니다.
# remove "gcc" at the end of our image build
install_packages --build gcc
# keep "top" in the resulting image
install_packages top
우리는 여전히이 프로젝트의 초기 단계에 있으므로 문서가 불완전 할 수 있습니다. 우리가 제공하는 기능에 대해 자세히 알아 보려면 쉘 라이브러리를 살펴보십시오.
YVES/ZED 인스턴스에서 /data/logs/ 내에서 nginx, php-fpm 및 응용 프로그램 로그를 찾을 수 있습니다.
우리는 공식 PHP 이미지에 따라 다릅니다 : https://hub.docker.com/_/php/
참으로 아주 좋은 질문!
우리는 소스 빌드 및 패키지 설치가 더 짧기 때문에 Alpine으로 가기로 결정했습니다. 그것은 무거운 리프팅 프로젝트조차도 알파인에서 호스팅 될 수 있음을 보여주는 개념 증명이었다. 예상되는 이점은 이미지 크기를 줄이고 더 빠른 빌드 시간뿐만 아니라 더 빠른 실행 시간입니다.
불행히도 Musl Lib C는 고객 상황에서 견딜 수없는 한계를 도입하는 것으로 나타났습니다. 여기서 다양성은 핵심입니다. 0.9.6 이후 우리는 데비안 기반 이미지로 전환했습니다.
두 가지가 떠 오릅니다.
곧 더 많이 올 것입니다. :)
/문제를 살펴보십시오.
