Как я управляю марионеточными узлами с различными версиями модуля?

Есть несколько способов, которыми мне больше всего нравятся следующие:

• Для перехода с apache1 на apache2 мы создали полностью отдельные модули. Вы могли подумать, что это вызвало много дублирования, но мы переделали нашу конфигурацию одновременно.

• Для простых обновлений отдельных пакетов мы делаем такие вещи, как

   package {"foo":
  гарантировать => $ хочет_foo_upgrade? {
   true => последнее,
   false => 1.0
   }
  }
  

  где $ want_foo_upgrade основан на нашей базе данных инфраструктуры, данных extlookup или фактах.

• Что касается промежуточных вещей, мы применяем второй подход и используем эту переменную для определения, какие конфигурационные файлы использовать, или шаблоны для конфигурационных файлов.

I would recommend doing this by having a single module that takes a version number as a parameter, something like this:

class our_software ($version) {
  ...
}

What you do within that class depends on how much the two versions of your software have in common. You might be able to have all of the config files included directly in the class with templates that pick the right values for their settings based on the version number or you might have two separate classes that set up each version's environment entirely differently, with the main class deciding which to include based on the version number.

If you're using hiera (or some other external lookup thing), this lets you specify the desired software version completely separately from the code that says "install our software".

If you want to get fancy, the module could include a fact to indicate what version of the software is currently installed so your module can prohibit things like version downgrades (assuming that's an appropriate thing in your environment).