[ANN] glv.one - Gemini PaaS

[Peter Vernigorov]

> 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.