apt atualizar comportamento diferente no Dockerfile e prompt, retornar o código de erro 100, mas funciona

Question

Estou tentando instalar uma fonte apt na janela de encaixe da função Microsoft Azure, aqui está meu Dockerfile

FROM mcr.microsoft.com/azure-functions/python:3.0-python3.9

RUN echo 'deb [trusted=yes] http://deb.debian.org/debian testing main' > /etc/apt/sources.list.d/testing.list
RUN apt update -y

Isso falha na apt update -yetapa com o seguinte erro

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
Get:2 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Hit:3 http://security.debian.org/debian-security jessie/updates InRelease
Get:4 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Get:5 https://packages.microsoft.com/debian/9/prod stretch InRelease [4009 B]
Get:6 http://deb.debian.org/debian testing InRelease [112 kB]
Get:7 https://packages.microsoft.com/debian/9/prod stretch/main amd64 Packages [161 kB]
Get:8 http://deb.debian.org/debian testing/main amd64 Packages [8248 kB]
Reading package lists...
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
E: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'stable-updates' to 'oldstable-updates'
The command '/bin/sh -c apt update -y' returned a non-zero code: 100

Mas:

• se eu executar exatamente os mesmos dois comandos após iniciar docker run --rm -it --entrypoint bash mcr.microsoft.com/azure-functions/python:3.0-python3.9, apt update -yfunciona bem,
• se eu alterar a imagem base debian:buster-slimna qual a imagem se baseia, a construção do docker funcionará bem,
• mesmo se o comando falhar, posso instalar o pacote de testing, por exemplo, apt update -y || apt install g++instalarei g++-10em vez do padrão g++-8no Buster.

Alguma ideia de por que o comando falha? E como posso consertar isso?

---

Editar:Adicionar --allow-releaseinfo-changeno apt update -ydockerfile corrigiu o problema, mas ainda gostaria de saberpor quefalhou sem?

---

Observação:A pergunta foi movida do SO porque aparentemente está fora de tópico... Deixe-me saber se também está fora de tópico aqui.

Answer 1

DR

A raiz do problema é um bug na imagem base que você está usando. A correção permanente é limpar /var/lib/apt/listso Dockerfile da imagem base, mas isso pode ser contornado temporariamente reconstruindo a imagem base ou usando a --allow-releaseinfo-changeopção.

A razão pela qual esse comportamento difere entre docker builde docker run -ité o uso do -tsinalizador para alocar um tty. Isso muda o comportamento de apt -y( APT::Get::Assume-Yes).

Explicação completa

Repositório ... mudou seu valor 'Suite'

Este erro ocorre quando:

1. O APT tem uma versão em cache do arquivo Release -Este é o erro. As imagens base do Docker geralmente devem limpar esse cache.
2. O repositório remoto tem uma versão mais recente
3. Certos campos não correspondem entre as duas versões

Em um ambiente não-docker,esta verificação destina-separa proteger o usuário de instalar repentina e inesperadamente pacotes de uma versão Debian diferente.

Neste caso, a imagem base mcr.microsoft.com/azure-functions/python:3.0-python3.9 contémversões em cache dos arquivos de lançamento do Debian buster(condição #1) com Suite: stable, porque era atual no momento em que foi construído.

No entanto, a cópia master noO arquivo Debian é mais recente(condição #2), e agora tem Suite: oldstable(condição #3), porque o Debian 10 buster foisuplantadapelo Debian 11 alvo.

Então, quando você tenta executar apt updatenesta imagem base, ela falha devido aoincompatibilidadeentre a versão antiga em cache e a versão atual.

Experimentei seu Dockerfile agora há pouco (03/09/2021) e funcionou bem para mim. Provavelmente porque ele foi reconstruído desde que você postou esta pergunta. Isso teria feito com que ele armazenasse em cache os novos arquivos Release do arquivo Debian, corrigindo a incompatibilidade (#2/#3 acima não são mais verdadeiros).

No entanto, você pode verificar se o bug ainda existe:

$ docker run --rm -it --entrypoint bash mcr.microsoft.com/azure-functions/python:3.0-python3.9               
root@722ec78233b4:/# grep Suite /var/lib/apt/lists/*Release
/var/lib/apt/lists/deb.debian.org_debian_dists_buster-updates_InRelease:Suite: oldstable-updates
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_InRelease:Suite: oldstable
/var/lib/apt/lists/packages.microsoft.com_debian_9_prod_dists_stretch_InRelease:Suite: stretch
/var/lib/apt/lists/security.debian.org_debian-security_dists_buster_updates_InRelease:Suite: oldstable
/var/lib/apt/lists/security.debian.org_debian-security_dists_jessie_updates_InRelease:Suite: oldoldstable

E o mesmo erro ocorrerá após o próximo lançamento do Debian, quando o buster se tornar oldoldstablee o bullseye se tornar oldstable.

Vi recentemente um problema semelhante com uma imagem base do docker não relacionada e acho que esse bug é bastante difundido.

Comportamento da -yopção

Quando você executa aptum tty como stdin, -ysubstituirá essa verificação e permitirá que o updatecomando seja bem-sucedido. Porém, se não houver tty (sessão não interativa), a -yopçãonão substituiráesta verificação. Confirmei isso usando uma versão mais antiga da imagem com erros:

# aborts    
docker run --rm mcr.microsoft.com/azure-functions/python:3.0.15066-python3.9-slim apt update -y

# succeeds
docker run -t --rm mcr.microsoft.com/azure-functions/python:3.0.15066-python3.9-slim apt update -y

# prompts for y/N to continue
docker run -it --rm mcr.microsoft.com/azure-functions/python:3.0.15066-python3.9-slim apt update

# aborts
docker run --rm mcr.microsoft.com/azure-functions/python:3.0.15066-python3.9-slim apt update