I am very excited about the possibilities of Rancher, even greater than the so expected Universal Control Plane by Docker. But anyway… is any of us still not amazed for the incredible things we can build using Docker and docker-related projects!!
Probably possible… Anything with a docker-compose shouldnt be too hard… nonetheless I’m not sure if the great devs would even get to finishing this… (or most of the functinoality)… Working on a full docker management/paas system (cattle/ranch), then also deciding do make a full OS (when there are a bunch already out there), then build xxx then yyy… i’m really sorry that rancher isnt just focused on being the de-facto tool for deploying, managing and monitoring conteinerized workloads… So many other things are coming and unfortunately they seem like they’ll eat up rancher due to its lack of focus… Its a pitty cause I really like rancher, but any project that strives to be “everything” usually ends up as nothing
I really hope the folks do get some more focus on what is really needed in the docker ecospace… So far I guess I’ll just turn to CLI tools like Deis or others, maybe with kubernetes for scheduling (since I dont want just “labels” for scheduling… having load-based scheduling is really crucial in any production workload)…
anyways, I’m still out looking… rancher has kinda let me down recently… too much intertwining with rancheros (whcih I dont see any benefit of), so I’m still looking for something “like rancher” but for coreos with better scheduling, etc… The concepts in rancher are great, the network volumes, snapshot ability and everything… but honestly, I feel its being hindered by just too many fronts… (OS, VMs, yadda yadda)…
@dalareo We’ve looked at doing this actually. The internals of our catalog implementation should make it quite simple. I believe we’ve had similar requests. I’ll let @vincent comment on how difficult this would be as it’s mostly a frontend feature. With all features requests though we do try to see if there enough users out there that want this.
@RVN_BR Sorry to hear you are so frustrated. As I commented in https://github.com/rancher/rancher/issues/3006, a good deal of your current issues are probably stemming from CoreOS Stable using Docker 1.8 and also that you need to setup CATTLE_AGENT_IP. Regarding focus, trust me we are focused. You’ve got to give us a little break here. Rancher (the software) has been around for about 1 year. We are relative late comers. CoreOS for example has been around almost 3 years https://web.archive.org/web/20130805052834/http://coreos.com/
We are very transparent in what we do, everything is open source. This is great and bad. You get to witness all our mess in real time. We are very open and saying that Rancher is still a beta product. We have plenty of customers in production, but for open source we have yet to declare a stable version. We are changing just too rapidly. What people are downloading right now of Rancher is basically our weekly development builds. Starting next year (meaning tomorrow) we are changing how we label releases. We are going to have more stable release that are release at more of a 1-2 month interval. This way we can keep our fast weekly iterations but not have users expect each week to be perfectly stable. Also we expect to release a 1.0 first half of next year.
We hope Rancher will become the defacto platform for managing containers, but please pardon our mess as we build it. We are close. In the meantime, I highly recommend you do try out other platforms. Other things that are close in functionality as Rancher would be Tectonic or Mesospheres’ DCOS. I’d love to hear why those products are better.
Grabbing the contents of the docker/rancher compose files is straightforward… There may be issues with GitHub rate limiting unauthenticated requests if not using our github auth integration… But I’m not sure if straight file gets even count against it.
Hi @ibuildthecloud thanks for your detailed response. I appologize if my “frustration” came out in a wrong way… I will try to comment below to make things clearer.
I agree 100%… your work is really remarkable in such a small period of time. And I guess its really my mistake about the coreos… nonetheless, I have had problems with 5 machines now running the git clone + vagrant up from your repo… The machines come up, but anything which tries to be run on it (be it a single container, such as a simple ubuntu image, or a catalog image, will all cause the entire cluster to fail… I’m pretty sure its a rancheros issue tho… it “looses” the network…)
When I speak of focus it is due to your team being developing so much (such as rancheros, when we have coreos, atomic, and a bunch of others doing “similar” docker-optimized OSs… But again, its just MY opinion… There are great OSs out there, do we really need another? (and I’m sure you guys have your 100 reasons for building yet another one, but still, from an end user, looking at what Rancher is shaping up to be, it really baffles me why you wouldnt focus 100% on rancher, and make it THE de facto standard tool…)
I do hope to… Mesosphere DCOS is a bit of a different league, although it could in theory become a competitor if rancher incorporates lots of its features (which I think is the way rancher is going), but still, in terms of what is available Rancher is one of the nicest “packages”… Giving us the access to bleeding edge releases is great (IMO), but it “requires” some sort of more detailed explanation (again, just imo)… Tectonic preview isnt even close to rancher imo… And I’m sure when Rancher starts incorporating more and more of the docker features, perhaps even integration with kubernetes, things will become even better for Rancher…
My sole gripe (and this is just one guys opinion…take it with 10 grains of salt please!!) is why the team doesnt focus on the major pain points in the docker deployment/orchestration/management which is RANCHER, and instead we see lots of development on the RancherOS side (which right now doesnt even work for any of the setups I tried…
I’m really into using Rancher with CoreOS… Rancher can and hpefully will become a “one-stop” way of connecting/clustiring OSs through the rancher agent, and managing them through the rancher-cli or webui…
I’ll go back to doing some tests using coreos alpha or beta, as stable isnt supported (I’d perhaps put a not abt that tho), and also am keeping away of rancheros as the current version just fails all the time and doesnt bring any benefits? (? unless I’ve not read some comaprison that shows the benefits of an entirely new OS?)
I really hope Rancher continues in its swift development pace, supporting more and more great technologies… I wouldnt be surprised if Rancher got swooped up by one of the big players soon, maybe even docker itself or coreos, but I - once again - dont see where rancheros will fit in… Rancher as a OS-agnostic clustering/management/orchestration/persistent storage management solution is “everything we need to get running on docker”… And the best is its, as I said, OS agnostic… just Add a host, BYOH, or whatever… No matter where the hosts or located, next door, in the same rack, or half way around the wold, it just WORKS… (in theory at least, for now :p) but still… Rancher is a hell of a product… I’d love to see more and more development!
You can’t really do this without UI changes, but like I said it’s fairly straightforward so I added it in for next release (https://github.com/vincent99/ui/commit/620b3bc0f5194c9e8dbfe701b02ff193ee8c10f4). It’s sort of limited usefulness because unlike Tutum where there’s just one central tutum.co, we don’t know where your Rancher install is, so the link has to point to your specific Rancher and is therefore not very useful to other people in a generic README.md.
So next release you can link to:
http://<your-rancher>/env/<environment id>/apps/stacks/add?githubRepo=<youruser>/<yourrepo> to pull docker-compose.yml and/or rancher-compose.yml from the root of that repo’s master branch.
githubRepo=<youruser>/<yourrepo>&githubBranch=<anotherBranch> to do the same with a different branch.
or
composeFiles=<https://any/base/url> to to the same with an arbitrary base URL that isn’t necessarily GitHub. The server must support SSL (if Rancher is behind SSL) and CORS (Access-Control-Allow-Origin: * header).
