hyte-web-dev

Cloud Services and Application Deployment

Cloud services and environments

Cloud computing models provide different levels of control, flexibility, and management. The three primary models are:

  1. Software as a Service (SaaS)
    • SaaS delivers software applications over the internet, on a subscription basis. The applications are hosted and managed by the service provider.
    • End-users can use the software but don’t manage the infrastructure or platform running the application.
    • Examples: Google Workspace, Microsoft Office 365, Salesforce, Dropbox.
    • Ideal for businesses that want ready-to-use applications without worrying about installation, maintenance, or infrastructure.
  2. Platform as a Service (PaaS)
    • PaaS provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.
    • Users manage applications and data, while the provider manages runtime, middleware, operating system, virtualization, servers, storage, and networking.
    • Examples: Heroku, Google App Engine, Microsoft Azure App Services.
    • Suitable for developers who want to focus on their software and data without dealing with servers, storage, and networking.
  3. Infrastructure as a Service (IaaS)
    • IaaS provides fundamental computing resources such as virtual machines, storage, and networks over the internet. Users have control over their infrastructure, similar to traditional physical data centers, but it’s available over the cloud.
    • Users have control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
    • Examples: Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine (GCE).
    • Ideal for companies needing complete control over their infrastructure but want to avoid the cost and complexity of managing physical servers.

SaaS is like renting a house - you use it as it is, without worrying about maintaining it. PaaS is like renting the land and building your house - you control the house but not the land it’s on. IaaS is like leasing/buying a plot of land - you have full control over the land and what you build on it, but you don’t own the land.

Public vs. Private

Cloud services can be deployed in different ways, primarily categorized as public, private, or hybrid clouds.

Cloud deployment models

Running environment

In server-side applications, the running environment, often referred to as the “runtime environment” or simply the “runtime,” is the software and hardware infrastructure where the server-side code of an application executes. This environment provides the necessary resources and services for the server-side code to run, handle requests, process data, and generate responses. The choice of a running environment depends on various factors, including the programming language, framework, and the specific requirements of the application.

The choice of the running environment components depends on factors like the type of application, expected traffic, scalability requirements, and the technology stack being used. Designing a robust and efficient running environment is essential for ensuring the reliable operation of server-side applications.

Installing a Virtual Server on Azure cloud environment (IaaS)

Browse, read, watch & study (optional but useful):

Help for Linux usage (for managing your Ubuntu VM, same concepts apply for other Linux distributions too):

Getting started & setting up the environment

  1. Sign up for a free student account using your school email address & login, you should get some free credits (100 USD), more info
  2. Go to Azure portal
  3. Create a resource: Virtual machine (VM) with following settings:
    • Choose your subscription (Azure for Students)
    • Create new resource group, e.g. web-project-rg
    • Virtual machine name: e.g. my-web-server
    • Region: choose the closest one
    • Availability options: No infrastructure redundancy required
    • Security type: Standard
    • Image: Choose a Linux server image, e.g. latest Ubuntu Server LTS
    • Select VM size & disks according your needs (Think about what is the minimum for a web server? Check the OS system requirements, etc.)
      • ‘Standard_B1ms’ is the teacher’s recommendation for this course
      • NOTE: you have 100 USD of student credits to spend in total (for a one year)
    • Authentication type: Password (or SSH public key if you prefer that), this is the admin user account for the VM
    • Public inbound ports: Allow access to SSH, HTTP and HTTPS ports
    • For other settings you can leave the default values
    • Disk tab: Change OS disk type to Standard SSD
    • Networking tab: Make sure that a new public IP address & subnet is created, default settings are ok
    • Management tab: default settings are ok, automatic shutdown can be useful in order to save credits
    • Click Review + create and check that all settings are ok
  4. Finally hit the CREATE button and wait for the VM deployment to finish
    • After successful deployment of the virtual machine go to the resources’s Overview page and configure the DNS name for your public IP address.
    • Note: VM is paid by hour when the VM is running. In development use it’s a good idea to stop the VM when you don’t need it (start/stop buttons are found in Azure portal).
  5. Use SSH connection for managing your VM (ssh username@PUBLIC_IP/YOUR_DNS_NAME in terminal/git bash or use e.g. Putty)
    • Optional: use public key authentication instead of username/password: Instructions
  6. Make sure you have all recent updates installed (this should be done on weekly basis)

    sudo apt update # checks for available updates
    sudo apt dist-upgrade # installs updates including kernel packages
    

    All administrator level tasks needs superuser (root) privileges. sudo (superuser do) needs to used before the actual command for gaining the access rights. Use your login password if prompted.

Installing & configuring web server software

Apache web server

  1. Install

    sudo apt update
    sudo apt upgrade
    sudo apt install apache2
    
  2. Check configuration files /etc/apache2/ & start sudo systemctl start apache2
  3. Add write permissions to your user account for the webroot folder /var/www/html: sudo chown <MYUSERNAME>.<GROUP> /var/www/html
  4. Copy your UI files to the webroot using e.g. scp/filezilla/winscp or clone/pull from GitHub
  5. Test with browser http://my.server.ipaddress.or.hostname/
  6. Enable HTTPS connections using Let’s encrypt & Certbot

    # Ensure that your version of snapd is up to date
    sudo snap install core; sudo snap refresh core
    # Install Certbot
    sudo snap install --classic certbot
    # Get a certificate and have Certbot edit your apache configuration automatically to serve it, turning on HTTPS access in a single step
    sudo certbot --apache
    # Answer the questions when prompted, you need to provide your server DNS-name, something like <my.website>.cloudapp.azure.com
    
    • To confirm that your site is set up properly, visit https://my.server.hostname.cloudapp.azure.com/ in your browser and look for the lock icon in the URL bar

MariaDB database server

  1. Install MariaDB server (more detailed instructions):

    sudo apt install mariadb-server
    
  2. Start and enable it:

    sudo systemctl start mariadb
    sudo systemctl enable mariadb
    
  3. Secure it by running the sript (optional in our one server system):

    mysql_secure_installation
    

    Note: In Ubuntu you don’t necessary need root password at all. Just use sudo for gaining root access: sudo mysql -u root. Skip that step when prompted.

  4. Connect to your database server as a root user: sudo mysql -u root and create a database and a user with privileges on it:

    CREATE DATABASE MyDatabaseName;
    CREATE USER 'myusername'@'localhost' IDENTIFIED BY 'mypassword';
    GRANT ALL PRIVILEGES ON `MyDatabaseName`.* TO 'myusername'@'localhost';
    FLUSH PRIVILEGES;
    

    (in case you would need outside access (e.g. during project, separate database server from app server), replace localhost with '%' in the two GRANT queries and remember that the settings you did with mysql_secure_installation may prevent this).

  5. Use your own database creation script.
    • You can download from the internet (e.g. Github) directly to the server using curl: curl -O <FILE-URL> (note: click the Raw button on script’s GitHub page in order to get a working url)
    • or upload with any SCP file transfer tool to the server. (e.g. using command line secure copy tool scp: scp my-db.sql <YOUR-USERNAME>@<YOUR-SERVE-NAME/IP>:)
  6. Import the tables and insert the data: mysql -u myusername -p < my-db.sql or sudo mysql < my-db.sql
  7. Eventually check that the user account works and the data is there: mysql -u myusername -p

    USE MyDatabaseName;
    SHOW TABLES;
    exit
    
  8. (Optional) if you would like to install phpMyAdmin to administrate your databases, tables and data with a graphical user interface, check for example instructions here

Node.js runtime and process management

This can be done later when you have your Express application ready for deployment, but here are the instructions in advance.

Apache reverse proxy

  1. Install node.js and npm from nodesource package repository:

    # Download the setup script:
    curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
    # Run the setup script:
    sudo -E bash nodesource_setup.sh
    # Install node.js:
    sudo apt install -y nodejs
    # Verify that the installed node tools are working:
    node -v
    npm -v
    
  2. Configure Apache httpd server as a reverse proxy to Node server:

    1. Edit the Apache configuration (Let’s encrypt’s default SSL configuration file):

      sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf
      
    2. Add the following content (to the bottom of <VirtualHost *:443> block) & save the conf file:

      <VirtualHost *:443>
              
        # some existing conf stuff here
      
        #...
        #...
      
        # Choose only (uncomment or copy) one of the following configuration options:
            
        # configuration for URL subpath, e.g.: https://myserver.example.com/api/ <-> localhost:3000
        #ProxyPreserveHost On
        #ProxyPass /api/ http://127.0.0.1:3000/
        #ProxyPassReverse /api/ http://127.0.0.1:3000/
      
        # OR configuration for root path: https://myserver.example.com/ <-> localhost:3000
        # this is the recommended (easier) option
        ProxyPreserveHost On
        ProxyPass / http://127.0.0.1:3000/
        ProxyPassReverse / http://127.0.0.1:3000/
      
      </VirtualHost>
      
  3. When working with Ubuntu 24.04 default installation you need to enable modules proxy and proxy_http by using command sudo a2enmod <MODULE-NAME> and restart the web server:

    sudo a2enmod proxy proxy_http
    sudo systemctl restart apache2
    
  4. Setup Git to connect to your remote repository

    1. Test that git command works, if not install it: sudo apt install git
    2. If your Github project repo is private, you need to setup ssh authentication:
      1. Generate a new SSH key
      2. Add SSH key to your GitHub account
      3. Test connection
    3. It’s also a good idea to setup your git user name: git config --global user.name "Your Name" and email: git config --global user.email "youremail@example.com" on the server.
  5. Install and run your Express application:

    1. Read Production best practices: performance and reliability and What is NODE_ENV in Node.js
      • Prepare your app for production and create a new git branch deployment or use main
      • Make sure the branch for the deployment is up to date with the latest changes and works on your local machine and push it to the remote repository (GitHub)
    2. On the server: Make sure you are in your home folder: cd
    3. git clone <your-github-repo-url-here> (or copy your back-end app to your home folder on the server exluding the contents of node_modules & uploads folders)
    4. Go to the app directory: cd <my-app>
    5. If you cloned the repo, make sure that you are in the right branch (git checkout <branchname> if not)
    6. Install your dependencies: npm install --production (--production flag is used to avoid installing development dependencies if not needed on deployment server)
    7. Create/edit .env file with your db credentials (you set in MariaDB) and other settings:
      • you can use .env.sample as a template by copying it: cp .env.sample .env (navigate to the correct directory first by using cd commands)
      • edit the env file with nano: nano .env:
      DB_HOST=127.0.0.1
      DB_USER=<your-db-user>
      DB_PASSWORD=<your-db-user_password>
      DB_NAME=<your-db-name>
      JWT_SECRET=somesecuresecrethere
      JWT_EXPIRES_IN=1d
      # add also other settings that you may have in your app (like the Kubios Api stuff)
      # ...
      
    8. To test start your application: node src/index.js or npm start
    9. Test that it works: open a browser and visit https://<your-ip-address-or-hostname>/api/<endpoint>
    10. To kill the app, use CTRL+C, or if it’s no more attached to your terminal session, try pkill node or use top
    11. To have your app running “forever” as a background service, featuring automatic restart on crash, writing log files, etc. use e.g. pm2:

      sudo npm install -g pm2
      pm2 start src/index.js --name <MY-SERVER-APP-NAME>
      
      • To check the status of running node apps, run pm2 status
      • To check for possible errors, etc.: log files can be accessed with pm2 logs
      • Restart app after code updates: pm2 restart <app-name>
      • If you want that the app automatically reload on change (e.g. on next git pull), use the --watch flag with pm2.
    12. (optional) other “pure” linux option for managing the service would be using systemd for creating a system process.

Publishing Front-end application (Client)

Front-end HTML/CSS/JS files can be served from any web server. Easiest and the recommended solution is to use the Express static files serving option. Then you don’t need care about cors issues and the apache proxy setup done earlier works out-of-the-box.

For example when using Vite for front-end development:

  1. Build your Vite app (npm run build) to create the static HTML/CSS/JS/etc. website files. (You cannot use the Vite development server for production on the server.)
    • Note: Remember to update your API connections (fetch() function calls) in your client code to use the real server’s URL address instead of localhost:3000!
    • You can do the build on your local machine and then copy the files to the server or build directly on the deployment server using a cloned git repository of your front-end project.
  2. Copy all contents of the dist/ folder (generated by Vite build) to your node application’s public/ folder on the server.
    • if you did the build on the local machine, you can use for instance WinSCP or Filezilla or cli tools scp/rsync to copy the files to the server: scp -r dist/ <USERNAME>@<SERVER-ADDRESS>:/path/to/your/app/public/ or put the files into public/ folder in your node app’s git repository (e.g. deployment branch) and push-pull them to the deployment server within the node app.
    • if you did the build on the server, just copy the files to the right place on the server: cp -r dist/* /path/to/your/app/public/
  3. Make sure you have the correct git branch checked out on the server and then restart your node app with pm2 restart <app-name> after making changes to the node app.
  4. Test: open a browser and visit https://<your-server-address>/ and https://<your-server-address>/api/

Or if you want to use Apache directly as a web server for static files:

  1. Change the owner of the web root folder such that no sudo permissions are needed when you edit the contents of the folder: sudo chown <USERNAME>.<USERNAME> /var/www/html
  2. Upload/copy/clone your front-end files to the server’s /var/www/html/ directory
  3. Update Apache config by enabling DocumentRoot and modifying proxy settings for Node app to use the sub url path version
  4. Test: open a browser and visit https://<your-server-address>/ and https://<your-server-address>/api/

Cross-Origin Resource Sharing (CORS)

If running the front-end and back-end on different servers, you need to take care of CORS issues. One option is to use the cors middleware in Express app.

Assignment - Deploy your application to Azure

Follow the instructions above to deploy your application to an Azure virtual machine.

Returning: No separate return is needed. This is part of your project assignment.