Docker support

Sure, try generating the cloudzoo.json file again. And just to be certain, are you using --isolation process when building the image?

If it still doesn’t work, try using the --pull argument when building to ensure you’re using the latest windows base image.

I’ve made a couple of changes to the Dockerfile…

  • Replaced the 1903 base image with 1809, since Windows Server 2019 hosts are the most common deployment environment for Windows containers.
  • Rhino 7 WIP now requires .NET 4.8 which needs to be installed before installing Rhino if you’re using the 1809 base image (1903 and later already have .NET 4.8).
  • The preferred method of licensing Rhino in this environment is now to use a RHINO_TOKEN environment variable instead of cloudzoo.json. This make it much easier to configure the license outside of the image.

Which version will this take in effect ? I am assuming from the date of your post after 8 Sep

I am running into this error when trying to run the docker image. Is this because I have not set up a RHINO_TOKEN environment variable ?:

[13:50:09 INF] Compute 1.0.0.0, Rhino 7.0.20287.16003
[13:50:09 INF] Configuration Result:
[Success] Name compute.geometry
[Success] ServiceName compute.geometry
[13:50:09 INF] Topshelf v4.1.0.172, .NET Framework v4.0.30319.42000
[13:50:09 INF] Launching RhinoCore library as ContainerAdministrator
[13:50:14 ERR] An exception occurred
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
at Rhino.Runtime.InProcess.RhinoCore.InternalStartup(Int32 argc, String[] argv, StartupInfo& info, IntPtr hostWnd)
at Rhino.Runtime.InProcess.RhinoCore..ctor(String[] args, WindowStyle windowStyle, IntPtr hostWnd)
at compute.geometry.OwinSelfHost.Start() in C:\src\compute.geometry\Program.cs:line 78
at Topshelf.ServiceConfiguratorExtensions.<>c__DisplayClass2_0`1.<WhenStarted>b__0(T service, HostControl control)
at Topshelf.Builders.DelegateServiceBuilder`1.DelegateServiceHandle.Start(HostControl hostControl)
at Topshelf.Hosts.ConsoleRunHost.Run()

I’m currently seeing the same thing as Docker support.

I’m using the default docker image and get:

2020-10-16T14:26:42.067+02:00	[12:26:41 INF] Compute 1.0.0.0, Rhino 7.0.20259.15365
2020-10-16T14:26:42.387+02:00	[12:26:42 INF] Configuration Result:
2020-10-16T14:26:42.387+02:00	[Success] Name compute.geometry
2020-10-16T14:26:42.387+02:00	[Success] ServiceName compute.geometry
2020-10-16T14:26:42.387+02:00	[12:26:42 INF] Topshelf v4.1.0.172, .NET Framework v4.0.30319.42000
2020-10-16T14:26:43.469+02:00	[12:26:43 INF] Launching RhinoCore library as ContainerAdministrator
2020-10-16T14:26:49.962+02:00	[12:26:49 ERR] An exception occurred 
2020-10-16T14:26:49.962+02:00	System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
2020-10-16T14:26:49.962+02:00	at Rhino.Runtime.InProcess.RhinoCore.InternalStartup(Int32 argc, String[] argv, StartupInfo& info, IntPtr hostWnd)
2020-10-16T14:26:49.962+02:00	at Rhino.Runtime.InProcess.RhinoCore..ctor(String[] args, WindowStyle windowStyle, IntPtr hostWnd)
2020-10-16T14:26:49.962+02:00	at compute.geometry.OwinSelfHost.Start() in C:\src\compute.geometry\Program.cs:line 78
2020-10-16T14:26:49.962+02:00	at Topshelf.ServiceConfiguratorExtensions.<>c__DisplayClass2_0`1.<WhenStarted>b__0(T service, HostControl control)
2020-10-16T14:26:49.962+02:00	at Topshelf.Builders.DelegateServiceBuilder`1.DelegateServiceHandle.Start(HostControl hostControl)
2020-10-16T14:26:49.962+02:00	at Topshelf.Hosts.ConsoleRunHost.Run()

I will investigate if a different Rhino version or perhaps Windows image will get a different result.

I tried another non-docker way.

Did all the steps according to https://github.com/mcneel/compute.rhino3d/blob/master/docs/deploy.md and end up with

C:\Users\Administrator\Desktop\compute> .\compute.geometry.exe
[10:04:40 INF] Compute 1.0.0.547, Rhino 7.0.20287.16003
[10:04:41 INF] Configuration Result:
[Success] Name compute.geometry
[Success] ServiceName compute.geometry
[10:04:41 INF] Topshelf v4.1.0.172, .NET Framework v4.0.30319.42000
[10:04:41 INF] Launching RhinoCore library as Administrator
[10:04:41 ERR] An exception occurred
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
    at Rhino.Runtime.InProcess.RhinoCore.InternalStartup(Int32 argc, String[] argv, StartupInfo& info, IntPtr hostWnd)
    at Rhino.Runtime.InProcess.RhinoCore..ctor(String[] args, WindowStyle windowStyle, IntPtr hostWnd)
    at compute.geometry.OwinSelfHost.Start() in C:\projects\compute-rhino3d\src\compute.geometry\Program.cs:line 78
    at Topshelf.ServiceConfiguratorExtensions.<>c__DisplayClass2_0`1.<WhenStarted>b__0(T service, HostControl control)
    at Topshelf.Builders.DelegateServiceBuilder`1.DelegateServiceHandle.Start(HostControl hostControl)
    at Topshelf.Hosts.ConsoleRunHost.Run()

So I will guess this is not Docker specific. I’m using Windows version 1809, Build 17763.1518.

I have not yet set up core hour billing, but I hope that would not have this effect.

What else can I try?

@t.ho, @martinkretz – I think you’re both running into the same issue. A month ago we made core-hour billing a requirement for running Rhino on Windows Server or in a Docker container.

Please take a look at part 1. of the “Deploying Rhino Compute” guide for steps to set up core-hour billing and get a token that you can use to set the RHINO_TOKEN environment variable in the container.

You’ll need to do this even if you’re already using core-hour billing. The method using cloudzoo.json (described in earlier versions of the Dockerfile) no longer works.

I have now set up core hour billing, and set the token - both on a manually started EC2 with the script install, and also by running the Dockerfile setup, only changing the RHINO_TOKEN, both locally and on AWS ECS. They all end with the same result as above.

Is there any way I can debug further to understand what is not working?

Perhaps I should add that I have had this working about 5 months ago.

And those Dockerfile scripts, unchanged, are now not working either locally or on AWS. That to me indicates that the problem may lie outside the container, i.e. in the Windows version or similar.

How does your Dockerfile differ from the current Dockerfile in the compute.rhino3d repo? In particular, as of a couple of months ago, there’s an additional build step to pre-install .NET 4.8 on 1809.

On the EC2 instance, is the RHINO_TOKEN environment variable set and is it correct? Does Rhino run interactively?

I have tried to eliminate all variables, so I’m also testing with the default Dockerfile in the repo, with the only diff setting the environment variable RHINO TOKEN inside the Dockerfile.

If I build that image and run locally, I get the same error. I can’t run it interactively as it is a headless VirtualBox running on Mac.

If I do the install on an AWS EC2 machine, and run it interactively I get an error of no licensing, which I thought would be normal, since I have not logged in. Or should the RHINO_TOKEN licensing work here?

Thanks for being thorough! Did you check the checkbox next to Rhino 7 when setting up the core-hour billing team (step 4. here)?

The RHINO_TOKEN should take care of logging you in and fetching licenses from the core-hour billing team.

Ah, that’s it! We set up core billing, and managed to get a token out, but somehow neither Rhino 6 nor Rhino 7 was checked.

Just verified on docker locally, and scripted install on AWS EC2. It works!

Thanks for your help @will!

3 Likes

Rhino 7 doesn’t seem to install on a Windows Server Core image, according to my tests on Azure (whereas it does install on a Windows Server image). Do you know what’s the dependence that’s missing from Windows Server Core?

Unfortunately not. Is there something stopping you from using the Windows base OS image?

No, however it implies a larger image size and hence an online registry with higher capacity.

I can appreciate that but I’m afraid this is the solution we have right now.

I have succeeded in building and running this container on an AWS EC2 Windows Docker instance but I can’t connect to the container from localhost. I have tried both with localhost ip and the docker containers ip.

I am used to using docker in Linux and are just beginning to learn how it works in a Windows Server environment. Any idea what I might have missed?

@frank.havsvinge Did you expose the port?

https://docs.docker.com/desktop/windows/networking/

@will I did. Do I need to configure the Windows firewall perhaps?

Edit: The issue ended up being unrelated to the RHINO_TOKEN (build, dependencies, etc), just happened to be breaking in the same place in the same way. Question is now just out of curiosity!

Is there a way I can know why my token is being rejected, or if it’s part of the problem at all? Currently experiencing this issue even after setting RHINO_TOKEN in the Dockerfile.

I can confirm it’s available in the environment variables before Rhino tries to start. But I also just updated my Rhino.Inside from 0.1.1 to 7.0.0. So if the answer is to finally just use the newer template instead of grafting onto my old one, I totally understand.