Ideas:

  • Offer Image Variants
    • Java 17 image variant, e.g, apache/nifi:latest-java17
    • A smaller base image (with an easy way to add extensions to it)
  • Consolidate dockerhub and dockermaven Dockerfiles
    • Currently, the only significant difference is the source the nifi-assembly archive
  • OpenShift compatibility without requiring custom Security Context Constraints (SCCs)
  • Better support for configuring properties via container environment variables, without having to explicitly map them in the Docker startup script
    • Alternatively, using a common Env Var prefix to and iterating through them within the script, e.g. anything that is NIFI_* is assumed to be a nifi.properties entry, etc.
    • Eventually, perhaps NiFi itself could support env var overrides for properties, similar to the way Spring Boot 2 support externalized configuration with relaxed binding, so that this is not just a feature of containerized NiFi.
  • Better support for configuration via mounted volumes
    • For example, allow for the config file changes during start.sh to be skipped, as users mounting a config directory are providing the exact configuration they want to be used
    • Change the default file locations within the Docker images to distinguish between files NiFi writes and files that could be user-provided, e.g. the flow.xml.gz and other system generated config would be better in a different folder to things like nifi.properties, then the config directory can be externalised as a docker volume (without running into permissions/read-only/mutability issues)
  • Docker-focussed default config, for example logback.xml that directs output to STDOUT/STDERR by default, optionally in JSON format, allowing easier out-of-the-box use of the logs in Docker-based environments that already process Docker log output
  • Make it easier for Docker-based instances to join an existing cluster
    • This might be a case of relocating some of the files to make better use of ephemeral vs. persistent directories/Volumes and/or having a configurable mechanism that allows for the cluster config files to be deleted during startup if the instance expects to join a cluster but cannot because it is unable to overwrite existing files with those being offered by the cluster
  • Process improvements:
    • Automation, perhaps a GitHub Action that can be manually invoked by maintainers / release managers to publish new dockerhub images (The current process is documented at Docker Hub Image Publishing)
    • Offer some sort of signing or image verification
    • Periodically scan images for vulnerabilities / CVEs
      • NOTE: Some vulnerability scanning tools will require unpacked .nars and .wars to fully identify Java and Javascript dependencies
  • Easier configuration for proxied networking
  • No labels