Self-hosted <open-vehicle-server v3> as a Docker container ?

[IamMattM]

Hi,

I am looking into OVMS for my Ioniq (no EV app), and was wondering if anyone had any suggestions as to how to run the "open-vehicle-server v3" as a docker container ?

I would be looking at running the docker container on a Synology DS920+ NAS , under DSM7.2:
Linux DiskStation 4.4.302+ #69057 SMP Mon Nov 13 14:19:30 CST 2023 x86_64 GNU/Linux synology_geminilake_920+

I must say that I am not a developer/software person but thought to perhaps ask if such a Docker Image had perhaps already been created that would run on platform above ?

I did come across a similarly named docker image called "ovms-server" and thought great !
https://registry.hub.docker.com/r/jkalapati/ovms-server/

however, I don't think it has anything to do with the open-vehicle-server ;-)

I had been hoping to run the "real" open-vehicle-server through Docker, like I do, for example, for the evcc.io server which uses a docker-compose.yaml and volume mounts with docker image available :
https://registry.hub.docker.com/r/evcc/evcc/

and supports vehicles under the ovms template:
https://docs.evcc.io/en/docs/devices/vehicles#open-vehicle-monitoring-system

I have asked evcc.io whether an additional field for a custom url would be possible when trying to make api calls to a self-hosted ovms-server:
evcc-io/evcc#12612

[IamMattM]

@dexterbg

Could a docker container for the server be created easily enough/possible at all ?

I had understood that you hosted the dexters-web.de in the cloud on a VPS and thought that perhaps you already had made use of a containerised version of the server ?

I would be hosting on a personal NAS from Synology and because of the way Synology restricts some of the "services" , the docker route would be the best course of acion for me as the alternative would be a more ressource-heavy VirtualMachine running on the NAS native linux O.S (called DSM)

Thank you for your help.

[markwj]

I don't think there is any reason a docker implementation could not be built. It would also need access to a mysql (presumably running in another container).

That said:

1. This is not a standalone install and run server. Somebody needs to implement the connection to the chosen authentication system, and presumably some UI to maintain users/passwords.
2. There is an example UI and authenticator for Drupal, but that is probably overkill for a single user.
3. Somebody with an itch to scratch needs to create the docker definitions, and publish them.

Longer term, the v2 server is not the way forward. We are migrating to MQTT, and that will then just need a basic MQTT server.

[IamMattM]

@markwj
Thank you for your reply.

I followed your advice and implemented a TLS-secured mosquitto MQTT broker with username/password authorisation and accessible from the outside.

I will "bridge" this new mosquitto container to my existing local-facing-only Mosquitto container (I did not want to have the same container dealing with both local and public end-points and possibly break things in the process...)

I believe also, that the bridging might offer me some extra degrees of security by only allowing specific topics through the bridge (i.e only the vehicleid specific one. so as ot not make the mistake of exposing my loca-facing only broker to the outside world)

Seems to be working well at first glance...

Just need to figure out how I "plumb" the received MQTT json data into both and <EVCC.io> as for the time being I was using the v2 API integrations to make it work.

Thank you for your pointer.

[markwj]

Well, I did say that the v2 -> MQTT migration is 'longer term'. But MQTT works today. Just be aware that data usage will be significantly higher than v2 protocol (which is optimised for extremely low data volumes).