web-dev-qa-db-ja.com

Magento 2で静的コンテンツを展開するためのより速いルートですか？ Dev to Liveなど？

これが私の環境です。これは、関連する開発モードと本番モードでも設定されることに注意してください。

Dev:
https://ar.dev.loc/
https://en.dev.loc/

Live:
https://ar.site.com/
https://en.site.com/

私はアラビア語と英語のマルチストア設定を使用しており、モジュールの構築やテンプレートの構築など、すべてがうまく機能しています。

ただし、（grunt lessまたはgrunt watchを使用しているにもかかわらず）lessファイルまたはJSファイルに変更を加えた場合、ローカルマシンでそれらを確認するには、開発環境で次のコマンドを1回実行する必要があります。

$ rm -rf var/cache var/page_cache var/view_preprocessed pub/static
$ mkdir pub/static
$ bin/magento setup:static-content:deploy
$ bin/magento setup:static-content:deploy ar_SA
$ grunt exec less // sometimes I leave this do this
$ grunt // I swap between these

このプロセスを毎回行うには、長い時間がかかります。私は速いコーダーであり、サイトですぐにCSSとLessを見るのが好きで、周りを待たずにイライラしています。

チームが行っている迅速なアプローチは、実際にpub/staticその後、これらをlessおよびapp/design etcそして、上記のプロセスを実行してからgitを実行します。

ライブサーバーはほとんど同じです。 Git pullとメンテナンスモード（ライブecomサイトの狂気！M2を構築するのは誰ですか？次に、上記のコマンドを実行します-ダウンタイム45分）

展開、開発、およびチームがダウンタイムを発生させることなく、作業を改善し、変更をより迅速に確認するためのより迅速な方法が必要です。

Magento 2の公式ドキュメントでも、コンテンツを公開するにはLIVEサイトをメンテナンスおよびダウンタイムモードにする必要があると書かれています-これはオプションではありません。 CTOは満足していません。単純にばかげている

より速い開発と同じ問題について尋ねる人々との関連質問：

Cssの変更は、magento2のdeployコマンドの後にのみ反映されます

Magento 2静的キャッシュ

CSSおよびJavaScriptへの変更は、静的コンテンツを展開した後にのみ適用されます

だから私はすべての問題を照合し、これを解決したい。

magentomagento2
28
TheBlackBenzKid

はい、次の手順を実行することで高速化できます。

  1. Appディレクトリのjs/cssファイルを変更します
  2. Pub/staticフォルダーからファイルを削除します

次のコマンドにより、pub staticでファイルを見つけることができます

find pub/static -iname yourjsfile.js
  1. pub/static folderから変更があるファイルのみを削除します
  2. pub/static.htaccess file＆pub/static.php fileがあることを確認してください
  3. pubフォルダーにファイル書き込み許可を割り当てます
  4. ブラウザでURLにアクセスします。

pub/staticの.htaccessは、欠落しているファイルをpub/static.phpに送信しますresourceおよびpub/static.phpファイルはStaticResourceを作成しますファイルがある場合は、それを展開します。

注：これはApacheでのみ機能しますmod_rewrite

Nginxの場合は、nginx.conf.sampleで同じ設定を行う必要があります

13
Emizen Tech

私は-j(--jobs)新しいプロセスをフォークするオプション、私はstatic-content:deploy 10分以上から1分未満までの時間。見る - Magento/Deploy/Process/Queue.php

php bin/magento setup:static-content:deploy -j[JOBS_AMOUNT]

--jobsオプションは、指定された数のジョブを使用して並列処理を有効にします。デフォルトは4です。タスクを1つのプロセスで実行するには（たとえば、システムがプロセス分岐をサポートしていない場合）、--jobs 1。 //参照： devdocs.magento.com

このオプションは、 pcntl が有効な場合にのみ使用できます。

pcntl

この拡張機能をビルドするために外部ライブラリは必要ありません。

PHP=のプロセス制御サポートはデフォルトでnotが有効になっています。

CGIまたはCLIバージョンのPHP with --enable-pcntlコンパイル時の構成オプションPHPプロセスコントロールサポートを有効にする。

注：現在、このモジュールは非Unixプラットフォームでnot機能します（ウィンドウズ）。

注：that pcntl_fork は、notPHPがApacheモジュールとして実行されている場合、この場合、この関数は存在しません！

4
Nolwennig

_setup:static-content:deploy_にはしばらく触れていません。 Magento 2の遅い展開プロセスにうんざりした後、CSSファイルまたはJSファイルに変更を加えて、すぐにサイトに反映できるようにする独自の方法を考案しました。ここに魔法があります：

_cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME
find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c 'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'
cd - 1> /dev/null
_

分解しましょう...

  1. _cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME_-アクティブなテーマディレクトリに変更します（_$VENDOR_および_$THEME_を独自の値に置き換えます）
  2. find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10-テーマディレクトリ内で過去10分以内に何らかの方法で変更されたすべてのCSSおよびJSファイルを検索します（_*_は結果の先頭の_./_を取り除きます）。ニーズに合わせてパラメータを自由に変更してください
  3. _xargs -I {} bash -c_-変更されたファイルごとに、＃4-6のコマンドを実行します（変更されたファイルへの相対パスは_{}_に保存されます）
  4. dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g")-展開先パスを設定します
    • _*_グロブは、現在のロケールに一致するものを処理します
    • $(...)はサブシェルを生成し、宛先パスに追加する必要があるソースパスの部分のみを抽出します（webディレクトリレベルはpubの下に存在しません）
  5. _echo Deploying {} to $dest ..._-アクティビティをコンソールに記録して、どのファイルがデプロイされているかを確認します
  6. _mkdir -p $dest && cp {} $__-宛先ディレクトリ構造を作成します。ディレクトリ構造が正常に作成された場合にのみ、変更されたファイルをpub（_$__が前のコマンドの最後の引数mkdirを指す展開先にコピーします。 _$dest_）
  7. _cd - 1> /dev/null_-前のディレクトリに変更して、中断したところから続行できるようにします

これをすべてエイリアスにスローして1つのコマンドに減らすことができますが、一重引用符を忘れずにエスケープしてください。

_alias update='cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME; find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c '"'"'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'"'"'; cd - 1> /dev/null'
_

ニスを使用する場合は、エイリアスの最後にニスを再起動するコマンドを追加する必要があります（例、_Sudo service varnish restart_）。そうしないと、キャッシュされた静的アセットにヒットする可能性があります。

変更を加えるたびにupdateを入力するのが面倒な場合は、cronに配置するか、うっとうしい監視タスクまたは同等のものに統合できます。

4
thdoan

一般的なコメント：

Setup：static-content：deployを実行するとき、ここで「うなり声」をしてはいけません。 en_US（パラメーターなし）とar_SAの静的コンテンツを並行して生成できます（bashを使用すると、非常に簡単にできます）。

HTTPS（セキュア）リソースが不足している場合（それがgruntを追加で使用した理由である可能性があります）、環境変数「HTTPS」が設定されていることを確認します（例：HTTPS=ON）静的コンテンツをコンパイルするプロセス（ ref ）。

それとは別に、はい、時間がかかります。注目されているのは、PHPの少ないコンパイルにはかなり時間がかかるということです。別の開発者から聞いたときに思いついたアイデアの1つは、ローカルレスキャッシュに少ないコンパイルをキャッシュし、ファイルが実際に変更された場合にのみ再コンパイルすることでした。たぶんあなたもそれを試すことができます。

私はまだPoCを一緒にハッキングする責任はありませんが、コンパイルが少ないことがボトルネックであるという主張の良いテストになると思います。

また、git Pushで自動的にコンパイルするビルドサーバーを実行して、負担を軽減することを強くお勧めします。

2
hakre

当社では、 Capistrano を使用してMagento2のデプロイを管理します。Magento2には 特定のタスクセットもあります それは非常にうまく機能します。

Capistranoを使用して、「リリース」フォルダーを指すシンボリックリンクを指すようにWebサーバーのルートを設定します。デプロイを開始すると、すべてのコンパイル（di、静的コンテンツ、ecc）は個別のフォルダーで作成されるため、オンラインWebサイトは影響を受けず、オンラインのままです。手順の最後に、エラーがない場合にのみ、シンボリックリンクは新しいリリースに切り替えられます。

このようにして、通常、ダウンタイムはゼロになるか、数秒に短縮されます。

Capistranoは、何か問題が発生した場合に古いリリースにすばやく戻ることができる基本的な「ロールバック」機能も提供します。

2
Mir

私はマグネトーに詳しくありませんが、これはあなたのために働くかもしれません。サイトを更新するときは、次の手順に従います。

サイトがsiteディレクトリの下にあるとします。

$ cp -r site site-update

# update the site in site-update directory

$ mv site site-old && mv site-update site

このようにして、ダウンタイムなしでサイトが更新されます。

1
napuzba

また、cssとjsにサインオンしている場合、セットアップアップグレードを実行すると、それが破壊されたように見え、それからバージョンが壊れ、静的コンテンツを再構築するまでcss/jsが起動します。

私は、彼らがこれが生産の人々のためにどのように働くべきであるかを彼らがどのように考えているのか見当がつかない。ほとんど何でも、それを気まぐれから抜け出すことができます、そして、あなたは再建しなければなりません。

1. css/jsのサインオンを有効にします。2。静的コンテンツのデプロイを実行できます。urはかなり邪魔になりません。3.キャッシュをフラッシュします（新しいバージョン12312312を静的URLに追加します）。

しかし、真剣に、展開で堅実になる方法はありません。

TheBlackBenzKidは非常に好奇心ios盛で、1年後に終わったのですが、magentoを捨てましたか？

1
Daniel Kozlowski

この問題の解決策があります。

希望するストアのコンテンツを公開する必要があります

php bin/magento setup:static-content:deploy [lang(en_US)] -t [vendor]/[theme]

Magentoのキャッシュは変更しないので、手動で削除してください

rm -rf pub/static/_*/*

php bin/magento cache:flush; php bin/magento cache:clean;

ページを更新して完了したら、ページの再生成時に新しい変更が必要になります。

この手順は、phtmlおよび静的コンテンツの変更には必須であり、レイアウトの変更にはキャッシュのフラッシュが必要です。また、コントローラーでの変更はdi：compileを使用する必要があるため、arshにとって苦痛です。

0
Yeison Agudelo