Patching linux servers in Microsoft Azure



As part of our cloud migration we have to still manage a large number of traditional style machines (IaaS in new world terminology). These cover both windows and linux platforms - and actually in our case a mix of many different flavours of linux.

There are a number of ways to deal with patching - basically the exactly the same as you could do today on premise - the cloud doesn't change any of that. It does however add a new option by using some features of the OMS management platform (which can supposedly be made to work pointing back at on prem - so could make this an on prem management solution too).

In this post I'm just going to talk about the linux patching as the windows one will be slightly longer as i'm going to include some stuff on WSUS in that and I don't have time to write that up just yet.

So OMS (or Operational Management Suite to give it it's full name) is a 'product' that covers quite a lot of features and is touted by Microsoft to be the ideal tool to do most of your management. I'm not going to really talk about any of the other stuff i'm just going to go straight into the patching topic.

The first thing you need to do to make use of OMS is of course to enable OMS itself - i'm not going to cover that - it's just a case of finding the right screen and enabling it which i'm sure is possible for even the newest person to Azure.

Once the OMS portal is created for you - the next thing to do is enable the solution that deals specifically with patching - so navigate to the solution tile (shown below).


Once in the solutions screen you then need to choose this one

Once that's imported you'll have some new tiles but there will be no data being loaded. To enable the data to be gathered on the state of the patching (and to allow the patching to be done) you'll need to install the OMS agent. Strangely this is not available as an extension yet and you have to do it my other means - either manually or write your own scripts to add it

You can find the details of the manual process by going to the settings tile and then clicking through to the linux computer section - see pic below


So if you follow those steps you'll end up with the OMS agent uploading data into the OMS server which is then automatically reported on. Note that the OMS agent uploads to a public endpoint so your server needs to be able to reach that via normal internet routing or hairpinning or via some sort of web proxy - but the address has to be reachable.

After some period of time the data will be uploaded and if you navigate back to the updates tile you'll see something similar to this


Nice summary - and you can drill into this to see more details - you can also build your own custom tiles should you wish just based on OMS query language (which is kind of similar to SQL).

Now that's all well and good for reporting but what if we actually want to patch stuff - how do we go about that?

Well first up you need to enable it as it's a preview feature - so navigate to this screen and do that.


Once that is done we can schedule the updates from the tile in OMS




Then we click on the add button and fill in the details and click save


Then we can see it is scheduled



Then after some time we can see it completes and we can go and look into the details


Nice and easy - gives a nice central GUI to control all os patching rather than having multiple tools and a really nice reporting engine too.

However a few warnings

1) It may (depending on nature of patches) reboot the system - there is no warning of this....sample output below

Broadcast message from root@server(Mon 2017-07-10 08:11:14 UTC):

OMS Agent initiated shutdown after update.
The system is going down for reboot at Mon 2017-07-10 08:26:14 UTC!

2) there is no granularity of which patches to apply - it's all or nothing ( my guess is this will improve in the future).

3) When it doesn't work (i had a couple of problems initially just scheduling the patching) its hard to get a decent terror message out - one of the problem i had was a resource lock on the subscription level prevented a job from scheduling patching even though it was just a delete lock - very strange and hard to track down.

In summary it's quite a nice interface, though a little basic in places - i can see this will improve a lot over time to the point where it may truly be the only tool you need. For us for now we're using it but we're looking in to other tools to see how they compare.

The other thing to mention is the cost - this OMS 'pack' (or whatever the term is) is not cheap and is very overpriced i think for what you get currently (essentially the oms agent runs yum update - little more than that). This is something else Microsoft need to re-evaluate if they want to drive customers on to it.

Comments

Post a Comment