search

oats-center / isoblue

ISOBlue Hardware, Avena software, and Deployment Files
MIT License
20 stars 9 forks source link

Dealing with "supervisor" requests, .e.g, TSDB user creation #26

Open aaron97neu opened 4 years ago

aaron97neu commented 4 years ago

Postgres/timescaledb currently uses "password" as the password for the database. As the ISOBlue lies behind a VPN, no one outside of the VPN should be able to access it regardless of the passsword. However, this should still be investigated, especially if we want to expose it on the wireguard interface in the future

Original comment by @abalmos in https://github.com/OATS-Group/isoblue-avena/pull/24#issuecomment-644517054_

abalmos commented 4 years ago

Talked about a supervisor service with local REST API for system status and admin requests like this. My gut says that might be a good direction ... ?

abalmos commented 4 years ago

Side thought: If we move forward with #29, then maybe one "supervisor" service isn't right... Maybe we should have "sidecar" supervisors that run as part of the related service:

  1. network-manager container has an API to configure the network (establish a WiFi connection, configure routes, etc), create a "hotspot", configure cell connection.
  2. modem-manager container has an API to spit out cell modem info, etc.
  3. postgres has an API to manage users, extensions, etc. Others?
abalmos commented 4 years ago

Here is a reference: https://www.magalix.com/blog/the-sidecar-pattern

That is for k8s ... but if you s/Pod/docker-compose/g then it is essentially the same idea. These various docker-compose files would all live in /data/services/core and be started together with many -f's at boot. If each service shared a private network with its sidecar and only the sidecar exposed to the host, then the only way to get the service would be through Avena's API.

abalmos commented 4 years ago

Although, for something like network-manager I guess the sidecar is the only real "service" to run.

abalmos commented 4 years ago

To clarifly (and to add yet although comment :) ), network-manager still runs on the host but it doesn't have any of the "connections" defined. Rather, our service has them and gives it all to the network manager service over DBUS. Our service could provide static configurations that we deploy (or set via the API), as well as "live" changes over the Avena API.