Tôi đã chơi xung quanh với Docker một thời gian và tiếp tục tìm ra vấn đề tương tự khi xử lý dữ liệu liên tục.

Tôi tạo Dockerfilevà hiển thị âm lượng hoặc sử dụng --volumes-fromđể gắn thư mục máy chủ vào trong thùng chứa của mình .

Tôi nên áp dụng quyền gì cho âm lượng được chia sẻ trên máy chủ?

Tôi có thể nghĩ về hai lựa chọn:

• Cho đến nay tôi đã cấp cho mọi người quyền truy cập đọc / ghi, vì vậy tôi có thể ghi vào thư mục từ bộ chứa Docker.

• Ánh xạ người dùng từ máy chủ lưu trữ vào vùng chứa, vì vậy tôi có thể gán các quyền chi tiết hơn. Không chắc chắn điều này là có thể mặc dù và không tìm thấy nhiều về nó. Cho đến nay, tất cả những gì tôi có thể làm là chạy container với tư cách là một số người dùng: docker run -i -t -user="myuser" postgresnhưng người dùng này có UID khác với máy chủ của tôi myuser, vì vậy các quyền không hoạt động. Ngoài ra, tôi không chắc chắn nếu ánh xạ người dùng sẽ gây ra một số rủi ro bảo mật.

Có những lựa chọn thay thế khác?

Các bạn / các cô gái đối phó với vấn đề này như thế nào?

CẬP NHẬT 2016/03/02 : Tính đến Docker 1.9.0, Docker đã đặt tên khối lượng mà thay thế các thùng chứa dữ liệu chỉ . Câu trả lời dưới đây, cũng như bài đăng trên blog được liên kết của tôi, vẫn có giá trị theo cách nghĩ về dữ liệu bên trong docker nhưng xem xét sử dụng các khối lượng được đặt tên để thực hiện mô hình được mô tả bên dưới thay vì các thùng chứa dữ liệu.

Tôi tin rằng cách thức kinh điển để giải quyết điều này là bằng cách sử dụng các thùng chứa chỉ có dữ liệu . Với phương pháp này, tất cả quyền truy cập vào dữ liệu âm lượng đều thông qua các thùng chứa sử dụng -volumes-frombộ chứa dữ liệu, vì vậy uid / gid của máy chủ không thành vấn đề.

Ví dụ: một trường hợp sử dụng được đưa ra trong tài liệu đang sao lưu một khối lượng dữ liệu. Để làm điều này, một container khác được sử dụng để thực hiện sao lưu thông qua tarvà nó cũng sử dụng -volumes-fromđể gắn kết âm lượng. Vì vậy, tôi nghĩ điểm mấu chốt của Grok là: thay vì suy nghĩ về cách truy cập dữ liệu trên máy chủ với quyền thích hợp, hãy nghĩ về cách làm bất cứ điều gì bạn cần - sao lưu, duyệt, v.v. - thông qua một container khác . Bản thân các container cần sử dụng uid / gids nhất quán, nhưng chúng không cần ánh xạ tới bất cứ thứ gì trên máy chủ, do đó vẫn có thể di động.

Điều này cũng tương đối mới đối với tôi nhưng nếu bạn có một trường hợp sử dụng cụ thể, hãy bình luận và tôi sẽ cố gắng mở rộng câu trả lời.

CẬP NHẬT : Đối với trường hợp sử dụng đã cho trong các nhận xét, bạn có thể có một hình ảnh some/graphiteđể chạy than chì và một hình ảnh some/graphitedatalàm nơi chứa dữ liệu. Vì vậy, bỏ qua các cổng và như vậy, Dockerfilehình ảnh some/graphitedatalà một cái gì đó như:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
RUN mkdir -p /data/graphite \
  && chown -R graphite:graphite /data/graphite
VOLUME /data/graphite
USER graphite
CMD ["echo", "Data container for graphite"]

Xây dựng và tạo bộ chứa dữ liệu:

docker build -t some/graphitedata Dockerfile
docker run --name graphitedata some/graphitedata

Các some/graphiteDockerfile cũng sẽ nhận được cùng một uid / gids, do đó nó có thể trông như thế này:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
# ... graphite installation ...
VOLUME /data/graphite
USER graphite
CMD ["/bin/graphite"]

Và nó sẽ được chạy như sau:

docker run --volumes-from=graphitedata some/graphite

Ok, bây giờ cung cấp cho chúng tôi thùng chứa than chì của chúng tôi và thùng chứa chỉ có dữ liệu được liên kết với người dùng / nhóm chính xác (lưu ý rằng bạn cũng có thể sử dụng lại bộ some/graphitechứa cho bộ chứa dữ liệu, ghi đè lên mục nhập / cmd khi chạy nó, nhưng có chúng như hình ảnh riêng biệt IMO rõ ràng hơn).

Bây giờ, giả sử bạn muốn chỉnh sửa một cái gì đó trong thư mục dữ liệu. Vì vậy, thay vì liên kết việc gắn âm lượng vào máy chủ và chỉnh sửa nó ở đó, hãy tạo một thùng chứa mới để thực hiện công việc đó. Hãy gọi nó some/graphitetools. Cho phép cũng tạo người dùng / nhóm thích hợp, giống như some/graphitehình ảnh.

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
VOLUME /data/graphite
USER graphite
CMD ["/bin/bash"]

Bạn có thể tạo DRY này bằng cách kế thừa từ some/graphitehoặc some/graphitedatatrong Dockerfile hoặc thay vì tạo một hình ảnh mới, chỉ cần sử dụng lại một trong những hình ảnh hiện có (ghi đè điểm nhập / cmd nếu cần).

Bây giờ, bạn chỉ cần chạy:

docker run -ti --rm --volumes-from=graphitedata some/graphitetools

và sau đó vi /data/graphite/whatever.txt. Điều này hoạt động hoàn hảo bởi vì tất cả các container có cùng một người sử dụng than chì với uid / gid phù hợp.

Vì bạn không bao giờ gắn kết /data/graphitetừ máy chủ lưu trữ, bạn không quan tâm làm thế nào máy chủ uid / gid ánh xạ tới uid / gid được xác định bên trong graphitevà graphitetoolscác thùng chứa. Những container này hiện có thể được triển khai cho bất kỳ máy chủ nào và chúng sẽ tiếp tục hoạt động hoàn hảo.

Điều thú vị về điều này là graphitetoolscó thể có tất cả các loại tiện ích và tập lệnh hữu ích, giờ đây bạn cũng có thể triển khai theo cách di động.

CẬP NHẬT 2 : Sau khi viết câu trả lời này, tôi quyết định viết một bài đăng blog đầy đủ hơn về phương pháp này. Tôi hy vọng nó sẽ giúp.

CẬP NHẬT 3 : Tôi đã sửa câu trả lời này và thêm chi tiết cụ thể. Trước đây nó chứa một số giả định không chính xác về quyền sở hữu và perm - quyền sở hữu thường được chỉ định tại thời điểm tạo khối lượng tức là trong bộ chứa dữ liệu, vì đó là khi khối lượng được tạo. Xem blog này . Mặc dù vậy, đây không phải là một yêu cầu - bạn chỉ có thể sử dụng bộ chứa dữ liệu làm "tham chiếu / xử lý" và đặt quyền sở hữu / perms trong một bộ chứa khác thông qua chown trong một điểm nhập, kết thúc bằng gosu để chạy lệnh là người dùng chính xác. Nếu bất cứ ai quan tâm đến phương pháp này, xin vui lòng bình luận và tôi có thể cung cấp các liên kết đến một mẫu bằng cách sử dụng phương pháp này.

Một giải pháp rất thanh lịch có thể được nhìn thấy trên hình ảnh redis chính thức và nói chung trong tất cả các hình ảnh chính thức.

Được mô tả trong quy trình từng bước:

• Tạo người dùng / nhóm redis trước bất cứ điều gì khác

Như đã thấy trên Dockerfile bình luận:

thêm người dùng và nhóm của chúng tôi trước để đảm bảo ID của họ được gán một cách nhất quán, bất kể phụ thuộc nào được thêm vào

• Cài đặt gosu với Dockerfile

gosu là một thay thế của su/ sudođể dễ dàng bước xuống từ người dùng root. (Redis luôn được chạy với redisngười dùng)

• Định cấu hình /dataâm lượng và đặt nó làm việc

Bằng cách cấu hình âm lượng / dữ liệu bằng VOLUME /datalệnh, giờ đây chúng ta có một âm lượng riêng có thể là âm lượng docker hoặc gắn kết với một máy chủ lưu trữ.

Cấu hình nó như là workdir ( WORKDIR /data) làm cho nó trở thành thư mục mặc định nơi các lệnh được thực thi từ đó.

• Thêm tệp docker-entrypoint và đặt nó là ENTRYPOINT với máy chủ redis-CMD mặc định

Điều này có nghĩa là tất cả các thực thi container sẽ chạy qua tập lệnh docker-entrypoint và theo mặc định, lệnh sẽ được chạy là redis-server.

docker-entrypointlà một kịch bản mà không một chức năng đơn giản: Thay đổi sở hữu của thư mục hiện tại (/ data) và bước xuống từ rootđể redisngười sử dụng để chạy redis-server. (Nếu lệnh được thực thi không phải là máy chủ redis, nó sẽ chạy lệnh trực tiếp.)

Điều này có tác dụng sau đây

Nếu thư mục / data được gắn kết với máy chủ lưu trữ, docker-entrypoint sẽ chuẩn bị quyền người dùng trước khi chạy redis-server theo redisngười dùng.

Điều này mang đến cho bạn sự thoải mái rằng không có thiết lập nào để chạy container dưới bất kỳ cấu hình âm lượng nào.

Tất nhiên, nếu bạn cần chia sẻ âm lượng giữa các hình ảnh khác nhau, bạn cần đảm bảo rằng chúng sử dụng cùng một userid / groupid nếu không, container mới nhất sẽ chiếm quyền của người dùng từ hình ảnh trước đó.

Đây được cho là không phải là cách tốt nhất cho hầu hết các trường hợp, nhưng nó chưa được đề cập đến nên có lẽ nó sẽ giúp được ai đó.

1. Khối lượng máy chủ gắn kết ràng buộc

   Host folder FOOBAR is mounted in container /volume/FOOBAR

2. Sửa đổi tập lệnh khởi động của bộ chứa của bạn để tìm GID của khối lượng bạn quan tâm

   $ TARGET_GID=$(stat -c "%g" /volume/FOOBAR)

3. Đảm bảo người dùng của bạn thuộc một nhóm có GID này (bạn có thể phải tạo một nhóm mới). Trong ví dụ này, tôi sẽ giả vờ phần mềm của mình chạy như nobodyngười dùng khi ở trong container, vì vậy tôi muốn đảm bảo nobodythuộc về một nhóm có id nhóm bằngTARGET_GID

  EXISTS=$(cat /etc/group | grep $TARGET_GID | wc -l)

  # Create new group using target GID and add nobody user
  if [ $EXISTS == "0" ]; then
    groupadd -g $TARGET_GID tempgroup
    usermod -a -G tempgroup nobody
  else
    # GID exists, find group name and add
    GROUP=$(getent group $TARGET_GID | cut -d: -f1)
    usermod -a -G $GROUP nobody
  fi

Tôi thích điều này bởi vì tôi có thể dễ dàng sửa đổi các quyền của nhóm trên khối lượng máy chủ của mình và biết rằng các quyền được cập nhật đó áp dụng bên trong bộ chứa docker. Điều này xảy ra mà không có sự cho phép hoặc sửa đổi quyền sở hữu đối với các thư mục / tệp lưu trữ của tôi, điều này làm tôi hài lòng.

Tôi không thích điều này bởi vì nó cho rằng không có nguy hiểm khi thêm bạn vào một nhóm tùy ý bên trong thùng chứa tình cờ sử dụng GID mà bạn muốn. Nó không thể được sử dụng với một USERmệnh đề trong Dockerfile (trừ khi người dùng đó có quyền root tôi cho là). Ngoài ra, nó hét công việc hack ;-)

Nếu bạn muốn trở nên khó tính, rõ ràng bạn có thể mở rộng điều này theo nhiều cách - ví dụ: tìm kiếm tất cả các nhóm trên bất kỳ tập tin con, nhiều tập, v.v.

Ok, điều này hiện đang được theo dõi tại vấn đề docker # 7198

Hiện tại, tôi đang xử lý vấn đề này bằng tùy chọn thứ hai của bạn:

Ánh xạ người dùng từ máy chủ vào container

Dockerfile

#=======
# Users
#=======
# TODO: Idk how to fix hardcoding uid & gid, specifics to docker host machine
RUN (adduser --system --uid=1000 --gid=1000 \
        --home /home/myguestuser --shell /bin/bash myguestuser)

CLI

# DIR_HOST and DIR_GUEST belongs to uid:gid 1000:1000
docker run -d -v ${DIR_HOST}:${DIR_GUEST} elgalu/myservice:latest

CẬP NHẬT Tôi hiện đang nghiêng về câu trả lời của Hamy

Cố gắng thêm một lệnh vào Dockerfile

RUN usermod -u 1000 www-data

tín dụng truy cập https://github.com/denderello/symfony-docker-example/issues/2#issuecomment-94387272

Giống như bạn, tôi đang tìm cách lập bản đồ người dùng / nhóm từ máy chủ đến container container và đây là cách ngắn nhất tôi tìm thấy cho đến nay:

  version: "3"
    services:
      my-service:
        .....
        volumes:
          # take uid/gid lists from host
          - /etc/passwd:/etc/passwd:ro
          - /etc/group:/etc/group:ro
          # mount config folder
          - path-to-my-configs/my-service:/etc/my-service:ro
        .....

Đây là một trích xuất từ ​​docker-compose.yml của tôi.

Ý tưởng là gắn kết (trong chế độ chỉ đọc) danh sách người dùng / nhóm từ máy chủ đến vùng chứa, do đó, sau khi container khởi động, nó sẽ có cùng tên người dùng (cũng như đối với nhóm) với máy chủ. Bây giờ bạn có thể định cấu hình cài đặt người dùng / nhóm cho dịch vụ của mình bên trong vùng chứa như thể nó đang hoạt động trên hệ thống máy chủ của bạn.

Khi bạn quyết định chuyển container của mình sang một máy chủ khác, bạn chỉ cần thay đổi tên người dùng trong tệp cấu hình dịch vụ thành những gì bạn có trên máy chủ đó.

Đây là một cách tiếp cận vẫn sử dụng bộ chứa chỉ dữ liệu nhưng không yêu cầu nó phải được đồng bộ hóa với bộ chứa ứng dụng (về mặt có cùng uid / gid).

Có lẽ, bạn muốn chạy một số ứng dụng trong vùng chứa dưới dạng $ USER không root mà không cần vỏ đăng nhập.

Trong Dockerfile:

RUN useradd -s /bin/false myuser

# Set environment variables
ENV VOLUME_ROOT /data
ENV USER myuser

...

ENTRYPOINT ["./entrypoint.sh"]

Sau đó, trong entrypoint.sh:

chown -R $USER:$USER $VOLUME_ROOT
su -s /bin/bash - $USER -c "cd $repo/build; $@"

Để bảo mật và thay đổi root cho docker container, máy chủ docker hãy thử sử dụng --uidmapvà --private-uidscác tùy chọn

https://github.com/docker/docker/pull/4572#issuecomment-38400893

Ngoài ra, bạn có thể loại bỏ một số khả năng ( --cap-drop) trong bộ chứa docker để bảo mật

http://opensource.com/business/14/9/security-for-docker

CẬP NHẬT hỗ trợ nên đếndocker > 1.7.0

Phiên bản CẬP NHẬT1.10.0 (2016 / 02-04) thêm --userns-remapcờ https://github.com/docker/docker/blob/master/CHANGELOG.md#security-2

Cách tiếp cận của tôi là phát hiện UID / GID hiện tại, sau đó tạo người dùng / nhóm như vậy bên trong container và thực thi tập lệnh theo anh ta. Do đó, tất cả các tệp anh ta sẽ tạo sẽ khớp với người dùng trên máy chủ (đó là tập lệnh):

# get location of this script no matter what your current folder is, this might break between shells so make sure you run bash
LOCAL_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

# get current IDs
USER_ID=$(id -u)
GROUP_ID=$(id -g)

echo "Mount $LOCAL_DIR into docker, and match the host IDs ($USER_ID:$GROUP_ID) inside the container."

docker run -v $LOCAL_DIR:/host_mount -i debian:9.4-slim bash -c "set -euo pipefail && groupadd -r -g $GROUP_ID lowprivgroup && useradd -u $USER_ID lowprivuser -g $GROUP_ID && cd /host_mount && su -c ./runMyScriptAsRegularUser.sh lowprivuser"

Hình ảnh cơ sở

Sử dụng hình ảnh này: https://hub.docker.com/r/reduardo7/docker-host-user

hoặc là

Quan trọng: điều này phá hủy tính di động của container trên các máy chủ .

1) init.sh

#!/bin/bash

if ! getent passwd $DOCKDEV_USER_NAME > /dev/null
  then
    echo "Creating user $DOCKDEV_USER_NAME:$DOCKDEV_GROUP_NAME"
    groupadd --gid $DOCKDEV_GROUP_ID -r $DOCKDEV_GROUP_NAME
    useradd --system --uid=$DOCKDEV_USER_ID --gid=$DOCKDEV_GROUP_ID \
        --home-dir /home --password $DOCKDEV_USER_NAME $DOCKDEV_USER_NAME
    usermod -a -G sudo $DOCKDEV_USER_NAME
    chown -R $DOCKDEV_USER_NAME:$DOCKDEV_GROUP_NAME /home
  fi

sudo -u $DOCKDEV_USER_NAME bash

2) Dockerfile

FROM ubuntu:latest
# Volumes
    VOLUME ["/home/data"]
# Copy Files
    COPY /home/data/init.sh /home
# Init
    RUN chmod a+x /home/init.sh

3) chạy

#!/bin/bash

DOCKDEV_VARIABLES=(\
  DOCKDEV_USER_NAME=$USERNAME\
  DOCKDEV_USER_ID=$UID\
  DOCKDEV_GROUP_NAME=$(id -g -n $USERNAME)\
  DOCKDEV_GROUP_ID=$(id -g $USERNAME)\
)

cmd="docker run"

if [ ! -z "${DOCKDEV_VARIABLES}" ]; then
  for v in ${DOCKDEV_VARIABLES[@]}; do
    cmd="${cmd} -e ${v}"
  done
fi

# /home/usr/data contains init.sh
$cmd -v /home/usr/data:/home/data -i -t my-image /home/init.sh

4) Xây dựng với docker

4) Chạy đi!

sh run.sh

Trong trường hợp cụ thể của tôi, tôi đã cố gắng xây dựng gói nút của mình với hình ảnh docker nút để tôi không phải cài đặt npm trên máy chủ triển khai. Nó hoạt động tốt cho đến khi, bên ngoài container và trên máy chủ, tôi đã cố gắng di chuyển một tập tin vào thư mục node_modules mà hình ảnh docker nút đã tạo, mà tôi đã bị từ chối bởi vì nó thuộc quyền sở hữu của root. Tôi nhận ra rằng tôi có thể giải quyết vấn đề này bằng cách sao chép thư mục ra khỏi container vào máy chủ. Thông qua các tài liệu docker ...

Các tệp được sao chép vào máy cục bộ được tạo bằng UID: GID của người dùng đã gọi lệnh cp docker.

Đây là mã bash tôi đã sử dụng để thay đổi quyền sở hữu thư mục được tạo bởi và trong bộ chứa docker.

NODE_IMAGE=node_builder
docker run -v $(pwd)/build:/build -w="/build" --name $NODE_IMAGE node:6-slim npm i --production
# node_modules is owned by root, so we need to copy it out 
docker cp $NODE_IMAGE:/build/node_modules build/lambda 
# you might have issues trying to remove the directory "node_modules" within the shared volume "build", because it is owned by root, so remove the image and its volumes
docker rm -vf $NODE_IMAGE || true

Nếu cần, bạn có thể xóa thư mục bằng thùng chứa thứ hai.

docker run -v $(pwd)/build:/build -w="/build" --name $RMR_IMAGE node:6-slim rm -r node_modules

Để chia sẻ thư mục giữa máy chủ docker và container docker, hãy thử lệnh bên dưới

$ docker chạy -v "$ (pwd): $ (pwd)" -i -t ubfox

Cờ -v gắn thư mục làm việc hiện tại vào thùng chứa. Khi thư mục máy chủ của ổ đĩa gắn kết không tồn tại, Docker sẽ tự động tạo thư mục này trên máy chủ cho bạn,

Tuy nhiên, có 2 vấn đề chúng tôi có ở đây:

1. Bạn không thể ghi vào ổ đĩa được gắn nếu bạn không phải là người dùng root vì tệp được chia sẻ sẽ thuộc sở hữu của người dùng khác trong máy chủ,
2. Bạn không nên chạy quy trình bên trong các thùng chứa của mình dưới dạng root nhưng ngay cả khi bạn chạy như một người dùng được mã hóa cứng, nó vẫn không khớp với người dùng trên máy tính xách tay của bạn / Jenkins,

Giải pháp:

Container: tạo người dùng nói 'testuser', theo mặc định id người dùng sẽ bắt đầu từ 1000,

Máy chủ: tạo một nhóm nói 'nhóm thử nghiệm' với id nhóm 1000 và chọn thư mục cho nhóm mới (nhóm thử nghiệm

Nếu bạn sử dụng Docker Compose, hãy khởi động container ở chế độ ưu tiên:

wordpress:
    image: wordpress:4.5.3
    restart: always
    ports:
      - 8084:80
    privileged: true