ContainerSSH: Launch containers on demand
github.com
github.com
It is SO nice to come back where you left from multiple machines. Also it is very nice to have a 10 gig connection. It works incredible well. With Scala and the metals plug-ins it is very close to a full blown intellij experience.
Also have arch + i3 + openrdp dev containers which work awesome. Even with multi-monitor support. The only thing missing is gpu acceleration. Then it would be perfect.
Any chance you've published the build files somewhere? This sounds fantastic
If your dev environment's state mutates and deviates from the rest of a team's (or away from production), the deviation introduces bugs. This tool lets you "start fresh" with the correct environment every time, but (I imagine) also lets you update that shared environment by pushing a new container.
In this way you ensure everybody is developing off exactly the same thing, and can easily update that shared environment, but nobody clobbers anybody else's WIP, and you can test new changes in your own container, even persisting your own configuration using persistent volumes.
Sadly, this does not support port forwarding, which is the final feature necessary to do remote development (run your web app remotely, see it in your browser locally).
Edit: also, ContainerSSH tears down the container when you disconnect, so that may not exactly be what you are looking for.
If you have any questions, I'd be happy to answer.
Am I understanding that this is a fancy way of doing: - SSH to server - Create docker container (or Kubernetes) - docker exec -it container /bin/bash But in 1 command & auto cleanup?
Pretty neat. Not sure I have a use for it though. Would've loved to see more use case in the docs (along with making the video explain the project better since it's a great concept!)
I guess there's people out there who like to complain about stuff they don't use?
Proxy —> hub —> spawner based on selected image —> container with /user persistent PV
But the image needs to be spawnable by jhub (i/e it needs to have some variant of jupyter-server-proxy installed), and currently that limits you to JupyterLab, RStudio and openrefine.
If you can port-forward with containerssh you could bypass the whole jhub proxy / hub / spawner rigmarole and simply
Select image -> containerssh w/port forward -> start the desired dev environment from inside the container -> get to work.
Then you’re not limited to jhub-compatible environments, and you don’t have to manage the complexity of jhub.
We don’t have support for volumes yet, but I’m open to ideas.
https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...
Over time, more use cases have developed, most of them around the need for jump host or lab access. There has also been some research done into SSH attack patterns using this as a honeypot, which will hopefully be published soon. See: https://containerssh.io/usecases/lab/
Containers may give some false sense of security tough, a lot of people doesn't understand really that escaping a container is not such a difficult thing, since it pretty new stuff and bugs are being discovered, also the container may be configured badly, while the UNIX permission mechanism is around since forever and it's pretty solid (not that in the past there weren't bug that bypassed it, but the same bugs may as well be used in a container anyway).
As far as features are concerned, yes, you can make a git server you can push to, but allowing users to get a full shell and pull from their git server is a whole other comfort level. More modern alternatives would include on-server development with VS Code, which we aim to support in the next version with port forwarding supported.
As far as container security is concerned, if properly configured, these are still a sight more secure than trying to give users shell access without them. The UNIX permission mechanism is woefully inadequate for keeping users from messing with each other's stuff. This is obviously not a problem if you don't want to provide a shell service to users, but some services, like the LX Plus service at CERN mentioned in the other thread [1] is specifically that: a shell service for users to access.
One of the problems containers (or more accurately, network namespaces) solve are the language or development servers users may start for their development needs. These often don't contain any extra security beyond binding to 127.0.0.1. However, on a shared server this is obviously not enough.
The other problem with using purely UNIX permissions to isolate users in the webhosting sector is users messing up their permissions. Back in the day this was also a constant problem, so nowadays all webhosters run the webserver / PHP-FPM instance with the same user ID as the user uses to upload their code, often having multiple websites for the same user using the same user ID. This lends itself to cross-contamination between sites if one is breached. If the sites run on a different user ID, however, it becomes more difficult for a user to move data between them.
https://rkeene.dev/js-repl/?arg=bash
It creates a secure environment on every connection, though it doesn't use cgroups, just chroot, resource limits, and other boundary protection mechanisms, etc.
Don’t underestimate how much pushback and struggle even such a small tool addition can add to developers with already too many other things on their mind.
This enables the whole dev org to use ephemeral workflow from k8s, without having to understanding k8s.
SSH also comes with a lot of tooling integration that is not as readily available as for k8s. Tunneling through anything, IDE integration or sshfs to name a few.
Granularly locking down a k8s cluster can also be a challenge. It’s easier to just block your k8s api server from anyone who is not admin.
Otherwise in principle you are right, kubectl should on paper be equally or even more capable.
For more advanced use cases, such as k8s with tons of services, you're better off using something like tilt.dev.
edit: A really simple and effective process manager is foreman and its procfile format. I like the golang version of it (simple single binary with zero dependencies): https://github.com/ddollar/forego or https://github.com/mattn/goreman
It's a userspace process orchestrator/scheduler that works across all relevant platforms, supporting daemon processes and k8s style readiness/health checks.
In combination with nix flakes, it quickly reduced my projects docker-compose usage for easy-to-configure services.
This gave huge performance benefits for the M1 Mac folks on my team especially for CPU intensive processes thanks to native binaries.
For maximal ease of use, the remaining docker-compose containers are started/stopped as a process-compose task. Quite meta :)
This has been discussed ad-nauseum, but "getting started" with nix (or home-manager, or devshell) is an experience worse than trying to do anything with Linux in 2005.
Cobbling together a bunch of blogposts and docs which kind of, sort of, might let you piece together a config which works after enough iterations and unreadable backtraces is far more difficult than it needs to be, and that's before you get into cases like "I want Python linters in my environment, so I need Python, but I also need access to some modules from Python on the system, which aren't installable (let's say `python-apt`, which cannot be installed from pypi), and..."
For probably the 500th time someone has said it on HN this week, nix will never be really usable or gain wider adoption until someone puts together solid documentation, or even a solid "getting started -- intermediate" guide which can bridge between "let me set up a trivial env" and "I'm running nixos and it's nix all the way down"
I wonder how hard it is to make a custom backend...
One of the plans after the current release is creating a pluggable backend system. This is currently not possible and backends are, unfortunately, fairly hard to write.
I'm afraid, this may be something where YouTube isn't working as intended. (For example, I had problems with YouTube in Firefox on Linux for quite a while and needed to disable tracking protection entirely to get it working despite paying for Premium.)