💾 Archived View for rawtext.club › ~sloum › geminilist › 002520.gmi captured on 2020-10-31 at 14:36:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Sat Aug 29 23:18:59 BST 2020
- - - - - - - - - - - - - - - - - - -
Beware, if you're building a Go app on Linux, on a platform that's notAlpine, your code may fail to run! Because Alpine uses musl instead oflibc.
Yes, I compile my Go code with CGO_ENABLED=0, good point!
Are you thinking about putting these instructions up onthe 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 Dockerregistry with some limitations (eg. can't fetch images, only push).Registry is configured with a webhook [1] that notifies a simple httpservice of a push, which in turn checks user permissions, shuts downany old Docker containers and starts one with a new image version.Routing mesh is nginx built with ngx_stream_ssl_preread module [2] toroute requests based on ClientHello messages. Admin panel is a verysimple (200 lines) gemini app built with gig to create apps, viewlogs, 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 meand 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.