Either way. You can just use "docker cp" to copy the file out of a running
instance.

On Wed, Apr 8, 2020 at 12:36 PM Kevin Telford <kevin.telf...@gmail.com>
wrote:

> Thank you Mike. This makes sense.
>
> How do you get the flow.xml.gz file? Do you have NiFi installed locally on
> bare metal or do you develop also in a container? Initially I was thinking
> of adding a custom volume to facilitate both getting and deploying the flow
> file.
>
> Best,
> Kevin
>
> On 2020/04/08 14:37:43, Mike Thomsen <mikerthom...@gmail.com> wrote:
> > What I've done in the past looks something like this:
> >
> > FROM apache/nifi:1.11.4
> > COPY flow.xml.gz /opt/nifi/nifi-current/conf/flow.xml.gz
> >
> > And that's it. The obvious caveat is that you need to follow good
> practices
> > with ensuring that your flow and the way you setup the container can
> > replicate the environment you built it on on your host.
> >
> > On Wed, Apr 8, 2020 at 10:34 AM Kevin Telford <kevin.telf...@gmail.com>
> > wrote:
> >
> > > Hi all – I have a two part question.
> > >
> > >
> > >
> > > I’d like to run NiFi inside a container in order to deploy to various
> > > environments. As far as I can tell, the flow.xml.gz file is the main
> > > “source” if you will, for a NiFi data flow.
> > >
> > > Q1) Is the flow.xml.gz file the “source” of a NiFi data flow, and if
> so, is
> > > it best practice to copy it to a new env in order to “deploy” a
> prebuilt
> > > flow? Or how best is this handled?
> > >
> > >
> > >
> > > Given that Q1 is true, my challenge then becomes somewhat
> Docker-specific…
> > >
> > > Situation:
> > >
> > >    - In the Dockerfile we unzip the NiFi source (L62
> > >    <
> > >
> https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L62
> > > >)
> > >    and then create Docker volumes (L75
> > >    <
> > >
> https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L75
> > > >
> > >    specifically for the conf dir). Once the container starts all the
> normal
> > >    NiFi startup things happen, and
> /opt/nifi/nifi-current/conf/flow.xml.gz
> > >    created.
> > >
> > > Complication:
> > >
> > >    - In order to persist flow.xml.gz outside of the container, I would
> > >    normally mount the /opt/nifi/nifi-current/conf directory, however in
> > > this
> > >    case I cannot mount it on initialization because that will overwrite
> > > conf
> > >    config files with whatever directory I bind it to (Docker container
> > >    isolation ensures host -> container file precedence).
> > >    - I could mount to a running container, but this is less ideal due
> to
> > >    the various ways a container can be deployed.
> > >    - I could copy manually from the running container, but this is less
> > >    ideal as it’s on demand, and not always persisting latest.
> > >
> > > Resolution:
> > >
> > >    - I believe instead, we would ideally create a few flow config
> specific
> > >    env vars and use them to update our nifi.properties (via
> > >
> > >
> https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/sh/start.sh
> > > ),
> > >    i.e. NIFI_FLOW_CONFIG_FILE_LOCATION,
> NIFI_FLOW_CONFIG_ARCHIVE_ENABLED,
> > >    NIFI_FLOW_CONFIG_ARCHIVE_DIR and so on for all
> nifi.flow.configuration
> > >    props.
> > >
> > > Q2) Would the above proposal be ideal? (add a few env vars to
> start.sh) –
> > > if so, happy to add a PR for the code and doc change. Or have others
> solved
> > > this a different way?
> > >
> > >
> > >
> > > Best,
> > >
> > > Kevin
> > >
> >
>

Reply via email to