💾 Archived View for rawtext.club › ~sloum › geminilist › 002518.gmi captured on 2020-10-31 at 14:36:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
easeout at tilde.team easeout at tilde.team
Sat Aug 29 21:15:18 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sat, Aug 29, 2020 at 07:39:17PM +0000, colecmac at protonmail.com wrote:
Beware, if you're building a Go app on Linux, on a platform that's not
Alpine, your code may fail to run! Because Alpine uses musl instead of
libc. Some solutions:
- Build the binary in the docker container, and use multi-stage builds
to reduce size
- Build with CGO_ENABLED=0 to not link to any C libs
- Base your docker image on Debian/Ubuntu instead of Alpine
I agree, and I'll add one more option:
- While developing an application that will run in Docker, run your development builds in Docker too.
One advantage of Docker is that your development environment can closelysimulate your release environment. A nice way to do that is with amulti-stage build and an optional bind-mounted volume:
- In the first stage, include what you need to build, adding your source files last.- In the second stage, do a release build.- In the third stage, restart with blank Alpine and add the binary.
For a release image, build to the last stage. For development, build upto the first stage only, and supply a command to build and run. If yousupply a bind mount to your source folder, you can even combine a toollike entr and a bind mount to build and run on source file changes fromyour editor of choice on the host OS.
I've used this kind of workflow with multiple languages, hosting Alpinecontainers on macOS. Go is particularly good at it due to its fast buildtimes. This would also work if you are not rebuilding software, but say,rerunning a static site generator given new input files. I could trimsome project down to an example if you're interested.