[HN Gopher] Show HN: Lapdev, a new open-source remote dev enviro...
___________________________________________________________________
Show HN: Lapdev, a new open-source remote dev environment
management software
Author : lyang2821
Score : 119 points
Date : 2024-03-23 17:07 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pocketarc wrote:
| This looks pretty good. Being able to use devcontainers on local
| server hardware without monthly fees (and/or hetzner servers)
| sounds great.
|
| Up until now we'd been making do with docker-compose and
| JetBrains's remote SSH dev; this should be significantly better.
| theK wrote:
| I spent more than a year living with the numerous downsides of
| high level CDE (containerized development environment) tools. I
| must admit that I am very skeptical about all options available
| right now and that I have rolled back to using plain, old
| school, docker compose based CDE.
|
| Both .devcontainers and .devfile managed to create more effort
| than they took away. Some key points:
|
| - long lived containers
|
| - abstracting away the fact that you run stuff inside
| containers in the IDE and abstracting away the container life
| cycle
|
| - cryptic error states and error messages, especially when
| setting up new projects from scratch. This often boiled down to
| bad plugins (even Microsoft's own VSCode plugins wet the bed
| often)
|
| - only superficial support for podman
|
| - bad support for arm based HW (and arch translation issues,
| like a tool requesting arm containers but the host running
| docker is x64)
|
| At this point I consult teams to try out a plain compose.yml as
| a CDE and skip the "enterprise" stuff.
| WhatIsDukkha wrote:
| This seems to be podman focused from what I see.
| theK wrote:
| No, not really. A big part of the problem is half baked
| software on the client side.
|
| For devcontainers even the reference implementation CLI is
| significantly incomplete.
| WhatIsDukkha wrote:
| https://happihacking.com/blog/posts/2023/dev-containers-
| emac...
|
| Looks pretty useable to me...
| algo_trader wrote:
| > JetBrains's remote SSH dev;
|
| Does that require a static ip on remote?
|
| I have skimmed the Jetbrain FAQ [1] and it says "no relay
| servers are involved"
|
| [1] https://www.jetbrains.com/help/idea/faq-about-remote-
| develop...
| vladvasiliu wrote:
| No, it's able to use your local ssh_config. For example, I
| use this to connect to a host running on aws via ssm. The vm
| isn't reachable at all directly.
|
| You can use something like the following in your
| ~/.ssh/config: Host devhost
| ProxyCommand aws --profile DevProfile ssm start-
| session --target i-0123456789abcdef0 --document-name AWS-
| StartSSHSession --parameters "portNumber=22"
|
| You then tell intellij to connect to "devhost". This also
| works under recent versions of Windows (those which ship with
| openssh).
| chiefalchemist wrote:
| If this is what I think it is, Visual Studio Code has an
| extension that does this as well.
| 1shooner wrote:
| I'm very interested to learn more about this class of tool. I had
| seen[0] Coder including alpha support for .devcontainer, but I'm
| not aware of other OSS options.
|
| 0.
| https://coder.com/docs/v2/latest/templates/devcontainers#dev...
| ninjha wrote:
| Having deployed a few of these over the last month or so, I
| feel like the devcontainer spec is very annoying. The
| alternative is what Coder does -- write some arbitrary
| terraform to bring up or down a workspace. I think this is
| better because I tend to need other things to go in a workspace
| (like an IAM role to access dev databases, associated
| Kubernetes resources, etc). With terraform I can configure
| whatever infrastructure I want to go along with workspaces.
|
| The main downside I can see is that users have to write their
| workspaces for a particular deployment target. This would be a
| problem for e.x. open source projects trying to check in a
| workspace definition file of some kind. We standardize on
| Kubernetes across clouds and bare metal so it's not an issue
| for us, but it makes sense that it would be an issue for other
| use cases.
| johnchristopher wrote:
| I don't understand. It's installed on a remote server, okay.
|
| But does it provide remote environments or local environments ?
|
| And what's an environment in this context ? A Docker compose file
| and a .env? Code or vim settings ? A vm a la vagrant ?
| lyang2821 wrote:
| Hi, Lapdev dev here. Let me try to answer your question.
|
| It's installed on a remote server so it provides remote
| environments. If you use VSCode remote, then you can "open" it
| through VSCode remote ssh.
|
| The environment that Lapdev provides essentially is a container
| (other format is on the roadmap) with things pre-installed as
| defined in Devcontainer(https://containers.dev/) format.
| johnchristopher wrote:
| Ah, I see. Thanks for the explanation !
|
| I haven't yet made the jump to remote/cloud development, I
| don't have a clear mental picture of how the pieces fit.
| brunoqc wrote:
| It's open-core
| https://github.com/lapce/lapdev/blob/8eeb3cc3cbbf4c5bf4e7928... ,
| if you care about that.
| code-wizz332 wrote:
| Yeah I wonder why they didn't go with Apache or MIT
| salamander014 wrote:
| So, I know very little about this devcontainer spec.
|
| Can I just ask, what value does this spec provide that a simple
| docker image containing the necessary tools does not already
| provide?
|
| Why do we need another layer on top? What am I missing?
| zamalek wrote:
| JSON, everything has to either be YAML or JSON.
|
| If I didn't invent the thing, then we shouldn't use the thing.
| Dockerfiles fall into this class too, they are just a shitty
| homegrown DSL.
| rad_gruchalski wrote:
| > If I didn't invent the thing, then we shouldn't use the
| thing.
|
| What about Linux? Or... the internet?
| owyn wrote:
| Well, developers seem to love writing "configuration" rather
| than "code" these days. But basically a container + the
| necessary tools IS a devcontainer. It's just a way of
| automating the "putting in the necessary tools" part especially
| if you need things that might need to be added to a base
| container, or services that need to be configured differently
| based on the external environment that you don't want to bake
| in for some reason.
|
| If you've ever had to cut and paste a 50 line docker run
| command snippet but you forgot that one volume mount or port or
| ENV var that someone added a dependency on last week then you
| pretty quickly realize just doing complex docker things by hand
| is a pain. Another example, if you have a script that you want
| to run to fetch the latest authentication token from a vault
| after the container launches because you don't want to store it
| inside the container. Sure, you could write a bash script to
| run all these steps inside the container after you launch it
| but it's nice to have a config file to share with another dev
| and just say: use this.
|
| And the secondary benefit is that having a config file for the
| editor (like VSCode) so that plugins can manage all of that
| stuff better. Generally a dev container runs the VSCode Server,
| and they know how to talk to each other which can make remote
| development easier. For example, now I can launch the same dev
| environment locally or on the 56 core xeon 1TB ram server at
| the office and it's exactly the same as far as the editor is
| concerned.
|
| It looks like this project is an alternative to the VSCode
| Server. My team generally uses docker-compose for this since
| not everyone uses VSCode.
| salamander014 wrote:
| For the first bit, all I can think is a compose file. Also
| podman can run k8s configs locally, which I personally hope
| all of that eventually washes into the same thing. It feels
| like we already have the tools to make this a "solved"
| problem, is what I'm trying to say. I just include an
| additional .env that the compose file pulls in so it's not
| committed to git.
|
| For the second point, ok this makes a little bit more sense,
| I've heard of Codespaces or OpenShift Dev Spaces but I guess
| I still question the value of additional complexity on top of
| the container (a simple dockerfile in my mind) your vscode
| instance's terminal is running in.
|
| Thanks for the info.
| bitwize wrote:
| It makes it easy to point the tool at a Git repo, have it
| automagically create a containerized environment for that repo
| with all its dependencies, and open Visual Studio Code on the
| codebase inside that remote containerized environment.
|
| Devcontainer was created by Microsoft to support Visual Studio
| Code's remote development features, so it works best in Visual
| Studio Code. Inasmuch as other IDEs support it, that's up to
| the IDE vendor.
| salamander014 wrote:
| So this is a config standard for the infrastructure
| underneath something like remote vscode / devcontainers?
| bitwize wrote:
| Pretty much, yeah. It contains all the info necessary to
| tell Docker how to build/deploy the container, and how to
| configure the editor to work in it. The goal is turnkey
| setup of the software, its environment, and the user's IDE
| so that developers don't have to waste _days_ doing that by
| hand.
| gravypod wrote:
| A lot of remote dev environments have limitations when it comes
| to certain types of development. For example, ios and android app
| development can be tricky. Or game development where you need to
| have GPUs and build artifacts may be slow to download to your
| machine.
|
| Are there any guidances for how to fix this?
| Oranguru wrote:
| You can access GPUs within containers using CDI (Container
| Device Interface): https://docs.nvidia.com/datacenter/cloud-
| native/container-to... No additional tools (e.g., nvidia-ctk)
| are needed. Docker has recently added support for CDI in
| version 25.0.
| ammario wrote:
| Founder of coder (https://github.com/coder/coder) here. We
| choose Terraform as our provisioning layer so that users can
| provision full blown VMs as their development environment.
|
| We have many teams using GPUs with Coder for ML workloads but
| doing GUI/Game remote development where interactivity is
| essential remains elusive.
| ivanjermakov wrote:
| Can I connect to the environment over https? I'm looking for a
| good solution to use nvim from the browser on my iPad on the go.
| Eridrus wrote:
| I am interested in remote dev environments, but I'm not super
| excited about managing yet more software in the cloud.
|
| There were some headaches around the exact specifics since it
| wasn't designed for this, but I liked the idea of using skypilot
| to launch dev machines in the cloud since it has plugins to all
| the cloud APIs and so you don't need to manage a k8s cluster to
| launch a dev machine. Admittedly it worked better for launching a
| Jupyter server than a "full" dev machine, but a full dev machine
| seemed to be just a few ssh/vs code configurations away.
| somethingsome wrote:
| Main current main pain point with devcontainers is to run a gui
| app remote, wathever I do, the gui opens only on the server. I'm
| wondering if this solution can export gui remotely?
___________________________________________________________________
(page generated 2024-03-23 23:00 UTC)