Re: Docker container for 2.0.0-M1
Hello Yeah pls do submit a PR. Thanks On Wed, Nov 29, 2023 at 9:34 PM Matthew Hawkins wrote: > Hi Joe, > > I have it running against Bellsoft's v21 alpine-musl base fine, with python > enabled. Happy to submit the Dockerfile if you want. In a nutshell, > > apk add --no-cache --no-interactive --no-progress coreutils unzip curl jq > xmlstarlet procps-ng python3 py3-pip py3-virtualenv ripgrep > > And other than obviously Alpine not Debian, Busybox wants adduser/addgroup > not the util-linux variants. I moved the apk call to the scripts section so > only one apk update is needed, and deleted the apt cache cleanup. I added > the ripgrep package to grok logs. > > I initially missed the VOLUME line in the dockerfile. Unfortunately I can't > seem to get the -v flag to work to use local folders instead of anonymous > volumes. I appreciate it's probably done for performance but it would be > nice if they had sensible names. Host is Win11 with docker desktop and > wsl2. For brevity, I'm adding a -v > c:\users\me\nifi\conf:/opt/nifi/nifi-current/conf format line for each of > the exported volumes to the docker run invocation (wrote a small cmd to > launch as I'm not typing that monstrosity out daily by hand) > I know I can manually docker volume some nice named ones and alter the > VOLUME line accordingly. Should a docker compose be used instead? Because > this is all feeling hackish. > > KR, > > On Wed, 29 Nov 2023, 17:24 Joe Witt, wrote: > > > Matt > > > > Alpine is still desirable but it was about availability of Alpine w Java > 21 > > at that time. I think Alpine also required some different command and > such > > in the dockerfile. > > > > As far as the repo volumes they can be mapped as you wish now. It is > how I > > keep updating my own flow deployments I test with when I want to retain > > state across deployment. Are you not able to map them? > > > > Thanks > > > > > > > > On Tue, Nov 28, 2023 at 9:41 PM Matthew Hawkins > > wrote: > > > > > Two Q's regarding the docker container; > > > > > > 1. Why the Debian version instead of Alpine? Was it compatibility with > > > external stuff? I can confirm 2.0.0-M1 works fine with the alpine > version > > > of liberica-jdk on at least basic flows, with python enabled. It'll > save > > > disk space. I love Debian but Alpine is king of containers! > > > > > > 2. If we shift the repository folders out of NIFI_HOME per the regular > > best > > > practice doco, then a persistent docker volume could easily be used to > > > house these, making upgrades painless. I guess the flow.json, keystores > > and > > > configs could move too. > > > > > > Kind regards, > > > Matt > > > > > >
Re: Docker container for 2.0.0-M1
Hi Joe, I have it running against Bellsoft's v21 alpine-musl base fine, with python enabled. Happy to submit the Dockerfile if you want. In a nutshell, apk add --no-cache --no-interactive --no-progress coreutils unzip curl jq xmlstarlet procps-ng python3 py3-pip py3-virtualenv ripgrep And other than obviously Alpine not Debian, Busybox wants adduser/addgroup not the util-linux variants. I moved the apk call to the scripts section so only one apk update is needed, and deleted the apt cache cleanup. I added the ripgrep package to grok logs. I initially missed the VOLUME line in the dockerfile. Unfortunately I can't seem to get the -v flag to work to use local folders instead of anonymous volumes. I appreciate it's probably done for performance but it would be nice if they had sensible names. Host is Win11 with docker desktop and wsl2. For brevity, I'm adding a -v c:\users\me\nifi\conf:/opt/nifi/nifi-current/conf format line for each of the exported volumes to the docker run invocation (wrote a small cmd to launch as I'm not typing that monstrosity out daily by hand) I know I can manually docker volume some nice named ones and alter the VOLUME line accordingly. Should a docker compose be used instead? Because this is all feeling hackish. KR, On Wed, 29 Nov 2023, 17:24 Joe Witt, wrote: > Matt > > Alpine is still desirable but it was about availability of Alpine w Java 21 > at that time. I think Alpine also required some different command and such > in the dockerfile. > > As far as the repo volumes they can be mapped as you wish now. It is how I > keep updating my own flow deployments I test with when I want to retain > state across deployment. Are you not able to map them? > > Thanks > > > > On Tue, Nov 28, 2023 at 9:41 PM Matthew Hawkins > wrote: > > > Two Q's regarding the docker container; > > > > 1. Why the Debian version instead of Alpine? Was it compatibility with > > external stuff? I can confirm 2.0.0-M1 works fine with the alpine version > > of liberica-jdk on at least basic flows, with python enabled. It'll save > > disk space. I love Debian but Alpine is king of containers! > > > > 2. If we shift the repository folders out of NIFI_HOME per the regular > best > > practice doco, then a persistent docker volume could easily be used to > > house these, making upgrades painless. I guess the flow.json, keystores > and > > configs could move too. > > > > Kind regards, > > Matt > > >
Re: Docker container for 2.0.0-M1
Matt Alpine is still desirable but it was about availability of Alpine w Java 21 at that time. I think Alpine also required some different command and such in the dockerfile. As far as the repo volumes they can be mapped as you wish now. It is how I keep updating my own flow deployments I test with when I want to retain state across deployment. Are you not able to map them? Thanks On Tue, Nov 28, 2023 at 9:41 PM Matthew Hawkins wrote: > Two Q's regarding the docker container; > > 1. Why the Debian version instead of Alpine? Was it compatibility with > external stuff? I can confirm 2.0.0-M1 works fine with the alpine version > of liberica-jdk on at least basic flows, with python enabled. It'll save > disk space. I love Debian but Alpine is king of containers! > > 2. If we shift the repository folders out of NIFI_HOME per the regular best > practice doco, then a persistent docker volume could easily be used to > house these, making upgrades painless. I guess the flow.json, keystores and > configs could move too. > > Kind regards, > Matt >
Docker container for 2.0.0-M1
Two Q's regarding the docker container; 1. Why the Debian version instead of Alpine? Was it compatibility with external stuff? I can confirm 2.0.0-M1 works fine with the alpine version of liberica-jdk on at least basic flows, with python enabled. It'll save disk space. I love Debian but Alpine is king of containers! 2. If we shift the repository folders out of NIFI_HOME per the regular best practice doco, then a persistent docker volume could easily be used to house these, making upgrades painless. I guess the flow.json, keystores and configs could move too. Kind regards, Matt
