Sign inSign up

phirumseng/knetrahub-ipmgt-api

By phirumseng

•Updated 7 days ago

KNetraHub IP Management API: endpoints and migrations, no background jobs.

Image
0

723

phirumseng/knetrahub-ipmgt-api repository overview

⁠phirumseng/knetrahub-ipmgt-api

IP Management API — the request half of IP Management.

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 IP Management module's HTTP API and realtime (SSE) endpoints, plus its schema migrations. No background jobs.

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

⁠How it works

Serves IP Management'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 IP Management'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-ipmgt-api (this image)yesnorequest load
knetrahub-ipmgt-worker⁠noyesjob volume
knetrahub-app⁠yesyesnothing — it is one process

Scale this with request and dashboard load. Scale ipmgt-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_REPLICAS2set
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

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_IPMGT_API_IMAGE, which the stack file reads:

export KNETRAHUB_IPMGT_API_IMAGE=phirumseng/knetrahub-ipmgt-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:fe97937f0…

Size

60.7 MB

Last updated

7 days ago

docker pull phirumseng/knetrahub-ipmgt-api