Could some one give me quick answer if it is possible to get Service state using puppet facter?
Basically in the Host facts section I would like to see:
Apache: Running, version x.x.x
Could someone point me to a right direction at least, on how to accomplish that?
You could always use the commands apache status and apache --version. If that's what you are looking for. If you are looking to implement it in a manifest then it is a totally different question.
Related
I'm trying to verify whether a particular Puppet role has been applied to a set of nodes.
I'm using Puppet Enterprise.
What I would like to see is lines akin to "INFO: applying role <role_name>" in the node log or in the Puppet master log.
I haven't found anything like that or similar to that, neither looking at the events log on the node nor in the Puppet Master log.
Does anyone know where to find this information, or at least a way to work around this limitation if needs be?
Eventually I used the Node Graph available in PE:
https://puppet.com/docs/pe/2017.2/index.html
I'm using the ibm_installation_manager module from the puppet forge and it is a bit basic because IBM wrote Installation Manager in a time where idempotency was done much.
ref: https://forge.puppet.com/puppetlabs/ibm_installation_manager
As such it does not cater nicely for upgrades - so the module will not detect if an upgrade is needed, stop existing processes, do the upgrade and then start the processes again. It will just detect if an upgrade is needed and try to install the desired version and if that constitutes an upgrade that's great, but it will probably fail due to running instances.
So I need to implement some "stop processes" pre-upgrade functionality.
I need to mention at this point I'm new to ruby and fairly new to puppet.
The provider that the module uses (imcl.rb) has an exists method.
The ideal way for me to detect if an upgrade is going to happen (and stop the instances if it is) would be for my puppet manifest to be able to somehow call the exists method. Is this possible?
Or how would you approach this problem?
Something like imcl.exists(ibm_pkg["my_imcl_pkg_resource"])
The ideal way for me to detect if an upgrade is going to happen (and stop the instances if it is) would be for my puppet manifest to be able to somehow call the exists method. Is this possible?
No, it is not possible, at least not in any useful way. Your manifests describe how to build a catalog of resources describing the target state of the machine. In a master / agent setup, this happens on the master. The catalog is then used as input to a separate step, in which it is transferred to the target machine and applied there. It is in this second step that providers are engaged.
To the extent that you want the contents of your catalogs to be influenced by the current state of the target machine, the Puppet mechanism for that is to convey the needed state details to the catalog builder in the form of facts. It is relatively straightforward to add your own facts. Indeed, there are at least two distinct, non-exclusive mechanisms, going under the names "external facts" and "custom facts".
I'm working on a tool which manages WordPress instances using puppet. The flow is the following: the user adds the data of the new WordPress installation in the web interface and then that web interface is supposed to send a message to the puppet master to tell it to deploy it to the selected machine.
Currently the setup is done via a manifest file which contains the declaration of all WordPress instances, and that is applied manually via puppet apply on the puppet agent. This brings me to my 2 questions:
Are manifests the correct way of doing this? If so, is it possible to apply them from the puppet master to a specific node instead of going to the agent?
Is it possible to automatically have a puppet run triggered once the list of instances is altered?
To answer your first question, yes there's absolutely a way of doing this via a puppetmaster, what you have at the moment is a masterless setup which assumes you're distributing your configuration with some kind of version control (like git) or manual process. This is a totally legitimate way of doing things if you don't want a centralized master.
If you want to use a master, you'll need to drop your manifest in the $modulepath of your master (it varies depending on your version, you can find it using puppet config print modulepath on your master) and then point the puppet agent at the master.
If you want to go down the master route, I'd suggest following the puppet documentation which will help you get started.
The second question brings me on to a philosphical argument of 'is this really want you want to do?'
Puppet traditionally (in my opinion) is a declarative config management tool that is designed to make your systems look a certain way. You write code to determine 'this is how I want it to look' and Puppet will converge to make it look that way. What you're looking to do is more of an orchestration task (ie when X do Y). There are ways of doing this with Puppet like using mcollective (to trigger a puppet run) which is managed by a webhook, but I think there are better tools for the job.
I'd suggest looking at ansible, saltstack or Chef's knife tool to do deploys like this.
I am trying to understand the best practice of setting up Puppet in the first place, let's say I have 1000 existing servers needs to be managed Puppet.
Do I manually install Puppet agent on each or there is a better way.
Sorry if this question is too generic just want to have some idea.
1000 servers could be a lot for a single master instance. of course it will depend on the master specs, and other factors related to the puppet runs.
There are few questions you need to answer first to determine how are you going to go about it such as
Puppet Enterprise or Open Source? What is the current configuration night mare you are trying to solve?
What is the current configuration data related to the challenge or
problem you have?
What are the current business roles (e.g. web server, load
balancer,database, ..etc) related to the problem you have? What
makes a role in terms of configurations?
I would suggest that you start first small to learn more about the puppet DSL, and its ECO system (master, agent, puppetdb, console/dashboard). I also recommend you start with the free 10 nodes puppet Enterprise as it will let you focus more on the problem at hand not how to configure the puppet masters, and agents, how to scale them, ..etc.
One more thing install puppet agent every where if you can in NOOP/disabled mode to get at least facts and run it in a masterless fashion using puppet apply when you need to. i find NOOP mode more useful as it tells you what needs to be changed, also you can enforce changes using --no-noop
hope that will get you started.
To answer your question: Yes, Puppet agent would need to be installed on every node. If you are managing 1000 nodes, I would assume you have your own OS image. In this case, its best to add it to the OS image, and use this image on 1000 nodes.
I want to make some dynamic configurations details in the puppet master side before it makes a deployment on puppet agent. So I want to send significant amount of configuration details along with the request of the agent to master. Is there a proper way to do this in puppet ?
Regards,
Malintha Adiakri
Yes! There is facter. This is how I use it and what I find most robust but there are other ways to define new facts.
For example if you want to add role of the server then you can do
export FACTER_ROLE=jenkins
Now you can see that command facter role will print jenkins. Yay!
After running puppet agent all facts known to system will be passed to thenpuppetmaster. Be aware that service puppet will not know fact that you just defined because it runs in other scope.
I put my facts in file .facts and source it before apply.
This is my script that runs from cron:
#!/bin/bash
source /root/.facts
puppet agent -t --server puppetmaster.example.com --pluginsync
While the previous answer is correct, I'm opening this as a new one because it's significant. Defining FACTER_factname variables in the agent's environment is a nice and quick way to override some facts. If you wish to rely on your own facts for production purposes, you should look to custom facts instead.
In its basic form, you use it by deploying Ruby code snippets to your boxen. For an easier approach, take special note of external facts. Those are probably the best solution for your problem.
Also note that as of Facter 2 you can contain complex data structures in your facts and don't have to serialize everything into strings. If the amount of data from the agent is high, as you emphasize, that may be helpful.