Image result for puppet logo

We’re thrilled to collaborate with Puppet to demonstrate network automation with the Cisco Meraki platform and Cisco’s cloud-managed products. Our joint customers, partners, and managed service providers need a way to further simplify at scale – and that means scripting tasks like configuration and auditing across all their Meraki networks. With Puppet, Meraki customers can now define their network configuration and policies and ensure that they remain in the desired state.

The new Cisco Meraki module for Puppet lets you define Meraki organization administrators across all of your networks and across multiple organizations, a task that can be tedious for large IT organizations with complex permissions such as service providers or large IT organizations. Customers are demanding more power, and the module will eventually enable Puppet to manage switch port configurations and control firewall policies across every Meraki cloud-managed device. The module will be available this month and will be an ongoing open source project supported by Cisco’s fastest growing developer community. More details will be shared on the Meraki community.meraki.com and meraki.io.

This Puppet module facilitates the configuration and management of Cisco Meraki via the Meraki Dashboard API and Puppet Resource API + Puppet Device. Current capabilities of the module are limited in scope, but the desire is to gain functionality via community contribution.

Setup Requirements

Use of this module requires Puppet >= 4.10.x (although >= 5.3.6 is suggested) and the following

Agent (Puppet Device)

Puppet Resource API
Resource API can be installed with Puppet via the puppetlabs/resource_api module and resource_api::agent class or manually via

sudo /opt/puppetlabs/puppet/bin/gem install puppet-resource_api

Meraki dashboard-api manually via

sudo /opt/puppetlabs/puppet/bin/gem install dashboard-api

Master

Puppet Resource API
Resource API can be installed with Puppet via the puppetlabs/resource_api module and resource_api::server class or manually via

sudo /opt/puppetlabs/bin/puppetserver gem install puppet-resource_api

Beginning with ciscomeraki-meraki

Usage of the module requires a Meraki Dashboard API access enabled and an API access key.https://documentation.meraki.com/zGeneral_Administration/Other_Topics/The_Cisco_Meraki_Dashboard_API

Puppet device is to be configured per Meraki Organization. A list of organizations the user has access to can be gathered with the Puppet Task meraki::list_orgs

[[email protected] tasks]# puppet task run meraki::list_orgs key=apikey123 -n puppet-device-devel.shermdog.local
Starting job ...
New job ID: 8
Nodes: 1

Started on puppet-device-devel.shermdog.local ...
Finished on node puppet-device-devel.shermdog.local
  status : success
  organizations : [{"id":549236,"name":"Meraki DevNet Sandbox"},{"id":646829496481088929,"name":"SD Test"}]

Job completed. 1/1 nodes succeeded.
Duration: 2 sec

vi /etc/puppetlabs/puppet/device.conf

[meraki-devnet-org]
  type meraki_organization
  url file:///root/meraki.yaml

vi /root/meraki.yaml


default{
  node {
    dashboard_org_id = 123456
    dashboard_api_key = apikey789
  }
}

Puppet Device nodes require a signed certificate from the master (just like an Agent). Add some notes here about that.

By default Puppet Device will process all nodes configured in device.conf. Output by default is suppressed, so include -v for interactive runs.

/opt/puppetlabs/puppet/bin/puppet device -v

Individual nodes (organizations) can be specified

/opt/puppetlabs/puppet/bin/puppet device -v --target meraki-devnet-org

Current administrators can be returned interactively as Puppet code

/opt/puppetlabs/puppet/bin/puppet device -v --target meraki-devnet-org --resource meraki_admin

Current administrators can be returned interactively as Puppet code and filtered by email

[[email protected] ~]# /opt/puppetlabs/puppet/bin/puppet device -v --target meraki-devnet-org --resource meraki_admin [email protected]
Info: retrieving resource: meraki_admin from meraki-devnet-org at file:///etc/puppetlabs/code/environments/production/meraki.yaml
meraki_admin { "[email protected]": 
  fullname => 'Rick Sherman',
  ensure => 'present',
# id => '646829496481137785', # Read Only
  orgaccess => 'full',
  networks => [
  {
    'id' => 'L_646829496481099051',
    'access' => 'full'
  },
  {
    'id' => 'L_646829496481095933',
    'access' => 'full'
  },
  {
    'id' => 'N_646829496481143399',
    'access' => 'full'
  }],
  tags => [
  {
    'tag' => 'Sandbox',
    'access' => 'full'
  },
  {
    'tag' => 'branch',
    'access' => 'full'
  }],
}

Usage

This section is where you describe how to customize, configure, and do the fancy stuff with your module here. It’s especially helpful if you include usage examples and code samples for doing things with your module.

Reference

Users need a complete list of your module’s classes, types, defined types providers, facts, and functions, along with the parameters for each. You can provide this list either via Puppet Strings code comments or as a complete list in the README Reference section.

  • If you are using Puppet Strings code comments, this Reference section should include Strings information so that your users know how to access your documentation.
  • If you are not using Puppet Strings, include a list of all of your classes, defined types, and so on, along with their parameters. Each element in this listing should include:
    • The data type, if applicable.
    • A description of what the element does.
    • Valid values, if the data type doesn’t make it obvious.
    • Default value, if any.

Limitations

This is where you list OS compatibility, version compatibility, etc. If there are Known Issues, you might want to include them under their own heading here.

Development

Since your module is awesome, other users will want to play with it. Let them know what the ground rules for contributing are.