I am creating a virtual machine in terraform that will appear in Azure. Broadly speaking, once that's created how can I tell puppet that the virtual machine exists and to do the basic config steps? I have puppet with the commands I want it to run when a virtual machine is made. Can I tell it to look for a resource with a name? I am pretty clueless and have not been able to find much information on how in code the two work together.
If I was doing it on a cloud infrastructure I'd install the agent, either from a local repo or downloading and installing from the Puppet downloads site https://puppet.com/try-puppet/puppet-enterprise/download/.
Then once the agent was installed I'd run puppet config set server <your puppet server>
Within 30 minutes the agent should run and contact the puppet server.
If you've configured autosign https://puppet.com/docs/puppet/7/ssl_autosign.html then the server will accept the certificate request and start managing the node.
Related
i have puppet master and node/agent setup configured manually. using the self signed certificates by master, all client nodes are bootstrapped and now they are under puppet master controlled. i mean registered with puppet master.
i have done this registration manually using commands like puppet cert sign and puppet agent --test and puppet cert list etc
however, my question is, what is the best automatic way to bootstrap a particular node..
1: Is it recommended that , write shell script (on UNIX) and get these commands automated ? any better way ?
2: does puppet already provides an automated configuration/resource which i can simply call in someway and get node registered ?
please suggest.
Regards,
you can get very close to your goal with external node classifiers and autosigning
i used this to fully automate the process of creating and deploying virtual machines.
I am deciding between using puppet or chef to provision a matching development and production environment. I plan to regularly add virtual hosts to apache. I have looked through the docs of both and I am not certain about this. If I add a virtual host, does the server need to be re-provisioned entirely (destroyed / rebuilt) for a new virtual host to be active? Or can I simply reboot the machine and new changes to the puppet or chef manifests will be applied?
Nope, provisioning can run over and over again, even without reboot.
Chef by default runs every 30 minutes.
Is there a built-in way to mass deploy the Puppet agent on hundreds of nodes, in an unattended, automated way? (providing user/pass/cert.)
There is no built in way to do so. But, you can always use kickstart/pre-seed to deploy puppet agent as part of os provisioning and hand it to puppet to manage your hosts.
Or as an alternate you can write custom shell script to deploy puppet agent's on hundreds on machines, I personally use this method to manage puppet. For reference here is the script.
Also, you may be interested in project razor which automatically deploys puppet as part of bare-metal provisioning and hands it to puppet for configuration management.
Basically the only thing you need to do is to install the Puppet Agent on those machines. I assume that you don't install software packages manually for hundreds of nodes, right?
Once you installed the Agent, it will automatically find the Puppet Master (if puppet.yourdomain.com points to that host), sends certificate requests to the Master where you need to sign them. You can also use the autosign feature of Puppet.
Furthermore, Puppet Enterprise and The Foreman are bases on Puppet and they come along with additional provisioning features.
I suggest that you use the parallel SSH. There are plenty of flavours, I prefer clush, see https://github.com/cea-hpc/clustershell/wiki/clush
You need to create your /etc/clustershell/groups file with groups, e.g.:
all: node[1-2000]
Then you can install the puppet on all the nodes easily with something like this:
clush -bw #all yum -y install puppet
I would like to know how automated deployment to production works with puppet.
Do I need a puppet-slave on my production server? If thats the case, is that insecure and what rights do puppet get with that?
A use-case could be to get a package from a repository manager and then to deploy it to the production server. What are the main steps on this way with puppet?
Puppet can run in solo-mode where you apply a set of configurations in config file on the host in which you run it, as long as puppet (client/agent) is already installed there.
You can also run puppet in a client-server mode, where an agent runs on your production server and obtains configuration details from a puppet server (or puppet master)
If you run in client-server mode, how do you ensure security?
Well, in client-server mode, you pre-register a client/agent to a server you nominate and the exchange ssl certificates before any actions can be applied on that agent. Again, you would have to (on your pupper server or master) associate a set of actions or manifests to the production server running the agent. I suppose that provides sufficient security, assuming you already took care of standard OS security for both systems in the first instance.
Also, additional security can be provided by the puppet file server as suggested in the link suggested by bagheera. If you are even more paranoid than that, then you would need to consider using puppet librarian with a Puppetfile that is assembled and used at run time.
In either case, the bigger challenge for you is that the set of instructions (or manifests) applied have undergone testing (on a test or staging server) before being applied to a production system.
So, you need to be sure what you are doing when you start trying to apply puppet manifests to production servers. I would not recommend just downloading puppet modules and using them without a decent insight into what you are doing and a clear understanding of what each module you intend to use does.
Puppetlabs have great introduction documentation for using puppet, and that would be an excellent place to start learning more about puppet. A good book would also be useful.
I'm trying to set up a multi-VM Vagrant environment that spins up an OpenStack controller and a few OpenStack compute nodes and then provisions a VM or two on the compute nodes.
Yes, I'm talking about VMs running on VMs. It sounds a little crazy, but this multi-VM Vagrant environment has already been created at https://github.com/lorin/openstack-ansible and it works perfectly, as I describe at http://wiki.greptilian.com/openstack
I can only draw inspiration from that GitHub repo and its corresponding tech talk, however, because it uses Ansible as the Vagrant provisioner while I have a requirement to use Puppet.
I'd like to use the official Puppet Labs module for OpenStack at https://github.com/puppetlabs/puppetlabs-openstack but it uses storeconfigs, so I get errors like this because my Vagrantfile doesn't include a VM to serve as a Puppet master:
warning: You cannot collect exported resources without storeconfigs being set; the collection will be ignored on line 142 in file /tmp/vagrant-puppet/modules-0/nova/manifests/init.pp
Resource type anchor doesn't exist at /tmp/vagrant-puppet/modules-0/nova/manifests/db/mysql.pp:18 on node controller.example.com.
I suppose I could tweak my Vagrantfile to spin up a Puppet master along with the OpenStack hosts, but I'm not sure how I'd do that and it seems to introduce extra complexity into the Vagrant environment.
I'm wondering if can do this in with "masterless" Puppet instead. A post at http://semicomplete.com/presentations/puppet-at-loggly/puppet-at-loggly.pdf.html suggests it's possible, saying, "puppet –environment prerun manifests/prerun.pp ... makes storeconfigs work ... puppet –storeconfigs manifests/site.pp ... This is the main puppet run" but I'm confused about the implementation details.
Can anyone point me to a Vagrant repo that runs "masterless" Puppet but uses storeconfigs?
You'll need to configure your storeconfigs with a DB that all vagrant VMs can reach. Loggly used AmazonRDS, but you can use other DBs as puppet docs show. Assuming you have a DB that all VMs can reach and you run puppet with storeconfigs option and you have the correct DB connection info configured in puppet, you should be good.