gbN025tt2Z1E2E4
Joined 5 years ago
Joined 5 years ago
COPY --from=ugit-ops /usr/lib/libreadline* /usr/lib/
COPY --from=ugit-ops /lib/libc.musl-* /lib/
COPY --from=ugit-ops /lib/ld-musl-* /lib/
No, what I'm saying is you're blanket copying fully different versions of common library files into operating system lib folders as shown above, possibly breaking OS lib symlinks and/or wholly overwriting OS lib files themselves in the process for _current_ versions used in Alpine OS if they exist now or in the future, potentially destroying OS lib dependencies, and also overwriting the ones possibly included in the future by Alpine OS itself to get your statically copied versions of the various CLI tools your shell script needs to work. The same goes for copying bash, tr, git, and other binaries to OS bin folders. No No NO!
That is _insanely_ shortsighted. There's a safe way to do that and then there is the way you did it. If you want to learn to do it right and are deadset against static binary versions of those tools for the sake of file size, look at how Exodus does it so that they don't destroy OS bin folders and library dependency files in the process of making a binary able to be moved from one OS to another.
Exodus: https://github.com/intoli/exodus
This is why I'm saying your resulting docker image is incredibly fragile and something I would never depend on long-term as it's almost guaranteed to crash and burn as Alpine OS upgrades OS bins and lib dependency files in the future. That it works now in this version is an aberration at best and in reality, there probably are things that are broken in Alpine OS that you aren't even aware of because you may not be using the functionality you broke yet.
OS package managers handle dependencies for a reason.
Overall this approach results in an image so fragile I would never use the resulting product in a high-priority production environment or even just my local dev environment as I want to code in it, not have to fix numerous compatibility issues in my tools all over 14MB of space.
This is adding yet another abstraction layer on top of docker which is already a convoluted space with numerous options available. Additionally, the "Balanced control between App Devs and Operators" tagline makes me wonder how "operators" would have a better awareness of how a deployment should operate versus the developers themselves. The developers should be creating their solutions based on previously defined security constraints and compliance requirements, so what "balanced control" is being shifted around here?
Grats on the sale either way.
I guess that's why the Democrat Obama opened up access to all NSA raw sigint data to every other federal law enforcement agency (all 16 of 'em) before leaving office. His final f you to American citizens as president (officially). Because he was soooooo concerned about trampling on citizen civil liberties... Right.
Give me a break... the article is obviously a leftist hit piece against the right.
Little Snitch is great for when I want hyper granular control of a specific app's network permissions while Radio Silence gives me a super quick way to just block EVERYTHING for a particular app right away without even opening it the first time.