Best Practice for Test/Dev Environments

Support
#1

I don’t know if anyone can comment on best practice for running a test/dev version of docker? Whether it be docker or something else.

I have been looking into running a test instance of foreman to connect to our test AD test the upgrade process before running through this on the live system. I’m keen to populate the system with much of the puppet classes and configuration that is in the live instance as I really want to get an idea of what might break during a Foreman update/upgrade.

I have tried restoring the live system to the test system with the foreman-maintain command but this is looking to restore the backups to a server with the same hostname. I’m getting the impression I’m not doing this in an advised way.

Thanks
James

#2

I am not sure to what extent this is an option for your pre existing setup, but if you really want to automate your Foreman instance you could look into provisioning both your environments using Ansible along with the Foreman Ansible collection.

Once this approach is fully implemented you could test any changes by adding them to your test environment first which would only differ from your production instance via a hand full of Ansible parameters. Once tested you can then add the same playbook changes to your production Ansible run.

This approach would require a certain initial investment.

I believe @evgeni has held various talks on automating Foreman with “Ansible operations”, perhaps he can add a link to one of the talks.

#3

Thanks for your response, I’m grateful for any suggestion as I feel I’m in the dark on this at the minute.

#4

Hey @jamboNum5!

I’ve recently gave a talk about this at FOSDEM: your management layer should be cattle too. The recording isn’t available yet (should be in the next days/weeks), but there are slides and a demo repository linked from the talk page and I can give a brief TL;DR version here:

  • use the same stack as your prod – if you’re running Foreman on CentOS7 in a VM in prod, try to do the same in your lab/test/dev.
  • keep your resource definitions (hostgroups, variables, etc) in a git-manageable file that you can re-play in every environment
  • we also building an operations collection right now, that is supposed to help with install/upgrade steps

Following that will allow you to have very similar environments, that hopefully behave the same. Obviously this is nothing you can do in a day, especially if you already have a prod setup that has had seen some changes over a longer period of time.

As for the actual upgrade testing: I’d verify that all features work using the standalone test environment, and then try an upgrade on a cloned prod VM, to see if the database can be properly migrated – as it will contain more data (reports, clients) than your test environment. If both are good, upgrade prod.

There are also older talks of mine linked on the Foreman Media page – some are in German, sorry.

3 Likes
How to configure foreman?
#5

Hi @evgeni thanks so much for putting this information together.

This seems like sound advice, I need to try to work out how that will fit in with our organisations managed CentOS service.

I have a separate dev VM that I have finally got round to building. The modules seem to be working ok so far, but I could do with bolstering that with git a little more to get that consistency you mentioned.

I’ll be sure to check some of your vids. Thanks again!

#6

The video of my talk is now up at FOSDEM - video recordings – enjoy :wink:

1 Like