Se formos por isso, sou mais a favor da opção RUNP, em vez de ter
todos os contêineres em execução no modo -privilegiado.

Na quarta-feira, 18 de setembro de 2013 às 13h07, Benjamin Podszun
notificaçõ[email protected] :

Atualmente, parece não haver maneira de executar operações privilegiadas fora de
docker run -privileged.

Isso significa que não posso fazer as mesmas coisas em um Dockerfile. Meu recente
problema: gostaria de executar o fusível (para encfs) dentro de um contêiner. Instalando
fuse já é uma bagunça com hacks e soluções alternativas (veja [1] e [2]),
porque o mknod falha / não é compatível sem uma etapa de compilação privilegiada.

A única solução agora é fazer a instalação manualmente, usando
run -privileged, e criando uma nova 'imagem base do fusível'. O que significa que eu
não pode descrever todo o contêiner, de uma imagem de base oficial ao acabamento,
em um único Dockerfile.

Eu, portanto, sugiro adicionar

• uma construção docker - privilegiada
  isso deve fazer a mesma coisa que executar -privileged, ou seja, remover todos
  limitações dos limites

ou

• um comando RUNP no Dockerfile
  isso deve .. bem .. EXECUTAR, mas com _P_rivileges

Tentei olhar para a fonte, mas sou inútil com go e não consegui encontrar um
ponto de entrada decente para anexar uma prova de conceito, infelizmente. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (comentário) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916
.

Victor VIEUX
http://vvieux.com

Na verdade, podemos ter que fazer ambos - ou seja, RUNP + requer um "-privilegiado"
bandeira.

Se dependermos apenas do RUNP (sem exigir "-privileged"), então
tem que se perguntar quando fazemos uma construção "esta construção é segura?".
Se dependermos apenas de "-privilegiado", perderemos a informação (no
Dockerfile) que "esta ação requer privilégios estendidos".

Acho que uma combinação de ambos é a maneira mais segura.

Na quarta-feira, 18 de setembro de 2013 às 4h07, Benjamin Podszun
notificaçõ[email protected] :

Atualmente, parece não haver maneira de executar operações privilegiadas fora de
docker run -privileged.

Isso significa que não posso fazer as mesmas coisas em um Dockerfile. Meu recente
problema: gostaria de executar o fusível (para encfs) dentro de um contêiner. Instalando
fuse já é uma bagunça com hacks e soluções alternativas (veja [1] e [2]),
porque o mknod falha / não é compatível sem uma etapa de compilação privilegiada.

A única solução agora é fazer a instalação manualmente, usando
run -privileged, e criando uma nova 'imagem base do fusível'. O que significa que eu
não pode descrever todo o contêiner, de uma imagem de base oficial ao acabamento,
em um único Dockerfile.

Eu, portanto, sugiro adicionar

• uma construção docker - privilegiada
  isso deve fazer a mesma coisa que executar -privileged, ou seja, remover todos
  limitações dos limites

ou

• um comando RUNP no Dockerfile
  isso deve .. bem .. EXECUTAR, mas com _P_rivileges

Tentei olhar para a fonte, mas sou inútil com go e não consegui encontrar um
ponto de entrada decente para anexar uma prova de conceito, infelizmente. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (comentário) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916
.

@jpetazzo https://twitter.com/jpetazzo
Última postagem do blog: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Parece razoável. Para mim, esse recurso (ser capaz de criar nós de dispositivo) torna ou quebra a capacidade de criar a implantação no Docker. Se eu puder ajudar (testando principalmente, tentei olhar a fonte, mas falhei até agora. Parece que os comandos disponíveis em um buildfile são encontrados por meio de reflexão, adicionei um comando runp que define config.privileged como true, mas até agora eu sou incapaz de construir e testar -> travado) Eu gostaria de investir algum tempo.

Eu sugeriria RUNP + build -privileged .

_Acende alguns sinais de fumaça para chamar a atenção de @shykes , @crosbymichael_

... E então teremos que encontrar alguém para implementá-lo, é claro ☺
Isso seria algo que você gostaria de tentar (com orientação apropriada e feedback da equipe principal, é claro)?

Se a última parte era direcionada a mim: Claro, por que não. Já estou mexendo no código go (não é uma linguagem com a qual estou familiarizado, mas veja acima: estou tentando descobrir o que está acontecendo de qualquer maneira).

Com algumas dicas / alguém para responder a algumas perguntas, eu certamente tentaria.

Não estou convencido de RUNP ou privilégio de compilação.

Geralmente não gosto de nada que introduza diferentes construções possíveis da mesma entrada. É por isso que você não pode passar argumentos ou variáveis ​​env para uma construção.

Especificamente, não gosto de introduzir dependências em "privilegiados" em todos os lugares, porque designa um conjunto de recursos que é a) muito grande eb) não claramente especificado ou definido. Isso é bom como um mecanismo grosso para administradores de sistemas contornar a segurança de uma forma tudo ou nada - uma "saída de emergência" quando o ambiente de execução docker padrão não é suficiente. É semelhante ao bind-mounts e custom lxc-conf.

-
@solomonstre
@getdocker

Na sexta-feira, 20 de setembro de 2013 às 15:18, Benjamin Podszun
notificaçõ[email protected] escreveu:

Se a última parte era direcionada a mim: Claro, por que não. Já estou mexendo no código go (não é uma linguagem com a qual estou familiarizado, mas veja acima: estou tentando descobrir o que está acontecendo de qualquer maneira).

Com algumas dicas / alguém para responder a algumas perguntas, eu certamente tentaria.

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

Bem, você concorda que deveria ser possível construir uma imagem docker que - por exemplo - execute fusível?
Para isso, precisamos mknod.

A meu ver, não há como esses builds serem diferentes dependendo dos parâmetros: O build funcionará (os limites não são / menos restritos do que agora) ou falhará (status quo). Há pouco ou nenhum risco de diferentes 'versões' do mesmo arquivo de compilação, certo?

Estou tendo esse problema agora. Para construir a imagem de que preciso, tenho que realizar uma série de run -privileged etapas + uma commit etapa, em vez de build ing um Dockerfile. Idealmente, seria bom expressar as etapas de construção da imagem em um Dockerfile.

Também está relacionado às operações mknod?
Se você pudesse descrever exatamente as ações que requerem modo privilegiado em
seu caso, seria muito útil!
Obrigado,

Olá @jpetazzo , da lista de e-mails, aqui está o problema que estou enfrentando: https://groups.google.com/forum/#!topic/docker -user / 1pFhqlfbqQI

Estou tentando mount a fs que criei (criado para contornar aufs e algo sobre registro no mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , onde /db/disk-image foi criado com dd if=/dev/zero of=disk-image count=409600 e home/db2inst1 é de onde estou tentando iniciar o DB2.

Se bem entendi, durante o processo de instalação, você precisa de um diretório não AUFS - ou melhor, algo que suporte O_DIRECT . Se for esse o caso, o Docker 0.7 deve resolver o problema, já que usará ext4 (e instantâneos em nível de bloco) em vez de AUFS.

1 para isso também.

A instalação de pacotes que requerem mudança nas configurações de memória e configuração do kernel (por exemplo, Vertica DB, WebSphere MQ) só pode ser feita no modo privilegiado.

Vamos tentar separar as preocupações quando se trata de executar / construir com "privilegiado": pode ser necessário apenas durante a construção, apenas durante a execução via docker run ou ambos.

Deve ser possível permitir que um build faça algo que requeira um pouco mais de permissões para uma etapa (ou mais), se necessário. Eu precisava disso para um projeto e tive que converter metade de um Dockerfile em um script de shell que invocou a compilação e continuou a compilar no modo privilegiado, portanto, ter uma compilação "privilegiada" seria útil.

No entanto, não devemos descer até o modo privilegiado por padrão apenas para que possamos usar o sysctl para alterar algumas configurações. Isso deve ser feito por meio de configuração de imagem ou por meio de argumentos de linha de comando a serem passados ​​para docker run .

Direito. @orikremer , você tem detalhes sobre os parâmetros que o Vertica DB e o WebSphere MQ estavam tentando alterar?

Se estiver em / sys ou / proc, a melhor solução pode ser colocar alguma simulação lá, em vez de alternar para o modo privilegiado (já que as alterações não serão persistidas de qualquer maneira).

No longo prazo, um sistema de arquivos fictício pode capturar a mudança e convertê-los em diretivas Dockerfile, instruindo o tempo de execução que "ei, este contêiner precisa de tal ou tal ajuste".

@jpetazzo Já se passaram alguns dias desde que criei a imagem. AFAIR Vertica estava reclamando que não tem memória suficiente e ambos estavam tentando alterar o máximo de arquivos abertos.
Vou tentar recriar a imagem usando um Dockerfile e relatar de volta.

Observando o problema nº 2080 conforme ele está relacionado.

@jpetazzo começou a recriar a imagem sem -privilegiado. Dois problemas até agora:

• nice em limits.conf: Vertica adiciona "dbadmin - nice 0" a /etc/security/limits.conf. Ao tentar alternar para esse usuário durante a execução em um contêiner sem privilégios, recebo um erro "não foi possível abrir a sessão". Em uma troca de contêiner privilegiado, o usuário trabalha sem erros.
• máximo de arquivos abertos: como o máximo necessário no contêiner era maior do que o definido no host, tive que alterar /etc/init/docker.conf no host e definir "limit nofile" e ulimit -n no contêiner. Essa é a abordagem correta?

Ao tentar mudar para esse usuário,

Como a troca acontece? Não entendo como -privileged ajudaria na troca de usuário; Provavelmente estou faltando alguma coisa aqui :-)

máximo de arquivos abertos

Se bem entendi, o instalador vertical tenta definir o número máximo de arquivos abertos para um número muito alto, e isso só funciona se o Docker foi iniciado com um número tão alto _ou_ com a sinalização -privileged ; direito?

trocar de usuário - su dbadmin falha com esse erro.
Consegui reproduzir por:

• extraia uma nova imagem (centos-6.4-x86_64) e execute sem privilégios
• useradd testuser
• edite /etc/security/limits.conf, adicione "testuser - nice 0"
• tente su testuser -> deve falhar com "não foi possível abrir a sessão"
  Em um contêiner privilegiado, su testuser funciona bem.

arquivos abertos máximos - correto. o instalador tenta definir um número maior do que o do host. Somente aumentando a configuração de hosts ou iniciando -privilegiado isso funciona.

Acabei de tentar com o seguinte Dockerfile:

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

E funciona bem. Qual é o nome exato da imagem que você está usando?
(Eu tentei centos-6.4-x86_64 mas parece que não consigo puxá-lo!)

@lukewpatterson Você pode compartilhar como fez o sistema de arquivos de loop funcionar dentro do seu contêiner?

@jpetazzo Executando este arquivo docker

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

falhou com:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

Ativei a depuração do módulo PAM (adicionando debug à linha pam_limits.so em /etc/pam.d/system-auth ), instalei syslog e tentei su novamente, e aqui está o que encontrei em /var/log/secure :

7 de outubro 14:12:23 8be1e7bc5590 su: pam_limits (su: sessão): lendo as configurações de '/etc/security/limits.conf'
7 de outubro 14:12:23 8be1e7bc5590 su: pam_limits (su: sessão): process_limit: processamento - bom 0 para USUÁRIO
7 de outubro 14:12:23 8be1e7bc5590 su: pam_limits (su: sessão): lendo as configurações de '/etc/security/limits.d/90-nproc.conf'
7 de outubro 14:12:23 8be1e7bc5590 su: pam_limits (su: sessão): process_limit: processando soft nproc 1024 para DEFAULT
7 de outubro 14:12:23 8be1e7bc5590 su: pam_limits (su: sessão): Não foi possível definir o limite para 'nice': Operação não permitida

Então eu strace d o processo su e descobri que a seguinte chamada de sistema estava falhando:

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

Isso, por sua vez, faz com que o módulo pam_limits relate uma falha; e isso evita que su continue.
Curiosamente, no Ubuntu, pam_limits não está habilitado para su por padrão; e mesmo se você habilitá-lo, a chamada setrlimit falha, mas su continua e funciona de qualquer maneira.
Pode estar relacionado ao código de auditoria, não tenho certeza.

Agora, por que setrlimit falhando? Porque o contêiner está faltando a capacidade sys_resource , que é necessária para aumentar qualquer tipo de limite.

Acho que gostaria apenas de comentar essa diretiva limits.conf .
(A propósito, não é uma prática adicionar coisas diretamente a limits.conf ; deve ir para um arquivo separado em limits.d , eu acho.)

Nota: como você já aumentou o limite para o número de arquivos abertos para o Docker, você também pode aumentar o limite para a prioridade máxima; isso deve funcionar também!

Eu espero que isso ajude.

Nesse Dockerfile, você tem a seguinte linha por si só:

RUN su testuser

Não há nenhum comando para acompanhar isso (e não aplicará nenhum shell resultante aos comandos RUN subsequentes), então eu não ficaria surpreso se ele realmente falhe ao tentar abrir um shell e não estar em algum lugar interativo que faça sentido (já que docker build não é um processo interativo). Não tenho tempo agora para confirmar, mas provavelmente vale a pena tentar com um comando real sendo passado para su .

@jpetazzo Obrigado pela descrição detalhada. Vou tentar aumentar a prioridade máxima do Docker e ver se isso ajuda.

(A propósito, não é uma boa prática adicionar coisas diretamente a limits.conf; deve ir para um arquivo separado em limits.d, eu acho.)

Concordo, mas como este é o código do instalador Vertica que o está colocando lá, estou tentando contornar isso.

@tianon O mesmo acontece se eu executar isso em um shell interativo (/ bin / bash).

Minhas desculpas, acho que ainda valeu a pena tentar.

A questão sobre essa linha não fazer muito sentido no Dockerfile ainda se aplica. Você provavelmente queria algo mais parecido com isto (depois de descobrir os problemas de limites):

RUN su testuser -c 'echo test > ~/test.txt'

@tianon você está certo, não faz muito sentido. Isso foi apenas para demonstrar que o próprio su falha.

Para voltar à discussão original: Eu acredito que é bom do ponto de vista de segurança (e útil!) Permitir setfcap e mknod recursos no processo de construção (e provavelmente na execução regular do contêiner como Nós vamos). Alguém vê algum problema que possa decorrer disso?

@jpetazzo Muito pelo contrário! Isso resolveria muitos problemas que estou encontrando. Acho que isso é necessário para pessoas que desejam executar contêineres Docker que agem / parecem mais uma máquina real.

OK! Se estiver tudo bem para você, estou encerrando este problema em favor de # 2191, "Habilitar os recursos mknod e setfcap em todos os contêineres" então :-)

Nós sabemos sobre esses cenários?

No domingo, 13 de outubro de 2013 às 12h22, unclejack [email protected] :

2191 https://github.com/dotcloud/docker/issues/2191 não resolve isso

problema para todos os cenários que exigiriam o privilégio de compilação do docker.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

@jpetazzo https://twitter.com/jpetazzo
Última postagem do blog:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Isso é necessário quando você deseja usar um Dockerfile para construir uma imagem do sistema operacional.

Excluí meu comentário por engano ao editá-lo.

Por favor, dê uma olhada em como isso ficaria sem fazer tudo em um Dockerfile:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

Isso está me forçando a contornar a falta de runp no Dockerfile ou docker build -privileged , tornando os Dockerfiles inúteis e me forçando a escrever uma ferramenta para duplicar a funcionalidade do tipo Dockerfile.

Obviamente, o Dockerfile seria muito mais útil com runp ou docker build -privileged :
exemplo runp:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged exemplo:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : desculpe, minha pergunta não foi precisa o suficiente!
O que eu quis dizer foi "de qual permissão você precisa exatamente (além do mknod e do setfcap)?"

@jpetazzo É difícil dizer, eu teria que auditar isso de alguma forma para descobrir o que é necessário. Montagem de sistemas de arquivos, uso de dispositivos de bloco montados em loopback e algumas outras coisas.

Existem pelo menos três necessidades distintas quando se trata de construir imagens: permissões necessárias durante docker build , permissões necessárias ao executar um contêiner com docker e necessidades de tempo de execução para processos durante a construção, execução ou ambos (como sysctls e outros) .

Acho que docker build -privileged (ou runp para usar o modo privilegiado apenas para os comandos que realmente precisam) seria útil.

Ah, montagens são definitivamente um grande problema. Esse é um caso de uso muito válido e _provavelmente_ não queremos permiti-lo no caso geral. Estou reabrindo o problema.

@jpetazzo RE: Módulo PAM (estou instalando o Vertica também), você sugere recompilar o docker depois de retirar o sys_resource do lxc.cap.drop?

Talvez alguns desses limites possam ser definidos por meio do arquivo docker.conf?

Deve-se considerar que o próprio Docker pode estar sendo executado em um conjunto limitado de recursos, pelo qual esses privilégios podem não estar disponíveis para o Docker delegar a seus contêineres. Isso seria especialmente verdadeiro em um cenário de Docker aninhado e deveria emitir # 2080 land - isso pode permitir Docker aninhado sem privilégios.

Não que isso mude nada, exceto que soluções como 'runp' ou '-priviledged' podem não ter sucesso garantido em todos os ambientes Docker. Isso deve ser considerado ao adicionar tais comandos e ao documentá-los.

@ramarnat @jpetazzo apenas para fechar o ciclo na instalação do Vertica e no bom problema de nível,
Eu tentei definir o limite legal no docker.conf, mas isso não funcionou para mim e fui forçado a executar o bash com privilégios e instalá-lo manualmente.

@orikremer @jpetazzo Consegui executar a instalação removendo sys_resource do lxc_template.go e recompilando o docker. Posso colocar uma solicitação pull lá, mas vou esperar que outros opinem sobre as implicações de segurança de remover isso da configuração do lxc.

@ramarnat : dependendo do cenário, algumas pessoas vão pensar que remover sys_resource é bom; para alguns outros, será um problema.

Uma possibilidade poderia ser aumentar os limites da base para algo mais alto (os descritores de arquivo também são um problema para o Elastic Search). Isso seria como afirmar "um tempo de execução mínimo do Docker deve ser capaz de lidar com 1.000.000 de descritores de arquivo". Se o Docker não puder aumentar o limite ao iniciar, ele emitirá um aviso e continuará (como faz para o grupo de controlador de memória / troca).

Isso não corrige o cenário de montagem / loop, embora (ainda estou dormindo sobre este).

@jpetazzo pode fornecer uma maneira de substituir os valores codificados em lxc_template.go. Já existe algo para o cenário com a linha de comando -lxc_conf, mas não funciona para a natureza .drop dessas diretivas de configuração lxc - eu tentei!

Bem, isso é uma possibilidade, mas também é uma boa maneira de quebrar a compatibilidade futura entre diferentes sistemas de contêineres :-) Veremos se não podemos encontrar nada melhor.

Podemos colocar / dev / loop * na lista de permissões no modo não privilegiado? Suponho que o problema é que ele pode me dar acesso aos arquivos montados em loop de outro contêiner, ou até mesmo do host ...

@solomonstre
@docker

Na quinta-feira, 17 de outubro de 2013 às 18h09, Jérôme Petazzoni
notificaçõ[email protected] escreveu:

Bem, isso é uma possibilidade, mas também é uma boa maneira de quebrar a compatibilidade futura entre diferentes sistemas de contêineres :-) Veremos se não podemos encontrar nada melhor.

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo Isso é verdade, mas eu acho que o docker precisará de uma maneira padrão de sobrescrever a configuração dos sistemas de contêinerização subjacentes se for permitido - de volta à consideração privilegiada de construção, eu acho!

@solomonstre A questão é que deve haver uma maneira de permitir que docker build construa em modo privilegiado. Permitir acesso a / dev / loop * não me ajudará em meu caso de uso específico.

@solomonstre : whitelisting / dev / loop é, IMHO, uma grande falta de nenhum, porque com o ramo DM, daria acesso de leitura / gravação a tudo (uma vez que o comportamento padrão do ramo DM é usar dispositivos de loop para armazenar o piscinas).

Eu entendo que algumas compilações exigirão dispositivos de loop, montagens e outras coisas. Vamos revisar nossas opções:

1. docker build -privileged
   Conveniente, mas traça a linha entre "compilações normais" e "compilações privilegiadas". Se você tiver uma imagem muito útil que requer um construtor privilegiado, será difícil construí-la em construtores públicos. Por exemplo, se alguém iniciar um serviço para automatizar compilações, provavelmente não oferecerá compilações com privilégios (ou terá que usar proteções extras).
2. Relaxe um pouco as permissões no construtor
   Isso significa (pelo menos) habilitar cap_sysadmin (isso faz o paranóico me estremecer um pouco), e talvez dar um ou dois dispositivos de loop para cada construtor. Isso limitaria o número total de construtores em execução em paralelo; mas não é um grande problema, já que as compilações devem ser processos rápidos e, mais importante, ativos. Ou seja, se você tiver 50 compilações rodando em paralelo, a menos que você tenha uma máquina com um subsistema de E / S kickass, essas compilações não irão progredir muito.
3. Envolva a construção em outra camada de virtualização / isolamento.
   Em vez de executar a construção diretamente no Docker, execute algo como QEMU-in -Docker ou UML-in-Docker. Esta é uma solução interessante do ponto de vista do desenvolvedor Docker, pois não significa nenhum trabalho adicional; esta é uma solução pobre do ponto de vista do usuário DOcker, pois significa lidar com outra camada de complexidade.

Eu me pergunto se a solução certa seria permitir docker build -privileged` e, ao mesmo tempo, pensar em ganchos que permitiriam uma implementação transparente da opção 3. Suponha que eu seja um "provedor de compilação docker": se Se alguém solicitar uma construção privilegiada, tudo que preciso fazer é inserir algo em algum lugar para executar o processo de construção em um ambiente de área restrita (QEMU e UML são candidatos óbvios, mas outras também podem funcionar; são apenas exemplos convenientes).

O que é que vocês acham?

@backjlack , posso perguntar como você usa esse contêiner depois de construído? O que
acontece quando você "executa o docker" exatamente, qual é o aplicativo? Somente
tentando ter uma noção dos casos de uso para isso.

Na sexta-feira, 18 de outubro de 2013 às 9h59, Jérôme Petazzoni
notificaçõ[email protected] :

@solomonstre https://github.com/solomonstre : whitelisting / dev / loop é,
IMHO, uma grande falta de nenhum, porque com o ramo DM, daria leitura / gravação
acesso a tudo (uma vez que o comportamento padrão do ramo DM é usar
dispositivos de loop para armazenar as piscinas).

Eu entendo que algumas construções exigirão dispositivos de loop, montagens e outros
coisas. Vamos revisar nossas opções:

1. docker build -privileged Conveniente, mas traça a linha entre
   "compilações normais" e "compilações privilegiadas". Se acontecer de você ter um
   imagem útil que requer um construtor privilegiado, será difícil
   construí-lo em construtores públicos. Por exemplo, se alguém iniciar um serviço para automatizar
   compilações, eles provavelmente não oferecerão compilações privilegiadas (ou terão
   para usar proteções extras).
2. Relaxe um pouco as permissões no construtor. Isso significa (pelo menos)
   habilitar cap_sysadmin (isso me deixa paranóico estremecer um pouco), e talvez
   dando um ou dois dispositivos de loop para cada construtor. Isso limitaria o total
   número de construtores executando em paralelo; mas não é grande coisa desde
   as compilações devem ser processos rápidos e, mais importante, ativos.
   IE, se você tiver 50 compilações rodando em paralelo, a menos que você tenha uma máquina
   com um subsistema de I / O incrível, essas compilações não progredirão muito.
3. Envolva a construção em outra camada de virtualização / isolamento.
   Em vez de executar a compilação diretamente no Docker, execute algo como
   QEMU-in -Docker ou UML-in-Docker. Esta é uma solução legal de um Docker
   ponto de vista do desenvolvedor, uma vez que não significa nenhum trabalho adicional; este é um pobre
   solução do ponto de vista do usuário DOcker, pois significa lidar com
   outra camada de complexidade.

Eu me pergunto se a solução certa seria permitir docker build-privileged`,
e ao mesmo tempo, pense em ganchos que permitiriam
implementação da opção 3. Suponha que eu seja um "provedor de compilação docker": se
alguem solicita uma compilação privilegiada, tudo que eu preciso fazer é inserir
algo em algum lugar para executar seu processo de construção dentro de uma área restrita
ambiente (QEMU e UML são candidatos óbvios, mas outros podem funcionar
também; são apenas exemplos convenientes).

O que é que vocês acham?

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - Eu gostaria de ver os recursos do mknode para instalar o fusível (para montar baldes S3) ou a capacidade de executar execuções privilegiadas em Dockerfiles. Ainda não tenho certeza de qual é a melhor solução.

+1. Alguma atualização para esse problema?

+1
Em 17 de novembro de 2013, 23h31, "yukw777" [email protected] escreveu:

+1. Alguma atualização para esse problema?

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

Também encontrei o problema do Fuse ao tentar instalar o Java e estou interessado em uma solução. Tentei a solução alternativa sugerida aqui https://gist.github.com/henrik-muehe/6155333, mas não funciona para mim no docker no Raspberry Pi.

@jpetazzo : Gosto da estratégia geral de implementar a sinalização -privileged enquanto, ao mesmo tempo, exploro uma solução de longo prazo. Para esse fim, enviei uma solicitação pull para implementar esse recurso. Observe que, a partir de agora, ele não implementa o comando "RUNP" conforme discutido anteriormente neste tópico.

(Deixe-me "postar" isso, já que as pessoas podem acabar aqui procurando uma solução alternativa)

Se você não estiver realmente usando o arquivo do dispositivo (mas é apenas parte de um script pós-inst, como no caso do pacote de fusíveis), você pode fazer:

fakeroot apt-get ...

ou:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

Tenho certeza de que foi bem-intencionado, mas o primeiro comentário / meu relatório já incluía duas soluções alternativas.
Para ser justo, você adicionou novos à lista, mas o problema não é 'Não é possível instalar o fusível' e ler o primeiro post deve ajudar aquelas pessoas que só precisam do pacote para instalar, não importa o que aconteça.

O verdadeiro problema é 'Preciso chamar mknod' (ou mais genérico: preciso de operações privilegiadas que falham até agora).

@jpetazzo Isso poderia consertar isso, certo? https://lwn.net/Articles/564977/ - Até então, eu escolheria 3) porque isolar o acesso ao dispositivo _é_ outra camada de complexidade e deve ser gerenciado em algum lugar.

Também não estou convencido de que a montagem em loop ou fusível é um recurso necessário. Parece loucura dar a um contêiner em espaço de uso permissões de root para montar um sistema de arquivos que está (fusível: execução é executada, loop: arquivo de imagem está) no espaço do usuário.

Se você precisar montar uma imagem do sistema de arquivos ou fundir fs, poderá montá-lo fora do contêiner e usá-lo como montagem de volume / ligação. Embora possa ser um bom recurso oferecer suporte e gerenciar sistemas de arquivos remotos no docker. Talvez um dockerfile MOUNT/ponto de montagem.

@discordianfish 3) é praticamente uma não solução.

o nº 2979 ajudaria com esse problema?

Estou esperando uma resolução para isso também, mas não por causa do mknod. Estamos executando contêineres centos com rpms que definem limites para usuários usando /etc/security/limits.d/ e, atualmente, estou usando uma solução alternativa de martelo que consiste em:

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

na parte superior do meu Dockerfile. (Estamos apenas fazendo um protótipo, não se preocupe :))

Olá, @jpetazzo , tentei as duas opções que você sugeriu. Estou tentando construir uma imagem "oracle_xe" usando

sudo docker build - privileged -t oracle_xe porque em meu Dockerfile eu quero executar estes 2 comandos

RUN mount -o remount, size = 3G / dev / shm
RUN mount -a

Mas isso não funciona, não sei se a sintaxe que usei está incorreta, o erro que recebo é
sinalizador fornecido, mas não definido: -privilegiado

Eu também tentei a segunda opção para usar RUNP, mas isso também não funcionou, quando eu construí a imagem, ele pula essa etapa dizendo

Ignorando a instrução RUNP desconhecida. Posso enviar a você o Dockerfile que estou tentando construir. Por favor me ajude a resolver este problema.

Obrigado.

Acho que nem RUNP nem "build --privileged" foram implementados.
Se possível, não hesite em compartilhar o Dockerfile; poderia ser útil então
podemos fornecer a solução alternativa "menos pior" :-)

Na quarta-feira, 9 de abril de 2014 às 7h44, Manoj7 [email protected] escreveu:

Olá, jpetazzo, tentei as duas opções que você sugeriu. Estou tentando construir
uma imagem "oracle_xe" usando

sudo docker build - privileged -t oracle_xe porque em meu Dockerfile i
deseja executar estes 2 comandos

RUN mount -o remount, size = 3G / dev / shm
RUN mount -a

Mas se isso não funcionar, não sei se a sintaxe que usei é
incorreta. Eu também tentei a segunda opção para usar RUNP, mas isso também não
trabalho, quando eu construo a imagem, ele pula essa etapa dizendo
Ignorando a instrução RUNP desconhecida. Posso enviar-lhe o Dockerfile que sou
tentando construir. Por favor me ajude a resolver este problema.

Obrigado.

Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

@jpetazzo https://twitter.com/jpetazzo
Última postagem do blog:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Olá @jpetazzo , gostaria de fazer um "RUN sudo umount / etc / hosts" no meu Dockerfile - existe uma solução "menos pior" para isso? ;)

@jpetazzo

O Dockerfile que usei para construir a imagem oracle_xe

De *

MAINTAINER * * * * * * *

ADICIONE oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN mount -o remount, size = 3G / dev / shm
RUN mount -a
EXECUTE cd / appl / oracle / xe && descompacte oracle-xe-11.2.0-1.0.x86_64.rpm.zip
EXECUTE cd / appl / oracle / xe / Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
EXECUTE cd / appl / oracle / xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

A primeira coisa que tentei foi

sudo docker build -privileged -t oracle_xe.

Isso não funcionou e então tentei usar o RUNP
RUNP mount -o remount, size = 3G / dev / shm
RUNP mount -a
isso também não funcionou, essas duas etapas foram puladas.

@gatoravi : infelizmente, desmontar / etc / hosts não funcionará facilmente. Por que você precisa fazer isso? (Eu entendo que você pode ter motivos muito válidos, mas adoraria ouvi-los para fornecer a melhor solução alternativa ...)

@ Bhagat7 : certo! Pergunta: você precisa de um / dev / shm maior no tempo de execução _e_ no tempo de instalação ou apenas no tempo de execução? Se estiver no momento da construção, qual etapa está falhando e como?

@jpetazzo Eu gostaria de adicionar um novo endereço IP a / etc / hosts como parte do processo de construção da minha ferramenta.
Algo como echo $IP $HOST >> / etc / hosts.

Posso fazer isso muito bem se usar docker run --privileged e, em seguida, fizer um sudo umount \etc\hosts mas parece que não posso confirmar isso usando docker commit portanto, tenho que repetir umount passo a cada vez manualmente quando executo um contêiner.

Eu gostaria de alguma forma de tornar \etc\hosts gravável e persistente; não consigo encontrar uma maneira de fazer isso com docker commit ou com um Dockerfile.

@jpetazzo

Eu tive esse problema

bash-4.1 # / etc / init.d / oracle-xe configure
Especifique a porta HTTP que será usada para Oracle Application Express [8080]:

Especifique uma porta que será usada para o ouvinte do banco de dados [1521]: 1521

Especifique uma senha a ser usada para contas de banco de dados. Observe que o mesmo
a senha será usada para SYS e SYSTEM. A Oracle recomenda o uso de
senhas diferentes para cada conta do banco de dados. Isso pode ser feito após
configuração inicial:
Confirme a senha:

Você deseja que o Oracle Database 11g Express Edition seja iniciado na inicialização (s / n) [s]: s

Iniciando o Oracle Net Listener ... Concluído
Configurando banco de dados ... Concluído
Iniciando instância do Oracle Database 11g Express Edition ... Feito
Instalação concluída com sucesso.
bash-4.1 # cd /u01/app/oracle/product/11.2.0/xe/bin
base-4.1 # sqlplus
Digite o nome de usuário: sistema
Digite a senha: * **
Mas eu recebo este erro
ORA-01034: ORACLE não disponível
ORA-27101: domínio de memória compartilhada não existe
Erro Linux-x86_64: 2: arquivo ou diretório inexistente
ID do processo: 0
ID da sessão: 0 Número de série: 0
df -h dentro do contêiner retornado
Tamanho do sistema de arquivos usado% de uso disponível montado em
tmpfs 64M 0 64M 0% / dev / shm

Então, quando aumentei o tamanho do tmpfs para 3G, não recebi esse erro. Resolvi isso executando o contêiner como
sudo docker run -privileged -i -t oracle_xe / bin / bash. Executei os 2 comandos de montagem dentro do contêiner. Mas não quero fazer dessa forma, em vez disso, quero colocá-los em meu Dockerfile e criá-lo.

@gatoravi : OK, entendido. Mais duas perguntas então: você precisa desses hosts extras em / etc / hosts durante a construção ou apenas durante a execução? E por que você precisa disso?

@ Bhagat7 : Desculpe, ainda não tenho uma solução elegante para isso :-( Eu sugiro dois Dockerfiles:

• um primeiro que faz todas as etapas (exceto a que requer o / dev / shm maior) e define um CMD que verificará se o contêiner está rodando em modo privilegiado, montará o / dev / shm maior e executará o especial comando;
• um segundo Dockerfile para realizar outras etapas (a menos que você também precise de / dev / shm no tempo de execução, então, por enquanto, você precisa de algo privilegiado).

@jpetazzo Gostaríamos de fornecer aos nossos usuários uma imagem (/ container) com um / etc / hosts / editável para que eles possam construir nosso código que modifica esse arquivo :) Por que precisamos adicionar o host, eu ' Não tenho certeza para ser honesto, fazemos isso como parte de nossa instalação para ajudar a apontar certos nomes de host para endereços IP.

@ Bhagat7 Consegui fazer o oracle XE rodar em um contêiner docker 0.9 usando uma combinação de:

1. https://github.com/wnameless/docker-oracle-xe-11g
   e
2. no hospedeiro ...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters Muito obrigado por responder. Acho que você construiu o Oracle XE com base no Ubuntu. Mas estou tentando construir no Centos.

@jpetazzo Muito obrigado por sua sugestão

Oi, pessoal,

Estou usando o google-chrome que precisa gravar /dev/shm que parece ser geralmente 777 e é 755 aqui. Tentei adicionar uma configuração específica ao meu /etc/fstab mas não consigo executar mout -a para aplicar as modificações em uma compilação. Claro que experimentei o chmod básico ou chown mas também não consigo fazer na versão.

Se eu usar meus comandos quando estiver conectado no modo --privileged , está tudo OK. Mas eu preciso, como outras pessoas explicaram, fazer isso no build.

Alguma sugestão?

Obrigada.

@tomav o problema de permissões "/ dev / shm" é na verdade # 5126, que foi corrigido no # 5131 e já está integrado ao mestre (e estará na próxima versão)

Obrigado @tianon.

hoje eu tive esta ideia: eu quero um container gerenciando meus volumes de dados. fácil, mas como estou em um vps, quero esses volumes criptografados, mas fornecidos a outros contêineres, como de costume, em claro. o ponto é, simplesmente não ter dados claros no disco virtual e uma maneira rápida de destruir, excluindo a chave.

Eu segui algumas das etapas lindamente documentadas neste artigo sobre a criação de um cryptfs para colocar contêineres: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

observe que _não_ estou tentando fazer isso, mas na verdade tenho um contêiner com um cryptfs montado:
portanto, um sistema de arquivos criptografado deve ser criado, montado e formatado durante a compilação via docker.

que falha:

• quando tento encontrar um dispositivo de loop:

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• estranhamente, o mesmo dockerfile _ às vezes_ consegue encontrar um dispositivo de loop, então:

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

existe uma maneira de contornar isso ainda? (além de mover as etapas de montagem / formatação de disco para run )

+1 Seria especialmente útil para ambientes "docker em docker"

+1 sobre isso, o iptables não funciona no modo sem privilégios, o que faz com que qualquer coisa que tente configurar as regras do firewall falhe.

@PerilousApricot : note, entretanto, que mesmo se você pudesse definir uma regra iptables em RUN , ela seria perdida imediatamente, já que uma imagem mantém apenas o estado do sistema de arquivos. Ele não sabe sobre processos em execução, rotas de rede, regras de iptables, etc.

Por mim tudo bem, já que o contêiner teria apenas portas específicas
encaminhado, não estou preocupado com o firewall, principalmente quero apenas o
instalador para ser capaz de ter sucesso em tudo

Andrew melo

@PerilousApricot entendo! Nesse caso, que tal vincular iptables a /bin/true ? Isso também deve deixar o instalador feliz. (Ou algum truque semelhante para enganar o instalador?)

Eu tentei isso, mas o instalador também precisa analisar a saída de
iptables, por isso não é tão fácil :)

OK, eu sei que isso está ficando hackeado, mas - que tal colocar um falso iptables vez disso? O que geraria alguma saída fictícia?

Eu entendo totalmente que não é ótimo; mas, falando sério, esse tipo de instalador deve ser consertado em primeiro lugar :)

O docker no caso de uso do docker é o que me trouxe aqui. Bem, docker no lxc, para ser específico, já que nosso ambiente de desenvolvimento usa lxc, e eu gostaria que os desenvolvedores pudessem construir as imagens no lxc.

Eu gostaria disso para docker no docker também. Há uma imagem que precisa ser extraída antes que o aplicativo possa ser executado, que é bastante grande, e eu prefiro que ela seja extraída e armazenada em cache como parte de docker build vez de precisar extrair e / ou confirmar com frequência recipientes que têm puxado.

Este recurso é um IMHO obrigatório, uma combinação de RUNP junto com build-privileged seria ótima.

O cenário de vida real / produção que enfrentei são imagens do Docker construídas com provisionamento Puppet em um contêiner intermediário. Em certos serviços que requerem recursos elevados, há falhas na construção exigindo que o contêiner seja executado em -privileged com um ENTRYPOINT ou CMD que reaplica o script fantoche.

Isso atrasa o tempo de inicialização do serviço real dentro do contêiner, pois a configuração do fantoche precisa ser construída e, em seguida, aplicada para garantir o estado adequado (e isso é demorado), bem como o contêiner em execução _pode_ não precisar estar em -privileged reais Modo

Espero que o acima faça sentido.

@jpetazzo Estou tentando construir um servidor web em cima do centos6. Estou perdido na configuração de regras de iptable por meio do dockerfile. É semelhante ao problema de

btw: NÃO estou para implementar os hacks, como um iptables falso.

@pmoust : você tem detalhes sobre quais operações de construção requerem privilégios elevados? Provavelmente irei recomendar que você evite o problema, e estou totalmente ciente de que isso pode não ser satisfatório para você; mas, mesmo assim, ficaria feliz em entender que tipo de instalador / construtor pode exigir esses privilégios ...

@ passion4aix : observe que se você definir regras de iptables no Dockerfile, elas NÃO serão salvas. O Docker salva apenas o estado do sistema de arquivos, não os processos de roteamento / filtragem / execução ... Existem maneiras de configurar regras de iptables com contêineres "auxiliares". Isso é algo que poderia ser interessante para você?

@jpetazzo O instalador Bitrock é um exemplo. Requer que / tmp seja montado como tmpfs. Você pode querer dar uma olhada em http://answers.bitrock.com/questions/3092/running-installer-inside-docker

@jpetazzo ou basicamente qualquer instalador openstack

Eu também encontrei um problema semelhante ao tentar executar o TokuMX em um contêiner do Docker, pois o TokuMX requer que a opção de kernel 'transparent_hugepage' seja desabilitada.

Existe algum progresso nesta questão? Já tem mais de um ano e, olhando os comentários, a maioria das pessoas usa para executar ações privilegiadas a partir de um Dockerfile.

Pessoalmente, eu não optaria pela solução de compilação com '--privileged'. A solução RUNP é melhor, pois você só pode executar algumas ações como usuário privilegiado em vez de executar toda a instalação como privilegiado. Dessa forma, pelo menos você deve pensar em quando usar o RUNP e apenas quando necessário.

Parece-me que a questão não é mais SE essa opção deve ser adicionada, mas apenas quando for feita. Então, quando podemos esperar essa funcionalidade?

@diversit Eles teriam que ser acoplados. Portanto, --privileged na linha de comando habilitaria a capacidade de usar RUNP , caso contrário, isso seria um pesadelo de segurança para pessoas que fazem compilações de código não confiável (incluindo DockerHub).

Mas também lembre-se de que você pode fazer isso manualmente fora da sintaxe do Dockerfile. O processo de construção está lendo o Dockerfile, criando um contêiner a partir dele e enviando-o de volta para uma imagem.

@deas : Acho que isso pode ser resolvido com VOLUME /tmp .

@PerilousApricot : você pode elaborar um pouco? Não entendo por que qualquer tipo de instalador exigiria privilégios especiais. (Sim, sou um cara velho e teimoso do Unix, esse é um dos meus defeitos: D)

@diversit : para esse caso específico, acho que o administrador da máquina deve desabilitar o widescreen transparente antes de compilar. Porque se o construtor tiver permissão para fazer isso, ele o fará globalmente (certo?) E pode quebrar outros contêineres que podem exigir o recurso. Você entende o que quero dizer? Seria ruim se a construção do contêiner X quebrasse a execução do contêiner Y ...

Todos: Eu entendo perfeitamente que é super frustrante quando um Dockerfile não funciona e tudo que você precisa é esta sinalização --privileged / RUNP . Mas se começarmos a ter compilações privilegiadas, isso vai quebrar um monte de coisas (por exemplo, compilações automatizadas no Docker Hub!), Então é por isso que nos sentimos muito mal a respeito. E pelo que vale a pena, estou disposto a investigar todos os cenários que requerem compilações privilegiadas e ajudar a corrigi-los :-) (já que é minha convicção pessoal que esses instaladores estão quebrados!)

@jpetazzo Muitas / a maioria das ferramentas de implantação do

Além disso, acho que é uma troca justa dizer: "Se você tem um Dockerfile que requer compilações privilegiadas, você perde os recursos X, Y, Z"

O Oracle xe não será executado sem espaço de memória compartilhado suficiente. Todas as contas remontam tmpfs com espaço suficiente tornam o Oracle xe feliz em inicializar e completar sua configuração .. (para aqueles com percepção, é a etapa '/etc/init.d/oracle-xe configure' que reclama sobre as limitações de memória alvo rumores de serem superados aumentando o tamanho da montagem)

Durante uma construção
RUN desmontar tmpfs
falha com
umount: / proc / kcore: deve ser superusuário para umount

dê-me RUNP ou dê-me a morte .... ou .... mostre-me o que poderia ser diferente :)

Meu exemplo é inválido; @jpefazzo ainda está de pé :) Minhas configurações do Oracle estavam causando o problema e parece não haver necessidade de ajustar o tamanho do tmpfs ... pelo menos para a instalação inicial.

Estou tendo um problema de iptables no CentOS 7.0 que só é resolvido quando run ning com --privileged https://github.com/docker/docker/issues/3416

Sem suporte para construção privilegiada, não tenho certeza de como contornar o problema

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley , acredito que com o security-opts em # 8299 será possível fazer isso sem --privileged

@jpetazzo Não vejo como usar VOLUME /tmp resolve o problema dos instaladores Bitrock. Isso pode funcionar para a construção, mas também fará com que /tmp ignore a estratificação AUFS para todos os contêineres baseados nessa imagem, certo? No final do dia, parece que a causa raiz deve ser corrigida no AUFS.

Este é meu caso de uso: eu quero construir um ambiente chroot dentro de um contêiner docker. O problema é que debootstrap não pode ser executado, porque não pode montar proc no chroot:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Se eu run --privileged o contêiner, ele (é claro) funciona ...
Eu realmente gostaria de debootstrap o chroot no Dockerfile (muito, muito mais limpo). Existe uma maneira de fazer funcionar, sem esperar por RUNP ou build --privileged?

Muito obrigado!

+1 para --privilegiado ou montagem. Necessidade de automatizar a construção de glusterfs

Isso está afetando meus esforços para construir uma imagem do instalador Bitnami Tomcat. 99% do processo de instalação é executado sem problemas, mas, quando ele tenta iniciar o tomcat pela primeira vez, falha com a seguinte saída em catalina-daemon.out:

set_caps: falha ao definir recursos
verifique se o seu kernel suporta capacidades
set_caps (CAPS) falhou para o usuário 'tomcat'
Saída de serviço com um valor de retorno de 4

Posso executar com êxito o instalador do Tomcat manualmente em um contêiner que criei com "--cap-add ALL". Parece estranho não poder usar 'docker build' para criar uma imagem que possa ser criada manualmente usando 'docker run' e depois 'docker commit'. Os contêineres que são usados ​​durante o processo de construção devem ter todas as funcionalidades dos contêineres que você pode criar usando 'docker run'.

@gilbertpilz Eles explicitamente não podem fazer isso para garantir a portabilidade e segurança do build.

@ cpuguy83 - Isso não faz sentido. Posso construir a imagem que quero, manualmente, se fizer:

docker run --cap-add ALL .... / bin / bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
saída
docker commit ....

Tudo o que estou pedindo é a capacidade de usar o "docker build" para fazer a mesma coisa que estou fazendo manualmente aqui. Não consigo ver como "portabilidade e segurança" estão sendo "garantidas" se eu puder criar a imagem de uma forma, mas não de outra.

Ok, deixe-me dar a você um Dockerfile que monta o / etc / passwd do host no construtor e acaba enviando-o para mim.

Isso pode ser perigoso.
Observe também que --privileged (e --cap-add ALL) dá ao usuário no contêiner o controle total do host.

Permitir essas coisas comprometeria todo o DockerHub

@ cpuguy83 - Você não precisa colocar o controle no Dockerfile. Você pode adicionar a opção "--cap-add" (ou algo semelhante) ao comando "docker build". Se seguirmos sua lógica, os scripts de shell não deveriam permitir o uso do comando "sudo" porque alguém poderia escrever um script que fazia coisas ruins.

Mas você não daria sudo a alguém em quem não confiasse de forma implícita as chaves do reino.
O Build deve ser capaz de, da forma mais segura possível, executar código não confiável.

A introdução de sinalizadores CLI para habilitar recursos extras no build quebra a portabilidade do build, e é por isso que ele ainda não foi adicionado.

Dito isso, o instalador quase certamente está errado aqui, solicitando coisas às quais ele próprio não deveria ter acesso.

Exatamente. Você não deve dar às pessoas em quem não confia a capacidade de executar builds do docker que requeiram privilégios, mas o docker não deve impedir que as pessoas em quem você confia façam isso. Esta é uma decisão política e realmente não gosto quando as ferramentas presumem tomar decisões políticas por mim. Uma boa ferramenta permite-me implementar as decisões políticas que tomei de uma forma clara e não surpreendente.

Você não está vendo o quadro geral.

Esse ecossistema é mais do que seu servidor e meu servidor. DockerHub, por exemplo, está fazendo compilações de código não confiável o tempo todo.

Então o DockerHub definitivamente _não_ deve permitir a adição de recursos para suas compilações. Se isso significa que não posso enviar minha compilação do docker para o DockerHub, tudo bem.

@ cpuguy83 @tianon @jpetazzo - Quando o FUD começa, sou compelido a falar:

Permitir essas coisas comprometeria todo o DockerHub

sério?
Implementando este recurso == TEOTWAWKI?

É claro que o DockerHub nunca executaria docker build com a sinalização --privileged solicitada.
Sem pensar muito, há pelo menos duas maneiras óbvias de implementá-lo:

• sinalizador só funciona se você também lançar docker -d com algum novo sinalizador, como: --i-want-a-broken-security-model
• Crie um sinalizador de tempo de compilação que habilite o caminho do código.

No geral, a proporção de razões de ranger de dentes para razões baseadas na engenharia contra implementação parece muito alta aqui.

@tamsky E então temos uma situação em que as compilações funcionam em um lugar, mas não em outro.
Estou explicando por que as coisas são como são, não discutindo um caso ou outro.

Mas também ... a maioria das coisas não precisa de nenhum tipo de acesso privilegiado, e aquelas que precisam de acesso privilegiado geralmente não _realmente_ precisam dele para que a instalação funcione. Se a instalação de algo está falhando por causa disso, esse instalador está quebrado, como é o caso do citado problema do tomcat.
Habilitar esse recurso encorajaria as pessoas a executar no modo privilegiado em vez de realmente resolver o problema real em questão.

@ cpuguy83

E então temos uma situação em que as construções funcionam em um lugar, mas não em outro.

Por favor, imagine por um momento que fomos magicamente transportados para um mundo onde a _política_ é diferente, e algumas construções funcionam em um lugar, mas não em outro ...

Por que este é um bom acordo?
Exatamente quem se importa?

A Docker Inc considerou que seu mantra / requisito de menor denominador comum de "todas as compilações devem funcionar em qualquer lugar" pode, na verdade, estar ignorando uma necessidade real do cliente?

A política atual está externalizando o custo de engenharia para que os clientes "consigam X para construir no docker":

Em vez de fornecer esse recurso no docker, você está forçando todos os projetos de terceiros no mundo que não "precisam de nenhum tipo de acesso privilegiado" (mas realmente precisam), a serem primeiro atualizados ou corrigidos para lidar com o caso de compilação do docker.

Eventualmente, se o Docker for executado em várias plataformas, 'docker build' NÃO funcionará da mesma forma em todos os sistemas. Ou seja, a construção de um contêiner Windows, contêiner Solaris ou mesmo contêiner ARM Linux não será igual ao que é no Linux x86-64. O contexto de segurança para eles também será diferente, conforme apropriado para suas plataformas.

Ou seja,

As compilações não estão funcionando em todos os lugares porque, por exemplo, perfis de armadura de aplicativo carregados.
Além disso, como você faria o caso com containers docker pré-armazenados em cache embutidos em uma imagem?

Em 18. 11. 2014, às 2:53, tamsky [email protected] escreveu:

@ cpuguy83

E então temos uma situação em que as construções funcionam em um lugar, mas não em outro.

Por favor, imagine por um momento que fomos magicamente transportados para um mundo onde a política é diferente, e algumas construções funcionam em um lugar, mas não em outro ...

Por que este é um bom acordo?
Exatamente quem se importa?

A Docker Inc considerou que seu mantra / requisito de menor denominador comum de "todas as compilações devem funcionar em qualquer lugar" pode, na verdade, estar ignorando uma necessidade real do cliente?

A política atual está externalizando o custo de engenharia para que os clientes "consigam X para construir no docker":

Em vez de fornecer esse recurso no docker, você está forçando todos os projetos de terceiros no mundo que não "precisam de nenhum tipo de acesso privilegiado" (mas realmente precisam), a serem primeiro atualizados ou corrigidos para lidar com o caso de compilação do docker.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Não é o "instalador" que está "quebrado" nesta situação, é o Tomcat 7. Estou usando a pilha Tomcat do Bitnami, que integra o Tomcat com Apache e MySQL. Docker está sentado no final de uma cadeia de suprimentos de serviços de origem, configuração, integração, teste e empacotamento. Exigir que eu "conserte" o Tomcat me impede de tirar vantagem dessa cadeia de suprimentos. É muito mais fácil construir a imagem que desejo manualmente (iniciar um contêiner com "--privileged", executar o instalador, fazer um instantâneo do contêiner, etc.) do que "consertar" o Tomcat.

+1
Não posso transferir minhas funções de chef para docker porque todas envolvem o uso de ufw para abrir portas.
adicionar --privileged para construir consertaria isso.

+1. Não posso ter debootstrap como uma etapa em meus Dockerfiles.

+1. Não posso ter debootstrap como uma etapa em meus Dockerfiles.

Parecia natural construir meu chroot por meio de um Dockerfile / build, mas encontrei os mesmos problemas que @fbrusch mencionou.

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

falha com:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

Que tal, em vez de RUNP , ter um sinalizador de construção --insecure .
Para todos os comandos RUN, o contêiner subsequente seria executado com --add-cap=all . Em vez de privilegiado, visto que privilegiado faz algumas outras coisas também ...
Mas realmente isso pode mudar para implementar as configurações privileged , se necessário em algum ponto, sem ter que modificar o sinalizador.

@ cpuguy83
Não me importo de ter que usar um sinalizador passado para o docker build que permite que os comandos RUN tenham privilégios ou habilite os comandos RUNP. Há valor em ser capaz de olhar para um Dockerfile e dizer pelos comandos ou algo dentro dele, que exigiria acesso privilegiado, e em tempo de execução, em vez de ir para a etapa 10 e cometer um erro, teria um atalho no início que o Dockerfile contém comandos que requerem privilégios.

O caso de uso que me trouxe a este encadeamento são montagens de ligação, que desejo fazer intracontainer. No momento, você só pode fazer isso se executar o contêiner no modo privilegiado. Ele força você a encadear comandos no início ou ter um script de inicialização que é executado para completar a configuração do sistema antes do processo que você deseja executar.

Seria bom poder apenas ter no Dockerfile:

RUN mount --bind /dir1 /dir2

Descreverei meu caso de uso com mais detalhes, portanto, esta não é apenas uma solicitação ampla de dar-me comandos privilegiados. Meu caso específico é querer vincular a montagem de um diretório na área de aplicativo a um volume de dados que foi anexado.

por exemplo

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

Isso poderia ser resolvido fazendo também a montagem do volume diretamente na área do aplicativo, mas estou procurando uma maneira de tê-los fornecidos em um local comum e permitir que o contêiner do aplicativo execute seu mapeamento específico. Isso também poderia ser resolvido com links simbólicos, mas alguns aplicativos não funcionam bem com links simbólicos como sua pasta de destino / dados. E se o aplicativo suportar a configuração do local do diretório de dados, isso também pode ser feito para apontar para a área de montagem do volume. No meu caso de uso, o aplicativo não suporta a configuração da localização do diretório de dados, e a realidade é que sempre haverá aplicativos que você terá que realizar alguma montagem de ligação ou link simbólico para separar adequadamente seus dados e espaço de aplicativo.

Essa capacidade de fazer isso A -> B -> C permite manter os contêineres de dados genéricos e fornece flexibilidade nas diferentes combinações que você pode conseguir com --volumes-from com contêineres de aplicativos e dados.

Você também pode conseguir isso tendo uma cadeia de contêineres com --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

O que pode ser a resposta certa, mas você poderia eliminar a necessidade de criar outro contêiner para os dados do aplicativo se o contêiner do aplicativo pudesse executar uma montagem de ligação.

Posso conseguir isso hoje executando o contêiner no modo privilegiado e, em seguida, executar o bind de montagem, mas como você verá abaixo, não há uma maneira de fazer com que esse bind de montagem persista e deve ser reiniciado toda vez que você iniciar o contêiner . Symlinks são persistentes em commits.

A resposta para meu caso de uso específico pode ser usar a abordagem de 3 contêineres de cadeia ou script de inicialização, mas seria bom ter a capacidade de vincular montagens intracontêiner (ou outros comandos privilegiados) do Dockerfile. Provavelmente, há outros casos de uso para montagens de ligação que podem ser descritos, os quais não envolvem nenhum mapeamento de host para contêiner que não pode ser resolvido com o encadeamento de contêineres de dados.

Não tenho certeza se isso está relacionado ou mais a um problema específico de montagem de ligação, mas ter os resultados dos comandos privilegiados persistindo quando você faz um commit do docker permitiria que você separasse a construção da imagem do docker e a execução da imagem do docker. Você pode controlar a área onde executa a construção docker e os usuários finais obtêm apenas o contêiner confirmado, que pode ser executado no modo sem privilégios. Esta não é a causa atualmente quando você executa uma montagem de ligação e confirmação. Isso pode estar mais relacionado a como /proc/mounts funciona.

Aqui está um exemplo simples

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Crie um exemplo de montagem de ligação, também crie um exemplo de link simbólico

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

O arquivo de exibição é visto em todos os 3 diretórios

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

Mostrar /proc/mounts atualizado

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

Saia do contêiner que o interrompe e comece novamente

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts está faltando a montagem de ligação

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Symlink sobreviveu, mas não ligou a montagem

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

Montagem de ligação de reinicialização

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

Em vez de sair do contêiner, desanexar com ctrl+p ctrl+q e então comprometer o contêiner

Confirme o contêiner como uma nova imagem, inicie um novo contêiner a partir da imagem no modo não privado

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

Verifique o /proc/mounts
a montagem de ligação está faltando, não tenho certeza do que acionou as montagens extras / proc / [sys, sysrq-trigger, irq, bus, kcore]

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

Symlink sobreviveu

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

Atualmente, estou tentando executar imagens docker na minha etapa de compilação, usando dind . Portanto, atualmente, não há como usar imagens docker de execução em sua compilação?

Pessoal, se você deseja isso, tente '/ usr / bin / unshare -f -m -u -i -n -p -U -r - / caminho / para / binário'. Isso criará um contêiner dentro de sua construção com um namespace de usuário. Você pode ajustar as opções para cancelar o compartilhamento conforme necessário. Na verdade, eu uso isso para executar '/ sbin / capsh', para definir granularmente os recursos para meus processos.

Não posso dizer que isso resolverá todos os casos de usuário para compilações privilegiadas, mas deve ajudar alguns de vocês.

Concordo que isso deve se tornar parte do próprio Docker, e a integração de namespaces de usuário parece estar em andamento.

@saulshanabrook você não pode executar imagens docker em uma construção, não exatamente. Espero que um dia em breve isso seja possível. Eu fiz algumas investigações sobre isso e descobri que você pode fazer um 'docker pull' de dentro de uma compilação, desde que use o armazenamento VFS. Convenientemente, 'docker save' também funciona.

Não é uma solução real para quem deseja executar imagens docker, mas observarei que 'unshare' e 'capsh' funcionam, então é possível fazer um runtime semelhante a um contêiner em contêineres sem privilégios (como durante uma compilação ) Indiscutivelmente, é possível evitar a 'execução do docker' e fazer essa etapa manualmente e recomprimir as imagens de volta ao docker. Tenho a maior parte disso funcionando hoje, mesmo que não tenha tudo embrulhado em um laço. Eventualmente, é claro, essa funcionalidade precisa ir para o próprio Docker.

+1 para docker pull via RUNP

A incapacidade de executar docker build privilegiado promove a construção manualmente com um shell e docker commit, o que torna os Dockerfiles inúteis. Não acho que adicionar um sinalizador privilegiado ao docker build traçaria uma linha entre os builds e os builds privilegiados; essa linha já foi desenhada quando o sinalizador foi adicionado para rodar e precisa ser suportado.

+1 Isso torna o contêiner docker reproduzível a qualquer momento (basta carregar o dockerfile sozinho)

1 tendo que separar completamente minhas funções de linha de base do ansible apenas para contornar coisas como esta. Eu realmente esperava que a adoção do docker me permitisse usar muito do meu código ansible existente, mas não apenas já criei funções personalizadas para o tamanho, mas agora estou tendo que contornar problemas como este.

@lsjommer que tipo de coisas você tem que resolver? --privileged é uma maneira completamente insegura de rodar um container e dá ao usuário no container acesso root completo ao host.

Não estou dizendo que não vamos implementar isso, mas vamos cair na real sobre o que estamos falando.

Além disso, isso seria relativamente fácil de implementar se alguém quiser ir em frente ...

@ cpuguy83 Esta é a nossa função de linha de base "bare metal" padrão que estou tentando adotar em contêineres docker para ter todas as libs instaladas e trata de memória compartilhada, mas talvez eu nem precise me preocupar com isso na construção do contêiner e só precisa executá-lo no host do contêiner?
http://pastebin.com/P3QQxjNQ

Admito que não entendo totalmente como o Docker lida com o compartilhamento de recursos.

@ljsommer Portanto, definir shm é completamente diferente e não persistiria entre os comandos RUN (ou quando você realmente docker run ) de qualquer maneira.

@ cpuguy83 Sim, acho que isso foi principalmente minha culpa no que diz respeito a atingir o que pensei ser um problema que posso simplesmente mudar para a linha de base para o próprio host do contêiner.
Obrigado por dedicar seu tempo para responder e desculpas por não me educar adequadamente antes de reclamar.
;)

Alguma ideia sobre RUNP / -privileged durante o processo de compilação?
Seria ótimo para configurar tabelas de ip para limitar o acesso do docker a endereços de ip especificados

Também quero RUNP e / ou "docker build --privileged".

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

Este Dockerfile não funciona devido ao seguinte erro, mas funciona com "docker run --privileged" ...

getsockopt failed strangely: Operation not permitted

@malcm , @ sakurai-youhei: mesmo se você tivesse algo como RUNP , não funcionaria neste cenário, porque as regras de iptables não são persistentes no sistema de arquivos.

Deixe-me explicar: quando você faz RUN x , o Docker executa x e tira um instantâneo do sistema de arquivos. Coisas fora do sistema de arquivos (processos em execução, tabelas de roteamento, regras de iptables, configurações de sysctl ...) não são armazenadas nas imagens do Docker.

Se você quiser regras de iptables personalizadas, um método é:

• inicie seu contêiner, por exemplo, com --name myapp
• inicie outro contêiner, com privilégios, de uma só vez, para configurar a regra iptables, por exemplo, docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

Isso faz sentido?

@jpetazzo : Obrigado por sua resposta. No meu caso, coloquei o segundo comando para fazer a regra iptables persistir como dados no sistema de arquivos conforme abaixo. Isso deve permitir que eu carregue a regra iptables após iniciar o contêiner com a opção --privileged.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

Sem RUNP nem "build --privileged", sou forçado a escrever como:

ADD iptables.rules /etc/

Sim, isso pode ser suficiente, no entanto, preciso adicionar iptables.rules ao lado do Dockerfile em meu repo.

É por isso que eu quero (ou gostaria de ter suavemente) RUNP. :)

@jpetazzo @strib
Além de problemas de iptables, montagens e outras operações privilegiadas, acho que há um cenário de construção que devemos abordar.

Enviamos aparelhos para implantação em VMs e instalação bare-metal. No entanto, para teste, usamos ambientes de contêiner. Por sua vez, dentro desses aparelhos operamos contêineres. Portanto, os contêineres de teste devem ser baseados em docker-in-docker. Agora imagine que temos uma imagem de serviço que precisa ser pré-carregada na imagem de teste (para que as imagens de serviço não sejam baixadas do registro em tempo de teste). No momento, não podemos fazer isso, pois não podemos executar o contêiner d-in-d no modo privilegiado durante a compilação do Dockerfile que usa d-in-d como base: o daemon do docker não inicia, "docker pull "ou" docker load "não funcionam.

Tive um problema em que, ao executar em um host RHEL7, su falharia se o usuário atual fosse root. Estranhamente, se o usuário atual fosse outra pessoa, su funcionou bem. Independentemente disso, a solução alternativa era passar ao comando de execução o sinalizador --add-cap=SYS_RESOURCE ; devido a esse problema, no entanto, não foi possível fazer isso durante a etapa de compilação.

+1 Scripting em torno de Dockerfiles com docker run e docker commit é ridículo. Inclua esta funcionalidade.

1 na necessidade deste recurso. Acho que um "nível de segurança" global pode ser configurado em um arquivo de configuração que limita os recursos que podem ser fornecidos a um contêiner. Deve haver um padrão seguro (como hoje) e um administrador de sistema pode alterá-lo para permitir que os contêineres sejam executados com mais privilégios. Os dockerfiles com essa instrução RUNP podem falhar ao serem executados com uma mensagem como "este Dockerfile requer os seguintes recursos .... para construir" em um sistema que tem tais limites globais.

Acho que isso permite um equilíbrio entre segurança e usabilidade.

Também temos esse problema ao tentar construir uma imagem com um banco de dados proprietário da evli, que permanecerá sem nome, dentro dele.
O banco de dados deseja alocar grandes quantidades de memória, o que não é permitido pelo docker.

Nossa solução alternativa atual é uma construção de 2 fases com uma etapa run --privileged e uma etapa de confirmação separada.

Talvez pudéssemos configurar o docker para permitir a alocação de memória de outra forma. É um pouco difícil descobrir o que o banco de dados realmente quer fazer porque é proprietário.

+1
para este recurso.
para histórico e exemplo de caso de uso, veja este dupe
https://github.com/docker/docker/issues/12138#issuecomment -90536998
obrigado @ cpuguy83 por apontar o idiota

Eu também tenho esse problema, tentar conectar-se a um compartilhamento cifs durante a compilação do docker não é permitido, a menos que o sinalizador privilegiado seja fornecido, alguma maneira de contornar isso?

Agora há uma solicitação pull que implementa isso; você pode verificar o progresso lá; https://github.com/docker/docker/issues/12261

Se algo requer o modo privilegiado, é possível que esteja modificando o host de alguma forma, o que significa que a imagem pode não ser portável, pois essas modificações precisam ser executadas em outros hosts que tentam consumir a imagem.

Assim que o # 13171 for mesclado, acho que devemos fechar isso, pois tornará a rolagem do seu próprio construtor trivial e, como tal, permitindo --privileged.
Não acho que o docker build embutido deva permitir isso.

Portanto, @ cpuguy83 , se bem entendi, a maneira de dar suporte a esse problema seria reimplementar totalmente docker build mas com um parâmetro extra?

Acho que devo dizer que, uma vez que o outro patch seja implementado, eu precisaria criar minha própria versão de docker build (talvez docker pbuild ?) Para preencher a funcionalidade adicional.

Existe algum progresso nesta questão? Eu verifiquei os PRs mencionados acima e todos eles falharam.
É possível tornar uma opção BUILD --privileged/--granted mais granular e tornar os acessos concedidos a um grupo específico de recursos de host limitados apenas ao criador / proprietário da imagem?

+1 para qualquer solução que me permita fazer RUN docker pull em um Dockerfile.

Caso de uso: preciso de um monte de ferramentas para conversão de imagens e construção de documentação, no entanto, todas essas ferramentas não podem ser instaladas em uma única imagem por causa de bibliotecas conflitantes. É por isso que separo algumas dessas ferramentas em uma imagem separada e gostaria de distribuir todas as ferramentas em uma única imagem, ou seja, imagem em uma imagem. É por isso que quero fazer RUN docker pull no meu Dockerfile.

@ cpuguy83 , não parece que o problema foi resolvido para a satisfação de ninguém. Eu absolutamente, 100%, preciso ser capaz de fazer algo tão chato quanto escrever para /proc/sys/kernel/core_pattern durante uma compilação.

No mundo atual, posso fazer essa operação privilegiada por meio de uma solução alternativa run e simplesmente enviar essa imagem para o hub de qualquer maneira. Além disso, nenhum Dockerfile que _tunca_ produzi é estritamente reproduzível, porque eles extraem de repositórios públicos aleatórios que mudam constantemente. Eu não tinha ideia disso

1. O consumo público de minhas imagens era uma prioridade.
2. Eles tinham qualquer necessidade, sempre, de serem reproduzíveis.

As pessoas _vai_ fazer soluções de merda para obter privileged na construção. Eu acho que você definitivamente deveria ir onde seus usuários estão e permitir isso na ferramenta de construção principal. Adicione uma mensagem aterrorizante, se necessário.

cc @thaJeztah , que parece simpático a esta posição

Olha, criei um PR para habilitar isso e foi rejeitado.
Não vejo isso acontecendo com o construtor de nenhuma forma.

Parecia que você fez a chamada final. Vou agitar no próprio tópico de relações públicas, então.

Isso é necessário para instalar os pacotes JDK 1.6 mais antigos no CentOS, já que a tentativa de registro dos RPMs é binmft_misc, que falha sem rodar com --privilegiado.

Dockerbuild é um não-stater para a construção de contêineres com ele.

Replicar

DE Centos5.11
RUN yum intall -y jre-1.6.0_29-fcs

Precisamos ter parte do comando privilegiado do build como um sinalizador opcional. Estou tentando portar um de nossos aplicativos para docker como um POC e ele falha para um de nossos componentes, pois tem configurações de IPtables que não estão sendo aplicadas e a compilação falha. Posso fazer as alterações necessárias manualmente e confirmá-las, mas então qual é a graça do docker build. É apenas uma parte da construção e deve ser fácil de portar, pois já faz parte da versão principal.

O Docker deve ser capaz de executar facilmente contêineres intermediários com um conjunto de opções privilegiado.

@shubhamrajvanshi , estamos no processo de mover o "construtor" do daemon (e para o cliente), isso deve abrir a porta para mais personalizações no processo de construção (incluindo a capacidade de implementar construtores customizados). Possivelmente, permitir builds "privilegiados" pode ser considerado, mas essa é uma decisão que pode ser tomada após a refatoração. (Consulte https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi você não pode fazer alterações no iptables no build por um bom motivo, as configurações nunca iriam travar.

Existem muito poucas coisas que se podem fazer com --privileged que ainda fazem sentido na construção.

@thaJeztah Obrigado, seria útil.
@ cpuguy83 Seria esse o caso mesmo se eu estivesse usando o pacote iptables-persistent na imagem.

Isso salvaria as regras no disco e, infelizmente, ainda teriam que ser recarregadas.

_USER POLL_

_A melhor maneira de ser notificado quando há mudanças nesta discussão é clicando no botão Inscrever-se no canto superior direito._

As pessoas listadas abaixo apreciaram sua discussão significativa com um +1 aleatório:

@karelstriegel

Eu também gostaria muito disso, para permitir o uso de drivers CUDA da nVidia com Docker no CoreOS. O instalador que eles fornecem constrói um módulo do kernel contra a fonte do kernel e então o instala usando modprobe. Eu não consigo ver como fazer isso funcionar sem algum tipo de opção --privileged para construir.

Por que nem sempre oferece suporte, por padrão, ao modo privilegiado na construção?

+1
Eu quero usar o comando mysql no Dockerfile para centos7.
Claro que podemos usar o entrypoint.sh, mas é mais útil se pudermos usar -privileged para construir e executar.

Não há necessidade de --privileged para executar o comando MySQL.

Este problema deve ser encerrado, pois não parece que isso vai acontecer (ou mesmo que deveria acontecer).
Permitir privilégios na construção significa permitir que o construtor altere coisas no host, o que, por sua vez, faz com que a imagem funcione apenas naquele host (ou hosts que tiveram modificações semelhantes).

Permitir privilégios na construção significa permitir que o construtor altere coisas no host, o que, por sua vez, faz com que a imagem funcione apenas naquele host (ou hosts que tiveram modificações semelhantes).

Isso se aplica ao caso do usuário chroot?

Estou tentando descobrir como fazer dpkg-depcheck -d ./configure sem algo assim.

Durante a compilação (ou execução sem --priviledged), recebo o erro abaixo - não tenho ideia de como descobrir qual permissão é necessária ou como habilitá-la.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

Depois de cerca de 3 anos e 162 comentários, acho que tem muito interesse em fazer. Os comentários sobre um modo privilegiado não ser necessário para a maioria dos casos citados são verdadeiros, até mesmo o meu; mas não deve ser usado para proibir o que pode ser útil para compilações locais, temporárias, exploratórias e / ou convenientes. Publique avisos até que as vacas soltem uma harmonia, imprima avisos de linha de comando, insulte e denuncie seu uso, mas dê flexibilidade às pessoas. A portabilidade nem sempre é o principal interesse de todos.

_USER POLL_

_A melhor maneira de ser notificado sobre atualizações é usar o botão _Subscribe_ nesta página._

Não use comentários "+1" ou "Eu também tenho" nas questões. Nós automaticamente
colete esses comentários para manter o tópico curto.

As pessoas listadas abaixo votaram a favor desse problema, deixando um comentário de +1:

@robeferre

+1

Eu realmente preciso montar um volume NFS dentro de um contêiner do docker, até agora não poderia criar o compartilhamento NFS sem o sinalizador "--privileged = true". O melhor caso, na minha opinião, é construir a imagem usando um comando privilegiado. Como isso é possível?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

Estou tentando instalar gobject-introspection no sistema gentoo no docker durante a compilação, mas falha com este erro:

• ISE: _do_ptrace: ptrace (PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operação não permitida

O mesmo resultado quando tento instalá-lo manualmente no contêiner, mas quando tento a partir do contêiner iniciado no modo privilegiado (docker run --privileged), ele funciona bem.

O mesmo problema quando tento instalar o glibc.

Portanto, também preciso de uma maneira de executar o comando privilegiado durante a compilação.

Estou usando o docker versão 1.10.1 e o problema com glibc não aparece no 1.9

Na versão 1.10 algo estava quebrado e não podemos construir contêineres de 32 bits, porque a rede não está disponível
--privileged ou --security-opt seccomp: não confinado para BUILD - é realmente necessário.
Ou diretivas correspondentes no Dockerfile

grande +1 de mim

É um problema real para mim não poder usar o comando 'montar' durante a construção.
Eu estava tentando superar a limitação de um diretório de host não pode ser montado em um contêiner durante a construção, então configurei um servidor NFS no host e tentei montar um compartilhamento NFS, apenas para descobrir que não é possível devido ao modo sem privilégios.

No meu caso de uso, preciso instalar algumas coisas na imagem sem copiá-las para o contexto de construção e ADICIONAR antes de instalá-las.

Parece que fiquei sem opções.

thaJeztah referiu-se a este problema em 10 de março
Regressão no comportamento do LTTng após a atualização para 1.10.2 # 20818 Fechado

Não, não está fechado, estamos usando 1.11.0-0 ~ wily e em contêineres de 32 bits o neworking não está funcionando desde 1.10.0, mas 1.9.x funcionou bem.
Apenas -privileged pode nos ajudar a iniciar contêineres. Mas não podemos construir novos

Estou surpreso de que algo tão obviamente necessário para tantas pessoas não tenha sido implementado, embora as pessoas tenham implorado por isso por 2,5 anos somente neste tópico e visto que as pessoas enviaram PRs para implementar essa funcionalidade.

Concordo, @ctindel , esse problema é um dos motivos pelos quais estou migrando do docker para o rkt .

@ctindel É algo que não estamos prontos para implementar ou apoiar. A implementação em si é bastante simples (eu mesmo implementei para que pudéssemos discutir), esse não é o problema.

--privileged é um tanque, e permiti-lo na construção é perigoso e afeta muito a portabilidade da imagem.

Brian,

Se você tiver uma solução alternativa, compartilhe-a comigo também. eu poderia
aprecio isso.

Obrigado
Shubham Rajvanshi
669-300-8346

Na segunda-feira, 2 de maio de 2016 às 14h30, Brian Goff [email protected] escreveu:

@ctindel https://github.com/ctindel É algo para o qual não estamos prontos
implementar ou apoiar. A implementação em si é bastante simples (eu até
implementei para que pudéssemos discutir), esse não é o problema.

--privilegiado é um tanque, e permitir sua construção é perigoso, e
afeta muito a portabilidade da imagem.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

Não entendo o efeito na portabilidade. Como as operações privilegiadas em tempo de construção afetam a portabilidade? Quer dizer, não é difícil criar imagens não portáteis de várias maneiras com ou sem privilégio, mas há alguma maneira de as imagens construídas com operações privilegiadas serem necessariamente não portáteis?

Não acredito que todo contêiner deva ser portátil. Alguns contêineres são criados para compartilhar com a comunidade e alguns podem ser criados para implementar aplicativos internos.

O problema de portabilidade com um aplicativo que requer execução no modo privilegiado está no próprio aplicativo.

O modo privilegiado é o último recurso para fazer com que o aplicativo funcione sem alterações de código.

Acredito que um criador de imagens que requer a construção em modo privilegiado entende que tal contêiner também pode exigir a execução em modo privilegiado.

Deve ser claramente documentado que a construção no modo privilegiado é desencorajada, pois pode criar problemas de portabilidade.

Enviado do Outlook Mo bilehttps: //aka.ms/blhgte

Na segunda-feira, 2 de maio de 2016 às 14h53 -0700, "Trevor Blackwell" < [email protected] [email protected] > escreveu:

Não entendo o efeito na portabilidade. Como as operações privilegiadas em tempo de construção afetam a portabilidade? Quer dizer, não é difícil criar imagens não portáteis de várias maneiras com ou sem privilégio, mas há alguma maneira de as imagens construídas com operações privilegiadas serem necessariamente não portáteis?

Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/docker/docker/issues/1916#issuecomment -216375159

@tlbtlbtlb Porque o modo privilegiado fornece acesso total ao host. Talvez eu defina algo simples como shmmax ou algo muito pior.
Eu garanto que essas coisas acontecerão no dia 1 em que isso estiver disponível.

@davidl-zend "portátil" não significa compartilhar com a comunidade. Significa passar de uma máquina para outra.

@ cpuguy83 Como outros apontaram, existem muitas outras maneiras de quebrar a portabilidade da imagem também. Tudo o que você está fazendo por não ter um processo de construção privilegiada é forçar as pessoas a terem um processo de duas etapas, seja construindo parcialmente a partir de um Dockerfile e, em seguida, alterando manualmente o contêiner e fazendo um commit, ou construindo parcialmente a partir de um Dockerfile e finalizando a instalação privilegiada na primeira vez que o contêiner é iniciado, o que é uma droga, porque isso significa que, se você está fazendo algo que consome muito tempo, pode levar alguns minutos para a primeira inicialização funcionar.

Dados os comentários que vi em vários fóruns, estou disposto a apostar que MUITAS pessoas já estão fazendo exatamente isso para contornar a limitação do docker que existe hoje.

Depois de ter uma arquitetura em que a portabilidade da imagem é quebrada em dezenas de outras maneiras, que sentido há em se inclinar contra esse moinho de vento específico?

Obviamente, você não seria mais capaz de fazer com que o docker hub ou travis-ci criasse sua imagem, mas as pessoas que precisassem construí-lo com o modo de privilégio entenderiam isso de qualquer maneira.

@ctindel Eu adoraria ver alguns exemplos de portabilidade de imagem quebrada

Fazer esse tipo de coisa na primeira inicialização do contêiner é _exatamente_ o caminho certo a seguir.
É uma configuração de tempo de execução que não deveria estar na imagem.

@ cpuguy83 Você está debatendo o fato de que alguém poderia fazer uma compilação parcial de um Dockerfile, ativar um contêiner no modo privilegiado, fazer mais alterações e, em seguida, fazer um commit do docker? Como isso é diferente de fazer uma compilação no modo privilegiado? Porque é isso que outras pessoas estão fazendo hoje.

Não estou tentando ser irritadiço, só estou dizendo que essa é uma limitação severa na plataforma em que as pessoas estão trabalhando de maneira estranha.

Por exemplo, existem pacotes debian de terceiros (e provavelmente RPMs) que não podem ser instalados corretamente a menos que você tenha certos recursos no sistema. Instalar um pacote debian não é uma "configuração de tempo de execução", é uma parte do processo de instalação.

@ctindel Não estou debatendo nada sobre isso. A diferença é apoiar o comportamento. Se não houvesse diferença, não estaríamos tendo essa discussão.

Para mim, sou um adulto consentido e quero ser capaz de rolar uma imagem de packstack em um monte de nós. Construir com bombas Dockerfile atualmente, então tenho que trapacear para contornar as restrições do docker.

@ cpuguy83 Ainda não está claro para mim (e acho que para outros neste tópico) o que exatamente é ganho por não fornecer essa opção que as pessoas estão trabalhando de outras maneiras. O tipo de pureza arquitetônica (não tenho uma palavra melhor para isso) que você parece estar defendendo se foi no minuto em que a opção de confirmação foi adicionada, então eu realmente não entendo que diferença existe se isso é feito por meio de um Dockerfile com construção privilegiada ou via docker commit em um contêiner privilegiado.

Exceto que uma forma é um PITA assustador para as pessoas e uma forma de encaixe no mecanismo atual de construção com Dockerfile muito bem.

Além disso, você não respondeu à minha pergunta. Por que você considera a simples instalação de um pacote debian de terceiros (ou packstack) como uma "configuração de tempo de execução"?

@ctindel Portabilidade. Só porque algo pode ser feito não significa que seja compatível, e incluí-lo em build , tornando-o conveniente para todos, significa que é compatível.
Nós _seremos_ inundados com problemas de imagens que não funcionam entre os hosts ... o que anula basicamente todo o motivo do Docker.

Se um pacote requer --privileged para ser instalado, então ele deve ser endereçado com o pacote. A instalação não deve exigir --privileged ... e se realmente exigir, então este é um sinal de que a instalação em si não é portátil (requer mudanças no host) ... Eu gostaria de até veja o docker ser executado em um contêiner sem --privileged (note que é executável, você pode instalar tudo o que quiser sem problemas sem --privileged).

Mas permitir que seja feito via docker commit significa que também é suportado!

Não entendo, você está fazendo várias pessoas contornar as limitações deste produto porque está preocupado que alguém reclamará pessoalmente com vocês sobre algum tipo de imagem incompatível?

Você ainda não respondeu minha pergunta sobre por que o ato de instalar um pacote (nem estou falando em configurá-lo aqui) é um ato de "configuração em tempo de execução". Apenas dizer "portabilidade" não significa nada.

Existe algo específico do x86_64 sobre o docker? Eventualmente, não haverá imagens do docker criadas para uma arquitetura de CPU específica? Isso também não os torna não portáteis? Quero dizer, toda essa ideia de que de alguma forma você sempre será capaz de pegar qualquer imagem docker e executá-la em qualquer docker host no mundo, independentemente de toneladas de outras variáveis, parece impossível de qualquer maneira, então eu não entendo a necessidade super forte de empurrar de volta a esse recurso específico que as pessoas estão pedindo.

BTW, deixe-me agradecer por suas respostas e envolvimento contínuo. Muitos outros projetos github onde tópicos de problemas são ignorados!

Concordo com o ponto sobre as pessoas trabalhando em torno disso usando docker run --privileged com docker commit . Eu fiz uma solução como essa para duas empresas até agora. As pessoas FARÃO imagens como essa e não adianta agir como se isso fosse algo horrível, horrível.

Inferno, se você tem tanto medo de suportar contêineres que foram construídos com --privileged então apenas indique isso claramente na documentação para que as pessoas fiquem perfeitamente cientes de que estão fazendo isso por sua própria conta e risco. Embora eu não tenha visto nenhum efeito negativo até agora. Mas, novamente, não temos tentado executar contêineres em distribuições diferentes.

@PerilousApricot o que está realmente causando o problema com packstack? Ficamos felizes em consertar problemas específicos ou ajudar o upstream a corrigi-los, mas não pense que apenas adicionar --privileged que fornece acesso root irrestrito e completo ao seu servidor host, é a maneira correta de fazer isso. Todos os casos que eu estou ciente em que as pessoas levantaram problemas específicos de compilação geralmente podem ser corrigidos, já que a maioria das coisas não precisa de acesso root na máquina host para fazer uma compilação.

@justincormack Qual é a solução para um pacote de terceiros (ou seja, não pode ser alterado) que inicia seu próprio serviço onde o script init precisa montar um sistema de arquivos tmpfs? Quero dizer, mesmo ignorando --privileged por enquanto, também não há como fazer um aparelho --cap-add ou --security-opt : não confinado durante uma compilação (eu não acho?)

@ctindel Não deveria estar tentando montar um tmpfs na instalação. Se precisar de tmpfs em tempo de execução, ótimo, mas certamente não está correto no momento da instalação.

@ cpuguy83 Você está impondo filosofia de arquitetura e implementação a algo que é imutável porque vem de um terceiro comercial. Nem tudo será consertado "upstream", mesmo se eles consertarem a versão mais recente do .deb ou .rpm, isso não significa que eles voltarão e repostarão a versão anterior, que é o que você pode precisar na imagem do docker.

Esse é o ponto de toda essa discussão, você está impondo restrições arbitrárias que tornam muito mais difícil o uso do docker por causa de alguma preocupação filosófica sobre pedidos de apoio de pessoas que "fazem tudo errado".

É como dizer que os sistemas operacionais não devem permitir que as pessoas alterem as classes de agendamento de processos porque, se você fizer isso da maneira errada, isso pode levar a uma inversão de prioridade. Ou que ninguém deveria fazer um martelo porque é possível acertar o polegar se você usar errado.

Como já foi dito muitas vezes, o docker JÁ SUPORTA ISTO através do comando commit, é apenas mais doloroso para os seus usuários. As pessoas que não querem esse recurso não vão usá-lo, e os adultos que consentirem e quiserem usá-lo por meio da compreensão das limitações podem fazê-lo com os olhos bem abertos.

@ctindel Mais como não, você não pode lidar com essa bomba nuclear porque você poderia matar qualquer pessoa em um raio de 50 km.

O que há sobre este pacote que ele precisa para carregar um tmpfs durante a instalação? A instalação é literalmente extrair arquivos de algum formato de arquivo para o rootfs.

Tudo pode ser alterado.
É uma mudança muito mais simples e segura a ser feita no upstream para não montar um tmpfs na instalação do que habilitar com privilégios na compilação.

O Docker trata da portabilidade da carga de trabalho. Habilitar privilégios na construção (ou privilégios extras, ou ajustes de perfis de segurança, etc) fundamentalmente quebra isso e não é algo que podemos aceitar hoje.

commit e build são duas coisas muito diferentes, e só porque é possível fazer algo de uma maneira não significa que devemos permitir fazê-lo de todas as outras também.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

Sem privilégios necessários.

A igreja da protabilidade.
Um dia a portabilidade "forçada" matará este projeto - ele já está fazendo isso.
Muitos recursos estão sendo negados por causa da portabilidade elusiva, muito progresso não está sendo feito por causa disso ...
Um dia alguém vai fazer um fork de um projeto e tornar a portabilidade opcional. Sonhos ... sonhos .... Amém.

Se dividirmos em dois casos:

1. Instaladores que usam operações privilegiadas levianamente, como montar tmpfs para desempenho. Esses instaladores podem ser facilmente corrigidos (mas talvez não o sejam em um futuro próximo).

Nesse caso, é uma filosofia válida para o Docker recuar em instaladores que se comportam mal. A maioria dos instaladores tem algum tipo de solução alternativa que apenas torna o Dockerfile um pouco mais longo.

1. Instaladores que dependem fundamentalmente de operações privilegiadas, como a instalação de módulos de kernel para drivers de GPU. Eles também são fundamentalmente não portáteis. Eles não funcionam em docker-machine para Mac, por exemplo.

Nesse caso, a experiência do Docker é interrompida de qualquer maneira. Não posso usar docker-machine no Mac, por exemplo, só posso construir a imagem em uma máquina host de destino compatível. Meu caso de uso foi instalar os drivers da GPU da nVidia em um sistema operacional host (CoreOS), o que desencorajou a instalação direta no sistema operacional host.

Então, acho que entendi a virtude de não apoiar --privilegiado em ambos os casos. Acho que o que me fez mudar de ideia foi a conveniência de criar imagens no meu laptop usando docker-machine, em vez de primeiro enviar meu código para uma caixa do Ubuntu e construir lá.

@tlbtlbtlb Não entendo a que "virtude" você está se referindo. Considere algo que não seja frívolo, mas há toneladas de imagens do docker que serão executadas em um ambiente, mas não em outro. Por exemplo, você pode montar um volume de host em um contêiner mongodb indo de linux-> linux porque o driver de armazenamento mmapv1 funcionará bem, mas você não pode passar um diretório mac osx através do virtualbox para um contêiner mongodb em seu laptop porque o O material do mmap não funcionará corretamente nesse caso.

Sei que isso não é um problema com relação à construção, mas a ideia de que as imagens do docker são "portáteis" e podem "rodar em qualquer lugar" é totalmente absurdo neste ponto. Se eles não podem ser executados em qualquer lugar, qual é a virtude em dizer que eles deveriam ser capazes de "construir em qualquer lugar"?

A questão é que a imagem mongodb funciona em qualquer lugar. Fornecer configuração de tempo de execução inválida é uma besta diferente.

Docker tem uma separação muito específica e intestinal de configuração portátil e configuração não portátil.

Que tal agora ?
Preciso ter meus ips reais dentro do contêiner para passar na verificação de configuração do nginx.

este é meu Dockerfile:

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

Obviamente, se eu executar o contêiner com a opção de privilégios, posso configurar o ip para a interface de loopback. Mas é mais um script a ser adicionado.

@ cpuguy83 Tenho cerca de 20 linhas de iptable entradas que gostaria de RUN em meu Dockderfile mas não posso, pois preciso de --cap-add=NET_ADMIN . Esses comandos devem acontecer independentemente de quem está executando o contêiner e independentemente da máquina em que ele é executado (o contêiner executa um aplicativo interno). Onde / como você sugere que eu faça isso com base no que você discutiu acima?

@MatthewHerbst Infelizmente as regras do iptables não podem / não podem persistir com a imagem.

@ cpuguy83 Estou usando uma imagem centos:6 e posso executar /sbin/service iptables save para manter as regras no sistema de arquivos. Acredito que seja um recurso semelhante no Ubuntu e outros por meio do pacote iptables-persistent .

Você pode apenas gerar as regras de iptables para esse arquivo, não há necessidade de
realmente os aplique. A situação da rede onde o contêiner é executado pode
ser muito diferente, então você deve apenas aplicar as regras em tempo de execução (se isso, você
pode ser melhor com o host que os gera).

Em 16 de maio de 2016 16:03, "Matthew Herbst" [email protected] escreveu:

@ cpuguy83 Estou no CentOS e posso executar run / sbin / service iptables save para
persistir as regras para o sistema de arquivos. Eu acredito que o deles é semelhante
capacidade no Ubuntu e outros por meio do pacote iptables-persistent.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

@justincormack não sei porque não pensei nisso! Obrigado!

Como você deve executar comandos que requerem privilégio ao usar docker service ? Preciso definir o nome do host em algumas de minhas máquinas, mas infelizmente isso requer privilégio.

@nostrebor isso não tem
Estamos avaliando quais opções devem existir para os serviços, em vez de copiá-los 1 para 1. O modo privilegiado provavelmente não estará em 1.12 para serviços.

Estou tentando builds docker que compilam algo para instalação, mas deve ser compilado em bibliotecas que existem em um sistema de arquivos de rede CVMFS. Claro, não posso montar CVMFS sem executar --privileged, então não posso fazer isso usando um Dockerfile.

@ cpuguy83 @tlbtlbtlb Este é o caso de um 'instalador' dependendo fundamentalmente de uma ação privilegiada. Mas não é o que eu chamaria de 'uso frívolo', só preciso acessar bibliotecas compartilhadas em um sistema de arquivos de rede. Ainda assim, a instalação neste caso NÃO é simplesmente extrair arquivos de algum arquivo.

Não entendo como montar um sistema de arquivos de rede é um problema de portabilidade. (Todos os nossos ambientes de destino terão acesso a este sistema de arquivos. Eles são obrigados porque criam outro código que TAMBÉM deve ser vinculado ao código binário no sistema de arquivos de rede.)

Devo tentar uma abordagem diferente? Devo montar o CVMFS no host e compartilhar esse diretório com o contêiner ou algo assim? Não quero ter que configurar um sistema de compilação externo apenas para fazer esta imagem - a imagem na qual é baseada já tem um sistema de compilação completo que fará o trabalho. Só preciso montar o CVMFS.

Eu estava animado para fazer isso com um Dockerfile, mas parece que terei que fazer da maneira mais difícil usando alguns scripts com docker run --privileged ou usar outra coisa em vez do docker. Existe uma maneira de montar um sistema de arquivos em um contêiner _sem_ ter acesso privilegiado?

Eu fiz uma solução alternativa, colocando / ecoando comandos privilegiados dentro de um script e usei a instrução CMD para executar o script no ponto de entrada do contêiner, então, depois de construir uma imagem como essa, posso apenas executar o contêiner no modo privilegiado e tudo funciona.

@drstapletron , de acordo com a documentação do CERN cvmfs, você tem duas opções por enquanto, montar o cvmfs do host para o contêiner ou instalar o cvmfs dentro de um contêiner privilegiado.

Para o caso dos segundos, acabei de escrever um arquivo docker para os caras do cmssw, aqui:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

então, usando este arquivo, você pode apenas construir uma imagem (ou pode ser você pegá-la do cmssw dockerhub) e executá-la no modo P, e tudo já estará lá dentro do contêiner (ls / cvmfs / *)

Não tenho certeza se isso foi abordado acima, pois é uma longa lista de comentários sobre este assunto. Eu também gostaria de ter comandos de compilação --privileged. Meu caso de uso atual é solucionar um problema que encontrei ao compilar o go ebuild em um gentoo stage3. Se eu não usar um contêiner, as instruções atuais no manual do gentoo fazem com que o systemd se comporte erraticamente quando eu 'umount -l / mnt / gentoo / dev {/ shm, pts,} && umount -l / mnt / gentoo / { proc, sys} 'de um sistema inicializado com systemd ... Quando eu movo minha compilação stage3 para um contêiner docker, tudo funciona bem até que uma compilação exija ptrace, ou algum outro recurso restrito ... que o go-1.7.1. ebuild parece exigir.

Por enquanto, estou simplesmente executando a compilação dentro de um comando docker run, confirmando e continuando a partir daí, mas seria preferível habilitar ptrace dentro do próprio comando docker build para evitar as etapas manuais.

Eu gostaria desse recurso também. Eu quero criar um ambiente de construção, mas requer um módulo de kernel e modprobe não coopera comigo quando estou construindo. Existem soluções alternativas para isso?

Especificamente:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

Parece um caso de uso totalmente razoável.

@seltzy , sugiro não prender a respiração esperando que alguém de docker reconheça a razoabilidade de seu caso de uso.

Quando se trata de arquitetura e inclusão de recursos, eles são muito pesados, pragmáticos, indiferentes e tendem a ignorar todo e qualquer caso de uso que não se encaixe em _seu_ roteiro.

Nós, pessoas comuns, precisamos entender que a equipe docker toma decisões de arquitetura que atendem às suas próprias necessidades (prováveis ​​clientes de negócios e autoatendimento), e essas decisões raramente se sobrepõem às nossas (o usuário final público) elaboradas com muito trabalho questões que arquivamos aqui.

Eles são, obviamente, livres para alocar seus recursos de engenharia dessa maneira.
Mas fornece um histórico que imploraria pela imaginação se a empresa algum dia fosse descrita como "levando a sério as necessidades do usuário".

@tamsky você

@tamsky posso entender porque você pensaria isso, já que o projeto não aceitou um recurso que você claramente deseja.

Posso garantir que isso não tem nada a ver com qualquer tipo de decisão de negócios. O fato é que --privileged na construção resultará em imagens não portáteis.
Coisas como modprobe no ambiente de construção não são úteis e podem até fazer com que duas construções produzam resultados totalmente diferentes.

Eu mesmo implementei --privileged na construção. Não é um problema de engenharia e, na verdade, é bastante trivial de implementar. É apoiar isso que é o problema.
Para usuários avançados, um construtor customizado pode ser implementado, até mesmo reutilizando o código existente, usando as APIs existentes que podem incluir suporte privilegiado.

Dito isso, esse problema ainda está aberto por um motivo. É porque as pessoas estão ouvindo.

Obrigado pela sua consideração.

@ cpuguy83 Obrigado pela explicação. Não sabia que era um problema de portabilidade. Suponho que meu desejo por isso seja alimentado por mal-entendidos.

Qual é a abordagem filosófica geral a seguir quando confrontado com a tentação de ter uma construção privilegiada?

@seltzy não tenha tanta certeza de que seu caso de uso não seja um exemplo razoável da necessidade desse recurso

@ cpuguy83 Ainda estou esperando uma resposta sobre meu caso de uso. Sistema de construção da nossa instituição é distribuído ao longo de um sistema de arquivos de rede que devo montar no meu recipiente. Isso requer que o contêiner seja executado no modo privilegiado. A decisão de minha instituição de usar um sistema de arquivos de rede para distribuição de software não é incomum para a física de partículas. Você afirma que --privileged na compilação cria imagens não portáteis, mas isso não está totalmente relacionado ao meu caso de uso. Nosso modelo de desenvolvimento já desistiu de qualquer portabilidade que _podemos_ perder devido ao uso de um sistema de arquivos de rede (sério?). Precisamos apenas que a máquina de desenvolvimento esteja prestes a montá-lo.

@ cpuguy83 PS, você mencionou um construtor personalizado. Onde posso encontrar informações sobre isso? Obrigado!

Toda essa discussão sobre a portabilidade do contêiner é uma pista falsa gigante. Você já pode realizar a mesma coisa criando uma imagem de estágio 1, iniciando um contêiner no modo privilegiado, fazendo tudo o que você precisa fazer e, em seguida, usando o docker commit para criar a imagem final desse contêiner.

Uma vez que adicionaram a opção docker commit, qualquer noção de portabilidade de imagem saiu pela porta de qualquer maneira, então forçar as pessoas a fazer isso em 3 etapas em vez de 1 não está ganhando nada e só serve para irritar as pessoas que poderiam realmente usar uma opção de construção privilegiada.

@drstapletron Montar um sistema de arquivos não é necessariamente algo que pode quebrar a portabilidade (a menos que alguém estivesse esperando que fosse montado na imagem).
O problema aqui é ter a capacidade de montar um sistema de arquivos também significa ser capaz de fazer um monte de outras coisas desagradáveis.

@ctindel Sim, você pode fazer o que quiser nos containers que criar. O fato de docker build ser "o" método suportado de construção de imagens, entretanto, significa que precisamos garantir que as imagens construídas com ele _são_ portáteis.

Imagens portáteis não são uma pista falsa. A portabilidade da carga de trabalho é o principal objetivo do design do Docker. Nossa primeira diretriz, por assim dizer.

@seltzy A maioria das coisas que requerem privilégios extras pertencem ao tempo de execução, porque na maioria das vezes os privilégios elevados são usados ​​para modificar o host de alguma forma.
Dito isso, posso certamente entender que algumas coisas são necessárias em tempo de construção (como o nfs mount acima) .... mas mesmo com o caso de NFS e construção manual da imagem (não com docker build ), eu não daria ao contêiner --privileged ou quaisquer recursos extras, em vez disso, montaria a exportação nfs como um volume.

@drstapletron mount não requer --privileged apenas um conjunto de capacidade mais restrito e é muito mais provável que aconteça antes de um modo totalmente privilegiado, pois dá acesso root completo ao host, o que a maioria das pessoas faz não quero. (Ainda tem problemas de segurança, mas são mais gerenciáveis).

Portanto, tenho um caso de uso totalmente portátil e sem modificação de host. É até código aberto e você pode vê-lo aqui .

Basicamente, eu quero executar o Mock em um contêiner Docker portátil para construir uma imagem ISO personalizada do CentOS. Mock, para quem não sabe, é um construtor de RPM em contêiner. O problema é que, como ele usa contêineres, preciso de --privileged ou --cap-add . Idealmente, acho que docker build funcionaria como uma função, pegando alguns argumentos e retornando seu resultado final. Sem essas bandeiras, porém, não posso fazer isso.

Mesmo aqui ! Usar simulação dentro do docker é um pesadelo por causa disso :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@ cpuguy83 escreveu:

O fato é que --privileged na construção resultará em imagens não portáteis.

Por que não permitir --privileged para aqueles que não exigem portabilidade de longo alcance?
Uma simples observação na documentação oficial seria um meio-termo razoável (por exemplo, _Aviso: passar --privilege para o comando build pode resultar em uma imagem menos portátil! _). Isso resolveria os requisitos de quase todos; alguns usuários não precisam de portabilidade, outros sim, um aviso seria o suficiente para atender às necessidades de todos.

Tenho certeza de que a falta de build --privileged complica significativamente meu caso de uso atual.

Ele poderia ser chamado de --non-portable . Eu não usei as partes de implantação do docker ainda, mas o material de isolamento + overlay do sistema de arquivos tem sido realmente útil sem isso.

Preciso usar um software proprietário que requer um contêiner privilegiado para instalação. Não há nada que eu possa fazer sobre isso. Estou preso com a necessidade de fazer o processo de construção, execução e confirmação de 3 estágios.

A portabilidade do contêiner não significa nada para mim ou para o meu negócio, na verdade, aposto que não significa nada para a grande maioria das empresas. O que é importante é que eu gostaria de manter menos software, então acho que selecionar portabilidade em vez de usabilidade nesta questão é prejudicial para o Docker.

1 para isso, no processo de construção usamos setfacl, isso falha durante a construção e os serviços falham ao iniciar no contêiner. Eu acho que, como usuários finais, não devemos ser restritos, use a opção --priviledge apenas se você precisar e o padrão estiver desabilitado.

1 para isso. Em nosso processo de construção, é necessário montar / proc e / dev. Idealmente, devemos ter a etapa de montagem como parte do dockerfile.

@ samsun387 Por que seu processo de construção exige isso?

@skshandilya setfacl não é portátil e eu ficaria surpreso se acls pudessem ser persistidos em uma imagem.

@robhaswell "requer um contêiner privilegiado" não ajuda muito. O que realmente está sendo usado na instalação?

+1. o init mock precisa disso.
quase li toda a edição. não entendo por que as pessoas ficam perguntando "por que você precisa disso" por 3 anos consecutivos.

@Betriebsrat Porque "X precisa disso" não ajuda muito.
O que "X" está fazendo? Por que "X" precisa disso durante a fase de construção?

Por exemplo, o caso acima com recursos para montar /proc e /dev realmente não parece o lugar certo para a fase de construção, e até parece que a imagem estaria ligada ao host em tal um caso.

"privilegiado" também é um tanque. Ele abre absolutamente tudo, desativa todos os recursos de segurança, dá acesso de gravação a locais normalmente somente leitura ... onde alguém provavelmente só precisa ser capaz de fazer uma coisa muito específica.

Essas perguntas são feitas para que possamos obter o caso de uso real e como podemos satisfazê-lo.

A propósito, quando digo "recursos de segurança", quero dizer duas coisas:

1. Coisas para evitar hacking
2. Isolamento das questões do aplicativo das questões do host (ou seja, a construção da imagem não deve amarrar a imagem ao host em que ela foi construída).

Parece que o meu foi resolvido em 21051, estou fora, por enquanto :)

@shykes disse em 28 de novembro de 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Desculpe, o design atual é para forçar '1 fonte, 1 compilação', por isso não permitimos nenhum argumento para encaixar a compilação diferente do diretório de origem.

Eu entendo o fato de que algumas compilações atualmente não podem ocorrer porque precisam de operações privilegiadas. Para lidar com isso de forma adequada, podemos precisar 1) permitir que um Dockerfile expresse a necessidade de ser construído de uma forma privilegiada e 2) implementar um sistema de autorização / trus que permita ao docker pausar a compilação, avisar adequadamente o usuário sobre o risco, expor informações sobre a origem e confiabilidade do Dockerfile e, em seguida, coletar a decisão do usuário de permitir ou negar a compilação.

@ cpuguy83 , o design mudou em relação a obrigar: "1 fonte, 1 compilação"?
O projeto Docker está disposto a alterar esse design e permitir esse recurso solicitado pela comunidade?

O comentário de Shykes acima parece esclarecer o que "podemos precisar" para resolver o problema. Ao mesmo tempo, a linguagem usada ("pode") parece fornecer ao projeto do docker muito espaço para apresentar motivos adicionais para rejeitar essa alteração de design.

Adicionar uma declaração NEEDS_PRIVILEGED faz sentido, mas tudo isso sobre pausar a compilação? Apenas falhe com um erro e deixe o operador passar a opção --privileged se ele realmente quiser permitir a construção privilegiada.

@ cpuguy83 o que acontece é que as pessoas que sempre precisam do modo privilegiado no build são geralmente usuários avançados que sabem perfeitamente bem quais são os riscos de usá-lo. E a maioria deles aceita isso e contorna isso simplesmente usando docker commit como parte de sua construção para a etapa que precisa disso.

Você não está de forma alguma impedindo que as pessoas usem o modo privilegiado no build, você está apenas tornando isso irritante.

Se o seu objetivo é tornar isso irritante, diga-o abertamente e encerre esta edição, em vez de deixá-la continuar por anos e anos.

Diga "não vamos consertar isso porque queremos que seja chato de fazer" e feche o problema.

/fio

@ cpuguy83 , do meu entendimento, o Mock usa unshare(2) com o sinalizador CLONE_NEWNS - e possivelmente outros - quando cria seu ambiente chroot / contêiner. Isso requer pelo menos CAP_SYS_ADMIN .

O que "X" está fazendo? Por que "X" precisa disso durante a fase de construção?

Em nosso caso de uso, não sabemos. É uma porcaria proprietária que não podemos mudar. O fato é que nosso negócio não se preocupa com "segurança" (neste contexto) ou portabilidade, ou qualquer uma das preocupações que foram listadas. Queremos apenas colocar essa porcaria em um recipiente e passar a fazer algo valioso.

Como @PonderingGrower diz, vamos fazer isso de qualquer maneira, é apenas uma questão de quanto tempo perderemos enquanto fazemos isso.

pessoas que sempre precisam do modo privilegiado no build são geralmente usuários avançados que sabem perfeitamente bem quais são os riscos de usá-lo

Eu discordo totalmente dessa suposição. No geral, as pessoas que usam --privileged são da mesma categoria de usuários que executam chmod -r 777 cegamente "porque alguém escreveu que corrigiu o problema"

Em nosso caso de uso, não sabemos. É uma porcaria proprietária que não podemos mudar. O fato é que nosso negócio não se preocupa com "segurança" (neste contexto) ou portabilidade, ou qualquer uma das preocupações que foram listadas.

"neste contexto" aqui, significando: dar "alguma porcaria proprietária" acesso root em seu host.

@thaJeztah Não tenho nenhum problema com isso. É um software que compramos e pelo qual pagamos suporte. Se não estivéssemos usando contêineres, ele ainda precisaria de root para instalar.

Precisamos desse recurso para usar dind durante a construção para pré-configurar alguns contêineres dentro daquele que estamos construindo.

O que você está discutindo aqui por 3 anos?

docker run tem opções --cap-add , --cap-drop e outras. Portanto, o comando RUN em Dockerfile deseja ter as mesmas opções. Portanto, Dockerfile deseja enviar solicitações para a máquina pai e pedir a ela para adicionar / retirar alguns privilégios.

A máquina-mãe pode fazer o que quiser com essas solicitações. Você pode tornar o shell interativo, pode fazer uma caixa de diálogo de confirmação da interface do usuário, etc. Por que você está discutindo a resolução dessas solicitações neste problema?

Um número significativo de usuários do docker deseja a capacidade de --cap-add ou --privileged no comando build, para imitar o que está lá no comando run.

É por isso que este tíquete está aberto há 3 anos com pessoas constantemente concordando, mesmo que os mantenedores não estejam interessados ​​em dar aos usuários o que eles querem nesta instância específica.

@ctindel Este é definitivamente o problema desta edição. Há uma lacuna entre docker build --cap-add e RUN --cap-add .

Algumas pessoas desejam resolver solicitações de privilégios de máquinas-filho com apenas docker build --cap-add=caps_array . O que é? Isso é apenas: caps_array.include? requested_cap .

Algumas pessoas querem pre_requested_caps.include? requested_cap . Algumas pessoas querem stdout << requested_cap, stdin.gets == 'y' . Algumas pessoas querem gui_confirm requested_cap . Algumas pessoas definitivamente vão querer UAC_fullscreen_dialog requested_cap .

O método de resolução de requested_cap depende do gosto do usuário e acho que esta questão nunca será respondida.

Mas RUN --cap-add não tem nada a ver com o gosto das pessoas. O que estamos esperando?

@ andrew-aladev Eu realmente não entendo o que sua postagem está dizendo. A questão é que as pessoas têm softwares de terceiros (RPMs, DEBs, qualquer que seja) que não estão sob seu controle, que desejam instalar em uma imagem no momento do "docker build" e que requer recursos extras para instalar corretamente. Como são RPMs de terceiros, não há como resolver o requisito de privilégios aumentados durante a fase de instalação.

Eles estão contornando o problema executando um contêiner com esses recursos aprimorados, instalando seu software e, em seguida, criando uma imagem desse contêiner. É uma dor e mostra claramente que não há razão funcional para proibir o acréscimo de limite no tempo de construção, uma vez que o mesmo fim pode ser alcançado indiretamente.

@ctindel Meu inglês não é muito bom, desculpe.

Eu sei. Tentei emerge glibc e recebi ptrace not permitted .

docker pode executar contêineres com recursos aumentados / diminuídos por si só. RUN comando Dockerfile deve suportar --cap-add , --cap-drop , etc.

Vamos imaginar que nosso Dockerfile terá RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . Como isso funcionaria?

1. A máquina filho envia uma solicitação ao pai e pede SYS_PTRACE .
2. Pai permite recursos estendidos.
3. O pai cria um novo contêiner com SYS_PTRACE permitido.

Vejo que ninguém nesta edição está realmente discutindo sobre isso. As pessoas estão apenas discutindo sobre um método de permitir esses recursos.

@thaJeztah disse

No geral, as pessoas que usam --privileged são da mesma categoria de usuários que executam cegamente chmod -r 777

Este homem quer um método mais flexível de validação dos recursos necessários do que apenas log :info, requested_cap; return privileged? .

@ctindel você disse

Adicionar uma declaração NEEDS_PRIVILEGED faz sentido, mas tudo isso sobre pausar a compilação? Apenas falhe com um erro e deixe o operador passar a opção --privileged se ele realmente quiser permitir a construção privilegiada.

Você deseja tornar o shell interativo. Você quer stdout << requested_cap, stdin.gets == 'y' . Este é outro método de validação de recursos necessários.

@ cpuguy83 disse

alguém provavelmente só precisa ser capaz de fazer uma coisa muito específica ... coisas para prevenir hacking.

Este homem quer docker build --cap-add=caps_array caps_array.include? requested_cap . Este é outro método de validação de recursos necessários.

Portanto, estou perguntando: Por que RUN em Dockerfile ainda não tem suporte de --cap-add , --cap-drop , etc? Ninguém discute sobre isso. 3 anos se passaram!

@ andrew-aladev Estou assumindo que ninguém defendeu essa sintaxe porque ficou claro que a sintaxe do dockerfile é congelada até que o construtor seja reescrito / refatorado / desacoplado do mecanismo principal. https://github.com/docker/docker/issues/29719#issuecomment -269342554

Mais especificamente, o título da edição e OP estão solicitando - compilação privilegiada

isso faz Fonzie bater: .

ser capaz de executar strace na etapa build ajuda muito.
atualmente, eu trabalho em torno disso movendo todas as coisas que preciso depurar para a etapa run - não é o ideal.

alguém sabe por que funcionaria na etapa run e não na etapa build ? ou seja, as razões históricas.
existe uma alternativa para strace que funciona sem muita permissão ou configuração?

Há uma proposta de solução / solução alternativa para isso em
https://github.com/docker/docker/issues/6800#issuecomment -50494871:

se você tiver problemas na compilação do docker, pode usar um "container builder":
docker run --cap-add [...] mybuilder | docker build -t myimage -

Alguém (possivelmente @tiborvass) poderia elaborar sobre isso? Que tipo está mybuilder aqui?
O nome da imagem com algum ENTRYPOINT? Ou a imagem é parte de [...] e mybuilder se refere
para um script de shell? E como faço para convencer docker run a passar o context.tar.gz para o docker build -
se isso é realmente o que está acontecendo aqui. Agradecemos antecipadamente, Steffen

@sneumann mybuilder seria um nome de imagem e teria algum CMD ou ENTRYPOINT fato. O contrato para essa solução alternativa funcionar é que mybuilder terá que tar o contexto de dentro do contêiner e deixá-lo ir para stdout. Isso é passado para o stdin de docker build , graças ao tubo de shell | e é considerado o contexto porque o caminho de contexto para docker build -t myimage - é - .

um pouco estranho ao olhar o código parece que esta opção está disponível no comando build :

• run : suponho que container aqui significa run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go # L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

Alguém mais informado tem ideia do porque não está sendo aplicado?

@mbana o --security-opt é para contêineres nativos do Windows, que suportam "credentialspec" https://github.com/docker/docker/pull/23389

é possível modificar isso e fazê-lo persistir de forma que build futuro habilite ptrace ?

para qualquer pessoa interessada, aqui estão alguns bons links:

• http://www.projectatomic.io/docs/docker-building-images/ - como construir a imagem usando a técnica descrita acima. ou seja, use run para build a imagem.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - misc

Já vi muitas afirmações de várias pessoas de que esse recurso não é necessário porque as compilações podem ser alteradas para não exigir certas operações privilegiadas, mas nenhuma sugestão sobre o que fazer sobre o caso "docker in docker". Se uma construção precisa executar comandos docker , por exemplo, para puxar algumas imagens que queremos enviar dentro desta, ou para construir uma sub-imagem, como podemos fazer isso sem algum tipo de privilégio opção de construção?

Por enquanto, vou contornar isso usando docker run e docker commit mas seria ótimo se docker build pudesse suportar este caso de uso.

@scjody Parece que você quer # 31257

@ cpuguy83 Não tenho certeza se isso cobre o que está acontecendo neste caso, mas vou tentar uma vez que for mesclado. Obrigado!

Olá, gostaria de colocar meu nome no item por favor, implemente este chapéu. Ou talvez haja uma solução diferente para o meu problema (docker noob aqui) que alguém poderia apontar para mim?

Estou tentando construir uma imagem baseada na imagem oficial centos / systemd e provisioná-la com o Saltstack. Isso requer iniciar (e talvez reiniciar) o daemon salt-minion com o systemd, o que não pode ser feito (AFAIK) sem o modo privilegiado.

@onlyanegg Acho que nessa situação, o Saltstack substitui em grande parte a funcionalidade do construtor; tenha em mente que cada instrução RUN é executada em um novo contêiner, ponto no qual o contêiner de compilação anterior é interrompido e confirmado em uma imagem / camada.

Você considerou realizar a compilação executando um contêiner e confirmando os resultados ( docker commit )?

Obrigado por responder, @thaJeztah. Não sabia que era isso que a diretiva RUN fazia. Eu li a maior parte deste problema, então estou ciente da solução alternativa docker build -> docker run -> docker commit , que é o que provavelmente vou acabar fazendo. Eu apenas sou mais a favor de ter um único arquivo que descreva minha imagem - parece mais organizado. Talvez eu possa colocar todas essas etapas em pós-processadores do packer e então terei isso.

Por que este é tão ignorado? Em tempos de contêineres, kubernetes e minikube, e uso de docker em CI e unificação de ambiente de desenvolvimento, essa funcionalidade é realmente crucial.

@onlyanegg você deve poder reiniciar os serviços _sem_ modo privilegiado. Se você tiver um Dockerfile ilustrando isso (ou seja, "o comando RUN na linha 8 deste Dockerfile não funciona porque requer modo privilegiado"), ficaria mais do que feliz em dar uma olhada!

@derberg precisamente! Em tempos de contêineres, CI, CD, é importante que as ferramentas de construção possam estar contidas (no sentido de segurança). Se você permitir o modo privilegiado, terá que mudar drasticamente a forma como usa as ferramentas CI como Jenkins, Travis, Codeship, etc. Mesma pergunta: se você tiver um Dockerfile que requer o modo privilegiado, ficaria feliz em dar uma olhada e sugerir alternativas.

Obrigado!

@jpetazzo tente obter uma imagem do docker com o docker dentro dele:

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

Agora construa e inicie. Depois de iniciar, execute service docker start para iniciar o docker deamon. Em seguida, verifique o status do serviço service docker status :

• com status de sinalizador privilegiado está ok e você pode iniciar o contêiner sem problemas
• sem a bandeira, nunca começa

@jpetazzo ech, acabei de notar que você é o criador de https://github.com/jpetazzo/dind :), então você conhece o docker no conceito docker :)

De qualquer forma, você está ciente de que o sinalizador privilegiado é necessário para a execução. Então agora você pode imaginar um grupo de pessoas trabalhando em algum ambiente e querendo ter um ambiente unificado para desenvolvimento com algumas coisas pré-configuradas dentro, por exemplo minikube com componentes pré-instalados ou qualquer outra coisa

Então, existe uma maneira de montar um compartilhamento NFS ou SMB em docker build ?

@derberg essas etapas não funcionarão, mesmo se o contêiner de compilação estiver executando --privileged ; os pacotes do docker (e o script de instalação) estão (por exemplo) instalando pacotes do kernel no Ubuntu 16.04.
Essa é exatamente a razão pela qual --privileged é uma má ideia para docker build , porque ele seria capaz de fazer alterações no _host_.

Mesmo que o docker precise de privilégios ao _running_, a instalação em si não precisa disso; por exemplo, aqui estão as etapas que você executaria para instalar o docker em sua imagem;

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

E você pode executá-lo perfeitamente (estou usando --privileged aqui, mas talvez permissões mais refinadas sejam possíveis):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

Aqui está como contornar esse problema, para pessoas que realmente precisam construir uma imagem docker no modo privilegiado. Pode não resolver todos os casos, mas pode ajudar em alguns.

Este método precisa de um Dockerfile, um arquivo docker-compse e um script de shell.

O Dockerfile

É o mesmo que você precisa para construir a imagem. A única diferença, pare onde você precisa fazer operações privilegiadas, não as inclua. Eles precisam ser executados pelo docker-compose, como um script. Por exemplo:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

Esses outros comandos que precisam ser executados no modo privilegiado agora estão em further-commands-to-run-in-privileged-mode.sh . Ele está incluído na imagem e, posteriormente, será executado pelo docker composer para concluir o processo de construção.

O arquivo de composição do docker

O arquivo de composição é a chave. Ele construirá a imagem primeiro a partir do Dockerfile acima e iniciará um contêiner a partir dessa imagem no modo privilegiado , então você pode fazer sua operação privilegiada lá. Por exemplo:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

Construa a imagem

As etapas abaixo também podem ser salvas em um script de shell.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah Não tenho problemas com a instalação, tenho problemas em iniciar o serviço docker durante a compilação e extrair algumas imagens para tê-las disponíveis na imagem fora da caixa.

Adicione o seguinte script ao seu Dockerfile e você verá que o serviço docker nunca inicia

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg OK, entendo! _Pessoalmente_, se eu quisesse incluir imagens em um contêiner dind , eu faria o download delas (por exemplo, com reg ) e as carregaria na primeira vez que o contêiner iniciar. Porque? Porque se você puxar as imagens durante a construção, a imagem funcionará _somente se dind for iniciado com o mesmo driver de armazenamento_. Em outras palavras, sua imagem pode ou não funcionar em outra máquina.

Além disso, se suas imagens forem grandes (ou seja, qualquer coisa além de, digamos, busybox ou alpine ), você acabará com uma imagem DinD realmente grande ...

Adoraria saber mais sobre seu caso de uso final - porque tenho certeza de que podemos ajudá-lo a encontrar uma maneira mais eficiente do que assar uma enorme imagem DinD :-)

(Caso contrário, a solução proposta por @kraml é bastante elegante!)

Consulte também https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Baixa imagens usando apenas bash + curl + tar.
Nós o usamos aqui: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo já executamos com essa solução alternativa build-run-commit, mas sim, ainda é uma solução alternativa do meu ponto de vista. O caso de uso é muito específico relacionado ao ambiente de kubernetes e minikube e não há nada que possamos fazer por enquanto. Por enquanto, fomos capazes de iniciar o minikube no docker apenas com o docker como um daemon, usar o virtualbox ou outros drivers de vm não funcionou, então dependemos da abordagem dind

Encontrei esse problema ao tentar construir uma imagem contendo um aplicativo legado (caso de uso bastante normal), onde o instalador tentou executar comandos sysctl e falhou.

Voltando a este tópico e revisando todos os 4 anos (!!!) de ida e volta sobre a questão de como adicionar algum tipo de recursos privilegiados ao comando docker build, parece que as opções disponíveis nesta situação são um grupo desagradável de comandos sed para modificar o instalador para remover as chamadas sysctl, ou uma compilação de vários estágios -> executar -> pipeline de confirmação. Eu concordo com @derberg que 'construir -> executar -> confirmar' parece ser uma solução alternativa (imo uma solução alternativa grosseira / hackeada) e não acho que meu caso de uso seja tão único. Verificando outros tópicos, vi muitas pessoas relatando problemas com várias instalações de aplicativos e bancos de dados com comandos docker build com falha devido à falta de privilégios.

Neste ponto, o comando docker run suporta várias opções 'privilegiadas', junto com "controle de granulação fina sobre os recursos usando --cap-add e --cap-drop". E então, eu acho que as objeções com base na segurança ou técnica são discutíveis. Se a opção de execução privilegiada for adicionada junto com '--cap-add' e '--cap-drop', um engenheiro preocupado com a segurança pode escolher limitar uma construção privilegiada para incluir apenas os recursos específicos necessários para sua construção.

Oi ,

Já relatei isso antes, mesmo problema.

E aqueles que querem apenas executar um contêiner por VM com o mesmo ID de usuário na VM e no contêiner, usando o docker apenas como uma ferramenta de empacotamento?

Ainda existe uma preocupação de segurança relacionada a isso?

Encontrei este problema. Realmente poderia usar recursos para construir.

Também enfrentou esse problema.
É muito útil ao usar o docker como escravos CI / CD que podem exigir permissão privilegiada em docker build para instalar as cadeias de ferramentas de compilação / teste CI / CD ao construir a imagem do docker escravo.
Estou esperando por esse recurso há anos e realmente espero que possa ser suportado no futuro.

Eu realmente não entendo por que há tanta resistência dos desenvolvedores em relação a --privileged for docker image.
Se os usuários querem atirar no próprio pé, por que não deixá-los? Basta colocar uma mensagem de aviso e é isso. Já existem soluções alternativas para conseguir a mesma coisa, por que não tornar mais fácil para os usuários que realmente precisam?
Já se passaram 4-5 anos e não houve nenhum progresso nisso.
Simplesmente incrível...

Até hoje, nem mesmo esse recurso foi implementado ainda:
RUN --cap-add = SYS_PTRACE
que atenderia às necessidades de muitos usuários.

Você poderia sugerir como posso construir este Dockerfile no host Gentoo Linux:

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

porque estou recebendo este erro ao emergir dev-lang / go:

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

Como posso executá-lo sem --cap-add=SYS_ADMIN --device /dev/fuse ou --privileged ?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

Posso fazer isso com um arquivo bash separado no entrypoint, mas preciso de um único Dockerfile

@ amd-nick qual é sua expectativa da linha RUN unionfs-fuse ... durante a construção? Mesmo que funcionasse, ele teria apenas o sistema de arquivos montado durante aquele único RUN e desapareceria na próxima etapa.

@thaJeztah é difícil de explicar para mim. Estou tentando modificar este repo . Posso simplesmente pular esta linha no prédio?

Oi

Aleatoriamente, a compilação do docker escolhe um nome de host começando com zero '0' que quebra nosso aplicativo. Tentei executar "hostname" nesse caso dentro do meu DockerFile, mas enfrentei o mesmo problema.

Também gostaria de ter a opção de executar a compilação do docker com RUNP ou obter a opção de escolher o nome do host durante a compilação.

Alguém já tentou construir esse tipo de imagem com Kaniko ? Acabei de fazer isso com o Dockerfile de @maneamarius no Docker para Mac e parece que foi compilado com sucesso quando você chama o comando docker run "build" de Kaniko com --cap-add=SYS_PTRACE . No entanto, estou tendo problemas para carregar o tarball resultante localmente, o uso de RAM é um pouco alto, pois não pode usar overlayfs e o cache de camada ainda é WIP. As coisas podem simplesmente funcionar se eu enviar para um registro, mas ainda não tentei.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

Ter esse recurso ajudaria muito nos esforços para construir imagens Docker por meio de imagens base do Puppet no Redhat / CentOS.

Desde a última vez que postei, segui de volta com as mudanças em Kaniko . Eles não estão mais fazendo tarball na memória e sim no disco, o que significa suporte para Dockerfiles que descrevem imagens grandes. O cache de camada ainda é um WIP, mas eles têm uma opção para armazenar em cache as imagens de base no momento (isso significa atualmente nenhum tipo de trabalho rápido de salvar e executar RUN iteração, mas podemos armazenar em cache alpine , ubuntu e quaisquer bases populares que existam).

Está em um estado em que tive sucesso na construção do Dockerfile de @maneamarius que emerge Golang em uma imagem do Gentoo neste projeto / demonstração sem modificar o Dockerfile de @maneamarius ou cortá-lo de qualquer forma ( EDITAR: teve que modificar Dockerfile para fixar a imagem base do gentoo na versão que era latest no momento desta postagem. Caso contrário, ainda não foi modificada. ):

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

Também configurei o Azure Pipelines para construir o Dockerfile em uma imagem com Kaniko com --cap-add=SYS_PTRACE , carregar o tarball de saída de Kaniko e executar go version na imagem gerada. Achei que alguma "prova de vida" interativa seria interessante. Alguns dos comentários anteriores aqui também diziam respeito aos sistemas de CI, então decidi configurar um sistema de CI público para funcionar também. Aliás, o Travis CI foi considerado, mas a saída da compilação era muito longa e foi encerrada e o Azure está perfeitamente satisfeito com 166 mil linhas de saída. Se o Dockerfile fosse construído com cerca de 70k a menos de linhas de saída, provavelmente teria tido sucesso no Travis CI. Um link para as saídas de compilação do Azure Pipeline está na parte superior do README.

Use buildah Luke

Estou encerrando este problema, porque o recurso agora está disponível como docker buildx build --allow security.insecure

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run --- securityinsecuresandbox

@AkihiroSuda Eu atualizei meu docker para a versão 19.03 para tentar buildx . Quando eu estava tentando o comando que você mencionou, ele me deu um erro

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

documentos buildx: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Obrigado @AkihiroSuda . Funcionou agora.

apenas para adicionar outro caso de uso.
Estou tentando consertar uma compilação de dockerfile de um contêiner ibmdb2 com um banco de dados de teste
A IBM removeu a imagem v10 do hub. Mas a imagem do banco de dados v11 só começa com --privileged.
Portanto, todo o código que configura o banco de dados no Dockerfile não é funcional agora porque o db2 não inicia sem privilégios. :(
Parece haver uma solução alternativa complicada com o uso do docker run e do docker commit.
Em um pipeline de construção produtivo, isso cria muita complexidade extra.

Tenho que perguntar como https://github.com/maneamarius em https://github.com/moby/moby/issues/1916#issuecomment -361173550

Por que é tão importante apoiar isso? A construção executa uma execução sob o capô.

Neste caso de uso específico, uma opção de compilação privilegiada ofereceria suporte a um tipo de "compatibilidade com versões anteriores" e eu sei que não sou o único que teve esse problema depois de minha pesquisa na web.

@uvwild Não tenho certeza se isso ajuda seu caso de uso, mas você pode tentar construir com kaniko Sua imagem será construída sem um docker deamon e você pode extrair a imagem assim que estiver pronta e usar o kaniko é apenas como executar um contêiner você pode usar --privileged ou --cap-add <capability which is needed> que pode resolver seu problema.

Aceito que não seja uma solução completa que você esperava, mas uma solução mais fácil que pode caber em seu pipeline de construção.

EDITAR: Como @ alexey-vostrikov disse que buildah poderia ser uma solução mais viável para casos de uso que precisam de --privileged para construir a imagem