I can imagine a scenario that if for any reason you need some particular kernel feature inside docker container which is not available on the host (or host uses some legacy kernel incompatible with current docker) this might be the way to go. My osx system has IST time zone. When i run, docker info command, it shows a wrong system time which is few hours behind the osx host. Docker info shows UTC time. I have properly configured time/timezone on my osx host. The timezone isn't the actual issue here. The time inside the the vm on Docker for Mac drifts away from system time. ![]() If you normalize the timezone to UTC In 's example, you can see that it's 08:01:45 in the vm and 08:32:31 on the host. I have the same problem with my Docker for Mac. At the moment, it's 18:11:37 in the vm, but 18:37:20 on my Mac host. My Docker for Mac VM's been up for 4 days, and the drift increases the longest it's been up. My Mac: → ~ date Thu 9 Feb 2017 11:37:20 MST Inside the VM: / # date Thu Feb 9 18:11:37 UTC 2017 / # uptime 18:13:11 up 4 days, 2:30, load average: 0.41, 3.22, 2.99. Thank you for your report. Unix systems run their system clock in UTC and any appearance of timezones is entirely a userspace concern i.e. So I'm afraid to say that the behaviour you are seeing is by design and unlikely to change. Please lets keep this issue for the timezone issue which the original report is concerned about instead of hijacking it to be another dup of. Without some external help, guest VMs on any platform will inevitably drift time from the host. It's a fundamental issue that VMware and Citrix deal with via the agent they highly encourage you install on the guest VM. The answer to this issue is to add a mechanism to sync time sources from host-> guest on a regular basis; either via direct hwclock assignment via crontab on the guest vm, or via a guest vm service solution like ntp/chrony. However, that explanation doesn't solve this issue for you guys with timing-sensitive docker images. I happen to have this same problem at the moment. So, in the meantime, I put together a super-gross docker image to run chrony on the VM that Docker for Mac utilizes. () It's been working for me, but obviously use at your own risk. Please submit issues to the github issue tracker as you find them; I'll do my best to address them in a timely manner. My hope is that the Docker for Mac CE build has a legit fix for this issue still landing within Q3/2018. Until then, I sincerely hope my awful hack helps ya'll out a bit. I was recently working on containerizing the data pipeline I wrote as part of my work at Zopper. This pipeline uses Boto3 to connect to Amazon SQS and SNS. While containerizing this pipeline, I managed to run 2 services that power the backward flow of the pipeline in 2 different containers while the forward flow pipeline was breaking because of some issue. I decided to look into it the next day. As usual my Mac got in sleep mode. The very next day, I did docker-compose up, I was expecting that 2 containers would run and I would start debugging the issue with the forward flow pipeline service; and it wasn't that easy. As soon as the 2 containers were spawned, they were destroyed. After inspecting the logs, I realized I was getting an error while connecting to Amazon services as: Amazon SQS SignatureDoesNotMatch: An error occurred (SignatureDoesNotMatch ) when calling the GetQueueUrl operation: Signature expired ) ' I immediately tried to verify the AWS keys for expiry, but they were correctly working. The services would run separately on a host correctly. So, I realized it has something to do with Docker. This would happen if you're using any of the Amazon's servies and here is the how I came to know about the problem: I tried to manually run the container and then exec a shell in it; to know the date.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |