This is an authorized repost of https://www.netways.de/blog/2019/11/07/open-source-camp-on-foreman/
Like every year there was an Open Source Camp following the OSMC and as usual we helped organize that. Just in case you aren’t aware of what an Open Source Camp is here is the just of it: It’s meant to be an offer for Open Source projects to present themselves more in depth to the community. This year the Open Source Camp is on that one special yellow helmet we all know and love, Foreman.
Ondřej Ezr started us off with Ansible automation for Foreman (hosts). There are probably more than enough people using puppet only in their Foreman environment. Alternative or complementary to that would be using the plugin foreman_ansible. Ansible and Puppet don’t necessarily need to be better or worse, they are different and both have their advantages and disadvantages. By going through some basic steps, like role assignment, host creation and so on, he showed how one can do all that, but with Ansible. You can easily dynamically allocate roles and installations through Ansible to your Foreman hosts, but to make it even more specific one can set custom variables within the Ansible plugin for it to use, like foreman_repository_version. You could invoke a Job, like an Ansible Playbook, which will overwrite the variables previously set or make your installation more customizable from the get go. Install from git, run a playbook through ssh and more was covered during his talk. The plugin would not be a good alternative or viable if it did not hold up against the standards that puppet sets as a competitor. While Ansible doesn’t offer an inherit solution for reoccurring runs like every hour, the plugin does.
Next up was Bernhard Suttner, who wanted to give us a taste of Salted Foreman. Initially he explained what all that salt was about. The SaltStack a open source project written in python, can be used as a configuration management tool for Foreman. Salt excels at orchestrating cloud environments and network use-cases, but then we got to the Foreman relation. Running a salt and Foreman environment means running a environment of managed hosts, which are salt minions and a foreman_smart_proxy, which will also be the salt master. He showed us what salt in Foreman looks like and gave us some insight on how it works, but even more important from now on there are people dedicated to the project and some day the plugin might be as good as the puppet or ansible plugin. Salt is great and especially effective in terms of scalability. It’s pretty straightforward to use and the initial setup is not so hard. We are excited for what is to come.
Provisioning on Azure Cloud through Foreman by Aditi Puntambekar was going to follow that one. Aditi made sure everyone is familiar with the extend of Foremans capabilities in terms of provisioning. This was especially important because Foremans capabilities differ from its usual when it comes to cloud provisioning. After a quick trip through the configuration of compute resources and imaged-based provisioning templates we went onward to the Azure Resource Manager. She explained how the Azure Resource Manager essentially worked, but what is interesting to us is the foreman_azure_rm. Well and foreman_azure_rm does what you expect it to do. It adds the Microsoft Azure Resource Manager as a compute resource for the foreman. In her demo, she showed us how to use said resource and more.
Martin Bačovský talked about CLI tools with Foreman. He started of with the Foreman API. Of course the Foreman API is fast and has a wide range of tools and libs included within it. Just like Martin said in his talk, if you are interested in the Foreman API check out the documentation, it’s very good. Also interesting in the realm of APIs was his next tool, which is using apipie/apipy, which you are probably aware of if you are more heavy on the python side of things. Up there with the most well-known tools is Martins next, Hammer CLI, a command-line tool for Foreman. After sharing his experience with these rather popular tools with everyone he introduced us to Foreman’s integration of GraphQL. It’s basically a query language, which seems to be promising so far. Martin especially focused on the flexibility of queries and the introspective it has, yet one has to see where the project goes. There were many more tools he told us a lot about. To name just a few more of them, Report Templates, Foreman Ansible Modules and foreman_maintain. If you are interested in one of these tools in particular check out the video of the talk, which will be available soon on our Youtube Channel.
Give your Foreman a greater toolbox with Plugins by our very own Dirk Götz. Like he said himself: I will start of with existing toolbox things and at the end I will show you how to create these things yourself. And that he did. This talk was very demo heavy, thereby everything he explained was plain and simple, because you where able to see it as he did it. At the very top of his agenda was Job Invocation/Remote Execution. Not that exciting you think? Well, more interesting is the best practice advice he threw in on the way, like there is no issue of the configured user because his password is not saved as plain text in the database. Then the development part was up. He showed a couple of jobs that he wrote himself. Easiest, which served as an example is a simple ping check. He pointed out important thoughts to keep in mind, while writing jobs, like default values. Before his talk came to a close he talked a bit about the Web Console which has been introduced and is yet not well known. The web console is pretty much a integration of Cockpit. A well experienced user in the Linux world won’t be that excited about this, but a less experienced user will love this.
The next talk would not have happened, if Dirk didn’t spontaneously offer to step in. So we got another thirty minutes of Dirk Götz and I won’t complain. Katello: Adding content management to Foreman was the title and people where keen to hear about just that. What is Katello? Dirk described it as a defined set of Foreman plugins but not just that. It enriches your content management, as well as subscription management. Wait… content management? Why do I need that? Configuration management should be enough! Not necessarily, depending on your environment. Lets just pick up the points that Dirk made towards content management. For local content it ensures availability. For staging, it allows testing updates and makes builds reproducible. So content management should be seen as an addition to config management. He also talks about content views and how they are used to do the versioning, while they are being held by life cycles. Integration in orchestration was also a rather big point during his talk, which is done via SSH or Ansible. Dirk designs his talk in a way that makes summarizing them impossible, because he covers way to much. Lets just say not announced but very appreciated and most definitely worth checking out at our NETWAYS-Youtube Channel.
It was my second Open Source Camp and if you ask me this kind of exchange is what one wants to see in the open source community. There was variety and judging by the crowd reactions I was not the only one enjoying these talks. Thanks to all the speakers and attendees, safe travels home to everyone. Until the next Open Source Camp, hope to see you there!