Blame view
README.md
10.5 KB
3a47d364c Remove caches for... |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 |
# Our Boxen This is a template Boxen project designed for your organization to fork and modify appropriately. The Boxen rubygem and the Boxen puppet modules are only a framework for getting things done. This repository template is just a basic example of _how_ to do things with them. ## Getting Started To give you a brief overview, we're going to: * Install dependencies (basically Xcode) * Bootstrap a boxen for your self/team/org/company * Then convert your local copy of that boxen to the post-bootstrapped version There are a few potential conflicts to keep in mind. Boxen does its best not to get in the way of a dirty system, but you should check into the following before attempting to install your boxen on any machine (we do some checks before every Boxen run to try and detect most of these and tell you anyway): * Boxen __requires__ at least the Xcode Command Line Tools installed. * Boxen __will not__ work with an existing rvm install. * Boxen __may not__ play nice with a GitHub username that includes dash(-) * Boxen __may not__ play nice with an existing rbenv install. * Boxen __may not__ play nice with an existing chruby install. * Boxen __may not__ play nice with an existing homebrew install. * Boxen __may not__ play nice with an existing nvm install. * Boxen __recommends__ installing the full Xcode. ### Dependencies **Install the Xcode Command Lines Tools and/or full Xcode.** This will grant you the most predictable behavior in building apps like MacVim. How do you do it? #### OS X 10.9 (Mavericks) If you are using [`b26abd0` of boxen-web](https://github.com/boxen/boxen-web/commit/b26abd0d681129eba0b5f46ed43110d873d8fdc2) or newer, it will be automatically installed as part of Boxen. Otherwise, follow instructions below. #### OS X < 10.9 1. Install Xcode from the Mac App Store. 1. Open Xcode. 1. Open the Preferences window (`Cmd-,`). 1. Go to the Downloads tab. 1. Install the Command Line Tools. ### Bootstrapping Create a **new** git repository somewhere on the internet. It can be private or public -- it really doesn't matter. If you're making a repository on GitHub, you _may not_ want to fork this repo to get started. The reason for that is that you can't really make private forks of public repositories easily. Once you've done that, you can run the following to bootstrap your boxen: ``` sudo mkdir -p /opt/boxen sudo chown ${USER}:staff /opt/boxen git clone https://github.com/boxen/our-boxen /opt/boxen/repo cd /opt/boxen/repo git remote rm origin git remote add origin <the location of my new git repository> git push -u origin master ``` Now that your boxen is bootstrapped, you can run the following to install the default configuration from this repo: ``` cd /opt/boxen/repo ./script/boxen ``` ### Distributing That's enough to get your boxen into a usable state on other machines, usually. From there, we recommend setting up [boxen-web](https://github.com/boxen/boxen-web) as an easy way to automate letting other folks install your boxen. If you _don't_ want to use boxen-web, folks can get using your boxen like so: ``` sudo mkdir -p /opt/boxen sudo chown ${USER}:staff /opt/boxen git clone <location of my new git repository> /opt/boxen/repo cd /opt/boxen/repo ./script/boxen ``` Keep in mind this requires you to encrypt your hard drive by default. If you do not want to do encrypt your hard drive, you can use the `--no-fde`. ``` ./script/boxen --no-fde ``` It should run successfully, and should tell you to source a shell script in your environment. For users without a bash or zsh config or a `~/.profile` file, Boxen will create a shim for you that will work correctly. If you do have a `~/.bashrc` or `~/.zshrc`, your shell will not use `~/.profile` so you'll need to add a line like so at _the end of your config_: ``` sh [ -f /opt/boxen/env.sh ] && source /opt/boxen/env.sh ``` Once your shell is ready, open a new tab/window in your Terminal and you should be able to successfully run `boxen --env`. If that runs cleanly, you're in good shape. ## What You Get This template project provides the following by default: * Homebrew * Git * Hub * dnsmasq w/ .dev resolver for localhost * rbenv * Full Disk Encryption requirement * Node.js 0.6 * Node.js 0.8 * Node.js 0.10 * Ruby 1.9.3 * Ruby 2.0.0 * Ruby 2.1.0 * Ruby 2.1.1 * ack * Findutils * GNU tar ## Customizing You can always check out the number of existing modules we already provide as optional installs under the [boxen organization](https://github.com/boxen). These modules are all tested to be compatible with Boxen. Use the `Puppetfile` to pull them in dependencies automatically whenever `boxen` is run. ### Including boxen modules from github (boxen/puppet-<name>) You must add the github information for your added Puppet module into your Puppetfile at the root of your boxen repo (ex. /path/to/your-boxen/Puppetfile): # Core modules for a basic development environment. You can replace # some/most of these if you want, but it's not recommended. github "repository", "2.0.2" github "dnsmasq", "1.0.0" github "gcc", "1.0.0" github "git", "1.2.2" github "homebrew", "1.1.2" github "hub", "1.0.0" github "inifile", "0.9.0", :repo => "cprice404/puppetlabs-inifile" github "nginx", "1.4.0" github "nodejs", "2.2.0" github "ruby", "4.1.0" github "stdlib", "4.0.2", :repo => "puppetlabs/puppetlabs-stdlib" github "sudo", "1.0.0" # Optional/custom modules. There are tons available at # https://github.com/boxen. github "java", "1.1.0" In the above snippet of a customized Puppetfile, the bottom line includes the Java module from Github using the tag "1.1.0" from the github repository "boxen/puppet-java". The function "github" is defined at the top of the Puppetfile and takes the name of the module, the version, and optional repo location: def github(name, version, options = nil) options ||= {} options[:repo] ||= "boxen/puppet-#{name}" mod name, version, :github_tarball => options[:repo] end Now Puppet knows where to download the module from when you include it in your site.pp or mypersonal.pp file: # include the java module referenced in my Puppetfile with the line # github "java", "1.1.0" include java ### Hiera Hiera is preferred mechanism to make changes to module defaults (e.g. default global ruby version, service ports, etc). This repository supplies a starting point for your Hiera configuration at `config/hiera.yml`, and an example data file at `hiera/common.yaml`. See those files for more details. The default `config/hiera.yml` is configured with a hierarchy that allows individuals to have their own hiera data file in `hiera/users/{github_login}.yaml` which augments and overrides site-wide values in `hiera/common.yaml`. This default is, as with most of the configuration in the example repo, a great starting point for many organisations, but is totally up to you. You might want to, for example, have a set of values that can't be overridden by adding a file to the top of the hierarchy, or to have values set on specific OS versions: ```yaml # ... :hierarchy: - "global-overrides.yaml" - "users/%{::github_login}" - "osx-%{::macosx_productversion_major}" - common ``` ### Node definitions Puppet has the concept of a ['node'](http://docs.puppetlabs.com/references/glossary.html#agent), which is essentially the machine on which Puppet is running. Puppet looks for [node definitions](http://docs.puppetlabs.com/learning/agent_master_basic.html#node-definitions) in the `manifests/site.pp` file in the Boxen repo. You'll see a default node declaration that looks like the following: ``` puppet node default { # core modules, needed for most things include dnsmasq # more... } ``` ### How Boxen interacts with Puppet Boxen runs everything declared in `manifests/site.pp` by default. But just like any other source code, throwing all your work into one massive file is going to be difficult to work with. Instead, we recommend you use modules in the `Puppetfile` when you can and make new modules in the `modules/` directory when you can't. Then add `include $modulename` for each new module in `manifests/site.pp` to include them. One pattern that's very common is to create a module for your organization (e.g., `modules/github`) and put an environment class in that module to include all of the modules your organization wants to install for everyone by default. An example of this might look like so: ``` puppet # modules/github/manifests/environment.pp class github::environment { include github::apps::mac include ruby::1-8-7 include projects::super-top-secret-project } ``` If you'd like to read more about how Puppet works, we recommend checking out [the official documentation](http://docs.puppetlabs.com/) for: * [Modules](http://docs.puppetlabs.com/learning/modules1.html#modules) * [Classes](http://docs.puppetlabs.com/learning/modules1.html#classes) * [Defined Types](http://docs.puppetlabs.com/learning/definedtypes.html) * [Facts](http://docs.puppetlabs.com/guides/custom_facts.html) ### Creating a personal module See [the documentation in the `modules/people`](modules/people/README.md) directory for creating per-user modules that don't need to be applied globally to everyone. ### Creating a project module See [the documentation in the `modules/projects`](modules/projects/README.md) directory for creating organization projects (i.e., repositories that people will be working in). ## Binary packages We support binary packaging for everything in Homebrew, rbenv, and nvm. See `config/boxen.rb` for the environment variables to define. ## Sharing Boxen Modules If you've got a Boxen module you'd like to be grouped under the Boxen org, (so it can easily be found by others), please file an issue on this repository with a link to your module. We'll review the code briefly, and if things look pretty all right, we'll fork it under the Boxen org and give you read+write access to our fork. You'll still be the maintainer, you'll still own the issues and PRs. It'll just be listed under the boxen org so folks can find it more easily. ##upgrading boxen See [FAQ-Upgrading](https://github.com/boxen/our-boxen/blob/master/docs/faq.md#q-how-do-you-upgrade-your-boxen-from-the-public-our-boxen). ## Integrating with Github Enterprise If you're using a Github Enterprise instance rather than github.com, you will need to set the `BOXEN_GITHUB_ENTERPRISE_URL` and `BOXEN_REPO_URL_TEMPLATE` variables in your [Boxen config](config/boxen.rb). ## Halp! See [FAQ](https://github.com/boxen/our-boxen/blob/master/docs/faq.md). Use Issues or #boxen on irc.freenode.net. |