cloud:intro
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| cloud:intro [2019/12/06 14:26] – chudler | cloud:intro [2020/01/16 15:39] – I forced python 3 and install to a user directory. kauffman | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| === SCOPE OF THIS DOCUMENT === | === SCOPE OF THIS DOCUMENT === | ||
| - | This guide will cover a common subset of tasks that a user would need to perform to have a set of clustered computer instances and associated resources, isolated from others, and accessible to a project for any general purpose, both long-term and short. We are catering heavily to short-term usage, perhaps lasting a few quarters. | + | This guide covers the common subset of tasks that users would need to perform to have a set of clustered computer instances and associated resources, isolated from others, and accessible to a project for any general purpose, both long-term and short. We are catering heavily to short-term |
| - | Some things that are not here but perhaps should be covered elsewhere | + | Some things that are not written about here but perhaps should be covered elsewhere |
| - | * Theory of operations (everything is by example) | + | * Theory of operations (everything |
| - | * Tasks accomplished | + | * Accomplishing tasks from the Web Interface |
| * Background and History | * Background and History | ||
| - | * Organizational Policy, such as who can do what. | + | |
| + | | ||
| * Deployment Architecture | * Deployment Architecture | ||
| - | * Limitations | + | * Systemic |
| - | * User management, Group management, and similar concepts | + | |
| * Good Practices (because they are nascent, at best) | * Good Practices (because they are nascent, at best) | ||
| * Cloud init, Fog, Terraform, Heat, and other operational tools | * Cloud init, Fog, Terraform, Heat, and other operational tools | ||
| - | * Security | + | * Network and Information |
| * Backup and Restore | * Backup and Restore | ||
| Line 26: | Line 26: | ||
| === INTRODUCTION AND NOTES === | === INTRODUCTION AND NOTES === | ||
| - | This cluster can spring into being computer resources, easily, and without | + | This cluster can spring into being computer resources, easily, and without |
| * L2 and L3 Network | * L2 and L3 Network | ||
| * Router (SNAT and DNAT devices, etc) | * Router (SNAT and DNAT devices, etc) | ||
| * Compute, and all that it entails such as RAM, CPU, Disk, ... | * Compute, and all that it entails such as RAM, CPU, Disk, ... | ||
| - | * Block Storage (volume mounts) | + | * Additional |
| * Security groups (firewall service) | * Security groups (firewall service) | ||
| Line 42: | Line 42: | ||
| * NFS | * NFS | ||
| * Rancher Kubernetes (among others) | * Rancher Kubernetes (among others) | ||
| + | * Lots more | ||
| == Web Access and Certificates == | == Web Access and Certificates == | ||
| - | The cloud is named **Overcloud**. The web interface at [[https:// | + | The cloud is named **Overcloud**. The web interface |
| NOTE: Our cloud DNS service might not meet your needs. Please test it anyway if you know how (TODO: document) | NOTE: Our cloud DNS service might not meet your needs. Please test it anyway if you know how (TODO: document) | ||
| Line 81: | Line 82: | ||
| Use your favorite package manager on your own computer. Pip is preferred because the upstream packages it for themselves and it is in pure python. The general CS infrastructure will become a managed client for you to use in the near future (e.g., linux.cs.uchicago.edu). However, our experience has been that the software installs cleanly and is free from dependency problems. | Use your favorite package manager on your own computer. Pip is preferred because the upstream packages it for themselves and it is in pure python. The general CS infrastructure will become a managed client for you to use in the near future (e.g., linux.cs.uchicago.edu). However, our experience has been that the software installs cleanly and is free from dependency problems. | ||
| - | Try: < | + | Try: < |
| == PRELIMINARY SETUP == | == PRELIMINARY SETUP == | ||
| Line 166: | Line 167: | ||
| After creating your own network and subnet(s), a router is also needed. However, a router is **not** needed if your instances only talk to each other. The router will take the gateway of your subnet automatically, | After creating your own network and subnet(s), a router is also needed. However, a router is **not** needed if your instances only talk to each other. The router will take the gateway of your subnet automatically, | ||
| < | < | ||
| - | openstack router add subnet mysubnet</ | + | openstack router add subnet |
| - | With the router created and attached to your subnet, develop it further. | + | With the router created and attached to your own subnet, develop it further. |
| - | < | + | |
| - | The output of the command | + | After this command, the router will have one leg in your subnet and one leg in the public campus network |
| - | < | + | |
| - | +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | + | |
| - | | Field | Value | | + | |
| - | +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | + | |
| - | | created_at | + | |
| - | | description | + | |
| - | | dns_domain | + | |
| - | | dns_name | + | |
| - | | fixed_ip_address | + | |
| - | | floating_ip_address | 128.135.37.244 | + | |
| - | | floating_network_id | f6a5f729-d5bf-4fa7-9cd9-e4ed23c7d48f | + | |
| - | | id | 7110ea40-8c32-4f99-8454-9a091bcd4623 | + | |
| - | | location | + | |
| - | | name | 128.135.37.244 | + | |
| - | | port_details | + | |
| - | | port_id | + | |
| - | | project_id | + | |
| - | | qos_policy_id | + | |
| - | | revision_number | + | |
| - | | router_id | + | |
| - | | status | + | |
| - | | subnet_id | + | |
| - | | tags | [] | | + | |
| - | | updated_at | + | |
| - | +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+</ | + | |
| Only you will be able to use this address until you destroy it. **DONT ever take more than you need and free this resource as soon as you project ends.** | Only you will be able to use this address until you destroy it. **DONT ever take more than you need and free this resource as soon as you project ends.** | ||
| - | |||
| - | Give this address to your Router, on a new interface. After this command, the router will have one leg in your subnet and one leg in the public campus network (and internet). The example above gave us 128.135.37.244. | ||
| < | < | ||
| - | openstack router set --fixed-ip subnet=$(openstack subnet show --format value --column id public37), | + | openstack router set myrouter |
| </ | </ | ||
| Line 242: | Line 216: | ||
| You could also use the web interface to access the console, but that's not quite the same. | You could also use the web interface to access the console, but that's not quite the same. | ||
| As before, in the Network Gear section, get a campus IP address from our pool. | As before, in the Network Gear section, get a campus IP address from our pool. | ||
| - | < | + | < |
| + | openstack server add floating ip myserver 128.135.37.XX | ||
| + | </ | ||
| + | |||
| + | Note that the command is showing you a deeper and more rare UX pattern than before: | ||
| + | |||
| + | < | ||
| + | openstack server $action $subresource $more_options | ||
| + | </ | ||
| At last, you can ssh into 128.135.37.XX. It is important for you to realize that your __local__ server IP does not change (no new interface is given to the instance). Instead, the router on the subnet simply performs DNAT on behalf of the clients. Here's another possibility: | At last, you can ssh into 128.135.37.XX. It is important for you to realize that your __local__ server IP does not change (no new interface is given to the instance). Instead, the router on the subnet simply performs DNAT on behalf of the clients. Here's another possibility: | ||
| < | < | ||
| - | **Now** your server does have a new interface attached to it, and will be served a DHCP address | + | **Now** your server does have a **new** network |
| + | |||
| + | This section added a floating ip address directly to the server. You must realize that a router was needed on the subnet for that to happen. We had created the router earlier for the purpose of SNAT, and had we not done that, this command would have failed. This means that if you are not doing SNAT, you should create a router anyway, but __do not__ give it a campus address of its own. | ||
| == A WORD ABOUT CLOUD INIT == | == A WORD ABOUT CLOUD INIT == | ||
| - | Your author uses cloud init extensively and does not imagine a life without it. It is optional. The file used in these examples is attached to this email, but you should develop your own if you use it at all. | + | Your author uses cloud init extensively and does not imagine a life without it. It is optional. The file used in these examples is available on request, but you should develop your own if you use it at all. |
| - | == FAQ, NAQ (Never Asked Questions) == | + | === NAQ (Never Asked Questions) |
| Q: Why does it use a self-signed certificate? | Q: Why does it use a self-signed certificate? | ||
/var/lib/dokuwiki/data/pages/cloud/intro.txt · Last modified: 2021/04/15 17:50 by chudler