Basic Science Cloud Usage
CONTENTS
Logging In
Go to the Science Cloud dashboard at https://coarecloud.asti.dost.gov.ph/dashboard. Enter the User Name and temporary Password sent by the COARE Team via e-mail.
Dashboard
After logging in, the page will be redirected to the OpenStack Dashboard. The default landing page is the project's quota overview and usage summary:
On the left-hand side portion of the page is the Navigation Bar containing different tabs for various operations:
- Manage compute resources
- Show project quota and usage
- Manage instances (virtual machines)
- Manage volumes (virtual disks)
- Manage images
- Manage SSH key pairs
- List relevant API addresses
- Manage network resources
- Show a diagram of configured networks
- Manage project networks
- Manage routers
- Manage firewall policies and rules
- Manage inbound and outbound IP protocols (e.g., ICMP, TCP, UDP, etc.)
- Manage load balancers
- Manage floating (public) IP addresses
- Manage stack using template and environment sources
- List supported resource types (AWS and OpenStack)
- List versions of stack templates
- (Deprecated) Manage object storage containers
- Manage compute resources
- Lists various information about the current system (some parts are for admins only)
- List all projects (for admins only)
- List all users (for admins only)
- List all user groups (for admins only)
- List all user roles (for admins only)
The following options become available when selecting the user settings as discussed in the next section:
- Modify dashboard settings
- Change user password
Dashboard Settings
Upon successful log in, the user's dashboard settings can be accessed by navigating to the upper right corner of the dashboard, click your username (in this example, ), then click :
On the left portion of the screen, the options and will appear:
User Settings
Here, the following dashboard settings can be changed: Language, Timezone, Items Per Page, and Log Lines Per Instance:
Change Password
To change the user password, enter the Current password, then the New Password and Confirm new password:
We highly recommend that users change the provided temporary password upon first log in. As the description indicates, we also highly recommend that you create a strong password by using at least eight (8) characters using a combination of uppercase and lower case letters, numbers, and symbols.
Key Pair Management
Before creating any instance, it is very important to first set up key pairs as these are the way to access created instances. Key pairs are similar to SSH key pairs composed of a pair of corresponding public and private keys. Navigate to the Key Pairs section in the Dashboard by selecting in the Navigation Bar. Two options are available: and .
Create Key Pair
This action will generate a new SSH private key. Fill in Key Pair Name, then click :
A download prompt will automatically appear. Give the file a name with a .pem
extension (such as test.pem
) and download it where you can locate it later on. If for any reason you weren't able to download the file, you can click the button:
Just make sure to download the file immediately because once you exit the "Download Key Pair" page (by clicking other links or reloading the page) this option will no longer be available. If the page is reloaded, it will change to the list of created Key Pairs:
Clicking on the Key Pair Name reveals the corresponding Public Key:
It is the Public Key that will be injected into the instance upon creation later on so that it can be accessed via SSH.
The Fingerprint information for the key is important because we can use this information to verify that the downloaded Private key corresponds to the indicated Public Key. To do this, in a Linux/Unix/MacOS terminal or Windows PowerShell, use the following command:
For Linux/Unix/MacOS systems, the command may run into a warning saying that the private key file is unprotected, like so:
This can be easily fixed using the following command:
Take note of the resulting MD5 fingerprint to confirm that it matches the fingerprint indicated in the Key Pairs dashboard.
Import Key Pair
Another way of adding a Key Pair is to import a preexisting SSH key.
In your Linux/Unix/MacOS terminal or Windows PowerShell, create an SSH private and public key pair (skip this if you already have an existing SSH key pair and you wish to append the public key of that key pair).
Then, go back to the Key Pairs dashboard and click the button to display the Import Key Pair window:
Give this key a name, paste the public key in the Public Key box, then click the button to add the key pair under your account.
Image Management
A working Image is a very important requirement prior to creating instances as it is the source of the instance's operating system (OS) and its configuration during creation. Metadata information, such as account creation and SSH key injection, are also automatically handled by the image. Publicly-available images (i.e., images from the same or other projects that are set with Public visibility) are listed OpenStack "Get images" documentation.
under the tab in the Navigation Bar. Here, preconfigured images are available for use, but users may still opt to upload their image of choice as described in theCreate Image
To create an image for the project, go to the tab in the Navigation Bar, then click the button to display the Create Image window:
Fill up the required fields indicated by asterisks. More information on the fields are described in the OpenStack Upload and manage images documentation.
On the next page, the image's metadata may be configured:
The OpenStack Useful image properties documentation lists some image properties and their supported values which can be used to configure the image to be created. However, please note that there may be discrepancies in the properties available in the dashboard compared to that in the online documentation. In most cases, it isn't necessary to define metadata properties to the image.
Security Groups Management
Security groups control network traffic going in (ingress) and out (egress) of the instances similar to how network firewalls work. Go to the tab in the Navigation Bar to manage your project's security groups.
Default
The default security group contains the following network rules:
The above rules allow all outgoing (egress) network traffic to the internet (::/0
for IPv6 and 0.0.0.0/0
for IPv4) through all ports and IP protocols. For incoming (ingress) traffic, the default
security group (itself) is used, but there are no ingress rules defined in the default
security group. Therefore, the default
security group only allows outgoing traffic to all IPv4 and IPv6 addresses, and no incoming traffic is allowed from anywhere. This is intended by design to help secure the instance from unauthorized and malicious access. However, to be able to access the instance — for example, ping (ICMP); logging in using SSH; HTTP (port 80) and HTTPS (port 443) for web server instances; etc. — ingress traffic must be allowed. Therefore, a new security group will be created.
Create Security Group
To create a new security group, click the button:
Give it a Name and Description. For this example, the new security group will be named minimal
to allow incoming traffic for SSH (port 22) and ping (ICMP). Then, click the button. After creation, click the button to configure the security group's network rules. By default, all outgoing (egress) traffic are allowed in the new minimal
security group like that in the default
security group:
Add Rules
Click the button to show the following window:
To allow SSH logins (via TCP port 22), select under Rule, under Remote, and type in 0.0.0.0/0
under CIDR to allow incoming access from all IPv4 addresses. Click to add the rule. Add another SSH rule but this time set the CIDR address to ::/0
to allow incoming access from all IPv6 addresses. The CIDR addresses may be modified to allow incoming requests only from a specific IP address (e.g., 192.168.6.69
equivalent to 192.168.6.69/32
) or a range of IP addresses (e.g., 192.168.6.1/24
). For more information about this notation, here is a quick overview on Understanding IP Addressing and CIDR Charts.
After creating both rules, the security group will look like this:
To be able to ping
instances, the ICMP rule must also be allowed for ingress traffic. Do the same steps outlined above for SSH, but use instead of under Rule. The minimal
security group should now look like this after adding SSH and All ICMP ingress access from all IPv4 (0.0.0.0/0
) and IPv6 (::/0
) addresses:
In the future, additional IP protocols and ports (or port ranges) may need to be opened for other applications and protocols, such as, among others:
- TCP ports 80 and 443 for HTTP and HTTPS protocols, respectively, for web servers;
- TCP ports 27017–20 for MongoDB;
- UDP ports 53, 68, and 88 which are used by online games.
Additional security groups with additional rules should be created to accommodate any new ports that need to be opened in your instances.
Instance Management
Create Instance
After the key pair, image, and security group are configured, the project's first instance may now be created. When creating an instance, make sure to use the least amount of resources possible (e.g., virtual CPUs, memory, disk size) first which can be gradually resized later on. It is also not advisable to create instances with large root disk sizes (e.g., more than 20 GB) for storage purposes because it will be almost impossible to recover data when the instance fails and there is no instance snapshot. Instances should only contain the bare minimum disk requirement for the operating system (OS) to run smoothly. Create and attach additional volumes instead for storage purposes.
From Image
The recommended way to create a new instance is from an image.
Go to the tab in the Navigation Bar, then click the button to show the Launch Instance window:
Give it an Instance Name, and keep the other settings as is (i.e., Any Availability Zone under Availability Zone, and 1 under Count). For this example, the instance name was set as test which will also become the instance's hostname later on.
Click to configure the instance source:
Choose the option under Select Boot Source, then select for Create New Volume to create a new root volume for the instance. Set the Volume Size (GB) for the root volume (minimum should be 20 GB as dictated by the different flavors, to be discussed further). Set for Delete Volume on Instance Delete if you want the volume to be automatically deleted when the instance is deleted. For Device Name there are two possible options: vda or sda; the default is vda, but if this results in errors later on, then you can try setting sda instead. Select the image to use from the list of available images by clicking the button. Only one (1) image may be selected.
For this example, the image Ubuntu 20-04-focal-server-lts was used:
Click to configure the instance flavor:
The flavor defines the instance's virtual resources, such as CPUs (VCPUs), memory (RAM), and root disk size (Root Disk). Be mindful of your project's resource quotas. Select the flavor to use from the list of available flavors by clicking the button. Only one (1) flavor may be selected.
Click to add a network to the instance:
In the networks listed, select only either int-vlan-network
(for internal users, i.e., ASTI users) or ext-vlan-network
(for non-ASTI users) by clicking the button. DO NOT use either the 159-pub-network
or public_v6
network as this will make the instance unreachable.
Skip the Network Ports tab and go directly to the Security Groups tab:
Here, add the minimal
security group previously created by clicking the button. Multiple security groups may be attached to a single instance. Click to proceed to the Key Pair tab:
Select the appropriate key pair by clicking the button. Only one (1) key pair may be attached per instance. Click to proceed to the Configuration tab:
Add any configuration script that you may have either by pasting directly into the Customization Script box or by attaching a file under Load script from a file. One useful example of a customization script is setting the root password during instance creation which may be useful later on when logging in via the instance's console.
Select Automatic for Disk Partition; if you'd like to configure the disk partition yourself, then select Manual instead. Check the Configuration Drive box to create a special partition within the instance where metadata are stored, such as the instance name (which will be used as the instance hostname), etc.
After the Configuration tab, the next tabs may be skipped. Click the button to finally create the instance which will take the page back to the Instances tab to show that the instance is being created:
After some time, if the instance creation is successful, the Status will be changed from Build to Active:
The instance log should be inspected to confirm that the SSH key pair has been successfully appended. Click the hyperlinked Instance Name, then navigate to the Log tab to show the Instance Console Log:
You can click the button to show the entire console log. There should be lines that look like that below saying that the authorized_keys
have been updated (this is already partially visible in the screenshot above):
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+
ci-info: | Keytype | Fingerprint (sha256) | Options | Comment |
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+
ci-info: | ssh-rsa | 09:57:6e:59:8e:02:ff:fb:c8:a9:42:3d:29:13:6a:0f:5e:e7:39:5e:72:2b:0f:9d:b4:42:83:7b:ad:e5:1b:bc | - | Generated-by-Nova |
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+
As per the OpenStack Get images guide, the default username for Ubuntu images is ubuntu
, hence the key pair was appended to /home/ubuntu/.ssh/authorized_keys
. For other images, such as those preconfigured by the COARE Team, the default username is indicated in the image's description. However, the SHA256 fingerprint of the key appended to the instance as indicated in the console log does not match the actual SHA256 fingerprint of the key. Please don't worry about this discrepancy as this seems to be only a bug in the current OpenStack implementation. The right key was still injected into the instance which is apparent in the successful SSH log in to the instance as discussed further.
From Instance Snapshot
Create a snapshot of your instance first as discussed further down. Then, follow the same steps above for creating an instance from an image because instance snapshots are stored as images in OpenStack. This is a good way of creating a working back up of your instance(s) which can be recreated as another instance especially when the original instance fails beyond repair and recovery.
Access the Instance
Accessing an instance after creation will depend on how the rules of its attached security group(s) is/are configured. In order to be able to access instances attached to either the int-vlan-network
(192.168.7.0/24
) or ext-vlan-network
(192.168.14.0/23
), connection to the appropriate COARE virtual private network (VPN) is required.
In the previously created instance, its IP address allocated under the ext-vlan-network
is 192.168.15.27
(see the screenshot above).
Ping
To check if the instance is indeed up and running, the ping
command may be used. To ping
the instance, make sure that the VPN is connected, then in your local machine's terminal:
The instance will respond if the VPN is connected and if the incoming ICMP access is allowed in the instance's security groups:
However, if any of the above conditions aren't met (i.e., the VPN is not connected, incoming ICMP access is not allowed in the security goups, or both), then the instance won't be reachable:
SSH
To log in to the instance via SSH, make sure that the VPN is also connected and incoming SSH access is allowed in the instance's security groups. In your local terminal:
For the same test instance, this is how a successful SSH log in should look like:
The access transitioned from the local Inspiron-5584
machine with username demo
to the remote test
hostname with user ubuntu
. To demonstrate that the machines are not the same, the ip -brief all
(shortcut: ip -brief a
) command was used on both the local and remote machines to determine their respective network intefaces/devices and their corresponding IP addresses. The above screenshot also indicates that the ubuntu
user is an administrator account in the instance which is the default for all images. Thus, users are free to configure their instances up to the system level as they have root
access to their instances, including but not limited to, creating additional accounts for other project members, installing various applications, etc.
Console
In default images (i.e., images that have not yet been preconfigured), the default user is passwordless. That is why making sure that the right SSH key pair is injected into the instance is critical for access. Therefore, access via console is not yet available immediately after instance creation.
For preconfigured images, check the image description or ask the COARE Team regarding the default login credentials. For default images, a password for the default user may be set. Log in to the instance via SSH as described above (remember to connect to the appropriate VPN first), then log in as root and change the default user's password using the following commands:
root@test:~# passwd ubuntu # default user
The same commands are applicable for other Linux distributions as well, such as CentOS, Debian, Fedora, etc. A notification will be printed when the password is successfully set:
Console access is now possible for the default user (or any other user created in the instance) after successfully setting a password. Console access is similar to a direct log in into a physical server. To do this, keep the VPN connection active as it is necessary to access the instance's Console tab. Navigate to the instance's Console tab in the dashboard:
Click the "Click here to show only console" link to get started. This will display only the console in the entire browser window. Now enter the username and password for the user you wish to log in. After successfully logging in, it will have a similar interface when logging in via SSH:
Similarly, a password may also be set for the root
user to be able to log in directly via the console:
root@test:~# passwd
Backup Instance
Create Instance Snapshot
An instance snapshot captures the instance's state at the time the snapshot is created. This can be easily done by either clicking the button at the rightmost portion of the instances list:
Or, by clicking the Instance Name, then clicking the same button at the top right portion:
After clicking the aforementioned button, the Create Snapshot window will appear where the Snapshot Name should be provided:
After creating the snapshot, the page will be redirected to the
tab in the Navigation Bar. Repeatedly click any of the headers (Owner, Name, Type, etc.) until all the images under the project are at the top of the list including the created snapshot:In the tab of the Navigation Bar under the sub-tab, a volume snapshot is also saved for the instance snapshot:
Other Instance Operations
Other operations may be performed on instances in the Instances dashboard:
- Associate Floating IP: Add a floating (public) IP to an instance.
- Attach Interface: Add a new interface/connection to a network.
- Detach Interface: Remove a network interface/connection.
- Edit Instance: Change the instance's name and security groups.
- Attach Volume: Add a volume as a new disk device to the instance.
- Detach Volume: Remove a volume from the instance. The volume contents are not affected.
- Update Metadata: Edit the instance's metadata.
- Edit Security Groups: Manage the security groups applied to the instance.
- Console: View the instance console (needs VPN connection).
- View Log: View the Instance Console Log.
- Pause Instance: Puts the instance in a state similar to "Sleep" in personal computers.
- Suspend Instance: Places the instance in a state similar to "Hibernate" in personal computers.
- Shelve Instance: Shutdown the instance and store it together with associated data and resources. A snapshot is taken if the volume is not backed. Note that anything in memory of the instance (e.g., running applications, data read/write to disk, etc.) will be lost.
- Resize Instance: Change the instance's flavor.
- Lock Instance: Prevents deletion of the instance.
- Unlock Instance: Allows deletion of the instance.
- Soft Reboot Instance: Attempt a graceful shutdown and reboot of the instance similar to issuing a reboot command within the instance.
- Hard Reboot Instance: Does not wait for a graceful shutdown similar to pressing and holding the power button of a physical machine until shutdown.
- Shut Off Instance: Turn off the instance.
- Rebuild Instance: Rebuild the instance from an existing image.
- Delete Instance: Delete the instance. WARNING: This operation is not recoverable once finalized.