2015-05-05 14 views

risposta

361

capito, utilizzare bash -c.

Esempio:

command: bash -c "python manage.py migrate && python manage.py runserver 0.0.0.0:8000" 

Stesso esempio in multilinee:

command: > 
    bash -c "python manage.py migrate 
    && python manage.py runserver 0.0.0.0:8000" 
+0

non ha funzionato per me. – Pedram

+0

@Pedram stai usando il formato della versione 2 di docker-compose? – ecoding5

+1

@ ecoding5 Sì, sto usando la versione 2 – Pedram

14

Un'altra idea:

Se, come in questo caso, si costruisce il contenitore è sufficiente posizionare uno script di avvio in esso e eseguilo con il comando. O montare lo script di avvio come volume.

+0

Sì, anche questo funziona! –

+0

Sì, alla fine ho creato uno script run.sh: '' '#!/Bin/bash \ n python manage.py migrate \ n python manage.py runserver 0.0.0.0: 8000''' (brutto oneline) – fero

79

corro roba pre-startup come le migrazioni in un contenitore effimera separata, in questo modo (si noti, file di comporre deve essere di versione '2' tipo):

db: 
    image: postgres 
web: 
    image: app 
    command: python manage.py runserver 0.0.0.0:8000 
    volumes: 
    - .:/code 
    ports: 
    - "8000:8000" 
    links: 
    - db 
    depends_on: 
    - migration 
migration: 
    build: . 
    image: app 
    command: python manage.py migrate 
    volumes: 
    - .:/code 
    links: 
    - db 
    depends_on: 
    - db 

Questo aiuta le cose mantenere puliti e separati . Due cose da considerare:

  1. È necessario garantire la sequenza di avvio corretta (usando depends_on)

  2. si vuole evitare multipla costruisce che si ottiene dalla codifica è la prima volta che giro con la costruzione e l'immagine; è possibile fare riferimento all'immagine in altri contenitori poi

+1

Questa mi sembra la migliore opzione, e mi piacerebbe usarla. Puoi approfondire la configurazione dei tag per evitare più build? Preferirei evitare passaggi aggiuntivi, quindi se questo ne ha bisogno, potrei andare con 'bash -c' sopra. –

+0

Nella yaml sopra, la generazione e l'etichettatura avvengono nella sezione di migrazione. Non è davvero ovvio a prima vista, ma i tag di composizione docker lo fanno quando si specificano le proprietà di build AND image - per cui la proprietà dell'immagine specifica il tag per quella build. Questo può quindi essere usato successivamente senza attivare una nuova build (se si guarda al web, si vede che non ha build ma solo una proprietà dell'immagine). Ecco alcuni dettagli in più https://docs.docker.com/compose/compose-file/) –

+0

Questo è molto istruttivo (e l'ho assolutamente perso nei documenti), grazie. –

1

Utilizzare uno strumento come wait-for-it o dockerize. Questi sono piccoli script wrapper che puoi includere nell'immagine dell'applicazione. Oppure scrivi il tuo script di wrapper per eseguire comandi più specifici per l'applicazione. secondo: https://docs.docker.com/compose/startup-order/

9

È possibile utilizzare entrypoint qui. entrypoint nella finestra mobile viene eseguito prima del comando mentre il comando è il comando predefinito che deve essere eseguito all'avvio del contenitore. Quindi la maggior parte delle applicazioni generalmente esegue la procedura di configurazione in un file di punti di accesso e nell'ultima che consentono l'esecuzione del comando.

fare un file di script di shell può essere come docker-entrypoint.sh (nome non importa) con il seguente contenuto in esso.

#!/bin/bash 
python manage.py migrate 
exec "[email protected]" 

nel file di finestra mobile-compose.yml utilizzarlo con entrypoint: /docker-entrypoint.sh e registrare comando come command: python manage.py runserver 0.0.0.0:8000 P.S: non dimenticate di copiare docker-entrypoint.sh con il vostro codice.

-5

provare a utilizzare ";" per separare i comandi se sei in versione due ad es.

command: "sleep 20; echo 'a'"

-1

Anche se questo non è del tutto pertinente alla questione, la pubblicazione qui in caso aiuta qualcuno. Se si desidera eseguire un comando prima di avviare il contenitore, è possibile eseguire normalmente il contenitore. Quindi accedi al contenitore e apporta le modifiche. È quindi possibile impegnare il contenitore come una nuova immagine. Questa nuova immagine può essere utilizzata per garantire che tutte le modifiche necessarie esistano prima di avviare il contenitore.

Problemi correlati