Skip to content

Instantly share code, notes, and snippets.

View charlesjohnson's full-sized avatar

Charles Johnson charlesjohnson

View GitHub Profile
@smford22
smford22 / chef_local_development_workflow.md
Last active November 1, 2023 00:07
Chef Local Development Workflow - ChefDK, Vagrant, VirtualBox, Test Kitchen

Chef Local Development Workflow with ChefDK, Vagrant, VirtualBox, and Test Kitchen

Overview

The following document is intended to be a quick guide to getting you setup for doing local development with Chef. This guide was created on my MacBook, but should work fine with Linux, and Windows workstations as well.

Quick review on fundamental tenets of Chef

  • Workstation - A workstation is a computer that is configured to run various Chef command-line tools that synchronize with a chef-repo, author cookbooks, interact with the Chef server, interact with nodes, or applications like Chef Delivery
  • Node - A node is any machine—physical, virtual, cloud, network device, etc.—that is under management by Chef.
  • Chef Server- The Chef server acts as a hub for configuration data. The Chef server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered
@vinyar
vinyar / Cookbook dependency reverse lookup.rb
Last active September 5, 2015 21:31
cookbook reverse dependency lookup
Its a cookbook class that we use to abstract cookbooks and their
dependencies. The key method to look at is dependency_hash which creates
a hash based on the dependencies of the cookbook.
We do not explicitly do a reverse dependency lookup but we can use this
hash to infer a change in dependencies from a change in any cookbook in
an environment. So the flow is:
1. I change cookbook A and it gets sent to the chef server and indexed
in berks.

A Quick Tour of A Chef Client Run Internals

Dan DeLeo appeared on the FoodFightShow some time ago to walk through "what a Chef run really does". I expanded on these remarks in my personal investigation.

/usr/bin/chef-client

  • bin/chef-client creates a new Chef::Application::Client (subclass of Chef::Application which sets up common things like loggers across chef-client, chef-solo, knife, etc.) then jump to:

  • lib/chef/client.rb

  • application classes create a new Chef::Client object, which calls initialize().

@logikal
logikal / get_chef_env.rb
Last active December 12, 2015 23:29
Get your Chef environment back to a pretty-printed hash. e.g. for use with vagrant.
require 'JSON'
require 'Chef'
require 'pp'
# Probably a better way to shell out, this was quick
# Interestingly, this gets typed out as a Chef::Environment, so you have to require 'Chef'
environment = JSON.parse(`knife environment show environmentname -Fj`)
# Pretty print your environment's hash.
# Suitable for use with vagrant!
@millisami
millisami / gist:3798773
Created September 28, 2012 09:04 — forked from juanje/gist:3797297
Mount apt cache of a Vagrant box in the host to spin up the packages installation

This is a little trick I use to spin up the packages instalation on Debian/Ubuntu boxes in Vagrant.

I add a simple function that checks if a directory named something similar to ~/.vagrant.d/cache/apt/opscode-ubuntu-12.04/partial (it may have another path in Windows or MacOS) and create the directory if it doesn't already exist.

def local_cache(box_name)
  cache_dir = File.join(File.expand_path(Vagrant::Environment::DEFAULT_HOME),
                        'cache',
                        'apt',
                        box_name)
@piscisaureus
piscisaureus / pr.md
Created August 13, 2012 16:12
Checkout github pull requests locally

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,

@nukemberg
nukemberg / knife.sh
Created June 28, 2011 07:51 — forked from ches/knife
bash completion for Chef's knife command (updated for 0.10)
# vim: ft=sh:ts=4:sw=4:autoindent:expandtab:
# Author: Avishai Ish-Shalom <avishai@fewbytes.com>
# We need to specify GNU sed for OS X, BSDs, etc.
if [[ "$(uname -s)" == "Darwin" ]]; then
SED=gsed
else
SED=sed
fi