search

CodeboxIDE / codebox

Open source cloud & desktop IDE
https://www.codebox.io
Apache License 2.0
4.11k stars 590 forks source link

What happened to codebox? #518

Open jhnlsn opened 8 years ago

jhnlsn commented 8 years ago

Does anyone know if this is being maintained anymore?

TylerJewell commented 8 years ago

They sold the assets to a commercial company, but have not been maintaining it. You may want to look at some other open source projects like Eclipse Che - www.eclipse.org/che.

Addvilz commented 8 years ago

Meh... I loved this project....

pspchucky commented 8 years ago

Similar to service codebox https://c9.io/

Compile the SDK for similar use as codebox https://github.com/c9/core/

mateothegreat commented 8 years ago

I've been pilot'ing eclipse che (codenvy) and I've come to the conclusion that (for now) it is not anywhere close to supporting web development. The workspace server & environment management that che brings is awesome but the IDE is way behind. Codebox is by far superior by just toy'ing around. Unfortunately the eclipse che "ide" is extendable only by java based extensions..

TylerJewell commented 8 years ago

@mateothegreat - Thanks for the feedback.

The goals are certainly different between the projects. The bulk of the engineering is in the workspace management and the encapsulation of the runtimes inside the workspace, and then making that extensible with templates, stacks, recipes, and the so forth. We'll be announcing with Red Hat on Monday the support for compose workspaces, a way to have the internal workspace structured according to compose orchestration.

As for the IDE, it's not really behind as much as having a different intention. It follows an extensbility pattern similar to the Eclipse IDE, so the richness of customization for plugins is higher, but with some added complexity. There will be things to simplify that over time. And SAP has written a JavaScript IDE that makes use of Che already, so Che's IDE is not the exclusive one, for example.

roynasser commented 8 years ago

I wonder if no forks are still in development... I'm actively looking for an "IDE only" cloud ide... I already have a production cluster to which I deploy, and I already have a very similar development structure (where each dev has their environment in a hosted fashion). Adding a cloud ide to the development structure would be nice for us... I investigated with che but was unable to get it working... c9 worked but I wasnt overly impressed (gonna use it a few days)... gonna give this a whirl too... if the IDE is better as some ppl imply we might adopt this and fork it off if there are any bugs etc...

TylerJewell commented 8 years ago

To be clear - Dan's point about Eclipse Che was that the product works, but is not deployable in the specific type of configuration that is needed, which is a pure play thin client that can delegate the runtime orchestration to a pre-existing system, like Rancher or Kubernetes. This is not an architecture Che supports today - so Dan's options are Codebox, C9, a plain ole editor like Orion / Ace / Codemirror, or wait for Che to provide this type of support by the end of the year, which is on the roadmap. Codebox would probably be a good solution for him if there is a maintained branch.

aaronbartell commented 7 years ago

Consider noide.

mateothegreat commented 7 years ago

@TylerJewell apologies if I came off flaming che.. I'd edit the comment if it could ... eclipse che is hands down the best the community has when combined with codenvy's docker images. I've been burning & turning through testing and have a local dev env. click -> install -> run for your entire stack ready for google & aws (or any docker host, just need the ram to keep the JVM from OOM'ing). I have my blog post 2/3 complete with a video + screen capture to get the newbies up and running and lower the barrier of entry.

To be fair, the things that are currently "missing" in che are not blockers, I've overcome things by common practices (running typescript compiler in watch mode in a background process, etc..).

So what I'm delivering is an automated installation process (using straight bash over curl/ssh or preferably saltstack) that will allow you to decouple che from the workspace services and the option to have disparate docker servers with open slots in different locations (I'm about a week out from testing being complete). SaltStack is doing the heavy lifting and gives durability & fault tolerance for the bash->tomcat hiccups heh.

I'll ping you when I get my rough draft post complete .. thanks for your commitment to the community!

P.S.: I hope at least 50% of that made sense, I pulled an all-nighter :1234:

mateothegreat commented 7 years ago

@RVN-BR It took me several days to get my mind wrapped around eclipse che before I was able to get things up and running smooth. That was a couple of months before their latest release which solved a lot of minor problems that makes you want to give up lol.

One thing that I will note (which I recently came across over the past few weeks) is that running the current version of Docker on Ubuntu or Debian and having an internal network interface that is NAT'ed to the outside world (as if you were running docker on a vm in aws or google cloud or behind a vpc for instance) you're going to run into a bug that will prevent you from receiving traffic on the --host=0.0.0.0 (or the any/all) public network interface. I was able to come up with a workaround just to validate my findings but it is wayyy too hack'ish so there are a couple of docker issues open.

Until then, getting things up and running on CentOS (if you're doing the complete install on the same box) will work like a charm. The only gotcha is updating the che configuration file to specify the public host/ip if you're NAT'ed.

Feel free to reach out if you need a hand! Ping me on skype @appsoa or lenixx@gmail.com on hangouts -- I could use the extra testing!

mateothegreat commented 7 years ago

@aaronbartell Cloud9 is probably as far out as I would go to have the minimum level of functionality & stability I'd need for daily use. Thanks for the recommendation .. I'll add it to the awesome-cloudide repo :dancer:

@pspchucky Getting c9 running from the core repo can be hit & miss.. I'd recommend this dockerfile: https://github.com/kdelfour/cloud9-docker .. 2 minutes and no segfaults I promise! Now if you want a one-command c9 in-a-nutshell have a look at my repo https://github.com/mateothegreat/devops-devqa-studio. You'll get c9 up and running with a node.js & typescript ready dev environment ready to roll. (wip)

aaronbartell commented 7 years ago

I'll add it to the awesome-cloudide repo

@mateothegreat I couldn't tell if you were being facetious or not, does such a repo actually exist? If so, I have a few more to add. I googled and couldn't find anything.

TylerJewell commented 7 years ago

@mateothegreat - oh I didn't think there was any kind of flaming going on. Just an intellectual discourse. But I am mindful that a large portion of the people who read GitHub pages probably have English as a second language, so just wanted to point out what your language meant.

One other thing that is going to happen with Che - we are simplifying the entire setup process to just be docker run eclipse/che [options]. You'd be surprised at how much infrastructure goes into simplifying something to that degree. I expect it will be merged in within a couple weeks. So pretty much any system running docker will have Che run properly. And it will run with root access, too. I can link in the tracking issue on this if anyone is interested.

mateothegreat commented 7 years ago

@TylerJewell link me up! I'd like to see how ya'll tackled those two issues. (I just happened to have a SaltStack deployment so I have SOA to do my manual labor lol)

mateothegreat commented 7 years ago

@aaronbartell I just couldn't remember the exact urls :)

There is https://github.com/sindresorhus/awesome#development-environment (the list needs some sprucing up and a separate section for software that is an IDE specifically.. but it is by far one of the biggest lists.

and then there is http://slant.co .. I really like how much content their community creates and the relational mapping is almost great. Check out http://www.slant.co/tags/development?filter=top to get started. I don't really depend on their reviews or comments really. I use it mainly to compile target hit lists for the technology evaluation & selection phase when I'm creating a reference architecture for a project or client. I actually created a web-crawler and light scraper using distributed clients via SaltStack and store all of my data dumps in elasticache as far as getting trending apps that people are paying $ for, trending opensource specifications, technology patterns, & so forth. But that should get you started along with ProductHunt for sure (https://www.producthunt.com/topics/developer-tools). Let me know if you need any help!

TylerJewell commented 7 years ago

@mateothegreat - check out this tracking PR for a bunch of work that we are doing. I just tried a sample of it and this syntax works on linux, mac and windows (whether moby or boot2docker):

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock mariolet/che-launcher [option]

https://github.com/eclipse/che/pull/1683

This is a docker container, which in turn takes a configuration definition and then launches the Che server as another container with the proper configuration. It should dramatically simplify getting started.

roynasser commented 7 years ago

Thanks for the comments guys,...

@aaronbartell Unfortunately noide seems a bit skimpish... codebox may work with some plugins...

@mateothegreat I'd like to see what you have done in terms of "uncoupling" the che environments... I'd basically like to use che to control rancher... Ideally I guess it would be cook to have "controls" into che where I can see or embed certain commands from other systems (like rancher, docker, tutum, heroku, carina, or others...)...

I'm a bit "sad" that most of the development is geared towards workspaces and recipes, which isnt really anything that has a "grand purpose" imho... But it probably makes sense within the RedHat vision and roadmap, so I fully understand the motivation... however as we see more and more "standardization" around docker and kubernetes, etc, it would be great to find a project that basically fuses "che editor" with "standard" (or at least as standardable as possible) devops environemtns...

I can totally see the simplicity of getting a che workspace up, using that for development, etc... but time to go to production and you are on your own.... Or at least you need to do all the translating of recipe to docker file, stack to compose, workspace to whatever the correlative term is...

Not to be repetitive but I like that Rancher doesnt "hide" docker or k8... They propose to work "within" the chosen architecture... and although it may not be so friednly if I'm a docker user wanting to go to a k8 envirnoent (services arent services, they are pods, etc), I think that the mass of people regularly going back and forth isnt really going to be that great... so I fail to see the big gain in abstracting the standards into a "new standard"...

Anyways, @mateothegreat I'd be really keen to see what you have done in terms of decoupling... my idea is to have che run as a container with the volume mapped from another location (shared by the existing containers)...

Basically lets say I have a docker setup with a single container which is my website (lets ignore that a real exaple probably have 5 or more services including a queue system, workers, db server(s), redis instances etc)... Lets just say I have a single container.

In production its as simple as deploying a docker-compose (with the arguments and settings for the container)... Using swarm or other (I control through rancher in my case, but anything else including ucp would work)...

In this example, I can get the same Docker file and compose, and ideally just add a che container, and if I have a container that already includes a "blank" workspace - or no workspace, and mapping the volumes correctly I could "edit files" from che and have them immediately show up on the webserver container... It would be the exact same container as production, what could change is a git branch that is pulled during build for example, and a che container running with a vlume mapped to the website html directory... I could (ideally) use the che terminal and perhaps a nicer gui even to integrate che with our git workflow, and so forht... but I wouldnt need to make "recipes" or anything else... the same container runs production and development, etc... There achieving "single infrastructure" and ending the age old proverbial stone in the show of devXops ops: "the environments are the same" dev: are you sure? im gettig a weird behavior ops: "sure, oh wait... ops, wait, forgot one thing... now they are the same - i'm sure...actually, I think...hmmmm".... #fail lol... (btw: this is where I'm at right now and tackling this is big on my priorities...)

Just in closing, we (I) have seen tons of different efforts at this.... From Stackato, to Openshift, to Vagrant, to Heroku, Mesos(phere) and their frameworks, to Cloudfoundry, to [insert whatever paas/iaas/devops product you want]... even puppet and chef have their uses and disservices in this space... but one thing is for sure... Dockerfiles, Containers (Docker or otherwise), and docker-compose stacks are here to stay... perhaps to be joined by some other...

but Cookbooks, Recipes, Stacks, "Applications", "Backing Resources", Vagrantfiles, etc, whatever you want to call other "infrastructure" or "infrastructure+software" definition files are just beating a dead horse imo... As a user I'm focusing on going "mainstream"... I dont want vendor lockin and I want something actively developed etc... as a developer I'd be looking at "allying myself" with strong standards and improving where improvement is needed. in summary, if I were building a colored wheel, I'd get a wheel and paint it instead of trying to re-engineer the wheel and then paint it and then try and get everyone to use my new non-standard wheel just cause its a new color....sooner or later someone is gonna start painting the standard wheels and i'm sol :p

Anyways, I digress... I understand RH is a stakeholder in che... hopefully they will see that docker support and not an abstraction of docker with yet another standard is the way the market goes... Initially they had their own sort of recipes etc, and now they are moving/moved to support containers...perhaps late to the container party, but nonetheless, the standard was up for grabs and for some reasons docker came out ahead...its good that redhat at least saw that and didnt insist on another standard

TylerJewell commented 7 years ago

@RVN-BR - I think your concern in Che is two parts: 1: The workspace definition in che mandates an included runtime, like a container. And so for any situations where you just want the lightweight IDE / editor (like Codebox does), then those use cases are not handled. Before the end of Q3, we'll be supporting localhost machines, which is just our way of allowing the IDE part to be used without a runtime (ie, whatever is on the underlying host).

2: The fact that our workspace "runtimes" need to be modified into stacks. Our runtimes are Dockerfiles, but you have to add in some other stuff that lets us do SSH, debugging, intellisense, terminal, etc. This is not a forever thing. Probably before the end of the year, all of this will be abstracted out into a generic format called an agent. We will inject agents into workspace runtimes after they are started. This will allow Che workspaces to be defined by any off-the-shelf Dockerfile without customizations. We will then quietly add in the stuff we need and let users remove agents they do not want. Also, extension developers can provide their own agents in a packaged format. Git and subversion utilities, for example, will be packaged as agents.

Also, we will support docker compose format for a workspace definition very shortly. So that will be cool - a single workspace for coding, but backed by a compose definition of multiple containers.

Che published roadmap: https://github.com/eclipse/che/wiki/Roadmap

roynasser commented 7 years ago

Hey @TylerJewell That sounds great!

Thanks for reading through my entire bible btw lol...

1 - regarding this item, its more or less what I am looking for... What would work for me, however, and I'm going to give this more of a try, is to have the workspace/container/whatever we call it, as the "developer machine" workspace... That can be used to run git commands, eventually CLI tools that aid development etc... All the while the other containers are running normally... If we have the workspace "html" file as a shared volume, then there isnt really need to access the remote container I believe... I actually tested this using 2 different cases, a single machine using volumes-from in order to have the webserver reading and che writign to the same directory... and I also used this in a gluster+convoy environment in a rancher cluster, where I have 1 che container writing to a network persistent volume (transparent to che), and the webservers reading from the same volume... so thats pretty good!

I kinda hicced up when trying to "maintain" workspaces... Basically whenever I reloaded che it would come up blank and looking for the files in another project location based on the project name... If I can just find a way to lock the configurations it may be as simple as that... I can then have rancher-compose cli tool in the che workspace, and use that to send any required commands to the rancher cluster (or docker-machine to control a swarm cluster)...

It may be simpler than I thought :) I'm going to try these. Initially I had problems getting the che directory into mapped volumes, etc, and it was erroring out about not accessing, not finding,e tc... I'll ry some more, but ideally if I can get a "snapshot" configuration that just loads a constant file location, etc, it would be ok... I actually like having the "developer machine" as a workspace... and not have them working "within the container"...it makes more sense for me and it prevents things from being done in a container shell for example.

2 - Good going... I'm not so sure what the agent does, but in any case, supporting docker-compose to a swarm cluster would be nice... Supporting "external launchers" of docker-compose would be rad too :p (although I suppose its a bit of a far feth)

TylerJewell commented 7 years ago

You might want to check out this new launcher approach that really simplifies how you start & configure che for a variety of scenarios. It's not entirely live yet as 4.5.0 is going through release cycle right now, but it gives a good idea of what is happening.

https://eclipse-che.readme.io/docs/usage-docker-launcher

wernight commented 7 years ago

For those looking at Che, how can you use it given it currently exposes SSH (may be they fixed that one) and also tons of other HTTP ports without authentication? https://github.com/eclipse/che/issues/1560 Currently it means for me that unless I VPN to Che, there is no way to have any authentication. It also means due to the random ports that it's hard to impossible to run on Kubernetes but that's another story.

TylerJewell commented 7 years ago
  1. Workspaces with SSH are now packaged as agents which can be enabled / disabled in the dashboard. It's part of the 5.0 release. There will also be shortly some smarts about SSH agents which automatically setup public / private keys, and randomize passwords for SSH.
  2. We are going to limit the ports of communication betwen Che & the well-known agents down to a single port. But it will not likely ever be possible to restrict the ephemeral port range. Think of a scenario where you launch a workspace, and the developer has development access to the workspace. That developer could launch 1 server, or n servers. Each of those servers are going to require a whole series of ports internally and then those ports have to be mapped externally. If you have two workspaces on the same docker daemon, and those two users each launch a server on port "80" then, the host has to map each of those to different ports so that there is no conflict.
  3. We will provide an SPI that lets vendors replace our docker implementation with other providers - so that when workspace runtimes are created, they can be created using an OpenShift API or maybe a kubernetes API. It could then be possible to distribute workspaces into orchestration services which bind virtual IPs and DNS names, which can then have a more limited port range.

But we have no plans to put authentication into Che at its core level. It would add a lot of complexity to the che architecture, which we have baked into Codenvy. Authentication must be enforced at che server level, the file system of each che workspace, and within each of the agents that are deployed in each workspace. It's a big surface area of attack, and it requires reverse proxy to sit in front of the architecture along with a backing user database.

So for now we leave that in Codenvy, and that is how we make money right now. We cannot put everything into the open source domain, otherwise we will not be able to afford to keep writing such great software. We will have a version of codenvy by the end of the year that is deployable as a set of docker containers using docker compose up, and we'll make it possible to switch betwen che vs. codenvy easily.

wernight commented 7 years ago

Thanks for the update. The plan sounds good. Reverse proxy to add authentication is what I was also planning to do, and ports opened while developing a server are normal but they are not "random" per say (actually quite often people stick to port 8080). So also no issues here. Point 2 is really the critical one for me.

I'm experimenting right now actually doing a proxy using SPDY which together with SwitchySharp extension allows automatic authentication and may also work with the various ports without forcing that proxy for other websites (work in progress / untested).

wernight commented 7 years ago

Hourray! It's working. So I got Che working on Kubernetes behind a SPDY Proxy. It's still a bit rough for the end user as you need a plugin, and very rough on Kubernetes as you cannot setup port ranges and other things so I need to see how to support it none the less for all port ranges.

TylerJewell commented 7 years ago

Cool!

l0rd commented 7 years ago

@wernight can you provide us more informations on what you did? What is the plugin? Have you used k8s API?

wernight commented 7 years ago

One Pod running wernight/spdyproxy with a LoadBalancer pointing to it. That one does encryption and authentication. I've set a PAC Script like:

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, "che")) {
    return "HTTPS che.example.com:44300";
  }

  return "DIRECT";
}

So for https://che/ it'll resolve it from within the cluster. Now it the only tricky part for which I'm not yet satisfied: Resolving che to a Pod running:

For that I've created a Service (not a LoadBalancer) named che listening to many ports (yes manually listing the first ports after 32768, and also port 80 for the main HTML page.

Last important thing, che-server env DOCKER_HOST=tcp://localhost:2375 so that it uses docker:dind. Why not mount the host docker? First and mostly because this way it's possible to resolve che to that container and also because I think it's a lot cleaner.

Of course still need to mount other volumes on these two containers for che-server to work (else it'll say that it could find ws-agent.zip or such):

      volumeMounts:
        - name: lib-vol
          mountPath: /home/user/che/lib-copy
        - name: workspaces-vol
          mountPath: /home/user/che/workspaces
        - name: storage-vol
          mountPath: /home/user/che/storage

I'll probably set up a repository with an example kubernetes.yml doing all this and more (like setting up TLS automatically).

TylerJewell commented 7 years ago

Did you rebuild the che-server Docker image to inherit from alpine's dind image? We had tried that a couple times and ran into some problems with it during workspace generation. But we haven't tested it in awhile.

wernight commented 7 years ago

No I didnt need to. Here is an example set up https://github.com/wernight/kubernetes-che

TylerJewell commented 7 years ago

So - can you walk me through one part of your Kubernetes configuration. I see that in the bottom part, you have two containers to define the che service: che & docker-dind. I get the che container. This is just reusing our che-server container AND changing the DOCKER_HOST to use the local Docker daemon underneath kubernetes. This configuration allows the Che server to use the DOCKER_HOST to generat new workspace containers.

But what is the docker-dind container doing? It's got some similar volume mounts as the che container. But I am not getting the connection of what the dind is doing for the overall system. If you can explain this part, then it will all connect for me.

wernight commented 7 years ago

The down side is that it's slower.

wernight commented 7 years ago

I forgot that it's also necessary to mount the volumes properly, especially if you want to persist changes.

cyberwillis commented 5 years ago

Similar to service codebox https://c9.io/

Compile the SDK for similar use as codebox https://github.com/c9/core/

This changed my life ! Thank you @pspchucky