Skip to content

Web Application Hosting

Introduction

This is not a generic web hosting service

HiPerGator Web Application Hosting a.k.a. 'PubApps' is not intended to be a generic web application hosting service. Use UFIT T4 CMS Hosting, UFIT Apache Hosting, or UFIT VM Hosting] for document or generic web application and service hosting. PubApps hosting infrastructure is intended primarily for Research web applications that

  • have significant computational and database needs.
  • showcase research and data produced on HiPerGator.
  • may or may not need HiPerGator integration.
  • were developed with the help of the UFIT RC Research Software Engineering team.
  • have specific access requirements (public or restricted to HPG users/groups or UF departments).
  • require GPUs for machine learning model inference.
  • need to be connected to data-producing hardware at the university.

as some of the examples.

The purpose of PubApps is to provide a kind of 'long-tail' service and infrastructure that cannot be obtained or set up elsewhere or requires access to data/computational resources on HiPerGator. It can give UF Research Computing customers a competitive edge for top-tier research and presentation of research.

If unsure, please reach out to use via Support System or one of the options listed in RC Remote Support documentation, so we could discuss your project and determine whether it's appropriate for PubApps or if we could refer you to one of the UFIT hosting solutions or external resources such as cloud hosting. Additionally, we're happy to discuss your application architecture and deployment options as a part of determining the feasibility of hosting the application in PubApps.

Architecture

PubApps Infrastructure Diagram:

Purchasing

Before application(s) can be deployed in pubapps a PubApps instance must be requested via a Trial Allocation or purchased via the HiPerGator Service Purchase form for $300 per year. If additional resources are required CPU/memory (NCU), storage units (in TB), and GPUs can be purchased in the same manner and with the same pricing as HPG NCU, BlSU, and NGU resources on HiPerGator. Each instance includes up to 2 virtual CPU cores, 16GB of memory, and 1TB of disk space on the public side or 40GB of space on the private side.

PubApps Instance Provisioning

Once a group has a PA-Instance allocatin one of the group members may open a support request for creation of a PubApps instance and to delineate the deployment options. A PubApps instance consists of a project user account, storage quota, and setup of ssh keys for group member access from HiPerGator. In addition, ssh linger and rootless podman configuration are set up for the pubapps project user.

Web Application Deployment

Whether it's an existing PubApps instance or the first application is being deployed alongside the initial PubApps instance creation use the support ticket to discuss any configuration we need to provide to enable you to deploy your application.

.rc.ufl.edu sub-domain and SSL Certificates are free

Here are the questions and options you should consider for application deployment within a PubApps instance.

Application URL

This is also know as the fully-qualified domain name. The easiest approach is to select a name under the .rc.ufl.edu sub-domain for your application as it's trivial to add and comes with an SSL certificate that you will not have to worry about renewing. It is possible to use a different domain like .org for the application, but you will be required to manage the Domain registrar DNS records. We can generate InCommon SSL certificates for .org domains, but doing so adds administrative burden and should be avoided if possible. We usully set up both project.rc.ufl.edu and devproject.rc.ufl.edu names, so you have a production and a development instance of each application.

Authentication and Authorization

We reverse-proxy all applications through a load balancer and can configure an authentication/authorization layer in front of your entire web application or some parts (urls, endpoints) of it based on the same UFRC Single-Signon we use for all UFRC websites and web applications. The options for protection include selected HiPerGator group(s), all HiPerGator users, or all UF Gatorlink accounts. Of course, basic Apache http auth (preset username/password) can also be configured. Public applications can be completely open, but private applications must be fully behind SSO as shown in the infrastructural diagram for PubApps.

Deployment questions

  • Purpose and the intended audience for the web application(s) you are going to run.
  • Access restrictions:
  • Public Open: Visible outside of the UF network. There are no access restrictions or authentication is used only for administrative urls.
  • Public Restricted: Visible outside of the UF network. Authentication is required for access to the application (Apache basic http auth or UFRC single signon with the following possible restrictions: All UF Gatorlink account holders, all HPG users, particular HPG group(s)).
  • Internal: Visible only on the UF network or via UF VPN. Authentication is required for the entire application. Apps on the internal side of PubApps (PrivApps) are expected to be integrated with HiPerGator computational and storage resources and cannot be accessed by public.
  • Resource requirements. A pubapps instance includes 2 NCUs and 1TB of combined filesystem and database storage. Additional computational and storage resources must be purchased.
  • Database requirements: Type(s) of the backend database(s) used if any.
  • Computational requirements: Will your code submit SLURM jobs, need to run in a separate VM, or be run on a shared backend sever? Can the application on the webserver if it only needs database access and no computation?
  • Do you need HiPerGator filesystem access (only for internal applications in standalone VMs with defined resources and not the larger shared PubApps webservers because of security considerations).
  • URL: Suggested domain name e.g. myresearchapp.rc.ufl.edu for the requests to be proxied to the application running on a pubapps server.
  • HiPerGator username(s) of the developer(s)? We use this information to set up the initial ssh access to the pubapps server afer which authorized developers can manage ssh key access for other group members.
  • Application dependencies (optional): Let us know if you need some help setting up conda environments or containers for the application dependencies.
  • Location of the /installation documentation and the application source code (optional): Only necessary if you require our help for the initial setup.

Additonal Considerations

PubApps Virtual vs Shared Hosting Infrastructure

As you can see from the architectural diagram the approach we took to the PubApps infrastructure is a 'curated cloud like experience' for web application deployments. We provide a platform, but it's up to you to choose how to deploy and run your application to make sure you work is productive and the application is stable, scalable, and efficient. You should consider what resources to use for the application front-end, back-end, and any worker type processes and select carefully from the options that include

Scheduled Resources

The application can submit SLURM jobs to the SLURM setup in PubApps or the HiPerGator SLURM scheduler in PrivApps, so you can develop and use the same code for both sides or even develop the app on HiPerGator before deploying into PubApps. * Pro: The advantage is a stable interface using standard slurm commands like sbatch, squeue, and scancel or the industry-standard DRMAA interface like python-drmaa, which we use ourselves and encourage you to check out. * Con: The disadvantage is that there can be contention for the resources to run the jobs, so you have to implement an asynchronous approach to running workfloads and be able to notify the users when the work is done to deliver the results.

Shared Resources

The pubcontainer nodes are large servers that can host many web applications whether deployed via simpler methods like conda environments or with full Podman orchestration (Docker is not available as it conflicts with RHEL-native podman in the system images). These nodes also have attached GPUs that are assigned to particular pubapps instances when purchased. * Pro: The advantages include being able to run long-term workloads from the web application backend processes without developing additional methods to submit scheduled jobs. As pubcontainer nodes are shared systems even if an application exceeds the resources that were paid for in short bursts there is enough capacity in the servers that the performance of other applications should not be affected. * Con: There is a limited number of GPUs available for purchase and use by the web applications. There is strict control over GPU access. There is a potential of excessive resource use to affect other applications.

VM Resources

Using a standalone VM (Virtual Machine) is a good solution for when the project needs dedicated resources, has more stringent security requirements, and may be running applications that are created to serve their every component (web application itself, database server, other services) from a single machine, etc. In short, if an application doesn't play well with others it should be in its own VM. On the PrivApps side, any application that has requirements beyond being a lightweight front-end interface that does database querying or is only used to submit jobs to SLURM and display the results (e.g. CryoSPARC) has to be hosted in a VM. * Pro: The advantages include stronger isolation from other applications, both security and resource-wise, defined resources. * Con: The disadvantages include longer setup time as each VM has to be provisioned by the DevSecOps group, resource constraints as there are no shared resource to burst to, no GPUs.

Software environment

All PubApps and PrivApps VMs and servers run RedHat Enterprise Linux 8 Operating System. You can use conda environments and containers (Podman and Apptainer/Singularity) for the applicatio deployment.

CI

We suggest setting up CI (continuous integration), so code changes in an external git repository get applied to the application. This approach allows limiting access to the hosting environment while a potentially large number of developers can work on the application code locally.