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のように。
初期化ルーチンがすべてのデータをデータベースにインポートしてからRedisおよびElasticSearchにエクスポートするのにかなりの時間がかかるため、Sprykerスタックが作成されている間は我慢してください。現在、これには約10分かかります。
初期化が終了した後、ブラウザを次のURLに向けることができます。
これは、Spryker Demoshopの公式リファレンス実装のドキュカリングバージョンです。必要なすべての依存関係を自動的に引っ張り、PostgreSQL、Redis、Elasticsearch、Jenkinsを含むスタックを作成することにより、すぐに実行する準備ができています。ランタイム中に各サービスが初期化されます。
このリポジトリは、Spryker Commerce OSに基づくパラダイムショップのデモとして、またはDemoshopのフォークから始まる独自の実装の開発の出発点として使用できます。
Build and Start手順は、さらにツーリングをクララネット/PHP画像から継承します。このドキュカ化の背後にある技術的なデザインのアイデアがあり、次のようなさらなるポイントへの回答があります。
docker/ Files -System構造コンテナ化の利点：
Docker-Composeスタックによっていくつかのサービスが公開されています。スタックを並行して実行し、ポートの衝突を防ぐには、ポート割り当てを調整する必要があります。
したがって、次のスキームが実装されています：ポート番号は次のようにエンコードされます： ECCDD
したがって、yves deはhttp：// localhost：20100/and yves usを介してhttp：// localhost：20102に到達できます。
通知：ポートごとの店舗/ドメイン間の差別化は、ローカルの開発環境にのみ適用できます。クララネットが提供する実際の生産グレードスタックは、実際のドメイン名に基づいてこの区別を行っています。
中心的な前提は、このスタックを理解するためには、開発環境と生産環境全体に1つの統一された画像を構築するために重要です。これは、Sprykerアプリ自体によって評価されるAPPLICATION_ENVの使用に影響します。
この変数には次の影響があります。
ローカル構成ファイルと外部リソースの位置は、とにかくすべてのスタックが分離されているため、コンテナ化された環境で特別な考慮を必要とするものではありません。そのため、 ./config/Shared/ APPLICATION_ENV下に構成ステートメントがないことを確認してください。
区別に値するポイント1.1のみを考慮します。また、これは、適切なVARを効果的なコンテナに注入することで達成できるため、画像を構築しながら環境を区別することはできません。ポイント1.1では、通常、より多くの依存関係を解決する必要があるため、 APPLICATION_ENV developmentに設定された状態で常に画像を作成します。しかし、どのモードでアプリケーションが実行されるかは、それから独立しています。
これは、生産コンテナでさえ開発依存関係を含むことを意味します。これの主な理由は、すべての段階とすべての環境でコンテナがまったく同じ動作をするようにするための開発/テスト/製品のパリティの要件です。この前提のトレードオフは、再びより大きな効果的な画像です。
ランタイム中、Sprykerアプリケーションの動作は、 developmentまたはproductionを受け入れるAPPLICATION_ENV設定することにより制御できます。 ./docker/runスクリプトを使用すると、この変数は自動的に設定されます。
./docker/runを介して提供されるラッパースクリプトの背後にあるアイデアは、 develとprod環境の基本的な区別です。 docker-composeの観点からのこれらの環境の主な違いは、DevelモードでのBindマウントの雇用です。これにより、開発者はコンテナ内の背景でコードを実行しながらコードベースを外側から編集できます。
このセットアップは手動の努力を減らすために努力しているため、必要なロジックをレンダリングし、画像の構築やコンテナのセットアップの作成または引き裂きなどの最も一般的なタスクのショートカットであなたをサポートするシェルスクリプトを準備します。 ./docker/run helpをチェックしてください
prod環境は、近くの環境での作業の結果をテストするためのものです。つまり、ローカルリポジトリとコンテナの間に共有データが確立されないことを意味します。さらに、アプリケーションは、開発固有の拡張機能を無効にするAPPLICTION_ENV=productionセットで実行されます。
Dockerized環境では、コードが実行されている環境に応じて異なるアドレスで外部サービスが到達可能であるため、コンテナ/画像は環境変数を介して外部から構成できる必要があります。これらは、Sprykerアプリによって消費する必要があります。したがって、この画像は、Docker env varsとして注入され、準備されたconfig_local.phpを介して分解されている特定の環境変数が予想されています。
順序、優先順位、および構成ファイルと見なされるスキームを定義する構成ファイル階層のSprykerネイティブメカニズムを活用しています。この画像はdocker/config_local.phpの下のこのリポジトリにある独自のサイトローカル構成ファイルを提供し、 config/Shared/config_local.phpの下の結果のdocker画像で見つけることができます。このファイルは他のすべてを無効にするファイルだからです。
構成順序は次のとおりです（最後にprioのものを上回っています）：
config_default.phpベース構成config_default-development.php開発モードに関連する構成（ APPLICATION_ENVを参照）config_local.phpサイトローカル構成。この場合、コンテナ化された環境の構成。この注文により、ショップが実行される効果的な環境とは独立して、構成ファイルを完全に使用できます。環境間で異なる動作を制御することもできます。私たちは、このアイデアが由来するサイトのローカル設定と言うようにオーバーライドします。
現在、両方の環境は、一時的な環境の仮定による名前のないボリュームを使用してdevelおよびprod 。つまり、コードベースをチェックする唯一の目的のためにスタック全体が作成されることを意味します。それは、コンテナのレクリエーションを介してデータを持続する必要がある生産グレードのセットアップを意味する状況ではありません!!!
想定されるワークフローは、次のように説明できます。
docker-compose(1)シェルスクリプト./docker/runを介してラップされています。このスクリプトは、ローカルリポジトリとその構成に注意を払いながら、ほとんどの一般的なタスクのショートカットを提供します。
Docker画像の使用をビルドするだけで： ./docker/run build
両方ともまったく同じ画像に基づいているため、これは両方の環境に適用されます。メインのSpryker-Demoshop画像と、Spryker-Demoshop画像の専門のJenkins-Slaveフレーバーを構築します。
実際、2つの画像が構築されています。1つは、YVEとZED層の両方のNginxとPHPコンテナに使用されている実際のショップ画像用です。後者は、ジェンキンスのスレーブ/ワーカーを作成するために、必要なすべてのジェンキンスコンポーネントによってショップの画像のみを拡張します。実際のショップの画像のトップでこれを行う理由は、Jenkinsを介して実行されているすべてのバックエンドジョブが完全なSprykerコードベースを必要とすることです。
SSDSが組み込まれた通常のワークステーションでのビルド時間は、現在、両方の画像に対して10分間に10分かかります。
デモショップに基づいて自分の仕事を始めたい場合は、地元の開発環境が興味深いと感じるかもしれません。このセットアップにより、ローカルコードベースを実行中のコンテナに取り付け、コードベースの変更がすぐに有効になることがわかります。
./docker/run devel upだけで、そこに行きます。
割り当てられたすべての名前のないボリュームを含むDevel Stackを破壊： ./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）を維持しながらYVEおよび/またはZedコンテナを再現する必要がある場合に備えてください： ./docker/run devel rebuild
それらのコンテナを再構築せずに再作成したい場合は、それらを実行してください： ./docker/run devel recreate
デバッグ中は、 /entrypoint.shにコンテナを初期化する代わりに便利かもしれません。この手順をスキップして自分で確認してください。これを行うことができますcommand: run-zed docker-compose-devel.ymlをcommand: sleep 1wする./docker/run devel recreate zedできます。
docker-composeへのインターフェースこれはすべてdocker-compose(1)に基づいているため、たとえばシェルを介してコンテナを入力するなど、自分で電話する必要があるかもしれません： ./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を介して、インストールルーチンのこのような契約を作成しました。
Debianストレッチを支持して、Alpine Supportを落としました！ Alpineが必要な場合は、2.28.0の前にバージョンを使用してください。ただし、Alpineはこれ以上サポートしていません。
また、注：親の画像はclaranet/spryker-baseからclaranet/phpに切り替えられ、以前のdocker/ Files-System構造を破壊します。このパスを選択しました。なぜなら、以前のベースイメージは、Spryker要件だけでなく、PHPベースのアプリケーション要件に一致するようにさらに一般化する可能性があるためです。
ここにリストされていないバグが見つかった場合は、報告してください！
https://bugs.php.net/bug.php?id=76029が固定され、Opcacheを有効にすることができるまで、デモショップを出荷することはありません。 Opcacheは製品環境に不可欠であり、開発者で7.2、生産で7.1を使用することは意味がありません...
Spryker Demoshop 2.32以来、Opcacheが例外をスローさせるバグがあるようです。そのため、Opcacheを無効にすることを余儀なくされました。
