2016-06-04 60 views
7

C'è l'famous issue con l'incubo e l'elettrone non funziona su server Linux senza testa. Il electron docs ufficiale suggerisce di usare xvfb per simulare il display. Suggeriscono di usare questo file .yml per travis.Come eseguire nightmare.js su google appengine per node.js

 
addons: 
    apt: 
    packages: 
     - xvfb 

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

Domanda

Come posso usare il pezzo di codice sopra in app.yaml di file di Google AppEngine per node.js. Ho provato a utilizzare questo come è, ma glcoud genera un errore che il comando addon non è valido. Il divario official docs non ha alcun comando simile.

Qualche suggerimento su come possiamo eseguire l'incubo e l'elettrone su google appengine per node.js ..?

risposta

12

Ci sono due parti relativi a questa domanda:

  1. Esecuzione di cromo (quello di elettroni e, a loro volta, da incubo "usi") headlessly su Linux.
  2. Installa/Utilizza xvfb per eseguire chromium sul motore dell'app.

Parte 1)

devi Xvfb.

Xvfb (Virtual Framebuffer) è solo un programma che, da wiki: "è un server di visualizzazione che implementa il protocollo del server di visualizzazione X11. Contrariamente ad altri server di visualizzazione, Xvfb esegue tutte le operazioni grafiche in memoria senza mostrare alcun output di schermo. "

Quale è ciò che è necessario per eseguire un browser senza un'uscita schermo.

Prima di tutto, installa tutti i pacchetti relativi a xvfb per eseguirlo su linux.

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

Quindi, con Xvfb installato è necessario creare uno schermo virtuale e Xvfb esportare una chiamata DISPLAY variabile di ambiente che punta ad esso. Chromium in Electron cercherà automaticamente $ DISPLAY.

Quanto sopra può essere fatto più facilmente. Qui ci sono due opzioni:

  • Richiamo del programma con linux cli (ignorare gli avvertimenti Xvfb se lo script incubo funziona bene):

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

    • Se si utilizzano funzionalità di rendering come la cattura di schermate: xvfb-run -a --server-args="-screen 0 1280x1028x24 -ac +extension GLX +extension RANDR +render" node app.js. Google le opzioni xvfb per adattarsi ai tuoi gusti.

  • di programmazione: usando xvfb npm package

Da questo punto in poi si dovrebbe essere in grado di eseguire incubo su linux.

Parte 2)

Nodejs su App Engine è gestito attraverso l'ambiente flessibile. Significato, attraverso i contenitori docker.

Dal runtime di GAE nodejs: "Se l'applicazione richiede ulteriori dipendenze a livello di sistema operativo, per installare i pacchetti appropriati sarà necessario utilizzare un runtime personalizzato basato su questo runtime."

Docker è un intero argomento a parte, ma per fare quanto sopra con il motore di applicazione si hanno due opzioni per quanto ne so:

  1. Extending the runtime

  2. Usa GAE con un custom runtime da graffiare.

In entrambi i casi, in pratica quello che si avrebbe bisogno di fare è installare i pacchetti relativi Xvfb li definiscono nel dockerfile e che dovrebbe fare il trucco.

Buona fortuna!

Note importanti:

  1. È possibile che questo apt-get pacchetti dipendono dalla disponibilità per quanto riguarda la distribuzione Linux (il codice precedente funziona su Ubuntu e Debian). Ad esempio, con il set di pacchetti specificato e al momento di questo post, funzionerà con l'ambiente flessibile di GAE poiché è basato su debian jessie e non funzionerà su linux alpha.

  2. Chromium richiede un'assegnazione minima dev/shm per funzionare correttamente. Ad esempio, su heroku è fissato a 5mb e non c'è modo di cambiarlo. Chromium si bloccherà dopo alcune azioni da incubo. Quindi il cromo non funzionerà su qualsiasi dinamo di heroku di qualsiasi dimensione. In docker è impostato su 64 MB, quindi a seconda della complessità del tuo script andrà bene o sarà necessario regolarlo. Nelle installazioni linux semplici, dev/shm è normalmente impostato su metà della memoria disponibile totale. Quindi, in un ambiente 512mb, dev/shm sarà impostato su 256mb e l'incubo funzionerà molto probabilmente.

+0

Vale la pena notare che NON è possibile modificare/dev/shm su appengine. –

2

Grazie a @rickmed per la sua risposta completa! Mi ha aiutato a iniziare a capire come usare xvfb in questo contesto. (https://stackoverflow.com/a/37663861/562915)

Sto utilizzando Nightmare per generare PDF da un endpoint. Il mio dev locale è fatto su OSX e ho avuto questo problema mentre cercavo di farlo funzionare su Google App Engine. Ho iniziato a funzionare inizialmente con la risposta di rickmed e da allora ho trovato un altro modo per evitare il Dockerfile/runtime personalizzato. Ho pensato di condividerlo qui.

Non sto utilizzando un Dockerfile personalizzato e consento a gcloud di generarne uno durante la distribuzione. Il mio file yaml utilizza runtime: nodejs. Per il mio semplice utilizzo di Nightmare sono in grado di aggiungere uno script di preinstallazione al mio package.json e aggiornare lo script di avvio. Questo è tutto ciò di cui ho bisogno per far funzionare l'incubo su GAE. Ecco le righe pertinenti dal mio pacchetto.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", 
    ... 
    }, 
    ... 
} 

ho tirato il set semplificato di apt-get i pacchetti installati dal commento di otaviomedeiros: https://github.com/segmentio/nightmare/issues/224#issuecomment-225887320

ho avuto l'idea da utili articolo di Daishi Kato: https://medium.com/google-cloud/how-to-use-phantomjs-with-node-js-on-google-app-engine-6f7feaea551#.6eoyvpn93 e Questa responsabilità è incluso in questo articolo:

Sebbene la seguente procedura funzioni bene come per la scrittura, ciò non significa che funzionerà a lungo. Non sono nemmeno sicuro se è raccomandato. Per favore, comprendi il rischio.

Quindi prendi questo per quello che è, e speriamo che possa aiutare qualcuno!