Chris Paquin

AI, Virtualization, Containers, Infrastructure, Linux

Tag: openstack.

  • OpenStack: Upload Glance Image Via the Command Line

    openstack

    It seems that every once and a while I run into issues uploading an image into Glance while using the WebUI. The “Create Image” function will just flat out fail without any helpful error messages.

    As a work around to the failure listed above, I suggest using the simple example shown below to upload an image. Note that all commands are being run from the Controller Node.

    First source your keystone credentials.

    [root@rhel7 ~]# source keystonerc_admin

    Then run the command below and wait for the output. If your’s looks anything like mine, then you will know that the image uploaded without issue.

    NOTE: The commands below have two dashes before each option…. its hard to see this in the output.

    [root@rhel7 ~(keystone_admin)]# glance image-create –name Cirros –disk-format qcow2 –container-format bare –is-public True –copy-from http://download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-disk.img

    +——————+————————————–+
    | Property | Value |
    +——————+————————————–+
    | checksum | None |
    | container_format | bare |
    | created_at | 2015-03-29T04:50:38 |
    | deleted | False |
    | deleted_at | None |
    | disk_format | qcow2 |
    | id | dd5937ef-c30c-465b-ba45-3f76a59164cd |
    | is_public | True |
    | min_disk | 0 |
    | min_ram | 0 |
    | name | Cirros |
    | owner | 1d84fe28da3f4e0a830c52929d85c917 |
    | protected | False |
    | size | 13200896 |
    | status | queued |
    | updated_at | 2015-03-29T04:50:38 |
    | virtual_size | None |
    +——————+————————————–+

    Feel free to verify this in the WebUI, just make sure that you refresh the page before you think you have been lulled into a false sense of accomplishment.

    Alternatively, you can also upload an image directly from local disk. In my particular case I am uploading directly from a locally mounted NFS mount.

    root@rhel7 storage(keystone_admin)]# glance image-create –name RHEL7-Guest –disk-format qcow2 –container-format bare –is-public True –file /storage/NAS/storage/rhel-guest-image-7.0-20140930.0.x86_64.qcow2

    +——————+————————————–+
    | Property | Value |
    +——————+————————————–+
    | checksum | 4fcc9b2b8db610187a6e7eac02608ab6 |
    | container_format | bare |
    | created_at | 2015-03-29T05:07:46 |
    | deleted | False |
    | deleted_at | None |
    | disk_format | qcow2 |
    | id | 5f6222b2-8b37-45e6-96db-c9fee8cb84b4 |
    | is_public | True |
    | min_disk | 0 |
    | min_ram | 0 |
    | name | RHEL7-Guest |
    | owner | 1d84fe28da3f4e0a830c52929d85c917 |
    | protected | False |
    | size | 435639808 |
    | status | active |
    | updated_at | 2015-03-29T05:08:21 |
    | virtual_size | None |
    +——————+————————————–+

  • OpenStack Packstack – How to configure an External Facing Bridged Interface

    openstack

    Specifically these directions are applicable to my experience with the OpenStack Packstack Installer, specifically when installing RHEL OpenStack 6 on RHEL 7. Plus, to get more specific (if that’s even possible — why yes it is), you will only need to follow the following steps on your Controller Node.

    Note that I am installing OpenStack on two VMs in my HomeLab for testing purposes. Once machine will serve as a ‘All-In-One”  Controller/Compute/Network/Storage node and the other machine will serve as a Compute Node.

    Basically what I am doing here is configuring networking in such a way to allow inbound access from my “public
    lab network. Without this I would not be able to SSH to the Floating IP addresses that are assigned to my instances.

    Note that my public interface is ens192 and has an ip address of 10.1.3.10. Here I copy ifcfg-ens192 to ifcfg-br-ex., which will be my external bridge. Note: br-ex is short for bridge external, however br-int is not short for bridge internal, rather it is short for integration bridge….not that we are talking about br-int, but I figured it was worth a mention.

    # cp ifcfg-ens192 ifcfg-br-ex

    I then modify the file as shown below. The device br-ex will effectively take the reins on hosting our external facing ip address. By moving ens192 to br-ex we are allowing Openvswitch to ‘hang’ additional ip addresses on this interface. “DEVICETYPE=ovs” tells the networking service that this device uses Openvswitch. “TYPE=OVSBridge” lets the networking service that this device will act as a bridge

    DEVICE=br-ex
    DEVICETYPE=ovs
    TYPE=OVSBridge
    BOOTPROTO=static
    IPADDR=10.1.3.10
    NETMASK=255.255.255.0
    GATEWAY=10.1.3.1
    ONBOOT=yes

    We also need to create a new ifcfg-ens192 file. Follow the template below. “TYPE=OVSPort” tells your networking service that this device is a port on an OVS bridge, while “OVS_BRIDGE” tells networking the name of the bridge where we need to attach.

    DEVICE=ens192
    ONBOOT=yes
    TYPE=OVSPort
    DEVICETYPE=ovs
    OVS_BRIDGE=br-ex

    Now you should be able to restart networking. Make sure that you have console access before you attempt the restart, just in case you fat-fingered something.

    If you are unable to ping your floating ip addresses from the public network, you have screwed something up.

  • Installing Red Hat Enterprise Linux OpenStack with Foreman

    openstack
    If you are looking to know a bit more about Red Hat’s offering in the OpenStack space, this is a good video to start with. The video also takes you through the “Evolution Of OpenStack Deployment Tools” which is helpful for those of us who are just getting our feet wet with OpenStack.

    For additional information on RHEL OpenStack 6 (Juno), this link below has plenty of helpful information.

  • What the Heck is a Linux Container, and Who the Hell is Docker?

    Docker-whaleA Linux Container is an Operating System level virtualization method for running isolated Linux environments on a single base install of Linux. Linux containers are not virtual machines, rather they are isolated virtual environments with dedicated CPU, memory, I/O, and network. One can think of a Linux Container as a light, virtual OS instance. At first glance one hearkens back to the time of Solaris Containers, but there is a lot more going on here then first meets the eye, especially when we throw Docker in the mix.

     

    But first, lets focus on Linux Containers…

     

    The technologies behind Linux Containers are Control Groups and Name Spaces. Control Groups manage and monitor resource allocation for processes and process groups such as CPU, Memory, and I/O. Name Spaces help isolate processes, in something akin to a chrooted environment, making processes running within them invisible to other processes in other Name Spaces.

     

    So why would you possibly want to run a Linux Container?

     

    Well for one you can consolidate multiple Linux servers into one Machine, therefor reducing the number of management points in your environment. Instead of having to patch 6 Virtual Machines, you now only have to patch one.

     

    Linux Containers can also be used to quickly spin up sandbox environments for development and testing so that you no longer need to spin up a new VM for each individual project. As we all know, this is how we end up with Virtual Sprawl. You create someone a Virtual Machine, with the intention of reclaiming it after a short period of time and all of a sudden that Virtual Machine becomes a permanent fixture in your environment. In the case of Linux Containers, you just tear down the instance and toss it away.

     

    Also, Linux Containers can be used to allow you to run multiple instances of the same application in parallel. Think of Apache virtual servers, running separately, independent and isolated from each other. Each with its own dedicated CPU, Memory, and I/O, and never stepping on each others toes.

     

    Linux Containers also provide an added layer of security. Just because a Container on a server is compromised, it does not mean that any other local Containers, or the base system itself is compromised in the least.

     

    Finally Linux Containers are efficient. First and foremost, they boot faster than traditional Virtual Machines. They also offer better performance over Virtual Machines as there is no hardware abstraction layer in the form of a hypervisor.

     

    So what is Docker then, you ask? Docker is an open source project that streamlines the deployment of an application (or OS) inside a Linux Container. Its designed to make the creation and management of Linux Containers simple as Docker can create and share disk images with ease.

     

    Here are just a few of the images available from the Docker Hub.

    • Apache CouchDB

    • PostgreSQL

    • Memcached

    • Mongo DB

    • NGINX

    • Mysql

    • WordPress

    • Centos

    • Ubuntu

    Whats amazing is that any dockerized image can run on any machine that is running docker. Imagine an Ubuntu docker image running on Centos. Weird huh?

     

    Have yourself a perfect OS image for your in-house java app? How about you dockerize that and use Docker as a revision control system for your application/OS. Sounds interesting, doesn't it.

     

    I have heard it said that Docker is not just Platform as a Service (PAAS) , its possibly could be much more than that. Right now Docker only works with Linux Containers, but imagine if it worked with KVM or Xen.

     

    Not sure about you but I look forward to getting deploy it in my lab.

    Related articles

    libswarm – Docker Orchestration Announced
    Docker 1.0 Provides Enterprise Support for Container Virtualization
    Docker 1.0 Backed By IBM, Red Hat, Rackspace
    Docker all geared up for the enterprise
    Docker: Lightweight Linux Containers for Consistent Development and Deployment
    Docker Software Containers Go Commercial