This is the most basic kind of docker querying you will find. Does not support HTTPS. Seems to work for local docker engines. Has not been tested against remote docker engines, or full URLs. Note that if you want this to work you'll have to configure docker to allow manipulation without being root, i.e., the user you connect as will need to be in the `docker` group. This was done instead of pulling in the `bollard` crate. Maybe I'm being silly, but `bollard` uses a whole lot of other crates in the name of being general and robust. These crates, however, add an unacceptable size to the final binary. (In the experiment I ran, on a release build, the binary size went from 2904696 to 4840968 bytes: an increase of 1.8 MB. With this patch the release binary is 2986360 bytes, which is an increase of 80k.) I wanted to see exactly what I could get away with when it came to talking to docker. This here actually seems like a fine compromise: HTTP is very simple if you only have to worry about one specific server, and JSON is not very hard to parse if you don't care too much about error handling, or are willing to play fast and loose with punctuation (which I am). |
||
|---|---|---|
| .github/workflows | ||
| .vscode | ||
| src | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| config.toml | ||
| LICENSE | ||
| README.md | ||
| rustfmt.toml | ||
| test.py | ||
fwd
A port-forwarding utility.
Here's how it works:
- Get the latest release of
fwd - You install
fwdon the server somewhere in your$PATH(like/usr/bin/) - You install
fwdon the client (like your laptop) - You run
fwdon the client to connect to the server, like so:
doty@my.laptop$ fwd some.server
fwd will connect to some.server via ssh, and then show you a screen listing all of the ports that the server is listening on locally.
Use the up and down arrow keys (or j/k) to select the port you're interested in and press e to toggle forwarding of that port.
Now, connections to that port locally will be forwarded to the remote server.
If the port is something that might be interesting to a web browser, you can press <ENTER> with the port selected to open a browser pointed at that port.
If something is going wrong, pressing l will toggle logs that might explain it.
Press q to quit.
Future Improvements:
-
Clipboard integration: send something from the remote end of the pipe to the host's clipboard. (Sometimes you really want to copy some big buffer from the remote side and your terminal just can't make that work.)
-
Client heartbeats: I frequently wind up in a situation where the pipe is stalled: not broken but nothing is getting through. (This happens with my coder.com pipes all the time.)