Skip to content

back to web hosting

Web Application Deployment

Whether adding a new application to an existing PubApps instance or setting up the first application in a new PubApps instance VM open a support ticket to list requirements and discuss the configuration needed to enable you to deploy your application successfully.

.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.

Deployment Checklist

This is a reference checklist for those already familiar with the procedure and the infrastructure.

  • Purpose and the intended audience for the web application you are going to run including 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. Authentication/authorization options are apache basic http auth with credential lists provided by you 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?
  • Need for 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.
  • Developer/Maintainer access: 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.
  • Optional: Location of the /installation documentation and the application source code. This is only necessary if you require our help for the initial setup.

Please read the above questions and describe your deployment scenario in the support ticket. You can reat the hosting infrastructure as a private cloud. We only a minimal involvement in the process, but

Resources

Hosting VM

Each pubapps/privapps hosting instance includes provisioning of one or more standalone VM(s) (Virtual Machines). The VM resources are based on the purchased allocations. The initial hosting VM provisioned based on a PA-Instance allocation receives 2 NCUs (2 cpu cores and 16GB of RAM). More resources can be added to the initial VM and more VMs can be provisioned via the purchase of PA-CPU and PA-GPU (if necessary) allocations. See ssh access for details on how to access the VM(s) under the instance user account. The project can run the processes they need to host their web application(s) in the VM either using standalone or orchestrated podman containers or even simple conda environments. Setting up at least two environments (prod and dev for 'production' and 'development' versionf of the web application are recommended.)

Scheduled Resources

To process data analysis requests submitted by the users of web applications the project can run the analyses in the hosting VM or submit SLURM jobs to the SLURM setup in PubApps or the HiPerGator SLURM scheduler in PrivApps. Since the Slurm command line tools like sbatch, squeue, and scancel or the industry-standard DRMAA interface like python-drmaa are standardized the same code can be developed for apps running on both the public and the private sides or even develop the app on HiPerGator before deploying into PubApps. One caveat of using the shared Slurm setup in PubApps is that there can be contention for the resources to run the jobs as the pubapps Slurm setup is shared, 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.

Software environments

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

We provide rootless podman setup and documenation for systemd control and automatic startup configurations.

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.

Application URL

It's also known as the fully-qualified domain name. We recommend selecting a name under the .rc.ufl.edu sub-domain for your application as we manage that subdomain, so it's we can add and remove names there on your request. We usually 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. A project.rc.ufl.edu domain name comes with a free SSL certificate that you will not have to worry about renewing.

It is possible to use a different top-level domain (TLD) like .org for the application, e.g. myproject.org, but you will have to manage the Domain registrar DNS records, and keep on top of SSL certificate renewal. We can generate InCommon SSL certificates for the .org domain, but doing so adds administrative burden and should be avoided if possible. You will need to notify us before each expiration date and may have to purchase consulting hours to cover the long-term support and administration costs.

Authentication and Authorization

For public (PubApps) applications you are welcome to use the authentication/authorization provided by a web application framework you are using to handle auth internally.

If requested, we can configure authentication/authorization for your entire web application or some parts (urls, endpoints like /admin or /api) using the same RC Single-Signon we use for all RC websites and web interfaces. Authorization scopes are currently limited to HiPerGator groups, all HiPerGator users, all UF Gatorlink accounts, or all InCommon Federated Users.

Basic Apache http_auth (preconfigured username/password combinations) can be configured on request.

Public applications can be completely open. Internal applications must be protected by RC SSO

Proxy Configuration

All applications that are not deployed directly on web servers must be configured to listen on selected port(s). It is your responsibilty to configure you web application to listen on the port(s) we agreed upon in the support ticket for the deployment. It is our responsibility to set up a webserver reverse proxy configuration to proxy requests made to the project URL e.g. https://project.rc.ufl.edu to the web application e.g. http://pubmygroup1:12345.

See the following diagram for a visual representation of reverse proxying:

Reverse Proxy Architecture Diagram

Application Configuration Examples