Re: NiFi docker container fails to start on VMWare host
It was because of this: https://stackoverflow.com/questions/72841549/container-fails-to-start-insufficient-memory-for-the-java-runtime-environment-t#:~:text=Possible%20reasons%3A%20The%20system%20is,physical%20memory%20or%20swap%20space The customer had installed docker 18.xx, and we have not had to specify the version before and this new NiFi 1.19.X version was put out with minimal testing on our servers (i.e. didn't check with older docker versions. Upgrading to docker 20.10.13 resolved the issue. Thanks! On Mon, Jan 30, 2023 at 11:52 PM Chris Sampson wrote: > Have you tried an earlier version of nifi in the same environment? > > Does the image for nifi 1.18.0 boot successfully, for example? > > The reason I'd check this is mainly that the apache/nifi convenience > docker image switched from java 8 to java 11 for nifi version 1.19.0+. I > think the way in which memory is allocated to the jvm within a docker > container changed between java 8 and 11, so it might be worth checking to > see whether an earlier version works. > > Is the VMWare environment 64 or 32bit as I think that can also affect how > the jvm allocates memory (based on a brief search for parts of your error > message - https://www.baeldung.com/jvm-compressed-oops)? > > > On Tue, 31 Jan 2023, 03:36 Cannon Palms, wrote: > >> Check the resources on the host. >> >> By default, the docker container will have all of the available memory on >> the host machine available to it. If you'd like to ensure that this >> available memory is at least X, you can use a memory reservation in your >> docker compose file: >> >> ``` >> ... >> mem_reservation: 4Gi >> ``` >> >> etc. >> >> You are correct, though, that this is not a Nifi-specific question. You >> may have more success on a docker-specific forum or platform. >> >> Best, >> Cannon >> >> >> On Mon, Jan 30, 2023, 8:27 PM David Early via users < >> users@nifi.apache.org> wrote: >> >>> Hi all, >>> >>> We are deploying several NiFi containers as part of a service for a >>> customer and we have run into an issue we have not seen before. >>> >>> I THINK the problem may be more of a problem with Java/Docker/VMWare >>> than NiFi per se, but I wanted to ask here in case someone has seen this >>> before. >>> >>> We recently upgraded a small system in Azure to 1.19.1 using the >>> "official" docker container. This worked just fine. The host was an Azure >>> VM running an older CentOS 7 image. There were no issues. >>> >>> For the current install, we used the same Docker image but it is on prem >>> with a customer who is using VMWare to create the hosts we are running on. >>> The hosts (3 of them) are 8 core/64G. >>> >>> The error we are getting is: >>> >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/bootstrap.conf Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/bootstrap.conf Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /home/nifi/.nifi-cli.nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /home/nifi/.nifi-cli.nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /home/nifi/.nifi-cli.nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /home/nifi/.nifi-cli.nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /home/nifi/.nifi-cli.nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file /opt/nifi/nifi-current/conf/nifi.properties Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file
Re: NiFi docker container fails to start on VMWare host
Have you tried an earlier version of nifi in the same environment? Does the image for nifi 1.18.0 boot successfully, for example? The reason I'd check this is mainly that the apache/nifi convenience docker image switched from java 8 to java 11 for nifi version 1.19.0+. I think the way in which memory is allocated to the jvm within a docker container changed between java 8 and 11, so it might be worth checking to see whether an earlier version works. Is the VMWare environment 64 or 32bit as I think that can also affect how the jvm allocates memory (based on a brief search for parts of your error message - https://www.baeldung.com/jvm-compressed-oops)? On Tue, 31 Jan 2023, 03:36 Cannon Palms, wrote: > Check the resources on the host. > > By default, the docker container will have all of the available memory on > the host machine available to it. If you'd like to ensure that this > available memory is at least X, you can use a memory reservation in your > docker compose file: > > ``` > ... > mem_reservation: 4Gi > ``` > > etc. > > You are correct, though, that this is not a Nifi-specific question. You > may have more success on a docker-specific forum or platform. > > Best, > Cannon > > > On Mon, Jan 30, 2023, 8:27 PM David Early via users > wrote: > >> Hi all, >> >> We are deploying several NiFi containers as part of a service for a >> customer and we have run into an issue we have not seen before. >> >> I THINK the problem may be more of a problem with Java/Docker/VMWare than >> NiFi per se, but I wanted to ask here in case someone has seen this before. >> >> We recently upgraded a small system in Azure to 1.19.1 using the >> "official" docker container. This worked just fine. The host was an Azure >> VM running an older CentOS 7 image. There were no issues. >> >> For the current install, we used the same Docker image but it is on prem >> with a customer who is using VMWare to create the hosts we are running on. >> The hosts (3 of them) are 8 core/64G. >> >> The error we are getting is: >> >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/bootstrap.conf >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/bootstrap.conf >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /home/nifi/.nifi-cli.nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /home/nifi/.nifi-cli.nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /home/nifi/.nifi-cli.nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /home/nifi/.nifi-cli.nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /home/nifi/.nifi-cli.nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >>> file /opt/nifi/nifi-current/conf/nifi.properties >>> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]:
Re: NiFi docker container fails to start on VMWare host
Check the resources on the host. By default, the docker container will have all of the available memory on the host machine available to it. If you'd like to ensure that this available memory is at least X, you can use a memory reservation in your docker compose file: ``` ... mem_reservation: 4Gi ``` etc. You are correct, though, that this is not a Nifi-specific question. You may have more success on a docker-specific forum or platform. Best, Cannon On Mon, Jan 30, 2023, 8:27 PM David Early via users wrote: > Hi all, > > We are deploying several NiFi containers as part of a service for a > customer and we have run into an issue we have not seen before. > > I THINK the problem may be more of a problem with Java/Docker/VMWare than > NiFi per se, but I wanted to ask here in case someone has seen this before. > > We recently upgraded a small system in Azure to 1.19.1 using the > "official" docker container. This worked just fine. The host was an Azure > VM running an older CentOS 7 image. There were no issues. > > For the current install, we used the same Docker image but it is on prem > with a customer who is using VMWare to create the hosts we are running on. > The hosts (3 of them) are 8 core/64G. > > The error we are getting is: > > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file >> /opt/nifi/nifi-current/conf/bootstrap.conf >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/bootstrap.conf >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /home/nifi/.nifi-cli.nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /home/nifi/.nifi-cli.nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /home/nifi/.nifi-cli.nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /home/nifi/.nifi-cli.nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /home/nifi/.nifi-cli.nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file /opt/nifi/nifi-current/conf/nifi.properties >> Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target >> file
NiFi docker container fails to start on VMWare host
Hi all, We are deploying several NiFi containers as part of a service for a customer and we have run into an issue we have not seen before. I THINK the problem may be more of a problem with Java/Docker/VMWare than NiFi per se, but I wanted to ask here in case someone has seen this before. We recently upgraded a small system in Azure to 1.19.1 using the "official" docker container. This worked just fine. The host was an Azure VM running an older CentOS 7 image. There were no issues. For the current install, we used the same Docker image but it is on prem with a customer who is using VMWare to create the hosts we are running on. The hosts (3 of them) are 8 core/64G. The error we are getting is: Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/bootstrap.conf > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/bootstrap.conf > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /home/nifi/.nifi-cli.nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /home/nifi/.nifi-cli.nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /home/nifi/.nifi-cli.nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /home/nifi/.nifi-cli.nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /home/nifi/.nifi-cli.nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: replacing target file > /opt/nifi/nifi-current/conf/nifi.properties > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: Java home: > /opt/java/openjdk > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: NiFi home: > /opt/nifi/nifi-current > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: Bootstrap Config > File: /opt/nifi/nifi-current/conf/bootstrap.conf > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: > Jan 27 16:32:36 dstsc01 cust-sts|2181237bc92f[1788]: > [0.003s][warning][os,thread] Failed to start thread "GC Thread#0" - > pthread_create
RE: how to setup nifi.content.repository.archive.max.retention.period in a Nifi docker image ?
Hi Breno.
Thanks for your feedback.
I think I will override the nifi image by adding my own entrypoint ( which will
call the nifi start.sh at the end)
In my entrypoint, I will call another script that will mimic the nifi
script.sh. In this new script , I will add something like :
prop_replace 'nifi.content.repository.archive.max.retention.period'
"${NIFI_CONTENT_REPOSITORY_ARCHIVE_MAX_RETENTION_PERIOD:-'12 hours"}"
Regards
From: Breno Cesar
Sent: Tuesday, February 22, 2022 3:07 PM
To: users@nifi.apache.org
Subject: Re: how to setup nifi.content.repository.archive.max.retention.period
in a Nifi docker image ?
CAUTION: External Email : Be wary of clicking links or if this claims to be
internal.
Hi Nicolas,
As far as i know, there is no variable for this config.The documentation has a
lack about this topic and does not explain about it.
Doing some "googling", i found that someone already maped this variables.
https://github.com/dprophet/nifi/blob/master/nifi-docker/dockerhub/CONFIGURATION.md<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdprophet%2Fnifi%2Fblob%2Fmaster%2Fnifi-docker%2Fdockerhub%2FCONFIGURATION.md=04%7C01%7Cnbelot%40infovista.com%7C9d7b2b54bc1c49e25d8308d9f60ca55f%7Cc8d853de982e440492ffb4189dc94e37%7C0%7C0%7C637811356471583447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=IRvhcPqQz2gYCRz5bRiVQCp%2F7JhRz5I9GJY6m6iSsXg%3D=0>
Assuming this configuration you need is a tunnig, and will not be done
frequenly, as far as I know, you can change it in the default nifi files on a
clean docker image, and export it for later use.
Breno
Em ter., 22 de fev. de 2022 às 10:01, Nicolas Belot
mailto:nbe...@infovista.com>> escreveu:
Hello everyone.
I use a docker image of nifi and I need to tune
nifi.content.repository.archive.max.retention.period.
Is there a way to simply set it up through an env variable ?
I read the start.sh script but
nifi.content.repository.archive.max.retention.period does not appear in this
script.
Regards
N.
Re: how to setup nifi.content.repository.archive.max.retention.period in a Nifi docker image ?
Breno, While we're on this topic, what's best practice for changing something like "the default nifi files on a clean docker image, ..."? Use sed or awk from a RUN command? (This is really a Docker question, but you raised it. Anything you suggest would be helpful.) Russ On 2/22/22 07:07, Breno Cesar wrote: Hi Nicolas, As far as i know, there is no variable for this config.The documentation has a lack about this topic and does not explain about it. Doing some "googling", i found that someone already maped this variables. https://github.com/dprophet/nifi/blob/master/nifi-docker/dockerhub/CONFIGURATION.md Assuming this configuration you need is a tunnig, and will not be done frequenly, as far as I know, you can change it in the default nifi files on a clean docker image, and export it for later use. *Breno * Em ter., 22 de fev. de 2022 às 10:01, Nicolas Belot escreveu: Hello everyone. I use a docker image of nifi and I need to tune nifi.content.repository.archive.max.retention.period. Is there a way to simply set it up through an env variable ? I read the start.sh script but nifi.content.repository.archive.max.retention.period does not appear in this script. Regards N.
Re: how to setup nifi.content.repository.archive.max.retention.period in a Nifi docker image ?
Hi Nicolas, As far as i know, there is no variable for this config.The documentation has a lack about this topic and does not explain about it. Doing some "googling", i found that someone already maped this variables. https://github.com/dprophet/nifi/blob/master/nifi-docker/dockerhub/CONFIGURATION.md Assuming this configuration you need is a tunnig, and will not be done frequenly, as far as I know, you can change it in the default nifi files on a clean docker image, and export it for later use. *Breno * Em ter., 22 de fev. de 2022 às 10:01, Nicolas Belot escreveu: > Hello everyone. > > > > I use a docker image of nifi and I need to tune > nifi.content.repository.archive.max.retention.period. > > > > Is there a way to simply set it up through an env variable ? > > > > I read the start.sh script but > nifi.content.repository.archive.max.retention.period does not appear in > this script. > > > > Regards > > > > N. > > >
how to setup nifi.content.repository.archive.max.retention.period in a Nifi docker image ?
Hello everyone. I use a docker image of nifi and I need to tune nifi.content.repository.archive.max.retention.period. Is there a way to simply set it up through an env variable ? I read the start.sh script but nifi.content.repository.archive.max.retention.period does not appear in this script. Regards N.
Re: Recommended NiFi Docker volume mappings?
@Juan, Thanks for the tip, probably not going to mount logs as using
Elastic filebeat to tail any live docker container logs - assuming that
nifi docker is configured to use the standard "docker log" API.
I've also found from experience that it is safer to move the default root
Docker volume location from /var/lib to a larger drive as it can blow up
and fill up root very quickly depending on how the internal docker app
behaves or writes logs.
On Thu, 25 Oct 2018 at 14:15, Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:
> I suggest to be careful when mount log directory. In one day fills some
> Gigabytes. If you want to mount logs, adjust the logging.
>
> On Thu, 25 Oct 2018 at 10:07 Stephen Greszczyszyn
> wrote:
>
>>
>>
>> On Thu, 25 Oct 2018 at 12:50, Peter Wilcsinszky <
>> peterwilcsins...@gmail.com> wrote:
>>
>> But even with 1.8 I'll need to declare the host mount directory somehow
>> via docker-compose, as how will the built docker image on dockerhub know
>> where to locally mount the internal $(NIFI_HOME) volumes as described below?
>>
>> VOLUME ${NIFI_LOG_DIR} \
>>>>${NIFI_HOME}/conf \
>>>>${NIFI_HOME}/database_repository \
>>>>${NIFI_HOME}/flowfile_repository \
>>>>${NIFI_HOME}/content_repository \
>>>>${NIFI_HOME}/provenance_repository \
>>>>${NIFI_HOME}/state
>>>>
>>>
>>> Yes you should specify volumes explicitly if you use 1.7.1, but also you
>>> should specify an extra separate volume to use for your incoming SFTP data.
>>>
>>>
Re: Recommended NiFi Docker volume mappings?
If you want them to be on your host machine then you have to declare those
yes. By default docker will create directories for those volumes on the
docker host under /var/lib/docker/volumes/. Note: the docker host is
typically running in a VM, at least this is the case on Docker for Mac.
On Thu, Oct 25, 2018 at 3:07 PM Stephen Greszczyszyn
wrote:
>
>
> On Thu, 25 Oct 2018 at 12:50, Peter Wilcsinszky <
> peterwilcsins...@gmail.com> wrote:
>
> But even with 1.8 I'll need to declare the host mount directory somehow
> via docker-compose, as how will the built docker image on dockerhub know
> where to locally mount the internal $(NIFI_HOME) volumes as described below?
>
> VOLUME ${NIFI_LOG_DIR} \
>>>${NIFI_HOME}/conf \
>>>${NIFI_HOME}/database_repository \
>>>${NIFI_HOME}/flowfile_repository \
>>>${NIFI_HOME}/content_repository \
>>>${NIFI_HOME}/provenance_repository \
>>>${NIFI_HOME}/state
>>>
>>
>> Yes you should specify volumes explicitly if you use 1.7.1, but also you
>> should specify an extra separate volume to use for your incoming SFTP data.
>>
>>
Re: Recommended NiFi Docker volume mappings?
I suggest to be careful when mount log directory. In one day fills some
Gigabytes. If you want to mount logs, adjust the logging.
On Thu, 25 Oct 2018 at 10:07 Stephen Greszczyszyn
wrote:
>
>
> On Thu, 25 Oct 2018 at 12:50, Peter Wilcsinszky <
> peterwilcsins...@gmail.com> wrote:
>
> But even with 1.8 I'll need to declare the host mount directory somehow
> via docker-compose, as how will the built docker image on dockerhub know
> where to locally mount the internal $(NIFI_HOME) volumes as described below?
>
> VOLUME ${NIFI_LOG_DIR} \
>>>${NIFI_HOME}/conf \
>>>${NIFI_HOME}/database_repository \
>>>${NIFI_HOME}/flowfile_repository \
>>>${NIFI_HOME}/content_repository \
>>>${NIFI_HOME}/provenance_repository \
>>>${NIFI_HOME}/state
>>>
>>
>> Yes you should specify volumes explicitly if you use 1.7.1, but also you
>> should specify an extra separate volume to use for your incoming SFTP data.
>>
>>
Re: Recommended NiFi Docker volume mappings?
On Thu, 25 Oct 2018 at 12:50, Peter Wilcsinszky
wrote:
But even with 1.8 I'll need to declare the host mount directory somehow via
docker-compose, as how will the built docker image on dockerhub know where
to locally mount the internal $(NIFI_HOME) volumes as described below?
VOLUME ${NIFI_LOG_DIR} \
>>${NIFI_HOME}/conf \
>>${NIFI_HOME}/database_repository \
>>${NIFI_HOME}/flowfile_repository \
>>${NIFI_HOME}/content_repository \
>>${NIFI_HOME}/provenance_repository \
>>${NIFI_HOME}/state
>>
>
> Yes you should specify volumes explicitly if you use 1.7.1, but also you
> should specify an extra separate volume to use for your incoming SFTP data.
>
>
Re: Recommended NiFi Docker volume mappings?
On Thu, Oct 25, 2018 at 1:01 PM Stephen Greszczyszyn
wrote:
> Thanks for the reply Peter,
>
> You are right, last night when I tried mapping just /opt/nifi from NiFi
> version 1.7.1 the container wasn't happy starting up and I couldn't figure
> out what folders were needed to store state and manage any configurations.
>
> Just to be clear, should I be mapping the following volumes to local
> folders that have read/write access for host user ID 1000 (or a Linux group
> that user 1000 is a member of) for the internal docker user nifi (UID 1000)
> to be able to access? I guess there is no way to change the UID of docker
> user nifi without doing a custom docker build. For security/LDAP, I'm
> assuming I can just pass the environment variables through as documented on
> the README.md?
>
> VOLUME ${NIFI_LOG_DIR} \
>${NIFI_HOME}/conf \
>${NIFI_HOME}/database_repository \
>${NIFI_HOME}/flowfile_repository \
>${NIFI_HOME}/content_repository \
>${NIFI_HOME}/provenance_repository \
>${NIFI_HOME}/state
>
Yes you should specify volumes explicitly if you use 1.7.1, but also you
should specify an extra separate volume to use for your incoming SFTP data.
>
> I'm trying to automate the docker config using docker-compose via ansible,
> so normally I use a framework like this:
>
> - name: Create local host nifi state directories in /data/nifi/
> file:
> path: "{{ item }}"
> state: directory
> owner: 1000
> group: 1000
> mode: 0775
> with_items:
> - /data/nifi
> - /data/nifi/conf
> - /data/nifi/state
> - /data/nifi/database_repository
> - /data/nifi/flowfile_repository
> - /data/nifi/content_repository
> - /data/nifi/provenance_repository
>
> - name: Build NiFi Docker Image
> docker_service:
> project_name: nifi
> definition:
> version: '2'
> services:
> nifi:
> image: apache/nifi:{{ nifi_version }}
> container_name: nifi
> restart: on-failure
> # environment:
>
> volumes:
> # take uid/gid lists from host to give same user/group
> permissions mapping as host
> #- /etc/passwd:/etc/passwd
> #- /etc/group:/etc/group
>
> # Give NiFi access to read/write in /data
> - /data:/data
>
> # Expose NiFi config and state directories
> - /data/nifi/conf:/opt/nifi/conf
> - /data/nifi/state:/data/nifi/state
> -
> /data/nifi/database_repository:/opt/nifi/database_repository
> -
> /data/nifi/flowfile_repository:/opt/nifi/flowfile_repository
> -
> /data/nifi/content_repository:/opt/nifi/content_repository
> -
> /data/nifi/provenance_repository:/opt/nifi/provenance_repository
>
> ports:
> - 8080:8080
> - 8443:8443
> - 1:1
>
> On Thu, 25 Oct 2018 at 11:02, Peter Wilcsinszky <
> peterwilcsins...@gmail.com> wrote:
>
>> Hi Stephen,
>>
>> I don't recommend mounting /opt/nifi directly as it will copy all the
>> NiFi binaries over to the volume as well, which is unnecessary I beleive.
>> The latest dockerfile that will be used to build the docker image for the
>> upcoming release already declares volumes that I recommend to leverage:
>>
>> https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L73
>>
>> However if you have special needs you can always tweak the dockerfile and
>> build you own image from it.
>>
>> On Wed, Oct 24, 2018 at 10:04 PM Stephen Greszczyszyn
>> wrote:
>>
>>> Hi there,
>>>
>>> I'm trying to get a working configuration for the official vanilla NiFi
>>> docker image where it can read existing SFTP incoming data as well as allow
>>> me to pass in any necessary configuration files.
>>>
>>> The problem seems to be that by default the docker container picks up
>>> userID 1000 to run the nifi process, which is OK since I mapped my
>>> /etc/passwd and /etc/group volumes and I'm managing the directory
>>> read/write access through my underlying OS (Ubuntu 18.04).
>>>
>>> Where I am having problems is mapping the docker NiFi /opt/nifi
>>> directory to a local directory, despite the permissions looking OK. I've
>>> even set my local /data/nifi directory to chmod 777, but the docker
>>> container fails to start.
>>>
>>> Any suggestions on how to resolve this? Also any best practices for
>>> mapping the NiFi internal docker volumes to the local OS would be
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> Stephen
>>>
>>
Re: Recommended NiFi Docker volume mappings?
Thanks for the reply Peter,
You are right, last night when I tried mapping just /opt/nifi from NiFi
version 1.7.1 the container wasn't happy starting up and I couldn't figure
out what folders were needed to store state and manage any configurations.
Just to be clear, should I be mapping the following volumes to local
folders that have read/write access for host user ID 1000 (or a Linux group
that user 1000 is a member of) for the internal docker user nifi (UID 1000)
to be able to access? I guess there is no way to change the UID of docker
user nifi without doing a custom docker build. For security/LDAP, I'm
assuming I can just pass the environment variables through as documented on
the README.md?
VOLUME ${NIFI_LOG_DIR} \
${NIFI_HOME}/conf \
${NIFI_HOME}/database_repository \
${NIFI_HOME}/flowfile_repository \
${NIFI_HOME}/content_repository \
${NIFI_HOME}/provenance_repository \
${NIFI_HOME}/state
I'm trying to automate the docker config using docker-compose via ansible,
so normally I use a framework like this:
- name: Create local host nifi state directories in /data/nifi/
file:
path: "{{ item }}"
state: directory
owner: 1000
group: 1000
mode: 0775
with_items:
- /data/nifi
- /data/nifi/conf
- /data/nifi/state
- /data/nifi/database_repository
- /data/nifi/flowfile_repository
- /data/nifi/content_repository
- /data/nifi/provenance_repository
- name: Build NiFi Docker Image
docker_service:
project_name: nifi
definition:
version: '2'
services:
nifi:
image: apache/nifi:{{ nifi_version }}
container_name: nifi
restart: on-failure
# environment:
volumes:
# take uid/gid lists from host to give same user/group
permissions mapping as host
#- /etc/passwd:/etc/passwd
#- /etc/group:/etc/group
# Give NiFi access to read/write in /data
- /data:/data
# Expose NiFi config and state directories
- /data/nifi/conf:/opt/nifi/conf
- /data/nifi/state:/data/nifi/state
-
/data/nifi/database_repository:/opt/nifi/database_repository
-
/data/nifi/flowfile_repository:/opt/nifi/flowfile_repository
- /data/nifi/content_repository:/opt/nifi/content_repository
-
/data/nifi/provenance_repository:/opt/nifi/provenance_repository
ports:
- 8080:8080
- 8443:8443
- 1:1
On Thu, 25 Oct 2018 at 11:02, Peter Wilcsinszky
wrote:
> Hi Stephen,
>
> I don't recommend mounting /opt/nifi directly as it will copy all the NiFi
> binaries over to the volume as well, which is unnecessary I beleive. The
> latest dockerfile that will be used to build the docker image for the
> upcoming release already declares volumes that I recommend to leverage:
>
> https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L73
>
> However if you have special needs you can always tweak the dockerfile and
> build you own image from it.
>
> On Wed, Oct 24, 2018 at 10:04 PM Stephen Greszczyszyn
> wrote:
>
>> Hi there,
>>
>> I'm trying to get a working configuration for the official vanilla NiFi
>> docker image where it can read existing SFTP incoming data as well as allow
>> me to pass in any necessary configuration files.
>>
>> The problem seems to be that by default the docker container picks up
>> userID 1000 to run the nifi process, which is OK since I mapped my
>> /etc/passwd and /etc/group volumes and I'm managing the directory
>> read/write access through my underlying OS (Ubuntu 18.04).
>>
>> Where I am having problems is mapping the docker NiFi /opt/nifi directory
>> to a local directory, despite the permissions looking OK. I've even set my
>> local /data/nifi directory to chmod 777, but the docker container fails to
>> start.
>>
>> Any suggestions on how to resolve this? Also any best practices for
>> mapping the NiFi internal docker volumes to the local OS would be
>> appreciated.
>>
>> Thanks,
>>
>> Stephen
>>
>
Re: Recommended NiFi Docker volume mappings?
Hi Stephen, I don't recommend mounting /opt/nifi directly as it will copy all the NiFi binaries over to the volume as well, which is unnecessary I beleive. The latest dockerfile that will be used to build the docker image for the upcoming release already declares volumes that I recommend to leverage: https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L73 However if you have special needs you can always tweak the dockerfile and build you own image from it. On Wed, Oct 24, 2018 at 10:04 PM Stephen Greszczyszyn wrote: > Hi there, > > I'm trying to get a working configuration for the official vanilla NiFi > docker image where it can read existing SFTP incoming data as well as allow > me to pass in any necessary configuration files. > > The problem seems to be that by default the docker container picks up > userID 1000 to run the nifi process, which is OK since I mapped my > /etc/passwd and /etc/group volumes and I'm managing the directory > read/write access through my underlying OS (Ubuntu 18.04). > > Where I am having problems is mapping the docker NiFi /opt/nifi directory > to a local directory, despite the permissions looking OK. I've even set my > local /data/nifi directory to chmod 777, but the docker container fails to > start. > > Any suggestions on how to resolve this? Also any best practices for > mapping the NiFi internal docker volumes to the local OS would be > appreciated. > > Thanks, > > Stephen >
Recommended NiFi Docker volume mappings?
Hi there, I'm trying to get a working configuration for the official vanilla NiFi docker image where it can read existing SFTP incoming data as well as allow me to pass in any necessary configuration files. The problem seems to be that by default the docker container picks up userID 1000 to run the nifi process, which is OK since I mapped my /etc/passwd and /etc/group volumes and I'm managing the directory read/write access through my underlying OS (Ubuntu 18.04). Where I am having problems is mapping the docker NiFi /opt/nifi directory to a local directory, despite the permissions looking OK. I've even set my local /data/nifi directory to chmod 777, but the docker container fails to start. Any suggestions on how to resolve this? Also any best practices for mapping the NiFi internal docker volumes to the local OS would be appreciated. Thanks, Stephen
Re: Has anyone ever gotten an ATO involving the official NiFi docker image?
It's an Authority to Operate certification. Decent enough summary: http://smallbusiness.chron.com/authorization-operate-ato-81858.html I'm trying to find out if anyone has gotten an ATO involving the official NiFi docker image. On Sat, Jul 14, 2018 at 11:29 AM Otto Fowler wrote: > What’s an ATO? Can you elaborate? I may have someone off list I can ask, > but I don’t know what an ATO is. > > > > On July 13, 2018 at 10:37:31, Mike Thomsen (mikerthom...@gmail.com) wrote: > > Just curious to know if anyone has gotten an ATO before involving the NiFi > docker image that's officially produced by the team, instead of rolling > their own. Not NiFi as a product, but the distribution of it under > apache/nifi that's publicly shared on Docker Hub. > > Thanks, > > Mike > >
Re: Has anyone ever gotten an ATO involving the official NiFi docker image?
What’s an ATO? Can you elaborate? I may have someone off list I can ask, but I don’t know what an ATO is. On July 13, 2018 at 10:37:31, Mike Thomsen (mikerthom...@gmail.com) wrote: Just curious to know if anyone has gotten an ATO before involving the NiFi docker image that's officially produced by the team, instead of rolling their own. Not NiFi as a product, but the distribution of it under apache/nifi that's publicly shared on Docker Hub. Thanks, Mike
Has anyone ever gotten an ATO involving the official NiFi docker image?
Just curious to know if anyone has gotten an ATO before involving the NiFi docker image that's officially produced by the team, instead of rolling their own. Not NiFi as a product, but the distribution of it under apache/nifi that's publicly shared on Docker Hub. Thanks, Mike
Re: NiFi Docker
Sounds great. Will keep an eye out for it. Thanks! On Tue, Aug 1, 2017 at 10:50 AM, ddewaele <ddewa...@gmail.com> wrote: > Great also have some ideas about this. I'll log a JIRA and elaborate > on > those. > > We can then see on how to move this forward. (willing to do a pull request > for this). > > > > -- > View this message in context: http://apache-nifi-users-list. > 2361937.n4.nabble.com/NiFi-Docker-tp2562p2576.html > Sent from the Apache NiFi Users List mailing list archive at Nabble.com. >
Re: NiFi Docker
Great also have some ideas about this. I'll log a JIRA and elaborate on those. We can then see on how to move this forward. (willing to do a pull request for this). -- View this message in context: http://apache-nifi-users-list.2361937.n4.nabble.com/NiFi-Docker-tp2562p2576.html Sent from the Apache NiFi Users List mailing list archive at Nabble.com.
Re: NiFi Docker
Dave, The echo Aldrin's comment I think this would be fantastic! Once you have a JIRA open I'd be more than happy to work with you and help get your suggested updates into the the code base. Thanks, Jeremy Dyer On Mon, Jul 31, 2017 at 8:40 AM, Aldrin Piri <aldrinp...@gmail.com> wrote: > Hi Dave, > > Yes! Most certainly to all these things you are suggesting. > > Would you be interested in opening a JIRA to capture these? If not, I > will be sure to do so. Definitely has been an item to address moving > forward as you are a limited with the current image. We may not be able to > support every configuration but we should strive to get an image that > covers all the base modes of operation. The items you highlight are well > within that purview. > > As far as the README, given how the images are published through ASF > channels, we do not have direct access to the Docker hub configuration. I > believe there is a way we can make it reflect a custom README in that > folder, but would have to do some research/experimentation. > > As far as the large layers, you would be correct and this is something > that has been remedied code wise via https://issues.apache.org/ > jira/browse/NIFI-4057. > > > > On Sun, Jul 30, 2017 at 6:32 AM, ddewaele <ddewa...@gmail.com> wrote: > >> Hi, >> >> We're using Nifi in a containerized environment (using docker-compose for >> local development and test, and docker swarm in production). >> >> The current docker image doesn't have a lot of environment options, >> meaning >> if you want to run Nifi with some custom config like the one below : >> >> environment: >> - NIFI_WEB_HTTP_HOST=xxx >> - NIFI_CLUSTER_HOST_NAME=xxx >> - NIFI_CLUSTER_HOST_PORT=xxx >> - NIFI_CLUSTER_PORT=xxx >> - NIFI_ZOOKEEPER_CONNECT_STRING=xxx >> - NIFI_CONTENT_REPOSITORY_ARCHIVE_MAX_USAGE_PERCENTAGE=xxx >> - CONFIG_URI_LABEL=xxx >> >> You need to create your own "wrapper" docker image (extending the base >> apache nifi one). >> >> Stuff that we typically to in a nifi installation is >> >> - change values in nifi.properties (a generic solution could be created >> for >> that where nifi property keys could be provided as environment variables >> to >> the docker container) >> - install custom processors (nar files) >> - custom log configuration (logback.xml) >> - custom bootstrap values >> - copy flow templates in nifi so they can be used immediately after >> startup. >> >> Have you ever thought of extending the current docker image, to allow a >> little bit more customization like this ones above. >> >> Some other things I noticed : >> >> - the readme on https://hub.docker.com/r/apache/nifi/ doesn't mention >> docker >> usage it all. seems to be the default nifi readme. >> >> - The current docker image contains 2 layers of 1gb each. I'm guessing >> this >> is the result of a) downloading and untarring the nifi distribution and b) >> executing the chown command. Is there a reason these are spread out over 2 >> docker run commands ? >> >> f5f88f68e088: Downloading [=> >> ] 25.9MB/978MB >> 5ed4b763cde4: Downloading [=> >> ] 34.02MB/978MB >> >> >> >> -- >> View this message in context: http://apache-nifi-users-list. >> 2361937.n4.nabble.com/NiFi-Docker-tp2562.html >> Sent from the Apache NiFi Users List mailing list archive at Nabble.com. >> > >
NiFi Docker
Hi, We're using Nifi in a containerized environment (using docker-compose for local development and test, and docker swarm in production). The current docker image doesn't have a lot of environment options, meaning if you want to run Nifi with some custom config like the one below : environment: - NIFI_WEB_HTTP_HOST=xxx - NIFI_CLUSTER_HOST_NAME=xxx - NIFI_CLUSTER_HOST_PORT=xxx - NIFI_CLUSTER_PORT=xxx - NIFI_ZOOKEEPER_CONNECT_STRING=xxx - NIFI_CONTENT_REPOSITORY_ARCHIVE_MAX_USAGE_PERCENTAGE=xxx - CONFIG_URI_LABEL=xxx You need to create your own "wrapper" docker image (extending the base apache nifi one). Stuff that we typically to in a nifi installation is - change values in nifi.properties (a generic solution could be created for that where nifi property keys could be provided as environment variables to the docker container) - install custom processors (nar files) - custom log configuration (logback.xml) - custom bootstrap values - copy flow templates in nifi so they can be used immediately after startup. Have you ever thought of extending the current docker image, to allow a little bit more customization like this ones above. Some other things I noticed : - the readme on https://hub.docker.com/r/apache/nifi/ doesn't mention docker usage it all. seems to be the default nifi readme. - The current docker image contains 2 layers of 1gb each. I'm guessing this is the result of a) downloading and untarring the nifi distribution and b) executing the chown command. Is there a reason these are spread out over 2 docker run commands ? f5f88f68e088: Downloading [=> ] 25.9MB/978MB 5ed4b763cde4: Downloading [=> ] 34.02MB/978MB -- View this message in context: http://apache-nifi-users-list.2361937.n4.nabble.com/NiFi-Docker-tp2562.html Sent from the Apache NiFi Users List mailing list archive at Nabble.com.
