Powered By Blogger

2015/07/29

Packstack Installation with Existing External Network / kickstart RHEL7 (CentOS7)

Interested in getting OpenStack up and running within few hours in the easiest possible way? Then Packstack is most probably your friend. Indeed, Packstack is a utility which leverages on Puppet modules to deploy various parts of OpenStack on multiple pre-installed servers over SSH automatically. I've been through a cycle of building/destroying my OpenStack Labs by using this tool and I'm willing to share below a Kickstart File which fully automate such type of Installation (OpenStack using PackStack with an Existing External Network). The initial process on which I built this KickStart Installation is well documented here. My main aim here is to be able to reference a Single Kickstart File during my RHEL/CentOS 7 Installation and have OpenStack Installed and partly configured without manual Intervention (except for a reboot that I preferred not to automate :-) ).

The same Kickstart File can also be used as a Template for RHEL7/CentOS7 (or any other Systemd-based's distribution), especially if there's a need to run some script (or any other program) during the first boot (after OS installation) of the System (see the %post section).
In fact, in this Kickstart File I've edited and created a Systemd service that will run only once after the first boot and delete itself.
I was used to do that on previous RHEL/CentOS (RHEL6...) by leveraging on /etc/rc.local. Though there’s still /etc/rc.local  on RHEL7,It is highly advisable to create own systemd services or udev rules to run scripts during boot instead of using that file.

Note that after the initial reboot, Packstack Configuration Progress can be followed using journalctl (journalctl -f -u pacstack_installation.service) 

Few Things that are specific to this Kickstart:
System Hostname: stiv-opsctr01
System IP: 192.168.0.21/24
System GW: 192.168.0.1 
DNS1 IP: 192.168.0.30
DNS2 IP: 192.168.0.31
PROXY and Install Server (I'm using proxy for Internet Access) : 192.168.0.33


My Kickstart File:



References:

2015/07/19

Puppet puppetlabs/apache SSL Vhost with Hiera

I've been writing a bunch of Puppet Modules to manage Servers these last time, and one of the thing I figured out(somewhat in a painful way...), is how much I needed to separate my Puppet configuration data which varies a lot from my Puppet Manifest, which I'm willing to keep as much static as possible. So, I naturally shifted from a bunch of <if-else> in some params.pp  to a clean and efficient Hiera Configuration (I read somewhere this great way of summarizing what Hiera is: Hiera lets you separate the "how" from the "what").

Anyway, moving forward in this process, I stumbled upon the re-configuration of some Apache VirtualHosts with Hiera (using the puppetlabs-apache module).  As seen in the example below, I've stivesso.mysite.org configured on both http and https, with http redirected to https. This code worked so well, but as explained above, my aim was to draw a clear line between what it does (configuring http, https server  in such a way that the user will also get to https) and the configuration Data associated (stivesso.mysite.org). Succeeding in that enterprise means that  I can with the same code, configured my others Vhosts Servers in an easy and repeatable way. 


class roles::myweb {

# Include Apache
    class { 'apache':
        default_vhost        => false,
    }
  
    apache::vhost { 'stivesso.mysite.org-nossl':
        servername      => 'stivesso.mysite.org',
        port            => '80',
        docroot         => '/var/www/html/stivesso',
        redirect_status => 'permanent',
        redirect_dest   => 'https://stivesso.mysite.org/'
    }

    apache::vhost { 'stivesso.mysite.org-ssl':
        servername => 'stivesso.mysite.org',
        port       => '443',
        docroot    => '/var/www/html/stivesso',
        ssl        => true,
        ssl_cert   => '/etc/pki/tls/certs/stivesso.crt'
        ssl_key    =>'/etc/pki/tls/certs/stivesso.key'
    }

}


Now, using Hiera would have been quite simple if apache::vhost was a Class, I'd just have added in my Hiera Configuration files directive such as  "apache::vhost::docroot": "/var/www/html/stivesso"...
But apache:vhost isn't a Class, it is a defined type, and Puppet DataBinding only works on Classes. The best way to workaround this and be able to use Hiera is to leverage the Function create_resources. In fact, create_resources is a function which converts a hash into a set of resources and adds them to the catalog. It's taking as argument a resource type (which is exactly what a Defined Type is) and the hash that will be converted to a set of resources. Fortunately, the hiera() lookup function returned Hiera data as a hash.
Below is what my Hiera configuration will look like


[stiv@puppetmaster ~]# cat /etc/puppetlabs/puppet/hieradata/node/myweb01.yaml
---
apache::vhost:
  'stivesso.mysite.org-ssl':
    servername: 'stivesso.mysite.org'
    serveraliases:
        - 'www.stivesso.mysite.org'
    serveradmin: 'stiv@myself.net'
    port: '443'
    docroot: '/var/www/html/stivesso'
    ssl: true
    ssl_cert: '/etc/pki/tls/certs/stivesso.crt'
    ssl_key: '/etc/pki/tls/certs/stivesso.key'
  'stivesso.mysite.org-nossl':
    servername: 'stivesso.mysite.org'
    serveraliases:
        - 'www.stivesso.mysite.org'
    serveradmin: 'stiv@myself.net'
    port: '80'
    docroot: '/var/www/html/stivesso'
    redirect_status: 'permanent'
    redirect_dest: 'https://stivesso.mysite.org/'

And my Puppet Module,


class roles::myweb {

    # Include Apache
    class { 'apache':
        default_vhost        => false,
    }
  
    # Create a hash from Hiera Data with the Vhosts
    $myApacheVhosts = hiera('apache::vhost', {})

    # With Create Resource Converts a hash into a set of resources
    create_resources('apache::vhost', $myApacheVhosts)

}

Well, clean module! The how (module) and the what (data) separated, That seems like what I wanted initially...