3 ms·

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

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 3y ago
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 3y ago
  This seems to be podman focused from what I see.
  - theK 3y ago
    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 3y ago
      https://happihacking.com/blog/posts/2023/dev-containers-emacs/ https://happihacking.com/blog/posts/2023/dev-containers-emac... Looks pretty useable to me...
      - theK 3y ago
        You still cannot stop, remove or update a Dev container from CLI and there at numerous issues with the rest of the implemented features. [0]: https://github.com/devcontainers/cli?tab=readme-ov-file#context https://github.com/devcontainers/cli?tab=readme-ov-file#cont...
algo_trader 3y ago
> 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-development.html https://www.jetbrains.com/help/idea/faq-about-remote-develop...
- vladvasiliu 3y ago
  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).
  - lucw 3y ago
    ipv6 is perfect for this use case, every development VM is directly reachable.
chiefalchemist 3y ago
If this is what I think it is, Visual Studio Code has an extension that does this as well.

theK 3y ago

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 3y ago
This seems to be podman focused from what I see.
- theK 3y ago
  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 3y ago
    https://happihacking.com/blog/posts/2023/dev-containers-emacs/ https://happihacking.com/blog/posts/2023/dev-containers-emac... Looks pretty useable to me...
    - theK 3y ago
      You still cannot stop, remove or update a Dev container from CLI and there at numerous issues with the rest of the implemented features. [0]: https://github.com/devcontainers/cli?tab=readme-ov-file#context https://github.com/devcontainers/cli?tab=readme-ov-file#cont...

algo_trader 3y ago

> 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-development.html https://www.jetbrains.com/help/idea/faq-about-remote-develop...

vladvasiliu 3y ago
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).
- lucw 3y ago
  ipv6 is perfect for this use case, every development VM is directly reachable.

chiefalchemist 3y ago

If this is what I think it is, Visual Studio Code has an extension that does this as well.