31–40 of 57 posts
Earlier quoted context omitted.
It's called Docker.
Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.
It feels almost as a native support, but the hack is betrayed by the networking setup.
I wish it would be possible to just expose ports on the real localhost.
Don't install server-side stuff directly on your Mac. If you are working on server-side projects, then use virtual machines. Vagrant in combination with a configuration management system (e.g. Puppet) is very helpful here. Use Homebrew to install command-line tools. Use Homebrew Cask to install GUI tools that aren't on the Mac App Store. Lots of people find it useful to check their environment's configuration files i…
One thing that I've thought about trying though, is Boxen. Github supports hundreds of developer macs and they built this framework to do so. It looks pretty incredible. https://github.com/blog/1345-introducing-boxen
Don't install server-side stuff directly on your Mac. If you are working on server-side projects, then use virtual machines. Vagrant in combination with a configuration management system (e.g. Puppet) is very helpful here. Use Homebrew to install command-line tools. Use Homebrew Cask to install GUI tools that aren't on the Mac App Store. Lots of people find it useful to check their environment's configuration files i…
Vagrant has been a much bigger time sink for me than benefit. The ssh-agent never works while provisioning for nix servers, only during ssh (which I can do using the -- -A regardless). It often gets confused and the machines need to be destroyed and re-created after 1-2 provisioning attempts. Packers (The tool used to create vagrant boxes) lack of support for winrm on windows systems has also been a bone of contentio…
A quick google search for 'vagrant windows' will lead you to one of many blog posts like this one [1], which point out that your Vagrant experience on Windows will be better if you install Git. This places 'ssh' and 'scp' on your path, and then everything about Vagrant just works, including vagrant ssh. I still prefer to use PuTTY to connect when on Windows, but that's my personal preference.
As for the chef re-provisioning, it is more likely an issue with the environment, not Chef of Vagrant. When Vagrant sees that the Chef binaries are already in place, it will note that and continue with the provisioning. Try it again when you have the git command line tools in your path and see if its still an issue.
However, these problems are with your Windows setup of Vagrant, not Vagrant itself. Vagrant on a Mac requires no such workaround to get the unix tools in place, and casting your aspersions against Vagrant from your experience on Windows when it works out of the box on a Mac is unfair to the tool.
Here are some of my tools and tips.
- homebrew is great - homebrew cask is helpful, too - 1password or similar - virtualbox can give you clean playgrounds and test environments that match your servers - boot2docker is handy for quickly starting and running services like databases without polluting your mac directly too much - I also get a lot of use out of vagrant but YMMV - I've lately started using project-specific instances of chrome (created with the chrome SSB script). This lets me keep lots of tabs separate and easily pause work and resume later - The chrome Tabs Outliner plugin is also really key
Here's my recent blog post with more details: http://peterlyons.com/problog/2015/02/osx-development-setup
Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.
IMHO, having a VM in hand may help you align both your dev and production environments.
Plus, many of the available database installs are much more fragile (and use older versions) on my Mac than they are on a VM.
The only time I see local development working particularly well is for front end development, where the part that matters is in the browser, not the server.
Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.
Earlier quoted context omitted.
The chef provisioner which comes as part of vagrant does indeed install chef on the target VM. To say that vagrant is not doing this is splitting hairs.
I've never used Chef, with or without Vagrant, but I have used Puppet. It's generally better to have a shell script install your provisioning tool, or use a box that already has it installed, than depending on Vagrant to do anything for you. Here's a simple example: https://github.com/puphpet/puphpet/blob/master/archive/puphp...
Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.
I use vagrant + virtualbox (runs ubuntu via vagrant setup) + ansible to bootstrap the VM. I've had this setup for 2 years now. No issues and I get to use sublime to edit files locally while they are shared with the VM.
I do the same, but I've had trouble with the overhead of virtual machines (admittedly on an older laptop). Have you not found this to be a problem at all? As deployments get simpler and the usefulness of Ansible for server config declines, I'm thinking about abandoning the VMs and going back to running things in OS X.
Not myself. The VMs are never doing anything so taxing that they incur significant overhead. I can regularly keep 3-4 running concurrently without an issue.
> usefulness of Ansible for server config declines
I don't ever see this being the case. Configuration is becoming more challenging, not easier. Even if you use a tool like Docker perfectly for all of your services (which is ironically very hard without some kind of CM tool beside dockerfiles), you still have to: install packages, change configuration files, run commands, enable services, change permissions, change firewall rules, modify DB users, manage SELinux, setup log file rotation...
Servers are hard to set up and maintain in a coordinated fashion without some kind of CM tool. And while PAAS providers can handle quite a few lightweight services without requiring you to use any CM tools, there comes a point where they no longer scale the way you need them to, and you're back to provisioning VMs or even bare metal.