关注微信公众号
第一手干货与资讯
加入官方微信群
获取免费技术支持
Update: This tutorial was updated for Rancher 2.x in 2019 here
Any time an organization, team or developer adopts a new platform, there are certain challenges during the setup and configuration process. Often installations have to be restarted from scratch and workloads are lost. This leaves adopters apprehensive about moving forward with new technologies. The cost, risk and effort are too great in the business of today. With Rancher, we’ve established a clear container installation and upgrade path so no work is thrown away. Facilitating a smooth upgrade path is key to mitigating against risk and increasing costs. This guide has two goals:
With that in mind, we’re going to walk through the set-up of Rancher Server in each of the following scenarios, with each step upgrading from the previous one:
A working knowledge of Docker is assumed. For this guide, you’ll need one or two Linux virtual machines with the Docker engine installed and an available MySQL database server. All virtual machines need to be able to talk to each other, so be mindful of any restrictions you have in a cloud environment (AWS, GCP, Digital Ocean etc.). Detailed documentation is located here.
**
You should see the Rancher UI with the welcome modal: Since this is our initial set up, we need to add a host to our Rancher environment:
This newly-updated, in-depth guidebook provides a detailed overview of the features and functionality of the new Rancher: an open-source enterprise Kubernetes platform.
So, what’s going on here? The rancher-agent-bootstrap container runs once to get the rancher-agent up and running then stops (notice the red circle indicating a stopped container). As we can see above, the health check container is starting up. Once all infrastructure containers are up and running on the host you’ll see this:
Here we see all infrastructure containers (health check, scheduler, metadata, network manager, IPsec, and cni-driver) are all up and running on the host.
Tip: to view only user containers, uncheck ‘Show System’ in the top right corner of the Host view. Congratulations! You’ve set up a Rancher Server in a single container. Rancher is up and running and has a local MySQL database running inside of the container. You can add items from the catalog, deploy your own containers etc. As long as you don’t delete the rancher/server container, any changes you make to the environment will be preserved as we go to our next step.
Now we’re going to take our existing Rancher server and upgrade it to use a bind-mounted volume for the database. This way, should the container die when we upgrade to a later version of Rancher, we don’t lose the data for what we’ve built. In our next steps, we’re going to stop the rancher-server container, externalize the data to the host, then start a new instance of the container using the bind-mounted volume. Detailed documentation is located here.
As we head toward an HA set up, we need have Rancher server running with an external database. Currently, if anything happens to our host, we could lose the data supporting the Rancher workloads. We’re going to launch our Rancher server with an external database. We don’t want to disturb our current set up or workloads so we’ll have to export our data, import into a proper MySQL or MySQL compliant database and restart our Rancher server that points to our external database with our data in it.
database.
Congrats! You’re now running Rancher server with an external database and your workloads are preserved.
Now it’s time to configure our Rancher server for High Availability. Running Rancher server in High Availability (HA) is as easy as running Rancher server using an external database, exposing an additional port, and adding in an additional argument to the command so that the servers can find each other. 1. Be sure that port 9345 is open between the Rancher server host and any other hosts we want to add to the cluster. Also, be sure port 3306 is open between any Rancher server and the MySQL server host. 2. Run docker stop <container name>. 3. Run docker run -d --restart=unless-stopped -p 8080:8080 -p 9345:9345 rancher/server --db-host <mysql host> --db-port 3306 --db-user cattle --db-pass cattle --db-name cattle \ --advertise-address <IP_of_the_Node> (*note: Cloud provider users should use the internal/private IP address). Give it 60+ seconds for the container to run. (note: if after 75 seconds you can’t view the Rancher UI, see the troubleshooting section below) 4. Open the Rancher UI at http://<server_ip>:8080. You’ll see all your workloads and settings as you left them. 5. Click on Admin then High Availability. You should see your single host you’ve added. Let’s add another node to the cluster. 6. On another host, run the same command but replacing the --advertise-address <IP_of_the_Node> with the IP address of the new host you’re adding to the cluster. Give it 60+ seconds. Refresh your Rancher server UI. 7. Click on Admin then High Availability. You should see both nodes have been added to your cluster. 8. Because we recommend an odd number of Rancher server nodes, add either 1 or 3 more nodes to the cluster using the same method. Congrats! You have a Rancher server cluster configured for High Availability.
During my time walking through these steps myself I ran into a few issues. Below are some you might run into and how to deal with them. Issue: Can’t view the Rancher UI after 75 seconds. 1. SSH into the Rancher server host. 2. Confirm rancher/server is running. Run docker ps –a. Given an output like this: 3. To view logs, run `docker logs –t tender_bassi` (in this case). If you see something like this: It’s Rancher being unable to reach the database server or authenticate with the credentials we’ve provided it in our start up command. Take a look at networking settings, username and password and access privileges in the MySQL server.
Tip: While you may be tempted to name your rancher/server ‘—name=rancher-server’ or something like it this is not recommended. The reason for this is if you need to rollback to your prior container version after an upgrade step, you’ll have clear distinction between container versions.
So, what have we done? We’ve installed Rancher server as a single container. We’ve upgraded the Rancher installation to a high availability platform instance without impacting running workloads. We’ve also established guidelines for different types of environments. We hope this was helpful. Further details on upgrading are available here https://rancher.com/docs/rancher/v1.6/en/upgrading/.