Rancher 1.6 is a widely used container orchestration platform that runs and manages Docker and Kubernetes in production. Cattle is the base orchestration engine for Rancher 1.6 that is being used by many opensource and enterprise setups.<\/p>\n
With the release of Rancher 2.0, we shifted from Cattle as the base orchestration platform to Kubernetes. As aptly noted here<\/a>, Rancher 2.0 aims at helping users align with the Kubernetes Everywhere<\/em> reality of the infrastructure and cloud domain.<\/p>\n However Rancher 2.0 differs from Rancher 1.6 because it brings in a new orchestration technology, Kubernetes. Currently, there is no straightforward upgrade path available between these versions.<\/p>\n So as a Rancher 1.6 user who\u2019s interested in moving to 2.0, what steps should you take?<\/p>\n In this article, I will provide a short checklist you can follow to do the migration:<\/p>\n Instructions for a Rancher 2.0 installation can be found in the Rancher Documentation<\/a>.<\/p>\n Note that the Docker versions currently supported by Rancher 2.0 are:<\/p>\n This list is per the validated Docker versions found under External Dependencies<\/a> in the Kubernetes upstream release.<\/p>\n For Kubernetes, Rancher currently uses the 1.10 version and is planning to go with the 1.11 version in the upcoming 2.0.7 release. Rancher will keep updating to the most-recent upstream Kubernetes releases.<\/p>\n For a basic single node dev installation, you would provision a single Linux host with Docker and install Rancher within a Docker container using the familiar docker run command, just like the Rancher 1.6 installation.<\/p>\n docker run -d –restart=unless-stopped For development environments, we recommend installing Rancher by running a single Docker container.<\/p>\n One difference from the 1.6 version is that Rancher now requires you to use SSL for security, so you need to provide a certificate during installation. If you don\u2019t provide a certificate, Rancher will generate a self-signed certificate for you. For all the certificate options, see here<\/a>.<\/p>\n Installing a High Availability Rancher setup is a lot different compared to 1.6. The steps are outlined here<\/a>.<\/p>\n Note that any existing automation that you have around a 1.6 Rancher Server in HA mode will need to be redone for 2.0.<\/p>\n If you have set up authentication with Rancher 1.6, you will be familiar with the array of auth providers supported.<\/p>\n With Rancher 2.0, all the above auth providers are still supported, and there are few new ones added to the set as well! Here is what the upcoming v2.0.7 authentication provider line up looks like:<\/p>\n The basic configuration requirements for setting up auth are still the same as 1.6. Look here<\/a> for detailed documentation about configuring every auth provider.<\/p>\n One difference to highlight is that in the Rancher 2.0 setup, local auth is always turned on<\/em>, even if you configure any other auth mechanism. This setting enables the Rancher admins to have a guaranteed access to the setup always!<\/p>\n After you have a running Rancher installation with your choice of authentication enabled, the next thing to do is create a Cluster and a Project under which workloads can be deployed.<\/p>\n In the Rancher 1.6 setup, after installation, you would create an environment<\/em> to which compute nodes could be added. In Rancher 2.0, you need to create a cluster and add the compute nodes to the cluster.<\/p>\n This is what the Cluster view looks like after it is setup. Within each cluster a Default project will be available.<\/p>\n The equivalent of a 1.6 Cattle environment is a 2.0 cluster with a project, for the following reasons:<\/p>\n This model of a cluster and a project allows for multi-tenancy because hosts are owned by the cluster, and the cluster can be further divided into multiple projects where users can manage their apps.<\/p>\n After adding a cluster and a project, the next step is to define any namespaces<\/em> used to group your application workloads. In Rancher 1.6, stacks<\/em> were created to group together the services belonging to your application. In 2.0, you need to create namespaces<\/em> for the same purpose. A default namespace will be available within the project, which is the namespace where workloads are deployed if one is not explicitly provided.<\/p>\n Just like 1.6, Rancher 2.0 supports service discovery within and across namespaces.<\/p>\n Once your Kubernetes cluster and a project are in place, the next step is to migrate the workloads.<\/p>\n You can follow the upcoming blog series<\/a> that talks about how you can do this migration using either the Rancher 2.0 UI or a conversion from Docker Compose config to Kubernetes YAML. It aims to explore various areas around workload deployment and their equivalent options available in Rancher 2.0.<\/li>\n Hope this migration checklist helps you get started!<\/p>\n Prachi Damle<\/p>\n Principal Software Engineer<\/p>\nChecklist for Migration<\/h2>\n
Installation<\/h3>\n
\n
\n-p 80:80 -p 443:443
\nrancher\/rancher:latest<\/p>\nConfigure Authentication<\/h3>\n
![\"Imgur\"](\"https:\/\/i.imgur.com\/VNm3tfv.png\")
<\/p>\n![\"Imgur\"](\"https:\/\/i.imgur.com\/o6ZBN3K.png\")
<\/p>\nAdd a Cluster and a Project<\/h3>\n
\n
![\"Imgur\"](\"https:\/\/i.imgur.com\/QQIj0An.png\")
<\/p>\n\n
Create Namespaces<\/h3>\n
![\"Imgur\"](\"https:\/\/i.imgur.com\/0FeHeth.png\")
<\/p>\nMigrate Apps<\/h3>\n
\n
![\"Prachi](\"https:\/\/rancher.com\/img\/bio\/prachi-damle.jpg\")
<\/p>\n