Recommended
More Related Content
What's hot
What's hot (9)
Viewers also liked
Viewers also liked (20)
Similar to Config mgmt camp 2015
Similar to Config mgmt camp 2015 (20)
Recently uploaded
Recently uploaded (20)
Config mgmt camp 2015
- 1. Puppet and OpenStack Colleen Murphy - Puppet Labs
- 2. About Me ● Background in system administration and puppet at Portland State University ● Puppet Labs module engineer ● StackForge puppet core contributor Colleen Murphy ⚙ freenode/crinkle ⚙ twitter/@pdx_krinkle ⚙ github/cmurphy
- 3. Overview ● Intro to OpenStack ● Leveraging puppet for OpenStack ● What makes puppet awesome at this ● Challenges we’re facing as puppet users
- 4. What is OpenStack? OpenStack is an open source cloud computing platform. ● Public clouds - Amazon competitors ● Private clouds - Internal infrastructure, developer support, QA support
- 7. An OpenStack Deployment Cinder Block Storage Designate DNS Trove Database Zaqar Messaging Manila Shared Files Horizon Dashboard Tempest QA Glance Image Swift Object Storage Ceilometer Telemetry Sahara Data Processing Neutron Networking Heat Orchestration Barbican Key Mgmt Ironic Bare Metal Nova Compute Keystone Identity MySQLRabbitMQ
- 8. An OpenStack Deployment Cinder Block Storage Designate DNS Trove Database Zaqar Messaging Manila Shared Files Horizon Dashboard Tempest QA Glance Image Swift Object Storage Ceilometer Telemetry Sahara Data Processing Neutron Networking Heat Orchestration Barbican Key Mgmt Ironic Bare Metal Nova Compute Keystone Identity MySQLRabbitMQ
- 9. Puppetizing OpenStack Cinder Block Storage Designate DNS Trove Database Zaqar Messaging Manila Shared Files Horizon Dashboard Tempest QA Glance Image Swift Object Storage Ceilometer Telemetry Sahara Data Processing Neutron Networking Heat Orchestration Barbican Key Mgmt Ironic Bare Metal Nova Compute Keystone Identity MySQLRabbitMQ
- 10. Puppetizing OpenStack Cinder Block Storage Designate DNS Trove Database Zaqar Messaging Manila Shared Files Horizon Dashboard Tempest QA Glance Image Swift Object Storage Ceilometer Telemetry Sahara Data Processing Neutron Networking Heat Orchestration Barbican Key Mgmt Ironic Bare Metal Nova Compute Keystone Identity MySQLRabbitMQ openstacklib openstack_extras apache firewall epel corosync memcached ntp apt
- 11. StackForge
- 12. Tools using Puppet for OpenStack ● Fuel ● RDO/PackStack ● TripleO-Puppet-Elements
- 13. Popularity of Puppet Source: OpenStack User Survey November 2014
- 14. Why is puppet great at this?
- 15. Resource Abstraction Layer package { 'nova': ensure => installed, name => $package_name, } file { '/etc/nova/nova.conf': mode => 0640, owner => 'nova', group => 'nova', require => Package['nova'], } service { 'nova-api': ensure => running, enable => true, }
- 16. Resource Abstraction Layer keystone_tenant { 'services': ensure => present, description => 'Services Tenant', enabled => true, } neutron_subnet { '10.0.0.0/24': cidr => '10.0.0.0/24', ip_version => '4', enable_dhcp => true, network_name => 'private', tenant_name => 'services', dns_nameservers => [$dns], } nova_config { 'DEFAULT/default_floating_pool': value => 'private' }
- 19. Active Community
- 20. Hiera ######## Fixed IPs (controllers) openstack::controller::address::api: '192.168.11.4' openstack::controller::address::management: '172.16.33.4' openstack::storage::address::api: '192.168.11.5' openstack::storage::address::management: '172.16.33.5' ######## Database openstack::mysql::root_password: 'spam-gak' openstack::mysql::service_password: 'fuva-wax' openstack::mysql::allowed_hosts: ['localhost', '127.0.0.1', '172.16.33.%'] openstack::mysql::keystone::user: 'keystone' openstack::mysql::keystone::pass: 'fuva-wax'
- 21. Hiera node 'control.example.com' { include ::openstack::role::controller } node 'storage.example.com' { include ::openstack::role::storage } node 'network.example.com' { include ::openstack::role::network } node 'compute.example.com' { include ::openstack::role::compute }
- 22. What challenges are there?
- 24. High Availability Image source: cloudcaboodle.com
- 25. Testing
- 26. Keeping up
- 28. Thanks! Colleen Murphy ⚙ freenode/crinkle ⚙ twitter/@pdx_krinkle ⚙ github/cmurphy
Editor's Notes
- 1. This talk is about openstack and how we’re trying to solve some of the problems of installing and managing an openstack deployment using puppet.
- 2. I was a student at Portland State University and learned puppet and system administration as a student worker there. I was hired at Puppet Labs a few months ago, where my focus has been on contributing to the community-maintained OpenStack modules on StackForge.
- 3. I want to very briefly give a baseline overview of what openstack is and how its architecture looks, just enough so I know we’re all on the same page, because next I want to talk about how the openstack modules are used to deploy this architecture. Then I want to highlight some of the features in puppet that make it really well suited for this, and then talk about some of the challenges we’re facing having chosen puppet as the tool for this.
- 4. OpenStack is an open source cloud computing platform. It has two main use cases: public clouds, where a cloud company productizes it, sticks some value-adds on it, and markets it as an Amazon competitor; and private clouds, where you run a virtualization platform to support internal infrastructure, run your application on it, or make it available for use by developers, QA engineers, researchers, students, etc.
- 5. An OpenStack deployment starts out with two base components: a relational database server, usually MySQL or one of the forks, and RabbitMQ as the messaging service. Every OpenStack service has its own database and every service connects to the messaging queue.
- 6. On top of that, the first OpenStack service that needs to be set up is Keystone, the identity service. This provides a place to register and look up other services and endpoints, plus service users, authentication, and access control.
- 7. Then we have everything else, with varying degrees of dispensability and from which operators can pick and choose. These services may be grouped together across a set of nodes, and in some cases the service is split up into an API server and an agent, and sometimes they are replicated and load balanced in an HA setup. There isn’t a single “right” configuration.
- 8. We can consider a couple of these as core services that basically any OpenStack cloud will have. Nova is the compute service. Neutron provides networking, though some of that functionality can be found in Nova. Cinder is the block storage service, so any long-term block-type data will need Cinder.
- 9. Where puppet comes into this is we have puppet modules for installing and configuring almost all of the openstack services and then we use the puppetlabs modules for rabbitmq and mysql. Within the modules, we have different classes for managing different parts of the service, so the api services and the actual worker services are separated but can share parameters.
- 10. In addition to that, we have two special modules: openstacklib is for common code that the modules share, because they’re surprisingly similar, so things like setting up the databases, database users and rabbitmq users, and common code in the types and providers, can go in openstacklib; openstack_extras is for the extra stuff around the modules that go with setting up a full openstack deployment, where so far we have code to manage package repositories and we’re in the process of adding pacemaker support for HA deployments.
- 11. The puppet modules live on StackForge, which is the home for OpenStack-related but not OpenStack-core projects. Being on stackforge means we get to take advantage of the openstack CI system, review process, and source hosting. We have numerous dedicated maintainers, primarily operators trying to use these in production or developers trying to integrate the modules into their own third-party tooling. The modules are not owned by puppet labs or any particular company.
- 12. To explain the third-party tooling a bit, there are three main tools that specifically integrate the StackForge puppet modules. Fuel is an open source deployment framework from Mirantis that uses the puppet modules as a primary component. RDO and PackStack are from RedHat; PackStack is a utility built by RedHat on top of the puppet modules and RDO is a packaged set of installation tools, including PackStack. TripleO is the official OpenStack deployment tool, and now has experimental integration with the puppet modules, with intentions to integrate with ansible and chef as well. Other tools are also able to integrate with puppet, such as juju and foreman.
- 13. Puppet is consistently voted the most popular deployment tool for OpenStack Sources: http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 http://www.slideshare.net/ryan-lane/openstack-atlanta-user-survey
- 14. What are the features of puppet and the puppet ecosystem that make it great at doing openstack?
- 15. The resource abstraction layer helps us manage traditional resources like packages, files, and services in an easy, implementation-agnostic way.
- 16. Where it really shines here, though, is we now also have the ability to invent totally new resources, and in our case we’re writing a lot of types and providers to manage openstack resources. So we’re able to manage things like keystone resources, service registration, network subnets, glance images, all in puppet. These are all managed via REST APIs that might not be on the same node, so that means we're doing things like authenticating against an endpoint in the provider, and writing timeouts and retries within the provider. We’re able to express a lot semi-complicated things in this way. Another interesting one is these resources for managing individual parameters in config files, nova_config is an example here. It’s kind of like a stripped-down version of the ini_setting resource specific to each service, with the idea that there are different pieces of a service managing the same config file, so rather than making complex templates or using concat fragments, we're treating each parameter as its own resource.
- 17. Within a single node, puppet is fantastic at setting up resources in the right order. This is important when we have a lot of things going on in a node, all depending on each other and talking to each other.
- 18. Because puppet promotes this modular approach to config management, we get this ability to build cool things out of chunks. We can reuse other modules to save ourselves a bunch of work, and we make the modules logically separate and as configurable as possible so they can be used in different types of deployments. We’re not creating a dot slash installopenstack.sh, we’re developing building blocks and using other building blocks to help compose OpenStack.
- 19. Part of why puppet is so popular in openstack is because it’s so popular in general, and the active community in puppet is a big factor in that.
- 20. We love hiera in OpenStack for the same reason we love hiera for everything else: we get to separate secrets and mundane data from the code, so that ...
- 21. ... you end up with cleaner manifests in the end.
- 22. What challenges are we facing having chosen puppet as our deployment technology?
- 23. There is currently no native inter-node orchestration in puppet, so when we say we deploy OpenStack using puppet, that's not really the whole picture. We need something else for this. People are using MCollective, Ansible, and other tools to accomplish this, but there isn't a standard. Puppet Labs has announced its plans to try to handle this natively, but for people deploying OpenStack now, it's an issue.
- 24. High Availability support is an area of active development, and we have some initial groundwork set up in openstack_extras to use pacemaker for this. Some of the challenges here, though, are 1) the definition of HA is different for different services - a storage service has different HA needs than an API service, for example, and 2) HA is, by its nature, a multi-node issue, so we still face challenges with orchestration.
- 25. We use rspec and rspec-puppet for writing unit tests for all the modules, and that helps a lot. We don’t yet have functional testing. We want to be using beaker-rspec for this since it’s the recommended way to test modules. There’s two problems here, one is a technical problem that’s largely been solved and one is more of a social problem. The first problem is that the modules are using the openstack-infra CI to run tests on, which is kind of a foreign environment to beaker. Beaker wants to manage spinning up the vms itself, and the openstack-infra nodepool and zuul and jenkins are already in charge of that. Spencer from the infra team has helped us a lot in hacking a way to get beaker and nodepool to cooperate with each other, but we still don’t really know how this is going to work for multinode nodesets. So we’ve got the groundwork set up for some initial functional testing, and we’re in the process of developing that, but now we have the challenge that these modules are already written, so adding in tests at this point is going to be a tedious challenge that no one has really picked up yet.
- 26. These projects are very fast-paced, things change all the time. Sometimes its breaking changes, sometimes its new features we want to take advantage of. Luckily we have a lot of skilled OpenStack operators who are always on top of what's breaking and changing in their infrastructure, so we are good at reactively fixing things, but it's an ongoing effort.
- 27. Even though OpenStack is a challenge, I really enjoy working on this because OpenStack is causing us to find really creative solutions to interesting problems. The challenge is fun, and working with a smart community toward different but overlapping goals is kind of awesome, and that’s why I wanted to give this talk and share where we’re at with this project.
- 28. :)