Heroku jest świetne. Ale za każdym razem, gdy wdrażam, Heroku wydaje się, że chce ponownie pobrać i odbudować wszystkie pakiety. Z socket.io i mailparser zajmuje to około 3 minuty.Przyspieszenie wdrażania na Heroku
Czy istnieje sposób na przyspieszenie procesu wdrażania? Czy istnieje sposób, aby powiedzieć Heroku, że może buforować te przedmioty? Czy mogę przesłać wstępnie zbudowane node_modules?
Wydaje jak na dzień dzisiejszy Heroku wreszcie buforuje folder node_modules!
-----> Usuwanie 6 plików pasujących do wzorców .psignignore. Wykryto
-----> aplikacja node.js
-----> Żądany zakres węzeł: 0.10.x
-----> Rozwiązano wersja węzeł: 0.10.22
-----> Pobieranie i instalowanie węzeł
-----> Przywracanie node_modules z pamięci podręcznej
-----> Instalacja dependen Cies
-----> Przycinanie niewykorzystane zależności
-----> Buforowanie node_modules katalogu dla przyszłości buduje
-----> Czyszczenie Node-Gyp i artefakty NPM
Czas budowy dla mnie to teraz 3 sekundy.
Tak samo miałem dzisiaj. Czy zawsze będzie je buforował, czy też będzie wiedział, kiedy zaktualizują się automatycznie teraz? – Alexis
Nie mam źródła, ale wyobrażam sobie to: jeśli po prostu skopiują folder 'node_modules' do projektu i uruchomią' npm update', zaktualizują tylko te części, które wymagają aktualizacji. Zasadniczo npm już sobie z tym radzi. Takie jest piękno npm, mapuje całe drzewo zależności do systemu plików. – Prinzhorn
Po tygodniu mogę potwierdzić, że za każdym razem, gdy aktualizuję zależność modułu i wysyłam do heroku, że tylko ten jeden moduł jest pobierany z rejestru npm. Jest o wiele szybszy niż wcześniej. – Prinzhorn
Jedną z rzeczy, które zrobiłem, aby przyspieszyć proces, było dodanie pliku .slugignore do głównego folderu i dodanie wszystkich plików i folderów, w których nie chciałbym uruchomić aplikacji.
zawartość Przykładowy .slugignore pliku:
roboczych
makiety
* .psd
* .pdf
Miałem to samo pytanie (patrz Avoid npm refresh after every deployment on Heroku).
Heroku wymusza pobieranie/kompilację/etc. sekwencja, ponieważ muszą uruchomić aplikację z pustym hasłem: czyszczenie wcześniej usuniętych plików, kiedy przenoszą aplikację na inny serwer, podczas przydzielania nowych internetowych dynów itp.
Kwestia jest wyraźnie związana z rodzimymi pakietami i rekompilacja. W przypadku wszystkich pakietów js-only zatwierdzam je za pomocą mojego projektu i usuwam je z pliku package.json. Zyskuje kilka sekund, ale nie za wiele.
Zdecydowanie będę w stanie wstępnie skompilować i zatwierdzić natywne moduły (z powodzeniem uruchomię wkhtml2pdf na Heroku, na przykład z binariami skompilowanymi dla linux-amd64), jeśli uzyskasz dostęp do Linuksa (lub VM) w tej samej konfiguracji - na dzień dzisiejszy, Linux [...] 2.6.32-350-ec2 #57-Ubuntu SMP [...] x86_64 GNU/Linux.
Chociaż nie poleciłbym tego jako ostatecznego rozwiązania, ponieważ może się kiedyś złamać - nie wydaje mi się, że heroku gwarantuje platformę, na której działa aplikacja.
Występuję w tym samym problemie.
Niektóre dyskusja tutaj o buforowanie folder node_modules: https://github.com/heroku/heroku-buildpack-nodejs/pull/37
Inny pomysł: https://github.com/heroku/heroku-buildpack-nodejs/issues/25
myślę o kilku rozwiązań już teraz.
Przyjazd node_modules w oddzielnej gałęzi: Rdzeń node.js opiekunowie faktycznie polecam sprawdzenie w folderze do kontroli źródła node_modules (dla aplikacji, a nie libs). Nie podoba mi się to. Jednak sposobem obejścia tego problemu może być posiadanie osobnego oddziału production z innym plikiem .gitignore, który nie zignoruje node_modules. Jeśli chcesz wdrożyć, po prostu wykonaj rebase od swojego mastera i zostanie on sprawdzony. Przynajmniej to utrzyma twój główny oddział wolny od zależności.
Dodaj preinstall skrypt package.json pobrać skompresowany zip zależność: Można również dodać git hak pre-push, aby zbierać swoje zależności i przesłać je do S3. Prawdopodobnie byłoby to jednak zbyt powolne.
Modyfikacja heroku-buildpack-nodejs: Integracja wyjątkową prośbę ściągania z node_modules buforowania:
heroku config:set BUILDPACK_URL=https://github.com/opdemand/buildpack-nodejs.git
Wydaje się, że w ostatnim czasie postęp w heroku-buildpack-nodejs.
Gdy prośba przyciąganie jest połączone, można dodać
heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs
do heroku environment variables.
Na razie David dolara rozwidlony repozytorium jest dostępny na
https://github.com/ddollar/heroku-buildpack-nodejs
z tego, ponieważ swoimi BUILDPACK_URL powinien buforować modułów NPM. Próbowałem go z node.js 0.10.5a, npm wersja: 1.3.5 i npm_modules w .gitignore. Wydaje się, że Tt do tej pory działa dobrze!
Sprawdź tę gałąź nowego Heroku node.js buildpack, obecnie w wersji beta, która wspiera node_modules buforowanie pomiędzy buduje:
https://github.com/heroku/heroku-buildpack-nodejs/tree/diet
Aby go użyć:
heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs#diet -a my-node-app
git commit -am "fakeout" --allow-empty
git push heroku
Pakiet [build-pack] (https: // github.com/heroku/heroku-buildpack-nodejs) (który jest kodem, który przekształca twój kod źródłowy na to, co zostanie wdrożone na Heroku) powinien już buforować 'node_modules' pomiędzy kompilacjami. Przynajmniej tak mówi w README. Jesteś pewien, że to właśnie spowalnia twoją kompilację? – friism
@friism Wydaje mi się, że używają standardowego buforowania NPM, więc moduły muszą zostać rozpakowane, skopiowane i, co najważniejsze, ponownie skompilowane po każdym naciśnięciu. Jeśli masz moduły z rozwiązłym drzewem zależności lub w zależności od rozszerzeń C++ (mongodb, socket.io, itp.), To zajmuje to trochę czasu. –