Auto Patch schedule with Satellite 6.3 and Ansible Tower Part 1

The Problem

When it comes to Satellite the flow to patch our life cycle environments feels like a very manual process, after our sync plan completes, I need to publish a new version and then promote this through my environments ( Dev, QA, Prod etc ) What I want is this to be fairly hands off and have it done in the background automatically for me. And so let’s go over the steps needed to achieve this.

Requirements. (What you need)

1.) Satellite server version 6.3 upwards

2.) Ansible Tower server

3.) Access to a Github

4.) Your own source control manager ( git, subversion etc… )

Setting up Satellite

The reason this is marked as Satellite 6.3+ is because prior there was a hammer cli that could help with this, but not anymore in 6.3 now we need to use the Katello-cvmanager, this does not come out of the box with Satellite, so we need to download it, I install this on my satellite server but this is not a hard requirement just note my steps are utilizing it on the satellite server.

1.) Get to a shell prompt on the satellite server and you need to have the optional repo and install a few dev packages first.

subscription-manager repos  --enable rhel-7-server-optional-rpms
yum install make automake gcc gcc-c++ kernel-devel ruby-devel

2.) Download katello go into /var and run

# git clone https://github.com/RedHatSatellite/katello-cvmanager.git

3.) Now cd into katello-cvmanager directory and run cvmanager you should get the following output

./cvmanager
Usage: cvmanager ACTION [options]

ACTION can be any of [clean,update,publish,promote]
-U, --uri=URI URI to the Satellite
-t, --timeout=TIMEOUT Timeout value in seconds for any API calls. -1 means never timeout
-u, --user=USER User to log in to Satellite
-p, --pass=PASS Password to log in to Satellite
-o, --organization-id=ID ID of the Organization to manage CVs in
-k, --keep=NUM how many unused versions should be kept
-c, --config=FILE configuration in YAML format
-lID, which LE should the promote be done to
--to-lifecycle-environment
-d, --description=STRING Description to use for publish operations
-n, --noop do not actually execute anything
-f, --force force actions that otherwise would have been skipped
--wait wait for started tasks to finish
--sequential [NUM] wait for each (or NUM) started task(s) to finish before starting the next one
--checkrepos check repository content was changed before publish
--verbose Get verbose logs from cvmanager
--no-verify-ssl don't verify SSL certs

If you get the following error then you need to build the gemspec file

./cvmanager 
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- apipie-bindings (LoadError)
    from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
    from ./cvmanager:20:in `<main>'

by doing this

# gem build cvmanager.gemspec

The output will tell you which version of the gem got built

gem build cvmanager.gemspec 
WARNING: licenses is empty
WARNING: no description specified
WARNING: no summary specified
WARNING: description and summary are identical
Successfully built RubyGem
Name: cvmanager
Version: 0.2
File: cvmanager-0.2.gem

Currently cvmanager version 0.2 got built and so we want to install the file it created for us.

# gem install cvmanager-0.2.gem

Now you can run katello-cvmanager.

The Next step is to create some yaml configuration files, the first one we need is our publish configuration, this will check to see if there is new packages, available since the last sync and if so publish a new version into Library and if not skip it.

Create a file called publish.yml and we need to add the following contents to it

---
:settings:
  :user: user
  :pass: password
  :uri: https://sat.example.com
  :timeout: 300
  :org: 1
  :lifecycle: 1
  :keep: 1
  :promote_cvs: true
  :checkrepos: true
:publish:
  - Contentview_name_1
  - Contentview_name_2

We can see that :settings: and :publish: are parents and then the various below are indented by 2 spaces, you do need to put in a username and password here for any security concerns there are 2 options which would be to set this to 0400 or you could have Ansible generate it from a template when it runs and use vault.

For Publish you will specify the content view names in a list and then when this runs it will check the repositories assigned to the content views and if there are updated packaged then it will publish a new version to life cycle i.d 1 which is Library.

Next we need to create a yml file for each of the life cycle environments, lets say for example you have a Content view called RHEL7 and inside here you created environments of dev, qa and prod, you will want to create 3 yml files “rhel7dev,yml rhel7qa,yml and rhel7prod,yml” You need to know the lifecycle id number this can be found by going into the lifecycle on satellite and the url will show you the id reference

lifecycle_url

We can see here for my RHEL8_DEV lifecycle environment the id is 2

so rhel7dev.yml would look like this

---
:settings:
  :user: user
  :pass: password
  :uri: https://sat.example.com
  :timeout: 300
  :org: 1
  :lifecycle: 2
  :keep: 1
  :promote_cvs: true
  :checkrepos: true
:cv:
  RHEL7: latest
:promote:
  - RHEL7

And a rhel7qa.yml would look the same with the exception of the lifecycle number changing like so.

---
:settings:
  :user: user
  :pass: password
  :uri: https://sat.example.com
  :timeout: 300
  :org: 1
  :lifecycle: 3
  :keep: 1
  :promote_cvs: true
  :checkrepos: true
:cv:
  RHEL7: latest
:promote:
  - RHEL7

So now we have our Publish and Promote configuration files set we should run an initial test manually to confirm they are good.

On the server you want to run the following command to publish a new version

./cvmanager --config=publish.yml --wait publish

If there are new packages from the last sync to the current published version you will see it publish a new version if not you will get a message like so

Inspecting RHEL7 as listed in CSV
repo Red_Hat_Enterprise_Linux_7_Server_RPMs_x86_64_7Server (id: 2) seems newer than CV RHEL7 (id: 2), checking if sync contains new packages.
'No new packages.' Found in last sync task, will search now for past sync tasks for packages not in the CV.

This is good as it shows we wont be just generating new published versions unless there are new packages available.

Next you want to promote a lifecycle to the latest published version we can test this by running the following.

./cvmanager --config=rhel7dev.yml --wait promote

You will see a promotion go through if there is a latest version to promote to with an output like this

Inspecting RHEL7
Promoting latest version to lifecycle-environment 2
waiting 10 for pending tasks: ["772f8a23-e5d1-4109-894d-39bb407e84d3"]
waiting 20 for pending tasks: ["772f8a23-e5d1-4109-894d-39bb407e84d3"]
waiting 10 for pending tasks: ["772f8a23-e5d1-4109-894d-39bb407e84d3"]

[root@satellite katello-cvmanager]#

So at this point we know we are good with our configurations and can proceed onto Ansible Setup.

Leave a Reply

Your email address will not be published. Required fields are marked *