Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Install Python package management (pip) and required packages: 

    Code Block
    $ sudo apt-get install python-pip python-dev


  2. Install Openstack command-line tools using pip: 

    Code Block
    $ sudo pip install python-openstackclient

Openrc file

The ‘rc’ in rc file stands for any or all of the following:

  • run commands

  • resource control

  • run control

  • runtime configuration

Using an rc file to outline your Rapid Access Cloud credentials allows you to pass your credentials to the cloud without needing to include them in your scripts. In fact, the rc file is a simple bash script that creates environment variables in your shell to be used by the openstack command (the ‘open’ in openrc). The environment variables, once set, exist only for the current session. If you open another concurrent session on the computer or log-out and back in, you will need to source the openrc file again.

You can download a pre-generated openrc file from the dashboard, or create one if you are unable to download from the dashboard.

Download openrc

  1. Log-in to the Rapid Access Cloud dashboard at https://cloud.cybera.ca.

  2. In the left-hand panel under “Compute”, click “Access & Security”.

  3. Click the “API Access” tab at the top then click the “Download Openstack RC file” on the right.

  4. The file downloaded will be named after your account name, e.g. <email>@<domain>-openrc.sh. This can be renamed to openrc if you like, or you can copy it and modify it so you can have one for the Calgary region and one for the Edmonton region. The rc file downloaded will be keyed for the region you are signed into in the dashboard.

  5. Add this line to the downloaded openrc file: 

    Code Block
    export OS_VOLUME_API_VERSION=2

Create openrc

You can use the downloaded rc file as a template or create one from scratch. The OS_USERNAME and OS_TENANT_NAME variables are the same; each will be the email address for your Rapid Access Cloud account.

Copy and paste the region-appropriate rc file. This openrc file will require you to enter your password each time you source the file, however you can modify the file if you like to include the password.

Note

Keep this file secure if you are keeping your password in plain text!

Calgary openrc

Code Block
#!/bin/bash
export OS_REGION_NAME="Calgary"
export OS_VOLUME_API_VERSION=2
export OS_AUTH_URL=https://keystone-yyc.cloud.cybera.ca:5000/v2.0
export OS_USERNAME="<account_username>"
export OS_TENANT_NAME="<account_username>"
echo "Please enter your OpenStack Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT

Installing command-line tools (OS X)

  1. Ensure you have the Developer Tools (Xcode) with the Command Line Tools for OS X.

  2. Open the Terminal application.

  3. Install pip (a package management system for software packages written in python): 

    Code Block
     $ sudo easy_install pip


  4. Install the openstack command line tool: 

    Code Block
    $ pip install --user python-openstackclient


  5. Add the following to .bashrc: 

    Code Block
    export PATH=/Users/<username>/Library/Python/2.7/bin:$PATH
    export PYTHONPATH=/Users/<username>/Library/Python/2.7/lib/python/site-packages



Openrc file

The ‘rc’ in rc file stands for any or all of the following:

  • run commands

  • resource control

  • run control

  • runtime configuration

Using an rc file to outline your Rapid Access Cloud credentials allows you to pass your credentials to the cloud without needing to include them in your scripts. In fact, the rc file is a simple bash script that creates environment variables in your shell to be used by the openstack command (the ‘open’ in openrc). The environment variables, once set, exist only for the current session. If you open another concurrent session on the computer or log-out and back in, you will need to source the openrc file again.

You can download a pre-generated openrc file from the dashboard, or create one if you are unable to download from the dashboard.

Download openrc

  1. Log-in to the Rapid Access Cloud dashboard at https://cloud.cybera.ca.

  2. In the left-hand panel under “Compute”, click “Access & Security”.

  3. Click the “API Access” tab at the top then click the “Download Openstack RC file” on the right.

  4. The file downloaded will be named after your account name, e.g. <email>@<domain>-openrc.sh. This can be renamed to openrc if you like, or you can copy it and modify it so you can have one for the Calgary region and one for the Edmonton region. The rc file downloaded will be keyed for the region you are signed into in the dashboard.

  5. Add this line to the downloaded openrc file: 

    Code Block
    export OS_VOLUME_API_VERSION=2


Create openrc

You can use the downloaded rc file as a template or create one from scratch. The OS_USERNAME and OS_TENANT_NAME variables are the same; each will be the email address for your Rapid Access Cloud account.

Copy and paste the region-appropriate rc file. This openrc file will require you to enter your password each time you source the file, however you can modify the file if you like to include the password.

Note

Keep this file secure if you are keeping your password in plain text!

Calgary

...

openrc

Code Block
#!/bin/bash
export OS_REGION_NAME="EdmontonCalgary"
export OS_VOLUME_API_VERSION=2
export OS_AUTH_URL=https://keystone-yegyyc.cloud.cybera.ca:5000/v2.0
export OS_USERNAME="<account_username>"
export OS_TENANT_NAME="<account_username>"
echo "Please enter your OpenStack Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT

...

This tutorial will walk through some of the steps outlined in the Basic Guide in building a single instance from scratch, with some notes about alternative functionality that each command offers, to show how flexible using the OpenStack command line client is.

The structure of the openstack command is fairly logical and intuitive. The OpenStack documentation project has a comprehensive outline on how the command is used, and help is available through the command for quick reference:

Code Block
$ openstack help

Before getting started, be sure to source your openrc file.

Key Pairs

  • A key pair is required before launching an instance, as the public key needs to be injected into the instance during the provisioning process. The following command will generate the pair, and output the private key: 

    Code Block
    $ openstack keypair create <key_name> >> my_key.pem
  • Or perhaps you have an existing RSA key pair that you would like to use instead: 

    Code Block
    $ openstack keypair create --public-key </path/to/public_key> <key_name>
  • Deleting a key pair is accomplished with: 

    Code Block
    $ openstack keypair delete <key_name>
  • And to list existing key pairs (you guessed it): 

    Code Block
    $ openstack keypair list 

Security Groups


Edmonton openrc

Code Block
#!/bin/bash
export OS_REGION_NAME="Edmonton"
export OS_VOLUME_API_VERSION=2
export OS_AUTH_URL=https://keystone-yeg.cloud.cybera.ca:5000/v2.0
export OS_USERNAME="<account_username>"
export OS_TENANT_NAME="<account_username>"
echo "Please enter your OpenStack Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT


Using
openstack client

This tutorial will walk through some of the steps outlined in the Basic Guide in building a single instance from scratch, with some notes about alternative functionality that each command offers, to show how flexible using the OpenStack command line client is.

The structure of the openstack command is fairly logical and intuitive. The OpenStack documentation project has a comprehensive outline on how the command is used, and help is available through the command for quick reference:

Code Block
$ openstack help

Before getting started, be sure to source your openrc file.

Key Pairs

  • A key pair is required before launching an instance, as the public key needs to be injected into the instance during the provisioning process. The following command will generate the pair, and output the private key: 

    Code Block
    $ openstack keypair create <key_name> >> my_key.pem


  • Or perhaps you have an existing RSA key pair that you would like to use instead: 

    Code Block
    $ openstack keypair create --public-key </path/to/public_key> <key_name>


  • Deleting a key pair is accomplished with

  • As outlined in the Basic Guide, modifying the default security group to permit ICMP and ssh means that you don’t need to assign specific security groups to an instance in order to do simple troubleshooting (ping or traceroute) or gain access: 

    Code Block
    $ openstack security group rule create --proto icmp --src-ip 0.0.0.0/0 default
    $ openstack security group rule create --proto icmp --src-ip ::/0 default
    $ openstack security group rule create --proto tcp --src-ip 0.0.0.0/0 --dst-port 22 default
    $ openstack security group rule create --proto tcp --src-ip ::/0 --dst-port 22 default
  • Adding too many rules to the default group is not good security practice, so create separate groups for instances with different roles and requirements

    Code Block
    $ openstack securitykeypair group create <security_groupdelete <key_name>


  • To remove an existing group rule from a group (without deleting the whole group) the rule ID is neededAnd to list existing key pairs (you guessed it)

    Code Block
    $ openstack keypair list 


Security Groups

  • As outlined in the Basic Guide, modifying the default security group to permit ICMP and ssh means that you don’t need to assign specific security groups to an instance in order to do simple troubleshooting (ping or traceroute) or gain access: 

    Code Block
    $ openstack security group rule create --proto icmp --src-ip 0.0.0.0/0 default
    $ openstack security group rule create --proto icmp --src-ip ::/0 default
    $ openstack security group rule create --proto tcp --src-ip 0.0.0.0/0 --dst-port 22 default
    $ openstack security group rule create --proto tcp --src-ip ::/0 --dst-port 22 default


  • Adding too many rules to the default group is not good security practice, so create separate groups for instances with different roles and requirements: 

    Code Block
    $ openstack security group create <security_group_name>


  • To remove an existing group rule from a group (without deleting the whole group) the rule ID is needed: 

    Code Block
    $ openstack security group rule list <security_group_name>security group rule list <security_group_name>
    +-------+-------------+-----------+------------+-----------------------+
    |    ID | IP Protocol | IP Range  | Port Range | Remote Security Group |
    +-------+-------------+-----------+------------+-----------------------+
    |  3737 | icmpID | IP Protocol | IP Range  | 0.0.0.0/0 Port Range | Remote           |                       |
    |  3822 | icmp        | ::/0Security Group |
    +-------+-------------+-----------+------------+-----------------------+
    |  3737 | icmp        |   0.0.0.0/0 |            |                       |
    | 16374 3822 | tcp icmp        | 0.0.0.0::/0      | 22:22            |                       |
    | 1637816374 | tcp         | ::0.0.0.0/0      | 22:22      |                       |
    +-------+-------------+-----------+| 16378 | tcp         | ::/0      | 22:22      |                       |
    +-------+-------------+-----------+------------+
  • Delete existing group rules with the rule ID. The security group name is not required, as the rule ID is unique across all security groups: 

    Code Block
     $ openstack security group rule delete <rule_id>
  • When an entire security group is no longer required, the whole group is deleted with: 

    Code Block
     $ openstack security group delete <security_group_name>

Instances

Most of the commands for manipulating and managing instances is with openstack server. This command is quite extensive, allowing creation, deletion, starting, stopping, adding/removing security groups, adding/removing volumes and more. Refer to the OpenStack server command-object documentation for more information. openstack flavor list, openstack flavor show <flavor_name> and openstack image list, openstack image show ‘<image_name>’ can provide information as to what flavors and images are available.

  • Launch a new ‘small’ instance from an Ubuntu 14.04 image: 

    Code Block
    $ openstack server create --flavor m1.small --image ‘Ubuntu 14.04’ --key-name <key_pair_name> <instance_name>
  • Add security groups to an instance: 

    Code Block
    $ openstack server add security group <instance_name> <security_group_name> 
  • Stop, start and reboot instances: 

    Code Block
    $ openstack server stop <instance_name>,
    $ openstack server start <instance_name>,
    $ openstack server reboot <instance_name>
  • -----------------------+


  • Delete existing group rules with the rule ID. The security group name is not required, as the rule ID is unique across all security groups: 

    Code Block
     $ openstack security group rule delete <rule_id>


  • When an entire security group is no longer required, the whole group is deleted with: 

    Code Block
     $ openstack security group delete <security_group_name>


Instances

Most of the commands for manipulating and managing instances is with openstack server. This command is quite extensive, allowing creation, deletion, starting, stopping, adding/removing security groups, adding/removing volumes and more. Refer to the OpenStack server command-object documentation for more information. openstack flavor list, openstack flavor show <flavor_name> and openstack image list, openstack image show ‘<image_name>’ can provide information as to what flavors and images are available.

  • Launch a new ‘small’ instance from an Ubuntu 14.04 imageAttach a volume

    Code Block
    $ openstack server addcreate volume <instance_name> <volume_name>
  • Detach a volume. This is not a destructive action and data on the volume is left intact: 

    Code Block
     $ openstack server remove volume <instance_name> <volume_name>

Floating IPs

As discussed previously, networking with respect to the assignment of IP addresses in the Rapid Access Cloud is handled automatically during provisioning, with the exception of public IPv4 addresses referred to as floating IPs in OpenStack. There is a single pool that floating IPs are allocated from, named ‘nova’ and by default each project is permitted a single IP from this pool:

  • --flavor m1.small --image ‘Ubuntu 14.04’ --key-name <key_pair_name> <instance_name>


  • Add security groups to an instance: 

    Code Block
    $ openstack server add security group <instance_name> <security_group_name> 


  • Stop, start and reboot instancesAllocate a floating IP to your project

    Code Block
    $ openstack ipserver floating create nova

    Assign an allocated floating IP to an instance: 

    Code Block
    stop <instance_name>,
    $ openstack ip floating add <ip_address>server start <instance_name>

    List IP addresses allocated to project: 

    Code Block
    ,
    $ openstack ipserver floatingreboot list<instance_name>


  • Attach a volumeRemove floating IP from an instance

    Code Block
    $ openstack ipserver floatingadd removevolume <ip<instance_address>name> <instance<volume_name>


  • Return allocated IP address to poolDetach a volume. This is not a destructive action and data on the volume is left intact

    Code Block
     $ openstack ipserver remove floatingvolume delete<instance_name> <ip<volume_address> name>

Volumes

Note

OpenStack instances are intended to be ephemeral, that is the storage associated with the instance is not meant to retain data for any length of time.

The root storage for an instance is solely for volatile application data such as kernel operations and applications. Rapid Access Cloud users are provided with a default 500GB of storage that can be used in the form of volumes to be attached to instances and treated no differently by the instance than an internal hard drive would be to a bare-metal server. Attaching volumes to instances is handled by the openstack server command detailed under managing instances. For volume backup, see managing snapshots and images.


Floating IPs

As discussed previously, networking with respect to the assignment of IP addresses in the Rapid Access Cloud is handled automatically during provisioning, with the exception of public IPv4 addresses referred to as floating IPs in OpenStack. There is a single pool that floating IPs are allocated from, named ‘nova’ and by default each project is permitted a single IP from this pool:

  • Allocate a floating IP to your projectCreate a volume

    Code Block
    $ openstack ip volumefloating create --size 25 <volume_name>nova


  • Assign an allocated floating IP to an instanceClone an existing volume

    Code Block
    $ openstack volumeip createfloating --sourceadd <existing<ip_volume_id_or_name> <volume_name>

     

    address> <instance_name>


  • List IP addresses allocated to project: 

    Code Block
    $ openstack ip floating list


  • Remove floating IP from an instanceCreate a volume from a snapshot (see snapshots and images below)

    Code Block
    $ openstack volumeip createfloating --snapshotremove <snapshot_id_or_name> <volume_name><ip_address> <instance_name>


  • Return allocated IP address to poolDelete a volume. This is a destructive action and all data associated with the volume is lost

    Code Block
     $ openstack volumeip floating delete <volume<ip_name>

Snapshots and Images

...

  • address> 


Volumes

Note

OpenStack instances are intended to

...

be ephemeral,

...

that is the storage associated with the instance is not meant to retain data for any length of time.

The root storage for an instance is solely for volatile application data such as kernel operations and applications. Rapid Access Cloud users are provided with a default 500GB of storage that can be used in the form of volumes to be attached to instances and treated no differently by the instance than an internal hard drive would be to a bare-metal server. Attaching volumes to instances is handled by the openstack server command detailed under managing instances. For volume backup, see managing snapshots and images.

  • Create a volume: 

    Code Block
    $ openstack volume create --size 25 <volume_name>


  • Clone an existing volume

Before snapshotting your instance, make sure it is in a shut-off state.

  • Create an image of an existing instance

    Code Block
    $ openstack server imagevolume create --name <imagesource <existing_volume_id_or_name> <instance<volume_name>

     

  • Download an image to a local computerCreate a volume from a snapshot (see snapshots and images below)

    Code Block
     $ openstack imagevolume savecreate --file <filesnapshot <snapshot_id_or_name> <image<volume_name>


  • Snapshot an existing volume, unattached to an instanceDelete a volume. This is a destructive action and all data associated with the volume is lost

    Code Block
     $ openstack snapshotvolume create --name <snapshot_name> <volume_name>
  • Snapshot an existing volume, attached to an instance: 

    Code Block
    $ openstack snapshot create --name <snapshot_name> --force <volume_name>
    Note

    Note about volume snapshots: Notice the use of the --force switch when taking a snapshot of an attached volume; the snapshot will work and not fail, however if there are open files being actively written to the validity of the data being cloned cannot be guaranteed.

Installing command-line tools (OS X)

...

Ensure you have the Developer Tools (Xcode) with the Command Line Tools for OS X.

...

Open the Terminal application.

...

Install pip (a package management system for software packages written in python): 

Code Block
 $ sudo easy_install pip

...

Install the openstack command line tool: 

Code Block
$ pip install --user python-openstackclient

Add the following to .bashrc: 

...

  • delete <volume_name>


Snapshots and Images

While it is true that instances in the Rapid Access Cloud are intended to be ephemeral, it is still possible to capture the state of an instance at any moment and save it as an image that can in turn be provisioned in a similar fashion to deploying a new instance using openstack server create as outlined above. This permits the ability to back-up an instance for safe keeping or create a base image with required applications already installed if you want to rapidly deploy many instances with a similar role. Volume snapshots are point-in-time stateful ‘freeze’ of a volume, meaning the volume itself cannot be attached after a snapshot is taken. (see volumes above for creating new volumes from snapshots)

Before snapshotting your instance, make sure it is in a shut-off state.


  • Create an image of an existing instance: 

    Code Block
    $ openstack server image create --name <image_name> <instance_name>

     

  • Download an image to a local computer: 

    Code Block
     $ openstack image save --file <file_name> <image_name>


  • Snapshot an existing volume, unattached to an instance: 

    Code Block
    $ openstack snapshot create --name <snapshot_name> <volume_name>


  • Snapshot an existing volume, attached to an instance: 

    Code Block
    $ openstack snapshot create --name <snapshot_name> --force <volume_name>


    Note

    Note about volume snapshots: Notice the use of the --force switch when taking a snapshot of an attached volume; the snapshot will work and not fail, however if there are open files being actively written to the validity of the data being cloned cannot be guaranteed.

...