by Ranju Upadhyay Rai
Conforming with feminist approach in digital humanities, the Full Stack Feminism project team has been exploring/discussing various approaches to making tools and technologies easily available/accessible and sustainable. As part of our effort to understand accessible technologies and ultimately produce an archival toolkit, one of the tasks the team is undertaking is creating infrastructure that is suitable for the archival toolkit in MS-Azure cloud, and setting up similar alternative using a non-commercial platform. Once the MS-Azure cloud-based infrastructure and the alternative environment are set up, we intend to install Omeka S (an open-source web publishing platform) on both the platforms. This will give us an opportunity to do a comparative study of creating a toolkit on two very different platforms and identify the scenarios when either is a useful/feasible/sustainable route to take.
This blog discusses the process of getting the environment ready in MS-Azure cloud. There are several steps involved.
Since the University IT services subscribe to MS-Azure cloud, the starting point was to ask our IT services team to set up a space for Full Stack Feminism Project in the cloud and give access to members of the team. A separate space for projects associated with specific departments (which is referred to as subscription) is necessary for billing purposes as well as for having an independent space to work in the cloud without affecting any other existing resources.
Once the Subscription has been set up, the next step is to create a Resource Group. The link to creating resource group is available on the home screen of MS-Azure Portal.
Having a Resource group will make it easy to group the resources created for each project. Everything is a resource in MS-Azure portal (VM, managed Db, storage disks etc).
The next step is to create a virtual machine (VM). Again, the link to create the VM is available on the Azure home screen, click on create and select Azure virtual machine.
There are documents available in Microsoft’s site (https://docs.microsoft.com/en-us/azure/virtual-machines/Linux/quick-create-portal). These documents outline the steps necessary to create a VM. There might be a slight difference in what the documents say and how it really looks on Azure Portal but for the most part the documents are good.
The VM creation process will ask for Subscription and Resource group, so we used what we had created. The next step is to select the right Operating System, In our case we are looking for a Linux OS. We picked the latest available version of RHEL, which is 8.2(even though RHEL is already on version 9, it is not yet available on the MS-Azure Portal). Picking the latest stable version of the OS will give longevity to VM i.e., the OS will be supported for longer.
The selection of the right region to avoid GDPR issues with data is important.
The authentication can be either password based or key based.
Since we need the web access as well as SSH access, we enabled all of the ports (SSH, HTTP and HTTPS).
For selecting the type/size of VMs, for our purpose the standard_B2s (2 VCPUs and 4 Gib memory) was adequate so we went with that. According to our IT services those are the most popular ones! Different pricing applies for the different types of VMs.
Next is the Disk setup, the process of setting up disks involves two types of disks, the OS disk and the data disk. The OS disk is available with the VM, but a separate disk is necessary for data storage.
For the OS disk we selected the Standard SSD with locally redundant storage and then used the option to create and attach a new disk (which will be the data disk). We have selected the 128 GiB premium SSD with locally redundant storage for the data disk. We left the option ‘Delete Disk with VM’ disabled.
The port rules that are set during the networking stage can be changed later. While we have enabled all the ports, we have restricted the access to certain IP addresses.
In the management process we made sure to enable the backup and left other options to default.
Once the VM is created, the data disk that is attached needs to be mounted. The following document gives the steps of mounting the disk. https://docs.microsoft.com/en-us/azure/virtual-machines/linux/attach-disk-portal
Since the process of creating and attaching the disk had happened during the VM creation, the applicable steps are from the point of ‘Connect to the Linux VM to mount the new Disk’ in the document.
Once the VM is fully setup along with the data disk, the next step is to set up a database. It is possible to install and create database server in the VM itself, but MS-Azure offers the possibility of using a managed Database (for MySQL, MariaDB etc). The advantage of using a managed database is that it separates the web server from the database and since it is a service, the service provider (i.e., Microsoft) takes the responsibility of optimizing the DB. This approach keeps the web server and DB server efficient.
The managed database is added as a resource, like the VM, from Azure home screen. We decided to use MariaDB as the backend database. The following document is helpful: https://docs.microsoft.com/en-us/azure/mariadb/quickstart-create-mariadb-server-database-using-azure-portal
As mentioned before, the document might be slightly different to how it currently looks in Azure cloud. Since the databases category did not list MariaDB as mentioned in the document, we had to search for it on the home screen and then go through the process of creating it.
We selected the Basic type for database server which has 2 vCores and 50Gb Storage. To connect to the database server from the VM it is necessary to install MySQL client in the VM. MySQL client provides the connector for MariaDB.
Once the managed database is set up and MySQL client is installed in the VM we use a connect string as below to connect to the Database server:
Mysql -h nameofdbserver.mariadb.database.azure.com
This completes the creation of Infrastructure that can host Omeka S in MS-Azure cloud.