Respostas:
Se você estiver no OSX executando boot2docker, veja este problema: https://github.com/boot2docker/boot2docker/issues/290
A sincronização de tempo se torna um problema porque o host boot2docker tem seu tempo oscilante enquanto o sistema operacional está adormecido. A sincronização de tempo com seu contêiner do docker não pode ser resolvida executando seu contêiner com-v /etc/localtime:/etc/localtime:ro
Em vez disso, por enquanto, você deve executar isso periodicamente no OSX:
/usr/local/bin/boot2docker ssh sudo ntpclient -s -h pool.ntp.org
Atualização para usuários do Kitematic
Se você estiver executando o Kitematic , que agora é o mecanismo sugerido para iniciar e executar no Docker no OSX, deverá executar este comando periodicamente:
docker-machine ssh default 'sudo ntpclient -s -h pool.ntp.org'
Ou, para versões mais antigas do docker
docker-machine ssh dev 'sudo ntpclient -s -h pool.ntp.org'
Atualização para usuários do novo Docker nativo para OSX
O novo Docker Beta acaba com VirtualBox e Docker Machine. As últimas compilações do docker (atualmente, 1.12.1-beta25 (compilação: 11807)) parecem ter a capacidade de detectar quando houve uma descontinuidade de tempo e ajustar de acordo. Portanto, isso não deve ser mais um problema ... hooray !!
https://github.com/sameersbn/docker-gitlab/issues/77
Veja a resposta de sameersbn.
option 1: -v /etc/localtime:/etc/localtime:ro
option 2: -e "TZ=Asia/Shanghai"
A solução mais simples parece ser executar seu contêiner com a -v /etc/localtime:/etc/localtime:ro
opção. Portanto:
#run without tz info:
docker run --rm -t -i ubuntu date
Wed Apr 2 18:40:07 UTC 2014
# run with tz info:
docker run --rm -t -i -v /etc/localtime:/etc/localtime:ro ubuntu date
Wed Apr 2 11:40:29 PDT 2014
--privileged
modo).
date
na máquina host em meu MWE, caso contrário, talvez não esteja claro se o contêiner obtém seu tempo do host.
setup mount namespace mounting /etc/localtime into /mnt/sda1/var/lib/docker/aufs/mnt/.../etc/localtime not a directory
No Docker para Mac OS X Beta, experimentei um desvio significativo na VM, que é baseada no Alpine Linux. No Alpine Linux FAQ, você pode sincronizar o relógio da VM com o seguinte comando.
ntpd -d -q -n -p pool.ntp.org
No entanto, obter acesso a um terminal na VM é outra questão, que pode ser feita se você usar o comando screen.
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
Esse caminho é um link simbólico, que aponta para o meu sistema /dev/ttys003
.
Depois de entrar, observe que o moby login
está simplesmente root
sem senha. Após terminar, CTRL-A, D se desconectará da sessão de tela.
NOTA: Isso costumava ser documentado no Docker para Mac Trouble Shooting, mas parece ter sido removido. Tive a sorte de vê-lo durante o Dockercon 2016. Parece que o Docker está tentando abstrair a VM completamente da experiência, o que explica por que não está mais documentado.
A solução atual para osx time drift no docker (abril de 2018):
Eu tenho meu mac em um servidor NTP, mas este relógio fixo muda com contêineres:
De https://docs.docker.com/docker-for-mac/troubleshoot/#known-issues :
Se o seu sistema não tiver acesso a um servidor NTP, após uma hibernação, o tempo visto pelo Docker para Mac pode ficar consideravelmente fora de sincronia com o host. Além disso, o tempo pode vagar lentamente fora de sincronia durante o uso. Para redefinir manualmente o tempo após a hibernação, execute:
docker run --rm --privileged alpine hwclock -s
Ou, para resolver os dois problemas, você pode adicionar o relógio local como uma fonte de tempo NTP de fallback de baixa prioridade (estrato alto) para o host. Para fazer isso, edite o /etc/ntp-restrict.conf do host para adicionar:
server 127.127.1.1 # LCL, local clock
fudge 127.127.1.1 stratum 12 # increase stratum
Em seguida, reinicie o serviço NTP com:
sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist
sudo launchctl load /System/Library/LaunchDaemons/org.ntp.ntpd.plist
Adicione /etc/localtime:/etc/localtime:ro
ao volumes
atributo.
Veja este link para demonstrar um exemplo.