Deployer Web UI Notes ​

Provisioning cloud infrastructure can very occasionally fail in unexpected ways. If this happens to you, or you'd like help or advice, please contact us at deployer-support@yellowbrick.com or, if you're an existing customer, file a support ticket.

If you can, please attach a debug log, which you can download by selecting Actions → Download Debug Log at the bottom right of the Deployer window.

The remainder of this document comprises notes on specific fields and screens in the Deployer.

Welcome ​

When you start the deployer, an access key should have been prepopulated and you can just keep going. The access key is a way to make sure random internet users don't stumble upon your deployer and mess with it.

If you suspend and resume the deployer you may need to repopulate the access key. See here for instructions on how to do so.

Deployer ​

On the Deployer page, you can choose to Install, Upgrade or Uninstall Yellowbrick. If you're part way through the process, a Continue option will also be available.

Install

Start an installation. Much of the installation process is gathering and validating information. At the end of the process, before the installation is actually performed, there's an option available to download an installation manifest or JSON configuration file without actually doing anything. The installation manifest shows, in a human readable or printable form, all of the cloud infrastructure components (such as VPCs, role names, service account names, node groups, etc) that would be created by an installation; it's ideal for showing other departments in larger organizations. The JSON configuration is the starting point for invoking a command line installation. If you quit the deployer without installing, you can always come back and pick up where you left off.

Continue

This operation is only visible if you started down the installation path but didn't complete the operation.

Upgrade

The Upgrade operation's primary function is to push a new version of the Yellowbrick database software to the artefact registry. It also triggers an immediate update and restart of the Yellowbrick Operator and Yellowbrick Manager. None of these operations result in downtime for Yellowbrick instances or users of the database. The database itself can be upgraded to the new version at a later date, using Yellowbrick Manager by navigating to Instance Management → Actions → Upgrade.

On rare occasions, running an upgrade will also upgrade cloud infrastructure, such as Kubernetes, to a newer version. These upgrades will require scheduled downtime. In such cases, the Deployer will warn you in red on the screen and with extra prompts.

Uninstall

This operation uninstalls a previously installed instance, Yellowbrick Operator and Yellowbrick Manager. If, for whatever reason, a previous installation failed, you'll need to Uninstall here and then try again.

Information ​

This page is available for Upgrade and Uninstall operations only. For Upgrades and Uninstalls, you'll need to re-enter the details of the cloud provider and other associated fields so that the Deployer can locate the Yellowbrick deployment. If during installation you customized the Kubernetes cluster name or namespace name, you'll also need to re-enter them here.

Provider ​

Instance name

This is the most important field; it's used by default for the Kubernetes cluster name, namespace name, along with many other infrastructure objects. You can override some of these names in the Advanced section, but if you do so, remember you'll also need to re-enter them during upgrades. The field is 20 alphanumeric characters long.

Provider

Choose which cloud provider you want to install into.

Region

The regions in the dropdown list have been formally qualified by Yellowbrick for production use. If you'd like to try one that isn't on the list, feel free to type it in but please let us know by emailing deployer-support@yellowbrick.com.

Various cloud-specific fields

For other cloud providers, you may need to enter other deployment information here, such as a project ID or subscription etc.

Advanced → Kubernetes Cluster/Namespace Name

You can provide names different from the instance name if you like.

Advanced → Block Storage Custom Encryption Key ID

Yellowbrick block storage volumes (aka EBS volumes) are encrypted by default using cloud provider managed keys. Using this option lets you supply your own custom key. Note that if the key is deleted, the data may be irreversibly lost. We recommend not using this option unless you have sufficient experience with cloud KMS, key versions, and key rotation processes. Each cloud provider uses a different format for the key ID, and only the corresponding format for that provider will function correctly.

For AWS, use the full ARN of the key in the KMS, for example arn:aws:kms:us-west-2:012345678901:key/deadbeef-dead-beef-dead-beefdeadbeef.

For Azure, use the resource ID of the Disk Encryption Set, including the subscription ID and resource group name, for example /subscriptions/deadbeef-dead-beef-dead-beefdeadbeef/resourceGroups/resource-group-name/providers/Microsoft.Compute/diskEncryptionSets/key-name.

For GCP, the format is the full ID of the key in the KMS, for example projects/0123456789/locations/us-east1/keyRings/key-ring-name/cryptoKeys/key-name.

Advanced → Custom Tags/Labels

See resource tagging and costing.

Restrict Access ​

A default public installation of Yellowbrick sets the Kubernetes API, listener pod (PostgreSQL port 5432 along with the Yellowbrick tools data and service ports) and Yellowbrick Manager to be publicly routable. Note that despite being routable, the Kubernetes API is protected by client certificates tied to logins (normally with MFA), and the other ports can be protected by single sign-on. Even in these public installations, all of the workers and paths Kubernetes workers are not routable from public networks, and access to object store is via private endpoints. So public installs are still highly secure.

By setting up network access restrictions, you can add allow lists for access to the public ports and the K8s API. Be really careful when changing these to not block access from the machine the deployer is running on or the machine you want to access the installed product from!

Yellowbrick Manager allows changing all of the allow lists after installation, except for the Kubernetes API which has to be changed via the cloud provider's management console. Unless you are particularly paranoid, there is no reason to restrict access at this point in the installation.

If you choose the private routing option, you'll need to follow the instructions for private installation first.

Network ​

This is where you specify the network the instance runs in. Our guidance is to make this network as large as possible; we recommend starting with a /16 network. You also need to nominate a first subnet to install into (or, for AWS, three subnets, two for autoscaler HA and a third for the NAT gateway for AWS API access).

Make the subnet as large as possible too. Kubernetes consumes a large number of IP addresses (one per pod, not one per instance). The larger the subnet, the more compute cluster nodes can be accommodated in future. The GUI will estimate roughly how many nodes you have room for as you modify the subnet.

Initial Account ​

The instance has an initial administrator account. By default we auto-generate a strong password which you can download, view or copy to the clipboard. Or you can enter your own credentials here, if you like.

Storage ​

Columnar data in Yellowbrick is persisted on object storage. By default we create storage buckets as part of the installation. You can choose to make your own object storage bucket afterwards by following the custom object storage documentation.

Install ​

This is the last page in the installation sequence that shows you all actions the Deployer is planning to undertake. You can review the infrastructure manifest here or export a JSON configuration file by pressing the Actions button at the bottom right of the window.