3 ms·
It seems (from the material on the site) that the motivating use case for this isn't development, but rather running computer labs for students.
by scoopertrooper 4y ago
It seems (from the material on the site) that the motivating use case for this isn't development, but rather running computer labs for students.
- razemio 4y agoIf did understand it correctly, it can be used to auto deploy a container on an ssh host, start the cli and once you exit, it will clean everything up. This would be very usable for developing certain things.
- janosdebugs 4y agoYou did understand it correctly. ;)
- scoopertrooper 4y agoFor sure, it could be used that way. But, a lot of people were comparing this unfavourably to how they currently manage their dev workflows. My point was that they weren't really the target market.
- 0xbadcafebee 4y agoI think this is the workflow most people should be moving to: immutable development. 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).
- janosdebugs 4y agoIf you build from the libcontainerssh sources on GitHub it does. We just haven't released it yet. :)
- 0xbadcafebee 4y agoIs there some docs on how to use it after I've compiled it? I'd like to try it out... Evaluating solutions like these right now, could be really useful for us