This article is now 5 years old! It is highly likely that this information is out of date and the author will have completely forgotten about it. Please take care when following any guidance to ensure you have up-to-date recommendations.
One question I’m asked quite a lot is what I use for a 3-tier application when I’m testing things like NSX micro-segmentation with vRealize Automation. The simple answer is that I used to make something up as I went along, deploying components by hand and generally repeating myself a lot. I had some cut/paste commands in my note application that sped things up a little, but nothing that developed. I’ve been meaning to rectify this for a while, and this is the result!
A lot of this is based on the excellent blog posts published on the VMware HOL blog by Doug Baer. Doug wrote five parts on creating his application on Photon OS and they’re well worth a read (start at part 1, here). I have changed a few things for my vRA Three Tier App, and some things are the same:
I’m using CentOS7, as that’s what I see out in the wild with customers (RHEL7) and I am most familiar with
I am including NSX on-demand load balancers in my blueprint, but you don’t actually need them for single-VM tiers
Finally, I want to be able to deploy my 3-tier application using vRA Software Components (though you can also use startup scripts in the customisation spec)
Based on this, my final application will look something like the image below, with clients connecting to the NSX load balancer on HTTPS/443, multiple NGINX reverse proxy servers communicating with the NSX load balancer on HTTP/8080, which is in front of multiple Apache web servers running the PHP application which all talk to the MySQL databased back end over MySQL/3306.
When in use, the application looks like this:
CentOS 7 Template
At the core of my three tier application is the CentOS 7 template, which has been prepared with open-vm-tools and the vRealize Automation Guest Agent (gugent). The installation was completed by following the Install the Guest Agent on a Linux Reference Machine document. The Guest Agent can be tricky to install, so use the prepare_vra_template.sh script and validate the downloaded IaaS Manager Service Host certificate.
I also have a software component that performs infrastructure tasks on my CentOS VMs, such as updating when they are first deployed.
Database Server Installer Script
The Database installer script (DBServer.sh) performs the following tasks:
Install the mariaDB server
Generates a secure password for the application to use
Secures the database installation (equivalent to running the “mysql_secure_installation” script) and root account
Creates the app database and the app user based on input variables
The two configuration files that are downloaded are available from my GitHub repository, one is a configuration file for the NGINX reverse proxy, which is placed in the /etc/nginx/conf.d folder. I don’t make any changes to the default NGINX configuration.
Creating the vRealize Automation Software Components
The next step is to create three Software Components, one for each tier of the application.
Demo App Database
The Database Script has five properties, four of which will be inputs for the end user, one of which is computed.
mysql_app_database - the name of the MySQL database to create
mysql_root_password - the password to set for the MySQL root user
mysql_bind_address - the address MySQL should listen on (this is bound to the database server’s IP in the blueprint later)
mysql_user_password - this is set as a Computed Value because the script auto-generates a password. Setting it to a Computed Value lets us bind to the property later in the blueprint to pass to other components)
mysql_user_name - the name of the MySQL user to be created for the app
Demo App Application
The application tier install component has four inputs, which will be directly mapped to the properties for the database component
demo_app_mysql_server - the IP address of the MySQL database server
demo_app_mysql_user - the MySQL user created for the application
demp_app_mysql_password - the generated password for the MySQL user
demo_app_mysql_database - the name of the MySQL databsae
Demo App Web
The web tier install component has two inputs for the script, which can be either mapped to the tier server IP addresses (for single node deploys) or to the load balancer IP addresses (for multi-node deploys).
web_server_name - the name or IP of the web tier (server or load balancer)
app_server_name - the DNS name or IP of the app tier (server or load balancer)
Creating the vRealize Automation Blueprints
Now that all of the building blocks are in place, I can create the Blueprints that will tie it all together.
For the multi-node deployment, the blueprint looks like this (running from left to right):
An on-demand routed network (though any network will be fine)
web_tier_lb - an on-demand load balancer to front the web_tier
web_tier - a vSphere Machine using my CentOS7 template, configured as 1-3 VMs
CentOS7_OS_Config - configures and updates my template, not strictly required!
Demo_App_Web - the Demo App Web software component
app_tier_lb - another on-demand load balancer to front the app_tier
app_tier - a vSphere Machine using my CentOS7 template, configured as 1-3 VMs
CentOS7_OS_Config - configures and updates my template, not strictly required!
Demo_App_Application - the Demo App Application software component
db_tier - a vSphere Machine using my CentOS7 template, configured as 1 VM only
CentOS7_OS_Config - configures and updates my template, not strictly required!
Demo_App_Database - the Demo App Database software component
Note the lines depicting build dependencies - the Web depends on the App, which depends on the DB.
The custom property mapping for the database tier lets the user specify the database name, root password and app user name in the request (Show in Request, Overridable) while providing some default values. The MySQL bind address is bound to the _resource~db_tier~ip_address property, which will be the IP address vRA assigns to the database server.
All of the custom properties for the application tier are bound to property values from the database tier, so that the PHP file is updated with the database server configuration (server, database, user and password). These properties are hidden from the user as they’re bound.
The two inputs for the web tier custom properties are mapped to the load balancer IP addresses for the web and app tier load balancers.
To create a single-node blueprint of the application there’s only one difference - the web tier properties are mapped directly to the web_tier and app_tier IP addresses.
Deploying and testing the three tier Demo App
Once the blueprint has been published and assigned to a catalog, service and entitlement, it’s time to deploy and test the app! Below you can see the deployment form, and the configuration of the database install script.
The deployed blueprint looks something like this - you can see that the web tier load balancer has an IP address of 10.0.0.210.
And when I hit the load balancer IP, the application loads!
And finally…
All of the vRA components have been exported using CloudClient and are also on the GitHub repo if you want to import them. Since this post is getting pretty long, I’ll draw it to a close here - hopefully this is of some use to you - please feel free to leave me a comment or ping me on twitter if you have any questions!