Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Windows] How to properly set container Time Zone configuration? OR, how to ignore host Time Zone configuration? #40284

Open
sanguedemonstro opened this issue Dec 4, 2019 · 11 comments

Comments

@sanguedemonstro
Copy link

@sanguedemonstro sanguedemonstro commented Dec 4, 2019

Hi, I'm using the following Windows Server Core Image:

FROM microsoft/dotnet-framework:4.7.2-runtime-windowsservercore-ltsc2019

My container image need to run over unknown container hosts, like AWS, Azure AKS, On Premises and even on Windows Desktops and those hosts have unknown Time Zone configurations.

I need to ensure that an Windows Server Core ltsc2019 container runs under an exactly Time Zone.

I'm newbie, but as far as I know, the whole thing about containers is ship it as image once and run it everywhere, with environment isolation and integrity.. right?!

Well, I already tried:

  • tzutil or Set-Timezone: Not OK, lack of privileges
  • set registry during dockerfile build: Not OK, container starting seems to ignore it

So,

  • How to properly set container Time Zone configuration?
  • How to ignore host Time Zone configuration?

By the way, Windows Location and Language container settings seems to have same issues :(

@thaJeztah

This comment has been minimized.

Copy link
Member

@thaJeztah thaJeztah commented Dec 4, 2019

@olljanat

This comment has been minimized.

Copy link
Contributor

@olljanat olljanat commented Dec 4, 2019

@sanguedemonstro Why system timezone matters on your use case? Common way handle these is use UTC time on those parts of code where time really matters (e.g. authentication) and then on UI side show time using timezone on where end user is located.

Side comment. If possible I highly recommend port your application(s) to .NET Core and switch to Linux containers because of much better performance, stability and community support.

@StefanScherer

This comment has been minimized.

Copy link
Contributor

@StefanScherer StefanScherer commented Dec 4, 2019

AFAIK in a Windows container you cannot change timezone. In old versions of Windows Server this worked, but actually it changed the timezone on the host. Nowadays it's blocked in a Windows container to prevent changing the host.

@sanguedemonstro

This comment has been minimized.

Copy link
Author

@sanguedemonstro sanguedemonstro commented Dec 4, 2019

Hi @thaJeztah @StefanScherer @olljanat ..

Why system timezone matters on your use case?

System Time Zone really really really matters on my use case, I'm porting whole legacy ERP systems to container, those systems are composed by:

  • IIS ASP.NET Application
  • who calls Win32 processes
  • both uses Win32 windows service

There are .NET components and Win32 components, some of them from 3rd party.
A lot of those components depends on system current time using it as param value in database commands like insert/update, from C#, Delphi and VBA Script.
A lot of computing is made based on system current time, comparing database values, always considering local time.

No way to change that.

We build and maintain a lot of ERP systems (accounting, HCM, health care, logistics, industry, tourism) for hundreds of customers running on many scenarious (cloud, on-prem, hybrid) all over the country.

Our company is beting on Windows Server containers to bring legacy systems to the cloud.

.NET and Win32 softwares will be around for long time for sure.. Microsoft could realize that globalization settings like language and time zone are fundamental to keep the world runnig..

So.. any help would be awesome.

Thanks!

@olljanat

This comment has been minimized.

Copy link
Contributor

@olljanat olljanat commented Dec 4, 2019

@sanguedemonstro OK. That is definitely right use case for Windows containers. I just wanted to make sure because you see (ugly) issues/limitations which does not exist Linux version of Docker.

However if you cannot change application(s) code then your options are:

  • Deploy your own Windows container VMs where you can control host timezone. Preferred option because it also allow you control Docker version and Windows updates (which you really want to have if you are running business critical workloads on top of Windows containers).
  • Include some middleware which uses similar idea than http://www.nirsoft.net/utils/run_as_date.html to your containers and use it to provide time on timezone you want.

I also suggest that you invest to Microsoft Premier Support becsuse it really is only way to get support for Windows containers issues which are not on open source parts of the code.

PS. We have run Windows containers on production about 2 years now and I have been the one who has tried to tackle those most critical issues so if you want here more about real world experiences you can reach me on Docker community Slack.

@sanguedemonstro

This comment has been minimized.

Copy link
Author

@sanguedemonstro sanguedemonstro commented Dec 5, 2019

@olljanat Thanks for your words.

I have opened 2 suggestions on Windows Server uservoice, here and here.

please, everybody who agree, vote up.

@olljanat

This comment has been minimized.

Copy link
Contributor

@olljanat olljanat commented Dec 5, 2019

@sanguedemonstro read your playground docs now and noticed that we have got date and time to be visible on Finnish format (and PowerShell cmdlet Get-Culture says also fi-FI).

That is done by importing those settings directly to registry by using Dockerfile like this:

FROM mcr.microsoft.com/windows/servercore:ltsc2019
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; Set-ExecutionPolicy Unrestricted -Force;"]
COPY RegionSettings.reg /
RUN REG IMPORT C:\RegionSettings.reg

And here is actual registry file (which I have just exported from server with full UI):
RegionSettings.reg

@olljanat

This comment has been minimized.

Copy link
Contributor

@olljanat olljanat commented Dec 5, 2019

@sanguedemonstro Other thing which come to my mind is that even on AKS those Windows container nodes are dedicated for single Azure tenant so it is technically possible to have different settings on them between Azure tenants.

That why I think that you should also create feature request for them about --timezone switch to az aks nodepool add command. Windows support for AKS is still on preview mode and under active development so it is much more likely that they will add it than implement some timezone isolation for Windows containers.

@sanguedemonstro

This comment has been minimized.

Copy link
Author

@sanguedemonstro sanguedemonstro commented Dec 5, 2019

That why I think that you should also create feature request for them about --timezone switch to az aks nodepool add command.

Yes @olljanat , feature request was created few days ago, here.

@weijuans-msft

This comment has been minimized.

Copy link

@weijuans-msft weijuans-msft commented Dec 12, 2019

Thanks @olljanat @sanguedemonstro for the feedback! I will file a bug on our end (if we don't have one) and keep you updated on the progress.

@olljanat - great to see you have been running Windows containers in production for 2 years. That's amazing! Would love to know more and hear your best practices. You can reach me and my team by email at win-containers@Microsoft.com. or on Twitter @WeijuanLand.

@olljanat

This comment has been minimized.

Copy link
Contributor

@olljanat olljanat commented Dec 12, 2019

@weijuans-msft I actually started list those to MicrosoftDocs/Virtualization-Documentation#818 already a while ago and can update latest ones there.

Also I was earlier keep tracking of known issues on https://github.com/olljanat/docker-issue-tracking but it is not fully up to date

Not so nice thing looks to be that Win Srv 2019 added a lot of new issues to Windows containers which indicates that integration tests with Docker features have not been run on Microsoft side (and lot of them are actually disabled on Moby too for Windows). That why we have been forced to keep most of our production containers still on Windows Server 2016. Also when I was working on with #39733 it started to feel that no one on Microsoft have not actually done any kind of load test/benchmarking for Windows containers...

So yes I can update those which was listed above and also drop your email but if I can wish I would like to see more people from Microsoft working with Moby project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.