Packages, Requirements, Planning, and Preparation¶
Enterprise Nucleus Server ships as a series of
stack and configuration files. A user is expected to configure the underlying
infrastructure, adjust configuration as required, and deploy one or more
compose stacks in accordance with her needs.
Compose files will pick up various containers for Nucleus components from a docker container registry, access to which is required in addition to obtaining the compose files.
Please contact your NVIDIA representative to obtain access to the above artifacts.
Within your package, you will find a number of setups - combinations of
compose files, settings (
.env) files, and miscellanea.
Each compose setup has at least two parts to it -
.yml (which is
the actual compose file) and
.env (which contains most common
settings for the compose file).
Trying to keep our documentation as close to the code as possible, the bulk
of information necessary to successfully deploy a stack is contained in the
.env files. Please make sure to review these files, and make sure you understand them completely. That’s where the bulk of actual Nucleus setup documentation lives. Not doing so is going to ensure that you will arrive at a broken deployment.
Some advanced features may require modifying the compose (
files - with details inside them as well.
Note: these compose files are designed for docker-compose setups, and will not run on Swarms, though they can be easily adopted to run there.
Just a quick reminder on starting and managing
docker-compose --env-file <.env file path> -f <.yml file path> pulldownloads images
docker-compose --env-file <.env file path> -f <.yml file path> upstarts the stack in the foreground, with logs streamed to your terminal
docker-compose --env-file <.env file path> -f <.yml file path> up -dstarts the stack in the background, ‘daemonizing’ it
docker-compose --env-file <.env file path> -f <.yml file path> downstop the stack or cleans up, which is a useful thing to do before starting it back up
System and Infrastructure Requirements¶
Nucleus stack does not require any special hardware - it’s a simple CPU/RAM/IO workload. From an operational and resource utilization standpoint, it can be thought of as a sophisticated file server.
12+ cores (3.0 GHz or better)
32 gigabytes of RAM - and the more RAM the better due to OS filesystem level caching
Network and storage based on desired IO performance and capacity
Above configuration will work well for up to 500 total users and 10 concurrent downloads. If more concurrent downloads are expected, we recommend adding one LFT instance per 10 concurrent downloads. Each one of those will require an additional core and an additional one gigabyte of RAM.
One instance of Nucleus can support up to 25 simultaneous live editing sessions. If more are desired, multiple instances of Nucleus should be deployed.
In reality, of course, resource usage will highly depend on load.
Ultimately, we recommend monitoring the installation, and adding resources and scaling services as required.
Note: the above are recommended amounts of resources to be allocated for a production instance. For evaluation and playing around, a few cores and 4-6 gigabytes of RAM should be sufficient.
Aside from basic considerations of making sure network matches and balances out other IO bottlenecks, for production instances, prudence may dictate isolating Nucleus Servers in a separate, controlled, subnet, and following other security and network architecture best practices. With SSL/TLS, latter becomes a necessity (having Nucleus on an open network will negate all benefits of SSL/TLS because Nucleus keeps its service ports open regardless of SSL/TLS).
Topic of SSL/TLS configuration is covered in its own section.
Having a DNS server is desirable as well - and with SSL/TLS, becomes a necessity.
In addition to basics, an installation of Nucleus requires some keys and may require SSL/TLS certificates, depending on the desired goals.
In production environments, questions of proper generation and house-keeping of those should be answered, if security is a consideration.
In general, requirements for key generation and handling can be summarized as:
Ability to generate and manage symmetric keys of varying lengths
Ability to generate and manage RSA keypairs
Host operating system can be any Linux - keeping in mind that you will need to install a recent Docker onto it. We run Ubuntu 18.04, Docker CE 18.x and 19.x on our production instances, and find that generally Ubuntu is the most user friendly and catered to. Other most popular options include CentOS and Debian.
We currently do not support Docker on Windows.
Docker and Compose¶
We run Docker 18.x and Docker 19.x in our installations. Newer versions of Docker should work as well, though we have not tested them.
Do not use your distribution’s default packages, or any other packages
coming from a package manager (i.e., snap). They are usually
outdated or packaged incorrectly. In other words,
apt install docker and just expect it to work - it most likely
We do not run firewalls on our Docker hosts. We have observed in-the-field
situations where enabled firewalls (ie,
ufw) caused problems
(services not being accessible, crashloops of some services, etc).