Che: Use IDE on existing server without vms/dockers?

[siliconalchemy]

Hi, many apologies if this has been answered already but I've looked through closed issues and the docs and can't see a simple answer.
Can I run che on an existing server as an IDE, similar to cloud9? I have servers already setup how I like them with puppet and lots of code on the local filesystem, I really just want to run che as an IDE for this code. Cloud9 offers an 'ssh' workspace for their commercial offering that allows use of existing servers/code.
I appreciate the che environments, they're cool and all, but like a lot of existing environments I already have mine setup how I like them.

[ghost]

Hello,

Right now, Docker is the only implementation of Machine API. So, Docker is a requirement. A workspace runs in a Docker containers, communicates with Che server etc.

[siliconalchemy]

Ah OK. So is there a plan to implement this?
And in the meantime, is there a way to work around this? Like import my code into a new workspace/environment but have it sync to the original filesystem so it can still be stored/served from there?

[ghost]

@benoitf experimented with a local implementation of Machine API.

As to project storage, when a workspace starts we mount a directory specified in che.properties into /projects directory in the container:

che.user.workspaces.storage=${che.home}/workspaces

You may reconfigure Che so that this property points to a location outside Che binaries. This storject storage directory will have subdirectories that container projects for each workspace. You may copy your local projects there, and they will show up in in the IDE and User Dashboard.

[siliconalchemy]

@eivantsov - this might be a good workaround. I need to symlink files into place however and my symlink just shows up in the IDE as a blank directory. Is there any way to use symlinks?

[ghost]

Can you elaborate?

I haven't personally tried the symlink approach. Will test today. Meanwhile, please share the steps you have taken.

[siliconalchemy]

If I create a simple workspace named default, then inside that I create a blank 'www' directory and import it as a blank project, then inside that if I try and symlink in content directories from elsewhere in the filesystem, these symlinks just show up as empty directories, with nothing in them. Permissions are correct.

[siliconalchemy]

As a follow-up to the original question, as I spend more and more time trying to get the workspaces and projects running in che, the more I wish for the simple ability to use it as a basic IDE, that is an intelligent editor for coding files. Not everyone uses docker or wants to use docker - a lot of devops or production environments already have complex environments configured through CM tools like chef or puppet. If you could have a 'native' option so that both the che process and a single workspace if you like that runs natively on the underlying server it would massively simplify setting up a basic che environment. Or even a pre-canned single tiny docker workspace/project that can map onto existing filesystem areas.

[TylerJewell]

I understand where you are coming from. That sort of mode would enable Che to operate as a more traditional desktop IDE. The proper implementation of such a thing would be a new implementation of the Machine API with a localhost provider. The default provider is a Docker Machine.

We need the community to investigate this and perhaps its a great improvement to provide multiple Machine providers out of the box, which are switchable on the command line with the system that is running.

In previous Che planning meetings (going back about 9 months), there was a discussion about whether such a capability is useful or potentially harmful without a reasonable remediation. The concern among engineers is that the core value of such a system like Che is that the workspaces are portable, so that they can run on different locations. This imposes some challenges with booting workspaces within a container. If a user was using a localhost Machine implementation, though, the workspace would be bound to that localhost and no longer portable. Also, we'd likely lose some multi-machine capabiltiies, snapshotting, and the so forth.

So this is a logical concern that gets discussion. I have designated this request as an enhancement with help wanted as we need to matriculate a non-Docker Machine implementation.

[SantjagoCorkez]

My 5 cents to this: dockerless implementations would help one to deploy a multi-user multi-workspace remote IDE for example as a FreeBSD jail. Jails are also still sort of portable environments.

[TylerJewell]

@SantjagoCorkez @siliconalchemy - we have scheduled the implementation of "localhost" machines to replace Docker machines and this should be completed before the end of the quarter. @vkuznyetsov - please create tracking epic in GitHub with all necessary issues as check boxes, and then link that epic to this issue for tracking.

[siliconalchemy]

@TylerJewell Great :) Really look forward to trying out che.

[jmls]

what I would _really_ like to be able to do is run the che IDE in a docker container.

The ide, the whole ide and nothing but the ide ;) (don't need workspaces, docker management). Just to be able to use che as a pure IDE

Would "localhost" mode provide this capability ?

oh, hi @TylerJewell : hope things are going well for you guys !

[TylerJewell]

We are thinking about it - but that mode does break a lot of the core principles behind the product, which is around workspace portability. The way we would implement that is with what we would call "localhost machines". You'd still get a workspace. That workspace would still have environments that start / stop. But instead of us using a Docker container to launch that environment, we would - instead - assume that localhost is the environment. We'd then add our agents into localhost and use the underlying OS the same way that we do inside of a container, or a local IDE does traditionally.

The downside of this is that the workspace becomes less portable - because there may be software installed on the localhost OS that does not exist elsewhere. So we get cautious with this configuration.

When we discussed this at the beginning of July - we were developing a specification. Now we have one, and it will probably be acted upon as soon as we ship composefile support - which lets workspaces be powered by docker compose like syntax.

[TylerJewell]

We are going to implement this and add it by the end of the year.

[muhsinvp]

Work sapces can't protect with authentication ?

[TylerJewell]

Codenvy provides authentication for workspaces with their implementation of Che. But Che does not provide this security. Bitnami provides a basic authentication but it is a router-based auth system. You can search through teh archives for an explanation architecturally as to _why_ this is the case, but this is a large complex distributed system and there are many surface areas of attack, so codnevy uses a more complicated architecture to lock it all down.

[muhsinvp]

Thanks TylerJewell for the information

[muhsinvp]

Any open source alternative for Eclipse Che in which we can create workspace for multiple developers with authentication, as Che dashboard & workspace can be accessed by any developer without authentication...!!

[TylerJewell]

Your options:

1. Get Codenvy, and for qualified open source projects they have fair source licenses.
2. Run che as a VM farm, and manage it yourself.
3. Get involved with the project and provide your own extensions or running it behind a proxy.

[dcominottim]

Any news on this, @TylerJewell? It seemed like it should have been ready before the end of 2016. Is it still on the roadmap?

[TylerJewell]

This work has not been scheduled yet. The work to stabilize and release Che 5 was a lot more significant than we had anticipated. It was about two months delayed and even now we have about 50 clean up issues that we must undertake before we can call it as fully complete.

We have done investigations and have a list of open items that would have to be taken into consideration to make a localhost machines approach viable.

Before we can start upon this we want to finalize work that redhat started four months ago on an openshift connector. It bypasses docker to use kubenetes apis. So this port is giving us high confidence in that we can support multiple machine types and would make a localhost machines port faster.

[TylerJewell]

This is going to be partially supported in Che 6. We now allow for simple abstractions of different infrastructure. @gazarenkov has a prototype in a branch that uses localhost for runtimes instead of docker.

[siliconalchemy]

So is this available anywhere to start testing? Is 'master' Che 6?

[TylerJewell]

Check back in towards the end of the year. We should have something posted with instructions when we start making beta releases in a couple months.

[brendandburns]

Checking in on this. I'd live to run Che in Azure Container Instances (serverless containers) but Docker isn't available inside those containers.

[ghost]

@brendandburns the SPI is there in che6 branch, but there's no 'localhost/VM' implementation for it. Right now only Docker and OpenShift implementations are available.

[ChinoMars]

I'm wondering if CHE 6 will support running without Docker.

[ghost]

@ChinoMars no, there's no localhost implementation in Che6.

[loverdeg]

I'd like to have this so I can deploy form a workspace to embedded single board computers running linux.

• Debugging the deployed application running in the machine is a must have.
• Being able to build the application on the machine would be a nice to have.
• Mounting the devices file-system remotely would be nice too.

[ChinoMars]

@eivantsov I'm gonna work on this feature if u guys allow me to ^^

[summershrimp]

Also need the feature to run Che without Docker.

[rafaellago]

I would like to know if there is some news about this.

[piratos]

Was wondering the same but because of another need, I have a project that uses docker within the code base and as the provider is already a docker container that pushes me into a docker-on-docker hell ...

[piratos]

To answer my own thought, I changed my code to connect to the local docker daemon, thus instead of creating docker containers inside the workspace I connect to the docker that is running the workspace and create the container outside, cleanest solution I can find for the time being.

[eliasvasylenko]

Is this issue still the appropriate place to discuss this "localhost provider" concept? I want to toss a few more use-cases into the mix involving deployments onto/alongside specialized user-facing hardware.

• As a baseline example, the Android stack appears to require USB passthrough to the Che container for adb to discover connected phones for debugging.

• I work in mass spec, and sometimes we will hook a dev machine up to an instrument for rapid iteration or debugging. I want to be able to hit "run" in my IDE, and have it build and deploy all the necessary drivers and/or instrument control software, then launch the software and have it discover the instrument hardware. I assume this would require USB & PCI passthrough to the _launch_ container.

• Even something as simple as a desktop application which utilises the GPU is troublesome. A user may want to launch this locally, but to enable VGA passthrough to the deployment container they probably have to completely reconfigure their system, making the video card otherwise inaccessible.

It might not be compatible with the philosophy of purely portable workspaces, but then supporting local hardware is fundamentally incompatible with purely portable workspaces. There's no container you can spin up which hooks up a VR headset to the developer's machine or whatever they need.

Besides, the workspace is still mostly portable, developers can still code & run tests portably. Portability only needs to be broken at well-defined boundaries when attempting to launch against local resources which may not be present. I think this is a reasonable concession.

If the new Che workspace model for 7 wants to be all things to all people and truly general purpose (but maybe it doesn't and that's fine!) then I think these kinds of workflows should be considered.

[SantjagoCorkez]

Wow! 3 years old request at "work in progress, due to the end of the quarter" state. Still sticky to linux-only crap of toolset. Che is another project to be moved into kindergarden for disabled where Gnome and other 'udev'-onlies play with safe-proof and soft balls.

[skabashnyuk]

At this moment K8S/OpenShift platform is the fundamental part.