Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This article explains how to set up a multi-node Atlassian Jira Datacenter Cluster locally using a reverse proxy as a load balancer (Apache httpd or NGINX), hosts file to resolve a name into an address, and PostgreSQL as a database server for Jira and RMsis.

\uD83D\uDCD8 Steps involved in the deployment process

  1. Prepare the PostgreSQL server to accept connections from multiple hosts.

  2. Prepare Apache httpd or NGINX server as a reverse proxy for Jira.

  3. Add entries to the host file to resolve a custom domain to an IP address.

  4. Install Jira in a reverse proxy configuration with a custom context path.

  5. Create a shared home directory for multiple nodes of Atlassian Jira.

  6. Re-configure Jira Installation to work in a cluster.

  7. Re-configure the reverse proxy server to work as a load balancer for the Jira Cluster.

  8. Add multiple nodes to the cluster.

  9. Install RMsis on one node of the cluster.

Although multiple steps can be clubbed into one, the steps listed here are independent of each other for easy understanding and debugging so that the focus remains on one problem at a time.

Preparing PostgreSQL server

Install PostgreSQL as per your OS by downloading it from the official website. Use homebrew or Postgres.app if you are on Mac OS. Keep note of all the paths involved during the installation and the password to access it later.

The default installation restricts the server access to the local instance only i.e it is configured to be bound to "localhost". Any request to access the database from any other host on the network will be denied. It is used to store data from Jira and RMsis servers.

The default PostgreSQL configuration works for single-node installation where Jira, PostgreSQL, and RMsis servers are installed on the same host but fails if the database server is installed on a separate host or if multiple nodes of the cluster are on separate hosts.

In order to allow access from the different hosts on the network, the PostgreSQL server must be configured to allow connections from other hosts on the network. This requires changes in two different PostgreSQL configuration files, namely postgresql.conf and pg_hba.conf

  1. Update postgresql.conf file

    • Location: Depending upon the OS and installation option, the location of this file varies. Do a google search to find the location of this file as per your OS and the installation option used.

    • Configuration to change: This file contains multiple options for PostreSQL database settings but we are only interested in listen_addresses property. This variable controls which IPs the server will answer on, not which IPs the server will permit connections to authenticate from.

    • Updated Value: Update the value of the listen_addresses property by replacing localhost with * and ensure that this line is not commented by removing the # symbol before this line. This is the most common mistake done by first-time users. The updated file should look like the image below.

    • Save and restart PostgreSQL This is necessary to apply the changes. The simplest way is to restart the PC or look for the restart command as per your OS and installation option.

  2. Update pg_hba.conf file

    • Location: Depending upon the OS and installation option, the location of this file varies. Do a Google search to find the location of this file as per your OS and the installation option used.

    • Configuration to change: This file is used to control access at a finer-grained level for which IPs the server will accept logins from for specific databases and users. We are interested in entries corresponding to IPv4 and IPv6 hosts.

    • Updated Value: We need to specify the addresses of the hosts which must be allowed to access the database along with the method for user authentication. Add the following entries:

      host    all             all              0.0.0.0/0                       md5
      host    all             all              ::/0                            md5

      The updated file should look like the image below. Save and restart PostgreSQL to apply the changes.

Create a Reverse Proxy server for Jira

A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. Visit this link to learn more about proxy and reverse proxy servers.

In practical implementations, if you see any named URL without a port number. It suggests that a reverse proxy is in use. For example, if Jira is running at http://localhost:8080/jira, we can use a reverse proxy to access it at http://jira.example.com/jira or https://jira.example.com/jira

If no port is specified in the URL, it defaults to port 80 for HTTP and port 443 for HTTPS connections.

We can use Apache httpd or NGINX to redirect requests from browsers to Jira or RMsis depending upon the context path(/jira for Jira and /rm for RMsis) in the URL. The reverse proxy intercepts each request and forwards it to the respective application.

  • This process has the additional advantage of accessing multiple applications using the same URL. For example, if we have multiple applications running on the same or different PC on the network. All these can be accessed using a single URL. Notice the common part http://my.atlassian.com in each URL which helps in hiding the implementation details like the application server IP address and port number.

  • We can also change HTTP requests into HTTPS requests using an SSL certificate to expose them to the end user. Notice how the above applications are running on HTTP but they are accessible over HTTPS.

  • This approach helps in avoiding the CORS issue as well which allows or restricts communication between two different applications based on various browser policies.

Install Apache httpd or NGINX on your system and add the necessary configurations for the redirections.

For Apache httpd

Find the location of httpd.conf file as per your OS and installation method and insert the following configurations.

Usually, it’s located at the following location: etc/httpd/conf/httpd. conf

Note: Do not forget to add / at the end of http://localhost:8080 as some of the URLs will break if we miss it. For example, http:/jira.example.com/icons/logo.jpg will change to http:/localhost:8080icons/logo.jpg instead of going to http:/localhost:8080/icons/logo.jpg. Notice the missing / between 8080 and icons

<VirtualHost *:80>
    #URL from which the application will be accessed 
    ServerName jira.example.com
     
    ProxyRequests Off
    ProxyVia Off
     
    <Proxy *>
         Require all granted
    </Proxy>
    
    #For Jira server running on port 8080
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/

    # Optional: Specify location for log files to ease debugging
    ErrorLog "/private/var/log/apache2/jira.example.com-error_log"
    CustomLog "/private/var/log/apache2/jira.example.com-access_log" common

</VirtualHost>

It is recommended to create a new configuration file and add a reference to the httpd.conf file. See attached image where these configurations are added to jira-vhost.conf file inside <APACHE_ROOT>/extra directory and the reference is added in the httpd.conf file

Please note we have not yet changed the context path of Jira. It is running in its default context of / and it can be accessed simply by using the URL http://localhost:8080/

For NGINX server

Find the location of ngnix.conf file as per your OS and installation method and insert the following configurations.

Usually, it’s located at the following location: /etc/nginx/nginx.conf

server {
          listen 80;
          server_name jira.example.com;

          #Configuration for JIRA (running on port 8080)
          location / {
                        proxy_set_header X-Forwarded-Host $host;
                        proxy_set_header X-Forwarded-Server $host;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_pass http://127.0.0.1:8080; 
                }
}

sdgs

 

asfasfd

fhsdg

sdg

sdggsdg

sdgsdg

sdgsg

sdgsg

wetwet

  • No labels