This page provides the information needed for system administrators wanting to set up Docker Deployments.
Please read this page in it’s entirety prior to attempting to set up a Docker stack.
Please note that Nucleus is still in Beta. Flaws in authentication, security and data loss are possible. We recommend using Nucleus for evaluation purposes and on prem only at this time. As we move towards release, we will update this notice. As per EULA, no cloud services to 3rd parties are allowed at this time.
Nucleus stack does not require anything special - it’s a simple CPU/RAM/disk workload.
Here’s what we recommend as the minimum baseline:
6+ reasonable cores
16+ GB of RAM
SSD type disk if any kind of load is expected
If you don’t know how much disk space to allocate, start with 50 Gb and observe usage, adding disk space as required
In reality, of course, resource usage will highly depend on load.
Ultimately, we recommend monitoring the installation, and adding resources as required.
Registering and Access¶
Omniverse Containers are available to members of Omniverse Early Access Program.
To register, please proceed to EAP Registration on developer.nvidia.com and follow the steps on the page to join the NVIDIA Developer Program and then submit your application to the Omniverse Early Access Program.
You will receive a notification email for joining the NVIDIA Developer Program and once your application to the EAP is approved, you will receive a notification email with further instructions.
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, and find that generally Ubuntu is the most user friendly and catered to. Other reasonable 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 be perfectly fine too.
Do not use your distribution’s default packages. They are usually outdated
and just plain wrong. In other words, don’t
apt install docker and just
expect it to work. Instead,
Docker Compose Stacks¶
Each compose “setup” has two parts to it -
.yml (which is the actual
compose file) and
.env (which contains most common settings for the
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 file. Please make sure to read comments located inside the .env file, and make sure you understand them completely. That’s where the bult of actual Nucleus setup documentation lives. Not doing so is going to ensure that you will arrive at a broken, crashlooping, deployment.
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
Errors on Startup¶
If you see errors in the log spew on startup of a stack, your first reaction should be giving it time. If you see crashing and restarting containers, you should do the same.
These errors happen because Docker launches everything at the same time, and some services in a stack depend on other services. So, for example, if Authentication Service happens to come up before it’s dependency - Discovery Service - it will fail, crash (and be happily restarted by Docker).
Only after you’ve given it enough time (a good 5 minutes), and your state is somewhat of a “stable crashloop” of some services, investigation is warranted.
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).
Verifying Nucleus is Up¶
When everything “settles in” and is running stable (containers not restarting), first thing you should do is direct your web browser to the IP address or hostname of a machine you have deployed it to, and attempt to log into the Navigator (Web UI). If you see that Web UI, you can be 99.9% certain that everything is perfectly fine. If you want to be 100% sure, using the Navigator, upload a >256KB file, and immediately download it.
Note to Workstation users: we have had confusions in the field with folks coming “off of” Workstation style Nucleus setups to these Docker setups, not realizing a few things:
Omniverse Navigator runs on port 80 with Docker (so no need to do
my.ip.he.re:8080when accessing it with a browser).
There is no System Monitor - which is purely a Workstation entity to manage your services. On a Docker Server, you got the full power of Docker to do the same thing.
All ports that will be opened by Nucleus are configurable (and suggested
defaults provided) in the
.env files. Don’t forget about
Client Assumptions when considering changing default
Please note that we have had at least one report from the field that re-assigning ports will not work. We have confirmed this issue and are looking into fixing it in our next release.