https://github.com/moribellamy/gexe
Easy binary runner / re-launcher.
https://github.com/moribellamy/gexe
cross-platform daemon daemonize golang
Last synced: 5 months ago
JSON representation
Easy binary runner / re-launcher.
- Host: GitHub
- URL: https://github.com/moribellamy/gexe
- Owner: moribellamy
- License: mit
- Created: 2018-03-05T22:37:13.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2018-03-08T22:34:15.000Z (over 8 years ago)
- Last Synced: 2024-06-20T14:27:42.058Z (about 2 years ago)
- Topics: cross-platform, daemon, daemonize, golang
- Language: Go
- Homepage:
- Size: 5.86 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# gexe
[](https://godoc.org/github.com/moribellamy/gexe)
gexe is a simple, cross-platform daemon to keep your binaries running. It
also supports a simple release flow.
At this time, gexe is _only_ recommended for hobby use (**not** production).
You might consider gexe if your binary isn't production critical, or if
you don't want to become expert in a new nanny proc every time you run on a new
platform.
## Usage
```
$ go get github.com/moribellamy/gexe
$ cp $GOPATH/src/github.com/moribellamy/gexe
$ ./gexe
```
## Alternatives
Consider your platform's main daemonization solution for production use.
Ubuntu has upstart, older linux has SYSV init, Windows has NSSM, Mac has
`brew services`, etc...
YAJSW seems to be cross-platform and mature.
There are also various devops solutions, like kubernetes, your cloud platform.
## The model
gexe manages a server "deployment" in a folder. The deployment folder is made
up of multiple "applications". Each application is a folder having this structure:
```
myapplication # A top-level directory, conceptually an "Application"
└── archive # Old releases
└── current
└── foo.exe # Exactly one executable file
└── any.txt # Other resources for foo.exe, ignored by gexe
└── any.dat
└── release # Contents of a new release
└── command # Files that appear here are interpreted as commands to gexe
```
* The `current` dir is where your executable, and any files needed by it, live.
The executable is invoked with `CWD=`
* The `release` dir is where you can stage a new release. Since it will
eventually be moved to `current`, you also want exactly one executable in
this folder.
* The `command` directory is for simple interface with the running gexe daemon.
To issue a command, create a file named...
* `stop` to temporarily halt your app
* `start` to restart your app after a call to stop
* `release` to stop your app, archive it, stage the contents of the "release"
dir to the "current" dir, then start
## TODO
* Integration with per-system nannys, so gexe will restart even after a crash.
* Unit tests
* Entire component tests with vagrant
* Per application configuration