I am using the trusty64 vagrant box and I provision it using puppet.
I just noticed today that ruby and chef are installed and I don't use either of them for my VM work.
Do I need them there for Vagrant to do its magic?
Can I remove them after my VM is provisioned or will vagrant halt and vagrant up stop working?
so to the question
Do I Need Ruby and Chef On My Vagrant Box
Its mainly up to you.
no, more seriously:
Ruby comes install with Linux distro, generally some older version but its a fact that it is delivered (as python, perl ...) so you should leave it. It is not doing any harm and some other tools (including chef and puppet) relies on Ruby to be installed so if you provision with puppet you must leave ruby
Vagrant does not rely on ruby to be installed on the guest to do its magic, its mainly issuing ssh script command to do the update on network/hostname ...
trustry64 box is an official box from hashicorp (the company behind vagrant) and vagrant does support out of the box chef and puppet provisioning those tools are installed. Again they don't make any harm even if you're not using it.
The thing is that your box will have ruby and chef installed and whenever you boot a new VM from this box, it will contain ruby and chef, I think you will spend more time cleaning the booted VM at the end of the day, specially if you have to destroy/rebuild the VM.
If you want a minimalist box that contains only the thing you need, you can look at packer - packer is a tool to automate the creation of vagrant box, so you can really control what is install from the iso file of the OS to the libraries and 3rd party tools.
Vagrant does rely on ruby installed in the box if you are using chef or puppet provisioner. chef/puppet runs happen inside the guest box which vagrant orchestrates using ssh.
You can remove chef when you will use chef provisioner,vagrant will download and install it again but you would need ruby for puppet.
See puppet install dependency here
Related
Our organization has not upgraded to Chef 13 or 14, so we have to pin all our cookbooks to version 12. This means pinning to chef-dk version 1.6.11.
I'm spinning a centos7 vm in Vagrant with a cookbook and have set the version, but it will only install the Latest of chefdk, which results in the machine getting Chef 14. I've added a dependency in metadata.rb of chef_version ~> 12, so the provision fails, as Chef 14 is installed but the cookbook demands 12.
I should mention that the VM is for cookbook dev, so i want the right version of chef on it.
What am i missing to get the right version installed?
Thanks.
recipes/default.rb:
node.default['chef_dk']['version'] = '1.6.11'
node.default['chef_dk']['global_shell_init'] = true
include_recipe 'chef-dk'
metadata.rb:
depends 'chef-dk'
chef_version '~> 12.0'
berksfile:
cookbook 'chef-dk'
The part that is failing is the "outer" Chef, the thing running the recipe, not the ChefDK install (it never gets that far). We don't generally recommend using Chef to install ChefDK because installing both the chef-client and ChefDK installers on the same machine can lead to confusion as there are overlapping command line tools. I would provision the dev VM using a simpler system, probably a bash script or similar. We also do provide chef/chefdk Docker images on Hub for this kind of thing. (also we don't recommend doing cookbook development inside a VM at all, but I would guess that ship has sailed for you)
Currrently, we are setting up development environment using Vagrant. All software (php, mysql, apache, memcached..) are installed using Vagrant Chef solo provisioner.
Now we want to create a test environment using a physical machine (it has same OS to the Vagrant virtual machine).
I don't want to install all required softwares on the test server manually, instead of that I want to setup test server automatically using same Vagrant provisioner. Is it posible and how can I do that?
You can use/run chef-client in local mode on that server see https://docs.chef.io/ctl_chef_client.html#run-in-local-mode
Chef solo https://docs.chef.io/chef_solo.html is also an option but I think chef-client local mode is preferred now.
Another option is to create a free hosted Chef account, upload your cookbooks to hosted Chef, bootstrap your server and run the chef-client.
The best approach I think is to use an actual Chef server. Use hosted Chef or setup your own Chef server. Assuming you will want to also easily update the configuration of the test server as you make changes to your recipes, using an actual Chef server is the best approach.
Is there a programmatic way to get the version of the locally installed Vagrant without using the terminal commands? (ie. Not parsing the answer from the output of `vagrant -v`)
As Vagrant is no longer served as RubyGem now (from v1.1), you'll need a new gem called vagrant-wrapper.
It's a Ruby wrapper around New Vagrant installations. You can control vagrant with it from Ruby.
For version this:
require 'vagrant-wrapper'
VagrantWrapper.new.vagrant_version
I am trying to execute chef commands and build the server for that I did below setup on MacOS but observed that I need to have vagrant and virtualbox but I am not sure if I need to install it on host macOS machine or Virtual machine. Could you please suggest on this.
Setup which I did so far is as below:
On Mac OS I have installed VirtualBox and created a base ubuntu Virtual Machine
Then Inside virtual machine having ubuntu as OS installed ChefDk, Hosted chef server setup, knife and git
created chef-repo repository
In order to complete setup, Do I need to install vagrant and one more instance of Virtualbox inside virtual machine on ubuntu OS and do I need any additional installation?
Install ChefDK and Vagrant as well as VirtualBox on your workstation. This allows you to use any editor/IDE to edit cookbooks and then provision a VM using Vagrant and Virtualbox (or other supported hypervisors).
In general, I would recommend to follow Learn Chef.
Honestly, the question is a little confusion on your objective. But from a high level, i can assume that you are trying to get started with chef using the hosted chef server. First i agree with #StephenKing pointing you to the learn chef site. That's a good starting point. But here are some things that should clear up your question:
Typically there will be a development workstation. In your case its the MacBook. This is where you will install chefDK and write your fancy cookbooks. It should have the chef-repo, knife.rb etc to talk with the chef server.
Once your initial cookbook writting is over, you upload the cookbook and other params like environment, data_bags, roles etc to the chef server (in the chef-org)
Its here you need a node to apply your cookbook. As a starter, use some nodes from a VPS that's far more easier rather then trying to use vagrant nodes or something. As the saying goes "one step at a time". Do not try to learn chef and vagrant or even more (which is what you will encounter with chef) at the same time.
Once you have the node, bootstrap the node to your chef-org where the cookbooks were uploaded. Then run chef-client on the node.
And you are on your way to the chef world.
I am using nodejs with ansible and vagrant
I need to create a new machine for development with such things:
on every vagrant up I need to do:
run this script (to install all needed soft for development):
bash <(wget -qO- https://raw.githubusercontent.com/thoughtbot/laptop/master/linux)
NPM install on every submodule in my project
install and run mongodb service
How I can set these stuff to do automatically in vagrant or ansible?
You have a few options:
vagrant up, install your dependencies and repackage it as a box with: vagrant package or vagrant box repackage
Use chef/puppet/ansible provisioners, or even the shell provisioner. This will allow it to happen on vagrant up or vagrant provision
Roll your own in ruby and have vagrant run it (a vagrantfile is basically just ruby). I don't recommend this way.
I personally recommend 2 even though its the slowest (requires you to do all the owrk every time you destroy and up). 1 is a really good choice but I tend to keep vagrant as close to base state as possible so that no surprises pop up during deployment. And it makes it easier to share across people if you don't have to constantly re-package it and maintain that .box