5 ms·

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 usi

by keslag 12y ago

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 contention. It requires a number of workarounds (like installing open-ssh) on the windows VM that in no way would be viable on a production windows server. And that divergence allows for the "It works on my machine" bugs which is really the whole point of using Vagrant. I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan. Homebrew Cask also has no oversight for breaking changes, so use this only as a convenience, not a tool to be relied upon. It frequently looses track of applications, and I can't even find where it decides to put some error logs if they're created at all. Some of these problems could be my lack of experience in operations, but the documentation for these is far from complete. A VM with snapshots and a good backup strategy will serve you better in the short term. This changes if you're attempting to support multiple dev, but if you're a lone guy, then snapshots are far far less buggy.

JimDabell 12y ago
I haven't experienced any of that, but then I wouldn't use it for Windows in the first place and it doesn't sound like the kind of thing the OP is doing either. The Salt provisioner doesn't bootstrap Salt every time, so it may be a bug with the Chef provisioner rather than something that's true of all provisioning. Isn't Chef installed by default on most base boxes anyway though? It sounds like you've hit an edge case that you can work around by installing Chef in your base box. Snapshots and backing up VMs sounds a lot more hassle than Vagrant. Same goes with Cask – I've never had it lose track of applications. It's hard to see how this could happen, as this mechanic is pretty simple – if it's in the directory, it's present, otherwise it's absent.
Quequau 12y ago
> Vagrant has been a much bigger time sink for me than benefit. This has been my experience as well... and I would really, really like to have a system in place where I could painlessly spin up VMs to do development in, so that I could leave my Mac as is.
- mateuszf 12y ago
  It's called Docker.
  - keslag 12y ago
    Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.
    - ithkuil 12y ago
      Yep, although it creates only one you can run a bunch of containers in it. 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.
      - keslag 12y ago
        Absolutely, I should have specified 'a single vm' in my response. I didn't understand that when I was first trying to understand boot2docker, and now I'm using imprecise language to help confuse others. Thanks for clarifying.
  - Jean-Philipe 12y ago
    Docker is not a VM and only works on Linux.
    - billdstrong 12y ago
      boot2docker is a commandline interface to docker that works on Windows, Mac and Linux. (Maybe *BSDs too.) On non Linux systems, it downoads a prebuilt VM, and runs it with Virtualbox. This is how Docker currently works on other OSes.
jtreminio 12y ago
> I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan. Vagrant won't install Chef or Puppet for you - your provisioning scripts need to do this. If you're seeing Chef being downloaded every single time you provision, then your scripts are broken and you should fix them, or your 3rd party scripts are broken and you should report a bug.
- keslag 12y ago
  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.
  - jtreminio 12y ago
    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/puphpet/shell/install-puppet.sh https://github.com/puphpet/puphpet/blob/master/archive/puphp...
    - geerlingguy 12y ago
      ...or switch to a provisioning tool that doesn't need to be installed on guest VMs (e.g. Ansible), saving a little time every time you provision. Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.
      - keslag 12y ago
        I liked Ansible a lot; during our evaluation I had a single Ansible file provisioning a sample dev setup in around 50 lines. We need to support windows servers primarily, much to my objection, so the 'blessing' of the machine to automate Ansible on windows required a manual step at the time, which wasn't acceptable for our use case. We ended up picking chef, both for it's more agnostic approach to OS's, but also it's much more developer friendly, regardless of it's overly verbose generators, git repository litter, and quirks that still have me scratching my head.
falcolas 12y ago
Windows is, admittedly, a second class citizen for Vagrant. That said, with one install and one config file change, vagrant is as usable on Windows as it is on the Mac. I keep a number of exploratory Vagrant instances on a USB key (just the files, the boxes default to your "home" directory on the machine), and work on them regularly on both a Mac and Windows. 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. [1] https://eamann.com/tech/vagrant-windows/ https://eamann.com/tech/vagrant-windows/
- keslag 12y ago
  I'm talking about running windows inside of Vagrant and having these issues on a Mac. The problems I've detailed have long standing issue logs on github, some closed without resolution. I'm not casting aspersions, I'm explaining my use and my experience. This is valid, regardless of whether you have had the same experience. Regardless, the tool sells itself as working on windows, so it is not only fair, but apt. Providing a counter example is a good rebuttal, but saying my experience is invalid reeks of fanboyism.

by keslag 12y ago

JimDabell 12y ago

I haven't experienced any of that, but then I wouldn't use it for Windows in the first place and it doesn't sound like the kind of thing the OP is doing either. The Salt provisioner doesn't bootstrap Salt every time, so it may be a bug with the Chef provisioner rather than something that's true of all provisioning. Isn't Chef installed by default on most base boxes anyway though? It sounds like you've hit an edge case that you can work around by installing Chef in your base box. Snapshots and backing up VMs sounds a lot more hassle than Vagrant. Same goes with Cask – I've never had it lose track of applications. It's hard to see how this could happen, as this mechanic is pretty simple – if it's in the directory, it's present, otherwise it's absent.

Quequau 12y ago

> Vagrant has been a much bigger time sink for me than benefit. This has been my experience as well... and I would really, really like to have a system in place where I could painlessly spin up VMs to do development in, so that I could leave my Mac as is.

mateuszf 12y ago
It's called Docker.
- keslag 12y ago
  Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.
  - ithkuil 12y ago
    Yep, although it creates only one you can run a bunch of containers in it. 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.
    - keslag 12y ago
      Absolutely, I should have specified 'a single vm' in my response. I didn't understand that when I was first trying to understand boot2docker, and now I'm using imprecise language to help confuse others. Thanks for clarifying.
- Jean-Philipe 12y ago
  Docker is not a VM and only works on Linux.
  - billdstrong 12y ago
    boot2docker is a commandline interface to docker that works on Windows, Mac and Linux. (Maybe *BSDs too.) On non Linux systems, it downoads a prebuilt VM, and runs it with Virtualbox. This is how Docker currently works on other OSes.

jtreminio 12y ago

> I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan. Vagrant won't install Chef or Puppet for you - your provisioning scripts need to do this. If you're seeing Chef being downloaded every single time you provision, then your scripts are broken and you should fix them, or your 3rd party scripts are broken and you should report a bug.

keslag 12y ago
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.
- jtreminio 12y ago
  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/puphpet/shell/install-puppet.sh https://github.com/puphpet/puphpet/blob/master/archive/puphp...
  - geerlingguy 12y ago
    ...or switch to a provisioning tool that doesn't need to be installed on guest VMs (e.g. Ansible), saving a little time every time you provision. Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.
    - keslag 12y ago
      I liked Ansible a lot; during our evaluation I had a single Ansible file provisioning a sample dev setup in around 50 lines. We need to support windows servers primarily, much to my objection, so the 'blessing' of the machine to automate Ansible on windows required a manual step at the time, which wasn't acceptable for our use case. We ended up picking chef, both for it's more agnostic approach to OS's, but also it's much more developer friendly, regardless of it's overly verbose generators, git repository litter, and quirks that still have me scratching my head.

falcolas 12y ago

Windows is, admittedly, a second class citizen for Vagrant. That said, with one install and one config file change, vagrant is as usable on Windows as it is on the Mac. I keep a number of exploratory Vagrant instances on a USB key (just the files, the boxes default to your "home" directory on the machine), and work on them regularly on both a Mac and Windows. 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. [1] https://eamann.com/tech/vagrant-windows/ https://eamann.com/tech/vagrant-windows/

keslag 12y ago
I'm talking about running windows inside of Vagrant and having these issues on a Mac. The problems I've detailed have long standing issue logs on github, some closed without resolution. I'm not casting aspersions, I'm explaining my use and my experience. This is valid, regardless of whether you have had the same experience. Regardless, the tool sells itself as working on windows, so it is not only fair, but apt. Providing a counter example is a good rebuttal, but saying my experience is invalid reeks of fanboyism.