Devservices in remote container IDEs

[edeandrea]

Description

I posted this on Zulip as well in the Dev stream (https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Devservices.20in.20remote.20container.20IDEs/near/247608708)

Has anyone given any thought to how devservices (spinning up databases/Kafka/etc) might work when the developer is working in a remote IDE (like Eclipse Che/GitPods/CodeReady Workspaces/etc)?

Right now it doesn't....and it isn't a good experience at all for some of the workshops we're building which use these remote IDEs. We can't at all showcase how to use devservices.

It means we have to get tricky and first do a deployment to the underlying k8s platform, deploy a db, and then use remote-dev, when really what we want to showcase is quarkus:dev with devservices & continuous testing.

I'm trying to work with the CRW team as well (see eclipse-che/che#20227). Right now we don't have a solution for this.

Implementation ideas

No response

[quarkus-bot]

/cc @stuartwdouglas

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip.

This message is automatically generated by a bot.

[edeandrea]

I've also taken a look at testcontainers/testcontainers-java#2088 & containers/podman#7927. Seems some have gotten Testcontainers to work with podman but there are some configurations that need to be done with paths that are specific to the user id. In OpenShift/CRW those userids are generated dynamically, so it would be impossible to statically code them into a configuration file I think.

[guss77]

[...] but there are some configurations that need to be done with paths that are specific to the user id.

If you are referring to my comment here, then I think there is a misunderstanding here - the configuration file ~/.config/containers/containers.conf with the hard coded UID is optional and only needed if you want the podman command line to automatically use the Docker compatible service (by default podman is serverless).

For normal Docker compatibility you just need the DOCKER_HOST environment variable that can be created using the $UID environment variable, and this is only for using the pre-configured Ubuntu-installed Systemd user service. If you want to use Podman as a drop-in replacement for Docker - just set it use the same socket as you would with Docker.

[edeandrea]

Thank you @guss77 for the clarification!

[stuartwdouglas]

@edeandrea I have been thinking a bit about this, but it is relatively complex. We would likely need to spin up pods to run these images rather than using docker/podman directly, so it will be a lot of work as it would be a very different implementation to what we currently have.

[edeandrea]

Understood. It really is an important feature though. As someone who is responsible for building demos & workshops, we base those workshops on k8s-based IDEs, and this eliminates the ability to show/use those powerful features.

[maxandersen]

@edeandrea don't try and squeeze this into a k8 based IDEs today - it is a fundemental limitation of how k8s and especially openshift works.

one 'hack' is that testcontainters can work with any docker compatible api so you can kinda get this level of devservices in k8s its just not something that wont be permitted in most clusters.

[edeandrea]

@maxandersen I can somewhat agree with what you're saying. The problem is that every workshop we put together, every learning scenario (think Katacodas on learn.openshift.com) all run on a k8s environment and use a cloud-based IDE. Our Quarkus workshop for instance - we can no show nor demonstrate any of these dev services features.

I'm not suggesting an easy "fix", but I feel this is important and should be given some thought.

[maxandersen]

fyi, it works in gitpod.io and github codeworkspaces

try https://gitpod.io#https://github.com/maxandersen/quarkus-devservice

run jbang -Dquarkus.dev qdevservice.java and it just works.

this example is using jbang but it doesn't do anything special. will work with gradle and maven too.

the example just shows docker devservices starts - it needs more setup to actually do something so just a POC for now.

but it shows this works with remote container/cloud based IDE's - the issue is when the IDE is running in a constrained environment, like k8s or similar.

[edeandrea]

So in that example gitpod must be exposing the underlying container runtime to the workspace pod, something Eclipse Che/CodeReady Workspaces does not do.

[maxandersen]

no, it does not mean they expose the underlying container runtime - just that they have a docker remote deamon running which could be running in full isolation from anything else.

[edeandrea]

Maybe thats what I meant to say. You just worded it better than me :)

They've been able to have a docker daemon exposed to the pod running the workspace. Something Che/CRW does not do.

[edeandrea]

Coming back to this I think what I was meaning all along with this was the ability for Dev Services to spin up containers on a remote k8s environment rather than on the local machine. Now that would solve a lot of problems.

I think @burrsutter was looking for something like that too.

[maxandersen]

Give https://github.com/joyrex2001/kubedock a go ?