3.3. Docker Configuration¶
Ngenea Hub is run via a collection of services defined in a Docker Compose file,
this manages and controls all actions, settings and operations within Ngenea Hub using the ngeneahubctl CLI tool.
It uses the configuration defined in /etc/sysconfig/ngeneahub to populate the environment files
With every call using ngeneahubctl it will generate both the docker compose files and the required environment
files each time. This is to ensure that any changes between setting changes correctly update the service files and
environment variables.
3.3.1. Directory structure¶
After the first run of either ngeneahubctl start or ngeneahubctl build the following file structure is generated
within /etc/ngenea/docker. This directory contains all needed files for use with the hub and can be edited but to
ensure these edits are not overwritten by ngeneahubctl the setting OVERWRITE_COMPOSE must be set to False.
With overwrite disabled, the compose can be edited and executed with like any other docker compose stack.
Note
Using the docker compose outside of ngeneahubctl is only advised if you are a system administrator that requires
extra features not present in ngeneahubctl. Using docker configurations not generated by ngeneahubctl may
not be supported.
/var/lib/pixstor/ngenea/
├── docker-compose.yml
└── environment
├── backend.env
├── celery-beats.env
├── celery-dags.env
├── celery.env
├── celery-events.env
├── celery-monitor.env
├── celery-refresh.env
├── celery-results.env
├── db.env
├── frontend.env
├── grafana.env
├── rabbitmq.env
├── redis.env
├── refresh-daemon.env
├── task-daemon.env
└── websockets.env
All containers within the hub use an environment file per service that are populated using the sysconfig file for
ngeneahubctl. When any operation is run through ngeneahubctl it will repopulate these environment files unless
OVERWRITE_COMPOSE is disabled.
3.3.2. Operating the hub outside ngeneahubctl¶
With the docker components exposed, it can be interacted with the same as any docker compose file.
3.3.2.1. Example use case¶
Using the above compose, there may be requirements for the hosting system, one example could be limiting the memory consumption of the API. To limit its memory you can adjust the following section:
backend:
image: eurepo.arcapix.com/arcapix/ngeneahub:ngeneahub-dev
depends_on:
- db
env_file: /etc/ngenea/docker/environment/backend.env
volumes:
- ${BITBUCKET_CLONE_DIR:-/etc}/ngenea:/etc/ngenea
restart: on-failure
Could be edited into to limit the max memory to 512mb with a reserved usage of 256mb:
backend:
image: eurepo.arcapix.com/arcapix/ngeneahub:ngeneahub-1.0.0
deploy:
resources:
limits:
memory: 512M
reservations:
memory: 256M
depends_on:
- db
env_file: /etc/ngenea/docker/environment/backend.env
volumes:
- ${BITBUCKET_CLONE_DIR:-/etc}/ngenea:/etc/ngenea
restart: on-failure
After changing this container, you can interact with it using the following:
3.3.2.2. Start up the hub¶
docker compose --file /var/lib/pixstor/ngenea/docker-compose.yml up -d
3.3.2.3. Shut down the hub¶
docker compose --file /var/lib/pixstor/ngenea/docker-compose.yml down
3.3.2.4. Shell into the backend container within the hub¶
docker compose --file /var/lib/pixstor/ngenea/docker-compose.yml exec -it backend bash