GB2621140A - Configuration management system - Google Patents

Abstract

A computer-implemented method for performing configuration management for managed computing nodes of an IT system. Inventory information for the IT system is stored in an inventory database 102 of a configuration management system, the information identifying a plurality of managed computing nodes in the IT system 116a-116c and a plurality of software services 116a-116d provided on the managed computing nodes. Entitlement information 104 is associated with the software services, identifying, for a given software service, one or more users of the configuration management system entitled to perform configuration management tasks in respect of the given software service. A configuration management application 100 is provided that enables a user to specify a configuration management task (e.g. deploying a software update or patch) to be performed for a selected software service at a selected computing node. The application restricts the specification of configuration management tasks by the user based on entitlements defined for the user in the entitlement information. A configuration subsystem is then invoked to initiate the specified configuration management task at the selected computing node.

Description

Configuration management system The present invention relates to systems and methods for managing configuration changes to computing nodes in information technology (IT) infrastructures.

As IT infrastructures and computer networks grow, configuration management becomes increasingly challenging and complex. Large organisations may deploy hundreds or even thousands of servers, running a multitude of services and applications. A key task in configuration management is the installation of software 1 0 updates or "patches". Such updates may occur relatively frequently and may address performance issues, security vulnerabilities or functionality changes. Keeping software up to date across large heterogeneous device populations is challenging and typically the responsibility of a team of operations engineers who are responsible for the smooth and efficient operation of the IT infrastructure. These specialists are generally trusted to understand the IT infrastructure and carry out software updates and other configuration management tasks and may have access to configuration management tools supporting some degree of automation to implement configuration changes.

On the other hand, responsibility for the applications and services themselves may often lie with development teams. However, since the developers are generally only familiar with their own services and applications and may not have a full understanding of an organisation's IT infrastructure, they are usually not trusted to perform the necessary configuration management tasks themselves. For example, a user not familiar with the full deployed IT infrastructure may easily select the wrong server from the hundreds or thousands in the network for deployment of a software patch or other configuration change. To guard against this and other configuration errors, the development teams that are actually responsible for services and applications (referred to as the service owners) will often not be given access to the configuration management tools and are instead required to submit change requests to the operations team and then wait for the operations team to carry out the requested changes, often resulting in slow turnaround. This can delay deployment of software updates and other configuration changes. In the case of security fixes, this can also leave systems vulnerable to security risks. 3 5

Embodiments of the invention aim to address some of the drawbacks of known approaches to IT infrastructure configuration management.

Accordingly, in a first aspect of the invention, there is provided a computer-implemented method performed in a configuration management system for performing configuration management for managed computing nodes of an IT (information technology) system, comprising: storing in an inventory database inventory information for the IT system, the inventory information identifying: a plurality of managed computing nodes in the IT system; and a plurality of software services provided on the managed computing nodes; associating entitlement information with the software services, wherein the entitlement information identifies, for a given (or each) software service, one or more users of the configuration management system entitled to perform configuration management tasks in respect of the given software service; providing a configuration management application arranged to enable a user to specify a configuration management task to be performed for a selected software service at a selected computing node, wherein the configuration management application restricts the specification of configuration management tasks by the user based on one or more entitlements defined for the user in the entitlement information; and invoking a configuration subsystem to initiate the specified configuration management task at the selected computing node The use of entitlement information linked to services defined in an inventory can allow users to be given access to perform configuration only for services and associated computing nodes that are relevant to them (e.g. for which a user is identified as service owner) and thus reduces the risk of configuration errors. This in turn allows configuration management to be performed directly by the service owners rather than the operations specialists looking after the wider IT infrastructure, providing, in essence, a self-service configuration management solution for service owners and improving configuration management efficiency.

The specified configuration management task may comprise one of: installation of a software update (patch) for the selected software service deployed on the selected computing node; and installation or renewal of a security certificate, optionally a Secure Sockets Layer (SSL) certificate or other cryptographic / security certificate, at the selected computing node. However, the described system can be used for any type of configuration management task.

The configuration management application preferably allows a user to specify a configuration management task only in respect of a service for which the user is entitled according to the entitlement information. More specifically, the configuration management application preferably allows a user to specify a configuration management task only in respect of one or more computing nodes associated in the inventory database with a service for which the user is entitled according to the entitlement information.

The method preferably comprises, by the configuration management application: identifying one or more of the plurality of services and/or one or more of the managed computing nodes for which the given user may initiate configuration management tasks based on the entitlement information; and restricting the user to specification of configuration management tasks only in relation to the identified services and/or computing nodes, for example by making only those services/nodes available for selection in an interface of the application.

The inventory information preferably associates a given service with one or more computing nodes that have software deployed for implementing the service (e.g. by associating computing nodes with service identifiers of one or more services deployed on the nodes) Preferably, the entitlement information defines service owner entitlements, each service owner entitlement identifying a given user of the configuration management system as a service owner of a given one of the software services and indicating an entitlement of the given user to perform configuration management tasks in respect of the given software service.

The entitlement information may further define delegation of entitlements from a given user to one or more other users. Preferably, the entitlement information identifies, for a given delegating user, preferably a user identified as a service owner of one or more services, at least one further user as a delegate user, wherein the delegate user(s) inherit one or more entitlements (optionally all entitlements) from the delegating user. The delegate user(s) are then preferably entitled to perform configuration management tasks in respect of one or more services for which the -4 -delegating user is entitled according to the entitlement information, preferably for one or more or each of the services for which the delegating user is identified as service owner.

The configuration application preferably restricts a user to enable the user to specify and/or initiate configuration management tasks only in respect of a service (or a computing node associated with a service) for which the user is identified as a service owner or delegate of the service owner.

The method may comprise, by the configuration management application: identifying a user of the configuration management system, the identifying step optionally comprising authenticating the user; identifying based on the inventory database and entitlement information, one or more services for which the identified user is entitled; and making the identified one or more services available for selection by the user in the application. The method may then further comprise identifying one or more computing nodes associated in the inventory database with the identified services and restricting a user to initiate configuration tasks only in relation to the identified computing nodes.

The method may comprise receiving a selection of one of the identified services from the user; identifying one or more computing nodes associated in the inventory database with the identified services; and making the identified one or more computing nodes available for selection by the user in the application to enable specification by the user of a configuration management task for a selected one of the identified computing nodes. Thus, the user interface of the application preferably only makes available for selection by the user services and computing nodes that are available to the user according to the entitlement information (including service owner entitlements and, if applicable, delegated entitlements).

Computing nodes may be associated with one or more classification attributes in the inventory database, each classification attribute defining a plurality of classes of computing nodes, the method comprising providing a selection interface for receiving a selection of a class of computing node from the user for one or more of the classification attributes.

The classes specified by the user for the classification attributes may be used to filter the computing nodes made available for selection (from those associated with a -5 -selected service). For example, the identifying step may include identifying one or more computing nodes associated in the inventory database with the selected service and the selected computing node classes, the method comprising making only the identified computing nodes matching the selected classes available for selection by the user when specifying a configuration management task to be performed on a computing node.

The one or more classification attributes may comprise one or more of: a technology classification attribute indicating one of a plurality of classes of software environment deployed on a computing node, optionally wherein the technology classification includes classes corresponding to one or more operating systems, middleware systems and/or database management systems provided on computing nodes; and an environment classification identifying one of a plurality of classes of usage environments or usage contexts of a computing node, optionally wherein the plurality of classes include one or more of: a production environment, a contingency environment, a development environment and a test environment. The method then preferably comprises restricting selection of a computing node by the user based on the technology and environment classes selected by the user for the selected service. The technology class (or another classification attribute) could alternatively or additionally identify a hardware type of a computing node.

Preferably, the method further comprises receiving a selection of one of the identified computing nodes from the user; receiving specification information defining a configuration management task to be performed for the selecting computing node; and invoking the configuration subsystem to configure the selected computing node based on the specification information. In one example, the configuration management task comprises a software update task, the specification information specifying a software update to be installed on the computing node (e.g. selected from multiple available software updates).

The specification information may comprise schedule information indicating a time at which the configuration management task is to be performed, the method comprising invoking or configuring the configuration subsystem to perform the specified configuration management task at the indicated time.

The method may further comprise monitoring an outcome of the configuration management task and notifying the user of the outcome. Monitoring may include -6 -determining whether a computing node has returned to operation following installation of a software update.

Computing nodes may comprise physical and/or virtual computing nodes, optionally including one or more physical servers and/or one or more virtual servers or virtual machines. More generally, a computing node may be any form of physical or virtual computing entity providing a software execution environment for executing software, e.g. to implement software services and applications. The IT system may comprise any IT infrastructure within which such computing nodes (including, if applicable, physical devices supporting virtual computing nodes) are deployed, e.g. a local or private network of computing nodes, a distributed network, e.g. involving private and/or cloud-based computing nodes, a data centre etc. The computing nodes may comprise one or both of: on-premise computing nodes provided within a network of an organisation operating the configuration management system; and cloud computing nodes provided via a public network (e.g. the Internet) by a cloud computing provider. Invoking a configuration subsystem to perform a configuration management task for a computing node may then comprise selecting an on-premise configuration subsystem or a cloud configuration subsystem depending on the type of computing node and invoking the selected configuration subsystem. Thus, on-premise and cloud configuration may be supported within a single configuration management application.

In a further aspect of the invention, there is provided a configuration management system for performing configuration management for managed computing nodes of an IT system, comprising: a database configured to store: inventory information for the IT system, the inventory information identifying a plurality of managed computing nodes in the IT system and a plurality of software services provided on the managed computing nodes; entitlement information associated with the software services, wherein the entitlement information identifies, for a given software service, one or more users of the configuration management system entitled to perform configuration management tasks in respect of the given software service; a configuration management application arranged to enable a user to specify a configuration management task to be performed for a selected software service at a selected computing node, wherein the configuration management application -7 -restricts the specification of configuration management tasks by the user based on one or more entitlements defined for the user in the entitlement information; and a configuration subsystem configured to initiate the specified configuration management task at the selected computing node.

The system may further be configured to perform any method as set out above.

More generally, the invention also provides a system having means, optionally comprising one or more processor(s) with associated memory, for performing any method as set out herein, and a computer program, computer program product or non-transitory computer readable medium comprising software code adapted, when executed by a data processing system, to perform any method as set out herein.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus and computer program aspects, and vice versa.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 illustrates a configuration management system in overview; Figure 2 illustrates associations between service owners, services and computing nodes; Figure 3 illustrates a process for a user to configure a software update for a computing node; Figure 4 illustrates a user interface of a configuration management application for use in the Figure 3 process; Figure 5 illustrates user entitlements used by the application to restrict configuration management options; Figure 6 illustrates a data model used by the application and associated information flows; -8 -Figure 7A and 7B illustrate on-premise and cloud-based configuration automation architectures; Figure 8 illustrates a detailed end-to-end flow example for defining and executing a software update operation; and Figure 9 illustrates an application server for running the configuration management application.

Embodiments of the invention provide a self-service configuration management system that allows service owners to check the configuration status (e.g. patch status) of their servers and make configuration changes. The system is also referred to as the SELFIE (Self Infrastructure Engineering) system. Described embodiments support the following types of configuration management tasks: * Installation of software updates / patches, e.g. for security fixes * Installation / renewal of certificates, e.g. Secure Sockets Layer (SSL) certificates or other security or cryptographic certificates However, the SELFIE system can be extended to support other forms of configuration management, for example: * middleware setup or configuration; * application setup / configuration; * database schema creations; * other database operations; * system / application restarts; * network health-check operations etc. The system is preferably configurable to support various kinds of configuration tasks, including bespoke configuration tasks relating to any aspect of configuration required for specific applications, middleware, operating system components or other systems.

Configuration tasks themselves (e.g. patch installation) are automated via various existing automation tools. However, the described system extends existing techniques by integrating the automation of the various types of configuration tasks into a single configuration management application. The application operates based on an inventory of managed computing nodes, in particular servers, to provide a self-service configuration management solution that can be used by service owners -9 -themselves (e.g. developers) rather than operational management specialists, whilst restricting configuration management to those parts of the IT infrastructure that are relevant to the user.

The configuration management system is illustrated in overview in Figure 1. The system includes a configuration management application 100 which is used to manage configurations of any number of servers 116a-116c via a communications network 110. Each server may run one or more applications or services 118a-118d. The term "service" as used herein refers to any logical collection of software funcfionalities that cooperate to provide a service (or collection of related services) to users. For example, a service may correspond to a particular application, or to a group of related applications. In some cases services may also be constituents of other services / applications. A "service" may be implemented by software components running on a computing node (e.g. a server) or distributed over multiple computing nodes. For example, a service may consist of a database server and a web application back-end providing access to data in the database which could run on the same server or different servers. More generally, a service designates a collection of software components that are managed as a unit from the perspective of the configuration management system. Examples of services could include, for example, a media streaming service, an online storefront application, an Internet banking application, a travel booking service etc. A client device 106 can connect over the network to the configuration management application 100 to view configuration management information and initiate configuration management tasks, such as scheduling installation of a server patch.

The client device may be a conventional personal computer or mobile computing/communications device, e.g. a PC/laptop, tablet computer or smartphone. The configuration management application may be in the form of a web application with an application back-end running on a central server 105 and a web front-end running in a web browser 107 on the client device 106 and communicating with the back-end over the network 110 (e.g. including an intranet or the public Internet). However, instead of a web application, a bespoke native application could be provided on the client device to interact with a corresponding server-side process.

The configuration management application 100 includes, or is connected to, a data store 101 including a configuration management database 102. This stores an inventory of the managed computing nodes in the network and the services deployed on those computing nodes. The data store further includes user and entitlement data 104 which includes information about the users of the configuration managing application and specifies entitlement information linking service owners to services and computing nodes as described in more detail later.

Managed servers 116a-116c may be physical computing nodes (e.g. physical servers) or virtual computing nodes (e.g. virtual machines running on underlying physical devices using a hypervisor). Each physical or virtual server runs an operating system along with software components implementing one or more applications or services 118a-118d. A given service may be deployed on a single server or may involve components on multiple servers (e.g. application 118a and 118b on servers 116a, 116b could form part of a single service).

Managed servers may include on-premise servers, e.g. installed within a data centre or wider network of an organisation running the configuration management system.

Managed servers may also include cloud-based servers, e.g. servers provided on-demand by cloud platform providers (such as Amazon Web Services (AWS)TM or Microsoft AzureTM) to run the organisation's applications and services. Typically, such servers are virtual machines which can be instantiated and scaled as needed on the cloud platform and accessed via the public Internet.

Configuration management application 100 supports configuration management in both contexts (on-premise and cloud-based) via different configuration automation layers. In particular, the system may comprise an on-premise configuration manager 112 for automating configuration tasks, such as patch deployment, for on-premise servers, and a cloud configuration manager 114 for automating configuration tasks for cloud servers.

Note that while reference is made generally herein to management of (physical or virtual) servers, the configuration management system may support management of any types of computing nodes or other IT resources, including hardware devices, virtual devices and software entities (for example network routers and switches, storage devices etc). Furthermore, while Figure 1 shows the system as predominantly managing services/applications running on the servers, the techniques may extend to managing other software components on the servers, such as operating systems and hypervisors.

As a given service may be associated with multiple managed computing nodes, e.g. multiple servers, the CMDB supports a hierarchical model for representing relationships between services and the computing nodes on which those services are deployed. An example is illustrated in Figure 2. In this approach, managed computing nodes such as servers associated with a service may be assigned to various technology and environment classes.

In particular, a "technology" classification in this model may include, for example, different device/server classes. In the present example, a technology class "UNIX" 202 is defined, e.g. for general purpose application servers, web servers or the like using a UNIXTM based operating system. A further technology class "ORACLE" 204 is defined, e.g. for database servers using an OracleTM database management system. Technology class "WAS" 205 corresponds to a WebSphereTM Application Server. Technology classes may thus define different general classes of server as well as different software platforms or software environments deployed on servers (e.g. operating system, middleware and/or database environments). Technology classes could also be used to define different types of computing node hardware.

The "environment" dimension classifies managed computing nodes depending on usage/operational context. In this example, a "PRODUCTION" environment 206 is defined for a production server, i.e. one used to provide live services to users, while a "CONTINGENCY" environment 208 is defined for backup or standby servers available in case the production server(s) fail or are overloaded. Additional environments could be defined, e.g. a development environment (for active software development for a service or application) and a test environment for testing.

Note the specific classes shown here are purely by way of example, and the technology and environment classes may be adapted as needed for the managed IT infrastructure. Furthermore, not all available classes may be relevant to all services.

At the bottom level of the hierarchy are the managed computing nodes, e.g. servers. In this case, servers 210 and 212 are shown. These are the servers associated with the production environment 206, for technology class 204 "ORACLE", for this particular service 200. Note that the example hierarchy of Figure 2 is not shown in full -for example, there may typically be other managed computing nodes associated with the contingency environment 208 and yet further environments and computing nodes associated with technology classes 202 and 205. A given complex service -12 -may involve a number of computing nodes across the technology and environment dimensions.

The configuration management database may store services using a hierarchical structure as depicted. Alternatively, a flat structure may be used, for example with service identifiers, technology classes and environment classes stored as attributes of the managed computing nodes in the CMDB 102. Regardless of the internal representation, the depicted logical hierarchy may be used to constrain the server selection by the user to allow the user to efficiently identify the correct server for which a configuration task is to be performed.

As shown, a service is also linked in the database with a service owner 220. The service owner is a user of the configuration management application who is designated as "owner" of the service, indicating that the user is authorised to manage the configuration of the service. An association between a service owner 220 and a service 200 defines an entitlement 222 for that user to perform configuration tasks for that service and its associated servers. A given user may have entitlements defined for any number of services. The configuration management application uses the defined entitlements to restrict the options made available to users when defining configuration tasks that are to be performed so that users can only initiate configuration tasks for services (and their associated computing nodes) for which the user has an entitlement defined.

As shown in the Figure 2 example, in preferred embodiments the entitlement is defined at the service level -indicating that the service owner is entitled to perform configuration tasks for any technology classes, environments, and managed computing nodes associated with that service. However, in other embodiments this could be extended to allow more granular entitlements to be defined. For example, an entitlement could be defined with respect to any component of the hierarchy -e.g. for a particular technology class of a given service, or a particular deployment environment, or even a specific managed computing node.

Figure 3 illustrates a process for self-service configuration management using the configuration management application. In this example, the user is using the application to schedule installation of a software update on a server (but a similar process may be used for other configuration management tasks).

The process starts in step 302, with the user accessing the application and logging into the system by providing authentication credentials (e.g. username and password). The user is identified and authenticated as a user of the system. If authentication is unsuccessful, access to the application is denied. Assuming authentication is successful (e.g. authentication credentials match those stored by the system), in step 304, the system identifies from the CMDB 102 and entitlement information 104 those services for which the authenticated user is entitled to perform configuration management, e.g. those services where the user is identified as service owner. The available services are presented to the user e.g. as a drop-down list.

Other services (for which the user is not entitled according to the entitlement information) are not shown or not made available for selection by the user.

The user selects the service for which software patching is to be performed from the options provided in step 306. The user then further identifies the technology class (e.g. UNIX / ORACLE / WAS etc.) and the environment (e.g. PRODUCTION / CONTINGENCY etc.) from the options available for that service in step 308. The system then identifies the available computing nodes, e.g. servers, associated with that combination of service, technology class and environment and displays these e.g. as a list or selection drop-down (310). The current patch status of each server may also be shown (e.g. as a currently installed software version number or patch level).

The user then selects the server to be patched in step 312 from the options provided. In some cases, multiple alternative patches may be available in which case the user can also select the patch to apply.

In step 314 the user specifies a date/time at which the software patch should be installed. At step 316 the system then schedules the patching operation for the chosen server at the specified date/time. For example, the system may maintain a schedule of patching operations that are to be performed as a table in the CMDB and may add the scheduled patching operation to the table. Alternatively, the patching process itself may be under control of a separate configuration manager (e.g. one of the configuration managers 112, 114 of Figure 1), in which case the scheduling step may involve sending the information defining the server to be patched, patch to be applied, and scheduled time to the relevant configuration manager to schedule the patching operation.

In step 318, the system then performs the scheduled patching operation at the scheduled time. This step may be initiated by the configuration management application, with the patch automation performed at the relevant configuration manager 112/114. Alternatively, patch application may be performed entirely by the relevant configuration manager.

The patching operation may, for example, including downloading an installer to the target computing node, running the installer (if necessary suspending/terminating the software service first) and then restarting the service and performing any necessary clean-up operations. These steps are automated by the configuration managers 112/114, for example using installation scripts.

Figure 4 shows an example of a configuration management interface provided to the user by the application after successful authentication. This includes a drop-down selection list 402 of the services for which the authenticated user is identified as service owner in the database. Note only those services for which the user is service owner and thus has a management entitlement will be shown. Other services will not be displayed and are not available for selection by the user.

The interface further provides selection fields 404 and 406 for selecting technology class and deployment environment class and a server selection drop down list 408 for selecting the server to patch. Note that the listed servers are associated with the specific service chosen in field 402, and so the user is only able to select servers for that service. Furthermore, since the user is restricted by their entitlements to access only services for which they are service owner, this means they can ultimately only see and select the servers on which those services are deployed and is not able to perform patching operations for any other servers in the IT infrastructure.

Once the server is selected, a further drop-down list 410 shows patch versions available for installation on that server. This information is configured by administrators when new patches are made available. The system could additionally display the current software / patch version for the server (e.g. as part of the server description in list 408).

The interface further includes entry fields 412 for specifying the date and time at which the patch is to be deployed and additional information fields 414 (e.g. allowing the user to specify a change request number or provide an email address to which -b -messages are to be sent to confirm successful patch deployment or alert the user if there are problems with installing the patch). Once all the necessary information has been specified the user then clicks the "submit" button 416, resulting in the software update being scheduled by the configuration management system based on the details provided.

The approach described above may be used to schedule patching operations for both on-premises servers and cloud-based servers. Additionally, a similar process is implemented to manage SSL certificate updates. In that case the system identifies services for which the user is service owner and allows the user to select the associated servers as previously described. The user is then presented with the current SSL certificate status (e.g. expiry date) and can then choose to schedule a certificate update. The certificate update functionality may, for example, be used for web servers, application serves and/or database servers.

In an alternative flow, the system may also automatically identify any SSL certificates associated with the servers corresponding to the services for which the user is service owner and that are close to expiring (or have expired) and then presents a list of the relevant servers. The user then selects the required server from the list and schedules the SSL certificate renewal.

In some cases, rather than scheduling a configuration management task such as patch installation or certificate renewal for a future time the user may be given the option of initiating the task immediately on submission.

The above process describes configuration management based on entitlements, whereby a user can only view and select services for which they are identified as servicer owner and can thus only perform configuration management for the servers associated with those services. In preferred embodiments, this concept is extended to support delegated entitlements.

In this approach, a service owner can identify one or more other users as their delegates. The delegate(s) then inherit any entitlements of the service owner. As a result, both the service owner and their delegate(s) are able to view and select services (and associated servers) of the service owner. This is illustrated in Figure 5.

Figure 5 illustrates by way of example user identities of two users 502 and 504 defined in the system. The database identifies the first user 502 as the service owner for a number of services 506a-506c, defining respective entitlements for the user to perform configuration management for those services (and hence for the servers associated with those services).

Additionally, the first, delegating, user has designated a second user 504 as a delegate. This may be identified, e.g. by way of a delegate attribute (or foreign key) specifying a user identifier of the delegated user in the delegating user's database entry. Alternatively, to support multiple delegates for a given user, a separate mapping table could be provided linking delegating users to delegated users.

As a result of the delegate status, the second user 504 inherits the entitlements of the service owner. Note that a user may (but need not have) both delegated entitlements and ordinary entitlements, e.g. where a user is service owner for some services (e.g. service 508) and a delegate for others. Furthermore, the system may support multiple layers of delegation (e.g. this could allow the second user to appoint one or more sub-delegates who could inherit both the ordinary entitlements and the delegated entitlements from that user in turn).

The Figure 3 process may be modified as followed to support delegate entitlements. After a user logs in to the configuration management application, the system identifies any users for which the authenticated user is specified as a delegate. The user is then presented with a profile selection interface, where they can select either their own profile or a delegated profile. Each delegated profile corresponds to another user who has designated the authenticated user as delegate. If the authenticated user selects their own profile, the process continues as described, with the user given access to those services for which they are identified as the service owner. If the user selects a delegated profile corresponding to another user who has designated the authenticated user as a delegate, then the process continues as described, except the user can now only view and interact with services (and their associated servers) of the selected delegating service owner. Thus, the user essentially interacts with the application interface as if they were the delegating service owner and can perform configuration management (e.g patch scheduling) for any services (and associated server) of the delegating service owner.

For example, in the Figure 5 example, if the second user 504 logs into the system they would be presented with two profiles. One profile corresponds to the services for which they are the service owner (in this case service 508) and the interface is restricted to those services for which the user has direct entitlement as service owner. The second profile corresponds to the services owned by the first user 502 for which user 504 is designated as delegate. When selecting the second profile the interface is then restricted to the delegated entitlements, i.e. the services 506a-506c owned by the delegating service owner 502 (and this profile would thus not include service 508). When user 502 logs into the system, on the other hand, they would only have access to a single profile, corresponding to services 506a-506c for which they are the service owner and hence directly entitled (since delegation is one-way).

Note one user can designate multiple delegates, and a given user can be a delegate for multiple service owners (and thus may be able to choose from multiple profiles corresponding to respective delegating service owners).

As an alternative to the profile-based approach, the system could instead provide access to the user to both owned and delegated services within the interface. Using this approach, in step 304 of Figure 3, in addition to identifying those services for which the current user has direct entitlements as service owner, the system additionally identifies any services for which the user holds delegated entitlements -that is, any services whose service owner has identified the current user as a delegate. This then allows the user to perform configuration management tasks for those delegated services (as well as their own).

The entitlement-based approach using delegation provides security and flexibility, since configuration management for a given service (and its associated servers) is restricted in general to the service owner, but the service owner has the option of specifically appointing one or more delegate users, to ensure that patches or other configuration changes can be scheduled and applied in a timely manner without being entirely reliant on the service owner.

In the described example, delegation from a service oner is for all entitlements associated with that service owner and entitlement is defined per service. Thus, when a user delegates entitlements to another user, the other user obtains access to all services (and associated computing nodes) for which the delegating user is the service owner. However, the system could be extended to support more granular delegation. For example, in an alternative implementation, a service owner could delegate on a per-service basis (by delegating entitlements for one or more selected services to another user). In other examples delegation could even be for specific technology/environment classes or specific computing nodes within a service.

Note that while the service owner of a service has the entitlement to perform configuration management operations for all computing nodes associated with the service, it is possible that multiple services could be deployed on the same computing node and those could have different service owners. As a result, different service owners could have entitlements permitting configuration management in the relation to the same computing node, though each service owner would then only be able to initiate configuration management tasks in relation to that computing node for the service of which they are the owner (and thus would only be able to patch software components associated with that service).

Furthermore, the system could additionally define host/server level entitlements, e.g. providing separate entitlements for patching operating systems / hypervisor software on a server, in addition to any entitlements relating to services and applications deployed on the server.

The selections and options presented to the user are dependent on the defined entitlements and the inventory information in the CMDB. Specifically, only services owned by the user (or for which the user is acting as a delegate authorised by the service owner) are made available to the user for selection in the Figure 4 interface.

Subsequent selections are constrained by the previous choices and the inventory information. For example, once the user selects a service, the system identifies "technology" and "environment" options available for that service and restricts selection options accordingly (e.g. by displaying only the options available for the service or greying out unavailable options). The server list 408 is similarly constrained to those servers matching the previous selections, including service, technology and environment. This ensure that the user can only select appropriate inputs and can quickly identify the relevant servers.

Furthermore, by restricting the service selection based on entitlements (or delegated entitlements), a user is limited to performing configuration management tasks only for their own services or delegated services. This can significantly reduce the scope for errors (e.g. through a user inadvertently selecting the wrong server for deployment of a patch or other configuration task).

In preferred embodiments, the same entitlements apply to different types of configuration management tasks. Thus, the service owner (who has the entitlement for a particular service) can perform software updates, certificate updates and/or other available types of configuration management tasks for that service and its associated servers.

Figure 6 illustrates an example data model and associated information flows in an example implementation.

In this example, the database 101 includes IT Services Owner (ITSO) table 602 which records information about the users of the system, including a user identifier and information (e.g. by way of a delegate attribute) identifying any delegate users to whom the service owner has delegated management entitlements for their services.

The database also includes a CM DB table 604 which stores the inventory information on the managed computing nodes, in particular servers, in the network. For each server, the table may include, for example, the following attributes: * The server hostname ("HOSTNAME") identifying the server * An identifier of the service ("APP NAME") deployed on the server * An identifier ("ITSO") and name of the service owner of the service * An identifier specifying the technology class ( TECHNOLOGY") * An identifier specifying the environment, e.g. production, contingency, development, test etc. The table may include other relevant information, such as server MAC/IP address, location and the like.

The identifier of the service owner provides a link (e.g. as a foreign key) between the CMDB table 604 and the ITSO table 602 and defines the management entitlement relationship 606 for the particular service deployed on the server. Specifically, for any record in the CMBD table identifying a server and its associated service (and other attributes), the user identified by the ITSO attribute is the service owner for the corresponding service and is thus the user with the entitlement to perform -20 -configuration tasks for that server. Table views are also defined to retrieve delegates for any service owners/services via the delegate attribute of the ITS0 table.

Note that in this example a simple flat data structure is used. However, alternatively, services could be separately represented as a "Service" table, with the Service table identifying the service owner and a separate table of managed servers taking the place of CMBD table 604 and linking each managed server to the relevant entry in the Service table. Many other data representations are also possible.

The database also includes a history table 608, which records details of configuration management tasks that have been scheduled or completed.

The left-hand section of Figure 6 illustrates aspects of the information flows when a configuration management task is defined, scheduled and executed.

Section 612 illustrates the authentication flow for authenticating the user. Authentication may use external authentication services such as LDAP (Lightweight Directory Access Protocol) or other single-sign-on systems to identify and authenticate the user. Once authenticated, if the user is not identified as either a service owner or a delegate of a service owner -i.e. the user has neither direct entitlements nor delegated entitlements in relation to any services -access to the system is denied. Otherwise, the user is provided access to those services for which they are service owner or delegate as previously described (e.g. by selecting either a service owner or delegate profile).

Various user interface flows can then occur (section 610) for scheduling different types of configuration management tasks (e.g. on-premise / cloud patching, SSL certificate updates etc.), during which the user supplies the required information to identify the managed computing node (e.g. server), task to be performed (e.g. patching) and scheduled date/time and then submits the new job (section 614). In this example, user interface flows are divided into an operations flow supporting e.g. patching, an environment flow for configurations such as setups, restarts etc., and an SSL flow for certificate updates. However, this division is by way of example, and different configuration tasks may be organised in a different manner or may be supported by a single generalized user interface flow. The interface flows also distinguish between on-premise and cloud management as needed to ensure the -21 -correct configuration subsystems are used. Following job submission, scheduled and completed jobs are recorded in the history table 608.

Once submitted, the required configuration management actions are then implemented at the scheduled time by the configuration automation layer. Various known tools can be used to automate the configuration tasks.

In an example embodiment, on-premise configuration management (element 112 in Figure 1) is managed via Ansible and GIT while cloud server configuration (element 114 in Figure 1) is managed using HashiCorp Terraform, HCL (HashiCorp Configuration language) and Hashicorp Vault. Automation is managed via a Jenkins-based automation system. An example architecture for on-premise configuration management is illustrated in Figure 7A, while Figure 7B illustrates an example architecture for cloud configuration management. Figure 7B shows integration with Amazon Web Services TM (AWS) by way of example but other cloud services may be used instead or in addition. More generally, specific technologies are given by way of example and may be substituted with other suitable technologies. The system may support pre-/post-patching customisation via scripts.

Figure 8 summarises the end-to-end process for patch scheduling and deployment in an embodiment. As depicted, the process may involve steps performed after the patching has been carried out to verify the patch status. For example, the system automatically checks that the server is up and running again after patch application. If the patch has been successfully applied, the service owner is notified. If patch deployment failed (e.g. if the service could not be restarted on the patched server) the system may automatically notify an infrastructure operations specialist / team, who investigate the reason for the failure and perform any necessary remedial actions, including possibly manual installation of the patch, and then notify the service owner of the outcome. Note that in some cases remedial actions may also include rolling back an installed patch (e.g. by reverting to a previous disk image), for example if the patched software is found to be unstable after application of the patch.

Figure 9 illustrates an example of the application server 105 that may be used to provide the server back-end component of the configuration management application, as part of the SELFIE configuration management system depicted in Figure 1.

-22 -Application server 105 includes one or more processors 902 together with volatile / random access memory 904 for storing temporary data and software code being executed.

A network interface 906 is provided for communication with other system components (e.g. database 101, client device 106 and configuration managers 112/114 of Figure 1) over one or more networks (e.g. Local or Wide Area Networks, including the Internet).

Persistent storage 908 (e.g. in the form of hard disk storage, optical storage and the like) persistently stores software and data for performing the described functions of the application server, including the CMDB 102 storing inventory information, users and entitlements data 104 and the configuration management application back-end component 100. The persistent storage also includes other server software and data (not shown), such as a server operating system.

The server will include other conventional hardware and software components as known to those skilled in the art, and the components are interconnected by one or more data buses (e.g. a memory bus and I/O bus).

While a specific architecture is shown by way of example, any appropriate hardware/software architecture may be employed Furthermore, functional components indicated as separate may be combined and vice versa. For example, the data 102 and 104 may be stored at the server 105 or may be stored in a database provided on a separate database server. Furthermore, the functions of server 105 may in practice be implemented by multiple separate server devices. For example, processing could be divided across multiple servers in a server cluster.

Embodiments of the invention can simplify configuration management including server patching and certificate management. By providing end-to-end infrastructure automation with self-service capability the described system can reduce the human effort involved, allowing patch deployment to be configured in a few simple steps in a few minutes by the service owner without the delay involved in coordinating between different responsible teams in an organisation. At the same time, the entitlements-based approach ensures that users can only manage services and associated -23 -servers for which they are designated as service owner or delegate of the service owner, which can simplify the process for the user and reduce the scope for errors and misconfiguration.

It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention.

Claims (1)

1. -24 -CLAIMS1. A computer-implemented method performed in a configuration management system for performing configuration management for managed computing nodes of an IT system, comprising: storing in an inventory database inventory information for the IT system, the inventory information identifying: a plurality of managed computing nodes in the IT system; and a plurality of software services provided on the managed computing nodes; associating entitlement information with the software services, wherein the entitlement information identifies, for a given software service, one or more users of the configuration management system entitled to perform configuration management tasks in respect of the given software service; providing a configuration management application arranged to enable a user to specify a configuration management task to be performed for a selected software service at a selected computing node, wherein the configuration management application restricts the specification of configuration management tasks by the user based on one or more entitlements defined for the user in the entitlement information; and invoking a configuration subsystem to initiate the specified configuration management task at the selected computing node 2. A method according to claim 1, wherein the specified configuration management task comprises one of: installation of a software update for the selected software service deployed on the selected computing node; and installation or renewal of a security certificate, optionally a Secure Sockets Layer (SSL) certificate, at the selected computing node.3. A method according to any of the preceding claims, wherein the configuration management application allows a user to specify a configuration management task only in respect of a service for which the user is entitled according to the entitlement information.4. A method according to any of the preceding claims, wherein the configuration management application allows a user to specify a configuration management task -25 -only in respect of one or more computing nodes associated in the inventory database with a service for which the user is entitled according to the entitlement information.5. A method according to claim any of the preceding claims, comprising, by the configuration management application: identifying one or more of the plurality of services and/or one or more of the managed computing nodes for which the given user may initiate configuration management tasks based on the entitlement information; and restricting the user to specification of configuration management tasks only in relation to the identified services and/or computing nodes.6. A method according to any of the preceding claims, wherein the inventory information associates a given service with one or more computing nodes that have software deployed for implementing the service.7. A method according to any of the preceding claims, wherein the entitlement information defines service owner entitlements, each service owner entitlement identifying a given user of the configuration management system as a service owner of a given one of the software services and indicating an entitlement of the given user to perform configuration management tasks in respect of the given software service.8. A method according to claim 7, wherein the entitlement information further defines delegation of entitlements from a given user to one or more other users.9. A method according to claim 8, wherein the entitlement information identifies, for a given delegating user, preferably a user identified as a service owner of one or more services, at least one further user as a delegate user, wherein the delegate user(s) inherit one or more entitlements from the delegating user.10. A method according to claim 9, wherein the delegate user(s) are entitled to perform configuration management tasks in respect of one or more services for which the delegating user is entitled according to the entitlement information, preferably for one or more or each of the services for which the delegating user is identified as service owner.11. A method according to any of the preceding claims, wherein the configuration application restricts a user to enable the user to specify or initiate configuration -26 -management tasks only in respect of a service (or a computing node associated with a service) for which the user is identified as a service owner or delegate of the service owner.12. A method according to any of the preceding claims, comprising, by the configuration management application: identifying a user of the configuration management system, the identifying step optionally comprising authenticating the user; identifying based on the inventory database and entitlement information, one or more services for which the identified user is entitled; and making the identified one or more services available for selection by the user in the application.13. A method according to claim 12, further comprising identifying one or more computing nodes associated in the inventory database with the identified services and restricting a user to initiate configuration tasks only in relation to the identified computing nodes.14. A method according to claim 12 or 13, comprising: receiving a selection of one of the identified services from the user; identifying one or more computing nodes associated in the inventory database with the identified services; and making the identified one or more computing nodes available for selection by the user in the application to enable specification by the user of a configuration management task for a selected one of the identified computing nodes.15. A method according to claim 14, wherein computing nodes are associated with one or more classification attributes in the inventory database, each classification attribute defining a plurality of classes of computing nodes, the method comprising providing a selection interface for receiving a selection of a class of computing node from the user for one or more of the classification attributes.16. A method according to claim 15, wherein the identifying step includes identifying one or more computing nodes associated in the inventory database with the selected service and the selected computing node classes, the method comprising making only the identified computing nodes matching the selected -27 -classes available for selection by the user when specifying a configuration management task to be performed on a computing node.17. A method according to claim 15 or 16, wherein the one or more classification attributes comprise one or more of: a technology classification attribute indicating one of a plurality of classes of software environment deployed on a computing node, optionally wherein the technology classification includes classes corresponding to one or more operating systems, middleware systems and/or database management systems provided on computing nodes; an environment classification identifying one of a plurality of classes of usage environments or usage contexts of a computing node, optionally wherein the plurality of classes include one or more of: a production environment, a contingency environment, a development environment and a test environment.18. A method according to claim 17, comprising restricting selection of a computing node by the user based on the technology and environment classes selected by the user for the selected service.19. A method according to any of claims 14 to 18, comprising: receiving a selection of one of the identified computing nodes from the user; receiving specification information defining a configuration management task to be performed for the selecting computing node; and invoking the configuration subsystem to configure the selected computing node based on the specification information.20. A method according to claim 19, wherein the configuration management task comprises a software update task, the specification information specifying a software update to be installed on the computing node, optionally selected from multiple available software updates.21. A method according to claim 19 or 20, wherein the specification information comprises schedule information indicating a time at which the configuration management task is to be performed, the method comprising invoking or configuring the configuration subsystem to perform the specified configuration management task at the indicated time.-28 - 22. A method according to any of the preceding claims, comprising monitoring an outcome of the configuration management task and notifying the user of the outcome 23. A method according to claim 22, wherein the monitoring includes determining whether a computing node has returned to operation following installation of a software update 24. A method according to any of the preceding claims, wherein the computing nodes comprise physical and/or virtual computing nodes, optionally including one or more physical servers and/or one or more virtual servers or virtual machines.25. A method according to any of the preceding claims, wherein the computing nodes comprises one or both of: on-premise computing nodes provided within a network of an organisation operating the configuration management system; cloud computing nodes provided via a public network by a cloud computing provider.26. A method according to claim 25, wherein invoking a configuration subsystem to perform a configuration management task for a computing node comprises selecting an on-premise configuration subsystem or a cloud configuration subsystem depending on the type of computing node and invoking the selected configuration subsystem.27. A configuration management system for performing configuration management for managed computing nodes of an IT system, comprising: a database configured to store: inventory information for the IT system, the inventory information identifying a plurality of managed computing nodes in the IT system and a plurality of software services provided on the managed computing nodes; entitlement information associated with the software services, wherein the entitlement information identifies, for a given software service, one or more users of the configuration management system entitled to perform configuration management tasks in respect of the given software service; a configuration management application arranged to enable a user to specify a configuration management task to be performed for a selected software service at -29 -a selected computing node, wherein the configuration management application restricts the specification of configuration management tasks by the user based on one or more entitlements defined for the user in the entitlement information; and a configuration subsystem configured to initiate the specified configuration management task at the selected computing node.28. A system having means, optionally comprising one or more processor(s) with associated memory, for performing a method as set out in any of claims 1 to 26.29. A computer program, computer program product or non-transitory computer readable medium comprising software code adapted, when executed by a data processing system, to perform a method as set out in any of claims 1 to 26.