2015-03-11 17 views

Odpowiedz

14

Można zrobić jak stwierdzono w tym bilecie: https://github.com/Unitech/pm2/issues/13

Choć jeśli jesteś przejazdem środowiska może warto rozważyć wykorzystanie zmiennych środowiskowych. W ten sposób tworzysz zmienną, do której dostęp ma każdy proces w tym środowisku z process.env.*.

Więc masz plik konfiguracyjny config.json:

{ 
    "dev": { 
     "db": { 
      "hosts":["localhost"], 
      "database": "api" 
     }, 
     "redis": { 
      "hosts": ["localhost"] 
     } 
    }, 
    "staging": { 
     "db": { 
      "hosts":["1.1.1.1"], 
      "database": "api" 
     }, 
     "redis": { 
      "hosts": ["2.2.2.2"] 
     } 
    }, 
    "production": { 
     "db": { 
      "hosts":["1.1.1.1", "1.1.1.2", "1.1.1.3"], 
      "database": "api" 
     }, 
     "redis": { 
      "hosts": ["2.2.2.2", "2.2.2.3"] 
     } 
    } 
} 

Następnie należy zaimportować config:

var config=require('./config.json')[process.env.NODE_ENV || 'dev']; 

db.connect(config.db.hosts, config.db.database); 

Potem ustawić zmienną w środowisku poprzez powłoki:

export NODE_ENV=staging 
pm2 start app.js 

Zmienna środowiskowa będzie trwać tak długo, jak sesja. Musisz więc ustawić go w pliku ~/.bashrc dla tego użytkownika, aby zmienna pozostała. Ustawi to zmienną w każdej sesji.

PM2 ma deploy system, która pozwala na ustawienie zmiennej środowiskowej za każdym razem, zanim zostanie ona dememizowana. W ten sposób demony w systemach POSIX zwykle przyjmują parametry, ponieważ te parametry nie są tracone w procesie. Biorąc pod uwagę twoje okoliczności, może to nie mieć większego znaczenia, ale jest dobrą praktyką.

Co więcej, w miarę możliwości należy rozważyć zatrzymanie/uruchomienie i ponowne uruchomienie (w trybie klastra), aby zapobiec przestojom w produkcji.

+0

Ustawiłem to za pomocą AWS Code Deploy i mojej aplikacji Node.JS i działa to cudownie. Używam portu 4040 lokalnie, a 80 na AWS. Jest to eleganckie rozwiązanie zapewniające poprawne skonfigurowanie portów. Dziękuję Ci! – BuffMcBigHuge

54

Jeśli chcesz przekazać argumenty węzła z CLI następnie

pm2 start myServer.js --node-args="--production --port=1337" 

.

Edited

można dodawać żadnych argumentów po -x --

pm2 start app.js -x -- --prod 

Sails docs dla deploymemt.

+1

To jest dobre. Ale kiedy przekazać go do Docker, to nie działa. Czy ktoś może mi pomóc. . ENTRYPOINT ["pm2"] CMD ["start", "msg/myServer.js", "--node-args = '- firstarg" "," - no-daemon "] –

+0

@RajRajen: Jeśli" Ponowne korzystanie z dockera Czuję, że prowadzenie PM2 nie jest najlepszą opcją. Docker niech monitoruje twoją aplikację i używaj jej zasad restartowania, aby utrzymać swoją aplikację przy życiu, lub użyj czegoś w rodzaju nadzorcy, aby Twój kontener nie musiał się restartować za każdym razem, gdy twoja aplikacja przestała działać. Po uruchomieniu PM2 w oknie dokowanym traci się wiele przydatnych funkcji PM2, a wszystko, co naprawdę robi, to utrzymywanie aplikacji przy życiu. W tym momencie używanie systemu na czas nieokreślony lub systemu inicjującego byłoby równie dobre i prawdopodobnie byłoby łatwiejsze. Supervisord jest niezwykle powszechny w przypadku kontenerów w doku obsługujących więcej niż jedną usługę na kontener. – tsturzl

+2

Dla docker można użyć dedykowanego polecenia PM2, pm2-docker. Więcej informacji tutaj: http://pm2.keymetrics.io/docs/usage/docker-pm2-nodejs/ – Unitech

0

Dobrze istnieją 2 sposoby można zrobić przekazać parametry z PM2 do nodejs w CLI:

  • PM2 rozpocząć app.js - dev --port = 1234 (nota jest dodatkowa przestrzeń między - i dev)
  • aplikacja startowa pm2.js --node-args = "dev --port = 1234"

obie strony, znajdziesz te wartości istnieją w process.argv ([dev '', '- port = 1234'])

0

z pm2 docs

//Inject what is declared in env_production 
$ pm2 start app.js --env production 

//Inject what is declared in env_staging 
$ pm2 restart app.js --env staging 
3

możliwe jest zdefiniowanie argumentów z procesem.

Można zdefiniować nowy proces w ecosystem.config.js z kluczem args, tak:

{ 
    name   : 'my-service', 
    script   : './src/service.js', 
    args   : 'firstArg secondArg', 
}, 
{ 
    name   : 'my-service-alternate', 
    script   : './src/service.js', 
    args   : 'altFirstArg altSecondArg', 
} 

Tutaj oba procesy korzystają z tego samego pliku (service.js), ale przechodzą różne argumenty do niego.

Należy zauważyć, że te argumenty są obsługiwane w ramach service.js. W moim przypadku użyłem tylko process.argv[2], aby uzyskać pierwszy argument, i tak dalej.

Powiązane problemy