I recently joined a new company and one of the first projects they’ve given me is to figure out how to install Foreman without Puppet. Essentially, this team seems to be hellbent on getting away from puppet and don’t even want me to use the foreman-installer package at all. They’re trying to migrate to 100% ansible.
I’ve downloaded the foreman-installer puppet modules and have been looking through them to see if it’d be possible to duplicate what they do with an ansible role. The puppet modules are pretty complex and appears to account for every possible scenario. I don’t think I would need the ansible role to be as flexible as the puppet-installer. I was thinking; though, before I even begin doing any sort of work toward doing this, I ought to see if anyone else is already doing this sort of thing, or if it’s even been discussed.
Has there been any discussion or desire to move away from or provide the possibility to install Foreman without the need for puppet? I’ve seen some discussion about making the foreman-installer the only support installation method. So I don’t see puppet ever becoming an optional component. Funnily, I’ve found someone else’s ansible role that installs Foreman, but the meat and potatoes of the role simply runs the foreman-installer.
I’ve tried; with little success, following the “Install From Packages” instructions provided in the Foreman 3.2 manual. I can install the packages just fine, but the manual configuration and setup portion of the documentation is terribly lacking.
I’m also thinking that doing the work to convert the foreman-installer puppet modules to ansible is more work than it’s worth. If anything changes with Foreman and the foreman-installer, then those changes would need to be tracked in the ansible role as well. It might be more worth my time putting forth the effort to convince the team that using the foreman-installer is the best way forward. I feel like, if they’re not willing to use Foreman purely based on the fact that puppet is involved, then that’s like throwing out the baby with the bathwater. There are too many useful features and benefits provided by Foreman that it’d be silly to not use it simply because puppet is a component of it.
This is exactly the summary of the discussion about this in the past.
If I get hit by the topic at customers with the same plan, I tell them that Puppet is a dependency of the installer like any other library would be and there are other examples out there which use Ansible, Chef or Salt.
This is also how the discussion goes at some point before legacy code starts to rot and maintenance starts sliding down a slope because eventually nobody wants to touch the code.
It’s certainly not a tasty prospect, but sometimes we need to grasp the nettle when weeding. Converting the installer to Ansible would be a worthwhile effort in my view. Any efforts to split various components of Foreman/Katello onto separate servers would benefit from being ansible playbooks in my view. Orchestrating the clustered deployment of Satellite over multiple servers would be much nicer through Ansible I feel.
This is very broad question and I guess some unpacking needs to be done to answer it fully, so I’ll try my best, but feel free to follow-up with questions for details.
So to have this out of the table as of Foreman 3.0 (with improvements in 3.1) Puppet is now fully optional feature on puppet installation: The Road to Making Puppet Optional
Tho foreman-installer is still depending on puppet-agent to run, but this is quite a lite dependency compared to the puppet-server. We were thinking about implementing the installer in “something else” where ansible would be an obvious choice, but we don’t feel it is worth the effort as there is just too many options to customize and account for and it would be hard to build a tool that would allow such a flexibility to users.
There is forklift project that wraps the foreman-installer with ansible playbooks and is not meant to use in production, but as you say that is not what you’re looking for.
Writing a pure ansible installer would be bit though, but if you’d not aim for the full complexity of foreman-installer it might be doable, there is a POC from @ehelms and @Marek_Hulanforeman_spark you might want to take a look into as a starting point, but it is bit outdated as noone has seen value in rewriting current installer.
I’d also add tho, that installer is really great tool to guide you throught the installation process and I’d not avoid it just because it uses Puppet, but if you really want to, you might install Foreman from code, that is certainly not recommended.
Another option might be to run foreman-installer and remove it once you’re happy with the setup you’ve got. It is definitelly useful to keep the installer configuration around in case you want to adjust your install. But you’d not have puppet around at all on the runing instance.
I question the benefit of this massive effort. Over time a lot of things have built up.
There are a lot of validations which Ansible simply doesn’t have. For example, Puppet’s data types ensure that only a correct value can be passed. The installer takes this and builds a UI around this. Ansible does not have a type system at all and you’d need to hand write this in any installer to prevent these misconfigurations.
We’ve also built up quite a set of tests over time. Do not underestimate rewriting all of those.
Having said that, you are right that the installing from packages instructions are outdated and simply lacking for various plugins, most notably Katello which has a massively bigger setup. While I think this should not be the install method followed by the majority of users, it is something that is good to have available as a reference.
To @Duncan_Innes’s point about multi machine setups, that is valid. Doing so in the current installer would be non-trivial. However, I think having such a setup requires some serious effort to be supportable. I’m leaning to thinking that moving to a containerized setup would make more sense than trying to rewrite the installer to Ansible. In that case you may use tools like Terraform instead, depending on the preferred way to deploy containers.
I really appreciate this response. I’ve taken a look at forklift and foreman_spark. You’re correct in that forklift is not what I’m looking for. But foreman_spark is really close! In fact, despite the fact that the last commit was 3 years ago, I was still able to get it to work with a modest amount of updating. I’m still a ways away from getting it to build the machine exactly as I want it, but it’s a great start.
I think I’ll likely be able to convince the team to let me use the foreman-installer if I push hard enough.
