Jak uruchomić plik nightmare.js w google appengine dla node.js

Question

Istnieje famous issue z koszmarem i elektronem nie działającym na bezgłowych serwerach linuksowych. Oficjalny model electron docs sugeruje użycie xvfb w celu sfałszowania wyświetlacza. Sugerują użycie tego pliku .yml do travis.

 
addons: 
    apt: 
    packages: 
     - xvfb 

install: 
    - export DISPLAY=':99.0' 
    - Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 & 

Pytanie

Jak mogę wykorzystać powyższy fragment kodu do app.yaml akt google AppEngine dla node.js. Próbowałem użyć tego, jak jest, ale glcoud zgłasza błąd, że addon jest nieprawidłowym poleceniem. Luka official docs nie ma żadnego podobnego polecenia.

Jakieś sugestie, jak możemy uruchomić koszmar i elektrony na google appengine dla node.js ..?

Answer 1

Istnieją dwie części związane z tym pytanie:

1. Running chromu (co elektron, co z kolei, nightmare "używa") headlessly w systemie Linux.
2. Zainstaluj/użyj xvfb, aby uruchomić chromium na silniku aplikacji.

Part 1)

Trzeba Xvfb.

Xvfb (Virtual Framebuffer) to program, który z wiki: "jest serwerem wyświetlania implementującym protokół serwera wyświetlania X11. W przeciwieństwie do innych serwerów wyświetlania, Xvfb wykonuje wszystkie operacje graficzne w pamięci bez pokazywania jakiegokolwiek wyjścia ekranu. "

To jest to, czego potrzebujesz, aby uruchomić przeglądarkę bez ekranu wyjściowego.

Najpierw zainstaluj wszystkie pakiety związane z Xvfb, aby uruchomić go na Linuksie.

apt-get install -y \ xvfb \ x11-xkb-utils \ xfonts-100dpi \ xfonts-75dpi \ xfonts-scalable \ xfonts-cyrillic \ x11-apps \ clang \ libdbus-1-dev \ libgtk2.0-dev \ libnotify-dev \ libgnome-keyring-dev \ libgconf2-dev \ libasound2-dev \ libcap-dev \ libcups2-dev \ libxtst-dev \ libxss1 \ libnss3-dev \ gcc-multilib \ g++-multilib

Więc z zainstalowanym Xvfb trzeba stworzyć ekran wirtualny Xvfb i wyeksportować zmienną środowiskową o nazwie wyświetlacz, który wskazuje na to. Chrom w Electron automatycznie wyszukuje $ DISPLAY.

Powyższe można zrobić łatwiej. Oto dwie opcje:

• wywołania programu z systemem Linux CLI (ignoruj ​​ostrzeżeń Xvfb jeśli skrypt koszmar działa poprawnie):

  • xvfb-run -a node main.js. Lub ...

  • Jeśli używasz funkcji związanych z renderowaniem, takich jak wykonywanie zrzutów ekranu: xvfb-run -a --server-args="-screen 0 1280x1028x24 -ac +extension GLX +extension RANDR +render" node app.js. Google opcje xvfb, aby dostosować się do gustu.

• Programowo: using xvfb npm package

Od tego momentu ciebie powinien być w stanie uruchomić na Linuksie koszmar.

część 2)

Nodejs na app silnika jest prowadzony za pośrednictwem elastycznego środowiska. Znaczenie, poprzez pojemniki dokowane.

Z środowiska wykonawczego GAE nodejs: "Jeśli twoja aplikacja wymaga dodatkowych zależności na poziomie systemu operacyjnego, będziesz musiał użyć niestandardowego środowiska wykonawczego na podstawie tego środowiska wykonawczego, aby zainstalować odpowiednie pakiety."

Docker jest zupełnie osobny temat, ale w tym celu wyżej z app silnika masz dwie opcje o ile wiem:

1. Extending the runtime

2. Używaj GAE z custom runtime od zadraśnięcie.

Tak czy inaczej, w zasadzie to, co trzeba zrobić, to zainstalować pakiety Xvfb związane określających je w dockerfile i że powinno załatwić sprawę.

Powodzenia!

Ważne Uwagi:

1. Powyższy apt-get pakiety są uzależnione od dostępności dotyczącej distro linux (powyższy kod działa na Ubuntu i Debianie). Na przykład, przy określonym zestawie pakietów i w czasie tego posta będzie on działał z elastycznym środowiskiem GAE, ponieważ jest oparty na debian jessie i nie będzie działał na alpejskim systemie Linux.

2. Chromium potrzebuje minimalnej alokacji dev/shm, aby dobrze działał. Na przykład na heroku jest ustalone na 5mb - i nie ma sposobu, aby to zmienić. Chromium ulegnie awarii po kilku koszmarnych działaniach. W związku z tym chrom nie będzie działał na żadnych dynamach Heroku o dowolnej wielkości. W docker jest ustawiony na 64mb, więc w zależności od złożoności skryptu będzie dobrze lub trzeba go dostosować. W zwykłych instalacjach Linux, dev/shm jest zwykle ustawiony na połowę całkowitej dostępnej pamięci. Tak więc w środowisku o wielkości 512 MB, dev/shm zostanie ustawione na 256 MB, a koszmar najprawdopodobniej będzie działał dobrze.

Answer 2

Dzięki @rickmed za jego dokładną odpowiedź! Pomogło mi to w opanowaniu obsługi xvfb w tym kontekście. (https://stackoverflow.com/a/37663861/562915)

Używam Nightmare do generowania plików PDF z punktu końcowego. Mój lokalny programista działa w systemie OSX i doszedłem do tego problemu, próbując uruchomić go w Google App Engine. Początkowo pracowałem z odpowiedzią Rickmeda i od tego czasu wymyśliłem inny sposób uniknięcia niestandardowego Dockerfile/runtime. Myślałem, że podzielę się tym tutaj.

Nie używam niestandardowego pliku Dockerfile i zezwalam gcloud na generowanie go podczas wdrażania. Mój plik yaml używa runtime: nodejs. Dla mojego prostego użycia Nightmare mogę dodać skrypt preinstalacyjny do mojego package.json i zaktualizować skrypt startowy. To wszystko, czego potrzebuję, aby zmarnować koszmar, pracując nad GAE. Oto odpowiednie linie z mojego pakietu.json:

{ 
    "scripts": { 
    "preinstall": "apt-get update && apt-get install -y libgtk2.0-0 libgconf-2-4 libasound2 libxtst6 libxss1 libnss3 xvfb", 
    "start": "xvfb-run -a node build/server/index", 
    ... 
    }, 
    ... 
} 

Wyciągnąłem uproszczonego zestawu apt-get zainstalowane pakiety z komentarzem otaviomedeiros męska: https://github.com/segmentio/nightmare/issues/224#issuecomment-225887320

wpadłem na pomysł z Daishi Kato pomocny artykuł: https://medium.com/google-cloud/how-to-use-phantomjs-with-node-js-on-google-app-engine-6f7feaea551#.6eoyvpn93 i to zrzeczenie jest zawarta w artykule:

Mimo że poniższa procedura sprawdza się dobrze na piśmie, nie oznacza to, że będzie działać przez długi czas. Nie jestem nawet pewien, czy jest to zalecane. Proszę zrozumieć ryzyko.

Weź więc to, czym jest, i miejmy nadzieję, że komuś pomoże!