How do I?

User Tools

Site Tools

You are here: start » cloud » cli
cloud:cli

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
cloud:cli [2020/05/14 09:49] – chudlercloud:cli [2021/04/15 16:45] – chudler
Line 8: Line 8:
 ===== CONFIGURATION ===== ===== CONFIGURATION =====
  
-Use a clouds.yaml file to direct your client. Below is a canonical example, but you __will__ have to modify the variables according to your account. +Use the ''~/.config/openstack/clouds.yaml'' file to direct your client.  
-''$HOME/.config/clouds.yaml''+ 
 +=== Generate New Credentials === 
 + 
 +Instead of taking risks and storing your University credentials in the file, use the [[ https://overcloud.cs.uchicago.edu | Web Interface ]] to create an Application Credential. Click the menu on the left side, Identity→Application Credentials. On the right side of the top of the page, click "Create Application Credential". Complete the form and check the box for ''unrestricted access''. Save the ''clouds.yaml'' file in your configuration directory. 
 + 
 +See the [[ cloud:recipe:coding | Python Examples Document ]] for detailed configuration recommendations. 
 + 
 +==Cloud Name== 
 +For convenience, export the cloud name to your environment. Otherwise, all commands must include the flag ''--os-cloud=openstack'':
 <code> <code>
-clouds: +export OS_CLOUD=openstack 
-  openstack: +
-    auth: +
-      auth_url: https://overcloud.cs.uchicago.edu:5000 +
-      username: "CNetID" +
-      password: "sekret" +
-      project_id: YOUR PROJECT UUID +
-      project_name: "CNetID" +
-      user_domain_name: "CS_LDAP" +
-    region_name: "RegionOne" +
-    interface: "public" +
-    identity_api_version: 3+
 </code> </code>
-The [[ cloud:recipe:coding | Python Examples ]] use the same configuration, please read that document for detailed information about configuration and recommendations. 
- 
-You can also download a customized version of this data after you authenticate to the Web Interface (click API Access from the menu and then the button "Download Openstackrc File"). Make sure you read this file carefully in case you want to customize it. Your password is not included in the file by default. 
  
 ====== USAGE ====== ====== USAGE ======
Line 35: Line 29:
 </code> </code>
  
-take note and always use help for guidance <code>--help</code> +always use help for guidance <code>--help</code> 
  
 For example<code>openstack server create --help</code> For example<code>openstack server create --help</code>
Line 47: Line 41:
 <code>openstack server list</code> <code>openstack server list</code>
  
-Images are prebuilt disks that are used to launch instances. They are usually a few GB in size. A copy of the disk image is written into the instance's boot volume just before it starts running. +====Images====
-There are images that Techstaff provides, some of which are restricted-use. We can build images for you or you can build and upload your own. Our images are generic, bare bones, cloud enabled popular operating systems that are a firm foundation for you to customize from. They are often in RAW format, not qcow2, for performance reasons. +
-<code>openstack image list</code>+
  
-Openstack can hold a public key in its db, and insert it into instances when told. This is optional (your author does not use this) +Images are prebuilt operating systems that are used to launch instances. It is equivalent to a live CD. They are usually a few GB in size. A copy of the disk image is written into the instance's boot volume just before it starts running.
-<code>openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey</code>+
  
-A flavor is a pre-chosen size for resources that make up an instance. It is a mandatory parameter when creating instances. Look at the available flavors ,which your admins have created.\\ +There are images that Techstaff provides, some of which are restricted-use. We can build images for you or you can build and upload your own. Our images are generic, bare bones, cloud enabled, popular operating systems, that are a firm foundation for you to customize from. They are often in RAW format, not qcow2, for performance reasons.
-Servers can grow after creation. For example, the disk-size attribute merely expresses the **minimum** size of the boot volume, and most cloud-enabled operating systems expand the root volume on first-boot. In spite of this, relying on dynamically resizing instances increases risk, and it is far better to size them correctly when they are built. +
-<code>openstack flavor list</code>+
  
-Look at the Networks that are available (an Openstack "Network" captures L2 semantics, and houses L3 subnets). FYI: As of 6DEC19, we have not tested IPv6 for instances.+Beware of images that are used internally to provide cloud services. You should not usually launch these directly. You do have access to them for the use of a service, and are welcome to customize for advanced usage.
  
-You are free to use the Network called __cloud__, if you don't need your hosts to be L2 isolated from other people, and you would like to proceed directly to creating servers. +<code>openstack image list</code>
-Using the __cloud__ network cuts down your complexity significantly, and can be changed later, or mixed with other modes at your leisure. Please talk with us if you want to attach a Router to the __cloud__ network.+
  
-<code> +====SSH Keys====
-openstack network list +
-</code>+
  
-[EDITOR NOTE: This section should be isolated from the main body]+Openstack can hold a public key in its db, and insert it into instances when told. This is optional (your author does not use this capability) 
 +<code>openstack keypair create --public-key ~/.ssh/id_ed25519.pub mykey</code>
  
-=== OPTIONALLY CREATING YOUR OWN NETWORK GEAR===+==== Flavors ==== 
 +A flavor is a pre-chosen size for resources that make up an instance. It is a mandatory parameter when creating instances. Look at the available flavors, which your admins have created.\\
  
-Should you want to create a network of your own that your hosts will be on, not all of these options are necessary +Servers can grow after creation. For example, the ''disk-size'' attribute merely expresses the **minimum** size of the boot volume, and most cloud-enabled operating systems expand the root volume on first-boot. In spite of this, relying on dynamically resizing instances increases risk, and you should choose a size that is close to what you expect to use. 
-<code> +<code>openstack flavor list</code>
-openstack network create mynet \ +
-  --provider-network-type geneve \ +
-  --enable-port-security \ +
-  --internal +
-</code>+
  
-Now create a subnet for your network. This is mandatory for launching instances in the network that you just created.+==== Networks ===== 
 +Look at the Networks that are available. The meaning of an Openstack "Network" captures L2 semantics, and houses L3 subnets. IPv6 is in preview mode at this time, and is not fully supported on the UC campus.
  
-After this, we now consider you to be a Network Administrator, and that may be more than you bargained for. The meaning of this is that we hold you responsible for connectivity into and out of the subnet, and any conflicts that might arise from your usage of it.+You are free to use the Network called __cloud__, if you don't need your hosts to be L2 isolated from other users, and you would like to proceed directly to creating servers.
  
-The cloud will **not** restrict your choices without cause. This means you can create impossible and insane situations that have no valid solution. There's no unique danger to the cloud infrastructure, however. +Using the __cloud__ network cuts down your complexity significantly, and can be changed later, or mixed with other modes at your leisure. Please talk with us if you want to attach a Router to the __cloud__ network.
- +
-You are now advised that there is no "correct" choice for subnet range and IP. Overlaps are **not** a concern unless you intend to perform route/tunneling among the overlapping regions.+
  
 <code> <code>
-openstack subnet create \ +openstack network list
-  --network mynet \ +
-  --ip-version 4 \ +
-  --subnet-range 192.168.222.0/24 \ +
-  --allocation-pool start=192.168.222.10,end=192.168.222.240 \ +
-  --dns-nameserver 128.135.164.141 mysubnet \ +
-  --gateway 192.168.222.1 \ +
-  --dhcp +
-</code> +
- +
-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, and allow clients to access the internet via outbound NAT. Much more is possible, and a router is a prerequisite for the next step, which is inbound NAT (DNAT). +
- +
-<code> +
-openstack router create --enable myrouter +
-</code> +
-<code> +
-openstack router add subnet myrouter mysubnet +
-</code> +
- +
-With the router created and attached to your own subnet, develop it further. You need to obtain a free IP address on the UC Campus. We call this network __campus37__. The Internet-connected subnet on that network is called __public37__. +
- +
-After this command, the router will have one leg in your subnet and one leg in the public campus network (and internet). +
- +
-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.** +
- +
-<code> +
-openstack router set myrouter \ +
-  --external-gateway campus37 \ +
-  --enable-snat+
 </code> </code>
  
-This is all that will be needed to launch instances. If you had used the network known as __cloud__, you can skip the steps for this custom network and subnet and router.+See also [[ cloud:recipe:networks | Advanced Networking ]] hints.
  
-=== Finally Creating an Instance ===+===== Creating an Instance =====
  
-If all of this worked, you now have all of the prerequisites for launching a virtual computer. These are the prerequisites:+You now have all of the prerequisites for launching a virtual computer. These are the prerequisites:
  
-  * Properly prepared Network -- or use the one called "cloud" if you don't care about the L2 boundary nor the source address of your NAT clients+  * Properly prepared Network -- or use the one called ''cloud'' if you don't mind sharing a broadcast domain, nor wish to control the source address of your NAT clients
   * Flavor Name   * Flavor Name
   * Image Name   * Image Name
Line 135: Line 89:
 <code> <code>
 openstack server create \ openstack server create \
-  --image bionic-server-cloudimg-amd64.raw \+  --image 20.04 \
   --boot-from-volume=32 \   --boot-from-volume=32 \
-  --flavor m1.small \+  --flavor m1.medium \
   --config-drive=true \   --config-drive=true \
   --user-data=/home/chudler/openstack/cluster_test/cloud-init.yml \   --user-data=/home/chudler/openstack/cluster_test/cloud-init.yml \
-  --network mynet \+  --network cloud \
   myserver   myserver
 </code> </code>
  
-The command executed asynchronously, check the status:+The command executed asynchronously, check the status, or supply the ''--wait'' option next time:
  
 <code> <code>
 openstack server list --name myserver openstack server list --name myserver
 </code> </code>
 +
 <code> <code>
 openstack server show myserver openstack server show myserver
Line 156: Line 111:
 <code> <code>
 openstack server create \ openstack server create \
-  --image bionic-server-cloudimg-amd64.raw \+  --image 20.04 \
   --boot-from-volume=32 \   --boot-from-volume=32 \
-  --flavor m1.small \+  --flavor m1.medium \
   --config-drive=true \   --config-drive=true \
   --user-data=/home/chudler/openstack/cluster_test/cloud-init.yml \   --user-data=/home/chudler/openstack/cluster_test/cloud-init.yml \
-  --network mynet \+  --network cloud \
   --min 10 \   --min 10 \
   --max 10 \   --max 10 \
   myserver   myserver
 </code> </code>
 +
 +==== Mandatory Firewall Rules ====
 +If you are using the default security groups, all ingress network communication is dropped.
  
 Here's a nasty thing I use to determine what the security group is for a server (it can be determined also by looking at security groups directly) [ITS BRITTLE, BEWARE] Here's a nasty thing I use to determine what the security group is for a server (it can be determined also by looking at security groups directly) [ITS BRITTLE, BEWARE]
Line 179: Line 137:
 </code> </code>
  
-If I learned the security group successfully, I can let in SSH. By default, **no communication is possible**.+If I learned the security group successfully, I can let in SSH.
  
 <code> <code>
Line 188: Line 146:
 </code> </code>
  
-In actual fact, all of the servers you create will be in the same security group. The above was attempting to suggest effective use of the tools, in combination.+In actual fact, all of the servers you create will be in the same security group, so you will not need to "discover" it more than once.
  
-If everything so far has succeeded. +==== Internet Addresses ====
-If the server's status shows "Active", choose one and get remote access to it. +
-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.+
  
 +If the server's status shows ''Active'', you can assign it an additional IP address. When doing networking work, you might wish to connect to web interface to access the console of the virtual machine.
 +
 +As in [[ cloud:recipe:networks | Advanced Networking ]] get a campus IP address from our pool.
  
 Where do you want to create your floating IP? Where do you want to create your floating IP?
Line 200: Line 158:
 openstack network list openstack network list
 </code> </code>
 +
 Use the network from the previous command: Use the network from the previous command:
 <code> <code>
-openstack floating ip create <network>+openstack floating ip create campus37
 </code> </code>
 +
 You now have an IP you can use:  You now have an IP you can use: 
 <code> <code>
Line 209: Line 169:
 </code> </code>
  
-Note that the command is showing you a deeper and more rare UX pattern than before:+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.
  
-<code> +Here's another possibility:
-openstack server $action $subresource $more_options  +
-</code> +
- +
-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:+
 <code>$ openstack server add network myserver campus37</code> <code>$ openstack server add network myserver campus37</code>
  
 **Now** your server does have a **new** network interface attached to it, and will be served a DHCP address on it. You will almost certainly have to inform the OS about this manually; the cloud may not help you do that. **Now** your server does have a **new** network interface attached to it, and will be served a DHCP address on it. You will almost certainly have to inform the OS about this manually; the cloud may not help you do that.
  
-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. +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. On default subnets, your cloud admin has pre-created suitable routers. The command will fail if you are creating your own subnets and networks without taking similar steps.
- +
-== 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 available on request, but you should develop your own if you use it at all.+
  
 +Mixing and matching these techniques will create hilarious disasters.
 +==== A WORD ABOUT CLOUD INIT ====
 +Your author uses cloud init extensively and does not contemplate alternative. It is optional. A minimal cloud-init for a modern Ubuntu cloud OS might look like this
 +<code>
 +#cloud-config
 +network:
 +  version: 2
 +  ethernets:
 +    net0:
 +      match:
 +        name: en*
 +      dhcp4: true
 +preserve_hostname: false
 +users:
 +  - name: ubuntu
 +    ssh-authorized-keys:
 +      - CONTENTS OF YOUR ssh key .pub file
 +timezone: America/Chicago
 +datasource:
 + OpenStack:
 +  metadata_urls: ["http://169.254.169.254"]
 +  max_wait: -1
 +  timeout: 10
 +  retries: 5
 +  apply_network_config: true
 +manage_etc_hosts: false
 +manual_cache_clean: false
 +</code>
/var/lib/dokuwiki/data/pages/cloud/cli.txt · Last modified: 2021/04/15 16:53 by chudler
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki