dockerfiles: reduce debug information from the production container image.

[anthisfan]

follow-up for #8807

By reducing debug information from the production container image, we aim to achieve a lightweight container image and enhance security.
I considered using the same fluent-bit binary for both production and debug containers, while including the debug information file only in the debug container, allowing for the continued use of debuggers such as gdb as before.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• [N/A] Example configuration file for the change
• [N/A] Debug log output from testing the change

• [N/A] Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• [N/A] Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• [N/A] Documentation required for this feature

Backporting

• [N/A] Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[patrick-stephens]

Can you provide some details of the changes in the size, etc.?

[anthisfan]

Can you provide some details of the changes in the size, etc.?

# Example of building with the mainline Dockerfile (production target)

$ git branch
* master
$ docker buildx build --target production --platform "linux/amd64"  -t fluent-bit:current-20240514 --load .
$ docker image ls fluent-bit:current-20240514
REPOSITORY   TAG                IMAGE ID       CREATED          SIZE
fluent-bit   current-20240514   3a8fe68841a3   18 seconds ago   99MB
$ id=$(docker create fluent-bit:current-20240514)
$ docker cp $id:/fluent-bit ./test
$ du -smh ./test/bin/fluent-bit 
60M     ./test/bin/fluent-bit

# Example of building with the modified Dockerfile from this change #

$ git branch
  master
* removing-debug-info-from-production-image
$ docker buildx build --target production --platform "linux/amd64"  -t fluent-bit:stripped-20240514 --load .
$ docker image ls fluent-bit:stripped-20240514
REPOSITORY   TAG                 IMAGE ID       CREATED          SIZE
fluent-bit   stripped-20240514   d3cb02620594   18 seconds ago   47.2MB
$ id=$(docker create fluent-bit:stripped-20240514)
$ docker cp $id:/fluent-bit ./test
$ du -smh ./test/bin/fluent-bit 
9.8M    ./test/bin/fluent-bit

Hello, @patrick-stephens

As an example for amd64, the commands above demonstrate the following effect.

Specifically, with the current production build, Fluent Bit is being built as a binary of around 60M.

By using the modified Dockerfile in this PR to build the container, we can reduce the binary size to around 9M. As a result, the container size is reduced from 99M to 47M.

(I've updated the commit message to adhere to the commit message rules)

[anthisfan]

Additional information:
Although it overlaps a bit with the explanation in the PR description, when building the debug images, the debug files are placed under /usr/lib/debug/fluent-bit/bin.
This is linked as the PATH for debug information to /fluent-bit/bin/fluent-bit, and these files are only available in the debug images.
I confirmed that debug information can be obtained using gdb or other tools, as shown below:

$ git branch
  master
* removing-debug-info-from-production-image
$ docker buildx build --target debug --platform "linux/amd64"  -t fluent-bit:stripped-debug-20240514 --load .
$ docker run -it fluent-bit:stripped-debug-20240514 gdb /fluent-bit/bin/fluent-bit
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /fluent-bit/bin/fluent-bit...
Reading symbols from /usr/lib/debug//fluent-bit/bin/fluent-bit.debug...
(gdb) 

Please let me know if there is anything else I can assist with.

[patrick-stephens]

No need for a separate layer, just add it above

[anthisfan]

61ef5d4
I made corrections and added new commits.
Also, I consolidated the objcopy processing into a single layer.

[patrick-stephens]

Please resolve the failing checks as well.

[anthisfan]

Thanks for the review.I will rework it later :)

[anthisfan]

Thank you for the review. @patrick-stephens
(And thank you for updating the pull request title as well.)

[edsiper]

will this change affect symbol resolution when we hit a crash ? e, .g: we have backtrace and we get a hint on where things got wrong

[anthisfan]

will this change affect symbol resolution when we hit a crash ? e, .g: we have backtrace and we get a hint on where things got wrong

Thank you for your feedback. @edsiper
I believe this will be a trade-off between weight reduction, security, and debugging capabilities.
Removing debug symbol information will reduce the amount of information available when a crash occurs.
If a core dump is available at the time of a crash, we can use the debug symbol files included in the debug image to obtain detailed information.
While I made this proposal with a focus on weight reduction and security, after some self-reflection, I have not seen (at least to my knowledge) any container environments that store debug symbols. Therefore, I am considering withdrawing this proposal as it may make debugging more difficult.
(Especially if there have been many cases in the past where investigations were conducted based on stack trace information from user-reported crashes, I believe this would be all the more true)
I would appreciate your thoughts on this matter.