Skip to content

Example deployments

These are examples of how one can use cloud resources for different types of deployments, along with examples of software that can be useful in this context. If you are not sure how to carry out your deployment in a secure and efficient way, or want suggestions for software to meet your requirements, you can contact support.

Generally, we recommend splitting up your deployments between a few machines, taking heed of which machines need to have, e.g, public IP:s and which machines contain the most valuable data and should be backed up frequently. Because OpenStack automatically creates a per-project private network (which functions similar to a LAN), it is easy to deploy machines which communicate only with other machines in the same project.

There are a few advantages of setting things up like this, one is that it is typically easier to maintain, update and replace smaller machines that carry out a small number of tasks. Moreover, it is easier to keep track of each machine's resource usage and scale their size accordingly. Finally, it is more secure, as only services on machines explicitly given a public IP can be exposed to the public internet.

Remote desktop provider

This is an example of a setup that provides remote desktop VM:s for users.

  • rd-proxy, a Small VM running Apache Guacamole, and perhaps an RDP gateway. It also runs a web application secured with mod_auth_openidc which controls what users are allowed to login, and where they can connect to. The server holds API keys to the OpenStack environment and can create new VM:s based on a snapshot, pre-configured for remote desktop work, which users can use to create new remote desktops as they require, and do limited management, without having to access the OpenStack UI.
  • rd-lldap, a Mini VM running LLDAP providing directory services
  • rd-auth, a Mini VM running KeyCloak for authentication. Has a public IP, but only accessible from limited IP ranges. It gets user information from rd-lldap and exposes it to rd-proxy. It also runs any middleware necessary to enable OpenID Connect-based logins to a remote desktop.
  • rd-work-#, VM:s of preferred size that users can connect to. Using LLDAP one can set users up with custom attributes that control which VM:s they can and cannot connect to or manage with the web UI. The remote desktop machines do not need to be exposed to the internet, as the proxy allows them to tunnel in.

This would cost (3 * 0.72 + 2.16) k-coins / 30 d = 4.32 k-coins/30 d as a baseline, plus the cost for whatever virtual machines the users run. For example, 2 Large and 1 XLarge machine would add a cost of (2 * 8.64 + 34.56) k-coins/30 d = 51.84 k-coins/30 d This is an example of a deployment combining existing Open Source software with custom middleware and the features that cloud compute offers, in order to achieve functionality that would not otherwise be possible.

Full-stack web application with development environment

This is an example of how a full-stack web application could be deployed using cloud resources.

  • app-entry, 1 Mini VM, an SSH jumphost. Has a public IP and listens to port 22 on the Chalmers subnet. The root user on this host has an ssh key that allows it to connect to the other VM:s in the project on the internal network.
  • app-db, 1 Medium VM dedicated to running a Postgresql database cluster accepting connections on the 10.10.10.0/24 network. Perhaps some of the queries the application carries out are quite heavy, so the database is on the larger side.
  • app-prod and app-dev, 2 small VM:s running development and production versions of the application. They both use different databases on the app-db Postgresql database cluster. They both listen only on the internal network.
  • app-monitor, a Mini VM that runs a monitoring software like Zabbix, allowing easy monitioring of each VM and its services through a web UI via e.g. SSH tunnelling from app-entry.
  • app-proxy small VM running the reverse proxy nginx, listening on a public IP to the world on ports 80 and 443. It also runs ModSecurity, fail2ban and nftables, banning IP:s engaging in suspicious activity. It proxies connections to either app-prod or app-dev depending on the URL, but only allows connections from chosen IP:s to app-dev.

In total, we have 2 Mini, 3 Small and 1 Medium VM. The 30-day cost in coins for this would be (2 * 0.72 + 3 * 2.16 + 4.32) k-coins/30 d = 12.22 k-coins/30 d. There are many ways one could spin this up -- the prod and dev apps could have their own databases and be a bit larger, nginx could run on two separate hosts with two separate public IP:s, and so on.

Internal data sharing and collaboration platform

This example considers a platform used by a larger research group collaboration which is perhaps divided across several countries hosting a platform to share small to moderately sized data and documents with one another.

  • ds-wg -- a Mini VM running Wireguard. It listens to a wide range of IP:s on a random but known UDP port on a public IP. All users are connected to it so that they can access the internal OpenStack network, and this is the only VM listening to a public IP.
  • ds-nfs -- A Medium VM running as an NFS server, exposing block storage as network-accessible storage volumes.
  • ds-ocis -- A Medium VM running OwnCloud InfiniteScale for file hosting, sharing and collaboration using the NFS VM for its storage.
  • ds-auth -- A Mini VM running either KaniDM or KeyCloak and LLDAP for authenticating users and providing the directory service.
  • ds-monitor -- A Mini VM running Zabbix for monitoring.
  • ds-work -- A Large VM running xrdp for remote desktop access and also mounting network shares over NFS, allowing users to log in and work using a shared platform without always having to download files to local storage, perhaps running simple analysis on a shared platform.

This project would use (3 * 0.72 + 2 * 4.32 + 8.64) k-coins/30 d = 19.44 k-coins / 30 d. In this case, Wireguard was used to create an secured environment, with OpenID Connect authentication to distinguish between users. Of course, if it is necessary to access the services from environments where wireguard cannot be run, a more standard set of firewall rules would be a better approach. Or one can combine the two, with firewall rules permitting acccess from a select few networks, and WireGuard being used for the remainder.