Rancher Docs: Upgrading Rancher

Upgrading Rancher

If you have launched Rancher server without using an external DB, the Rancher server database is inside your Rancher server container. We will use the running Rancher server container to create a data container. This data container will be used to start new Rancher server containers by using a --volumes-from. Alternatively, you can copy the database out of the container to a directory on the host and bind mount the database.

Note: If you used an external DB, you can stop the original Rancher server container and launch a new version of Rancher server using the same external DB instructions. After the new server is up and running, you can remove the old Rancher server container. Note: If you only stop the container, the container will be restarted if your machine is rebooted due to the --restart=always.

Upgrading Rancher by Creating a Data Container

Stop the container.

$ docker stop <container_name_of_original_server>

Create a rancher-data container. Note: This step can be skipped if you have already upgraded in the past and already have a rancher-data container.

$ docker create --volumes-from <container_name_of_original_server> \
 --name rancher-data rancher/server:<tag_of_previous_rancher_server>

Pull the most recent image of Rancher Server. Note: If you skip this step and try to run the latest image, it will not automatically pull an updated image.
```
$ docker pull rancher/server:v1.0.2
```
Launch a new Rancher Server container using the database from the rancher-data container. Any changes in Rancher will be saved in the rancher-data container. If you seen an exception in the server regarding a log lock, please refer to how to fix the log lock.

Note: Depending on how long you’ve had Rancher server, certain database migrations may take longer than expected. Please do not stop upgrades in the middle of upgrading as you will hit a database migration error the next time you upgrade.
```
$ docker run -d --volumes-from rancher-data --restart=always \
  -p 8080:8080 rancher/server:v1.0.2
```
Note: If you set any environment variables or passed in a ldap certificate in your original Rancher server setup, you’ll need to add those environment variables or certificate in the command.
Remove the old Rancher server container. Note: If you only stop the container, the container will be restarted if your machine is rebooted due to the --restart=always. We recommend removing the container after your upgrade has been successful.

Upgrading Rancher launched using Bind Mounts

Stop the running Rancher Server container.

$ docker stop <container_name_of_original_server>

Copy the database files out of the server container. Note: If you already have the database stored on the host, you can skip this step. Also, if the DB has been copied out of the container, it will be inside //mysql/ because of the way Docker copies it out. Be sure to account for this when bind mounting into the container. If you started with bind mounts, you will not need the mysql/.
```
$ docker cp <container_name_of_original_server>:/var/lib/mysql <path on host>
```
Now set the UID/GID for the folder so that the mysql user within the container has the correct ownership of the mysql mount.
```
$ sudo chown -R 102:105 <path on host>
```
Start new server container.
```
$ docker run -d -v <path_on_host>:/var/lib/mysql -p 8080:8080 \
  --restart=always rancher/server:v1.0.2
```
Note: It is important that you have trailing ‘/’ at the end of the host path if you have copied a database out of a previous container. Otherwise, the directory ends up in the wrong place.

Rancher Agents

Each Rancher agent version is pinned to a Rancher server version. If you upgrade Rancher server and Rancher agents require an upgrade, it will automatically upgrade the agents to the latest version of Rancher agent.

For anything using the rancher/agent-instance image, the running container gets upgraded even if the image of the container is not updated to the latest version. For the Network Agent, this occurs when there is a trigger regarding networking (e.g. adding another container, deleting a container). For the Load Balancers, the upgrade occurs by the next load balancer configuration update (e.g. target instance gets restarted, new target service is added, hostname routing rules change, load balacner instance restart, etc).

Users with No Internet Access

Users without internet will need to download the latest rancher/agent-instance into their own registry. In order to upgrade the version of the network agent, you’d need to manually stop the network agent and remove from the UI. Anything that triggers networking on the host that has the missing network agent will cause a new network agent (with the latest version) to be started. In order to upgrade the version of your load balancers, you’ll need to re-create them to get the newest version of rancher/agent-instance.