> 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. Yes, I compile my Go code with CGO_ENABLED=0, good point! > Are you thinking about putting these instructions up on the capsule itself? Good idea, I added a link to a How To page. > And finally, is the source code of this platform available? There isn't much code to make available per se. I run a private Docker registry with some limitations (eg. can't fetch images, only push). Registry is configured with a webhook [1] that notifies a simple http service of a push, which in turn checks user permissions, shuts down any old Docker containers and starts one with a new image version. Routing mesh is nginx built with ngx_stream_ssl_preread module [2] to route requests based on ClientHello messages. Admin panel is a very simple (200 lines) gemini app built with gig to create apps, view logs, rollback to old versions, etc. [1] https://docs.docker.com/registry/notifications/ [2] http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html > Could I host a SMTP server with the Gemini server an make a gemail service? Why not! I am not entirely sure what you mean by gemail, but ping me and we can try setting this up. On Sat, Aug 29, 2020 at 10:37 PM A. E. Spencer-Reed <easrng at gmail.com> wrote: > > Could I host a SMTP server with the Gemini server an make a gemail service? > > On Sat, Aug 29, 2020, 4:15 PM <easeout at tilde.team> wrote: >> >> 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 closely >> simulate your release environment. A nice way to do that is with a >> multi-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 up >> to the first stage only, and supply a command to build and run. If you >> supply a bind mount to your source folder, you can even combine a tool >> like entr and a bind mount to build and run on source file changes from >> your editor of choice on the host OS. >> >> I've used this kind of workflow with multiple languages, hosting Alpine >> containers on macOS. Go is particularly good at it due to its fast build >> times. This would also work if you are not rebuilding software, but say, >> rerunning a static site generator given new input files. I could trim >> some project down to an example if you're interested.
---
Previous in thread (4 of 6): 🗣️ A. E. Spencer-Reed (easrng (a) gmail.com)
Next in thread (6 of 6): 🗣️ A. E. Spencer-Reed (easrng (a) gmail.com)