Are you dropping the support of “cattle” environment from version 2.0?
Would it be possible to use rancher without kubernetes?
1 Like
We are in the process of adding a FAQ and one of the question it will address is this one. This is what I added in our release notes.
With 2.0, Rancher now bases its architecture and every cluster/environment on Kubernetes. While 1.0 already supported installing, operating, and managing Kubernetes environments, we’ve always felt that it did not mesh with the rest of the Rancher user experience. In 2.0, we remedied that. Not only do you get access to the native Kubernetes dashboard UI and kubectl, but now the Rancher UX (CLI, API, UI, and Docker compose) works directly on top of Kubernetes. Think of 2.0 as an enhanced add-on to the Kubernetes platform where you can continue to use all of the existing Rancher features you know and love, along with leveraging the rich Kubernetes ecosystem and rapid innovations.
To sum it up, we are definitely NOT getting rid of Cattle. In 2.0, this is now referred to as the Rancher UX (API, CLI, UI, Compose). In 1.6x, we created this to enhance Docker. In 2.0, we’ve kept this to enhance the k8s experience in our own way because our users love the UX we have created. The only difference is that behind the scenes, we will be leveraging k8s and creating pods. You, as Rancher users, will soon be able to leverage k8s innovations and their rich ecosystem. You will no longer be choosing a “Cattle” or “K8s” environment. They are one and the same going forward.
1 Like
@vincent correctly chided us for posting in the “about category” thread, so I’m moving my reply here.
I love the Rancher team for their technical chops in making Docker orchestration a a much simper affair than in any other environment… but marketing guru communicators they are not. Maybe that’s what I like about them. 
When we first heard the news about Rancher 2.0, we were panicking for the exact same reason. We tried Kubernetes with a very large scale proof of concept. We tried in GCP, in AWS, and in our own datacenter, but where did we land? With Rancher. Rancher just made more sense and made complex things simpler and “docker-like”. We’re not in production yet, but have invested heavily in Cattle, so when we saw the 2.0 plans saying “now it’s all Kubernetes”, our eyes went wide and I nearly threw my keyboard against the wall.
But, if I’m understanding things correctly, that’s not what’s happening. It’s still Rancher as we know it on the front end, the API, and the control mechanisms (docker-compose/rancher-compose/ rancher cli), but the underlying technology that’s deploying containers, handling networking, storage, etc.; that’s all Kubernetes.
Frankly, that’s not only “ok”, I think it’s great! From our point of view, this let’s the Rancher team focus on the things that made us select Rancher in the first place: the UX, API and control schemes are comprehensible and usable in ways that no other docker orchestrator are. Kubernetes on the other hand has a proven record with wide-scale adoption of it’s technical components. Best of both worlds!!
Re-read the second paragraph of the Announcement post (not just the first sentence):
With 2.0, Rancher now bases its architecture and every cluster/environment on Kubernetes. While 1.0 already supported installing, operating, and managing Kubernetes environments, we’ve always felt that it did not mesh with the rest of the Rancher user experience. In 2.0, we remedied that. Not only do you get access to the native Kubernetes dashboard UI and kubectl, but now the Rancher UX (CLI, API, UI, and Docker compose) works directly on top of Kubernetes. Think of 2.0 as an enhanced add-on to the Kubernetes platform where you can continue to use all of the existing Rancher features you know and love, along with leveraging the rich Kubernetes ecosystem and rapid innovations.
3 Likes
So I do have a question that seems to be related to this.
We went with Rancher instead of Kubernetes because Rancher was easier to deploy, use, and automate. I understand that this move to Kubernetes being made in 2.0 is probably the right one, and maybe even the only real long term choice for Rancher; however, I do worry that we’ll now be entering a situation where we need to become 1) experts on Rancher (UI, API, CLI, and constructs like Service, Stack, etc.), but ALSO, in order to actually leverage anything beyond the basics, 2) become experts on Kubernetes. That’s a lot. The eccentricities of Kubernetes are WHY we didn’t select it over Rancher/Cattle in the first place.
Am I wrong? I’m sure for some things we can probably get away with ignoring the fact that Kubernetes is sitting underneath Rancher now, but how far will that take us? If Rancher is a facade on top of Kubernetes, and we’re going to have to become Kubernetes experts, why not just go all in for Kubernetes without Rancher in front of it?
To summarize, 1) will we need to become proficient in Kubernetes to do anything beyond the basics, and 2) if that’s the case, what is Rancher bringing to the table that makes it worthwhile to become proficient in two systems; both Rancher and Kubernetes instead of “just” Kubernetes?
Hello, your answer is not “cristal clear” for me sorry. And because we have to do some strategic choices can you precise one or two things things like…
- cattle will still be available but it’ll be based on k8s instead but without changing the user experience, unless he wants to
- are custom catalogs available in 2.0 (with private registry)
- i’ve read that adding a new service to a running cattle (or k8s) stack will be available. Do you confirm ?
- will the “delete host and reinstall with the same name” issue be solved on 2.0 ?
Do you suggest we keep the 1.2/1.6 versions until you produce the full 2.0 version with tutorial on how to migrate…if you do not provide upgrades from those versions.
Best regards
@Matt_Welch I don’t think you’ll need to become proficient in both systems to get “beyond the basics.” Do you think current feature set of cattle in the 1.X line is beyond the basics? Because for starters, that’s what you’ll get without having to dive deeply into k8s.
And as we add new features to Rancher, we’ll continue to do so in a way that is true to Rancher’s core value of simple, practical, functional UX. Often, these may end up being features that are already available in k8s but aren’t very accessible to the end user because of their complexity. One great example is storage: k8s has a good, correct, and robust model for managing persistent storage for containers. But setting up and managing that can be cumbersome or confusing for both administrators and end users. So, Rancher can present and manage that in a way that makes it fast, simple, and accessible for everyone involved while still leveraging the robust primitives of k8s underneath.
The goal is that you do not have to know or care that kubernetes exists, unless you want to. As an analog, 1.x uses the docker remote api to launch containers, but you’re probably not an expert on it. All the existing UI, API, compose files, features, etc work the same way from the user’s perspective but create pods in k8s.
Yes.
There are some bugs in the preview with multiple environments but yes.
I have no idea what this means since you’ve always been able to add more services to a stack.
There is no issue here and it has nothing to do with k8s. Hosts are given a uuid on registration and that is used as their identifier because IP address, hostname, etc can all change. If you delete the host and want to reuse it as a new one you need to erase the uuid.
1.2 is very old. We suggest the latest stable version, which is 1.6.10 today. There is no upgrade to 2.0 preview today and you should definitely not run it for anything important.
There’s no automated upgrade/conversion today from Cattle on 1.6 to 2.0 k8s, but can you confirm that there will be?
1 Like
We will have some sort of migration path, with details to come later. The simple path is not really upgrading at all, but exporting compose files, setting up a new install and importing them.
An in-place upgrade is likely going to require stopping everything and re-deploying all the service’s containers to get them into k8s.
when you write “compose files”, do you mean both docker-compose and rancher-compose?
I do not see any reference to rancher-compose files in the 2.0 preview, you can create a stack from a docker-compose file, but what about the config set through rancher-compose files?
1.x always produces docker/rancher-compose files so that’s what you’d import into 2.0.
In 2.0 we default to generating a single combined compose.yml file because the number of people that actually care about giving the docker-compose file to vanilla docker compose is limited, and claiming to be a particular version of their format has become more and more problematic as they make new versions more swarm-specific and add or remove fields as it suits them for that.
So import (and catalog) supports combined, docker/rancher-compose, or kubernetes yaml files. And export will likely have an option to generate the separate files as in 1.x.
1 Like
let me rephrase that to check that I understood correctly:
- the “compose” file is a mix of the docker-compose and rancher-compose files, that may not be compatible with upstream docker-compose format (whatever the version)
- the export feature in rancher 2 preview already produces this mixed format
Am I right?
I have tested the new 2.0 Technical Preview and I love it. UX is much better and UI looks more cleaner. (which I like)
Although I still have one question about Cattle and possible migration steps.
We have Rancher 1.6.10 running in DTA on Cattle and planning to go into production. Is it still wise to use Cattle for orchestration or is it better to use K8s. (With migration in mind when we want to move to 2.0)
I’d like to build upon @rgruyters concern, as we are also looking to move to production with rancher 1.X
Will there be a straightforward merge tool, to combine docker/rancher compose into a 2.0 compatible format?
In reviewing some of our rancher-compose files, my main concern is the definition of external services that point to IPs or hostnames.
1 Like
funnily 
, that was going to be my next question :
are there specs/tools to combine existing compose files into the new supported format
2.0 supports importing the same thing 1.x supports exporting.
Conversion to a combined file is mostly just straightforward combining of the keys.
K8s in 1.x is pretty much entirely unrelated. It gives you raw kubernetes. 2.0 provides the same UX (ui, api, compose files) as Cattle in 1.x, but creates the underlying containers in k8s.
Rancher 2.0 is a very good approach!
Is there anything about how Rancher uses k8s behind the scenes the precludes using and managing the environment with native k8s tools as well? Asking because at times I like the simplicity of the rancher management layers but other times I need to test out the same commands I’d be running on a prod k8s cluster that doesn’t have Rancher surrounding it.
Thanks for the clarifications.
"multiple environments"
Of course using Rancher for us is meant to be for several environments. Hope you’ll solve those bugs. Good luck 
Adding a service to a running stack without stopping and deleting it and then change the compose files, is not possible actually (v1.6.5).
Will it be possible in 2.0 ?
About the “Removed host cannot be added again” issue…
For this a script to delete it from the DB will be a solution. I’ll look forward for it.
https://github.com/rancher/rancher/issues/5514