Installing Ruby from the CentOS repositories. Peatio install series.
Run the following commands as root or user with sudo privileges to install the ruby package:
#sudo dnf install ruby
relax and wait for the installation to compete.
Once installation is completed, you can verify that it was successful by printing the Ruby version:
$ruby –version
The output will look something like this:
Output
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
Your Ruby version may be different from the one above.
Installing Ruby with Rbenv
Rbenv is a lightweight Ruby management utility that allows you to easily switch Ruby versions.
We’ll use the ruby-build plugin that extends the core functionality of Rbenv and allow you to install any Ruby version from source.
Start by installing git and other dependencies required to build Ruby from the source.
sudo dnf install git wget gcc bzip2 openssl-devel libffi-devel readline-devel zlib-devel gdbm-devel ncurses-devel
Run the following command to install both rbenv
and ruby-build
:
wget -q https://github.com/rbenv/rbenv-installer/raw/master/bin/rbenv-installer -O- | bash
The script will clone both rbenv and ruby-build repositories from GitHub to ~/.rbenv
directory.
Before starting using rbenv
, you need to add $HOME/.rbenv/bin
to your PATH
.
If you are using Bash, type:
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc
If you are using Zsh type:
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(rbenv init -)"' >> ~/.zshrc
source ~/.zshrc
Run the rbenv -v
command to ensure that installation was successful:
rbenv -v
rbenv 1.1.2-17-g7795476
To get a list of all Ruby versions that can be installed with rbenv
enter:
rbenv install -l
For example, if you want to install the Ruby 2.7.0 and set it as default version you would type:
rbenv install 2.7.0
rbenv global 2.7.0
Verify that Ruby was properly installed by printing the version number:
ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]
Installing Ruby with RVM
RVM (Ruby Version Manager) is a command-line tool that allows you to install, manage, and work with multiple Ruby environments.
First, install the dependencies required for rvm
to build Ruby from source:
sudo dnf install curl gcc bzip2 openssl-devel libffi-devel readline-devel zlib-devel gdbm-devel ncurses-devel
Run the following commands to import the GPG keys and install RVM:
gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
curl -sSL https://get.rvm.io | bash -s stable
To start using RVM you need to run the following source
command:
source ~/.rvm/scripts/rvm
To get a list of all known Ruby versions type:
rvm list known
If for example, you want to install Ruby 2.6 and set it as the default version you would issue the following commands:
rvm install 2.6
rvm use 2.6 --default
Verify the installation:
ruby -v
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
For more information about how to manage your Ruby installations with RVM visit the RVM Documentation page .
Peatio Install.
Install Ruby
Install MySQL
Install Redis
Install RabbitMQ
Install Bitcoind
Install Nginx with Passenger
Install JavaScript Runtime
Install ImageMagick
Configure Peatio
Setup Pusher
Setup Bitcoin RPC
Run Daemons
Setup Google Authentication
Setup Auth0
Run Peatio
Setup nginx
Table of Contents
- Setup deploy user
- Install Ruby
- Install MySQL
- Install Redis
- Install RabbitMQ
- Install Bitcoind
- Install Nginx with Passenger
- Install JavaScript Runtime
- Install ImageMagick
- Configure Peatio
- Setup Pusher
- Setup Bitcoin RPC
- Run Daemons
- Setup Google authentication
- Setup Auth0
- Run Peatio
- Setup nginx
( Get Jenkins to install the Server(s)), Also, get cluster of nginx and a cluster of Mysql/MariaDB Servers, Also, MariaDB servers need to be in a cluster with failover and fault tolerant configuration).
- Get Monitoring in place, Grafana, ELK stack, HTTP logs, etc.
- Document the whole process in detail.
Setup deploy user
Create (if it doesn’t exist) deploy user, and assign it to the sudo group:
# sudo adduser deploysudo usermod -a -G sudo deploy
Re-login as deploy user
su deploy cd
Install Ruby
- Make sure your system is up-to-date.
#sudo apt-get updatesudo apt-get upgrade
- Installing dependencies
sudo apt-get install git curl zlib1g-dev build-essential \ libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 \ libxml2-dev libxslt1-dev libcurl4-openssl-dev libff
- Installing rvm
gpg —keyserver hkp://keys.gnupg.net \ —recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 \ 7D2BAF1CF37B13E2069D6956105BD0E739499BDB\curl –sSL https://get.rvm.io | bash -s stable –ruby=2.5.0 –gems=rails
If you want to skip fetching documentation when installing gems, do the following:
echo “gem: –no-ri –no-rdoc” > ~/.gemrc
- Source rvm
source /home/deploy/.rvm/scripts/rvm rvm use 2.5.0
Install MySQL
sudo apt-get install mysql-server mysql-client libmysqlclient-dev
- Setup a password for root while its installing
- Create environment variables for database
cd sudo nano .bashrc ## Add following lines. at the end of .bashrc file ## Insert your password for m export DATABASE_HOST=localhost export DATABASE_USER=root export DATABASE_PASS=Bilal-IS-Awesome
- Source the bashrc file
source ~/.bashrc
Install Redis
Be sure to install the latest stable Redis, as the package in the distro may be a bit old:
sudo add-apt-repository ppa:chris-lea/redis-serversudo apt-get updatesudo apt-get install redis-server
Install RabbitMQ
- Download Erlang wget http://packages.erlang-solutions.com/site/esl/esl-erlang/FLAVOUR_1_genesl-erlang_20.1-1~ubuntu~xenial_amd64.deb
- Install using gdebi
sudo apt install gdebi sudo gdebi esl-erlang_20.1-1~ubuntu~xenial_amd64.deb
- Install RabbitMQ
echo “deb https://dl.bintray.com/rabbitmq/debian xenial main” | sudo tee /etc/apt/sources.list.d/bintray.rabbitmq.listwget -O- https://www.rabbitmq.com/rabbitmq-release-signing-key.asc | sudo apt-key add –sudo apt-get updatesudo apt-get install rabbitmq-serversudo rabbitmq-plugins enable rabbitmq_managementsudo service rabbitmq-server restartwget http://localhost:15672/cli/rabbitmqadminchmod +x rabbitmqadminsudo mv rabbitmqadmin /usr/local/sbin
Install Bitcoind
sudo add-apt-repository ppa:bitcoin/bitcoinsudo apt-get updatesudo apt-get install bitcoind
Configuring Bitcoind
- Prepare config files:
mkdir -p ~/.bitcointouch ~/.bitcoin/bitcoin.confsudo nano ~/.bitcoin/bitcoin.conf
- Insert the following lines into bitcoin.conf, and replace with your username and password.
server=1daemon=1# If run on the test network instead of the real bitcoin network# testnet=1# You must set rpcuser and rpcpassword to secure the JSON-RPC api# Please make rpcpassword to something secure, `5gKAgrJv8CQr2CGUhjVbBFLSj29HnE6YGXvfykHJzS3k` for example.# Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)rpcuser=deployuserrpcpassword=deploypassrpcport=8332# Notify when receiving coinswalletnotify=/usr/local/sbin/rabbitmqadmin publish routing_key=peatio.deposit.coin payload='{“txid”:”%s”, “currency”:”btc”}’
- Start bitcoin daemon:
bitcoind
Installing Nginx & Passenger
- Install Phusion’s PGP key to verify packages
sudo apt-get install -y dirmngr gnupg sudo apt-key adv —keyserver keyserver.ubuntu.com —recv-keys 561F9B9CAC40B2F7
- Add HTTPS support to APT
sudo apt-get install apt-transport-https ca-certificates
- Add the passenger repository.
Note that this only works for Ubuntu 16.04. For other versions of Ubuntu, you have to add the appropriate repository according to Section 2.3.1 of this link.
sudo add-apt-repository ‘deb https://oss-binaries.phusionpassenger.com/apt/passenger xenial main’sudo apt-get update
- Install nginx and passenger
sudo apt-get install nginx-extras passenger
- Next, we need to update the Nginx configuration to point Passenger to the version of Ruby that we’re using. You’ll want to open up /etc/nginx/nginx.conf in your favorite editor,
sudo nano /etc/nginx/passenger.conf
- Find the following lines, and update them with these:
passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini;passenger_ruby /home/.rvm/rubies/ruby-2.5.0/bin/ruby;
- Enable to include this file in nginx
sudo nano /etc/nginx/nginx.conf
Find this line and uncomment it.
include /etc/nginx/passenger.conf;
- Install JavaScript Runtime A JavaScript Runtime is needed for Asset Pipeline to work. Any runtime will do but Node.js is recommended.
curl –sL https://deb.nodesource.com/setup_8.x | sudo bash – sudo apt-get install nodejs
- Then install and run yarn:
sudo apt-get install gcc g++ makecurl –sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -echo “deb https://dl.yarnpkg.com/debian/ stable main” | sudo tee /etc/apt/sources.list.d/yarn.listsudo apt-get update && sudo apt-get install yarn9. Install ImageMagick“`shellsudo apt-get install imagemagick
Configure Peatio
- Setup production environment variable
- Setting up production environment
echo “export RAILS_ENV=production” >> ~/.bashrc
- Clone the project:
git clone https://github.com/berycoin-project/Beryxchange.git peatiocd peatiogit checkout 1-8-stable // Choose your version, but make sure you’ll install the same version for peatio-trading-uibundle installbin/init_config
- Creating and Sourcing Secret_key_base
bundle exec rake secretecho “export SECRET_KEY_BASE=YOUR-SECRET” >> ~/.bashrcsource ~/.bashrc
- Install ruby-dev
sudo apt-add-repository ppa:brightbox/ruby-ngsudo apt updatesudo apt-get install ruby2.5 ruby2.5-devsudo apt upgrade
- Run setup
bin/setup
- Setup Pusher Peatio depends on pusher. A development key/secret pair for development/test is provided in config/application.yml.
PLEASE USE IT IN DEVELOPMENT/TEST ENVIRONMENT ONLY!
- Create an account on www.pusher.com
- Create an app
- Set pusher-related settings
sudo nano config/application.yml
- Setup bitcoind rpc endpoint
sudo nano config/seed/currencies.yml
- Replace username:pass and port
json_rpc_endpoint: http://deployuser:deploypass@127.0.0.1:8332
- Run daemons Make sure you are in /peatio directory
god -c lib/daemons/daemons.god
Setup the Google Authentication
By default, it ask for Google Authentication. This parameter can be changed in /config/application.yml
OAUTH2_SIGN_IN_PROVIDER: google
- Setup a new Web application on https://console.developers.google.com Configure the Google Id, Secret and callback in
sudo nano config/application.yml
Note: Make sure your host ISN’T an IP in the callback config. Looks like Google auth expect a callback to a DNS only
GOOGLE_CLIENT_ID: <Google id> GOOGLE_CLIENT_SECRET: <Google secret> GOOGLE_OAUTH2_REDIRECT_URL: https://yourAwesome-exchange.com:3000/auth/google_oauth2/callback
- Setup Auth0
Change OAUTH2. This parameter can be changed in /config/application.yml ->
OAUTH2_SIGN_IN_PROVIDER: auth0
- Setup a new Web application on https://manage.auth0.com/
sudo nano config/application.yml
- Insert values
AUTH0_OAUTH2_DOMAIN: DOMAIN AUTH0_OAUTH2_CLIENT_ID: CLIENTID AUTH0_OAUTH2_CLIENT_SECRET: CLIENTSECRET AUTH0_OAUTH2_REDIRECT_URL: REDIRECTURI-IN-HTTPS
Run Peatio
Finalize the config; open /config/application.yml Set the DNS of your host (IP won’t work if you use Google Authentication)
sudo nano config/application.ymlURL_HOST: yourAwesome-exchange.com:3000Start the server:“`shellbundle exec rails serverOR Make sure the port 3000 is open your server Start the server by passing the ip in parameterbundle exec rails server -b 0.0.0.0
You can also provide a port
bundle exec rails server -p 3000
Validate the server is working:
Install nginx to setup a reverse proxy
sudo apt-get update sudo apt-get install nginx sudo ufw allow ‘Nginx HTTP’ systemctl status nginx
At this point you should see nginx running. But you need to edit the default config to setup the reverse proxy. Open /etc/nginx/sites-available/default in your favorite editor Replace the content of the file by the following
server { server_name http://YOUR-AWESOME-WEBSITE.com; listen 80 default_server; location ~ ^/(?:trading|trading-ui-assets)\/ { proxy_pass http://127.0.0.1:4000; } location / { proxy_pass http://127.0.0.1:3000; } }
Generate JWT key-pair
ruby -e “require ‘openssl’; require ‘base64’; OpenSSL::PKey::RSA.generate(2048).tap { |p| puts ”, ‘PRIVATE RSA KEY (URL-safe Base64 encoded, PEM):’, ”, Base64.urlsafe_encode64(p.to_pem), ”, ‘PUBLIC RSA KEY (URL-safe Base64 encoded, PEM):’, ”, Base64.urlsafe_encode64(p.public_key.to_pem) }”
————————–
Pinance Domains
https://www.marcaria.com/ws/en/domain-search-results 01/13/2021
Pinance.jp |
|
$48 | ||
pinance.cn | NOT AVAILABLE |
|
||
pinance.co.jp | AVAILABLE |
|
$ 99 | |
pinance.com.br | AVAILABLE |
|
$ 29 | |
pinance.de | AVAILABLE | $ 7 | ||
pinance.es | AVAILABLE | $ 14 | ||
pinance.eu | AVAILABLE |
|
$ 11 | |
pinance.fr | NOT AVAILABLE |
|
||
pinance.hk | AVAILABLE |
|
$ 22 | |
pinance.in | NOT AVAILABLE | |||
pinance.it | AVAILABLE | $ 14 | ||
pinance.kr | AVAILABLE | $ 48 | ||
pinance.pt | AVAILABLE |
|
$ 29 | |
pinance.ru | AVAILABLE |
|
$ 28 | |
pinance.sg | AVAILABLE |
|
$ 36 | |
pinance.tw | AVAILABLE |
|
$ 29 | |
pinance.uk | AVAILABLE |
|
$ 12 |
How to Install and Configure MySQL Cluster on CentOS 7
https://www.howtoforge.com/tutorial/how-to-install-and-configure-mysql-cluster-on-centos-7/
MySQL Cluster is designed to provide a MySQL compatible database with high availability and low latency. The MySQL Cluster technology is implemented through the NDB (Network DataBase) and NDBCLUSTER storage engines and provides shared-nothing clustering and auto-sharding for MySQL database systems. In the shared-nothing architecture, each of nodes has its own memory and disk, the use of shared storage such as NFS, SANs is not recommended and supported.
How to Setup a Redis Cluster in CentOS 8 – Part 3
Redis Cluster is a builtin Redis feature that supports automatic sharding, replication and high availability which was previously implemented using Sentinels. It is designed for two major purposes: one is to automatically split your dataset among multiple instances and secondly to provide some degree of availability during partitions, to continue operations when some instances (especially masters) fail or are not able to communicate with the majority of nodes in the cluster.
However, the cluster stops to operate in the event of larger failures (e.g when the majority of master instances are unavailable). Also, if a master and slave fail at the same time, the cluster cannot continue normal operations (though the workaround is to add more nodes or create an asymmetry in the cluster, to auto-change the cluster layout).
According to the Redis cluster documentation, the “minimal cluster” that works as expected requires to contain at least 3 master nodes. But the most suitable setup for high availability should have at least 6 nodes with three masters and three slaves, each master having a slave.
Important: Redis Cluster also has some limitations which are lack of support for NATted environments as well those where IP addresses or TCP ports are remapped for instance under Docker. Additionally, not every client library supports it.
This article shows how to set up a Redis Cluster (with Cluster-Mode Disabled) in CentOS 8. It includes how to install Redis, configure the cluster nodes, create a cluster and test the cluster failover.
Note: For this guide, we will use fresh/empty Redis instances to run the cluster mode. The cluster mode will not work with some configurations done in the first two guides of our Redis Series, particularly it doesn’t work when the replica of the parameter is being used.
Prerequisites:
Test Environment Setup
Redis Master1: 10.42.0.247
Redis Master2: 10.42.0.197
Redis Master3: 10.42.0.132
Redis Slave1: 10.42.0.200
Redis Slave2: 10.42.0.21
Redis Slave3: 10.42.0.34
Our setup has 3 read/write master nodes and 3 read-only replica nodes, each master having one replica, so three shards contain all of the cluster’s data in each node. An application API or CLI client can write only to the master nodes but read from any node in the cluster.
Step 1: Installing Redis on All Nodes
- Log into all the instances viaSSH, then run the following command to install the Redis module using the DNF package manager as shown.
# dnf module install redis
- Next, start theRedis service, enable it to automatically start at system boot and check its status to verify that it is running (verify the service on all the 6 instances):
# systemctl start redis
# systemctl enable redis
# systemctl status redis
Step 2: Configuring Redis Instances on all Nodes
- This section describes how to configure the Redis cluster nodes. Remember to perform the configurations here on all the nodes.
Use the /etc/redis.conf configuration file to configure the Redis server. As a recommended practice, create a backup of the original file before editing it using a command-line text editor of your choice.
# cp /etc/redis.conf /etc/redis.conf.orig# vi /etc/redis.conf
- Next, find the following configuration parameters and edit their values as shown. Thebind parameter sets the interface of the Redis server will listen on, set its value to the instance LAN IP. Remove the 127.0.0.1 because we realized leaving it there slows down the process of cluster creation, particularly the stage of joining the cluster.
bind 10.42.0.247
Then set the protected-mode to no to allow connections from the other instances on the cluster.
protected-mode no
The port parameter defines the port the Redis server will listen on for connections, the default is 6379. This is the data port for communicating with clients.
port 6379
Set Redis Listen Interface and Port
- The next set of parameters will enable the cluster mode and set some of its useful features. Thecluster-enabled parameter, when set to yes, activates the cluster mode.
cluster-enabled yes
Next, the cluster-config-file parameter sets the name of a cluster node’s cluster configuration file (e.g nodes-6379.conf). The file is created in the working directory (default is /var/lib/redis defined using the dir parameter) and is not user editable.
cluster-config-file nodes-6379.conf
The next useful cluster option is cluster-node-timeout, it is used to set the maximum amount of time in milliseconds an instance can be unavailable for it to be considered in a failure state. A value of 15000 is equivalent to 15 seconds.
cluster-node-timeout 15000
Set Cluster Node Timeout
- We also need to enable Redis persistence on disk. We can use one of the persistence modes, that is theAppend Only File (AOF): it logs (in the file appendonly.aof created under the working directory) every write operation successfully received by the server. The data will be played during the server startup to reconstruct the original dataset.
To enable it, set the appendonly parameter to yes.
appendonly yes
Set Persistence Options
- After making all the changes, restart theRedis service on all the nodes to apply the recent changes.
# systemctl restart redis
- At this point, every cluster node should now have anID. You can check this in the logfile located at /var/log/redis/redis.log.
# cat /var/log/redis/redis.log
Check Cluster Node Log File
- Next, open port6397 and 16379 on all the instances. The later port is used for the cluster bus (a node-to-node communication channel using a binary protocol). This is a basic requirement for the Redis cluster TCP connections.
# firewall-cmd –zone=public –permanent –add-port=6379/tcp
# firewall-cmd –zone=public –permanent –add-port=16379/tcp
# firewall-cmd –reload
Step 3: Creating the Redis Cluster
- To create the cluster, use theredis-cli command-line client as follows. The –cluster create enables cluster creation and –cluster-replicas 1 means create one replica per master.
For our setup which has 6 nodes, we will have 3 masters and 3 slaves.
Note that the first 6 nodes will be considered masters (M) and the next three will be considered slaves (S). The first slave i.e 10.42.0.200:6379 replicates the first master i.e 10.42.0.247:6379, the second slave replicates the second master, in that order.
The following command is formatted in a way that the outcome will represent our logical setup above.
# redis-cli –cluster create 10.42.0.247:6379 10.42.0.197:6379 10.42.0.132:6379 10.42.0.200:6379 10.42.0.21:6379 10.42.0.34:6379 –cluster-replicas 1
Create Redis Cluster
Step 4: Testing Redis Cluster Failover
- In this section, we will demonstrate how to test a cluster failover. First, let’s take note of the masters.
- Once the cluster creation is successful, run the following command on any host (specify its IP address using the-h flag) to list all cluster nodes.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes
You should be able to see all the cluster nodes, with the slaves indicating their masters, as shown in the following screenshot.
Check All Cluster Nodes on Any Node
The different fields are in this order: node ID, IP address:port, flags, last ping sent, last pong received, configuration epoch, link-state, slots (for masters).
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
List Redis Cluster Masters
Also, take note of the Redis slaves.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep slave
List All Redis Cluster Slaves
- Next, let’s stop the Redis service on one of the master nodese.g 10.42.0.197 and check all master nodes in the cluster.
# systemctl stop redis
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
From the following screenshot, you can see that the node 10.42.0.197:6367 is in fail state and its slave 10.42.0.21:6379 has been promoted to master status.
Check Cluster Failover Status
- Now let’s start theRedis service once again on the failed node and check all the masters in the cluster.
# systemctl start redis
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
Check All Redis Cluster Master Status
Also, check the cluster slaves to confirm that the failed master is now a slave.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep slave
Check All Redis Cluster Slaves
Step 5: Testing Data Replication Across the Redis Cluster
- This last section explains how to verify cluster data replication. We will create a key and value on one of the masters, then try to read it from all the cluster nodes as follows. Use the-c switch to enable cluster support under redis-cli utility and access data in cluster mode.
# redis-cli -c -h 10.42.0.247 -p 6379 set name ‘TecMint.com’
# redis-cli -c -h 10.42.0.247 -p 6379 get name
# redis-cli -c -h 10.42.0.21 -p 6379 get name
# redis-cli -c -h 10.42.0.132 -p 6379 get name
# redis-cli -c -h 10.42.0.200 -p 6379 get name
# redis-cli -c -h 10.42.0.197 -p 6379 get name
# redis-cli -c -h 10.42.0.34 -p 6379 get name
Verify Redis Cluster Data Replication
The bottom line is the Redis Cluster is the preferred way to get automatic sharding, replication, and high availability. There are many other well-documented configuration parameters in the rest of the /etc/redis.conf file, you can find more information in the official documentation: Redis cluster tutorial and Redis cluster specification.
This brings us to the end of the three-part Redis tutorial series.
———————————————–
In this three-part Redis tutorial series, we will cover how to set up and use some of Redis’ key features which are replication, high availability using Redis Sentinel and Redis Cluster, the articles are:
This guide shows how to setup Redis Replication (with Cluster-Mode Disabled) in CentOS 8 Linux, including how to install Redis, configure the master and replicas, and test the replication.
Important: A Redis Cluster (i.e a Replication Cluster) with cluster mode disabled has a single node group (e.g a master and one or two replicas) wheres a Redis cluster with cluster mode enabled may consists of two or more node groups (e.g three masters each having slaves or two).
Test Environment Setup
Redis Master Server: 10.42.0.247
Redis Replica1/Slave1: 10.42.0.21
Redis Replica2/Slave2: 10.42.0.34
Logical Representation of Redis Replication Diagram
With the above setup (which has a single read/write primary/master node and 2 read-only replica nodes), we have a single node group that contains all of the cluster’s data in each node. Once a slave connects to a master, it receives an initial copy of the full database and any data that previously existed on the slave will be discarded.
Besides, a client can write only to the master but read from any node in the cluster. And as writes are performed on the master, they propagated to all connected slaves for updating the slave datasets in real-time.
Step 1: Installing Redis on CentOS 8
- To begin with, log into all theCentOS 8 nodes via SSH, then install the Redis package on all the nodes (master and replicas) using the DNF package manager as shown.
# dnf install @redis
- Upon completion of theRedis package installation, start the Redis service, enable it to automatically start at every system boot and check if it is up and running as follows.
# systemctl start redis
# systemctl enable redis
# systemctl status redis
- You can also confirm that theRedis server is up and running by checking listening ports using the ss command, as follows.
# ss –ltpn | grep redis-server
Confirm Redis Server Ports
Step 2: Configuring Redis Master Server
- Redis is configured using the/etc/redis.conf configuration file, a self-documented example configuration file. First, create a backup of the original file, then open it for editing using your command-line editor of choice.
# cp /etc/redis.conf /etc/redis.conf.org
# vi /etc/redis.conf
- By default, aRedis instance is configured to listen and accept connections on the loopback interface, using the bind directive. To communicate with the replicas, the master should be configured to listen on the IPv4 loopback address and its LAN IP address i.e 10.42.0.247.
bind 127.0.0.1 10.42.0.247
- Next, set the protected-mode parameter tono to allow communication with the replicas as shown.
protected-mode no
Also, Redis listens on port 6379 which is set using the port directive. This is the data port for communicating with application APIs or CLI clients.
port 6379
Configuring Redis Master Server
- To optionally secure themaster-replica communications, we can protect the master using the requirepass directive, so that the clients/replicas have to issue an authentication password before running any commands or starting a replication synchronization process, otherwise the master will refuse the client/replica request (remember to set a secure password).
We will use the following option for demonstration purposes, to show how it works.
requirepass Securep@55Here
Set Authentication Password
- Also, Redis logs are stored in the/var/log/redis/redis.log file, this is set using the logfile directive and the default server verbosity level is notice, defined using the loglevel parameter.
loglevel notice
logfile /var/log/redis/redis.log
Set Redis Log File and Log Level
- Sincesystemd is the default system and service manager in CentOS 8, you can configure Redis to interact with the systemd supervision tree by setting the supervised parameter to systemd.
supervised systemd
Set Redis Supervisor to Systemd
- After making all the necessary configurations, save the file and close it. Then restart theRedis service to apply the new changes.
# systemctl daemon-reload
# systemctl restart redis
- To access theRedis server, we need to use the redis-cli (a command-line interface to the redis-server). By default, it connects to the server on the localhost (at 127.0.0.1 port 6379). Note that because the server is secured from clients using a password, running a command before authentication should fail.
Use the auth command to supply the authentication password as shown in the following screenshot.
# redis-cli
127.0.0.1:6379> client list
127.0.0.1:6379> AUTH Securep@55Here
127.0.0.1:6379> client list
Access Redis Server via Redis CLI
- To connect to areplica (after configuring them as described in the next section), use the -h and -p options to specify the replica IP address/hostname and port respectively (not that port 6379 must be open in the replica’s firewall).
# # redis-cli -h 10.42.0.21 -p 6379
- Next, open theRedis server data port in the firewall to allow inbound connections to the master, and subsequently reload the firewall rules using the firewall-cmd command as shown.
# firewall-cmd –zone=public –permanent –add-port=6379/tcp
# firewall-cmd –reload
Step 3: Configuring Redis Replica/Slave Servers
- To quickly set aRedis instance as a replica on the fly, use the redis-cli utility and call the the REPLICAOF command as shown.
# redis-cli replicaof 10.42.0.247 6379OR
# redis-cli127.0.0.1:6379> REPLICAOF 10.42.0.247 6379
Connect to a Master Redis Instance
- To make a replication connection permanent, you need to make the following changes in the configuration file. Start by backing up the original file, then open it for editing.
# cp /etc/redis.conf /etc/redis.conf.org
# vi /etc/redis.conf
- To allow clients to connect to the replica to read data, add the replica IP address to the bind directive.
# replica1bind 127.0.0.1 10.42.0.21
# replica2bind 127.0.0.1 10.42.0.34
Setting a Redis Instance as a Replica
- To configure a Redis instance as areplica, use the replicaof parameter and set the master node’s IP address (or hostname) and port as values.
replicaof 10.42.0.247 6379
Setting Replica to Authenticate to the Master
- Next, since our master instance is protected using a password, we need to set the password in the replica configuration to enable it to authenticate to the master, using themasterauth parameter.
Masterauth
- Additionally, when a replica loses its connection with the master, or when the replication is underway, the replica is configured to reply to client requests, possibly with “out of date” data. But for if it the first synchronization, then the data set may just be empty. This behavior is controlled by thereplica-serve-stale-data parameter.
And, since Redis 2.6 by default replicas are read-only, this is controlled by the replica-read-only parameter. You can make other replica configuration adjustments to suit your application needs.
- Once you have made all the necessary changes, restart the Redis service on all replicas.
# systemctl restart redis
- Also, open port6379 in the firewall to allow connections from the master and clients to the replicas, and reload the firewall rules.
# firewall-cmd –zone=public —permanenent –add-port=6379/tcp
# firewall-cmd –reload
Step 4: Check Master-replica Replication Status
- Once themaster-replica replication configuration is complete, we can check if the set up is working fine as follows.
On the master, run the following commands.
# redis-cli
127.0.0.1:6379> AUTH Securep@55Here
127.0.0.1:6379> info replication
Check Redis Relocation Info on Master
- Also, check the replication status on the replicas/slaves as follows.
# redis-cli
127.0.0.1:6379> info replication
Check Redis Replication Info on Redis Replica 1
Check Redis Replication Info on Redis Replica 2
- Now let’s test the replication by settings akey-value in the master instance and check if the data is synced to the replicas.
On the master, do this:
# redis-cli
127.0.0.1:6379> AUTH Securep@55Here
127.0.0.1:6379> set domain ‘www.tecmint.com‘
by settings a key-value in the master instance and check if the data is synced to the replicas.
On the master, do this:
# redis-cli127.0.0.1:6379> AUTH Securep@55Here127.0.0.1:6379> set domain ‘www.tecmint.com’
Set Key Value in Master Instance
- Then check if the data has been synced to the replicas as shown.
# redis-cli
127.0.0.1:6379> get domain
Check Data Sync Status on Replicas
Protecting the Master Instance Against Risk of Losing Some Writes
- Redis has a feature that enables a master instance to limit the risk of losing some writes in case not enough replicas are available, to a specified number of seconds.
This means that a master can stop accepting writes if there are less than N replicas connected, having a lag less or equal than M seconds, as controlled by the min-replicas-to-write and min-replicas-max-lag options respectively.
To set them, uncomment them and set the values according to your setup requirements in /etc/redis.conf, as shown in the following screenshot. This configuration means that, from the last ping to replicas, after 10 seconds, if there are less than 2 replicas online, the master will stop accepting writes.
min-replicas-to-write 2
min-replicas-max-lag 10
Protecting the Redis Master Against Loss of Write
You can find more options in the rest of the /etc/redis.conf configuration file and for more detail read about replication in the Redis documentation.
In the next article, we will cover how to set up Redis for high availability with Sentinel in CentOS 8. Until then, stay locked and remember to share your thoughrs and questions using our comment form below is there for you to reach us.
How to Set up RabbitMQ Cluster on CentOS 7
https://www.howtoforge.com/how-to-set-up-rabbitmq-cluster-on-centos-7/
RabbitMQ is an open source message-broker software that originally implements the AMQP (Advanced Message Queuing Protocol) protocol, and while it has been developed and extended in order to support other protocols such as STOMP (Streaming Text Oriented Messaging Protocol) and MQTT (Message Queuing Telemetry Transport).
RabbitMQ is the message-queueing software that offers support for sending and receiving messages between distributed systems, applications, and services. It’s written with the Erlang programming language and supports client interfaces and libraries for all major programming languages including Python, NodeJS, Java, PHP etc.
On this page
- What we will do?
- Step 1 – Setup Hosts File
- Step 2 – Install RabbitMQ Server
- Step 3 – Enable RabbitMQ Management Plugins
- Step 4 – Configure CentOS Firewalld
- Step 5 – Set up RabbitMQ Cluster
- Step 6 – Create a New Administrator User
- Step 7 – RabbitMQ Setup Queue Mirroring
- Step 8 – Testing
- Reference
I will show you step-by-step how to set up the RabbitMQ Cluster on a CentOS 7 Server. We will set up the RabbitMQ Cluster using Three CentOS servers, enable the RabbitMQ Management, and Setup the HA policy for all nodes.
Prerequisites
- 3 or more CentOS 7 Server
- 10.0.15.21 node01
- 10.0.15.22 node02
- 10.0.15.23 node03
- Root privileges
What we will do?
- Setup Hosts File
- Install RabbitMQ Server
- Enable RabbitMQ Management Plugins
- Configure Firewalld
- Setup RabbitMQ Cluster
- Configure a New Admin User
- Setup RabbitMQ Queue Mirroring
- Testing
Step 1 – Setup Hosts File
In this step, we will edit the ‘/etc/hosts’ file on all servers and mapping each server IP address as a hostname.
Edit the ‘/etc/hosts’ file using vim editor.
sudo vim /etc/hosts
Now paste the following configuration there.
10.0.15.21 node01
10.0.15.22 node02
10.0.15.23 node03
Save and exit.
Step 2 – Install RabbitMQ Server
In this step, we will install the RabbitMQ Server packages from the EPEL (Extra Packages for Enterprise Linux) repository.
Add the EPEL repository to the CentOS 7 system.
sudo yum -y install epel-release
Now install RabbitMQ Server to all nodes ‘node01’, ‘node02’, and ‘node03’ using the yum command below.
sudo yum -y install rabbitmq-server
And after the installation is complete, start the RabbitMQ service and enable it to launch everytime at system boot.
sudo systemctl start rabbitmq-server
sudo systemctl enable rabbitmq-server
The RabbitMQ Server has been installed on all node cluster CentOS 7.
Step 3 – Enable RabbitMQ Management Plugins
In this step, we will enable RabbitMQ management plugins. It’s an interface that allows you to monitor and handle RabbitMQ server from the web browser, running on the default TCP port ‘15672’.
Enable the RabbitMQ management plugins by running the command below.
sudo rabbitmq-plugins enable rabbitmq_management
Make sure there is no error, then restart the RabbitMQ service.
sudo systemctl restart rabbitmq-server
And the RabbitMQ Management has been enabled.
Step 4 – Configure CentOS Firewalld
In this tutorial, we will enable the CentOS firewalld service, so we need to open the port that’s used by the RabbitMQ server.
We will open the port that uses the RabbitMQ server ‘5672’, the port for RabbitMQ management ‘15672’, and ports for the RabbitMQ cluster ‘4369, 25672’.
Run the following firewalld commands.
sudo firewall-cmd –add-port=15672/tcp –permanent
sudo firewall-cmd –add-port=5672/tcp –permanent
sudo firewall-cmd –add-port={4369/tcp,25672/tcp} –permanent
Now reload firewalld and check all opened ports on the list.
sudo firewall-cmd –reload
sudo firewall-cmd –list-all
The CentOS firewalld configuration has been completed, and we’re ready to set up the RabbitMQ Cluster.
Step 5 – Set up RabbitMQ Cluster
In order to setup the RabbitMQ cluster, we need to make sure the ‘.erlang.cookie’ file is same on all nodes. We will copy the ‘.erlang.cookie’ file in the ‘/var/lib/rabbitmq’ directory from ‘node01’ to other node ‘node02’ and ‘node03’.
Copy the ‘.erlang.cookie’ file using scp commands from the ‘node01’.
scp /var/lib/rabbitmq/.erlang.cookie root@node02:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie root@node03:/var/lib/rabbitmq/
Make sure there is no error on both servers.
Next, we need to setup ‘node02’ and ‘node03’ to join the cluster ‘node01’.
Run all commands below on the ‘node02’ and ‘node03’ servers.
Restart the RabbitMQ service and stop the app.
sudo systemctl restart rabbitmq-server
sudo rabbitmqctl stop_app
Now let RabbitMQ server on both nodes join the cluster on ‘node01’, then start the app.
sudo rabbitmqctl join_cluster rabbit@node01
sudo rabbitmqctl start_app
After it’s complete, check the RabbitMQ cluster status.
sudo rabbitmqctl cluster_status
And you will get the results as shown below.
On the ‘node02’.
On the ‘node03’.
The RabbitMQ Cluster has been created, with node01, node02, and node03 as members.
Step 6 – Create a New Administrator User
In this tutorial, we will create a new admin user for our RabbitMQ server and delete the default ‘guest’ user. We will be creating a new user from ‘node01’, and it will be automatically replicated to all nodes on the cluster.
Add a new user named ‘hakase’ with password ‘aqwe123@’.
sudo rabbitmqctl add_user hakase aqwe123@
Setup the ‘hakase’ user as an administrator.
sudo rabbitmqctl set_user_tags hakase administrator
And grant the ‘hakase’ user permission to modify, write, and read all vhosts.
sudo rabbitmqctl set_permissions -p / hakase “.*” “.*” “.*”
Now delete the default ‘guest’ user.
sudo rabbitmqctl delete_user guest
And check all available users.
sudo rabbitmqctl list_users
And you will get the result as shown below.
A new RabbitMQ user has been created, and the default ‘guest’ user is deleted.
Step 7 – RabbitMQ Setup Queue Mirroring
This setup is must, we need to configure the ‘ha policy’ cluster for queue mirroring and replication to all cluster nodes. If the node that hosts queue master fails, the oldest mirror will be promoted to the new master as long as it synchronized, depends on the ‘ha-mode’ and ‘ha-params’ policies.
Following are some example about the RabbitMQ ha policies.
Setup ha policy named ‘ha-all’ which all queues on the RabbitMQ cluster will be mirroring to all nodes on the cluster.
sudo rabbitmqctl set_policy ha-all “.*” ‘{“ha-mode”:”all”}’
Setup ha policy named ‘ha-two’ which all queue name start with ‘two.’ will be mirroring to the two nodes on the cluster.
sudo rabbitmqctl set_policy ha-two “^two\.” \
‘{“ha-mode”:”exactly”,”ha-params”:2,”ha-sync-mode”:”automatic”}’
Setup ha policy named ‘ha-nodes’ which all queue name start with ‘nodes.’ will be mirroring to two specific nodes ‘node02’ and ‘node03’ on the cluster.
sudo rabbitmqctl set_policy ha-nodes “^nodes\.” \
‘{“ha-mode”:”nodes”,”ha-params”:[“rabbit@node02”, “rabbit@node03”]}’
Now check all available policies using the command below.
sudo rabbitmqctl list_policies;
And if you want to remove the policy, use the following command.
sudo rabbitmqctl clear_policy ha-two
Step 8 – Testing
Open your web browser and type the IP address of the node with port ‘15672’.
Type the username ‘hakase’ with password ‘aqwe123@’.
And you will get the RabbitMQ admin dashboard as below.
All cluster nodes status is up and running.
Now click on the ‘Admin’ tab menu, and click the ‘Users’ menu on the side.
And you will get the hakase user on the list.
Now click on the ‘Admin’ tab menu, and click the ‘Policies’ menu on the side.
.
And you will get all RabbitMQ ha policies we’ve created.
The installation and configuration of RabbitMQ Cluster on CentOS 7 server has been completed successfully.
Reference