Skip to content

Microservices

Nikita Ivanovski edited this page May 4, 2023 · 15 revisions

Overview

Notes

  1. Every NoCloud Microservice Doc section in this page has Container section, with all supported enironment variables and requirements listed.

Reverse Proxy

Well, Traefik routes trafik, you coudn't see that coming.

However, you can refer to Running Localy section at README file to see how to set it up.

See Traefik Docs for more info.

This is the default "routing table" shown considering you're running locally(Production setup would basically replace nocloud.local domain with your base domain).

See links in Overview, like Billing Machine

# Entrypoint - Host/Domain - Path
┌── grpc
│   └── api.nocloud.local
│       ├── /nocloud.billing -> Billing Machine
│       ├── /nocloud.dns -> DNS Manager
│       ├── /nocloud.edge -> Edge service
│       ├── /nocloud.instances -> Services Registry
│       ├── /nocloud.services -> Services Registry
│       ├── /nocloud.registry -> Registry
│       ├── /nocloud.services_providers -> Services Providers(SP) Registry
│       └── /nocloud.settings -> Settings Manager
└── http
    ├── api.nocloud.local -> API Server WEB
    ├── db.nocloud.local -> ArangoDB UI
    ├── rbmq.nocloud.local -> RabbitMQ Manager UI
    └── traefik.nocloud.local -> Traefik Dashboard
  • http - port 80
  • grpc - port 8000

See this article for Production setup scenario example.

DataBase

ArangoDB is the DataBase back-end for NoCloud.

Collections and indices are mostly created in runtime(once the other services are up and running), so you won't need any further interactions. But if you need to, UI is always available at db.nocloud.local or

Updates

NoCloud is ought to use latest versions of software and libraries. And Database is no exception. Although one might face issues while restarting Database if it got updated. One of them is this:

FATAL Database '_system' needs upgrade. Please start the server with the --database.auto-upgrade option
FATAL Database '_system' upgrade failed. Please inspect the logs from the upgrade procedure

ArangoDB is asking for some mystical auto-upgrade. Use this to instantly fix this issue:

docker-compose run --rm db arangod --database.auto-upgrade

Health

Provides minimal API for Health checks. Reference to this protobuf for API

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • PROBABLES - comma separated list of NoCloud microservices hosts, like serviceX:port,serviceY:port

Networks:

  • Must be resolvable by proxy
  • Must resolve given PROBABLES

API

Probe: PING

Just checks wether health microservice is available. Must return PONG

Probe: Services and Routines

Each of NoCloud microservices implements gRPC Service InternalProbeService. This service has two methods.

  1. Service - Returns infos about service, like it's status, errors and name, Health microservice combines them into one and returns as ProbeResponse
  2. Routine - Returns infos about service routines, like it's status, last execution time, errors and name, Health microservice combines them into one and returns as ProbeResponse

API Server WEB

Provides gRPC Gateway - REST API and serves Admin UI static files.

Reference:

See proto files and this reference for REST API description

Admin UI is accessible at api.nocloud.local/admin

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • APISERVER_HOST - Combined gRPC API, normally proxy

Networks:

Registry

Manages NoCloud Accounts and Namespaces in DB, Permissions, Authorization mechanisms, makes tokens

See this protos for API reference:

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password
  • NOCLOUD_ROOT_PASSWORD - i guess it's quite self-speaking
  • SETTINGS_HOST - Settings service host

Networks:

Services Registry

Manages NoCloud Services in DB, initiates deployments to Services Providers, checks for Instances Billing Plans and runs Services consistency check Routine.

See this API reference: Services Registry API

Routine updates Service document with Instances UUIDs index and stores their latest State from State manager

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password
  • DRIVERS - comma-separated list of drivers hosts like driverX:port,driverY:port
  • SETTINGS_HOST - Settings service host
  • BILLING_HIST - Billing service host
  • STATES_HOST - States manager host

Networks:

SP Registry

Manages NoCloud Services Providers in DB, runs Monitoring routine.

See this API reference: Services Providers Registry API

Routine triggers Monitoring action with each Services Provider registered.

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password
  • DRIVERS - comma-separated list of drivers hosts like driverX:port,driverY:port
  • SETTINGS_HOST - Settings service host
  • STATES_HOST - States manager host

Networks:

Billing

Manages NoCloud Billing Plans, Transactions and Records, runs Routines.

See this API reference: Billing API

Routine runs two sub routines:

  1. Generate Transactions Routine checks for all unprocessed Records to be executed and combines them into transactions to be immediately processed
  2. Process Transactions Routine checks for all unprocessed Transactions to be executed and deducts their total from according Accounts balances

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password
  • SETTINGS_HOST - Settings service host

Networks:

Edge

This service provides API to let Instances update them selves from location via Instance Tokens.

See this API reference: Edge API

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password
  • STATES_HOST - States manager host

Networks:

DNS Manager

Provides API to manage internal DNS using CoreDNS and Redis.

See this API reference: DNS Manager API

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • REDIS_HOST - States manager host

Networks:

  • Must be resolvable by proxy
  • Must resolve given Redis host

Settings

Provides Thin API to manage platform global settings. Settings are stored in Redis.

See this API reference: Settings API

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • REDIS_HOST - States manager host

Networks:

  • Must be resolvable by proxy
  • Ultimately must be resolvable by all NoCloud Microservices internally
  • Must resolve given Redis host

Proxy

Proxies requests to the ServicesProviders API. Mainly WebSockets(for example for VNC).

Accepts connections from *.proxy.${BASE_DOMAIN} where * is ServicesProvider's UUID.

Socket proxy is available at path /socket.

Headers and Query are forwarded.

The Proxy destination URL must be set at ServicesProvider's ProxyConf field(proxy).

Container

Environment variables:

  • LOG_LEVEL - integer between -1 and 5, where -1 is DEBUG and 5 is FATAL
  • SIGNING_KEY - NoCloud JWT Signing Key
  • DB_HOST - ArangoDB host as host:port
  • DB_CRED - ArangoDB credentials as username:password

Networks:

  • Must be resolvable by proxy
  • Must resolve Database