mirror of
https://github.com/empayre/fleet.git
synced 2024-11-06 17:05:18 +00:00
3205 improve updating docs (#3593)
* Updating Upgrade docs * making changes to database section of upgrade docs * Update docs/02-Deploying/06-Upgrading-Fleet.md Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com> * Update docs/02-Deploying/06-Upgrading-Fleet.md Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com> * Update docs/02-Deploying/06-Upgrading-Fleet.md Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com> * Corrected anchor tags, ready to merge Co-authored-by: Katheryn Satterlee <ksatter@Kathys-MacBook-Pro.local> Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com>
This commit is contained in:
Katheryn Satterlee
GitHub
parent
be1105757b
commit
331a04121a
@ -66,7 +66,7 @@ Scaling Fleet horizontally is as simple as running more Fleet server processes c
|
||||
|
||||
The Fleet/osquery system is resilient to loss of availability. Osquery agents will continue executing the existing configuration and buffering result logs during downtime due to lack of network connectivity, server maintenance, or any other reason. Buffering in osquery can be configured with the `--buffered_log_max` flag.
|
||||
|
||||
Note that short downtimes are expected during [Fleet server upgrades](./08-Updating-Fleet.md)-fleet.md) that require database migrations.
|
||||
Note that short downtimes are expected during [Fleet server upgrades](../02-Deploying/06-Upgrading-Fleet.md) that require database migrations.
|
||||
|
||||
### Debugging performance issues
|
||||
|
||||
|
||||
@ -1,55 +0,0 @@
|
||||
# Updating Fleet
|
||||
- [Overview](#overview)
|
||||
- [Updating the Fleet binary](#updating-the-fleet-binary)
|
||||
- [Raw binaries](#raw-binaries)
|
||||
- [Docker container](#docker-container)
|
||||
- [Running database migrations](#running-database-migrations)
|
||||
|
||||
## Overview
|
||||
|
||||
This guide explains how to update and run new versions of Fleet. For initial installation instructions, see [Installing Fleet](../02-Deploying/02-Server-Installation.md).
|
||||
|
||||
There are two steps to perform a typical Fleet update. If any other steps are required, they will be noted in the release notes.
|
||||
|
||||
1. [Update the Fleet binary](#updating-the-fleet-binary)
|
||||
2. [Run database migrations](#running-database-migrations)
|
||||
|
||||
As with any enterprise software update, it's a good idea to back up your MySQL data before updating Fleet.
|
||||
|
||||
## Updating the Fleet binary
|
||||
|
||||
To update to a new version of Fleet, follow the [same binary install instructions](../02-Deploying/02-Server-Installation.md) from the original installation method you used to install Fleet.
|
||||
|
||||
### Raw binaries
|
||||
|
||||
Download, unzip, and replace the existing Fleet binary with the newly unzipped binary.
|
||||
|
||||
### Docker container
|
||||
|
||||
Pull the latest Fleet docker image:
|
||||
|
||||
```
|
||||
docker pull fleetdm/fleet
|
||||
```
|
||||
|
||||
## Running database migrations
|
||||
|
||||
Before running the updated server, perform necessary database migrations. It is always advised to back up the database before running migrations.
|
||||
|
||||
Database migrations in Fleet are intended to be run while the server is offline. Osquery is designed to be resilient to short downtime from the server, so no data will be lost from `osqueryd` clients in this process. Even on large Fleet installations, downtime during migrations is usually only seconds to minutes.
|
||||
|
||||
First, take the existing servers offline.
|
||||
|
||||
Run database migrations:
|
||||
|
||||
```
|
||||
fleet prepare db
|
||||
```
|
||||
|
||||
Note, if you would like to run this in a script, you can use the `--no-prompt` option to disable prompting before the migrations.
|
||||
|
||||
Start new Fleet server instances:
|
||||
|
||||
```
|
||||
fleet serve
|
||||
```
|
||||
@ -25,7 +25,7 @@ The upgrade from kolide/fleet to fleetdm/fleet works the same as any minor versi
|
||||
|
||||
Minor version upgrades in Kolide Fleet often included database migrations and the recommendation to back up the database before migrating. The same goes for FleetDM Fleet versions.
|
||||
|
||||
To migrate from Kolide Fleet to FleetDM Fleet, please follow the steps outlined in the [Updating Fleet section](./08-Updating-Fleet.md) of the documentation.
|
||||
To migrate from Kolide Fleet to FleetDM Fleet, please follow the steps outlined in the [Upgrading Fleet section](../02-Deploying/06-Upgrading-Fleet.md) of the documentation.
|
||||
|
||||
## Has anyone stress tested Fleet? How many clients can the Fleet server handle?
|
||||
|
||||
@ -143,12 +143,6 @@ You can also do this by setting the `targets` field in the [YAML configuration f
|
||||
|
||||
[Team enroll secrets](https://github.com/fleetdm/fleet/blob/main/docs/01-Using-Fleet/10-Teams.md#enroll-hosts-to-a-team) allow you to automatically assign a host to a team.
|
||||
|
||||
## How do I resolve an "unknown column" error when upgrading Fleet?
|
||||
|
||||
The `unknown column` error typically occurs when the database migrations haven't been run during the upgrade process.
|
||||
|
||||
Check out the [documentation on running database migrations](./08-Updating-Fleet.md#running-database-migrations) to resolve this issue.
|
||||
|
||||
## Why my host is not updating a policy's response.
|
||||
|
||||
The following are reasons why a host may not be updating a policy's response:
|
||||
|
||||
@ -21,8 +21,5 @@ Provides documentation for load balancer health checks and working with Fleet se
|
||||
### [Security best practices](./07-Security-best-practices.md)
|
||||
Includes resources for ways to mitigate against the OWASP top 10 issues
|
||||
|
||||
### [Updating Fleet](./08-Updating-Fleet.md)
|
||||
Includes a guide for how to update and run new versions of Fleet
|
||||
|
||||
### [FAQ](./FAQ.md)
|
||||
Includes commonly asked questions and answers about using Fleet from the Fleet community
|
||||
62
docs/02-Deploying/06-Upgrading-Fleet.md
Normal file
62
docs/02-Deploying/06-Upgrading-Fleet.md
Normal file
@ -0,0 +1,62 @@
|
||||
# Upgrading Fleet
|
||||
|
||||
This guide explains how to upgrade your Fleet instance to the latest version in order to get the latest features and bug fixes. For initial installation instructions, see [Installing Fleet](./02-Server-Installation.md#installing-fleet).
|
||||
|
||||
There are three steps to perform a typical Fleet upgrade:
|
||||
|
||||
1. [Installing the latest version](#install-the-latest-version-of-fleet)
|
||||
2. [Preparing the database](#prepare-the-database)
|
||||
3. [Serving the new Fleet instance](#serve-the-new-version)
|
||||
|
||||
## Install the latest version of Fleet
|
||||
|
||||
Fleet may be installed locally, or used in a Docker container. Follow the appropriate method for your environment.
|
||||
|
||||
### Local Installation
|
||||
|
||||
[Download](https://github.com/fleetdm/fleet/releases) the latest version of Fleet. Check the `Upgrading` section of the release notes for any additional steps that may need to be taken for a specific release.
|
||||
|
||||
Unzip the newly downloaded version, and replace the existing Fleet version with the new, unzipped version.
|
||||
|
||||
For example, after downloading:
|
||||
|
||||
```sh
|
||||
unzip fleet.zip 'linux/*' -d fleet
|
||||
sudo cp fleet/linux/fleet* /usr/bin/
|
||||
```
|
||||
|
||||
### Docker container
|
||||
|
||||
Pull the latest Fleet docker image:
|
||||
|
||||
```
|
||||
docker pull fleetdm/fleet
|
||||
```
|
||||
|
||||
## Prepare the database
|
||||
|
||||
Changes to Fleet may include changes to the database. Running the built-in database migrations will ensure that your database is set up properly for the currently installed version.
|
||||
|
||||
It is always advised to [back up the database](https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html) before running migrations.
|
||||
|
||||
Database migrations in Fleet are intended to be run while the server is offline. Osquery is designed to be resilient to short downtime from the server, so no data will be lost from `osqueryd` clients in this process. Even on large Fleet installations, downtime during migrations is usually only seconds to minutes.
|
||||
|
||||
First, take the existing servers offline.
|
||||
|
||||
Run database migrations:
|
||||
|
||||
```
|
||||
fleet prepare db
|
||||
```
|
||||
|
||||
## Serve the new version
|
||||
|
||||
<<<<<<< HEAD
|
||||
Once Fleet has been replaced with the newest version and the database migrations have completed, serve the newly upgraded Fleet instance:
|
||||
=======
|
||||
Once Fleet has been replaced with the latest version and the database migrations have been completed, serve the newly upgraded Fleet instance:
|
||||
>>>>>>> b6404417f6964ec2ea0f2448f129725bf7bbdacb
|
||||
|
||||
```
|
||||
fleet serve
|
||||
```
|
||||
@ -220,3 +220,9 @@ complete.
|
||||
|
||||
A similar process may be followed for rotating team-specific enroll secrets. For teams, the secrets
|
||||
are managed in the team yaml.
|
||||
|
||||
## How do I resolve an "unknown column" error when upgrading Fleet?
|
||||
|
||||
The `unknown column` error typically occurs when the database migrations haven't been run during the upgrade process.
|
||||
|
||||
Check out the [documentation on running database migrations](./06-Upgrading-Fleet.md#running-database-migrations) to resolve this issue.
|
||||
@ -15,5 +15,8 @@ Information about running an update server with fleetctl.
|
||||
### [Load Testing](./05-Load-testing.md)
|
||||
Information about running an update server with fleetctl.
|
||||
|
||||
### [Upgrading Fleet](./06-Upgrading-Fleet.md)
|
||||
Includes a guide for how to update and run new versions of Fleet
|
||||
|
||||
### [FAQ](./FAQ.md)
|
||||
Includes commonly asked questions and answers about deployment from the Fleet community.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user