nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <>
Subject Re: Revisiting MINIFI-175; minifi-cpp Alpine Dockerfile
Date Wed, 26 Apr 2017 15:09:13 GMT
Don't think there would be any objections to going smaller with Alpine and
certainly makes a lot of sense, but I believe initial efforts were
problematic and there was a general desire to get a foundation going.  The
biggest issue was needing to navigate cross compilation of a given host to
the Alpine format which was something our processes are not quite up to at
this juncture.  The integrated dev setup in the image avoided having to
tackle this and allowed building of the image on any system where Docker
could run whether natively or via one of the Docker for $OS setups.

Hadn't actually been aware of the multi-stage docker builds before this
thread, but certainly seems like a great application after looking through
the associated PRs and docs and could be a more immediate win for the
particular case above.

We could and should certainly strive to make components pluggable, in this
case logging, to support such cases where things may be problematic given a
target environment.  I don't think I'd be in favor of removing spdlog at
this point but could apply similar approaches used elsewhere in the
codebase to give us a little more configurability to use an alternate

Would be in favor of opening up an issue to optimize our Docker build and
certainly target Alpine with some of the new build magic.  By the time we
have it implemented, the multi-stage builds should likely be sufficiently

On Wed, Apr 26, 2017 at 10:19 AM, Andrew Christianson <> wrote:

> Have we considered porting the current Dockerfile from Ubuntu to Alpine?
> The ubuntu image, especially with all the build-time deps left in the final
> image, is quite bloated. This runs against the design intent of minimal
> footprint in minifi-cpp. Further, the new multi-stage Docker builds would
> allow us to isolate the build environment in its own stage and allow only
> runtime deps to exist in the final image. Overall it would be a much
> smaller image.
> Reviewing the JIRA activity for MINIFI-175, it seems the decision to not
> use alpine was originally due to the desire to encapsulate the build of
> minifi inside the build of the docker image, which for some reason wasn't
> compatible with using alpine. On initial testing, it seems alpine's musl
> libc has issues with spdlog. Since it may involve some effort and decision
> making with regard to which dependencies are used, this is a decision
> probably best made by the community.
> Thoughts?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message