Install the ThoughtSpot application on offline clusters that use RHEL
Install ThoughtSpot on RHEL offline clusters.
Before starting the install, make sure that you completed the pre-installation steps.
In an offline cluster, the hosts cannot connect to the public repositories to download the required packages. Instead, you must download the packages from your organization’s mirror repository to each host. Otherwise, the steps for installing on offline clusters are practically the same as the steps for installing on online cluster.
Before you build the ThoughtSpot cluster and install the ThoughtSpot application on the hosts, you must run the Ansible playbook. The TS Ansible playbook prepares your clusters in the following manner:
-
Ansible installs the required packages: YAML, Python, and R packages; see Packages installed with ThoughtSpot for RHEL.
-
It creates and configures local user accounts for ThoughtSpot:
-
admin
user has full administrative functionality -
thoughtspot
user can load data in the application -
It installs the ThoughtSpot CLI,
tscli
. -
It configures the ThoughtSpot host nodes:
-
checks that customization scripts can execute on the nodes
-
checks that the partitions meet minimum size requirements
Here are the general steps for installing offline:
❏ |
|
❏ |
|
❏ |
|
❏ |
Configure the Ansible Playbook
To set up the Ansible, follow these steps:
-
Obtain the Ansible tarball from ThoughtSpot Support.
-
Download it to your local machine.
-
Unzip the Ansible tarball, to see the following files and directories on your local machine:
customize.sh
-
This script runs as the last step in the preparation process. You can use it to inject deployment-specific customizations, such as enabling or disabling a corporate proxy, configuring extra SSH keys, installing extra services, and so on.
hosts.sample
-
Ansible inventory file for host configuration.
prod_image
-
This directory contains the ThoughtSpot tools and
tscli
, the ThoughtSpot CLI binary. README.md
-
Basic information for the unzipped file
rpm_gpg
-
This directory contains the GPG keys that authenticate the public repository.
toolchain
-
The tools that are necessary to compile the instructions you define in the Ansible Playbook, the source code, into executables that can run on your device. The toolchain includes a compiler, a linker, and run-time libraries.
ts-new.yaml
-
The Ansible Playbook for new installations.
ts-update.yaml
-
The Ansible Playbook for updates.
ts.yaml
yum.repos.d
-
This directory contains information about the yum repo used by the cluster.
-
Copy the Ansible inventory file
hosts.sample
tohosts.yaml
, and using a text editor of your choice, update the file to include your host configuration:hosts
-
Add the IP addresses or hostnames of all hosts in the ThoughtSpot cluster.
admin_uid
-
The admin user ID parameter.
- On-premise deployments
-
Use the default values.
- AWS
-
Use the default values.
- GCP
-
Add values that are not currently in use. To determine what values your system uses already, run the following command:
cat /etc/passwd | cut -d ":" -f3-4| sort
admin_gid
-
The admin user group ID.
- On-premise deployments
-
Use the default values.
- AWS
-
Use the default values.
- GCP
-
Add values that are not currently in use. To determine what values your system uses already, run the following command:
cat /etc/passwd | cut -d ":" -f3-4| sort
ldap_admin_user
-
[optional] One of three parameters required to enable users to use their OpenLDAP admin user to SSH as an admin, instead of using the local ThoughtSpot admin user, which has sudo privileges. Specify the OpenLDAP admin user, in the form [email protected]. You must include all 3 of the LDAP parameters (
ldap_admin_user
,ldap_server_uri
,ldap_server_base
), or none of them. If you include 1 or 2, the playbook fails. ldap_server_uri
-
[optional] One of three parameters required to enable users to use their OpenLDAP admin user to SSH as an admin, instead of using the local ThoughtSpot admin user, which has sudo privileges. Specify the LDAP server uniform resource identifier, in the form ldap://<ldap_server_IP>. You must include all 3 of the LDAP parameters (
ldap_admin_user
,ldap_server_uri
,ldap_server_base
), or none of them. If you include 1 or 2, the playbook fails. ldap_server_base
-
[optional] One of three parameters required to enable users to use their OpenLDAP admin user to SSH as an admin, instead of using the local ThoughtSpot admin user, which has sudo privileges. Specify the LDAP server base distinguished name, in the form dc=<optional_subdomain>,dc=<domain>,dc=<top-level-domain>, such as dc=thoughtspot,dc=com. You must include all 3 of the LDAP parameters (
ldap_admin_user
,ldap_server_uri
,ldap_server_base
), or none of them. If you include 1 or 2, the playbook fails. ssh_user
-
The
ssh_user
must exist on the ThoughtSpot host, and it must havesudo
privileges.- On-premise deployments
-
The
ssh_user
is the user who runs the playbook, and who is connected to the hosts. - AWS
-
The same as
ec2_user
. - GCP
-
The
ssh_user
is the user who runs the playbook, and who is connected to the hosts.
ssh_private_key
-
Add the private key for
ssh
access to thehosts.yaml
file. You can use an existing key pair, or generate a new key pair in the Ansible Control server.Run the following command to verify that the Ansible Control Server can connect to the hosts over
ssh
:ansible -m ping -i hosts.yaml all
ssh_public_key
-
Add the public key to the
ssh authorized_keys
file for each host, and add the private key to thehosts.yaml
file. You can use an existing key pair, or generate a new key pair in the Ansible Control server.Run the following command to verify that the Ansible Control Server can connect to the hosts over
ssh
:ansible -m ping -i hosts.yaml all
extra_admin_ssh_key
-
(Optional) An additional or extra key may be required by your security application, such as Qualys, to connect to the hosts.
http(s)_proxy
-
If the hosts must access public repositories through an internal proxy service, provide the proxy information.
This release of ThoughtSpot does not support proxy credentials to authenticate to the proxy service.
ts_partition_name
-
The extended name of the ThoughtSpot export partition, such as
/dev/sdb1
.
Redirect the mirror repository
For the cluster hosts to connect to your organization mirror repository, you must redirect the hosts requests to the mirror repository, through the DNS.
Alternatively, you can manually update the repository URLs in the yum.repos.d
file.
Run the Ansible Playbook
First, to allow installation of the Yum, Python, and R packages, you must run the run_offline
script on your local machine. Run the following command on all nodes:
run_offline.sh
Now you can run the Ansible Playbook from your local machine by entering the following command:
ansible-playbook -i hosts.yaml ts.yaml
As the Ansible Playbook runs, it will perform these tasks:
-
Trigger the installation of Yum, Python, and R packages.
-
Configure the local user accounts that the ThoughtSpot application uses
-
Install the ThoughtSpot CLI
-
Configure all the nodes in the ThoughtSpot cluster:
-
Format and create export partitions, if they do not exist
-
Format the data disks
-
After the Ansible Playbook finishes, run the prepare_disks
script on every node. You must run this script as an admin user. Specify the data drives by adding the full device path for all data drives, such as /dev/sdc
, after the script name. Separate data drives with a space.
-
Switch to the admin user, if necessary:
su admin
-
Run the
prepare_disks
script:/usr/local/scaligent/bin/prepare_disks.sh /dev/sdc /dev/sdd
Your hosts are ready for installing the ThoughtSpot application.
Install the ThoughtSpot cluster and the application
Refer to the ThoughtSpot documentation for the detailed steps to install the ThoughtSpot cluster for each deployment platform:
Follow these general steps to install ThoughtSpot on the prepared hosts:
-
Connect to the host as an admin user.
-
Download the release artifact from the ThoughtSpot file sharing system.
-
Upload the release artifact to your organization’s mirror repository.
-
Run the
tscli cluster create
command. This script prompts for user input. -
Check the cluster health by running health checks and logging into the application.