Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
exceptionfactory commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1839962723 Thanks for the thoughtful reply @hawko2600, on further review, referencing that post was short-sighted on my part. The list of vulnerabilities claim caught my eye as unsubstantiated, but I should have taken a closer look at the other claims. I also should have taken a closer at the liberica-openjdk-alpine image description, noting the glibc base instead of musl, which I expected from other Alpine containers. I see from the the [image tag details](https://hub.docker.com/layers/bellsoft/liberica-openjdk-alpine/21/images/sha256-1b160fcd879e0d7e310773aa42f3b59fa8d907c4a1a50c64c18d822541d2da93?context=explore) that this does indeed use the glibc base. This is a good example of where having a more thorough background on the change would be helped provide a better initial evaluation. If you are still willing to put time into this, I would be glad to revisit the changes. As mentioned initially, if you can create a Jira issue for tracking, that would also help capture the background rationale, and importance of the fact that this Alpine image is based on glibc as opposed to musl. -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
joewitt commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1839955747 I am still interested in this happening. If the claims arent valid we just need to run this thing. Anything which makes the builds smaller is a win but we should be consistent. We need a JIRA, and the various docker images updated. -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
joewitt commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1839384718 Ahhh that is a great point @exceptionfactory. It might make sense to support/include a non python Java 2.0 based image on Alpine. That would end up a good bit smaller too. Something to consider as an alternative JIRA/PR -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
exceptionfactory commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1839297256 @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. -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
exceptionfactory closed pull request #8111: Update Dockerfile for alpine v3 / liberica v21 URL: https://github.com/apache/nifi/pull/8111 -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
exceptionfactory commented on PR #8111: URL: https://github.com/apache/nifi/pull/8111#issuecomment-1838858688 @hawko2600 Please review the pull request checklist and follow the steps to create an Apache NiFi Jira issue for tracking these changes as well. Thanks! -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Update Dockerfile for alpine v3 / liberica v21 [nifi]
hawko2600 opened a new pull request, #8111: URL: https://github.com/apache/nifi/pull/8111 Alter Dockerfile to rebase on Alpine Linux v3 with Liberica OpenJDK v21 for NiFi 2.0.0 # Summary [NIFI-0](https://issues.apache.org/jira/browse/NIFI-0) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
