
Introducing Boxen - jakebellacera
https://github.com/blog/1345-introducing-boxen
======
JangoSteve
This is pretty cool. There are some other companies that have released similar
tools in the past. I personally tried out:

* Thoughtbot's laptop script - [http://robots.thoughtbot.com/post/8700977975/2011-rubyists-g...](http://robots.thoughtbot.com/post/8700977975/2011-rubyists-guide-to-a-mac-os-x-development)

* Lunar Logic's Lunar Station - <https://github.com/LunarLogicPolska/lunar-station>

* Pivotal Labs's Pivotal Workstation - <https://github.com/pivotal/pivotal_workstation>

I personally liked Pivotal Workstation the best, as it had the best
combination of robustness, pre-built recipes, and easy configurability. I'll
be excited to take a look at Boxen the next time we bring someone into our
team.

~~~
laktek
However, it's still a pain for a small team to keep those recipes up to date
and invest time to tweak configs.

That's why I love a product like Action.io (<http://action.io>), which allows
all dev-boxes to be kept in sync and create clones when needed

(disclaimer: I work with action.io team and it's still in private beta)

~~~
Kudos
Until services like that allow me to code on a plane, I'm not interested.

------
WestCoastJustin
A tool-chain like this is needed for Apple to move widely into the enterprise.
As a sysadmin, it is a _major_ pain to worry about unpatched, outdated, apple
laptops that have to conform to a security policy. Without automated tools
like this, you are left running around patching the latest java/flash/pdf
issue!

~~~
rdl
I still don't understand why Apple hasn't built something like this for the
SMB market. Maybe they don't want to play in the true enterprise space, but
even if a company has 5 workers, having a central cloud service to handle
system configuration, baselines for security, backups, vpn, software push,
hardware replacement, etc. would be essential.

On mobile there are a variety of MDM services so you can almost do this for
phones, but there isn't much for the SMB market for desktops/laptops. In the
Microsoft world there are some tools, but even those are generally too much
work for a small business to set up (even a non-tech business with 100
employees isn't likely to do it, at best they'll have ghost or something to
image new machines -- a tech business might after 25-50 employees)

~~~
homosaur
They don't see themselves in that market...yet, and the trends don't look good
in that direction either. As we all know, Apple has continued to shy away from
actual computing in recent years. Now if you could do something like this for
Linux, businesses that don't yet have an MS infrastructure could find this
very compelling, especially if the rumors of Linux MS Office come true. I work
in IT in a large nationwide law firm and we spend so much time of our days
dealing with viruses and general Windows headaches when what people do is
mostly either 1) through Citrix, where we manage the Windows instances or 2)
on the web. If MS Office for Linux dropped, I think businesses like ours would
find this a very compelling option.

~~~
wes-exp
_"we spend so much time of our days dealing with viruses and general Windows
headaches"_

Rather than maintaining all this enterprise stuff to fight off the Windows
tar-pit of viruses and dreaming of a day of MS Office on Linux, why don't you
switch to Macs which require no such special effort to stay virus-free and
already have MS Office available?

Am I missing something here?

~~~
LunaSea
Because double the price ?

------
fideloper
This sounds awesome!

That being said, there's not a chance in hell I'd install so much stuff onto
my mac.

IMO, Vagrant and VM's in general are what you should use to develop your web
applications. (I happen to be opinionated about this :D )

Mainly this is because I believe in matching your production environment for
development.

It's also because I'm anal about installing memory-using apps into my little
MBA.

However, for things like Minecraft, onepassword, wget, sublime text 2 - this
is really awesome.

~~~
jonknee
You're anal about install memory-using apps onto your MBA so instead of
installing them you run them inside a VM? That uses quite a bit more memory.

Boxen doesn't seem to care too much about what you want to install, so you
could have it install Vagrant and VirtualBox for you.

~~~
encoderer
> That uses quite a bit more memory.

Not really. What it gives you is easily configurable, absolute control over
memory usage. I can ensure that my local dev environment doesn't use more than
2GB of RAM. From one setting. In one place. In about 20 seconds flat.

~~~
stcredzero
_> What it gives you is easily configurable, absolute control over memory
usage._

Perhaps this speaks to OS X's rather wimpy, squishily configurable control
over memory usage.

~~~
encoderer
You think? It's OSX's job to give me a way to say "Don't let the combination
of Mysql, Apache and nginx use more than 1 GB ram" ?

I disagree. That doesn't belong in a consumer OS.

~~~
stcredzero
_> You think? It's OSX's job to give me a way_

Bzzzt! Jumped to conclusions & placed words in my mouth! Thanks for playing.
BTW, I'm an iOS developer and I've been using OS X as almost my exclusive dev
environment since 2003.

Sorry, forgot that I have to keep quiet about shortcomings of OS X, or else.

 _> I disagree. That doesn't belong in a consumer OS._

I applaud your brave stance against the straw man you just conjured. [slow
clap]

~~~
encoderer
Wow. Just wow. Your winning combination of charm, wit and kindness must keep
your social calendar very full.

Enjoy the ride home on the short bus, man.

~~~
stcredzero
_> Enjoy the ride home on the short bus, man._

Also, doesn't admit or apologize when he's shown to be wrong, and responds
with cheap insults instead.

------
one-man-bucket
I'm not trying to flamebait, but are macs so popular that it's just assumed
that all new hires want one as their tool? At my company we're still asking
new employees which platform they want to work on, is this falling out of
fashion?

~~~
jayferd
Seriously. I find Apple's UI to be really frustrating to use. And honestly, I
can't go back after switching to XMonad.

I have many happy coworkers who use Macs, but please don't make me use one.

~~~
steveklabnik
[http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_on_Ap...](http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_on_Apple_OSX)

~~~
emillon
A X11 window manager can only manage X11 apps.

~~~
marchdown
There's nothing keeping you from using the same X11 apps on OS X as you do on
Linux.

------
contingencies
Honest question; I've never understood why people have such a fixation on
puppet-style tools.

Small-scale? Run a simple script. Large-scale? Use a network-hosted
configuration (optimally read-only root and network booting so the entire
system is known-good) to avoid the entire class of configuration drift /
migration / state-accrual problems associated with the above.

I just see puppet as sort of trying to provide the latter and failing,
resulting in a complex version of the former.

~~~
jacques_chester
> _Honest question; I've never understood why people have such a fixation on
> puppet-style tools._

There are two things I want:

1\. To describe the desired correct configuration as a directed, acyclic
graph.

2\. To have some automatic compare-and-repair mechanism regularly bring my
systems to such a state.

If you don't have a good tool for those two requirements, you wind up
reinventing it anyway.

Your small shell scripts start being littered with lots of checks for this and
that file, if-thens and cases. Then they break when script 27 silently gets
out of sync with script 42.

You realise one day that system configurations can be expressed as DAGs
(possibly it's a new insight, perhaps you were reading ITIL documentation).
And you begin to dream about a tool that can take a descriptive DAG and
generate the correct shell scripts. You have now half reinvented puppet.

But the systems _still_ get out of sync. So you start tinkering with a tool
that periodically checks each system and reruns the correct script. Now you
have to ensure that your scripts are all idempotent. All those if-thens and
checks creep back in.

So now you begin to dream about a system that only generates the steps needed
to close the gap between the DAG and the current state of the system.

Congratulations. You just reinvented the other half of puppet.

~~~
contingencies
> 1\. To describe the desired correct configuration as a directed, acyclic
> graph.

If you have already decided on your solution before you have analyzed the
problem then there's nothing to discuss.

> 2\. To have some automatic compare-and-repair mechanism regularly bring my
> systems to such a state.

Right. My fundamental point is that puppet-esque solutions only describe
certain aspects of the system state, ultimately failing here and resulting in
'configuration drift'. Entire system images are far more elegant.

Most of the use cases I have seen for puppet-style stuff are legacy-situation
based and only make sense within that context.

So what is the alternative to puppet-style solutions? Personally I use full
system images on cloud and cluster solutions (corosync/pacemaker) to maintain
server state.

~~~
jacques_chester
> _If you have already decided on your solution before you have analyzed the
> problem then there's nothing to discuss._

You can see how I arrived at that solution.

> _My fundamental point is that puppet-esque solutions only describe certain
> aspects of the system state, ultimately failing here and resulting in
> 'configuration drift'._

Particularly with runtime / process supervision. One of my pet peeves.

> _Entire system images are far more elegant._

Yes and no. It really depends on what your cost/benefit tradeoffs are. I like
system images for startup, but systems still drift from their initial
configuration no matter how that configuration is established (DAG or blob).

Even with system images you'll need to detect divergence from ... what,
exactly? Doing a byte-for-byte comparison is going to suck.

Do you just kill and relaunch periodically? I can see that being
stochastically effective.

~~~
contingencies
> Do you just kill and relaunch periodically? I can see that being
> stochastically effective.

Personally no, but you easily could.

> It really depends on what your cost/benefit tradeoffs are.

Well, realistically, to facilitate automated deployment and testing of multi-
machine systems you _really do need_ to be operating at this level of
abstraction. (ie. to declare your desired state). Once you reach this point, a
configuration file for some version of a package within some node is really a
distraction rather than a help; it should have been abstracted to some known-
good state and taken out of the equation if you are to have any hope of
staying sane. Many people use entire system images coupled with service
monitoring as the de-facto segregation point for management purposes.

> Do you just kill and relaunch periodically? I can see that being
> stochastically effective.

While that's entirely possible and probably a reasonable approach in some
cases, the corosync/pacemaker de-facto/spiritual approach is to detect issues
with a given resource (roughly: 'service instance'), automatically destroy it
and fail over to another instance thereof, and then potentially start another
instance to replace it automatically on the same, or some other cluster node.
To facilitate rapid failover, the master/slave paradigm allows you to have
live backup nodes running and promote them as masters easily. Any type of
hardware or software can be scripted as a managed resource. The type and
frequency of resource health monitoring checks can be custom defined.

~~~
mnutt
I still don't quite understand how you manage version control with entire
system images. I guess you could just write a changelog, but that requires a
large amount of self-discipline to ensure that the changelog exactly matches
system state. Let's say you discover some minor instability, and discover that
it was introduced 8 months ago, but the changelog for that image was
completely innocuous. Can you do anything other than throw out all 8 months'
worth of images and try to work your way back to present via the changelogs?

Puppet-like systems have the same issue in that they don't attempt to specify
the entire system, but at least with puppet if there is an issue due to system
drift you can start with a clean base installation and re-run it.

~~~
contingencies
_I still don't quite understand how you manage version control with entire
system images._

You just uniquely name the environment, for example with a version number,
and/or use a snapshot-capable datastore.

 _I guess you could just write a changelog, but that requires a large amount
of self-discipline to ensure that the changelog exactly matches system state._

Definitely don't do this.

 _Let's say you discover some minor instability, and discover that it was
introduced 8 months ago, but the changelog for that image was completely
innocuous. Can you do anything other than throw out all 8 months' worth of
images and try to work your way back to present via the changelogs?_

If you write a test that can trigger the issue and replay the test against
past images ("regression test") then you will identify exactly where the issue
was introduced. The key thing is: don't have manually configured what-not in
production. Keep it versioned, keep it solid, keep it known.

 _Puppet-like systems have the same issue..._

Exactly. This is my point. They don't really deliver on the promise of decent
automation, because they are inherently patchwork/partial-scope in approach.

------
benatkin
Clever name. <http://www.jargon.net/jargonfile/b/boxen.html>

~~~
bcgraham
I thought it was a reference to Brian Regan Live, 1997:
<http://www.youtube.com/watch?v=yxenUzZPFiQ#t=01m56s>

------
jbarnette
We've opened up #boxen on freenode for questions and discussion. We'll idle
there whenever we can.

------
buf
Looks very similar to Vagrant: <http://www.vagrantup.com/>

~~~
jimray
That was my first thought as well. And then I started wondering why they are
automating so much setup on OS X itself instead of using something like
Vagrant for dev stuff.

I find OS X to be pretty frustrating to work with natively. I've long tried to
keep things like Postgres and Python consistent, but even a 10.x.y update can
break things. Even with homebrew and postgresapp, it's challenging to keep the
system from breaking. I'm currently running 10.7 precisely because I didn't
want to rebuild my setup on 10.8 (I've since started using Vagrant much more
aggressively to help solve this).

I realize that part of the point of boxen is to help set a baseline but it
seems like a Vagrant box that mimics the actual Github stack would make more
sense.

~~~
cwb71
This surprised me too, I would not have expected that Githubbers develop on OS
X and deploy to Linux.

I would be interested to hear more about why they made that choice.

~~~
technoweenie
Not everything we work on deploys to Linux.

~~~
cwb71
Understood, but the original blog post begins “Boxen started nearly a year ago
as a project called “The Setup” — a pipe dream to let anyone at GitHub run
GitHub.com on their development machine with a single command.”

It was this line specifically which implied that Boxen is used to emulate the
production environment in OS X and spurred my comment.

------
account_taken
Isn't puppet overkill for this? Seems like a bunch of ruby to build command
line arguments. Bash would have been easier. We have a workstation dotfiles
which we clone and execute an install script with plugins for oh-my-zsh.

~~~
jeremymcanally
To set up initially, possibly. But this is for maintenance too. Need to
install a security patch? Puppet. Need to upgrade versions? Puppet. Want to
tweak some setting somewhere? Puppet. Using Puppet makes it stupid easy for us
to keep our setups (a) in sync, (b) up to date and secure, and (c) do it
without a bunch of hacky scripts that will probably break or not work right in
3 months.

~~~
account_taken
I'm not seeing it how installing a security patch is any different. Security
patches usually check to see if they need to be applied before doing anything.
Updating a version is as simple as `brew update node`, `brew updated mongodb`,
etc. The bash you call hacky is what's being done here with an extra layer of
Ruby.

~~~
jeremymcanally
Cool, well have fun next time you need to update a setting buried in a config
file or verify the results of something you ran. You can write 200 lines of
bash that might work (or might not if the user decides they like csh or zsh)
or like 3 lines of Puppet and guarantee it's idempotent.

There's a lot more to this than just setup scripts, but if all you need is
setup scripts with the occasional update, then by all means just stick with
that. Our needs just happen to be beyond that.

------
stcredzero
Does it work well with Homebrew, or does it subsume that functionality?

~~~
jyunderwood
It's kind of like initializing a fresh OS install to something useable.

Their our-boxen template[1] installs homebrew for you as well as some other
software.

[1]<https://github.com/boxen/our-boxen>

~~~
shurane
How does this work for proprietary software, or stuff that requires
installation keys or authorization? Say Office 2011 or sublime text 2 or some
other paid app (whether in the app store or not)?

------
kzrdude
"brutalize a key with your favorite finger"

------
zx2c4
Massive ruby framework that only runs on macs? Yuck.

------
Hovertruck
This looks pretty great. We do something slightly similar at Chartbeat, but
using puppet + ubuntu server VMs on our macs. Enables us to to develop on the
same hardware we'll be using in production. Our CTO wrote a blog post about it
here if anyone is interested:

<http://engineering.chartbeat.com/2012/09/24/devvm/>

------
shykes
This reminds me of radmind: <http://rsug.itd.umich.edu/software/radmind/>

Lots of good ideas in there (some of which inspired early work on dotCloud,
including <https://github.com/dotcloud/cloudlets> )

------
DannoHung
I just can't keep track of SCM systems any more...

Calgon, take me away.

------
jxf
This looks very nice -- automated workflow setup for developers. It's
essentially generalization across every "developer setup guide" you could
possibly imagine.

Now the question is: can we get this for Linux users?

~~~
WestCoastJustin
Puppet/systemimager already exists for Linux users.

~~~
jxf
Boxen works with puppet too, but they don't fulfill the same role. Boxen is
about the sharing and centralization of your puppet-like tools. Presumably not
everyone wants to write a developer workflow from scratch, and Boxen could
solve that without requiring a Mac, right?

~~~
WestCoastJustin
Exactly -- no one wants to start from scratch. Puppet maintains something
called, Puppet Forge [1] where anyone can uploads and share their puppet
recipes. This goes beyond Puppet Forge, since it is a bundle of scripts that
work together, so there is much added value to something like boxen.

[1] <http://forge.puppetlabs.com/>

------
kellysutton
This is awesome and a long-time coming. If you're setting up a developer box,
the last step should deploy to production :)

------
seryl
I had built something very similar to this a while ago, based off of the
pivotal idea but with a one-liner install.

<https://github.com/seryl/kindness>

supports updating itself and it's templates form the git repo it's
referencing.

------
lox
We use babushka for local machine config and also production. It's radically
simpler than Puppet/Chef.

<http://babushka.me/>

------
kriro
This might be enough for me to settle on Puppet over Chef. Haven't really
compared them in depth and only played around with Chef so far.

Either way it seems pretty cool.

------
deepflame
Would be interesting to know what made them settle on Puppet instead of Chef.
Thought the guys at Github were big Ruby-Lovers...

------
jacques_chester
"Boxen" is the German word for "Boxing".

I learnt this when I considered starting a linux-optimised PC business back in
the early noughties.

~~~
jurre
Also in Dutch :)

------
lightyrs
This looks very promising. Thanks, GitHub!

------
banachtarski
I can't bring myself to trust a project that has such horrible commit
messages, even if it is github.

------
geetarista
Heard about this a while back from a beta user. Very excited to start playing
with it!

------
init0
\--> You must be running OS X 10.8 (Mountain Lion). :(

------
chris092
This looks very promising.

------
glamsmash689
cool.

