2015-12-04 22 views
5

Ho problemi con il rilevamento coerente dei servizi utilizzando EC2, AWS, Docker, Consul-Template, Consul e NGINX.NGINX & Consul-Template in Docker

Possiedo più servizi, ciascuno in esecuzione sulla propria istanza EC2. Su questi casi corro seguenti contenitori (in questo ordine):

  • cAdvisor (monitoraggio)
  • nodo-esportatore (monitoraggio)
  • Console (esecuzione in modalità agent)
  • Registrator
  • Il mio servizio
  • contenitore
  • personalizzato in esecuzione sia nginx e console-template

Il contenitore personalizzato ha la seguente Dockerfile:

FROM nginx:1.9 

#Install Curl 
RUN apt-get update -qq && apt-get -y install curl 

#Install Consul Template 
RUN curl -L https://github.com/hashicorp/consul-template/releases/download/v0.10.0/consul-template_0.10.0_linux_amd64.tar.gz | tar -C /usr/local/bin --strip-components 1 -zxf - 

#Setup Consul Template Files 
RUN mkdir /etc/consul-templates 
COPY ./app.conf.tmpl /etc/consul-templates/app.conf 

# Remove all other conf files from nginx 
RUN rm /etc/nginx/conf.d/* 

#Default Variables 
ENV CONSUL consul:8500 

CMD /usr/sbin/nginx -c /etc/nginx/nginx.conf && consul-template -consul=$CONSUL -template "/etc/consul-templates/app.conf:/etc/nginx/conf.d/app.conf:/usr/sbin/nginx -s reload" 

Il file app.conf assomiglia a questo:

{{range services}} 
    upstream {{.Name}} { 
    least_conn;{{range service .Name}} 
    server {{.Address}}:{{.Port}};{{end}} 
    } 
{{end}} 

server { 
    listen 80 default_server; 
    proxy_set_header   Host $host; 
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for; 

    location/{ 
    proxy_pass http://cart/cart/; 
    } 

    location /cart { 
    proxy_pass http://cart/cart; 
    } 

    {{range services}} 
    location /api/{{.Name}} { 
    proxy_read_timeout 180; 
    proxy_pass http://{{.Name}}/{{.Name}}; 
    } 
    {{end}} 
} 

Tutto sembra avviarsi perfettamente ok, ma ad un certo punto (che io sono ancora per identificare) dopo l'avvio, consul-template sembra restituire che non ci sono server disponibili per un particolare servizio. Ciò significa che la sezione upstream per tale servizio contiene alcun server, e io alla fine con questo nei ceppi:

2015/12/04 07:09:34 [emerg] 77#77: no servers are inside upstream in /etc/nginx/conf.d/app.conf:336 
nginx: [emerg] no servers are inside upstream in /etc/nginx/conf.d/app.conf:336 
2015/12/04 07:09:34 [ERR] (runner) error running command: exit status 1 
Consul Template returned errors: 
1 error(s) occurred: 

* exit status 1 
2015/12/04 07:09:34 [DEBUG] (logging) setting up logging 
2015/12/04 07:09:34 [DEBUG] (logging) config: 

{ 
    "name": "consul-template", 
    "level": "WARN", 
    "syslog": false, 
    "syslog_facility": "LOCAL0" 
} 

2015/12/04 07:09:34 [emerg] 7#7: no servers are inside upstream in /etc/nginx/conf.d/app.conf:336 
nginx: [emerg] no servers are inside upstream in /etc/nginx/conf.d/app.conf:336 

Dopo questo, Nginx non accetterà più richieste.

Sono sicuro che mi manca qualcosa di ovvio, ma mi sono legato a nodi mentali sulla sequenza di eventi ecc. Quello che penso potrebbe accadere è che NGINX si blocca, ma perché consul-template è ancora in esecuzione , il contenitore Docker non si riavvia. In realtà non mi interessa se il contenitore si riavvia, o se solo NGINX si riavvia.

Qualcuno può aiutare?

risposta

6

Il modello di console uscirà quando lo script viene eseguito dopo la scrittura restituisce un codice di uscita diverso da zero. See here for the documentation.

La documentazione suggerisce di inserire un || true subito dopo il comando di riavvio (o ricarica). Ciò manterrà il modello di console in esecuzione indipendente dal codice di uscita.

Si potrebbe considerare di avvolgere il riavvio nel proprio script di shell che prima verifica la configurazione (con nginx -t) prima di attivare una ricarica. Si potrebbe anche spostare l'avvio iniziale di nginx in questo script, poiché è logico iniziare nginx una volta che è stata scritta la prima configurazione (valida) ?!

+0

Così '' '' '' '' '' Effettivamente esegue un controllo di convalida sulla configurazione a cui viene chiesto di ricaricare, e se la convalida fallisce, si rifiuta di eseguire una ricarica? Se è così, questo potrebbe aiutare. – Will

+0

'-t' convaliderà solo la configurazione. 'ricarica 'per prima cosa testerà la configurazione e, in caso di successo, ricaricherà la configurazione - vedi https://www.nginx.com/resources/wiki/start/topics/tutorials/commandline/. – ahus1

+0

Ok, quindi se aggiungo il || vero, questo fermerà il modello di console dall'uscita, e quindi presumibilmente manterrà il contenitore in esecuzione. Tuttavia, se Nginx si è arrestato in modo anomalo/chiuso, ricaricare non avrà alcun effetto, correggere? Oppure, il comando di ricarica sta restituendo 1, mentre Nginx continua a funzionare, ma il modello di console è uscito? – Will