Docker ile bir süredir oynuyorum ve kalıcı verilerle uğraşırken aynı sorunu bulmaya devam ediyorum.

Kızkardeşimi oluşturmak Dockerfileve bir hacim ortaya veya kullanmak --volumes-fromiçin benim kabın içinde bir konak klasörü monte .

Ana bilgisayardaki paylaşılan birime hangi izinleri uygulamalıyım?

İki seçeneği düşünebilirim:

• Şimdiye kadar herkese okuma / yazma erişimi verdim, böylece Docker kapsayıcısından klasöre yazabiliyorum.

• Ana bilgisayardan kapsayıcıya kullanıcılar eşleyin, böylece daha ayrıntılı izinler atayabilirim. Bunun mümkün olduğundan ve bu konuda fazla bir şey bulamadığından emin değilim. Şimdiye kadar yapabileceğim tek şey kapsayıcıyı bazı kullanıcı olarak çalıştırmak: docker run -i -t -user="myuser" postgresancak bu kullanıcının ana bilgisayarımdan farklı bir UID'si var myuser, bu yüzden izinler çalışmıyor. Ayrıca, kullanıcıların eşlenmesinin bazı güvenlik riskleri oluşturup oluşturmayacağından emin değilim.

Başka alternatifler var mı?

Bu sorunla nasıl başa çıkıyorsunuz?

GÜNCELLEME 2016/03/02 : Docker 1.9.0 itibariyle Docker etti hacimleri adında yalnızca veri kapların yerini . Aşağıdaki yanıtın yanı sıra bağlantılı blog yayınım da, docker içindeki veriler hakkında nasıl düşünüleceği anlamında değer taşıyor, ancak veri kapsayıcıları yerine aşağıda açıklanan kalıbı uygulamak için adlandırılmış birimler kullanmayı düşünüyor .

Bunu çözmenin kanonik yolunun sadece veri içeren kapları kullanmak olduğuna inanıyorum . Bu yaklaşımla, birim verilere tüm erişim -volumes-fromveri kabını kullanan kapsayıcılar yoluyla olur , bu nedenle ana bilgisayar uid / gid önemli değildir.

Örneğin, belgelerde verilen bir kullanım örneği bir veri birimini yedeklemektir. Bunu yapmak için, yedekleme yapmak için başka bir kap kullanılır ve birimi bağlamak için tarde kullanılır -volumes-from. Bu yüzden grok için kilit noktanın: ana bilgisayardaki verilere uygun izinlerle nasıl erişileceğini düşünmek yerine, ihtiyacınız olan her şeyi (yedeklemeler, göz atma vb.) Nasıl yapacağınızı düşünün. . Kapların kendilerinin tutarlı uid / gids kullanmaları gerekir, ancak ana bilgisayarda herhangi bir şeyle eşleşmeleri gerekmez, böylece taşınabilir kalırlar.

Bu benim için nispeten yeni ama belirli bir kullanım durumunuz varsa yorum yapmaktan çekinmeyin ve cevabı genişletmeye çalışacağım.

GÜNCELLEME : Yorumlarda verilen kullanım durumu için, some/graphitegrafit çalıştırmak için bir görüntünüz some/graphitedatave veri kabı olarak bir görüntünüz olabilir . Yani, portları ve benzeri şeyleri görmezden gelmek Dockerfile, görüntünün some/graphitedataşuna benzer:

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"]

Veri taşıyıcısını oluşturun ve oluşturun:

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

some/graphiteDockerfile aynı uid / gid'leri almalısınız, bu nedenle bu gibi görünebilir:

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"]

Ve şu şekilde çalıştırılır:

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

Tamam, şimdi bize grafit konteynırımızı ve doğru kullanıcı / grupla ilişkili sadece veri içeren konteyneri veriyor ( some/graphitekapsayıcıyı veri kabı için de yeniden kullanabileceğinizi, giriş sırasında / cmd'yi geçersiz kıldığınızı, ancak ayrı görüntüler IMO daha net).

Şimdi, veri klasöründeki bir şeyi düzenlemek istediğinizi varsayalım. Bu nedenle, birimi ana bilgisayara bağlamak ve orada düzenlemek yerine, bu işi yapmak için yeni bir kap oluşturun. Hadi diyelim some/graphitetools. some/graphiteGörüntüde olduğu gibi uygun kullanıcı / grup da oluşturalım .

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"]

Bu DRY'yi Dockerfile öğesinden veya Dockerfile dosyasından devralarak veya yeni bir görüntü oluşturmak yerine sadece mevcut olanlardan birini yeniden kullanın (gerektiğinde giriş noktası some/graphite/ some/graphitedatacmd'yi geçersiz kılar).

Şimdi, sadece şunu çalıştırın:

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

ve sonra vi /data/graphite/whatever.txt. Bu, tüm kapların eşleşen uid / gid ile aynı grafit kullanıcısına sahip olması nedeniyle mükemmel çalışır.

/data/graphiteAna bilgisayardan asla bağlanmadığınız için, ana bilgisayar uid / gid graphiteve graphitetoolskaplarının içinde tanımlanan uid / gid ile nasıl eşleştiği umurumda değildir . Bu kapsayıcılar artık herhangi bir ana bilgisayara dağıtılabilir ve mükemmel bir şekilde çalışmaya devam ederler.

Bununla ilgili temiz olan şey graphitetools, artık taşınabilir bir şekilde de dağıtabileceğiniz her türlü yararlı yardımcı program ve komut dosyasına sahip olabilmesidir.

GÜNCELLEME 2 : Bu cevabı yazdıktan sonra, bu yaklaşım hakkında daha eksiksiz bir blog yazısı yazmaya karar verdim . Umut ediyorum bu yardım eder.

GÜNCELLEME 3 : Bu yanıtı düzelttim ve daha fazla ayrıntı ekledim. Daha önce sahiplik ve izinlerle ilgili bazı yanlış varsayımlar içeriyordu - sahiplik genellikle birim oluşturma zamanında, yani veri kabında atanır, çünkü birim oluşturulur. Bu bloga bakın . Bu bir zorunluluk değildir - veri kapsayıcısını yalnızca "başvuru / tanıtıcı" olarak kullanabilir ve komutu doğru kullanıcı olarak çalıştırmak için gosu ile biten bir giriş noktasındaki chown yoluyla başka bir kaptaki sahiplik / izinleri ayarlayabilirsiniz. Bu yaklaşımla ilgilenen varsa, lütfen yorum yapın ve bu yaklaşımı kullanarak bir örneğe bağlantılar sağlayabilirim.

Resmi redis görüntüsünde ve genel olarak tüm resmi görüntülerde çok zarif bir çözüm görülebilir .

Adım adım süreçte açıklanmaktadır:

• Her şeyden önce kullanıcı / grup yeniden oluştur

Dockerfile yorumlarında görüldüğü gibi:

eklenen bağımlılıklardan bağımsız olarak kimliklerinin tutarlı bir şekilde atanmasını sağlamak için önce kullanıcı ve grubumuzu ekleyin

• Dockerfile ile gosu yükleyin

Gosu bir alternatiftir su/ ' sudokökü kullanıcının kolay adım-down. (Redis her zaman rediskullanıcı ile çalıştırılır )

• /dataBirimi yapılandırın ve iş dizini olarak ayarlayın

/ Data birimini VOLUME /datakomutla yapılandırarak, artık docker birimi veya ana bilgisayar dizinine bağlanan ayrı bir birimimiz var.

İş dizini ( WORKDIR /data) olarak yapılandırılması , komutların yürütüldüğü varsayılan dizin olmasını sağlar.

• Docker-giriş noktası dosyası ekleyin ve varsayılan CMD redis sunucusu ile ENTRYPOINT olarak ayarlayın

Bu, tüm kapsayıcı yürütmelerinin docker-giriş noktası komut dosyası aracılığıyla çalıştırılacağı ve varsayılan olarak çalıştırılacak komutun redis-server olduğu anlamına gelir.

docker-entrypointbasit bir işlevi yerine getiren bir betiktir: Geçerli dizinin (/ data) sahipliğini değiştirin ve çalıştırmak rootiçin rediskullanıcıya adım adım atılır redis-server. (Yürütülen komut redis-sunucusu değilse, komutu doğrudan çalıştırır.)

Bu aşağıdaki etkiye sahiptir

/ Data dizini ana bilgisayara bağlanırsa, docker-giriş noktası redis-server'ı rediskullanıcı altında çalıştırmadan önce kullanıcı izinlerini hazırlar .

Bu, kapsayıcıyı herhangi bir birim yapılandırması altında çalıştırmak için sıfır kurulum olduğunu aklınızda bulundurun.

Tabii ki farklı görüntüler arasında hacmi paylaşmanız gerekiyorsa, aynı kullanıcı kimliği / grup kimliğini kullandıklarından emin olmanız gerekir, aksi takdirde en son kapsayıcı bir öncekinden kullanıcı izinlerini ele geçirir.

Bu, çoğu durum için tartışmasız en iyi yol değildir , ancak henüz bahsedilmemiştir, bu yüzden belki birine yardımcı olacaktır.

1. Bağlanan ana bilgisayar hacmini bağlama

   Host folder FOOBAR is mounted in container /volume/FOOBAR

2. İlgilendiğiniz birimin GID'sini bulmak için kapsayıcınızın başlangıç ​​komut dosyasını değiştirin

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

3. Kullanıcının bu GID ile bir gruba ait olduğundan emin olun (yeni bir grup oluşturmanız gerekebilir). Bu örnekte, kabımın içindeyken yazılımımın nobodykullanıcı olarak çalıştığını iddia edeceğim , bu yüzden nobodygrup kimliğine eşit bir gruba ait olmasını sağlamak istiyorumTARGET_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

Ana bilgisayar birimlerimdeki grup izinlerini kolayca değiştirebildiğim ve bu güncellenmiş izinlerin docker kapsayıcısı için geçerli olduğunu bildiğim için bunu beğendim. Bu, ana bilgisayar klasörlerim / dosyalarımda herhangi bir izin veya sahiplik değişikliği olmadan gerçekleşir ve bu beni mutlu eder.

Bunu sevmiyorum çünkü istediğiniz bir GID'yi kullanan kap içindeki rastgele gruplara kendinizi eklemenin hiçbir tehlikesi olmadığını varsayıyor. USERDockerfile öğesinde bir cümle ile kullanılamaz (bu kullanıcının sanırım kök ayrıcalıkları yoksa). Ayrıca, kesmek iş ;-) bağırır

Eğer sert olmak istiyorsanız, bunu birçok yönden uzatabilirsiniz - örneğin, herhangi bir alt dosyadaki, çoklu ciltlerdeki vb.

Tamam, şimdi liman işçisi sorunu izleniyor # 7198

Şimdilik, ikinci seçeneğinizi kullanarak bununla ilgileniyorum:

Ana bilgisayardan kullanıcıları kapsayıcıya eşleyin

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

GÜNCELLEME Şu anda Hamy'nin cevabına daha meyilliyim

Dockerfile'a bir komut eklemeyi deneyin

RUN usermod -u 1000 www-data

krediler https://github.com/denderello/symfony-docker-example/issues/2#issuecomment-94387272 adresine gider.

Sizinle aynı, ana bilgisayardan docker kapsayıcılarına kullanıcıları / grupları eşlemenin bir yolunu arıyordum ve bu şimdiye kadar bulduğum en kısa yol:

  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
        .....

Bu benim docker-compose.yml bir özü.

Fikir, ana bilgisayardan kapsayıcıya (salt okunur modda) kullanıcı / grup listelerini bağlamaktır, böylece kap başladıktan sonra ana bilgisayarla aynı uid-> kullanıcı adı (ve gruplar için) eşleşmelerine sahip olur. Artık kapsayıcı içindeki hizmetiniz için kullanıcı / grup ayarlarını, ana sisteminizde çalışıyormuş gibi yapılandırabilirsiniz.

Kapsayıcınızı başka bir ana bilgisayara taşımaya karar verdiğinizde, hizmet yapılandırma dosyasındaki kullanıcı adını o ana bilgisayarda sahip olduğunuz şekilde değiştirmeniz yeterlidir.

Yine de yalnızca veri içeren bir kapsayıcı kullanan ancak uygulama kapsayıcısıyla eşitlenmesini gerektirmeyen bir yaklaşım aşağıdadır (aynı uid / gid'e sahip olma açısından).

Muhtemelen, kapsayıcıda bazı uygulamaları bir giriş kabuğu olmadan root olmayan bir USERERER kullanıcısı olarak çalıştırmak istiyorsunuz.

Dockerfile dosyasında:

RUN useradd -s /bin/false myuser

# Set environment variables
ENV VOLUME_ROOT /data
ENV USER myuser

...

ENTRYPOINT ["./entrypoint.sh"]

Sonra, inputpoint.sh dosyasında:

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

Docker konteyneri için güvenli ve kök değiştirmek için bir docker ana makinesi kullanmayı --uidmapve --private-uidsseçenekleri deneyin

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

Ayrıca --cap-dropgüvenlik için docker kapsayıcısındaki çeşitli özellikleri ( ) kaldırabilirsiniz

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

GÜNCELLEME desteği gelmelidirdocker > 1.7.0

GÜNCELLEME Sürümü 1.10.0(2016-02-04) --userns-remapbayrak ekle https://github.com/docker/docker/blob/master/CHANGELOG.md#security-2

Benim yaklaşımım şu anki UID / GID algılamak, daha sonra konteyner içinde böyle bir kullanıcı / grup oluşturmak ve onun altında komut dosyası yürütmektir. Sonuç olarak oluşturacağı tüm dosyalar ana bilgisayardaki (komut dosyası olan) kullanıcıyla eşleşir:

# 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"

Temel Görüntü

Bu resmi kullanın: https://hub.docker.com/r/reduardo7/docker-host-user

veya

Önemli: Bu, ana bilgisayarlar arasında kapsayıcı taşınabilirliğini yok eder .

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) run.sh

#!/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) ile inşa docker

4) Koş!

sh run.sh

Benim özel durumda, dağıtım sunucusuna npm yüklemek zorunda kalmamak için düğüm paketleyici görüntü ile düğüm paketimi oluşturmak çalışıyordu. Kapsayıcı dışında ve ana makine üzerinde, düğüm docker görüntüsünün oluşturduğu node_modules dizinine bir dosyayı taşımaya çalıştım, bu yüzden root'a ait olduğu için izinler reddedildim. Dizini konteynırdan ana makineye kopyalayarak bu sorunu çözebileceğimi fark ettim. Via liman işçisi dokümanlar ...

Yerel makineye kopyalanan dosyalar, docker cp komutunu çağıran kullanıcının UID: GID'si ile oluşturulur.

Bu, docker konteyneri tarafından ve docker kapsayıcısı tarafından oluşturulan dizinin sahipliğini değiştirmek için kullandığım bash kodudur.

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

Gerekirse, dizini ikinci bir docker kapsayıcısıyla kaldırabilirsiniz.

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

Docker ana bilgisayarı ve docker kapsayıcısı arasında klasör paylaşmak için aşağıdaki komutu deneyin

$ docker run -v "$ (pwd): $ (pwd)" -i -t ubuntu

-V bayrağı, geçerli çalışma dizinini kaba bağlar. Bağlanan bir birimin ana bilgisayar dizini yoksa, Docker bu dizini sizin için otomatik olarak ana bilgisayarda oluşturur,

Ancak, burada yaşadığımız 2 sorun var:

1. Kök olmayan bir kullanıcıysanız , bağlanan birime yazamazsınız, çünkü paylaşılan dosya ana bilgisayardaki başka bir kullanıcıya ait olacaktır,
2. İşlemi kaplarınızın içinde kök olarak çalıştırmamalısınız, ancak sabit kodlanmış bir kullanıcı olarak çalıştırsanız bile, yine de dizüstü bilgisayarınızda / Jenkins'teki kullanıcıyla eşleşmez

Çözüm:

Kapsayıcı: 'testuser' diyen bir kullanıcı oluşturun, varsayılan olarak kullanıcı kimliği 1000'den başlayacak,

Ana bilgisayar: 1000 grup kimliği ile 'testgroup' adlı bir grup oluşturun ve dizini yeni gruba (test grubu) seçin

Docker Compose kullanıyorsanız, kapsayıcıyı öncelikli modda başlatın:

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