Come posso includere file al di fuori del contesto di compilazione di Docker usando il comando "AGGIUNGI" nel file Docker?

Dalla documentazione Docker:

Il percorso deve essere all'interno del contesto della build; non puoi AGGIUNGERE ../something/something, perché il primo passo di una build docker è inviare la directory di contesto (e le sottodirectory) al demone docker.

Non voglio ristrutturare il mio intero progetto solo per accogliere Docker in questa materia. Voglio mantenere tutti i miei file Docker nella stessa sottodirectory.

Inoltre, sembra che Docker non supporti ancora (e potrebbe non mai) i collegamenti simbolici: il comando ADD Dockerfile non segue i collegamenti simbolici sull'host # 1676.

L'unica altra cosa a cui riesco a pensare è quella di includere un passaggio di pre-compilazione per copiare i file nel contesto di compilazione Docker (e configurare il mio controllo versione per ignorare quei file). C'è una soluzione migliore per quella?

Il modo migliore per aggirare questo problema è specificare il Dockerfile indipendentemente dal contesto di compilazione, usando -f.

Ad esempio, questo comando darà al comando ADD l'accesso a qualsiasi cosa nella directory corrente.

docker build -f docker-files/Dockerfile .

Aggiornamento : Docker ora consente di disporre del file Docker al di fuori del contesto di compilazione (risolto in 18.03.0-ce, https://github.com/docker/cli/pull/886 ). Quindi puoi anche fare qualcosa del genere

docker build -f ../Dockerfile .

Mi trovo spesso a utilizzare l' --build-argopzione per questo scopo. Ad esempio dopo aver inserito quanto segue nel Dockerfile:

ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa

Puoi semplicemente fare:

docker build -t some-app --build-arg SSH_KEY="$(cat ~/file/outside/build/context/id_rsa)" .

Ma nota il seguente avviso dalla documentazione Docker :

Avvertenza: non è consigliabile utilizzare le variabili del tempo di costruzione per il passaggio di segreti come chiavi github, credenziali utente ecc. I valori delle variabili del tempo di costruzione sono visibili a qualsiasi utente dell'immagine con il comando cronologia finestra mobile.

Su Linux puoi montare altre directory invece di collegarle simbolicamente

mount --bind olddir newdir

Vedi /superuser/842642 per maggiori dettagli.

Non so se qualcosa di simile è disponibile per altri sistemi operativi. Ho anche provato a usare Samba per condividere una cartella e rimontarla nel contesto Docker che ha funzionato.

Ho trascorso un buon tempo cercando di capire un buon modello e come spiegare meglio cosa sta succedendo con questo supporto per le funzionalità. Mi sono reso conto che il modo migliore per spiegarlo era il seguente ...

• Dockerfile: vedrà solo i file nel proprio percorso relativo
• Contesto: un posto nello "spazio" in cui verranno copiati i file che si desidera condividere e il Dockerfile

Quindi, detto questo, ecco un esempio del Dockerfile che deve riutilizzare un file chiamato start.sh

Dockerfile

Si ALWAYScaricherà dal suo percorso relativo, avendo la directory corrente di se stesso come il localriferimento ai percorsi specificati.

COPY start.sh /runtime/start.sh

File

Considerando questa idea, possiamo pensare di avere più copie per i Dockerfile che costruiscono cose specifiche, ma tutti hanno bisogno dell'accesso a start.sh.

./all-services/
   /start.sh
   /service-X/Dockerfile
   /service-Y/Dockerfile
   /service-Z/Dockerfile
./docker-compose.yaml

Considerando questa struttura e i file sopra, ecco un docker-compose.yml

finestra mobile-compose.yaml

• In questo esempio, la shareddirectory di contesto è la runtimedirectory.
  • Lo stesso modello mentale qui, pensa che tutti i file sotto questa dir vengono spostati sul cosiddetto context.
  • Allo stesso modo, basta specificare il Dockerfile che si desidera copiare nella stessa directory. Puoi specificarlo usando dockerfile.
• la directory in cui si trova il contenuto principale è il contesto effettivo da impostare.

Il docker-compose.ymlè il seguente

version: "3.3"
services:

  service-A
    build:
      context: ./all-service
      dockerfile: ./service-A/Dockerfile

  service-B
    build:
      context: ./all-service
      dockerfile: ./service-B/Dockerfile

  service-C
    build:
      context: ./all-service
      dockerfile: ./service-C/Dockerfile

• all-serviceviene impostato come contesto, il file condiviso start.shviene copiato lì e anche il file Docker specificato da ciascuno dockerfile.
• Ognuno può essere costruito a modo suo, condividendo il file di avvio!

Saluti!

Se leggi la discussione nel numero 2745, non solo la finestra mobile potrebbe non supportare mai i collegamenti simbolici, ma potrebbe non supportare l'aggiunta di file al di fuori del tuo contesto. Sembra essere una filosofia di progettazione secondo cui i file che vanno nella build docker dovrebbero esplicitamente far parte del suo contesto o provenire da un URL in cui è presumibilmente distribuito anche con una versione fissa in modo che la build sia ripetibile con URL ben noti o file forniti con il contenitore docker.

Preferisco costruire da una fonte controllata dalla versione - cioè docker build -t stuff http://my.git.org/repo - altrimenti sto costruendo da un posto casuale con file casuali.

fondamentalmente no ... - SvenDowideit, Docker Inc

Solo la mia opinione, ma penso che dovresti ristrutturare per separare i repository di codice e docker. In questo modo i contenitori possono essere generici e inserire qualsiasi versione del codice in fase di esecuzione anziché in fase di compilazione.

In alternativa, utilizzare la finestra mobile come artefatto di distribuzione del codice fondamentale e quindi inserire il file docker nella radice del repository di codice. se segui questa strada probabilmente ha senso avere un contenitore docker principale per dettagli più generali a livello di sistema e un contenitore figlio per un'installazione specifica per il tuo codice.

Credo che la soluzione più semplice sarebbe quella di cambiare il "contesto" stesso.

Quindi, ad esempio, invece di dare:

docker build -t hello-demo-app .

che imposta la directory corrente come contesto, supponiamo che tu voglia la directory principale come contesto, basta usare:

docker build -t hello-demo-app ..

Puoi anche creare un tarball di ciò di cui l'immagine ha bisogno per prima e usarla come contesto.

https://docs.docker.com/engine/reference/commandline/build/#/tarball-contexts

Usando docker-compose, ho realizzato questo creando un servizio che monta i volumi di cui ho bisogno e commette l'immagine del contenitore. Quindi, nel servizio successivo, mi affido all'immagine precedentemente impegnata, che ha tutti i dati memorizzati in posizioni montate. Dovrai quindi copiare questi file nella loro destinazione finale, poiché le directory montate sull'host non vengono impegnate durante l'esecuzione di un docker commitcomando

Non è necessario utilizzare docker-compose per farlo, ma rende la vita un po 'più semplice

# docker-compose.yml

version: '3'
  services:
    stage:
      image: alpine
      volumes:
        - /host/machine/path:/tmp/container/path
      command: bash -c "cp -r /tmp/container/path /final/container/path"
    setup:
      image: stage

# setup.sh

# Start "stage" service
docker-compose up stage

# Commit changes to an image named "stage"
docker commit $(docker-compose ps -q stage) stage

# Start setup service off of stage image
docker-compose up setup

Ho avuto lo stesso problema con un progetto e alcuni file di dati che non sono stato in grado di spostare all'interno del contesto repository per motivi HIPPA. Ho finito per usare 2 Dockerfile. Uno crea l'applicazione principale senza le cose di cui avevo bisogno al di fuori del contenitore e le pubblica nel repository interno. Quindi un secondo file docker estrae quell'immagine e aggiunge i dati e crea una nuova immagine che viene quindi distribuita e mai archiviata da nessuna parte. Non è l'ideale, ma ha funzionato per i miei scopi di mantenere le informazioni sensibili fuori dal repository.

Una soluzione semplice potrebbe essere quella di montare semplicemente il volume (usando il flag -v o --mount) sul contenitore quando lo si esegue e si accede ai file in quel modo.

esempio:

docker run -v /path/to/file/on/host:/desired/path/to/file/in/container/ image_name

per maggiori informazioni: https://docs.docker.com/storage/volumes/

Come è descritto in questo problema di GitHub in cui si verifica effettivamente la compilazione /tmp/docker-12345, quindi un percorso relativo come ../relative-add/some-fileè relativo /tmp/docker-12345. Quindi cercherebbe /tmp/relative-add/some-file, che è anche mostrato nel messaggio di errore. *

Non è consentito includere file al di fuori della directory di compilazione, quindi questo porta al messaggio "Percorso proibito". "

Un modo rapido e sporco è impostare il contesto di costruzione su tutti i livelli di cui hai bisogno, ma ciò può avere conseguenze. Se lavori in un'architettura di microservizi simile a questa:

./Code/Repo1
./Code/Repo2
...

È possibile impostare il contesto di compilazione sulla Codedirectory principale e quindi accedere a tutto, ma si scopre che con un numero elevato di repository, ciò può comportare che la compilazione richieda molto tempo.

Una situazione di esempio potrebbe essere quella in cui un altro team mantiene uno schema del database Repo1e inserisce il codice del proprio teamRepo2 dipende da questo. Si desidera agganciare questa dipendenza con alcuni dei propri dati seed senza preoccuparsi delle modifiche dello schema o inquinare il repository dell'altro team (a seconda di quali cambiamenti si potrebbero ancora cambiare gli script dei dati seed ovviamente) Il secondo approccio è disordinato ma aggira il problema delle build lunghe:

Creare uno script sh (o ps1) ./Code/Repo2per copiare i file necessari e richiamare i comandi docker desiderati, ad esempio:

#!/bin/bash
rm -r ./db/schema
mkdir ./db/schema

cp  -r ../Repo1/db/schema ./db/schema

docker-compose -f docker-compose.yml down
docker container prune -f
docker-compose -f docker-compose.yml up --build

Nel file componi docker, imposta semplicemente il contesto come Repo2root e usa il contenuto della ./db/schemadirectory nel tuo file docker senza preoccuparti del percorso. Tenere presente che si corre il rischio di commettere accidentalmente questa directory sul controllo del codice sorgente, ma le azioni di pulizia dello scripting dovrebbero essere abbastanza facili.

Nel mio caso, il mio Dockerfile è scritto come un modello contenente segnaposto che sto sostituendo con un valore reale usando il mio file di configurazione.

Quindi non ho potuto specificare direttamente questo file ma inserirlo nella build docker in questo modo:

sed "s/%email_address%/$EMAIL_ADDRESS/;" ./Dockerfile | docker build -t katzda/bookings:latest . -f -;

Ma a causa della pipe, il COPYcomando non ha funzionato. Ma il modo precedente risolve -f -(dicendo esplicitamente il file non fornito). Facendo solo -senza la -fbandiera, il contesto E il Dockerfile non sono forniti, il che è un avvertimento.

Il trucco è riconoscere che puoi specificare il contesto nel comando build per includere i file dalla directory principale se specifichi il percorso Docker, cambierei il mio Dockerfile in questo modo:

...
COPY ./ /dest/
...

Quindi il mio comando build può apparire così:

docker built -t TAG -f DOCKER_FILE_PATH CONTEXT

Dalla directory del progetto

docker built -t username/project[:tag] -f ./docker/Dockerfile .

Dal progetto / finestra mobile

docker built -t username/project[:tag] -f ./docker/Dockerfile ..