spryker base
1.0.0
重要な注意：このプロジェクトは非推奨です！より一般的なPHPユースケースのためにclaranet/php claranet/spryker-demoshopブートストラップリファレンスとして使用してください。もうこのプロジェクトを維持していません。
この画像は、YVEとZedにベースインフラストラクチャを提供する目的に役立ちます。ビルド/INITスクリプトと、ショップ自体の周りのさらなるツールの観点からインフラストラクチャ。この画像は、すぐに使用できるショップを提供しません！ここで実装されている機能を使用するために、Sprykerショップの実際の実装に沿って、このベース画像を使用して継承する独自のDockerfile書きます。
このプロジェクトはまだベータ版であり、可能性のある壊れた変更を受けます！
だから私たちはあなたからフィードバックを得たいと思っています！これは、Sprykerショップを可能な限り簡単にDockerizingするために努力する進行中の努力です。この目標を成功裏に達成するには、一般化され、このベースイメージに入れる価値のある一般的な手順を特定する必要があります。だからあなたのニーズとあなたの経験について教えてください。
この画像が動作しているのを見たい場合、どのように使用されるかは、コンテナ化されたSprykerデモショップをチェックしてください。このDemoshopは、ベースイメージの参照実装として機能します。 Sprykerがバンドルを進め、デモショップをそれらの変更を反映しているようにしているのと同じように、Demoshopをまったく同じ方法で使用しています。
コア特性は次のとおりです。
ONBUILD Trigger機能を使用して、子の画像ビルドプロセスにフックして制御するコンテナ化の利点：
最初の前提は、1つの画像からYvesとZedコンテナを提供することにしたことです。利点は、クラスター全体に共有コードベースを常に一貫してアップグレードすることです。両方のコンポーネントの要件を含める必要があるため、トレードオフはわずかに大きな画像です。
別の前提は、このスタックを理解するためには、開発環境と生産環境全体に1つの統一された画像を構築することです。これは、Sprykerアプリ自体によって評価されるAPPLICATION_ENVの使用に影響します。
この変数には次の影響があります。
ローカル構成ファイルと外部リソースの位置は、とにかくすべてのスタックが分離されているため、コンテナ化された環境で特別な考慮を必要とするものではありません。そのため、 ./config/Shared/ APPLICATION_ENV下に構成ステートメントがないことを確認してください。
区別に値するポイント1.1のみを考慮します。また、これは、適切なVARを効果的なコンテナに注入することで達成できるため、画像を構築しながら環境を区別することはできません。ポイント1.1では、通常、より多くの依存関係を解決する必要があるため、 APPLICATION_ENV developmentに設定された状態で常に画像を作成します。しかし、どのモードでアプリケーションが実際に実行されるかは、ビルドから独立しています。
これは、生産容器でさえ開発者の依存関係を含むことを意味します。これの主な理由は、すべての段階とすべての環境でコンテナがまったく同じ動作をするようにするための開発/テスト/製品のパリティの要件です。この前提のトレードオフは、再びより大きな効果的な画像です。ランタイム中、Sprykerアプリケーションの動作は、 developmentまたはproductionを受け入れるAPPLICATION_ENV設定することにより制御できます。 ./docker/runスクリプトを使用すると、この変数は自動的に設定されます。
この./shop/dockerサブフォルダーで提供されているスクリプトの背後にあるアイデアは、 develとprod環境の基本的な区別に従います。 docker-composeの観点からのこれらの環境の主な違いは、DevelモードでのBindマウントの雇用です。これにより、開発者はコンテナ内の背景でコードを実行しながらコードベースを外側から編集できます。
このセットアップは手動の努力を減らすために努力しているため、必要なロジックをレンダリングし、画像の構築やコンテナのセットアップの作成または引き裂きなどの最も一般的なタスクのショートカットであなたをサポートするシェルスクリプトを準備します。 ./docker/run helpをチェックしてください
prod環境は、近くの環境での作業の結果をテストするためのものです。つまり、ローカルリポジトリとコンテナの間に共有データが確立されないことを意味します。さらに、アプリケーションは、開発固有の拡張機能を無効にするAPPLICTION_ENV=productionセットで実行されます。
このベースイメージによって導入された概念は、結果のショップ画像を3つの異なるレイヤーに分割することです（事実上、 Dockerfileの各ステートメントが新しいレイヤーになるため、3つ以上のレイヤーがあります。これにはいくつかの理由があります：
まず、Dockerキャッシュを活用し、ショップの画像の反復的な再構築をスピードアップする必要があります。これらのレイヤーは一般的なものから特定に順序付けられるため、実際のショップの実装のコードベースで繰り返し作業しながら、スタック全体の再構築の必要性を削減する必要があります。
第二に、画像を引っ張っている間、異なるレイヤーを並行して取得できます。これにより、コンテナの作成時間が高速化されます。これは、ローカル開発だけでなく、生産セットアップの展開に関連するものです。さらに、一般的な層は頻繁に変化しないため、再建のためだけでなく、画像全体を補充するための必要性も削減する必要があります。
残念ながら、これにはコストがかからないわけではありません。効果的な画像サイズは、1つのレイヤーだけで構築される画像サイズよりもわずかに高くなります。今のところ、これは許容可能なトレードオフのようです。
これらのレイヤーの責任は何ですか？それらはどこにあり、いつ構築されるのでしょうか？
claranet/spryker-base （この画像）：claranet/spryker-demoshop （下流のショップの画像、例：デモショップ）：spryker-base画像からベースレイヤーをオーバーライドします（ $REBUILD_BASE_LAYERビルド変数）PHPまたはノードの依存関係をプライベートリポジトリから引き出す必要がある場合は、 ~/.netrcを提供するだけです。このファイルは、適切なリポジトリをクローニングするためにGITで使用される一時的なビルドコンテナにDockerビルドARGが注入されると、自動的に検出され、一時的に検出されます。
$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ビルドイントラクションの唯一のソースではないため、この機能が再現性を危険にさらす可能性があるため、彼らは実際に印象的な理由を獲得しました。 ISは - 他の技術の議論と同様に、絶対的な真実ではなく、トレードオフだけです。
Dockerized環境では、外部サービスは環境に応じて異なるアドレスで到達可能であるため、コードが実行されているため、調整するためにいくつかの構成が必要です。したがって、サイトローカル構成ファイルconfig/Shared/config_local.phpを介して構成を挿入するために、構成ファイルの優先順位のSprykerネイティブメカニズムを使用します。このファイルは他のすべてを無効にするファイルだからです。
構成順序は次のとおりです。
config_default.phpベース構成config_default-development.php開発モードに関連する構成（ APPLICATION_ENVを参照）config_local.phpサイトローカル構成。この場合、コンテナ化された環境の構成。この注文により、ショップが実行される効果的な環境とは独立して、構成ファイルを完全に使用できます。環境間で異なる動作を制御することもできます。私たちは、このアイデアが由来するサイトのローカル設定と言うようにオーバーライドします。
このために、 .gitignoreリストからconfig/Shared/config_local.phpを削除する必要がありました。
現在、両方の環境は、一時的な環境の仮定による名前のないボリュームを使用してdevelおよびprod 。つまり、スタック全体がコードベースをチェックすることを唯一の目的で作成することを意味します。それは、コンテナのレクリエーションを介してデータを持続する必要がある生産グレードのセットアップを意味する状況ではありません!!!
想定されるワークフローは、次のように説明できます。
ここで実装されている機能を再利用するには、以下の側面をベース画像と整合する必要があります。
./src/Pyzショップの実装./config構成./public/{Yves,Zed} - アプリケーションへのエントリポイント（documentroot）composer.json and composer.lockpackages.json 、 packages.lock and yarn.lock./docker/build.conf build.conf経由./docker/build.d/の下に配置することにより、画像のビルドプロセスを制御します./docker/init.d/の下に配置することにより、セットアップの初期化プロセスを制御しますここでこの画像を使用するために準備したデモショップをご覧ください。これは、あなたが持っているかもしれないすべての質問に答えるべきです。
参照実装は私たちによって維持されているデモショップであるため、これはかなり良いスターターです。このレポをフォーキングするか、ゼロから始めることによって。
ゼロから始めたい場合は、デモショップから必要な関心のある唯一のアーティファクトは次のとおりです。
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.phpこれにより、リポジトリにコードを入力し、個々のニーズに合わせてカスタマイズする準備ができています。
これと同じくらいきれいに見えるDockerfileに注意してください：
FROM claranet/spryker-base:latest
これは再利用性のような匂いがします。 :)
ショップのスケルトンとデモショップには、 ./docker/run 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 （必須） - 結果のDocker画像の名前は何ですか？VERSION （必須） - どのバージョンのDocker画像に取り組んでいますか？BUILD_DEPENDENCIESビルド時間中にインストールされる配布（debian）パッケージBASE_DEPENDENCIESさらにインストールする配布（Debian）パッケージPHP_EXTENSIONSインストールされるPHP拡張機能のスペース分離リストNPM_DEPENDENCIES DEPSレイヤーでのNPM処理の前に挿入される配布パッケージKEEP_DEVEL_TOOLS （デフォルト：false） - 開発ツールをインストールし、ビルドを超えて保持しますか？SKIP_CLEANUP （デフォルト：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トリガーは、実行されるチャイルドDockerfileファイルの最初の指令となるため、これらのオーバーライドされたファイルは、コンテナの実行時に最初に使用できます。
ベース画像で行われた設計上の決定のほとんどは、カスタマイズ可能性と拡張性のアイデアによって支配されています。個々のショップの画像に一度だけ使用できるベース画像は、かなり役に立たず、ベースと呼ばれるものから遠く離れています。
ビルドプロセスは、名前がランタイムの後にすべての派生コンテナによって共有される画像を生成するプロセスを示唆しているとおりです。
一部のビルドスクリプトは./docker/build.conf build.confに設定できるパラメーターを考慮してください
上記の参照を参照してください。
フックdir： ./docker/build.d/ build.d/
ベース画像から継承されたビルドステップを拡張するか、それらを無効にする場合は、カスタムビルドスクリプトを./docker/build.d/の下に配置する必要があります。そこには、各ステージ/レイヤーを反映した3つのディレクトリがあります。
./docker/build.d/base/ベースOSレベルのインストール./docker/build.d/deps/ショップ固有のPHP/ノード依存関係を扱います./docker/build.d/shop/実際のショップコードベースのコード生成を扱う各subdirのスクリプトは、語彙的に順序付けられた実行（Actuall Sourced）になります。
たとえば、ベースイメージによってナビゲーションキャッシュが構築される方法を変更する場合は、ベース画像によって./docker/build.d/shop/650_build_navigation_cache.shの下のベース画像によって提供される場所とまったく同じ場所にスクリプトを提供する必要があります。結果の画像とコンテナはユニオンファイルシステムを利用するため、ショップ画像によって提供されるファイルは、BAS画像によって提供されるファイルよりも優先されます。このメカニズムにより、何もしないスクリプトを提供するだけで機能を無効にするか、何かを異なるまたは追加で行うスクリプトを追加することで動作を変更できます。
上記のメカニズムは、Sprykerコンテナの初期化とセットアップ全体を実行する方法を変更するために使用できます。ベースイメージには、共通環境に有効な意味のあるデフォルトが付属していますが、適切な場所にカスタムスクリプトを配置することでオーバーライドできます。
ベース画像は、両方のフック、各コンテナの初期化、およびセットアップ全体の初期化のためのフックを提供します。
フックdir： ./docker/entry.d/ entry.d/
ランタイムエントリポイント引数（ run-yves 、 run-zed 、 run-yves-and-zed 、 run-cron ）は、この実際のコンテナがどの役割を担っているかを管理し、このフックディレクトリにリストされているファイルをすべてソースにします。変数を介して、スクリプトは、実行時間中に有効および開始するサービスを決定します。
一般的なタスクは、コンテナ作成でenv var ENABLE_XDEBUGを介して要求されたxdebug有効にすることです。
性質のため、すべてのフックは各コンテナの開始で実行されます。
フックdir： ./docker/init.d/ init.d/
通常、各ショップインスタンスは、そのようなショップを初期化するための最初の手順を実行する必要があります。このセットアップ中に、フック監督の下のすべてのシェルスクリプトが実行されます。たとえば、Demoshopが./docker/init.d/500_import_demo_data.shの下にスクリプトを配置するようなダミーデータを使用してデータベースを初期化するため。
これは暗黙のうちに行われません。エントリポイントのArg initで個別の容器を生成する必要があります。
フックdir： ./docker/deploy.d/ deploy.d/
init手順と同じです展開手順です。この手順は、展開中に実行されます。ライフサイクルのコンセプトは、これらの2つのフックで構成されています。初めては初めて呼び出され、新しいバージョンの画像が実行されるたびに展開されます。
これは暗黙のうちに行われません。エントリポイントARG deployでは、別の容器を生成する必要があります。
すでに述べたように、あなたはあなたの非常にカスタムビルドとINITの手順を自由に追加することができます。 ./docker/common.inc.shスクリプトは、いくつかの有用な機能を支援します。自分でチェックしてください。
準備された出力関数を使用して、ビルドステップを作成します。
errorTextエラーを上げますsuccessText成功を送り返しますsectionHead - タスクのグループの見出しを印刷しますsectionText Text-中間ビルドステップ情報を印刷します含まれるすべてのビルドステップに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インスタンスでは、nginx、php-fpm、およびアプリケーションログ内/data/logs/を見つけることができます。
公式のPHP画像に依存しています：https：//hub.docker.com/_/php/
確かにとても良い質問です！
画像の構築時間が短いため、ソースビルドとパッケージの両方のインストールのために、Alpineに行くことにしました。それは多かれ少なかれ、重いリフティングプロジェクトでさえアルパインでホストできることを示すべき概念の証明です。予想される利点は、画像サイズの削減と、より速い実行時間と、より速い実行時間です。
残念ながら、MUSL Lib Cは、汎用性が鍵である場合、顧客の文脈で耐えられない制限を導入することがわかります。 0.9.6以降、Debianベースの画像に切り替えました。
2つのことが思い浮かびます：
もうすぐ来る。 :)
問題を確認してください。
