Làm cách nào tôi có thể bao gồm các tệp từ bên ngoài bối cảnh xây dựng của Docker bằng lệnh "THÊM" trong tệp Docker?

Từ tài liệu Docker:

Đường dẫn phải nằm trong bối cảnh của bản dựng; bạn không thể THÊM ../s Something / s Something, vì bước đầu tiên của quá trình xây dựng docker là gửi thư mục ngữ cảnh (và thư mục con) đến trình nền của docker.

Tôi không muốn cơ cấu lại toàn bộ dự án của mình chỉ để phù hợp với Docker trong vấn đề này. Tôi muốn giữ tất cả các tệp Docker của mình trong cùng một thư mục con.

Ngoài ra, có vẻ như Docker chưa (và có thể chưa bao giờ) hỗ trợ các liên kết tượng trưng: Lệnh Dockerfile ADD không tuân theo các liên kết tượng trưng trên máy chủ # 1676.

Điều khác duy nhất tôi có thể nghĩ đến là bao gồm một bước dựng trước để sao chép các tệp vào bối cảnh xây dựng Docker (và định cấu hình kiểm soát phiên bản của tôi để bỏ qua các tệp đó). Có một cách giải quyết tốt hơn cho điều đó?

Cách tốt nhất để giải quyết vấn đề này là chỉ định Dockerfile độc ​​lập với bối cảnh xây dựng, sử dụng -f.

Chẳng hạn, lệnh này sẽ cấp cho lệnh ADD quyền truy cập vào bất cứ thứ gì trong thư mục hiện tại của bạn.

docker build -f docker-files/Dockerfile .

Cập nhật : Docker hiện cho phép có Dockerfile bên ngoài bối cảnh xây dựng (được sửa trong 18.03.0-ce, https://github.com/docker/cli/pull/886 ). Vì vậy, bạn cũng có thể làm một cái gì đó như

docker build -f ../Dockerfile .

Tôi thường thấy mình sử dụng --build-argtùy chọn cho mục đích này. Ví dụ: sau khi đặt các mục sau vào Dockerfile:

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

Bạn chỉ có thể làm:

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

Nhưng lưu ý cảnh báo sau từ tài liệu Docker :

Cảnh báo: Không nên sử dụng các biến thời gian xây dựng để truyền các bí mật như khóa github, thông tin người dùng, v.v. Giá trị biến thời gian xây dựng được hiển thị cho bất kỳ người dùng hình ảnh nào bằng lệnh lịch sử docker.

Trên Linux, bạn có thể gắn các thư mục khác thay vì liên kết chúng

mount --bind olddir newdir

Xem /superuser/842642 để biết thêm chi tiết.

Tôi không biết nếu một cái gì đó tương tự có sẵn cho các hệ điều hành khác. Tôi cũng đã thử sử dụng Samba để chia sẻ một thư mục và đưa nó vào bối cảnh Docker cũng hoạt động.

Tôi đã dành thời gian tốt để cố gắng tìm ra một mô hình tốt và cách giải thích rõ hơn những gì đang diễn ra với tính năng hỗ trợ này. Tôi nhận ra rằng cách tốt nhất để giải thích nó như sau ...

• Dockerfile: Sẽ chỉ thấy các tệp trong đường dẫn tương đối của chính nó
• Bối cảnh: một vị trí trong "không gian" nơi các tệp bạn muốn chia sẻ và Dockerfile của bạn sẽ được sao chép vào

Vì vậy, như đã nói, đây là một ví dụ về Dockerfile cần sử dụng lại một tệp có tên start.sh

Dockerfile

Nó ALWAYSsẽ tải từ đường dẫn tương đối của nó, có thư mục hiện tại của chính nó làm localtham chiếu đến các đường dẫn bạn chỉ định.

COPY start.sh /runtime/start.sh

Các tập tin

Xem xét ý tưởng này, chúng ta có thể nghĩ đến việc có nhiều bản sao cho Dockerfiles xây dựng những thứ cụ thể, nhưng tất cả chúng đều cần quyền truy cập vào start.sh.

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

Xem xét cấu trúc này và các tệp ở trên, đây là một docker-compose.yml

docker-compose.yaml

• Trong ví dụ này, shareddir ngữ cảnh của bạn là runtimedir.
  • Cùng một mô hình tinh thần ở đây, hãy nghĩ rằng tất cả các tệp trong thư mục này được chuyển sang cái gọi là context.
  • Tương tự, chỉ cần xác định Dockerfile mà bạn muốn sao chép vào cùng một thư mục đó. Bạn có thể chỉ định rằng sử dụng dockerfile.
• thư mục chứa nội dung chính của bạn là bối cảnh thực tế sẽ được đặt.

Các docker-compose.ymlthực hiện như sau

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-serviceđược đặt làm bối cảnh, tệp chia sẻ start.shđược sao chép ở đó cũng như Dockerfile được chỉ định bởi mỗi tệp dockerfile.
• Mỗi người được xây dựng theo cách riêng của họ, chia sẻ tệp bắt đầu!

Chúc mừng!

Nếu bạn đọc các cuộc thảo luận trong vấn đề 2745, không chỉ docker có thể không bao giờ hỗ trợ các liên kết tượng trưng, ​​họ có thể không bao giờ hỗ trợ thêm các tệp bên ngoài ngữ cảnh của bạn. Dường như là một triết lý thiết kế rằng các tệp đi vào xây dựng docker rõ ràng phải là một phần trong bối cảnh của nó hoặc là từ một URL có thể được triển khai với phiên bản cố định để bản dựng có thể lặp lại với các URL hoặc tệp nổi tiếng được gửi cùng với docker container.

Tôi thích xây dựng từ một nguồn được kiểm soát phiên bản - tức là docker build -t Stuff http://my.git.org/repo - nếu không tôi đang xây dựng từ một nơi ngẫu nhiên với các tệp ngẫu nhiên.

về cơ bản, không .... - SvenDowideit, Docker Inc

Chỉ là ý kiến ​​của tôi nhưng tôi nghĩ bạn nên cơ cấu lại để tách ra các kho chứa mã và docker. Bằng cách đó, các thùng chứa có thể chung chung và kéo theo bất kỳ phiên bản mã nào trong thời gian chạy thay vì thời gian xây dựng.

Ngoài ra, sử dụng docker làm tạo tác triển khai mã cơ bản của bạn và sau đó bạn đặt dockerfile vào thư mục gốc của kho lưu trữ mã. nếu bạn đi tuyến đường này có thể có ý nghĩa để có một thùng chứa cha mẹ để biết thêm chi tiết cấp độ hệ thống chung và một thùng chứa con để thiết lập cụ thể cho mã của bạn.

Tôi tin rằng cách giải quyết đơn giản hơn sẽ là thay đổi 'bối cảnh'.

Vì vậy, ví dụ, thay vì cho:

docker build -t hello-demo-app .

trong đó đặt thư mục hiện tại làm bối cảnh, giả sử bạn muốn thư mục mẹ làm bối cảnh, chỉ cần sử dụng:

docker build -t hello-demo-app ..

Bạn cũng có thể tạo một tarball về những gì hình ảnh cần trước tiên và sử dụng nó làm bối cảnh của bạn.

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

Sử dụng docker-compose, tôi đã thực hiện điều này bằng cách tạo ra một dịch vụ gắn kết các khối lượng mà tôi cần và cam kết hình ảnh của container. Sau đó, trong dịch vụ tiếp theo, tôi dựa vào hình ảnh đã cam kết trước đó, có tất cả dữ liệu được lưu trữ tại các vị trí được gắn. Sau đó, bạn sẽ phải sao chép các tệp này vào đích cuối cùng của chúng, vì các thư mục được gắn trên máy chủ không được cam kết khi chạy docker commitlệnh

Bạn không phải sử dụng docker-compose để thực hiện điều này, nhưng nó giúp cuộc sống dễ dàng hơn một chút

# 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

Tôi gặp vấn đề tương tự với một dự án và một số tệp dữ liệu mà tôi không thể di chuyển trong bối cảnh repo vì lý do HIPPA. Tôi đã kết thúc bằng cách sử dụng 2 Dockerfiles. Người ta xây dựng ứng dụng chính mà không có những thứ tôi cần bên ngoài container và xuất bản nó lên repo nội bộ. Sau đó, một dockerfile thứ hai kéo hình ảnh đó và thêm dữ liệu và tạo một hình ảnh mới sau đó được triển khai và không bao giờ được lưu trữ ở bất cứ đâu. Không lý tưởng, nhưng nó hoạt động cho mục đích của tôi là giữ thông tin nhạy cảm ra khỏi repo.

Một cách giải quyết dễ dàng có thể chỉ đơn giản là gắn âm lượng (sử dụng cờ -v hoặc --mount) vào thùng chứa khi bạn chạy nó và truy cập các tệp theo cách đó.

thí dụ:

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

để biết thêm xem: https://docs.docker.com/st Storage / volume /

Như được mô tả trong này vấn đề GitHub xây dựng thực sự xảy ra trong /tmp/docker-12345, do đó, một đường dẫn tương đối như ../relative-add/some-filelà liên quan đến /tmp/docker-12345. Do đó, nó sẽ tìm kiếm /tmp/relative-add/some-file, cũng được hiển thị trong thông báo lỗi. *

Không được phép bao gồm các tệp từ bên ngoài thư mục bản dựng, do đó, điều này dẫn đến thông báo "Đường dẫn bị cấm". "

Một cách nhanh chóng và bẩn thỉu là thiết lập bối cảnh xây dựng lên bao nhiêu cấp độ bạn cần - nhưng điều này có thể gây ra hậu quả. Nếu bạn đang làm việc trong một kiến ​​trúc microservice trông như thế này:

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

Bạn có thể đặt bối cảnh xây dựng vào Codethư mục mẹ và sau đó truy cập mọi thứ, nhưng hóa ra với một số lượng lớn các kho lưu trữ, điều này có thể dẫn đến việc xây dựng mất nhiều thời gian.

Một tình huống ví dụ có thể là một nhóm khác duy trì một lược đồ cơ sở dữ liệu Repo1và mã nhóm của bạn Repo2phụ thuộc vào điều này. Bạn muốn cập nhật sự phụ thuộc này với một số dữ liệu hạt giống của riêng bạn mà không phải lo lắng về thay đổi lược đồ hoặc gây ô nhiễm kho lưu trữ của nhóm khác (tùy thuộc vào những thay đổi nào bạn vẫn có thể phải thay đổi tập lệnh dữ liệu hạt giống của mình) Cách tiếp cận thứ hai là hacky nhưng xoay quanh vấn đề xây dựng dài:

Tạo tập lệnh sh (hoặc ps1) ./Code/Repo2để sao chép các tệp bạn cần và gọi các lệnh docker mà bạn muốn, ví dụ:

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

Trong tệp soạn thảo docker , chỉ cần đặt bối cảnh là Repo2root và sử dụng nội dung của ./db/schemathư mục trong dockerfile của bạn mà không phải lo lắng về đường dẫn. Hãy nhớ rằng bạn sẽ có nguy cơ vô tình cam kết thư mục này vào kiểm soát nguồn, nhưng các hành động dọn dẹp kịch bản phải đủ dễ dàng.

Trong trường hợp của tôi, Dockerfile của tôi được viết giống như một mẫu chứa các phần giữ chỗ mà tôi sẽ thay thế bằng giá trị thực bằng tệp cấu hình của mình.

Vì vậy, tôi không thể chỉ định tệp này trực tiếp nhưng chuyển nó vào bản dựng docker như thế này:

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

Nhưng vì đường ống, COPYlệnh không hoạt động. Nhưng cách trên giải quyết nó bằng cách -f -(nói rõ ràng tệp không được cung cấp). Chỉ thực hiện -mà không có -fcờ, bối cảnh VÀ Dockerfile không được cung cấp mà là một cảnh báo.

Mẹo nhỏ là nhận ra rằng bạn có thể chỉ định ngữ cảnh trong lệnh xây dựng để bao gồm các tệp từ thư mục mẹ nếu bạn chỉ định đường dẫn Docker, tôi sẽ thay đổi Dockerfile của mình thành như sau:

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

Sau đó, lệnh xây dựng của tôi có thể trông như thế này:

docker built -t TAG -f DOCKER_FILE_PATH CONTEXT

Từ thư mục dự án

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

Từ dự án / bến tàu

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