This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
I had a customer recently ask about how to leverage the Azure Update Management Center (UMC) preview offering to update their own in-house software deployments on running Linux VMs. There’s a few different discussions that can come out of that question, including questions around whether or not they actually should be doing that long-term vs. using a CD pipeline in a modern DevOps fashion, but I thought it was an interesting to show a bit of what’s happening with the UMC under the covers a bit. This article shows an end-to-end demo of using UMC with a custom software package.
Basic Infrastructure Setup
This post is focusing on the details of the update side, so I’m not going to deep dive on the basic VM creation process. For the purposes of this demo, I’m using a Linux Generation 1 VM running Canonical Ubuntu Server version 18.04-LTS, which (as of August, 2022) is on the supported OS list.
Sample Package Setup
I wanted a custom package that I could reference, but I didn’t want to be caught up in the details of that. Ultimately, it’s on the customer to manage the packaging of their solution for basic OS update integration, of course, but to demonstrate the functionality, I needed something. I followed a lightly modified version of the instructions at https://linuxconfig.org/easy-way-to-create-a-debian-package-and-local-package-repository to create a simple file structure:
The file “hello” is just a simple Bourne Again Shell script:
And the DEBIAN/control file is just a text file with basic package metadata:
I then built the package:
I then followed the steps in that blog post to create the local repository and move the file in (I won’t repeat those steps here), and then added the repository to /etc/apt/sources.list, although I did it a little differently in that I used http://127.0.0.1/debian as the source instead of the machine’s IP address, just because I was being lazy and didn’t want to have to worry about the IP.
I then updated apt’s local copy of the package information and installed the package – notice the local repository is listed:
I then installed the app and made sure it runs:
I then copied the 1.0.1 folder to a 2.0.1 folder, updated the script to have the new version number, and built a new package – this was following the same basic pattern as above. I then copied the helloworld_2.0-1_amd64.deb file into the /var/www/html/debian folder, and rebuilt the Packages.gz file. Critically though, I made sure to include the --multiversion option, so that both versions would be in the Packages.gz file, otherwise only the newest one would be in the file. That’s not important for this demo, but you’d want this to be able to demo again on this machine in the future, so that you can install the 1.0.1 version again if desired...
I then asked for my upgradable package list, and my 2.0.1 package was now there:
Notice that the helloworld/unknown package shows as upgradable from 1.0.1.
Updating in the Update Management Center
Cool, so now that I had that out there, it was time to go look at the Updates view in the Portal. The original view looks like this:
The “Update Management Center” is the next generation interface for dealing with this kind of thing. The whole goal of this post is now coming up. Going to the “Update Management Center” through either of the two buttons (one at the top of the right-hand pane, one in the middle of that pane), there was no data out there:
The “Check for updates” button at the top allows running the assessment on the VM. If the assessment was doing something unusual relative to the OS, or working off of some kind of Microsoft-maintained “master update list”, or anything along those lines, the custom “helloworld” package wouldn’t appear. But, after a couple of minutes or so, a notification appeared, and the list of updates available on the machine showed up – and that included the custom package:
The “One-time update” button allowed for applying updates on the VM:
After a little while, the update completed, and I was able to see my new updated version was on the machine:
And there it is!
Conclusion
So, to summarize, the point of this was to show that the Azure Update Management Center is just leveraging the standard update system on the OS to track and deploy updates. There's no special magic or secret sauce. This means that if you’re a software developer, if you leverage the facilities of the OS that you’re developing on, you’ll be integrated with the Azure Update Center with no extra effort on your part, and that’s a pretty great outcome. If you're an OS administrator, and your vendors play nice with the OS, you get this integration, too!