I suspect that you won’t succeed. Docker is a product of Linux philosophy, where “everything” is moulded into a file. All operations are file read/write calls. If you can transfer/tunnel a file read/write operation from A to B (e.g. from inside the container to the host), it makes no difference if the write really is configuring, say, the bit rate or parity of the physical serial port. All device APIs and drivers follow this philosophy.
In Windows (as well in the great majority of pre *nix OSes), devices are distinct concepts. At the API level you have got distinct calls for e.g. configuring the hardware, different from file read/write calls. A host/container interface made to transfer information through file system calls (only) has no facilities for non-filesystem device configuration calls.
There are two solutions to this - but as far as I know, neither is available as of todyay 
-
Either, you can hope for the host/container interface in a future version to be extended, to include device management functions.
Or, you (or maybe “someone”) can write code stubs for moulding the device control functions to file system calls so that the the existing interface can be used as a tunneling mechanism. This requires a high level of expertise: In your case, you must learn exactly how the control functions are encoded when they come across the line from the Linux container. On the Windows side, you must write a service exposing a file (most likely a pipe) to the container interface in such a way that the interface believes it is a Linux style device file. The service must then interpret anything coming across this pipe and map it to Windows device calls. Status and data from the device must be mapped to the correct file write operations on the pipe going back to the container.
If the container is of Windows flavor, you must provide a device driver that captures all calls to the device, and marshall them into file system writes, and moulds data returned from the host, appearing as file system data, into device status reports for the container application.
Maybe this is not that difficult to do for a seasoned low level systems programming expert for a trivial demo example. To make a robust solution handling every possible call, every valid configuration, is a large undertaking.
For Linux, the mapping to file system calls is standardized (and has been for ages). To my knowledge, there is no similar standard mapping for Windows. Hopefully, the Linux standard can be used for that part of the functionality that is identical among the OSes, but I would be less than surprised if it turns out that Windows device operations in some details have a different semantics, or functionality not covered by the Linux encoding standard. Or, the Linux standard includes some funtionality with no equivalent in Windows. Before this can be offered as a general mechanism (so that you don’t have to install different drivers depending on which Docker image you want to run!), a standard must be established.
We have been waiting for this for USB devices for a whlle, but no solution is available, at least not yet. Several years ago, there was an open source project attempting to do it, using the network interface rather than the file system as a tunneling mechanism, but that activitiy seems to have died years ago. We hear rumours of something being worked on, but nothing is available for now.
I suspect that a USB solution has higher priority than the old COM port. Probably, if a USB solution is found, you can use a USB/RS232 adapter on the physical side, and map the serial port to a USB driver on the container (Linux) side. But you will probably have to wait a while before the USB solution is offered in the marketplace
