hawko2600 commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1839944758
> @hawko2600 On further consideration, moving to Alpine does not look like a feasible approach for the standard container images. > > The primary reason is the difference in platforms with musl for Alpine versus glibc for Debian, as described in the following article: > > https://megamorf.gitlab.io/2020/05/06/why-it-s-better-not-to-use-alpine-linux-for-python-projects/ > > With NiFi 2.0.0 supporting native Python Processors, having general compatibility with Python C libraries is important. > > In terms of actual container size, the current difference between the Debian and Alpine images is around 75 MB. Although size optimization is important, NiFi binaries make up the primary share of container size. > > It is also worth highlighting that the current container images are targeted for general use cases, and particular deployment environments may have other requirements. > > There are other potential improvements for the current container configuration, so some of this discussion may be worth continuing in Jira. > > In light of the platform concerns with Alpine and Python, I am closing the pull request for now. Thanks for proposing this alternative approach. It's unfortunate that that website from 3 years ago contains verifiable lies, for example it states that there is no CVE list for alpine whereas anyone can see from the homepage of alpinelinux.org that security.alpinelinux.org is linked directly and contains a comprehensive list. I also find the performance issue contrived; the example given demonstrates installing pre-compiled apks versus compiling and installing muultiple packages from source. It claims the precompiled version took over 16 minutes whereas the needs-compiling version took only 12 seconds. There's no way that stacks up in the real world! The only way to achieve this would be to pre-compile the wheel files and include them in the docker image so the pip install only takes I/O unpacking time, which would mount to about ... 12 seconds. Obviously 16 minutes to install apks is because they set the network interface to 2Kb/s and let it download from an alpine mirror on the other side of the planet. Absolutely zero evidence was supplied as a normal shootout would do to ensure basic critical analysis would be satisfied that the premise is being tested, not external factors. The main complaint about using MUSL stdlib is that "it might" be different to glibc. Well, it better be, or they failed in their mission to remove the bloat. No evidence was produced for the claim. Presumably, if I am on a Linux system with the debug version of glibc and the debug version of musl, then the difference in debugging is that with one I run the app through gdb and the other I ... run the app through gdb? There's absolutely zero difference. It's just FUD. And in any case, it's a moot point because the images here are based on the glibc version of Alpine, which I did deliberately because I'm well aware that some libraries insist on being glibc-compatible only and we have an open-ended functionality presented through the new Python API interface. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
