[ANN] glv.one - Gemini PaaS

[A. E. Spencer-Reed]

GemMail, without two Ms.

On Sat, Aug 29, 2020, 6:19 PM Peter Vernigorov <pitr.vern at gmail.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.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200829/308ff2bd/attachment-0001.htm>