NextHost is a service designed to manage the creation, use, and status of hostnames. Hostnames are generated based on rules defined in the pattern. Once created, hostnames are available for use and can be assigned, reserved, or released.
Think of NextHost as an IPAM but for hostnames.
NextHost is build on python3, django2.2, and bootstrap 4. Components such as the database powering it are configurable. The demo uses MySql.
The best use of NextHost is likely in your host provisioning workflow. An example workflow could be creating a project and one or more patterns in NextHost, which automatically generates pools of hostnames (per pattern). Next your automation can get/assign the 'next available hostname' from NextHost via API call. (you can also assign a hostname through the web GUI) When a host is de-provisioned, another call can release the hostname back to the pool, making it available for future use.
NextHost is not a DNS. NextHost is a database of hostnames that tracks which hostnames are available, assigned, and reserved. The best analogy is that of an IPAM, but instead of tracking use and available IP address per subnet, NextHost tracks used and available hostnames per pattern in a project.
A project in NextHost is an organizational construct used to group similar hosts with defined ownership. Say, for example, you have a fleet of Redis servers. These could all live under a 'Redis' project where a particular group is responsible for ownership. All projects must have a owner.
Patterns are pools of hosts under a project. This creates differentiation based on things like environment, location, zone, or whatever is applicable.
Let's say for our Redis project we have dev, staging, and prod environments. We can reflect this with patterns such as redis_dev, redis_staging, redis_prod. Patterns include rules to generate hostnames, which are generated when a pattern is created.
There is no limit to the number of projects or patterns in NextHost.
Yes. Projects and patterns can be updated at anytime. If the count of hostnames in a pattern increases, new hostnames will be created. If the number decreases, unassigned hostnames will be removed.
Hostnames are generated when a pattern is created. The pattern sets rules, such as the structure of the hostnames, count of hostnames allowed, and interable definitions. Based on these rules, hostnames are generated and set to an initial status of available.
No; this is by design.
You can assign, reserve, or release a hostname via RESTful API of web GUI. For the API, the endpoint consists of the hostname and the desired action; such as: <server_address>/api/v1/hostname/<hostname>/release/
No. All hostnames are unique and no duplicates are allowed.
NextHost provides a full set of RESTful APIs for managing owner, projects, patterns and hostnames.
API documentation is provided by swagger. In swagger you can see all available API endpoints, methods, parameters, and even execute the API to see output and response. Additionally, APIs are accessible via the Django Rest Framework (DRF) browsable interface. Checkout the live demo to view swagger and the DRF interface.
NextHost uses token authentication for all APIs. Read-only operations (all GET requests) are unrestricted and do not require any permissions. Other operations, such as reserving or releasing a hostname, are RBAC restricted. For example, a user would have to be an owner of the project containing the hostname change a hostname status.
Every user has an API token. You can view and reset yours in the user profile page. In NextHost, click your username in the right hand corner of the navigation bar and select Profile in the dropdown.