2015-03-24 16 views
10

Sono in procinto di tentare di containerizzare il nostro ambiente di sviluppo con la finestra mobile. Ciò include un mix di progetti Google Appengine e servizi eventualmente ospitati nel motore di Google Compute all'interno di un contenitore vm.Docker Componi il contenitore circolare che collega

Il nostro ambiente di sviluppo corrente script di avvio porta elasticsearch e nginx in boot2docker e le altre applicazioni eseguite su localhost: {porta prodotto} all'interno della sandbox appengine dev_appserver. Questo processo si sta dimostrando difficile da gestire e da mantenere, poiché richiede molte informazioni su come comunicano le nostre applicazioni.

Viene visualizzato un errore con la finestra mobile-compose che rileva una dipendenza circolare tra i contenitori.

Importazione circolare tra cs e vbc e aa e sr.

Poiché questa configurazione è solo per ambienti di sviluppo (mac osx), chiunque ha suggerimenti o idee su un approccio diverso da adottare quando si collegano insieme tutte le dipendenze delle suite del prodotto.

Una porzione di finestra mobile-compose.yml:

elasticsearch: 
    build: ./compute/containers/elasticsearch/elasticsearch 
    ports: 
    - "9200:9200" 
    environment: 
    - PROJECT_ID=localhost 
nginx: 
    build: ./compute/containers/elasticsearch/nginx 
    links: 
    - elasticsearch:localhost 
    ports: 
    - "9201:9201" 
cs: 
    build: ./CS 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8080 --admin_port=9080 --storage_path=/data/ 
    ports: 
    - "8080:8080" 
    - "9080:9080" 
    volumes: 
    - /Users/source/CS/src:/src 
    - /Users/source/CS/data:/data 
aa: 
    build: ./AA 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8081 --admin_port=9081 --storage_path=/data/ 
    links: 
    - vbc:vbc-local 
    - st:st-local 
    - elasticsearch:localhost  
    ports: 
    - "8081:8081" 
    - "9081:9081" 
    volumes: 
    - /Users/source/AA/src:/src 
    - /Users/source/AA/data:/data 
vbc: 
    image: google/cloud-sdk 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8082 --admin_port=9082 --storage_path=/data/ 
    links: 
    - cs:cs-local 
    - sr:sr-local 
    - sm:sm-local 
    - ms:ms-local 
    - st:st-local  
    - cis:cis-local 
    - elasticsearch:localhost 
    ports: 
    - "8082:8082" 
    - "9082:9082" 
    volumes: 
    - /Users/source/VBC/src:/src 
    - /Users/source/VBC/data:/data  
sr: 
    build: ./SR 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8083 --admin_port=9083 --storage_path=/data/ 
    links: 
    - cs:cs-local 
    - aa:aa-local  
    ports: 
    - "8083:8083" 
    - "9083:9083" 
    volumes: 
    - /Users/source/SR/src:/src 
    - /Users/source/SR/data:/data 
+2

si potrebbe considerare l'utilizzo di un servizio di registro come console https://github.com/progrium/docker-consul e un registratore automatico per i contenitori come https://registry.hub.docker.com/u/progrium/registrator/. Con questi componenti è possibile registrare i propri contenitori in console e ogni contenitore dovrebbe leggere le informazioni necessarie dal console, eliminando le dipendenze circolari. Tuttavia aggiunge più complessità. – christian

risposta

8

Dovresti essere in grado di utilizzare presto la seguente soluzione.

Il collegamento circolare viene fissato in PR # 1676

This è come stanno affrontando il problema. In poche parole, renderanno i contenitori in grado di parlare tra loro senza collegamento. Ho aggiunto gli aggiornamenti della documentazione Docker Componi di seguito:

Networking in Compose

Per impostazione predefinita, Componi imposta una singola rete di default per la vostra applicazione. Ogni contenitore per un servizio si unisce alla rete predefinita ed è individuabile tramite DNS sotto il nome del servizio.

Nota: rete della tua app viene dato lo stesso nome come il "nome di progetto", che si basa sul nome della directory in cui vive Vedere la documentazione CLI per procedure per ignorarlo..

Ad esempio, supponiamo che la vostra applicazione è in una directory chiamata myapp, e la vostra docker-compose.yml si presenta così:

web: 
    build: . 
    ports: 
    - "8000:8000" 
db: 
    image: postgres 

Quando si esegue docker-compose up, accade quanto segue:

  1. Una rete chiamato myapp viene creato.
  2. Un contenitore viene creato utilizzando la configurazione di web. Si unisce alla rete myapp con il nome web.
  3. Un contenitore viene creato utilizzando la configurazione di db. Si unisce alla rete myapp con il nome db.

Ogni contenitore può ora cercare il nome host web o db e recuperare l'indirizzo IP del contenitore appropriato. Ad esempio, il codice dell'applicazione web potrebbe connettersi all'URL postgres://db:5432 e iniziare a utilizzare il database Postgres.

Poiché web associa esplicitamente una porta, è anche accessibile dal mondo esterno tramite la porta 8000 sull'interfaccia di rete dell'host del Docker.

ulteriore lettura sul sperimentale API di rete Docker: https://github.com/docker/docker/blob/master/experimental/networking_api.md

+2

Fantastico, non vedo l'ora di provarlo! – Jesse

0

è nel vostro collegamento:

sr requires aa 
aa requires vbc 
vbc requires sr 
sr requires aa 

sr requires cs 
sr requires vbc 
vbc requires sr 
vbc requires cs 

si può vedere come questo è circolare.

+0

Sì, sono a conoscenza di questo problema a causa del collegamento. Tuttavia, nel mio singolo file di composizione docker per "domarli tutti" per l'ambiente di sviluppo, questo è un male desiderato. L'intento della domanda era di capire come realizzarlo. – Jesse

+0

Perché vuoi collegarli insieme? È per la comunicazione? Se è così, allora hai diverse opzioni: 1. contenitori ambasciatore 2. proxy in mezzo (preferisco questo personalmente) 3. diversi altri progetti che tentano di collegare contenitori remoti. – Michael

2

Ora con v2 definizione file docker-composizione, tutti i servizi sono disponibili tra di loro, senza la necessità di una sezione di collegamento.

È possibile effettuare direttamente una richiesta al nome del servizio da tutti a tutti (incluso un servizio a sé stante). Quindi se volevi fare una richiesta da cs a vbc, ti basta curl vbc.

È anche possibile definire un servizio con un nome di dominio personalizzato che dichiara una chiave hostname nella sezione di servizio del file di composizione.

Se volete vedere di più, l'API di rete non è più sperimentale: https://github.com/docker/compose/blob/master/docs/networking.md

Questo è il file finestra mobile-composizione in v2, senza link inutili:

version: '2' 

services: 
    elasticsearch: 
    build: ./compute/containers/elasticsearch/elasticsearch 
    ports: 
     - "9200:9200" 
    environment: 
     - PROJECT_ID=localhost 
    nginx: 
    build: ./compute/containers/elasticsearch/nginx 
    ports: 
     - "9201:9201" 
    cs: 
    build: ./CS 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8080 --admin_port=9080 --storage_path=/data/ 
    ports: 
     - "8080:8080" 
     - "9080:9080" 
    volumes: 
    - /Users/source/CS/src:/src 
    - /Users/source/CS/data:/data 
    aa: 
    build: ./AA 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8081 --admin_port=9081 --storage_path=/data/ 
    ports: 
     - "8081:8081" 
     - "9081:9081" 
    volumes: 
    - /Users/source/AA/src:/src 
    - /Users/source/AA/data:/data 
    vbc: 
    image: google/cloud-sdk 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8082 --admin_port=9082 --storage_path=/data/ 
    ports: 
     - "8082:8082" 
     - "9082:9082" 
    volumes: 
    - /Users/source/VBC/src:/src 
    - /Users/source/VBC/data:/data  
    sr: 
    build: ./SR 
    command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8083 --admin_port=9083 --storage_path=/data/ 
    ports: 
     - "8083:8083" 
     - "9083:9083" 
    volumes: 
    - /Users/source/SR/src:/src 
    - /Users/source/SR/data:/data