Installation Ansible playbooks - kwantu/platformconfiguration GitHub Wiki

https://wiki.kwantu.me/en/Installation/Installation-Ansible-playbooks

back

Using Ansible to configure new servers and update existing ones

Ansible playbooks

Ansible is leveraged in order to help get the core services up and running on the required servers. These servers and services will be maintained with Ansible.

For newly provisioned servers there is a level of setup that needs to be done before these servers will be able to be targeted with the Ansible roles defined.

The public ssh key for the user running the Ansible playbooks needs to be present on the remote server in order for the playbook to successfully start and run. Generally a user account and password is given for the newly provisioned server that will have super user access, or alternatively the root password will be provided.

Once the key is uploaded to the server using the remote account Ansible will be able to SSH to that server without providing a password, since password-less certificate based authentication is being leveraged.

Specific playbooks have been written to setup these servers to get them into a standardized state that will allow the subsiquint playbooks to be executed in the manner in which they where intended. These initial playbooks are designed to setup the initial user accounts and change the behaviour of SSH, namely disallowing remote root access and only allowing password-less certificate based authentication.

Environments

There are the following environments to choose from when running the script.

  1. setup - Only for first time server installations
  2. dev - dev server
  3. staging - staging server
  4. prod - production servers
  5. ntip - ntip lmsntip server

Within each of these environments, you can choose the following host groups

  1. application: For all functions that need to go to the application server
  2. couchdb: for all functions that must to go each of the couchdb servers
  3. nginx: for all functions that must go to the server running nginx
  4. kibana: for all functions that goes to the reporting server

Setup a new server using Ansible

  1. Go to the environments, and edit environments/setup/hosts file to add the new host to be set up. Clear other hosts that have already been set up.
  2. Copy the public keys for the admin user to the new server
sudo su - admin
ssh-copy-id root@<server ip/fqdn>

Also make sure that the DNS servers to be used are accessible

vi /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4
#nameserver 1xx.1xx.1xx.x
#nameserver 1xx.1xx.1xx.x

  1. Setup the hosts to be set up in the environments/setup/hosts

  2. Run the initial setup scripts

cd ansible
ansible-playbook -i environments/setup/hosts update_admin_key.yml
# The next updates all the packages. It is an optional step and isn't enforced, however it is always recommended to be running the latest patch level on a server. Unless there is a very specific reason this step is highly recommended.
ansible-playbook -i environments/setup/hosts update_host_software.yml
  1. Then run the basics playbook to set up all the basics.
./playbook.sh <environment> basics <hosts in the environment> -e "restart_service=true clean_temp=false reboot=false"
  1. Because SELinux is enabled in this script the new server must be rebooted to take effect. Login to the

Running playbook for specific roles

This will run the "basic" Ansible role against a single host named "servername.domain.co.za" found under the prod environment.

sudo su - admin
cd ansible
./playbook.sh <environment> <role> <servergroup>

This will run the "basic" Ansible role against the host group labelled "test" found under the prod environment.

sudo su - admin
cd ansible
./playbook.sh prod basics test

Advanced playbook runs tweaking environment variables

With this method the script will accept an additional parameter for defining the state of environment variables at runtime. These values have the ability to override the ones set in the role and thus can be leveraged to do more advanced tasks that generally aren't wanted/expected during normal playbook execution. Each role will have it's

sudo su - admin
cd ansible
./playbook.sh prod basics test -e "restart_service=true clean_temp=false"

Detailed table of playbooks

To access the roles that contain the various playbooks.

sudo su - admin
cd ansible/roles
Name Function Tag options
BASICS Basic initial server configuration. restart_service=true (Restarts the services after running)
clean_temp=false Clears the /tmp/ dir)
COUCHDB Installs Couchdb Setup. Currently 3.3.1 -e "couchdb_clustered=true administrator_password= jwt_key=<jwt_key here> admins_lucene_password="
COUCHDB_OPTIMIZE Set up the optimisation parameters and file limits ???
ELASTIC Installs Elastic stack -e "elastic_setup=true elastic_set_passwords=true" when setting up a new instance. -e "elastic_upgrade_latest=true" when you want to run the upgrade after all the preparations for upgrade has been done
KIBANA Installs Kibana -e "kibana_set_passwords=true kibana_setup=true KIBANA_ELASTIC_password=xxxxxxxx" when setting up a new instance. -e= "kibana_upgrade_latest=true" when you want to run the upgrade after all the preparations for upgrade has been done
MYSQL Installs MySQL version 5.7.30 -e "mysql_harden=true mysql_setup=true" Note if there is an issue that the server does not want to start, make sure that selinux is set to permissive mode (selinux)
NGINX Installs Nginx -e "nginx_setup=true"
NODEJS Installs node js and the core betterdata application ???
REDIS Installs Redis ??
RHEL-CIS Not sure ???

FirewallD

Servers configuration

Production setup

Appserver: Redis, Mysql, Node, exist-db kwantu02 197.242.147.53

Nginx: kwantu00 154.0.170.230

DBCluster User write: kwantu00 154.0.170.230 Read lucene: kwantu03 154.0.170.247 Node Services: kwantu05 154.0.174.153

Reports: existdb, kibana, elastic kwantu06 154.0.175.164

Staging Server: kwantu04 154.0.174.125


10.155.78.115
⚠️ **GitHub.com Fallback** ⚠️