How to use Puppet correctly?

Question

Puppet

We are looking at Puppet.
There was such a question.
Let's say everything is set. With Puppet, all machines are configured.
It's time to change something in the configs. BUT this needs to be tested first.
Immediately the question is - where? In a separate copy of the combat infrastructure? Yes, this is ideal.
But, for example, there is no infrastructure copy.
And, for example, I have a park of 10 nodes of the same type. I want to test the modified nginx config on one of these nodes.
And here I have questions :)
I change the config. After all, Puppet should notice that the config is different from the reference one and will re-upload it to me? Or not?
Or do I need to stop the puppet agent on this node, play with the config. Make the same changes on puppet master and it will spill to everyone else? So? Or is it completely different?
Let me ask you a simpler question. The introduction says that the puppet agent goes to the master once every 30 minutes with a question if the settings have changed and, if so, changes them. This means that nodes can apply new settings at different times. Surely it is possible to make sure that the new settings of the same nginx on all nodes are applied simultaneously? If it is in the docks, then just tell me "read the manual, it's there" :)

Answer 1

I would recommend that you add hiera to your folder, there was an article about it habrahabr.ru/post/242657
It will allow you to manage your servers more flexibly.
In your case, you will need to create 1 yaml file for a specific node and rewrite the location of the new config.

Answer 2

Puppet's orchestration is bad.
There was puppet-kick, but it was cut out, now there is mcollective, which will allow you to pull the agent on all nodes and apply the configuration. But IMHO this is from a cannon to sparrows.
We are still in the old fashioned way, through pssh we pull on the desired group of nodes 'puppet agent -t'.
Apply the config on a separate server, I think it's unlikely to work out of the box. You need to come up with something of your own :).
Well, or of course, you can always reward

if $::fqdn in $testing_nginx_servers {
    $config = new_config
  else {
    $config = stable_config
  }
  ::nginx::vhost { 'server.com' :
    template      => $config
    server_name   => "${::fqdn} ${title}",
    document_root => '/var/www/server.com',
    ssl_keys      => 'server.com'
  }

And where is the thread in site.pp declare
In the end, you can roll out the config, but not reload nginx :).
On the topic of ansible vs puppet. Subjectively, ansible, mass script runner :). In addition, the state of six months ago is quite inhibitory.
Puppet means that the rollup of changes does not critically affect your environment, and can occur in the background. That is, for a number of packages you wrote 'ensure => latest', and do not worry, it is updated by itself when +\- 30 minutes is needed and that's it. We made changes to the config, checked it on one server, and we are sure that in half an hour it will be everywhere. Now I’ll say nonsense, but about the “scheme” of its work, we can say that it is “finally agreed”, and this “final score” is determined by a half-hour update timeout (as in DNS :) )
Maybe it’s already irrelevant,the person was comparing ansible\salt as alternatives for moving.
If YAML is involved in puppet, there is a hiera, for exporting resources from nodes, there is puppetdb (for example, so that when adding backend servers, their addresses get into the required upstream from nginx, without directly prescribing them in the config).
If it’s annoying that there are no “cycles”, then this is solved first with the help of define, or in the fresh syntax there is each / slise / reduce / filter, which allows you to conveniently work with all sorts of parameter lists, plus a lot of useful things are implemented in stdlib.
Puppet is declarative, and if you do not want to put up with the lack of opportunities to overwrite a variable / resource / class parameters, then it will be difficult for you with it, otherwise I don’t see anything wrong with this choice.

Answer 3

To do this, there are environments in pappet.
Create a new environment with the settings you need, drive one - two - several nodes into this environment, check. Then transfer the changes to the production environment, return the nodes back to the production.
When using r10k - it's very convenient to do it directly with branches in the git - create a new branch, deploy it as a separate environment, then merge.

Answer 4

In the pappet config, apply the new config only for one node and not for all, you can also prescribe specific nodes there.
In general, I recommend that you switch to ansible, it is more cheerful and interesting

Answer 5

We are in a state where we haven't implemented puppet yet. But they seem to have read comparisons, including with ansible. Maybe you didn't read it? :) Can you make a case for crawling ansible? I would not want to regret choosing puppet later.