ability to use docker-compose.yml instead of docker file for dev environments

[draco2003]

_1 Upvote_ Our dev environment is a composition of a few different pieces so we use compose to orchestrate them when spinning up a new developers environment. Ideally che could support this configuration in the future (or does currently and i'm missing something in the docs?).

[TylerJewell]

Today you can manually launch additional containers. However we will have proper compose support where you can have a stack for a workspace defined by a type of compose file optimized for development by the end of q3. We have it working in our labs now in branches. We will be demoing it in a couple weeks. It will be awesome.

[garagatyi]

@draco2003 Can you share compose file of your project. I'm investigating which features of docker compose real projects use.

[draco2003]

Thanks for the quick response. Example being PHP container, that needs memcache container, and webpack nodejs container I'll see if i can get a sanitized real world compose file that would work outside our network.

[garagatyi]

Great. Thanks!

[seanlutner]

Hi there, I work with @draco2003 and am just stopping by to drop off the requested compose config.

docker-compose-test.yml.zip

[garagatyi]

Thanks

[roynasser]

+1 for this... we have nginx container, php-fpm container, data container (sourcecode), all separate...

Have you guys seen Rancher? I'd love to have che running on rancher to edit sourcode and immediately deploy on the rancher cluster itself... (btw rancher is compatible with swarm, kubernetes, a bunch of different technologies, and it employs docker "natively" almost, they arent special containers or anything... its really cool - full disclaimer I am a fan but have nothing to do with the project I just think it would be a nice fit)

[TylerJewell]

We are familiar with rancher but no one on the team hs tried an installation of it yet. If it accepts native containers and you can configure Che properties to access the right location of the docker daemon then no reason it shouldn't work out of the box. Though with Codenvy we have made about 1000 modifications to support running Che on a swarm cluster.

We hope to have a multi container compose like syntax available in q3. One option is to run Che with our compose syntax that we will ship and then when your code is committed to execute a deployment script with ansible which will also support the same identical syntax as Che. We will show a scenario in red hat's keynote on Monday on how development will work like this. Their annual conference is next week.

We would love for the community to start submitting pull requests on how to deploy Che for various tools like rancher, kube, and so forth. So if you want to run some tests and file issues we would like that.

[roynasser]

Hi @TylerJewell thanks for the info...

When you say "you can launch additional containers manually" could you elaborate on how that works? Woudl it be under the additional workspaces? Since we can only specify a dockerfle and not a dockercompose file, I'd like to understand if/how you can get these additional containers to communicate or interact with each other (I would guess volumes-from is out of the question :) )...

Anyways, I have been quite interested in rancher over other solutions because although it has a nice GUI it also has everything (actually even more than in the gui) in its CLI and API, so its very developer friendly... Also, it works great with docker-native tools, and is now supporting more and more orchestration options such as swarm and k8s...so I think it allows a "certain degree" of vendor freedom / doesnt lock you down too much... I regularly deploy docker-compose files with few or no modifications on a vanilla docker host and a rancher instance, for example... (so thats my addtl plug for rancher lol)...

Anyways, I'm going to look into how Che could work on top of rancher. I know that you can launch your own docker containers, and by adding a specific label to the container it will automatically be joined into the rancher environment (although now that I think of it I'm not sure how I'd add a label from Che if its not supporting a compose file or a docker run statement.... is there any other way you can think?)

I think you can get the docker daemon (and docker-machine and swarm) endpoints/daemon location open and access it potentially from che... I'm not sure how I'd set that up on the Che side tho... I'll do a bit more digging...

Another idea I've had is to perhaps just use the Che editor with some commands/etc to reload containers, and using -volumes-from or host mapping I'd get my files mapped ont the /projects directory... This would be of most use in development, but I'd basically start a dev environment within rancher, and start a che container with the /projects directory mounted/mapped to wherever I have my project files... I think this may work and be a simpler way to start at least...

And finally, I'm a little lost between the boundaries of what is Eclipse/Che and what is Codenvy/Che... I get it that there is a premium/paid/commercial version of Che by Codenvy which isnt available for download, right? (at least not on github - on github codenvy/che = eclipse/che)... and the documentation seems a little bit "intertwined" between the two... I'm just trying to understand... Is Che an editor with workspaces (i.e. containers you launch), and Codenvy/Che a multitenant Che with Authentication? (in broad terms... I know how much work goes into making something multitenant, etc...)... And is there a Che editor without the workspaces functionality? (Or is it possible to disable it?)

Just brainstorming what I could get going with Che and Rancher for our developers...esp if we want to hire people from around the world, for example, getting them on a large project with many microservices isnt trivial... having a cloud setup for everything is a nice idea...

[TylerJewell]

Hi Roy: saw the note and questions. I am at a conference and will get some proper answers soon.

[TylerJewell]

Hi. Sorry it took so long to respond. We had a busy week with the Red Hat conference. Also our support tickets have ballooned recently which a wonderful situation for us.

Right now, yes, volumes-from isn't a supported option. But we are working hard to have docker compose support baked into our workspace definition so that workspaces can be generated from a minimized version of the syntax optimized for dev workspaces. I really hope we ship that within a couple months.

Specific to adding more machines to a workspace today it can only be done through the rest API. We have made it a bit unfriendly to users by mandating API because we did not want to introduce a syntax that wasn't like compose. Also in the multi machine scenario today there is not network overlay but machines can talk to one another. So it is multi machine but it is not elegant.

RedHat is going to help us port Che to run on kubernetes. Codenvy runs on swarm. And we want Che to run natively on swarm and other orchestration engines. In order to make this work we have to make an improvement to our orchestration layer for workspaces. Today we have bound the workspace lifecycle events to the docker engine API (not the cli). In kube, rancher, or swarm scenarios these lifecycle events should be delegated to plugins that can translate them to the proper commands that can execute in the underlying container engine. Then it will be possible to write simple plugins that make Che run on different platforms more easily.

The challenge for Che is that Che itself is a container but then workspaces are themselves containers. We do not want docker in docker so we have Che delegate workspace events to the parent orchestrator so that workspaces are siblings of the Che server itself.

This abstraction and improvement work is starting immediately though no ETA. Though maybe with rancher Che can run on it without any modifications because of the way it supports docker engine?

As for Codenvy it is available for download at docs.codenvy.com. It is under a fair source five license so free for five users. The big differences between Che and Codenvy are that Codenvy supports multi user and elasticity with many tools for it operations staff to simplify resource management, security, and backup.

Though later this year we will move elasticity into Che and also provide a very simple form based multi user ability in Che too.

[roynasser]

Hi @TylerJewell Thanks a lot for the detailed explanation. I hope you had a good conference.

I understand well where you are coming from and what you are trying to tackle :) It seems to be a "common goal" for loads of projects... RedHat has their "interests" and I guess those may influence the direction of che, which can be good or bad, depending on what you use etc...

In our case we ar looking more for the editor functionality, than for something which replicates all or a part of a full orchestration suite (such as openstack, rancher, and many others)... Supporting multiple orchestration methods such as k8, swarm, etc is a good idea imo, (and its exactly the direction rancher took by starting with their orchestrator, and now supporting kubernetes, mesos, swarm, etc)... I do believe you should adhere to some standard in terms of "compose" files... Humbly I'd suggest docker-compose as thats what I use :p but in practice any sort of "recipe file"which is standard would be ok, but creating yet another standard is imho unneeded and will make adoption harder...

At this point I've spent some time getting Che up and running in a "persistant" way. I figured I could use just a blank workspace with GIT (as per the template) as a "developer" workspace, and edit the files on a host mapped folder which other containers would read from (Che itself and these managed by rancher), however despite setting the che.properties stuff as per the documentation I have been unable to get workspaces and projects to survive a restart... (The workspace and project files are still on the host, but it seems to loose the config...)

My idea was to try and mount multiple containers mapped to the same host directory in order to launch a dev environment and editor all together (in this scenario it would be limited to a single host), but could be expanded to multi host with gluster or similar...

I was actually able to make this work with cloud9. I mapped my sources to the directory configured and that worked... I was able to edit and see the alterations on the other containers already running. This worked both locally with a simple docker-compose, as well as on a rancher cluster with multiple hosts and gluster with the native docker filesystem support...

I think I'll stick with cloud9 and see how things work out for a little while... Its currently a "alpha" project, and I cant dedicate too much time to it... but the prospectus of integrating IDE with Orchestration environment is a cool one in my opinion... It opens lots of possibilities for remote devs, for small jobs offsite, etc...

I'll keep checking in tho as its a great project! My personal need however is for something more focused on the IDE, and less on orchestration... I looked at Ace, but thats just too barebones and would require all the filemanagement etc be developed from scratch... cloud9 is a little bit in the middle I guess.

[TylerJewell]

@RVN-BR - I would still encourage you to consider Che further. We will have a configuration of Che a little bit later this year that supports "localhost" machines, which is essentially making it operate just like Cloud9 SDK, which for what it is worth, is not open source. We are working with a couple different vendors who have asked for this requirement building products similar to yours of a high scale.

So you could start with some of the docker stuff today that is containerized, and then have the pure IDE part ready when we introduce those localhost machines a bit later.

[roynasser]

Hi @TylerJewell indeed I will still consider Che :) Like I said, I'll keep checking in, and really do hope you make it easier at some point to "uncouple" the IDE and Workspaces functionality...

Congrats anyways as che is a great project... Were we not already invested in native docker impleemntations, with multiple containers, etc, I could maybe make it fit...

I'm aware of the c9 license, which is one of the reasons i'm not really that into it... (were it a perfect fit for our needs, I'd have no problem with licensing it for commercial use)... Right now like I said its just an "alpha" and I'm doing it mostly in spare time as PoC...

I'm not really sure how I would use Che with the containerized "stuff" as you put it... Our basic service contains at least 2 containers (one for nginx & one for php5-fpm)... Arguably they could be together but it makes scaling less flexible and if I make a "single container" version just for use within Che, then it defeats the purpose of having the developers work on an environment very close to the real environment...

[TylerJewell]

Pull requests for docker compose syntax and support have been issued. We are going to merge them into the master branch as soon as 4.7 is released, which is in a couple days. 4.8 will be dedicated to embedded docker compose support.

[TylerJewell]

@RVN-BR @draco2003 @seanlutner - this has been released as part of 5.0.0-M1 release. There is a compose-file stack that is also included in the ready-to-go stacks. The product is very stable. Great work by @garagatyi to implement this over the past year.

[roynasser]

@TylerJewell Cool, I'm trying to test this but I dont see compose anywhere... I only have this under ready-to-go:

am I being blind? lol....

This is the command I used to run che... docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock -v /root/che:/home/user/che eclipse/che start

docker ps shows image as codenvy/che-server:latest. Do I need to force a different tag?

[TylerJewell]

You have to explicitly run the m1 version.

Set CHE_VERSION=5.0.0-M1

[roynasser]

Hi @TylerJewell I must be doing something dumb, I got a new ready-to-go stack, JAVA-MYSQL, but nothing for compose.... I tried searching for compose in stack library, in the previous version it would find a php stack with composer, now it doesnt find even that one (I guess that name or description or whole stack was changed - but thats irrelevant)... it appears it updated as I'm seeing different stacks, but no compose...

docker ps is showing che-server:5.0.0-M1

thanks!!

[TylerJewell]

That stack uses compose in the recipe. Launch it and you will see two machines created. We are working on docs that explain how to write custom compose stacks now.

[roynasser]

doh! sorry... I'm trying it out now :)

Cant wait to find out how to use our own compose files

[roynasser]

@TylerJewell Sorry if this is the wrong place, but I am getting a strange error all the time now...

I get Environment 'default' contains machine 'default' with invalid source location: 'stub' whenever I try to create any environment... I tried the M1 release, and also the nightly release... on both a PHP and a blank workspace... I tried clearing up all the images and containers on the server, running with most basic commands

docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock -e CHE_HOSTNAME=xxxxxxx eclipse/che start

Only added che_hostname as I need access from the external ip of the server.... I get to the empty che workspace, but anything I try to create brings m to this... any ideas? Couldnt find an issue or anything on the web referring to this.... docker logs dont look out of the ordinary in my newbie eyes...? Something i did could have "broken" it? docker-machine ls doesnt show anything running... very weird? or am I just blind and dumb? lol

2016-09-23 19:01:51,137[main]             [INFO ] [o.a.c.s.VersionLoggerListener 89]    - Server version:        Apache Tomcat/8.0.32
2016-09-23 19:01:51,141[main]             [INFO ] [o.a.c.s.VersionLoggerListener 91]    - Server built:          Feb 2 2016 19:34:53 UTC
2016-09-23 19:01:51,142[main]             [INFO ] [o.a.c.s.VersionLoggerListener 93]    - Server number:         8.0.32.0
2016-09-23 19:01:51,143[main]             [INFO ] [o.a.c.s.VersionLoggerListener 95]    - OS Name:               Linux
2016-09-23 19:01:51,143[main]             [INFO ] [o.a.c.s.VersionLoggerListener 97]    - OS Version:            4.5.7-docker-4
2016-09-23 19:01:51,144[main]             [INFO ] [o.a.c.s.VersionLoggerListener 99]    - Architecture:          amd64
2016-09-23 19:01:51,145[main]             [INFO ] [o.a.c.s.VersionLoggerListener 101]   - Java Home:             /usr/lib/jvm/java-1.8-openjdk/jre
2016-09-23 19:01:51,146[main]             [INFO ] [o.a.c.s.VersionLoggerListener 103]   - JVM Version:           1.8.0_92-internal-alpine-r1-b14
2016-09-23 19:01:51,147[main]             [INFO ] [o.a.c.s.VersionLoggerListener 105]   - JVM Vendor:            Oracle Corporation
2016-09-23 19:01:51,148[main]             [INFO ] [o.a.c.s.VersionLoggerListener 107]   - CATALINA_BASE:         /home/user/che/tomcat
2016-09-23 19:01:51,148[main]             [INFO ] [o.a.c.s.VersionLoggerListener 109]   - CATALINA_HOME:         /home/user/che/tomcat
2016-09-23 19:01:51,149[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Djava.util.logging.config.file=/home/user/che/tomcat/conf/logging.properties
2016-09-23 19:01:51,150[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
2016-09-23 19:01:51,151[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Xms256m
2016-09-23 19:01:51,151[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Xmx1024m
2016-09-23 19:01:51,152[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Djava.security.egd=file:/dev/./urandom
2016-09-23 19:01:51,153[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dport.http=8080
2016-09-23 19:01:51,153[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dche.home=/home/user/che
2016-09-23 19:01:51,154[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dche.logs.dir=/home/user/che/tomcat/logs/
2016-09-23 19:01:51,154[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dche.logs.level=INFO
2016-09-23 19:01:51,155[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dcom.sun.management.jmxremote
2016-09-23 19:01:51,156[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dcom.sun.management.jmxremote.ssl=false
2016-09-23 19:01:51,156[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dcom.sun.management.jmxremote.authenticate=false
2016-09-23 19:01:51,157[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dche.local.conf.dir=/home/user/che/conf/
2016-09-23 19:01:51,157[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Djava.endorsed.dirs=/home/user/che/tomcat/endorsed
2016-09-23 19:01:51,158[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dcatalina.base=/home/user/che/tomcat
2016-09-23 19:01:51,158[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Dcatalina.home=/home/user/che/tomcat
2016-09-23 19:01:51,159[main]             [INFO ] [o.a.c.s.VersionLoggerListener 115]   - Command line argument: -Djava.io.tmpdir=/home/user/che/tomcat/temp
2016-09-23 19:01:51,354[main]             [INFO ] [o.a.c.http11.Http11NioProtocol 425]  - Initializing ProtocolHandler ["http-nio-8080"]
2016-09-23 19:01:51,381[main]             [INFO ] [o.a.t.util.net.NioSelectorPool 72]   - Using a shared selector for servlet write/read
2016-09-23 19:01:51,386[main]             [INFO ] [o.a.catalina.startup.Catalina 591]   - Initialization processed in 873 ms
2016-09-23 19:01:51,571[main]             [INFO ] [c.m.JmxRemoteLifecycleListener 332]  - The JMX Remote Listener has configured the registry on port 32001 and the server on port 32101 for the Platform server
2016-09-23 19:01:51,572[main]             [INFO ] [o.a.c.core.StandardService 435]      - Starting service Catalina
2016-09-23 19:01:51,572[main]             [INFO ] [o.a.c.core.StandardEngine 259]       - Starting Servlet Engine: Apache Tomcat/8.0.32
2016-09-23 19:01:51,734[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 910]        - Deploying web application archive /home/user/che/tomcat/webapps/ROOT.war
2016-09-23 19:01:54,084[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 974]        - Deployment of web application archive /home/user/che/tomcat/webapps/ROOT.war has finished in 2,349 ms
2016-09-23 19:01:54,088[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 910]        - Deploying web application archive /home/user/che/tomcat/webapps/wsmaster.war
2016-09-23 19:01:58,557[ost-startStop-1]  [WARN ] [p.DockerExtConfBindingProvider 51]   - DockerExtConfBindingProvider
2016-09-23 19:02:01,428[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 974]        - Deployment of web application archive /home/user/che/tomcat/webapps/wsmaster.war has finished in 7,340 ms
2016-09-23 19:02:01,429[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 910]        - Deploying web application archive /home/user/che/tomcat/webapps/dashboard.war
2016-09-23 19:02:02,049[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 974]        - Deployment of web application archive /home/user/che/tomcat/webapps/dashboard.war has finished in 620 ms
2016-09-23 19:02:02,051[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 910]        - Deploying web application archive /home/user/che/tomcat/webapps/swagger.war
2016-09-23 19:02:02,226[ost-startStop-1]  [INFO ] [o.a.c.startup.HostConfig 974]        - Deployment of web application archive /home/user/che/tomcat/webapps/swagger.war has finished in 175 ms
2016-09-23 19:02:02,235[main]             [INFO ] [o.a.c.http11.Http11NioProtocol 470]  - Starting ProtocolHandler ["http-nio-8080"]
2016-09-23 19:02:02,248[main]             [INFO ] [o.a.catalina.startup.Catalina 642]   - Server startup in 10860 ms

(If this is indeed a real issue feel free to move it, but I'm unsure...)

[TylerJewell]

set CHE_HOST_IP, not CHE_HOSTNAME if you want external users to access your workspaces. CHE_HOSTNAME Is for limited scenarios.

Also - really recommend you use the CLI as it helps manage cross-OS dependencies and makes it a lot easier to set / remove environment variables.

[roynasser]

Hmm that was dumb.... But I know why it happened... your two pages that list the env variables have CHE_HOST_IP and CHE_HOSTNAME in different orders... I randomly hit the wrong one and I remembered it was one of the top parameters I had to chenge... doh...

I will look into the CLI soon... thought the docker was the recommended way for a quick and dirty trial run...

thanks anyways

vs

Should teach me to be less visual and more read-ual lol... thanks! feel free to delete these posts as it doesnt really pertain to anyhing useful lol