Eu tenho um problema que estou procurando para obter algum feedback sobre a maneira correta de "docker" para resolver. Eu acredito que este é Docker para Mac específico por causa do fato de montagens de ligação usam osxfs e os inodes são de 64 bits, não 32 bits. Ao contrário dos sistemas de arquivos como cifs que permitem o uso de ‘noserverino’, os ossxfs não parecem ter uma maneira de permitir que o cliente determine inodes em vez do sistema montado.
Eu criei uma imagem docker básica baseada no Ubuntu 16.04
FROM ubuntu:16.04@sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368
RUN dpkg --add-architecture i386
RUN apt-get update && apt-get install -y \
bzip2 \
expect \
file \
gtk2-engines-murrine:i386 \
libgtk2.0-0:i386 \
libxtst6:i386 \
lib32stdc++6 \
libxt6:i386 \
libdbus-glib-1-2:i386 \
libasound2:i386 \
make \
maven \
openjdk-8-jdk \
patch \
python \
rsync \
swig \
unzip \
vim \
wget \
&& rm -rf /var/lib/apt/lists/*
O propósito desta imagem é para o servidor como um ambiente de construção comum para desenvolvedores. Ele também inclui um compilador comercial para um dispositivo incorporado de 32 bits mais antigo. Para os fins desta explicação, a imagem do docker é denominada "crosscompiler"
O uso do Ubuntu (16.04 especificamente) não tem sido um problema para os desenvolvedores em uma forma de máquina virtual, mas os muitos benefícios do Docker superam a abordagem de VM. Portanto, esta imagem do Docker é substituir a VM.
Então o PROBLEMA: Como o compilador cruzado é um conjunto de ferramentas de 32 bits, ele conta com bibliotecas i386 a serem incluídas, que incluímos no Dockerfile acima.
Para usar essa imagem para compilar código, podemos executar algo como o seguinte:
docker run --rm -ti --volume=/path/to/source/code/to/build:/root/workspace crosscompiler /bin/sh -c “cd /root/workspace && ./build.sh”
build.sh executa um script que cria todo o código. A questão é que, porque este é um compilador cruzado de 32 bits que faz coisas como stat (que em nosso compilador mais antigo não tem suporte para arquivos grandes, ou seja, inodes de 64 bits). Quando o contêiner do Ubuntu monta o diretório hosts contendo o código-fonte, os inodes são todos de 64 bits e o GNU Tools de 32 bits vê esses arquivos como Value too large for defined data type . Atualmente, eu não sei de nenhuma maneira de dizer osxfs (ou seja, o compartilhamento do sistema de arquivos macOS usado com Docker para Mac).
Qual seria o caminho sugerido para resolver algo assim?
O objetivo aqui é permitir que as alterações no código-fonte local no host sejam facilmente compiladas no contêiner. Isso será usado localmente ou em um ambiente de Construção Contínua, então é vantajoso criar uma solução elegante e sustentável.