One of our main offerings with DUST is the hosting of container images. The container page shows an overview of the projects resource quotas as well as a list of all current containers.

To create a container job press the "Create Container Job", here you can give the job a name, image, resources, and environment variables.

The most important one is the container image, this defines what the container job will contain and if anything will be automatically ran when starting the container.

busybox for example is a basic image which contains a very minimal unix install. By creating a container with the busybox image, you automatically go to the container settings page. Where you can change more settings before applying them, applying meanins essentialy saving the settings and running the container.

If you want to try out running a busybox container you need to give the container a command to run, as otherwise it would immediately exit after running. For example using sleep: ["sleep", "1000000"].

Nomad is essentially your container manager and is found in the top right corner of DUST (or here). There, you will find a list of your projects' jobs (containers) and some brief information about them. After selecting a job, you can view detailed information about it, notably its logs (stdout/stderr) at the bottom of the page.

If you want an interactive shell into your running container, find the Exec button in the top right corner. After selecting the app task of main, you can enter a command to run, for example /bin/bash to give you an interactive Bash shell (or /bin/sh if your container is minimal enough). Remember that the job must be running for you to be able to do this!

DUST can use Docker images from any registry. By default it will use Dockerhub if you don't specify anything else. If the images available on Dockerhub aren't enough for someone of your caliber (likely), you are free (encouraged) to create your own. This is possible to automate on (not just) LUDD's very own GitLab instance through a Dockerfile and a .gitlab-ci.yml in your repository. The Dockerfile contains instructions on how to compile your project, and the .gitlab-ci.yml will follow those instructions on every commit to create a pipeline that (hopefully) compiles your project into a usable Docker image.

When it comes to creating the Dockerfile, consider looking up a template for your project's language and adapting it to suit your needs. Also, consider using a "two-stage process" to significantly cut down on the size of the image if your project benefits from it. Essentially, compile your program in stage 1, copy over and then run the compiled binary in stage 2. This excludes all of the downloaded dependencies from the produced Docker image. Look it up.

When it comes to the .gitlab-ci.yml, GitLab's official Docker CI template should be enough for most projects. It simply builds the Docker image from your Dockerfile and pushes it to the registry.

If the pipeline succeeds, your image should be uploaded to the registry. If your project is hosted on LUDD's GitLab, you can reference your image in your DUST project's container parameters with registry.git.ludd.ltu.se/[USERNAME]/[REPOSITORY]:latest (you can, of course, choose something other than latest).

Environment variables are a common and convenient way to pass configuration to your container. Keep in mind that it is generally considered bad practice to store secrets as environment variables for serious production use (the bottom example image is from a project that is not in serious production use!).

Environment variables for your container are managed in DUST through Templates. If you did not set any environment variables when creating your container, you will need to create the template yourself. The default destination is /secrets/.env. Remember to check the Env checkbox to load the template as environment variables. The content itself should be standard KEY=VALUE pairs, with one per line.