Introducing Boxen

https://github.com/blog/1345-introducing-boxen

by jakebellacera • 13 years ago

470 122 13 years ago

github.com

lightyrs• 13 years ago

This looks very promising. Thanks, GitHub!

stcredzero5• 13 years ago

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

jyunderwood• 13 years ago

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• 13 years ago

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)?

colechristensen• 13 years ago

You can use Boxen to install Homebrew and then (with puppet modules which you may have to install yourself) you can use Boxen to manage/install Homebrew packages.

stcredzero5• 13 years ago

That's very cool! Exactly what I wanted to know.

jxf2• 13 years ago

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?

WestCoastJustin5• 13 years ago

Puppet/systemimager already exists for Linux users.

jxf2• 13 years ago

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?

benatkin2• 13 years ago

Clever name. http://www.jargon.net/jargonfile/b/boxen.html

bcgraham• 13 years ago

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

geetarista• 13 years ago

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

Hovertruck• 13 years ago

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/

WestCoastJustin5• 13 years ago

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!

ajasmin• 13 years ago

Are sysadmins really the target audience? At first glance it seems the intent of Boxen is to get your developer tools installed and configured.

I guess how useful it is for a sysadmin would depend on whether changes are pushed automatically to the macs.

WestCoastJustin5• 13 years ago

Ultimately someone is responsible for that machine, I think that role should fall with the sysadmins, if they exist yet.

Github is large enough that they should have in-house IT looking after the desktops/internal network. They might even have two teams, one looking after employees, and one looking after the server infrastructure.

Start-ups grow organically, so there might not be "someone" at first, other than the developer. This quickly turns into a burden when you have 50+ employees running around and warranties start to lapse, there is no current inventory list, you have a mish-mash of machine configs. Then comes the stage of getting a consistent config on each machine, so that person X and person Y can collaborate, using the same dev tools, at the same rev level. Looks like Puppet/Boxen is a tool to solve that problem.

This problem is compounded when you are in a hiring frenzy, because new people almost appear out of thin air, and you are supposed to have a machine for them. Having a quick deploy script will save your hair line considerably.

MiguelHudnandez• 13 years ago

Exactly. I have been fighting to allow people to choose Mac or PC when they are due for new hardware, and now that 80% of people are choosing Macs, it is getting to be a pain to manage them.

I am so glad to see this as an alternative to the tools that Apple has been neglecting since they stopped trying to sell server hardware.

rdl4• 13 years ago

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)

homosaur6• 13 years ago

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.

pclark• 13 years ago

Apple Remote Desktop does almost everything you're describing.

muraiki• 13 years ago

For enterprise Mac management I've found the Casper Suite to be awesome: http://www.jamfsoftware.com/ (no affiliation)

It can easily create thin images for setting up new machines (make a small base install and then give the computer applications X Y and Z), package software and remotely deploy it to computers, create rules to push out new versions of software to computers, etc. You can set up self service so that users can browse a general store of applications but you can also assign applications to specific computers. They handle iOS devices now too, and their community is great. It also has SCCM and Altiris plugins, but I haven't used either of those features.

buf• 13 years ago

Looks very similar to Vagrant: http://www.vagrantup.com/

dljsjr• 13 years ago

Except Vagrant is used to spin up small virtual development environments whereas it looks like this is used to actually spin up a physical machine.

davidradcliffe• 13 years ago

Vagrant spins up the VM but then hands off to a provider (chef, puppet, etc.) for configuration.

Aqua_Geek• 13 years ago

Looks more like Pivotal Workstation: https://github.com/pivotal/pivotal_workstation

stock_toaster• 13 years ago

Unrelated, but I am excited by pending vmware fushion support: vimeo.com/58059557

jimray• 13 years ago

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.

cwb712• 13 years ago

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.

kzrdude• 13 years ago

"brutalize a key with your favorite finger"

shykes• 13 years ago

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 )

jbarnette2• 13 years ago

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

JangoSteve• 13 years ago

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...

* 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• 13 years ago

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• 13 years ago

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

mirsadm• 13 years ago

That was REALLY obvious advertisment of your startup :P

1qaz2wsx3edc• 13 years ago

In our projects' README.md we have a section for installation. It's about 7-12 of terminal commands. It takes us less then an hour to get someone setup. I guess what I'm trying to say is that it's easy enough at small-scale. We also get some good knowledge transfer out of this process. I'm put off by the whole "let's throw puppet at it", but github is not small-scale.

DannoHung• 13 years ago

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

Calgon, take me away.

account_taken3• 13 years ago

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.

WestCoastJustin5• 13 years ago

Puppet not only allows you to deploy changes but makes sure they stay. There is something called Puppet Dashboard, that allows you to see all the installed clients, who has a valid config, who is outside that config. This allows you to quickly see machines that need attention. There are some better screenshots here [2].

[1] https://puppetlabs.com/puppet/related-projects/dashboard/

[2] http://bitcube.co.uk/content/puppet-dashboard-six-months

account_taken3• 13 years ago

I understand the benefits of puppet, ansible, etc for provisioning on a massive scale.

jbarnette2• 13 years ago

Drift after installation and incremental updates were more of a problem for us than initial installs.

jeremymcanally2• 13 years ago

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_taken3• 13 years ago

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.

philfreo• 13 years ago

It's easy to install something originally from state X to state Y with bash, but Puppet makes it easy to continue ongoing because it's a declarative syntax.

patcon2• 13 years ago

Might seem like overkill, but Chef/Puppet are designed to be idempotent, which is exactly what you want when you're running configuration scripts that are expected to evolve and update, and hence must be run over and over without reformatting the workstation.

Disclosure: I'm a big pivotal_workstation and Chef fan, but excited to see what new angles boxen demonstrates :)

fideloper• 13 years ago

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.

patcon2• 13 years ago

I share your opinion on vagrant, but it still stands that there are lots of tools you use on your host machine that you might want to make simple to share and configure organizationally. Look into how pivotal labs (consultancy) works and its a little mind-blowing and inspiring -- they all share the same configs and many of the same defaults and dotfiles and shortcuts (which they decide through deliberation and consensus), they reformat their macbooks from scratch between each project (for infosec), and they all know how to write chef recipes, so if they customize their system in a way that they want back after they wipe, then they write a recipe for it and share it back via pivotal_workstation :)

It's pretty cool. And even if not everyone can put the time into building that sort of solution from scratch, pretty much everyone can ride their coattails

jonknee• 13 years ago

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.

encoderer3• 13 years ago

> 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.

jim-greer• 13 years ago

I don't care much about the memory, but having my dev machine match production is great.

ebiester• 13 years ago

How do you develop on multiple monitors with your VMs? That's always kept me back.

atlbeer• 13 years ago

Vagrant is basically a headless box running on a local directory.

On vagrant you have your production tool chain open in terminal (via ssh) where you can run a dev version of what you are building by forwarding ports to local host

You then can run browsers, IDE consoles across as many monitors as you want

*obviously web dev centric

kellysutton• 13 years ago

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

one-man-bucket2• 13 years ago

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?

jneen• 13 years ago

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.

steveklabnik2• 13 years ago

http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_on_Ap...

zobzu• 13 years ago

Likewise. In fact, I like the Windows (7) UI better. I'm a full time desktop Linux user, but that's not for the desktop. I'd be happy with Windows as UI on top for "desktop stuff".

Note: I've been using macs daily, for hours from OS 6 to OSX 10.3, before I started using Windows and Linux more.

rdl4• 13 years ago

Everyone technical I see in silicon valley, with maybe 5 exceptions, is on Mac laptops. A fair number of serious devs have Linux workstations to go along with their Mac laptops.

People who do some other stuff (heavy email users, some video/audio people) do sometimes use Windows (it's weird, but I think the Windows audio stuff is better for realtime now than Mac).

(the exceptions are people with FreeBSD, NetBSD, and Linux laptops)

I'd be pretty comfortable as a Silicon Valley employer only supporting Macs for office automation, and then either Mac or Linux for development workstations. If someone really wants Windows, s/he can support it independently.

The harder problem is phones -- there are people who are religiously attached to iOS and to Android, and you basically need to support both. There are pretty good MDM tools to cover both at the same time, but it does mean you can't push enterprise apps unless you do crossplatform development.

one-man-bucket2• 13 years ago

At my company, small cms company bought a few years ago by older larger media company, recruiting in Stockholm, we're offering new employees a Mac or Linux laptop, but there is a lot of hinting that "you'd probably be best off picking a Mac", and a few new hires have opted for the latter because of reasons that to me sound like they think it's the "company DNA" or something.

I'm not religious about platform choice, but I'd hate to see a future where developers are pidgeonholed with regards to their tools

Edit: currently 13 of 15 of our devs use Mac

cobychapple• 13 years ago

We don't assume anything. New employees here at GitHub can choose whichever platform they prefer—it just so happens that most people here go for Macs of their own accord :)

bti• 13 years ago

Out of curiosity, how many developers do you have who primarily use a Windows machine?

homosaur6• 13 years ago

It's not really about Macs per se, it's about the Unix toolchain and unlike Linux, Macs have Photoshop, etc.

DeepDuh3• 13 years ago

I think you hit the spot. The reason why so many devs go for mac nowadays, is to have a good laptop that you don't have to babysit / configure much yourself and that's well integrated with a unix toolchain. On a desktop, many of these advantages go away when you compare to a linux workstation, therefore many go for that.

chacham15• 13 years ago

My main gripe with Macs supposed 'toolchain' is that clones are nowhere comparable to 'apt-get'.

seldo• 13 years ago

We offer new employees Apple hardware, on which they are free to use OSX or Linux. Apple hardware is the best hardware out there, so that's a no-brainer. We avoid Windows for security and compatibility reasons.

throwaway1• 13 years ago

Yes, sadly. At my interview they said I could have a Linux machine, and I believed them. I got a freaking Mac. It's assumed that everybody secretly yearns for a Macintosh.

zx2c4• 13 years ago

Massive ruby framework that only runs on macs? Yuck.

seryl• 13 years ago

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.

contingencies7• 13 years ago

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.

dschep• 13 years ago

How do you propose implementing a netbooted infrastructure with laptops?

contingencies7• 13 years ago

If they are always on the network, it's trivial, you just boot from the network as with any other machine.

If they are often on the network, you can use occasional rsync, for example to the system partition either at boot or in the background. That way, boot is possible even if disconnected.

If they're not often on the network, and you are seriously considering doing this at all, I would reconsider which problem you are trying to solve.

Also: I don't know about anyone else here, but I would prefer not having a company manage my laptop. The use cases for such a scenario, in my view, are pretty hard to imagine.

mpdehaan22• 13 years ago

This kind of feeling is a large reason why I created http://ansible.cc/

The feeling that I want to write something quick or easy shouldn't depend on the size of my infrastructure, it should be easy either way -- 500 servers, 50, 1, doesn't matter.

That being said, our modules do need some patch-love for things like launchd and OS X groups, we've been a lot more Linux/Unix focused to date. (Patches are welcome of course!)

contingencies7• 13 years ago

Thanks for your reply Michael. I had a look at Ansible and your personal website and you definitely have been doing work with a fair bunch of serious systems in this space, so I really value your perspective. However, looking at the ansible news and documentation - "playbooks, configuration management, deployment, and orchestration" - I really couldn't see how it differs significantly in paradigm to puppet. Is it just the ability to converge on some defined configuration automatically? It's unclear to me. Would you be so kind as to summarise the differences in brief? Thanks.

jacques_chester4• 13 years ago

> 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.

contingencies7• 13 years ago

> 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.

parasubvert• 13 years ago

Network hosted configurations are the scourge of most admin's existence due to the emphasis it places on network reliability and performance along with a SPOF for the network storage.

The other aspect is that many admins are ally do not like the bad habits associated with an image-level of abstraction, which leads to many hidden dependencies and configurations settings. Aa package-level manifest like Puppet, Chef, or Ansible enables much more of a complete explicit specification of the environment along with cross-machine dependencies. Such a description also allows easier reassembly of subsets of the system into different combinations.

The trend towards image-level abstractions does work for many as an alternative: Netflix for example avoids Puppet and just reassembles AMI images on each deploy, with auto discovery of cross machine dependencies at runtime via (eg) Zookeeper or other cluster facilities. But they have the discipline not to get into an image sprawl situation.

jacques_chester4• 13 years ago

"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• 13 years ago

Also in Dutch :)

init0• 13 years ago

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

banachtarski• 13 years ago

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

kriro• 13 years ago

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.

chris092• 13 years ago

This looks very promising.

glamsmash689• 13 years ago

cool.

deepflame• 13 years ago

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

lox• 13 years ago

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

http://babushka.me/

Introducing Boxen

Related Stories