Sign inSign up

phirumseng/knetrahub-dbmanager-api

By phirumseng

•Updated 2 days ago

KNetraHub Database Manager API: endpoints and migrations, no background jobs.

Image
0

860

phirumseng/knetrahub-dbmanager-api repository overview

⁠phirumseng/knetrahub-dbmanager-api

Database Manager API — the request half of Database Manager.

KNetraHub is a self-hosted IT operations portal: a Docker Swarm console, full-stack monitoring, work management, privileged access management, IP address management and a database workspace, behind one sign-in. It ships two ways — as a single monolith image, or as the split stack of one image per service that this image belongs to.

šŸ“– Documentation: https://sengphirum.github.io/KNetraHub/documentation⁠


⁠What this image does

The Database Manager module's HTTP API and realtime (SSE) endpoints, plus its schema migrations. No background jobs.

It bundles the server code of dbmanager and nothing else, so the image carries only the module it is named after.

⁠How it works

Serves Database Manager's HTTP endpoints and its realtime stream, and applies that module's own schema migrations at start-up. It opens two database pools: the portal pool it shares with every service, and Database Manager's module pool, which it shares only with that module's worker.

⁠What it deliberately does not do

It runs no background job whatsoever. Nothing here polls, sweeps or drains, so restarting it interrupts requests only — never the work already in flight on the worker.

⁠Privileges

Runs unprivileged with cap_drop: [ALL] and nothing added back.

⁠Which image do I want

ImageServes HTTPRuns background jobsScale it with
knetrahub-dbmanager-api (this image)yesnorequest load
knetrahub-app⁠yesyesnothing — it is one process

Scale this with request and dashboard load. Scale dbmanager-worker separately when it is the jobs, not the traffic, that are growing.

⁠Settings

Read straight from the stack file that deploys this service, so the list is what the image actually takes. Optional entries ship commented out.

VariableDefault
NUXT_APP_REPLICAS1set
NUXT_DB_POOL_MAX8set
NUXT_MODULE_POOL_REPLICAS1set
NUXT_JWT_SECRETchange-me-to-a-long-random-stringset
NUXT_ENV_MODEstagingoptional
NUXT_DB_HOSTtimescaledbset
NUXT_DB_PORT5432set
NUXT_DB_NAMEknetrahubset
NUXT_DB_USERknetrahubset
NUXT_DB_PASSWORDchange-me-to-a-long-random-stringset
KNETRA_INTERNAL_TOKEN_FILE/run/secrets/knetrahub_internal_tokenoptional
NUXT_DBMANAGER_MASTER_KEY_FILE/run/secrets/knetrahub_dbmanager_master_keyoptional
DBMANAGER_GATEWAY_COMMAND_KEY_FILE/run/secrets/knetrahub_dbmanager_gateway_command_keyoptional
NUXT_DOCKER_HOSTmanager.example.comoptional
NUXT_DOCKER_PORT2376optional

Anything ending in _FILE reads its value from that path instead, which is how the stack passes Docker secrets.

⁠Deploying it

This is one service of a stack, not a standalone container: it expects the portal database and its siblings on the same overlay network. Deploy it with the stack file that owns it rather than with docker run.

docker stack deploy -c docker/docker-compose.yml knetrahub

Pin a tag or a registry for this one service with KNETRAHUB_DBMANAGER_API_IMAGE, which the stack file reads:

export KNETRAHUB_DBMANAGER_API_IMAGE=phirumseng/knetrahub-dbmanager-api:0.1.11

⁠Supported tags

  • latest — the most recent release
  • x.y.z (e.g. 0.1.11) — immutable release versions

Pin the version in production. A rollback needs a tag that does not move, and every image in the stack is released under the same version so the whole set can be pinned together.

⁠The rest of the stack

Each service is its own image, so one can be updated without restarting the others:

⁠License

Proprietary — Ā© Seng Phirum. All rights reserved.

Tag summary

Content type

Image

Digest

sha256:298ed918b…

Size

60 MB

Last updated

2 days ago

docker pull phirumseng/knetrahub-dbmanager-api