barak/kubelwagen
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
No description
16 commits 1 branch 0 tags 1,021 KiB
Find a file
Exact
Barak Michener b07acdf5c8 forgot connect.go
2018-03-31 18:03:37 -07:00
client File operations 2018-03-31 16:58:46 -07:00
cmd/kubelwagen forgot connect.go 2018-03-31 18:03:37 -07:00
fs File operations 2018-03-31 16:58:46 -07:00
vendor use cachingfs 2018-03-31 17:24:57 -07:00
.gitignore first servicable server 2018-03-29 14:29:05 -07:00
filesystem.go use cachingfs 2018-03-31 17:24:57 -07:00
fs.go first cross-websocket ls 2018-03-30 11:39:11 -07:00
fs_file.go File operations 2018-03-31 16:58:46 -07:00
fuse.go add a bunch of methods to the client end 2018-03-30 21:36:56 -07:00
Gopkg.lock use cachingfs 2018-03-31 17:24:57 -07:00
Gopkg.toml fix dep, impl nonempty 2018-03-30 19:36:37 -07:00
http.go first servicable server 2018-03-29 14:29:05 -07:00
LICENSE Initial commit 2018-03-28 13:07:45 -07:00
README.md finish basic fs commands, stub out file on server side 2018-03-31 15:11:02 -07:00
request.go set up requests from server side 2018-03-31 15:43:38 -07:00
serve.go fix dep, impl nonempty 2018-03-30 19:36:37 -07:00
wsconn.go first servicable server 2018-03-29 14:29:05 -07:00

README.md

kubelwagen

Getting your dev environment to the front lines

It's great to have a consistent environment in containers, and it's great to have services run on Kubernetes, but it's a pain to build dev containers to be run as pods on Kubernetes. git pull on pod creation helps, but it still requires you commit and push the code, and restart the pod.

It would be great if your live development working directory could be mounted into a running pod on the powerful metal in the cloud. Plus, it would obviate the need for workaround services such as ngrok to share a running WIP instance, as it would have a valid service on the dev cluster, complete with Ingress resources and everything. Plus, it's running in-cluster; so all the configurations and access controls and service discoveries are available to your dev instance. With the absolute latest, WIP code from your laptop.

Use it in tandem with automatically refreshing dev environments -- JS auto-reloaders for frontend devs, entr for general reloads, or any other tooling you like.

Kubelwagen is a sidecar (hah) container that provides a FUSE directory to the running pod that is mounted in from a client connecting in over an HTTPS websocket.

FUSE over Websockets? Are you insane?

It's a dev tool, HTTPS is pretty good, relax. Yeah, it'll be slow... but with appropriate caching, a few extra automatic reload milliseconds of the code you just changed is preferable to rebuilding a container or rescheduling a pod. Faster iteration times == happier devs. Closer parity to your laptop and production == happier ops.

Setting it up

kubelwagen serve [TARGET DIRECTORY]

kubelwagen connect [TARGET ADDRESS] [SOURCE DIRECTORY]

Status & Todo

Status

First mounting! ls over the internet to your heart's content!

Todo

  • Implement all the methods!
    • XAttrs
  • File handles
  • Caching
  • INotify
  • Overlay (serve local directory when not connected)

Licensing

Distributed under the GPL, as it's a dev tool and not meant as a product. Use it internally. Share alike.

Why call it kubelwagen?

I was on vacation and read The Last Battle: When U.S. and German Soldiers Joined Forces in the Waning Hours of World War II in Europe in one sitting, and noticed a word, starting with kube, that fit themeatically, with an idea I already had.