2013-08-27 Chef-Boston Meetup - Using Berkshelf
Upcoming SlideShare
Loading in...5
×
 

2013-08-27 Chef-Boston Meetup - Using Berkshelf

on

  • 749 views

This was a brief presentation at the Boston Chef Meetup on Fiksu's use of Berkshelf.

This was a brief presentation at the Boston Chef Meetup on Fiksu's use of Berkshelf.

Statistics

Views

Total Views
749
Slideshare-icon Views on SlideShare
740
Embed Views
9

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 9

https://twitter.com 9

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    2013-08-27 Chef-Boston Meetup - Using Berkshelf 2013-08-27 Chef-Boston Meetup - Using Berkshelf Presentation Transcript

    • Using Berkshelf Evolution in Cookbook Development at Fiksu.
    • What is Berkshelf? ● A Cookbook authoring productivity tool by Jamie Windsor and the Riot Games crew. ● Replaces some functions of knife (cookbook download / upload / create) ● A package manager of sorts (think bundler for cookbooks)
    • Why Berkshelf? ● Simplifies collaborative development. ● Promotes wrapping and extending public cookbooks. ● Greatly simplifies cookbook and dependency upload process. ● Seamless vagrant integration. (via plugin)
    • “The Berkshelf Way” 1. Work in verticals from the outside in: ● Start with the application cookbook and work down through the dependencies. 2. Favor Data-driven Cookbooks: ● Cookbook attributes preferred; tune on an environment level. 3. Write well-encapsulated Cookbooks: ● Stop using Roles. They aren’t immutably versioned and add additional setup and complexity for users. Cookbooks should be self-contained. 4. Have short iteration loops: ● Use vagrant with berkshelf plugin to greatly reduce iteration cycle time.
    • Berksfile ● Think Gemfile; tells Berkshelf where it should look for dependent cookbooks: ○ cookbook “nginx”, chef_api :config (Your chef server) ○ cookbook “nginx”, site :opscode (Opscode Public Cookbooks) ○ cookbook “nginx”, git: 'git://github.com/opscode-cookbooks/nginx.git' ○ cookbook “nginx”, path: '/Users/bob/cookbooks/nginx' ● You can tell Berkshelf to use your metadata file: ○ metadata
    • Fiksu specifics ● Application, Wrapper, Utility Cookbooks ○ All explicitly namespaced. ● Cookbook metadata is the source of truth ○ depends statements in metadata.rb constrain versions, not Berksfile. ● Chef Environments ○ Use of metadata makes production constraints much simpler. ○ Staging is unconstrained ■ Promotes faster iteration cycle ■ Reduces Ops overhead/bottleneck ● Roles ○ For now, a placeholder that binds our base role with an app cookbook.
    • Fiksu’s Berksfile # Check our hosted chef server first. Looks for the chef configuration # info in ~/.berkshelf/config.json. If not there, run 'berks configure'. chef_api :config # Now look at the community cookbooks. site :opscode # Finally, reference the metadata file in the cookbook. metadata
    • metadata.rb maintainer "Fiksu Inc." maintainer_email "xxxxxxx@fiksu.com" license "All rights reserved" description "Installs/Configures Fiksu’s awesome app!" long_description IO.read(File.join(File.dirname(__FILE__), 'README.md')) name “fiksu_awesome_app” version “1.0.0” depends "fiksu_nginx", "1.1.4" depends "fiksu_redis", "1.2.3" depends "monit", "0.0.15"
    • The Past ● All chef artifacts (cookbooks, roles, envs, etc.) in one giant chef-repo. ● Adding or extending public cookbooks was painful and sloppy… git submodules were less than ideal. ● A very role-centric environment; tough to easily see the “big picture” while working on a single cookbook. ● No use of Vagrant for testing. Everything was uploaded to Hosted Chef and tested in EC2… cookbook testing in isolation was impossible.
    • The Present ● One cookbook per repo. ● All Application Cookbooks use Berkshelf and Vagrant for much faster iteration cycles. ● CI: Use TravisCI for linting (foodcritic) and syntax checks (knife cookbook check). ● Little to no test coverage with chefspec/fauxhai or minitest-handler. ● Still using roles.
    • The Future ● Well defined cookbook development workflow process that empowers both dev and ops as productive cookbook authors. ● Matured CI workflow (automated cookbook uploads to chef-server, etc.). ● Embrace TDD in cookbook authoring is a must. ● Roles days numbered?
    • Some references: http://berkshelf.com/ http://www.opscode.com/blog/chefconf-talks/the-berkshelf- way-jamie-winsor/ http://alluvium.com/blog/2013/05/03/the-application- cookbook-pattern-berkshelf-and-team-chef-workflow/ http://realityforge.org/code/2012/11/19/role-cookbooks-and- wrapper-cookbooks.html