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

Application Configuration Examples

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

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

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 options 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 instead of RC SSO.

Public applications can be completely open. However, private web applications must be protected by RC SSO as shown in the infrastructural diagram for PubApps.

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 Diagram:

Shared Scheduled Resources

The hosted applications 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.

Software environment

All PubApps and PrivApps VMs run RedHat Enterprise Linux 9 Operating System. You can use conda environments and containers (Podman) for the applicatio deployment. We provide rootless podman setup and documenation for systemd control and automatic startup configuration.