💾 Archived View for gemi.dev › gemini-mailing-list › 000349.gmi captured on 2023-11-04 at 12:43:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
This is slightly different from other capsule hosting sites. Instead
of hosting .gmi files, glv.one will run your Docker image with Gemini
service. Obviously the barrier of entry is higher than sftp-ing text
files to a server, but I see some folks here who want to build dynamic
gemini sites but not able to host them themselves.
It all started when I was annoyed with complicated deployment of my
gemini servers (egsam, wikipedia proxy, geddit) and wanted something
simple, like a `docker push`. So I've built a Platform-as-a-Service
(think Heroku, AWS Elastic Beanstalk etc). My sites have been running
on it for about a month now.
## What you get
- 1 docker container with 0.1 CPU shares and 10mb of RAM
- MySQL database with daily backups
- Domain MY_APP.glv.one with support for a custom (sub-)domain if you have one
- At no cost (my setup is pretty economical and I can easily support ~50 apps)
## How to use it
- Ping me for an account at this email address
- Login and create an app at gemini://glv.one (this is where you will
find an admin panel)
- Push your docker images to deploy.glv.one/USER/APP:VERSION
## Example
The following example deploys a simple Go app using gig framework, but
any language is supported as long as it can run inside Docker. To
start, create the following files:
### Dockerfile
```
FROM alpine:latest
ADD example /
ADD my.crt /my.crt
ADD my.key /my.key
CMD ["/example"]
```
### main.go
```
package main
import "github.com/pitr/gig"
func main() {
g := gig.Default()
g.Handle("/", func(c gig.Context) error {
return c.Gemini("# Hello, World!")
})
g.Run("my.crt", "my.key")
}
```
Now run the following:
- `go mod init example`
- `GOOS=linux GOARCH=amd64 go build`
- `openssl req -x509 -out my.crt -keyout my.key -newkey rsa:2048
-nodes -sha256 -subj '/CN=example.glv.one' -extensions EXT -config <(
printf "[dn]\nCN=example.glv.one\n[req]\ndistinguished_name =
dn\n[EXT]\nsubjectAltName=DNS:example.glv.one\nkeyUsage=digitalSignature\ne
xtendedKeyUsage=serverAuth")`
- `docker build -t deploy.glv.one/USER/example:v1 .`
- `docker push deploy.glv.one/USER/example:v1`
That's it, it's deployed. More information, such as how to access DB,
is available once authenticated at gemini://glv.one
Hello Peter, This looks awesome! Thanks for making it free, it's a nice service for the community. And using Docker images is an interesting way to do this, was it your idea? I like it. One thing I noticed is that in your example you show a docker container on Alpine, and building the Linux binary like this: > `GOOS=linux GOARCH=amd64 go build` 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 Hope that's helpful. Two more things. Are you thinking about putting these instructions up on the capsule itself? Right now glv.one just says to email you, but it'd be nice if you pasted your email on their to give people an idea of what they could do. And finally, is the source code of this platform available? I think I'm becoming the Gemini source code guy at this point, but I think it's important. Cheers, makeworld
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.
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. >
> 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.
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. >
---
Previous Thread: Announcing slice.breadpunk.club
Next Thread: Geminaut, anyone else have Antivirus rejecting the executable?