Bagaimana saya bisa memasukkan file dari luar konteks pembangunan Docker menggunakan perintah "ADD" di file Docker?

Dari dokumentasi Docker:

Jalan harus berada di dalam konteks bangunan; Anda tidak dapat ADD ../something/something, karena langkah pertama pembuatan buruh pelabuhan adalah mengirim direktori konteks (dan subdirektori) ke daemon buruh pelabuhan.

Saya tidak ingin merestrukturisasi seluruh proyek saya hanya untuk mengakomodasi Docker dalam hal ini. Saya ingin menyimpan semua file Docker saya di sub-direktori yang sama.

Selain itu, tampaknya Docker belum (dan mungkin tidak pernah) mendukung symlink: Perintah ADD Dockerfile tidak mengikuti symlink pada host # 1676.

Satu-satunya hal lain yang dapat saya pikirkan adalah memasukkan langkah pra-bangun untuk menyalin file ke dalam konteks pembangunan Docker (dan mengonfigurasi kontrol versi saya untuk mengabaikan file-file itu). Apakah ada solusi yang lebih baik dari itu?

Cara terbaik untuk mengatasi ini adalah dengan menentukan Dockerfile secara independen dari konteks build, menggunakan -f.

Misalnya, perintah ini akan memberikan perintah ADD akses ke apa pun di direktori Anda saat ini.

docker build -f docker-files/Dockerfile .

Pembaruan : Docker sekarang memungkinkan Dockerfile berada di luar konteks build (diperbaiki pada 18.03.0-ce, https://github.com/docker/cli/pull/886 ). Jadi Anda juga bisa melakukan sesuatu seperti

docker build -f ../Dockerfile .

Saya sering mendapati diri saya menggunakan --build-argopsi untuk tujuan ini. Misalnya setelah meletakkan yang berikut di Dockerfile:

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

Anda bisa melakukannya:

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

Tetapi perhatikan peringatan berikut dari dokumentasi Docker :

Peringatan: Tidak disarankan untuk menggunakan variabel build-time untuk meneruskan rahasia seperti kunci github, kredensial pengguna, dll. Nilai variabel build-time terlihat oleh setiap pengguna gambar dengan perintah history docker.

Di Linux Anda dapat memasang direktori lain alih-alih menghubungkannya

mount --bind olddir newdir

Lihat /superuser/842642 untuk lebih jelasnya.

Saya tidak tahu apakah sesuatu yang serupa tersedia untuk OS lain. Saya juga mencoba menggunakan Samba untuk berbagi folder dan mengirimnya kembali ke dalam konteks Docker yang berfungsi juga.

Saya menghabiskan waktu yang baik untuk mencari tahu pola yang baik dan bagaimana menjelaskan dengan lebih baik apa yang terjadi dengan dukungan fitur ini. Saya menyadari bahwa cara terbaik untuk menjelaskannya adalah sebagai berikut ...

• Dockerfile: Hanya akan melihat file di bawah jalur relatifnya sendiri
• Konteks: tempat di "spasi" tempat file yang ingin Anda bagikan dan Dockerfile Anda akan disalin

Jadi, dengan itu, inilah contoh Dockerfile yang perlu menggunakan kembali file yang disebut start.sh

Dockerfile

Ini ALWAYSakan memuat dari jalur relatifnya, memiliki dir saat ini sendiri sebagai localreferensi ke jalur yang Anda tentukan.

COPY start.sh /runtime/start.sh

File

Mempertimbangkan gagasan ini, kita dapat berpikir memiliki banyak salinan untuk Dockerfiles membangun hal-hal tertentu, tetapi mereka semua memerlukan akses ke start.sh.

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

Mempertimbangkan struktur ini dan file-file di atas, inilah docker-compose.yml

docker-compose.yaml

• Dalam contoh ini, shareddir konteks Anda adalahruntime dir.
  • Model mental yang sama di sini, berpikir bahwa semua file di bawah dir ini dipindahkan ke yang disebut context .
  • Demikian pula, tentukan saja Dockerfile yang ingin Anda salin ke dir yang sama. Anda dapat menentukan itu menggunakan dockerfile.
• direktori tempat konten utama Anda berada adalah konteks aktual yang akan ditetapkan.

The docker-compose.ymladalah sebagai berikut

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-servicediatur sebagai konteks, file bersama start.shdisalin di sana serta Dockerfile ditentukan oleh masing-masingdockerfile .
• Masing-masing dapat dibangun dengan caranya sendiri, berbagi file awal!

Bersulang!

Jika Anda membaca diskusi dalam masalah 2745 tidak hanya buruh pelabuhan mungkin tidak pernah mendukung symlinks mereka mungkin tidak pernah mendukung penambahan file di luar konteks Anda. Tampaknya menjadi filosofi desain bahwa file yang masuk ke bangunan buruh pelabuhan harus secara eksplisit menjadi bagian dari konteksnya atau berasal dari URL yang mungkin juga digunakan dengan versi tetap sehingga pembuatannya dapat diulang dengan URL atau file terkenal yang dikirimkan bersama wadah buruh pelabuhan.

Saya lebih suka membangun dari sumber versi terkontrol - yaitu buruh pelabuhan -t hal-hal http://my.git.org/repo - kalau tidak saya membangun dari beberapa tempat acak dengan file acak.

pada dasarnya, tidak .... - SvenDowideit, Docker Inc

Hanya pendapat saya tapi saya pikir Anda harus merestrukturisasi untuk memisahkan kode dan repositori buruh pelabuhan. Dengan cara itu wadah bisa menjadi generik dan menarik versi kode apa pun pada saat dijalankan daripada membangun waktu.

Atau, gunakan buruh pelabuhan sebagai artefak penyebaran kode dasar Anda dan kemudian Anda letakkan buruh pelabuhan di root repositori kode. jika Anda menggunakan rute ini mungkin masuk akal untuk memiliki container docker induk untuk detail level sistem yang lebih umum dan container anak untuk pengaturan khusus untuk kode Anda.

Saya percaya solusi yang lebih sederhana adalah mengubah 'konteks' itu sendiri.

Jadi, misalnya, alih-alih memberi:

docker build -t hello-demo-app .

yang menetapkan direktori saat ini sebagai konteks, katakanlah Anda menginginkan direktori induk sebagai konteks, cukup gunakan:

docker build -t hello-demo-app ..

Anda juga dapat membuat tarball dari apa yang dibutuhkan gambar terlebih dahulu dan menggunakannya sebagai konteks Anda.

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

Menggunakan docker-compose, saya menyelesaikan ini dengan membuat layanan yang me-mount volume yang saya butuhkan dan melakukan gambar kontainer. Kemudian, dalam layanan selanjutnya, saya mengandalkan gambar yang dilakukan sebelumnya, yang memiliki semua data yang disimpan di lokasi yang dipasang. Anda kemudian harus menyalin file-file ini ke tujuan akhir mereka, karena direktori yang di-host di host tidak mendapatkan komitmen ketika menjalankan docker commitperintah

Anda tidak harus menggunakan komposisi buruh pelabuhan untuk melakukan ini, tetapi itu membuat hidup sedikit lebih mudah

# 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

Saya memiliki masalah yang sama dengan proyek dan beberapa file data yang saya tidak dapat pindah ke dalam konteks repo karena alasan HIPPA. Saya akhirnya menggunakan 2 Dockerfiles. Seseorang membangun aplikasi utama tanpa barang-barang yang saya butuhkan di luar wadah dan menerbitkannya ke repo internal. Kemudian dockerfile kedua menarik gambar itu dan menambahkan data dan membuat gambar baru yang kemudian digunakan dan tidak pernah disimpan di mana pun. Tidak ideal, tetapi berfungsi untuk tujuan saya menjaga informasi sensitif dari repo.

Solusi mudahnya adalah dengan memasang volume (menggunakan flag -v atau --mount) ke kontainer saat Anda menjalankannya dan mengakses file dengan cara itu.

contoh:

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

untuk lebih lanjut lihat: https://docs.docker.com/storage/volumes/

Seperti yang dijelaskan dalam masalah GitHub ini , build benar-benar terjadi /tmp/docker-12345, jadi path relatif seperti ../relative-add/some-filerelatif terhadap /tmp/docker-12345. Maka akan dicari /tmp/relative-add/some-file, yang juga ditampilkan dalam pesan kesalahan. *

Tidak diperbolehkan memasukkan file dari luar direktori build, jadi ini menghasilkan pesan "Jalur terlarang". "

Salah satu cara cepat dan kotor adalah mengatur konteks build sebanyak level yang Anda butuhkan - tetapi ini dapat memiliki konsekuensi. Jika Anda bekerja dalam arsitektur layanan microser yang terlihat seperti ini:

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

Anda dapat mengatur konteks build ke Codedirektori induk dan kemudian mengakses semuanya, tetapi ternyata dengan sejumlah besar repositori, ini dapat menyebabkan build membutuhkan waktu lama.

Contoh situasi bisa jadi tim lain mengelola skema basis data Repo1dan kode tim AndaRepo2 bergantung pada ini. Anda ingin mengurangi ketergantungan ini dengan beberapa data seed Anda sendiri tanpa khawatir tentang perubahan skema atau mengotori repositori tim lain (tergantung pada apa perubahannya Anda mungkin masih harus mengubah skrip data seed Anda tentu saja) Pendekatan kedua adalah hacky tetapi mengatasi masalah long build:

Buat skrip sh (atau ps1) ./Code/Repo2untuk menyalin file yang Anda butuhkan dan aktifkan perintah buruh pelabuhan yang Anda inginkan, misalnya:

#!/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

Dalam file pembuatan docker, cukup atur konteksnya sebagai Repo2root dan gunakan konten ./db/schemadirektori di dockerfile Anda tanpa khawatir tentang path. Ingatlah bahwa Anda akan menjalankan risiko tidak sengaja melakukan direktori ini ke kontrol sumber, tetapi tindakan pembersihan skrip harus cukup mudah.

Dalam kasus saya, Dockerfile saya ditulis seperti templat yang berisi placeholder yang saya ganti dengan nilai nyata menggunakan file konfigurasi saya.

Jadi saya tidak bisa menentukan file ini secara langsung tetapi pipa ke bangunan buruh pelabuhan seperti ini:

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

Tetapi karena pipa itu, COPYperintahnya tidak bekerja. Tetapi cara di atas menyelesaikannya dengan -f -(secara eksplisit mengatakan file tidak disediakan). Melakukan hanya -tanpa -fbendera, konteks DAN Dockerfile tidak disediakan yang merupakan peringatan.

Triknya adalah mengenali bahwa Anda dapat menentukan konteks dalam perintah build untuk memasukkan file dari direktori induk jika Anda menentukan jalur Docker, saya akan mengubah Dockerfile saya menjadi seperti ini:

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

Maka perintah build saya dapat terlihat seperti ini:

docker built -t TAG -f DOCKER_FILE_PATH CONTEXT

Dari direktori proyek

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

Dari proyek / buruh pelabuhan

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