Thanks, Chris! I’ve incorporated these ideas into the Confluence page. I’ll look into getting you edit permissions - what is your username there?
> On Dec 18, 2021, at 13:35, Chris Sampson <chris.samp...@naimuri.com.INVALID> > wrote: > > Kevin, > > Good idea to write up a list of ideas - unfortunately I don't appear to > have permission to edit the page, but a few other ideas are: > > - Provide an "alpine" based image (could be the > "openjdk:<version>-alpine" image used as a base) to reduce image size and > O/S footprint of the container > - Change the Docker start scripts to allow for all nifi.properties (and > other config file properties) to be set by Environment Variables - this > could be a case of 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. - this would make the convenience image all the > more convenient for people and follow suit with some other applications > using Docker wrappers > - Docker-focussed default config, for example logback.xml that directs > output to STDOUT/STDERR by default, possibly in JSON format, allowing > easier out-of-the-box use of the logs in Docker-based environments that > already process Docker log output > - Allow for the nifi.properties/config file changes during start.sh to > be skipped (some people inject the config files into their containers but > want them to be read-only, which then means the start.sh script fails > because the files can't be edited) > - Change the default config file locations within the Docker images, > e.g. the flow.xml.gz and other system generated config that should be > persisted through container restart would be better in a different folder > to things like nifi.properties, then the directory can be externalised as a > Volume (without running into read-only/mutability issues like the start.sh > point above) > - 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 (not sure how much of an issue this still is after some > recent changes) > > Please feel free to add any/all of the above to the Confluence page that > you think would be worthwhile to add to the pile for consideration. > > > --- > *Chris Sampson* > IT Consultant > chris.samp...@naimuri.com > > > On Fri, 17 Dec 2021 at 18:01, Kevin Doran <kdo...@apache.org> wrote: > >> Hi Chris, >> >> I like this idea and have been thinking of a number of other improvements >> we could make for container images of Apache NiFi, including (I think >> discussed on another thread) consolidating Dockerfiles for dockerhub / >> dockermaven, as the only significant difference is where the nifi assembly >> archive comes from, arm64 images that run native on ARM platforms, >> including newer M1 Macs (requires some minor changes to NiFi source itself >> to compile). >> >> I’ve started a Wiki page [1] to collect ideas, and once we reach consensus >> on the improvements we’d like to make and possible approaches, we can turn >> these into Jiras. >> >> [1] >> https://cwiki.apache.org/confluence/display/NIFI/NiFi+Docker+Container+Improvements >> >> Thanks! >> Kevin >> >>> On Nov 26, 2021, at 07:46, Chris Sampson <chris.samp...@naimuri.com.INVALID> >> wrote: >>> >>> I'm not sure whether I've seen this discussed previously, but I thought >> it >>> worth asking whether we could/should publish a JDK 11 based version of >> the >>> apache/nifi Docker Image to Docker Hub as part of the release process in >>> future? >>> >>> I realise NiFi 1.x is/will remain based on JDK 8 but with all the work >> gone >>> into enabling JDK 11 compilation and deployment, along with the planned >>> move to JDK 11 in the future for NiFi 2.x, it would seem sensible to >> start >>> making it easier for people to move towards using JDK 11 now that it's >>> available. >>> >>> The Dockerfiles used to build NiFi (I've not looked at Toolkit, MiNiFi or >>> Registry) can be given a build ARG to use different base images/versions, >>> so it should be relatively straightforward to do this and maybe publish >> the >>> Image to Docker Hub as *apache/nifi:<version>-jdk11*? >>> >>> Users can, of course, download the NiFi source to build this image >>> themselves, but to make it easier for the community it would seem >> sensible >>> to consider the additional release artifact. This avoids lots of people >>> having to pull all of the code (it's not a small repo) or build the >> image, >>> which can take a long time, etc. >>> >>> >>> --- >>> *Chris Sampson* >>> IT Consultant >>> chris.samp...@naimuri.com >> >>
