I am having an absolute nightmare getting Puppet to load a group of modules that will be shared between multiple environments.
The modules in puppet/environments/development/modules get loaded fine BUT none of the dependencies in puppet/modules can be found.
The folder structure for my project is:
And the project is up on bitbucket:
https://bitbucket.org/andrew_hancox/vagrantmoodle
What I do usually to manage the modules dependencies is to have a shell script that will install the modules directly, this way it downloads the necessary dependency as well as pushing to the right place.
I will have in my Vagrantfile
node_config.vm.provision "shell", path: "puppet/script/install-puppet-modules-app.sh"
node_config.vm.provision :puppet do |puppet|
puppet.environment = "production"
puppet.environment_path = "puppet/environments"
puppet.manifests_path = "puppet/environments/production/manifests"
puppet.manifest_file = "base-app.pp"
#puppet.options = "--verbose --trace"
end
The script shell is something like
#!/bin/bash
puppet module install puppet-nginx --version 0.4.0
here you will have your apache, mysql module etc
the environment.conf file will locate the default place for the installed module
# environment configuration used by Puppet4
modulepath = /etc/puppetlabs/code/environments/production/modules:$basemodulepath
I got the whole thing working properly thanks to #michael-mulqueen
The way he fixed it was by setting the module path in the vagrant file:
puppet.module_path = ["puppet/modules", "puppet/environments/development/modules"]
You can see this in the repo referenced in the question.
Related
Not experienced with puppet and vagrant. We used to have all the puppet settings in a big puppet repository and our vagrant instance worked fine. Recently, to have things better isolated so they are not rolled out accidentally, we have a certain path from the big puppet repos separated into a new puppet repos. But I still need all the facters living within the old big repos while the server specific setting from the new repos. Unfortunately, I cannot just specify the big old repos as a module path as my server specific settings will come from the old directory in the old repos, but if I just specify the new repos as the module path, then I miss all the facts. And I have been googling crazily to find a way to specify the facter path for vagrant in vain :(
old_repos -> dir -> my_server_setting
-> module1 -> facter
-> module2 -> facter
....
new_repos -> my_server_setting
can anyone please give me some hints? many thanks
The module_path can be a vector
Vagrant::Config.run do |config|
...
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.module_path = ["old_repos","new_repos"]
puppet.manifest_file = "base.pp"
end
end
I never tried but I guess the hiera_config_path can specify a vector of location too so if you have hiera defined in both the old and the new repos you should be able to point the 2.
I have a projekt with a setup for a multi machine environment for Vagrant. I had to fix some problems, which were initially caused by the redirect issue to https, but solving these lead into other errors, which I fixed in all projects except this one now, which uses the multi machine feature of Vagrant.
So I have this folder structure:
/Vagrantfile
/puppet/box_1/puppetfile
/puppet/box_1/manifests/site.pp
This is my code snippet, where I define my provision directories:
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppet/box_1/manifests"
puppet.manifest_file = "site.pp"
end
My puppetfile looks like this:
forge "https://forgeapi.puppetlabs.com"
mod 'tPl0ch/composer'
mod 'puppetlabs/apt'
mod 'puppetlabs/apache'
mod 'puppetlabs/firewall'
In my site.pp I try to include apt, but I get this error message:
Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::apt for project.local at /tmp/vagrant-puppet/manifests-f2b1fd0ac42b51938ed6ae7e6917367e/site.pp:1:1 on node project.local
When I rearange my puppet files like this:
/Vagrantfile
/puppet/puppetfile
/puppet/manifests/site.pp
like this is the common way of setting this up, it works without that problem, but as I mentioned, there are other boxes, which use different puppetfiles and site.pp files, so this folder structure makes some kinda sense. It seems, that it doesn'even matter, if I delete the config for the other boxes, and setup my Vagrantfile, as if it would be only one box, so I am just confused, how the location, of these files influence the scope of certain classes.
So my questions is here: Is there a way, to keep this folder structure and still have these modules defined in puppetfile available in my site.pp? Or is this generally some kinda bad practice to organize it this way? I was searching for some examples for this, but couldn't find any for some reason...
EDIT: It seems, on provision the puppetfile isnt even used anymore, when its not located in /puppet/ So maybe I just have to tell Vagrant how to use it?
define where librarian should find the puppet file
Vagrant.configure("2") do |config|
config.librarian_puppet.puppetfile_dir = "puppet/box1"
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppet/box_1/manifests"
puppet.manifest_file = "site.pp"
end
Consider the following Puppet-provisioned Vagrant project directory structure:
environments/
dev/
manifests/
site.pp <- Some standard Puppet stuff in here.
prod/
manifests/
site.pp <- Very similar to dev/manifests/site.pp, but with some prod differences
manifests/
default.pp <- Empty, but a place I'd like to keep common parts of the site.pp files
modules/
Vagrantfile <- See below.
Puppetfile
and the following (simplified) Vagrantfile:
# -*- mode: ruby -*-
# vi: set ft=ruby :
envs = ["local", "dev"]
Vagrant.configure(2) do |config|
config.vm.box = "puppetlabs/centos-7.0-64-puppet"
envs.each do |env|
config.vm.define env do |node|
node.vm.provision "puppet" do |puppet|
puppet.environment_path = "environments"
puppet.module_path = "modules"
puppet.environment = env
end
end
end
end
What options are available to me if I'd like to factor out the common parts of the two site.pp files into a single file?
I have tried the following strategies to no avail:
1 - One Manifest Per Environment Which "Inherits" From a Single Project-Wide Manifest
After some reading I'm not even sure this is possible. There used to be the import command which I feel like could have been what I was looking for, but that has been deprecated in newer versions of Puppet.
2 - A Single Project-Wide Manifest and One Hiera File Per Environment
I consider this the least-attractive of the two options since it means the only way to distinguish between environments is via data, and some things are just better expressed with differences in manifests.
However I can't even get this to work. Given the following environment.conf files in the dev/ and prod/ folders:
manifest = ../../manifests/default.pp
gives me an error about not being able to find the default.pp file.
Basically I need to a way to stop duplication between environments. My project is actually more complicated than that above, given that the manifests are getting rather large and unwieldy, and I have more than two environments. I also feel like the fact I'm using Vagrant here (which has it's own ways of passing options to Puppet) is complicating things further.
Any help at all would be appreciated here.
So, here's what I went with. Not what I originally wanted but I'm still new to Puppet and not even convinced what I wanted is possible anyway.
I settled on using hiera data to distinguish between environments, and am now using a single manifest (default.pp). The two site.pp files are completely empty, and are only there as placeholders so Git keeps the dev and prod folders. Rather than have environment.conf files pointing towards the manifest, I simply added the following to the Vagrantfile:
puppet.manifest_file = "default.pp"
I also have started putting things into their own modules, rather than having a huge monolithic manifest.
I have inherited a python app that uses Puppet, Vagrant and VirtualBox to provision a local Centos test machine.
This app was written on Mac and I'm developing on Windows.
When I run vagrant up I see a large list of command line errors, the most relevant of which is:
Running Puppet with site.pp..
Warning: Config file /home/vagrant/hiera.yaml not found, using Hiera defaults
WARN: Fri Apr 25 16:32:24 +0100 2014: Not using Hiera::Puppet_logger. It does not report itself to b
e suitable.
I know what Hiera is, and why it's important, but I'm not sure how to fix this.
The file hiera.yaml is present in the repo but it's not found at home/vagrant/hiera.yaml, instead it's found at ./puppet/manifests/hiera.yaml.... Similarly if I ssh into the box, there is absolutely nothing whatsoever inside home/vagrant but I can find this file when I look in /tmp
So I'm confused, is vagrant looking inside the Virtual box and expecting this file to be found at home/vagrant/hiera.yaml? Or have I inherited an app that did not work properly in the first place? I'm really stuck here and I can't get in touch with the original dev.
Here are some details from my Vagrantfile:
Vagrant.configure("2") do |config|
# Base box configuration ommitted
# Forwarded ports ommitted
# Statically set hostname and internal network to match puppet env ommitted
# Enable provisioning with Puppet standalone
config.vm.provision :puppet do |puppet|
# Tell Puppet where to find the hiera config
puppet.options = "--hiera_config hiera.yaml --manifestdir /tmp/vagrant-puppet/manifests"
# Boilerplate Vagrant/Puppet configuration
puppet.module_path = "puppet/modules"
puppet.manifests_path = "puppet/manifests"
puppet.manifest_file = "site.pp"
# Custom facts provided to Puppet
puppet.facter = {
# Tells Puppet that we're running in Vagrant
"is_vagrant" => true,
}
end
# Make the client accessible
config.vm.synced_folder "marflar_client/", "/opt/marflar_client"
end
It's really strange.
There's this puppet.options line that tells Puppet where to look for hiera.yaml and currently it simply specifies the file name. Now, when you run vagrant up, it mounts the current directory (the one that has the Vagrantfile in it) into /vagrant on the guest machine. Since you're saying hiera.yaml is actually found in ./puppet/manifests/hiera.yaml, I believe you want to change the puppet.options line as follows:
puppet.options = "--hiera_config /vagrant/puppet/manifests/hiera.yaml --manifestdir /tmp/vagrant-puppet/manifests"
To solve this warning, you may first try to check from where this file is referenced, i.e.:
$ grep -Rn hiera.yaml /etc/puppet
/etc/puppet/modules/stdlib/spec/spec_helper_acceptance.rb:13: on hosts, '/bin/touch /etc/puppet/hiera.yaml'
/etc/puppet/modules/mysql/spec/spec_helper_acceptance.rb:34: shell("/bin/touch #{default['puppetpath']}/hiera.yaml")
In this case it's your vagrant file.
You may also try to find the right path to it via:
sudo updatedb && locate hiera.yaml
And either follow the #EvgenyChernyavskiy suggestion, create a symbolic link if you found the file:
sudo ln -vs /etc/hiera.yaml /etc/puppet/hiera.yaml
or create the empty file (touch /etc/puppet/hiera.yaml).
In your case you should use the absolute path to your hiera.yaml file, instead of relative.
The warning should be gone.
I'd like to specify directly in the vagrantfile which provider to use by default for each VM.
For example, given this vagrantfile:
# Vagrantfile
[...]
config.vm.define 'dev_vm' do |machine|
machine.vm.provider :libvirt do |os|
[...]
end
# machine.default_provider = :libvirt
end
config.vm.define 'production_vm' do |machine|
machine.vm.provider :openstack do |os|
[...]
end
# machine.default_provider = :openstack
end
To boot up the following to VMs, I have to issue two commands currently:
vagrant up --provider=libvirt dev_vm
vagrant up --provider=openstack production_vm
I'd like to bring up both with a single vagrant up, especially because I'm running quite a few more machines. Some configuration like the commented machine.default_provider = :openstack would be fantastic to have.
Is there a way to do so?
I don't think there is any easy way to do it. Vagrant will currently use the same provider during the whole run so it could possibly be quite big code change to support this.
Maybe wrapper scripts are the easiest solution now.
Another workaround would be to use separate Vagrantfiles for the VMs and set VAGRANT_DEFAULT_PROVIDER in each. If there is a lot of common config, you could extract it to e.g. Vagrantfile.common, which is included by the others. Something like:
# Vagrantfile 1
ENV['VAGRANT_DEFAULT_PROVIDER'] = 'libvirt'
# assume the common config is in parent directory
load File.expand_path('../../Vagrantfile.common', __FILE__)
Vagrant.configure('2') do |config|
# ...
end