Install OpenRose on Network Computer(s)
Multi-user Corporate Network / Team installation of OpenRose - Requirements Management - An Open Source and FREE Requirements Management Application / Tool.
- OpenRose WebUI front-end
- OpenRose API back-end
- SQL Server Database
Video Transcript :
Hello,
Today we are going to talk about installing OpenRose in a network environment. The first scenario we will discuss is installing all the required components on a single computer, which could be a server or a desktop computer. We will start by making sure that the required components for OpenRose to run are present in the target environment.
The reason for discussing this today is to provide an overview of how this installation can be implemented and how it can help corporations or teams with network-connected computers. This will essentially allow multiple users to connect to OpenRose over a browser URL pointing to one of the servers within the network, within your company, or within the team that is connecting and using OpenRose for requirements management purposes.
On the target computer, which could be a Windows server or a desktop computer available on the network, you should install IIS. Inside IIS, you install two separate applications: OpenRose Web UI and OpenRose API. On the same server, you can also install SQL Server, which acts as the database.
Once these three components are installed, we need to establish connections between them. The Web UI connects to the API using the localhost API URL, which will be implemented in the `appsettings.json` file. OpenRose API connects to SQL Server using a connection string.
Every application deployed in IIS runs under an "Application Pool", and an "Application Pool Account" is created in Windows. You can use the inbuilt IIS pool account to authenticate OpenRose API to SQL Server. The first option is to connect or authenticate the API to SQL Server using the application pool account itself. The advantage of this option is that you don't have to remember any user ID and password; it is all self-contained. When you upgrade the OpenRose API application, you don't need to provide the user ID and password or maintain the `appsettings.json` file. Another advantage is that you never store user IDs and passwords in plain text or any secured form; it all uses integrated security or a Windows integrated account, which is the application pool account.
We will also discuss domain service accounts later on, where we may expand this scenario to deploy different components on different computers. The second option in SQL Server is to authenticate users using both Windows identities and SQL Server user accounts or service accounts. You can use the user ID and password defined in SQL Server and provide this information in the connection string, which could be within the `appsettings.json` file or an environment variable on the computer where you are deploying OpenRose API.
I'm providing this information today to ensure you understand how to deploy OpenRose in a network environment. You might require help from your IT team or people who are hosting applications on your network computers to assist with the final installation. If you do not have access to such network environments or target environments with IIS, or if you do not have access to domain services where you create service accounts for establishing a connection between OpenRose API and SQL Server, you'll need to seek additional support.
Let's look at the scenario where everything is installed on the same computer. I'll start by showing that I have deployed the two applications: OpenRose API and OpenRose Web UI. The Web UI communicates with the API using the `appsettings.json` file, where you define the information about the API application.
First, I'll show the bindings, where port number 7673 is used for binding the OpenRose Web UI application. The directory in which the application is deployed contains the `appsettings.json` file, which shows the connection to port number 6736, where the API application is expected to run.
Next, I'll show the bindings for the API, where port number 6736 is configured to communicate or listen for incoming requests. In the `appsettings.json` file for the API, you will see the default connection string provided by the installer, which we will override. There are two ways to override this value: directly in the `appsettings.json` file or through an environment variable.
The environment variable in the system specifies the connection string, indicating that SQL Server is on the same computer named "BAGHEERA" and using SQL Express as the database server, with the database named "OpenRoseDB". I'm not passing any user ID and password, which means I'm using the inbuilt Windows Integrated Security and the application pool account.
In IIS, the OpenRose API site uses the OpenRose API application pool, which is defined in Windows' identity. The application pool account will be used to communicate with SQL Server. To use the application pool account for SQL Server, we must add this account as a DB owner for our database.
First, add the application pool account to the local computer and then to the database. You can do this manually or use a provided script available in the OpenRose wiki, replacing the application pool name appropriately.
The second option is to use SQL Server user ID and password authentication. In SQL Server properties under security, you can configure it to allow users to connect using either Windows authentication or SQL Server. Create a user ID and password, then provide this information in the connection string within the `appsettings.json` file or as an environment variable.
With these configurations, you can deploy OpenRose in a network environment effectively. Okay so with that uh, we have already discussed how we could deploy all the components on a single computer. Now, let's start the IIS. So far, my IIS was stopped, so you can see nothing is running; the entire server is stopped. Let me just go back to the browser and verify that port number 7673, the localhost port number, is not accessible; it's not working. If I just try to start this or try to connect to that location, it will obviously fail. As you can see, I can't reach that page.
Let's go back to IIS and start it. I'm using the Windows integrated communication method between the API and the database, so I don't need to pass any user ID and passwords. Now that I have started the server, I should be able to connect to port number 7673, which is the port number on which these applications are running. Port 7673 is for the Web UI, which is why I'm able to connect and see the Web UI. When I go to the project, the Web UI communicates with the API and brings me all the information about the projects, which means the API is communicating with the database.
I'm still using the localhost URL here, but if your IIS and the Windows server where you install this application are in the corporate network, you will be provided with the correct URL by your IT administrator. This will allow you to communicate directly to that specific network URL. It will mostly be deployed on the default port number 80, meaning it will be the default site on that IIS instance, so you won't have to provide any port number (in your URL. e.g. http://BAGHEERA/). If your IT administrator decides to install and configure it on a different port, they will provide you with the correct URL to communicate and work with OpenRose on that specific network address.
With this, we covered the entire possibility of deployment in a network environment on IIS on a single server. The other option is to install a separate instance of SQL Server. Here, I will show that we have a separate computer on the network, and I would like my database to be sitting somewhere else, not on the same server where my web application is sitting.
You could easily implement this. In this case, you could use option number two, where you have SQL authentication. Create the user in SQL Server and provide the user ID and password in the connection string so that the API application can communicate with SQL Server. If you don't want to do that, you could create a domain service account in your network domain, and that service account needs to be configured both in IIS and SQL Server so that it can be authenticated. The API can be authenticated against SQL Server with domain services. You maintain the user ID and password of that service account in Active Directory or the domain services, which is another option you could incorporate.
The third option is having your front end on a separate instance or environment, and your back end on a separate instance. We have three computers: two of them have IIS installed. Our Web UI, the front end where all users connect, is on its own server, so there is only one application pool containing that specific application. On a separate server, you will have OpenRose API installed.
When you do it this way, the communication between the Web UI and the API will not be via localhost URL but the URL of the API. In your IIS, if the API is not on the same server, the Web UI's URL for the API will be the specific instance URL of IIS.
For SQL Server, you can use either domain services or SQL Server user ID and password, both of which can be used in the connection string that can be set through the environment variable. This topology can also be incorporated to allow OpenRose to deploy in a multi-tier environment within your corporate network.
To conclude, this information should help your technical team decide how they want to deploy OpenRose in your network. The architecture of the application enables administrators to be more flexible in deciding how to implement it based on your requirements and network capabilities.
Thank you for your time, and have a great day.
Bye now!
Comments
Post a Comment