EP3796161A1 - Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium - Google Patents

Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium Download PDF

Info

Publication number
EP3796161A1
EP3796161A1 EP19198405.3A EP19198405A EP3796161A1 EP 3796161 A1 EP3796161 A1 EP 3796161A1 EP 19198405 A EP19198405 A EP 19198405A EP 3796161 A1 EP3796161 A1 EP 3796161A1
Authority
EP
European Patent Office
Prior art keywords
container
engines
engine
containers
path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP19198405.3A
Other languages
English (en)
French (fr)
Inventor
Harald Albrecht
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to EP19198405.3A priority Critical patent/EP3796161A1/de
Publication of EP3796161A1 publication Critical patent/EP3796161A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the invention relates to a method for determining a container configuration of a system, the system having an operating system and a plurality of software containers which are managed by a plurality of container engines are present on the system.
  • the invention also relates to a system for carrying out such a method, a computer program and a computer-readable medium.
  • Containers which can also be referred to as application or software containers, are generally "encapsulated" units that can be run independently of one another, regardless of where they are located. Similar to virtual machines (abbreviated VMs), containers are a type of container for applications in which they can run. However, while virtual machines represent an entire computer environment, the containers usually only contain the important data that are required for the execution of the respective application or applications.
  • VMs virtual machines
  • the container technologies or containerization make it possible in particular to pack a software or application in a container that includes everything it needs to run, for example program code, runtime, system tools and / or system libraries.
  • the container technologies and functions can be easily and conveniently packaged, transported and finally rolled out into the operational area.
  • Containers thus allow flexible transport and use of modular software in the form of independently executable modules without any dependencies on the software libraries of the executing operating system.
  • Classic areas of application of containers for example, can be used to conveniently pack applications such as a database or a web front end.
  • the positive properties can also be used advantageously in the industrial edge products of the digital industry (DI).
  • DI digital industry
  • Examples of software for container virtualization / containerization are for example “Docker” or “rkt” (pronounced “rocket”, see for example https://coreos.com/rkt/ and https://www.docker.com or EP 3 267 351 A1 to Docker ).
  • An example of an orchestration system / tool or orchestration software for containers is given by “Kubernetes” (see for example https://kubernetes.io/ and https://de.wikipedia.org/wiki/Kubernetes).
  • the containers are usually managed by so-called “container engines” which, for example, take care of downloading the required container images and starting and stopping them.
  • a container engine could also be referred to as a container machine or container mechanics.
  • Container engines usually hide the technical details of a subordinate operating system from which containers are assembled at runtime.
  • VMM virtual machine monitor
  • cluster management and orchestration systems known today (such as Kubernetes and Collinser, see, for example, https://en.wikipedia.org/wiki/Rancher_Labs) do not offer any support here. These systems are based on the basic model in which only one container engine is used per (work) system such as VM or bare metal. This does not in principle exclude more complex system configurations, but these are not supported.
  • the method should be easy to carry out and, compared to the prior art, require less or even detailed system knowledge on the part of the user.
  • the second-mentioned object is achieved by a system which is designed and / or set up to carry out the method according to the invention.
  • the invention is based on the idea of providing a discovery service by means of which, on the one hand, the containers currently present in a system with multiple container engines can be determined automatically, and, on the other hand, it is possible, likewise automatically, to obtain information about the logical To record hierarchy or topology.
  • the discovery service is provided by the discovery module.
  • the logical hierarchy or topology is designed in particular on the basis of the specific arrangement of the container engines found.
  • the discovery module preferably creates a data model that lists all of the containers determined in step c).
  • the discovery service and thus the discovery module creates an up-to-date data model that lists all the containers found in a single system, including across various container engines.
  • the Discovery Service preferably determines a logical hierarchy or topology of the container engines, in particular via the creation of the paths. If a data model is created by the discovery module, this accordingly preferably also comprises the path or paths created in step d).
  • the data model particularly preferably includes which process identifier the respective container has and which of the created paths belongs to the respective container. In other words, its process identifier and the path associated with the container can preferably be stored for each container. This is the path that was created for the container engine to which the respective container is assigned.
  • the procedure according to the invention offers various advantages. It provides a universal basic service for container discovery in various system configurations, on which specialized diagnostic tools and applications can then easily be built.
  • the invention can thus form an important component, for example, for diagnosis and monitoring of container communication, for example in industrial clusters with industrial edge devices.
  • a simple, clear handling of containers is possible even in complex system configurations of work nodes (e.g. industrial edges) with several container engines in the same system in different arrangements.
  • configurations can be covered that are not covered by the conventional, previously known management and orchestration tools.
  • the complexity of system configurations is hidden from the user and he is allowed to work on the simple abstraction level of the container that he wishes, without any unnecessary detailed knowledge of system configurations.
  • the existing container engines are found automatically based on the locally available information from the operating system and a container hierarchy or topology based on the current arrangement ("nesting") of container engines found in is preferred Containers generated.
  • the invention makes it possible, among other things, to detect whether container engines are in a side-by-side arrangement and / or whether container engines are in a container-in-container arrangement.
  • each container can be managed by exactly one of the container engines.
  • At least two container engines are provided in a side-by-side arrangement and / or at least two container engines are provided in a container-in-container arrangement. If there are three container engines, for example two containers can be side-by-side, in particular in a hierarchy level, and the third container engine in a container of one of the two side-by-side engines, so that the third engine can deal with it Engine is in a container-in-container configuration.
  • a container is available can mean, for example, that it has (only once) been created, in particular without processes having already been started or running in it. In particular, the container is then (only) configured. Furthermore, the processes in a container can already have been completed, but the container can still be recognized from an administrative point of view. In addition, a container with processes can also be stopped (frozen, so to speak). Alternatively or additionally, containers can also be in this "state" taken as present and determined step c).
  • all configured containers are used for the detection of the container. If it is known from the outset that there is only interest in running containers, for example, you can only focus on running containers, for example.
  • the process tree lists the processes in a manner known per se, preferably all processes that are currently running on the system.
  • the process tree can also be in table form (one then also speaks of a process table), which contains the processes and the information about the tree structure, in particular information about which processes are parent processes of another process.
  • the process identifier is preferably, in a manner known per se, an identifier which is used to uniquely identify processes. It is also called Process Id or PID for short. For process identification see e.g. https://de.wikipedia.org/wiki/Process_identifier.
  • the process ID of a parent process is also known as the Parent Process ID or PPID for short.
  • the system according to the invention can be, for example, a PC, for example an industrial PC.
  • the system can be in the form of a work node, in particular an industrial one Clusters. It can also be a so-called industrial edge or a so-called industrial edge device.
  • An edge or an edge device is to be understood in particular as a device that executes the or at least one function of edge computing (for edge computing, see, for example, https://de.wikipedia.org/wiki/Edge_Computing).
  • An industrial edge device can, for example, be an industrial computer that performs an edge computing function.
  • a discovery module is preferably provided or implemented for each node.
  • the system according to the invention is given by a virtual machine (VM) or comprises one.
  • VM virtual machine
  • the system according to the invention is in the form of a virtual machine (VM), it preferably has an operating system, in particular precisely one operating system.
  • container engines for example two or three or more container engines, means in particular or includes in particular that the existing containers are partitioned into two or more administrative areas and each area has its own (instance of a) container Engine heard.
  • a container engine can be given, for example, by a Docker engine (see e.g. https://docs.docker.com/engine/).
  • a Docker engine can include a Docker daemon and a container daemon. It can also include the container runtime runC. For runC see, for example, https://blog.docker.com/2017/08/what-iscontainerd-runtime/).
  • a container engine is generally used in particular to provide API / user interfaces and / or to generate container images and / or configurations or to provide configuration files, for example a config.json.
  • a container configuration of the system is determined means in particular or includes in particular that the existing container engines and containers are determined and a topology or hierarchy of the container engines is determined. It should be noted that a container configuration can also be understood to mean a container deployment or, in German, container use, or a container configuration can include a container deployment or use.
  • the discovery module provided according to the invention preferably monitors the operating system and the container engines.
  • the monitoring is expediently carried out largely or fully automatically.
  • the discovery module is particularly preferably provided on the system whose container engines and associated containers are to be recorded.
  • the discovery module can be implemented, for example, in software or in hardware or in a combination of software and hardware.
  • a discovery module can be implemented on the system as a software module, for example. It can be a "simple" process that is preferably integrated or installed in the system. For example, it can also be installed and run as a container.
  • each system is preferably assigned its own discovery module, in particular a separate discovery module is implemented on each system.
  • the container engines present on the (respective) system are recorded by the discovery module.
  • Container engines can, for example, be recognized by their names (eg "dockerd") or by means of parts of their names.
  • the Discovery module can be designed and / or set up accordingly in an advantageous embodiment. It is also possible for the discovery module to use a list of known names or known parts of names of container engine processes in the process tree of the operating system. Alternatively or additionally, container engines can also be found using known process properties of these. It can also be known what size they are, or in what range their size is. A search or identification can then take place via the size.
  • the discovery module can be designed and / or set up accordingly in a further development.
  • the process identifiers of the container engine processes of the container engines are also determined in step a).
  • the result of the search or the container engine detection is, in particular, a list of process IDs of currently running container engines, in particular of all currently running container engines.
  • control channels via which the container engines can or could be addressed. These control channels can also be considered and designated as possible control channels.
  • Control channels can be provided, for example, by so-called Unix sockets, in particular control Unix sockets. For Unix sockets, see, for example, https://de.wikipedia.org/wiki/POSIX_local_inter-process_communication_socket.
  • the result for each individual container engine is initially a separate (expediently ordered) list of potential, possible control channels via which the respective container engine could be addressed.
  • each control channel possibly providing different functions. It may be, that not every control channel provides the functionality to access the list of containers of a container engine.
  • the determination of the control channels includes that those control channels, in particular Unix sockets, preferably together with their inode numbers and their paths in the file system are recorded or determined in mount namespaces of the container engines that are in the "listen” state.
  • the acquisition or determination of the control channels, in particular Unix sockets can take place on the basis of information from / sys / net / unix.
  • the API function "listen (2)" is described, with which, among other things, a Unix socket is set to the LISTEN state.
  • handles in particular file descriptors ("fd")
  • fd file descriptors
  • open handles preferably open file descriptors
  • only those control channels are considered and recorded as control channels or possible control channels for which this applies, that is to say which refer to one of the previously determined control channels in the “listen” state.
  • the mount namespaces are in particular - in a manner known per se from the prior art - namespaces of the operating system or operating system kernel, for example Linux or Linux kernel namespaces (see e.g. https: // en.wikipedia.org/wiki/Linux_namespaces). For handles see, for example, https://de.wikipedia.org/wiki/Handle and for file descriptors, for example, https://en.wikipedia.org/wiki/File_descriptor. File descriptors are, so to speak, "handles" for data channels to files, devices, Unix sockets, etc.
  • the discovery module determines containers belonging to the container engines detected by it. All containers are preferably determined by all container engines. It is of course possible that the attempt to discover the container will fail for at least one of the engines. It is therefore quite possible that the associated containers are only recorded for some, possibly even only for one engine.
  • the process identifiers belonging to the containers are also expediently determined, as well as names belonging to the containers, in particular names given to containers from an application perspective and / or by the user.
  • step c) an attempt is made in step c) for the respective container engine in the mount namespace to contact the container engine via the control channel or channels and to query the container or containers assigned to it.
  • Those control channels through which this succeeds can be understood and referred to as suitable control channels.
  • the associated container and preferably the process IDs and names of each of these are queried via the (possible) control channel (s) determined for the (respective) container narrowness.
  • step d) the discovery module creates a path for one or more of the container engines.
  • a path is preferably created for each detected engine. It is of course conceivable that this is not possible for at least one of the captured engines, for example because it was already not possible to find one or more control channels for this or their containers could not be captured via them.
  • a path is to be understood in particular as a hierarchical identifier or an identifier from which a hierarchy or hierarchy information can be derived, in particular on the basis of the sequence of components contained in the path or the identifier.
  • hierarchical information or hierarchical information for a container engine is to be understood as meaning, in particular, information as to whether the container engine is "nested” in one or more containers like a matryoshka or not, which is more appropriate Way can be inferred from the path created for the container engine, in particular also "how many containers deep" the container engine lies.
  • a path can be given by a hierarchical name, in other words hierarchy name.
  • the entire hierarchy or topology can be determined or displayed or derived from the comparison or consideration of the paths of several, preferably all, existing container engines.
  • the respective path also receives the identifier or an identifier, in particular the name or a name of the container engine, which can be, for example, "dockerd”.
  • the path "dockerd / outer" would then result.
  • the identifier or identifiers of containers and / or of container engines that are added to the paths can in principle be identifiers or identifications or designations of any kind. It is particularly preferred that the names of the containers and / or container engines are used by means of which these can be distinguished.
  • the names can be words. For example, the names can only contain letters, but this is not absolutely necessary. In principle, alternatively or in addition, names can also have digits or other characters, for example.
  • identifiers of the containers and / or container engines can in principle also be used for the paths. Especially since these may also change can, however, it is generally advantageous to include other identifiers, preferably container (engine) names, in the paths, particularly preferably those that have been assigned by a user and / or that are also used in the event that a container is terminated and subsequently is restarted, stay the same.
  • the name of a container is preferably managed by the respective container engine to which the container belongs, and can, for example, also be generated automatically or also be or have been specified by a container orchestration system.
  • names of the containers can be included in the paths as identifiers, that is to say used for creating the path, for example UUIDs and / or UIDs can also be used as identifiers of the containers.
  • UUID stands in a manner known per se for Universally Unique Identifier (see, for example, https://de.wikipedia.org/wiki/Universally_Unique_Identifier) and UID for Unique Identifier.
  • identifiers that are assigned to a container or a container engine are added to the (respective) path.
  • an identifier such as the name, will suffice.
  • exactly one identifier of the associated container is preferably included in the (respective) path for each container process identifier found.
  • the empty path or original path is expediently assigned to this engine.
  • An empty path or original path can be given by "" or "/", for example.
  • the path of the respective container engine (s) is in particular the stringing together of the identifiers, in particular names of the containers found when "climbing" along the process tree or process tree branch, preferably in the reverse order. If, for example, a container has been assigned the identifier or the name "outer" and it comprises or contains a container engine, then the container engine contained - and preferably also the container assigned to it, in particular the container managed by it - receives the Associated path "outer".
  • the associated identifiers are particularly preferably included in the path in reverse order as the container process IDs are present in the process tree based on the process ID of the container engine in the direction of the process tree root. This corresponds in particular to the reverse order for finding the container process IDs.
  • the identifier for example the name of the container belonging to the container process identifier found last, is on the far left in the path description, while that of the container found first is on the far right.
  • the search in the process tree is expediently carried out until the top process identifier of the process tree or the root is reached. This ends the search for the container engine in question and the path is complete. If no process ID of a container is found on the way from the process ID of the container engine under consideration to the root, this means that the container engine is not itself located in a container, so to speak, is not nested in one (or more) container.
  • the paths can be separated, for example, by adding different additional path components to identical paths.
  • the process identifier and / or the name of the container engine for which the respective path was created come into consideration as additional path components for obtaining a separation.
  • additional path components for obtaining a separation.
  • step d The case that the same path is created for two or more container engines in step d) occurs in particular when two or more container engines are next to each other (side-by-side) in a container - or on the top hierarchy level - lie.
  • the same container process IDs - or no process IDs - are found and corresponding to the paths the same identifiers, in particular names of the associated containers - or no identifiers or names - added, so that two or more identical paths result.
  • the discovery module checks, in particular after the creation of all paths in step d), whether there are multiple paths. If the check shows that this is the case, the discovery module occasionally prefers the paths.
  • the path separation takes place in such a way that one begins with the shortest identical paths. If, for example, two or more container engines are each assigned an "empty" path or an original path, for example "/" or "”, these are preferably first separated and then any longer paths that may be present, for example “/ Outer” “or” / Outer / Inner ".
  • the discovery module after the discovery module has found two or even more, in particular, shortest identical paths a first time and has isolated and, if necessary, adapted paths that are dependent on them, at least one more time whether identical paths are still available are and occasionally also these. This can be repeated until no more identical paths can be found.
  • Another particularly advantageous embodiment is further characterized in that the paths determined and possibly isolated in step d) for the respective container engine or engines are stored, for example in the discovery module or a data model of the discovery module.
  • a data model is preferably given by the paths together with their assignment to the individual containers and container engines or includes this.
  • the path or paths determined in step d) for the respective container engine and possibly isolated paths are stored in the data of the associated container or containers.
  • the path of the respective engine is preferably stored in the data of each container assigned to a container engine. This makes it possible for a simple and unambiguous assignment (in each case) between an individual container and its container engine to be available later, in particular.
  • At least one further instance for example at least one diagnostic tool, such as one that displays the ascertained topology to a user in text or graphical form, can access data ascertained and / or provided by the discovery module, in particular on a data item from the discovery module access the information or data model provided.
  • at least one diagnostic tool such as one that displays the ascertained topology to a user in text or graphical form
  • the data provided can also be accessed, for example, by an external plug-in for recording network traffic (so-called Extcaps).
  • an external plug-in for recording network traffic for example, an external plug-in for recording network traffic (so-called Extcaps).
  • Extcaps for recording network traffic
  • Such a plug-in for example a Wireshark plug-in, can use a data model of the Discovery module, for example, in order to present a list of available containers (in particular including their names and paths) to a user.
  • a method for diagnosing the network traffic can be carried out in which data is accessed which was stored in the context of carrying out the method according to the invention for determining a container configuration, in particular by the discovery module.
  • REST stands for Representational State Transfer (see, for example, https://de.wikipedia.org/wiki/Representational_State_Transfer) and API for Application Programming Interface (German: user programming interface, see, for example, https://de.wikipedia.org/wiki/Programmiingangstelle) ).
  • the system according to the invention can be designed and / or set up in an advantageous embodiment in order to implement one or more of the preferred features described above.
  • the features described above relate to the discovery module, it is true that the discovery module can be designed and / or set up accordingly in a preferred development.
  • the system according to the invention can be developed in accordance with the dependent method claims.
  • Another subject matter of the present invention is a computer program comprising program code means which, when the program is executed on at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.
  • the invention relates to a computer-readable medium which comprises instructions which, when they are executed on at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.
  • the computer-readable medium can be, for example, a CD-ROM or DVD or a USB or flash memory. It should be noted that a computer-readable medium should not be understood exclusively as a physical medium, but rather such a medium can also be present, for example, in the form of a data stream and / or a signal that represents a data stream.
  • the Figure 1 shows in a purely schematic, greatly simplified representation an exemplary embodiment of a system S according to the invention.
  • this is an industrial edge device which forms a working node of an industrial cluster.
  • the cluster preferably comprises, in a manner known per se, a plurality of systems 1 of the in Figure 1 the type shown, for example on an industrial network, such as an industrial automation system, take part.
  • the system 1 or the systems 1 are each provided by an industrial computer that performs an edge computing function.
  • a system according to the invention can also be provided, for example, by a virtual machine (VM).
  • VM virtual machine
  • a cluster can comprise several virtual machines as working nodes, each of which represents an exemplary embodiment of a system according to the invention.
  • the system S has exactly one operating system OS, which is given by Linux in the example shown.
  • Container C Several software containers, in this case Docker containers C1-C7, are present on the system S, which are referred to below as container C for short.
  • the containers C1-C7 are not managed by one but by several container engines CE1-CE4.
  • Each container C1-C6 is assigned to exactly one of the container engines CE1-CE4 and is managed by this.
  • the containers C1 and C2 belong to the container engine CE1
  • the containers C3 and C4 belong to the container engine CE2
  • the containers C5 and C6 belong to the container engine CE3
  • the container C7 belongs to the container engine CE4 .
  • container engines CE1-CE4 are shown with dashed lines and containers C1-C7 with dash-dotted lines.
  • the container engines CE1-CE4 are provided by Docker engines.
  • the Docker engines CE1-CE4 each include a Docker daemon, a container daemon and runC.
  • container engines CE1-CE4 are both in a side-by-side arrangement and in a container-in-container arrangement are located.
  • the container engines CE1 and CE2 lie next to one another in a hierarchy level, that is to say "side-by-side”.
  • the container engine CE3 is in the container C4 of the container engine CE2 and the container engine CE4 is in the container C6 of the container engine CE3.
  • the container engines CE2, CE3 and CE4 are thus in a matryoshka-like "nested” arrangement, in other words are container-in-container.
  • the procedure according to the invention enables automatic container discovery even in this complex system configuration with several container engines CE1-CE4 in mixed arrangements side-by-side and container-in-container.
  • the system S has a discovery module D for this purpose. It should be noted that even if in the Figure 1 two modules D are shown schematically, on the system S only one such module D is provided.
  • a discovery module D can, for example, be a "simple" process that is integrated or installed in the system S.
  • a discovery module D can, however, for its part also be installed and implemented as a container, for example.
  • the Figure 1 shows both of these possibilities in that the module D is shown once in a container, namely in the container C1, and once outside the container C1-C6 in FIG Figure 1 far left.
  • the discovery module D can be implemented in software in both variants, although this is not to be understood as restrictive.
  • Each system S representing a working node of the cluster preferably has its own discovery module D for container discovery.
  • discovery module D With the discovery module D, the steps described below of an embodiment of the invention Method carried out, for which purpose the discovery module D is designed and set up accordingly.
  • the discovery module D monitors the operating system OS and the container engines CE1-CE4.
  • the container engines CE1-CE4 present on the system S are recorded with this.
  • container engine processes PZ1-PZ4 belonging to the container engines CE1-CE4 and the associated process identifiers PID are determined.
  • the PIDs are entered in the process construction PT, whereby these values are to be understood purely as examples.
  • Container engines CE1-CE4 can, for example, be recognized by their names (e.g. "dockerd"). It is also possible for the discovery module D to use a list of known names of container engine processes PZ1-PZ4 in the process tree PT of the operating system OS. Alternatively or additionally, container engines CE1-CE4 can also be found using known process properties. It can also be known what size they are, or in what range their size is. A search or identification can then take place via the size. The discovery module can be designed and / or set up accordingly in a further development.
  • the result of the search or the container engine detection is in the present case a list of process identifiers PZ1-PZ4 of all the container engines CE1-CE4 currently running on the system S.
  • control channels SK in this case control Unix sockets (see FIG Figure 2 ) determines via which the container engines CE1-CE4 are addressed can be.
  • control channels SK are also considered and referred to as possible control channels.
  • the determination of the possible control channels SK in step b) includes in the present case that those control channels SK, specifically Control Unix Sockets, preferably recorded together with their inode numbers and their paths in the file system in the mount namespaces of the container engines CE1-CE4 or which are in the "listen" state. It is preferable to temporarily switch to the mount namespaces of the container engines CE1-CE4 one after the other.
  • the acquisition or determination of the control channels SK can be carried out using information from / sys / net / unix UXT (see Figure 2 ) respectively.
  • UXT stands for Unix (domain) socket table.
  • CE1 has the PID 42.
  • CE1 may currently have the file descriptors 0-18 open, i.e. / proc / 42 / fd / contains the child nodes "0" to "19".
  • the file descriptor "6" (/ proc / 42 / fd / 6) refers to the Unix socket with the inode number 29368 (e.g. determine via "readlink / proc / 42 / fd / 6"), the file descriptor "19" the Unix socket with the inode number 228971.
  • the table (s) of the Unix sockets / proc / net / unix has, for example, the following text structure: Num RefCount Protocol Flags Type St. Inode Path ffff95e3a8ed8400: 00000002 00000000 00010000 0001 01 29368 ... /var/run/docker.sock ...
  • the Unix socket with the inode number 228971 also refers to "/var/run/docker.sock", but is in the state "03" "CONNECTED”.
  • each individual container engine CE1-CE4 or each individual container engine copy CE1-CE4 the result is initially a separate (ordered) list of potential, i.e. possible control channels via which the respective container engine CE1-CE4 is addressed could.
  • the discovery module D uses at least some of the control channels SK to determine the containers C1-C7 belonging to the container engines CE1-CE4 detected by it, as well as their process identifiers, PIDs and names N. If possible, all containers C1-C7 are determined by all container engines Ce1-CE4 along with the associated PIDs and names.
  • Control channels SK An attempt is made for the respective container engine CE1-CE4 in the mount namespace of this via the possible one or more Control channels SK to contact the container engine CE1-CE4 and to query the container or containers C1-C7 assigned to them, their PIDs and N names.
  • Those control channels SK via which this is possible can be considered and referred to as suitable control channels SK.
  • the mount namespaces of all container engines CE1-CE4 are switched one after the other.
  • the containers C1-C7 assigned to a container engine CE1-CE4 could be read out or their container C1-C7 cannot or could not be read out via any of the possible control channels SK of a container engine CE1-CE4
  • in each case changed to the mount namespace of the next container engine CE1-CE4 and tried to determine the assigned container C1-C7 of this. It is thus possible to switch from mount namespace to mount namespace of the running container engines CE1-CE4 one after the other until all the existing engines CE1-CE4 are through. After the last container engine CE1-CE4, there is expediently no further change.
  • step d) the discovery module D (if possible) creates a path P (see FIG Figure 3 ) created. It should be noted that it can happen that this is not possible for at least one of the captured engines CE1-CE4, for example because it was already not possible to find suitable control channels SK for this or to capture their containers.
  • a path P is to be understood in particular as a hierarchical identifier or an identifier from which a hierarchy or hierarchy information can be derived, in particular due to the sequence of components contained in the path P or the identifier.
  • a search is made in the process tree PT in the direction of the root R of the process tree PT, and for each process identifier PID (container -Process identifier) a or the name of that container C1-C7, whose container process identifier PID was (in each case) found, is preferably added to the previous, in particular empty path at the beginning of the search.
  • PID container -Process identifier
  • the name of a container C1-C7 is preferably managed by the respective container engine CE1-CE4 to which the container C1-C7 belongs, and can, for example, be generated automatically or also be specified by a container orchestration system.
  • an empty path or original path for example “” or “/”, is initially assumed and in particular initialized for the respective container engine CE1-CE4.
  • one or more container process identifiers PID are found for a container engine CE1-CE4
  • the empty path is expediently assigned to this engine CE1-CE4.
  • the associated names are particularly preferably included in the path P in the reverse order than the container process identifiers starting from PID from the considered process identifier PID of the container engine CE1-CE4 in the direction of the process tree root R in the Process tree PT are available. This corresponds in particular to the reverse sequence for finding the container process IDs PID.
  • the process tree PT also contains the container process IDs 800, that is the PID of the container C6 and the container process ID 80, that is the PID of the container C4 (cf. in particular Figure 4 above, in which the containers C4 and C6 are shown above the process tree PT and to the right of it again the associated PIDs and names N).
  • the path of the container engine CE4 is the stringing together of the names of the containers C1-C7 found when "climbing" along the process tree PT or process tree branch, preferably in reverse order.
  • the path P also receives the or a "name" of the container engine, which can be, for example, "dockerd”. Then you would get e.g. "/ dockerd” instead of "" or "/ dockerd / O" instead of "/ O”.
  • the container engines CE1-CE4 can be advantageous to avoid that two or more of the container engines CE1-CE4 are assigned the same path. Accordingly, it can be provided that in the event that the paths P created for the container engines CE1-CE4 include two or more identical paths P, the paths P are separated. In the example described, the same path P has been created for the container engines CE1 and CE2, namely the "empty" or "original path” for both "/", because these two engines are next to each other in the top hierarchy level.
  • the discovery module D preferably checks whether there are multiple paths P. If the check shows that this is the case, the discovery module D can separate identical paths P.
  • the paths P can be separated, for example, by adding different additional path components to (each) identical paths P.
  • the PIDs of the engines CE1 and CE2 are added to the two identical paths P of CE1 and CE2 for separation. This results in path P "/ 42" as path P "/ 42" for container engine CE1 and path P "/ 45" for engine CE2, so that individual paths P which are different from one another are obtained.
  • adaptations carried out in shorter paths P for the isolation are adopted into longer paths P which may be present and which are dependent on the shorter paths P.
  • the adaptation carried out for the engine CE2 for the separation can preferably be adopted in the paths of the engines CE3 and CE4, both of which are located in containers C4, C6 which are subordinate to the engine CE2 in single or double “nesting” (see in particular Figure 1 ).
  • the path "/ 45 / O” would then result for engine CE3 and the path "/ 45 / O / I" for engine CE4.
  • the discovery module D checks, after it has found two or more, in particular, shortest identical paths P a first time and has isolated them and, if necessary, appropriately adapted dependent paths P, at least one more time whether identical paths P are still present and occasionally also these. This can be repeated until no more identical paths P are found by the discovery module D.
  • the discovery module D could then, for example, again add the PID of the relevant container engines to the paths P, preferably at the right end thereof.
  • the other engine which is also located in the container C6, has the PID 905, which is to be understood as an example, the individual paths "/ 45 / O / I / 902" for the engine CE4 and "/ 45 / O would be / I / 905 "for the other engine in the same container C6.
  • the discovery module D creates a data model M (see Figures 1 and 2 ), which lists all determined containers C1-C7.
  • the discovery module D stores the - and possibly isolated - paths P determined for the container engines CE1-CE4 in the data of the associated container (s) C1-C7.
  • the path P of the respective engine CE1-CE4 is stored in the data of each container C1-C7.
  • These data records contain the information for each container C1-C7 that was previously queried by the container engines CE1-Ce4.
  • the paths P are in the Figure 4 entered in the respective container engine CE1-CE4 and the associated containers C1-C7. This makes it possible that, in particular, a simple and unambiguous assignment (in each case) between an individual container C1-C7 and its container engine CE1-CE4 is also available later.
  • the separated paths P are expediently stored in the data model M of the discovery module D and / or in the data of the relevant containers C1-C7.
  • the separated paths P are expediently stored in the data model M of the discovery module D and / or in the data of the relevant containers C1-C7.
  • the data M provided can then be accessed, for example, by an external plug-in for recording network traffic (so-called extcaps).
  • an external plug-in for recording network traffic for example, an external plug-in for recording network traffic (so-called extcaps).
  • extcaps an external plug-in for recording network traffic
  • Such a plug-in for example a Wireshark plug-in, can use the data model M of the discovery module D, for example, to present a list of available containers C1-C7 (in particular including their names N and paths P) to a user.
  • REST Representational State Transfer
  • API Application Programming Interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Factory Administration (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Bestimmung einer Container-Konfiguration eines Systems (S), wobei das System (S) ein Betriebssystem (OS) aufweist und auf dem System (S) mehrere Software-Container (C1-C7) vorhanden sind, die von mehreren Container-Engines (CE1-CE4) verwaltet werden, bei dem mittels eines Discovery-Moduls (D)
a) die Container-Engines (CE1-CE4) erfasst werden, wobei in einem Prozessbaum (PT) des Betriebssystems (OS) des Systems (S)zu den Container-Engines (CE1-CE4) gehörige Container-Engine-Prozesse (PZ1-PZ4) ermittelt werden,
b) für die erfassten Container-Engines (CE1-CE4) Steuerkanäle (SK) ermittelt werden, über welche die Container-Engines (CE1-CE4) angesprochen werden können,
c) unter Nutzung zumindest einiger der Steuerkanäle (SK) ermittelt wird, welche Container (C1-C7) zu welchen Container-Engines (CE1-CE4) gehören und welche Prozesskennungen (PID) die Container (C1-C7) jeweils aufweisen, und
d) für eine oder mehrere der Container-Engines (CE1-CE4) ein Pfad (P) erstellt wird.
Darüber hinaus betrifft die Erfindung ein System (S) zur Durchführung eines solchen Verfahrens, ein Computerprogramm und ein computerlesbares Medium.

Description

  • Die Erfindung betrifft ein Verfahren zur Bestimmung einer Container-Konfiguration eines Systems, wobei das System ein Betriebssystem aufweist und auf dem System mehrere Software-Container vorhanden sind, die von mehreren Container-Engines verwaltet werden. Darüber hinaus betrifft die Erfindung ein System zur Durchführung eines solchen Verfahrens, ein Computerprogramm und ein computerlesbares Medium.
  • Im Bereich der allgemeinen IT hat sich die so genannte Container-Technologie bewährt. Container, die auch als Anwendungs- bzw. Software-Container bezeichnet werden können, stellen in der Regel "abgekapselte" Einheiten dar, die unabhängig voneinander ausgeführt werden können, egal wo sie sich befinden. Ähnlich wie bei virtuellen Maschinen (abgekürzt VMs) sind Container eine Art Behälter für Anwendungen, in denen diese laufen können. Während virtuelle Maschinen jedoch eine ganze Computerumgebung abbilden, enthalten die Container üblicherweise lediglich die wichtigen Daten, die für die Ausführung der jeweiligen Anwendung bzw. Anwendungen benötigt werden.
  • Die Container-Technologien bzw. die Containerisierung ermöglichen es insbesondere, eine Software bzw. Anwendung in einem Container zu verpacken, der alles umfasst, was sie zum Laufen braucht, beispielsweise Programmcode, Laufzeit, System-Tools und/oder Systembibliotheken. Die Container-Technologien bzw. Funktionen können einfach und bequem modular verpackt, transportiert und schließlich in den operativen Bereich ausgerollt werden. Container erlauben somit einen flexiblen Transport und Einsatz modularer Software in Form eigenständig ablauffähiger Bausteine ohne Abhängigkeiten zu den Software-Bibliotheken des ausführenden Betriebssystems. Klassische Einsatzgebiete von Containern liegen beispielsweise darin Applikationen, etwa eine Datenbank oder einen Web-Front-End, bequem zu verpacken.
  • Die positiven Eigenschaften können nach Ansicht der Anmelderin aber z.B. auch vorteilhaft in den Industrial Edge-Produkten der Digital Industry (DI) eingesetzt werden.
  • Beispiele für Software für die Container-Virtualisierung/Containerisierung sind etwa "Docker" oder "rkt" (gesprochen "rocket", siehe etwa https://coreos.com/rkt/sowie https://www.docker.com bzw. EP 3 267 351 A1 zu Docker ). Ein Beispiel für ein Orchestrierungssystem/-tool bzw. eine Orchestrierungs-Software für Container ist durch "Kubernetes" gegeben (siehe etwa https://kubernetes.io/ sowie https://de.wikipedia.org/wiki/Kubernetes) .
  • Die Container werden in der Regel von sogenannten "Container-Engines" verwaltet, die sich beispielsweise um das Herunterladen der benötigten Container-Abbilder und das Starten und Stoppen kümmern. Ins Deutsche übersetzt könnte man eine Container-Engine auch als Container-Maschine oder Container-Mechanik bezeichnen. Container-Engines verstecken in der Regel die technischen Details eines unterlagerten Betriebssystems, aus denen Container zur Laufzeit zusammengesetzt werden.
  • Es kann, beispielsweise aus Gründen der Systemorganisation oder Sicherheit, gewünscht oder erforderlich sein, die in einem einzelnen System, beispielsweise einer einzelnen virtuellen Maschine oder einer einzelnen "bare metal"-Installation insbesondere ohne Hypervisor (Virtual-Machine-Monitor, abgekürzt VMM) auszuführenden Container auf mehr als eine Container-Engine, etwa zwei, drei oder mehr Container-Engines aufzuteilen. Dabei können die Container-Engines sowohl Seite-an-Seite (side-by-side) als auch quasi wie Matrjoschkas ineinander geschachtelt (container-in-container) ausgeführt sein. Letztere Konfiguration ist insbesondere unter dem Namen "Docker-in-Docker" (kurz: DinD) bekannt.
  • Systemkonfigurationen mit mehreren Container-Engines verkomplizieren jedoch Diagnosen beispielsweise der Kommunikation zwischen Containern sowie Containern und der Umwelt signifikant.
  • Anwender und Entwickler wünschen sich den einfachen Umgang mit Containern wie im Falle einer einzelnen Container-Engine auch in komplexen Systemkonfigurationen mit mehreren Container-Engines in möglicherweise sogar gemischten Anordnungen Seite-an-Seite und Container-in-Container.
  • Die heute bekannten Cluster-Verwaltungs- und -Orchestrierungs-Systeme (etwa Kubernetes und Rancher, siehe beispielsweise https://en.wikipedia.org/wiki/Rancher_Labs) bieten hier keine Unterstützung. Diese Systeme gehen von dem Grundmodell aus, bei dem pro (Arbeits-)System wie etwa VM bzw. bare metal jeweils nur eine Container-Engine eingesetzt wird. Dieses schließt zwar komplexere Systemkonfigurationen nicht prinzipiell aus, diese werden jedoch nicht unterstützt.
  • Die Anmelderin erwartet, dass ein wiederkehrendes Element in verschiedenen Anwendungen im Kontext von Containern, wie beispielsweise der Kommunikation auf (virtueller) Netzwerkebene, das automatische Auffinden aller Container in einem System (VM, bare metal) auch über mehrere Container-Engines hinweg und das Bereitstellen dieser Informationen, bevorzugt angereichert um logische Hierarchie-Daten, zur weiteren Verwendung in verschiedenen Diagnose-Werkzeugen und Applikationen sein wird.
  • Bisher erfordert der Umgang und die Diagnose von Systemen mit mehreren Container-Engines detailliertes Systemwissen in verschiedenen Dimensionen wie beispielsweise Container-Engine-Tools, spezifischen Systemkonfigurationen, Betrieb von Container-Engines ihrerseits in Containern, Werkzeugen der Betriebssysteme und spezifischen Informationsquellen in den Betriebssystemen. Anwender müssen die Hierarchie von Container-Engines mental selbst erstellen und zudem verschiedene Werkzeuge mehrfach in verschiedenen Kontexten ausführen, was mit nicht unbeachtlichem Aufwand verbunden ist. Als Werkzeuge in diesem Kontext seien rein beispielhaft docker-inspect (siehe z.B. https://docs.docker.com/engine/reference/commandline/inspect/ ), kubectl (siehe z.B. https://kubernetes.io/de/docs/tasks/tools/install-kubectl/), grep (siehe z.B. https://de.wikipedia.org/wiki/Grep), netstat (siehe z.B. https://wiki.ubuntuusers.de/netstat/) und dergleichen genannt.
  • Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben, mittels dem für den Fall, dass in einem System Container auf mehrere Container-Engines aufgeteilt sind, die Container aufgefunden und Informationen über die hierarchische bzw. topologische Anordnung der Container und/oder Container-Engines erhalten werden kann. Das Verfahren soll sich dabei einfach durchführen lassen und im Vergleich zum Stand der Technik weniger oder gar detailliertes Systemwissen seitens der Anwender voraussetzen. Weiterhin ist es eine Aufgabe der Erfindung ein System anzugeben, welches für die Durchführung eines solchen Verfahrens geeignet ist.
  • Die erstgenannte Aufgabe wird gelöst durch ein Verfahren zur Bestimmung einer Container-Konfiguration eines Systems, wobei das System ein, bevorzugt genau ein Betriebssystem aufweist und auf dem System mehrere Software-Container vorhanden sind, die von mehreren Container-Engines verwaltet werden, wobei bevorzugt jeder Container von genau einer der Container-Engines verwaltet wird,
    bei dem mittels eines Discovery-Moduls
    1. a) die Container-Engines erfasst werden, wobei in einem Prozessbaum des Betriebssystems des Systems zu den Container-Engines gehörige Container-Engine-Prozesse ermittelt werden,
    2. b) für die erfassten Container-Engines Steuerkanäle ermittelt werden, über welche die Container-Engines angesprochen werden können,
    3. c) unter Nutzung zumindest einiger der Steuerkanäle ermittelt wird, welche Container zu welchen Container-Engines gehören und welche Prozesskennungen die Container jeweils aufweisen, und
    4. d) für eine oder mehrere der Container-Engines ein Pfad erstellt wird, wobei ermittelt wird, ob in dem Prozessbaum ausgehend von der Prozesskennung der oder der jeweiligen Container-Engine in Richtung der Prozessbaumwurzel eine oder mehrere Prozesskennungen vorhanden sind, welche jeweils zu einem der in Schritt c) ermittelten Container gehören, Container-Prozesskennungen, und für den Fall, dass eine oder mehrere Container-Prozesskennungen vorhanden sind, eine Kennung, insbesondere ein Name des zugehörigen Containers bzw. Kennungen, insbesondere Namen der zugehörigen Container in den Pfad der oder der jeweiligen Container-Engine aufgenommen wird bzw. werden.
  • Die zweitgenannte Aufgabe wird gelöst durch ein System, das zur Durchführung des erfindungsgemäßen Verfahrens ausgebildet und/oder eingerichtet ist.
  • Das erfindungsgemäße System zeichnet sich bevorzugt dadurch aus, dass auf diesem mehrere Software-Container vorhanden sind, die von mehreren Container-Engines verwaltet werden, wobei bevorzugt jeder Container von genau einer der Container-Engines verwaltet wird, und dass das System ein Betriebssystem umfasst und ein Discovery-Modul, das dazu ausgebildet und/oder eingerichtet ist,
    1. a) die Container-Engines zu erfassen, wobei in einem Prozessbaum des Betriebssystems des Systems zu den Container-Engines gehörige Container-Engine-Prozesse ermittelt werden,
    2. b) für die erfassten Container-Engines Steuerkanäle zu ermitteln, über welche die Container-Engines angesprochen werden können,
    3. c) unter Nutzung zumindest einiger der Steuerkanäle zu ermitteln, welche Container zu welchen Container-Engines gehören und welche Prozesskennungen die Container jeweils aufweisen, und
    4. d) für eine oder mehrere der Container-Engines einen Pfad zu erstellen, wobei ermittelt wird, ob in dem Prozessbaum ausgehend von der Prozesskennung der oder der jeweiligen Container-Engine in Richtung der Prozessbaumwurzel eine oder mehrere Prozesskennungen vorhanden sind, welche jeweils zu einem der in Schritt c) ermittelten Container gehören, Container-Prozesskennungen, und für den Fall, dass eine oder mehrere Container-Prozesskennungen vorhanden sind, eine Kennung, insbesondere ein Name des zugehörigen Containers bzw. Kennungen, insbesondere Namen der zugehörigen Container in den Pfad der oder der jeweiligen Container-Engine aufgenommen wird bzw. werden.
  • Der Erfindung liegt mit anderen Worten die Idee zugrunde, einen Discovery-Service bereitzustellen, mittels dem einerseits automatisch die aktuell in einem System auch mit mehreren Container-Engines vorhandenen Container ermittelt werden können, und es andererseits möglich ist, ebenfalls automatisch, Informationen zu der logischen Hierarchie bzw. Topologie zu erfassen. Der Discovery-Service wird dabei von dem Discovery-Modul bereitgestellt. Die logische Hierarchie bzw. Topologie wird dabei insbesondere anhand der konkreten Anordnung der aufgefundenen Container-Engines gestaltet.
  • Sollten Container bzw. Container-Engines ausschließlich in einer Side-by-Side-Anordnung vorhanden sein, liegt streng genommen keine Hierarchie mit über- und unterlagerten Engines vor, weshalb der allgemeinere Begriff Topologie vor allem in diesem Falle passender ist.
  • Bevorzugt erstellt das Discovery-Modul ein Datenmodell, das alle in Schritt c) ermittelten Container aufführt.
  • Der Discovery-Service und somit Discovery-Modul erstellt mit anderen Worten in bevorzugter Ausgestaltung ein aktuelles Datenmodell, das alle aufgefundenen Container in einem einzelnen System auch über verschiedene Container-Engines hinweg aufführt. Zusätzlich bestimmt der Discovery Service bevorzugt eine logische Hierarchie bzw. Topologie der Container-Engines, insbesondere über die Erstellung der Pfade. Wird von dem Discovery-Modul ein Datenmodell erstellt, umfasst dieses entsprechend bevorzugt auch den oder die in Schritt d) erstellten Pfade. Das Datenmodell umfasst besonders bevorzugt, welche Prozesskennung der jeweilige Container hat und welcher der erstellten Pfade zu dem jeweiligen Container gehört. Mit anderen Worten kann bevorzugt für jeden Container dessen Prozesskennung und der dem Container zugehörige Pfad abgelegt sein. Dies ist der Pfad, welcher für diejenige Container-Engine erstellt wurde, welcher der jeweilige Container zugeordnet ist.
  • Die erfindungsgemäße Vorgehensweise bietet diverse Vorteile. Sie stellt einen universellen Basisdienst zur Container Discovery in verschiedenen Systemkonfigurationen bereit, auf dem dann spezialisierte Diagnosewerkzeuge und Anwendungen einfach aufbauen können. Die Erfindung kann somit einen wichtigen Baustein beispielsweise für Diagnose und Überwachung der Container-Kommunikation etwa in industriellen Clustern mit Industrial Edge-Geräten bilden. Es wird ein einfacher, eindeutiger Umgang mit Containern auch in komplexen Systemkonfigurationen von Arbeitsknoten (bspw. Industrial Edges) mit mehreren Container-Engines im gleichen System in verschiedenen Anordnungen möglich. Es können erstmalig Konfigurationen abgedeckt werden, die durch die konventionellen, vorbekannten Management- und Orchestrierungswerkzeuge nicht erfasst werden. Die Komplexität von Systemkonfigurationen wird dabei vor dem Anwender versteckt und diesem wird erlaubt, auf der von ihm gewünschten einfachen Abstraktionsebene der Container zu arbeiten, ganz ohne unnötiges Detailwissen über Systemkonfigurationen. Anwender brauchen kein detailliertes Wissen, da der erfindungsgemäße Discovery-Prozess automatisch abläuft. Das automatische Auffinden der vorhandenen Container-Engines (und Steuerkanälen) erfolgt dabei bevorzugt allein anhand der lokal verfügbaren Informationen des Betriebssystems und bevorzugt wird automatisch eine Container-Hierarchie bzw. - Topologie anhand der vorgefundenen aktuellen Anordnung ("Schachtelung") von Container-Engines in Containern generiert.
  • Durch die Erfindung wird es u.a. möglich, zu erfassen, ob sich Container-Engines in einer Side-by-Side Anordnung befinden und/oder ob sich Container-Engines in einer Container-in-Container-Anordnung befinden.
  • Dabei können beispielsweise drei Container-Engines vorhanden sein, die jeweils zwei Container verwalten. Zweckmäßiger Weise gilt, dass jeder Container von genau einer der Container-Engines verwaltet wird. Bei dem genannten Beispiel wären dann sechs Container vorhanden.
  • Es kann sein, dass wenigstens zwei Container-Engines in einer Side-by-Side-Anordnung und/oder wenigstens zwei Container-Engines in einer Container-in-Container-Anordnung vorgesehen sind. Sind drei Container-Engines vorhanden, können beispielsweise zwei Container Side-by-Side, insbesondere in einer Hierarchieebene liegen, und die dritte Container-Engine in einem Container einer der beiden Side-by-Side Engines, so dass sich die dritte Engine mit dieser Engine in einer Container-in-Container-Konfiguration befindet.
  • Dass ein Container vorhanden ist, kann beispielsweise bedeuten, dass dieser (erst einmal nur) erzeugt ist, insbesondere ohne dass in ihm schon Prozesse gestartet worden sind bzw. laufen. Der Container ist dann insbesondere (nur) konfiguriert. Weiterhin können die Prozesse in einem Container bereits beendet worden sein, der Container aber verwaltungstechnisch noch erkennbar sein. Zudem kann ein Container mit Prozessen auch angehalten (sozusagen eingefroren) sein. Alternativ oder zusätzlich können auch Container in diesem "Zustand" als vorhanden aufgefasst und Schritt c) ermittelt werden.
  • Diese Dualität von "erzeugt" versus "läuft" ist besonders bei containerd (https://containerd.io/) sichtbar. Hier wird zwischen dem "Container" als konfiguriertes Element und seiner Ausführung als sog. "Task" unterschieden. Beide Sichten sind hierbei über die identische ID miteinander verknüpft. In beiden Fällen ist der betreffende Container im Sinne der vorliegenden Anmeldung vorhanden.
  • Vorzugsweise wird bei der Erfassung der Container auf alle konfigurierten Container abgestellt. Sollte von vornherein bekannt sein, dass Interesse beispielsweise nur an laufenden Containern besteht, kann alternativ dazu beispielsweise nur auf laufende Container abgestellt werden.
  • Der Prozessbaum führt insbesondere in an sich bekannter Weise die Prozesse auf, bevorzugt sämtliche Prozesse, die aktuelle auf dem System laufen. Der Prozessbaum kann prinzipiell auch in Tabellenform vorliegen (man spricht dann auch von einer Prozesstabelle), welche die Prozesse und die Informationen über die Baumstruktur enthält, insbesondere Informationen, welche Prozesse jeweils Elternprozesse (englisch: Parent Processes) eines anderen Prozesses sind. Im Zusammenhang mit dem Prozessbaum (bzw. der Prozesstabelle) sei beispielhaft auch auf https://de.wikipedia.org/wiki/Procfs verwiesen.
    Die Prozesskennung ist bevorzugt in an sich bekannter Weise eine Kennung, die der eindeutigen Identifikation von Prozessen dient. Sie wird auch Process Id oder abgekürzt PID bezeichnet. Zur Prozesskennung siehe z.B. https://de.wikipedia.org/wiki/Process_identifier. Die Prozesskennung eines Elternprozesses wird auch als Parent Process ID oder kurz PPID bezeichnet.
  • Bei dem erfindungsgemäßen System kann es sich beispielsweise um einen PC, etwa Industrie-PC handeln. Das System kann in Form eines Arbeitsknotens eines insbesondere industriellen Clusters gegeben sein. Es kann sich auch um eine sogenannte Industrial Edge bzw. ein sogenanntes Industrial-Edge-Gerät handeln. Unter einer Edge bzw. einem Edge-Gerät ist insbesondere ein Gerät zu verstehen, welches die bzw. wenigstens eine Funktion des Edge-Computings ausführt (zum Edge-Computing siehe z.B. https://de.wikipedia.org/wiki/Edge_Computing). Ein Industrial-Edge-Gerät kann beispielsweise durch einen Industrie-Computer gegeben sein, der eine Edge-Computing Funktion ausführt. In einem Cluster mit mehr als einem Arbeitsknoten ist bevorzugt jedem Knoten ein Discovery-Modul vorgesehen bzw. implementiert.
  • Es kann ferner sein, dass das erfindungsgemäße System durch eine virtuelle Maschine (VM) gegeben ist oder eine solche umfasst. Auch für den Fall, dass das erfindungsgemäße System in Form einer virtuellen Maschine (VM) vorliegt, weist dieses bevorzugt ein Betriebssystem, insbesondere genau ein Betriebssystem auf.
  • Dass mehrere Container-Engines, beispielsweise zwei oder drei oder mehr Container-Engines vorhanden sind, bedeutet insbesondere bzw. schließt insbesondere mit ein, dass die vorhandenen Container in zwei oder mehr Verwaltungsbereiche partitioniert sind und zu jedem Bereich eine eigene (Instanz einer) Container-Engine gehört.
  • Eine Container-Engine kann beispielsweise durch eine Docker-Engine gegeben sein (siehe z.B. https://docs.docker.com/engine/). Eine Docker-Engine kann einen Docker Daemon und einen Container Daemon umfassen. Sie kann ferner die Container-Runtime runC umfassen. Zu runC siehe beispielsweise https://blog.docker.com/2017/08/what-iscontainerd-runtime/).
  • Eine Container-Engine kommt in der Regel insbesondere dafür zum Einsatz, API/Nutzer-Schnittstellen bereitzustellen und/oder Container-Images zu erzeugen und/oder Konfigurationen bzw. Konfigurationsdateien bereitzustellen, beispielsweise eine config.json.
  • Dass eine Container-Konfiguration des Systems bestimmt wird bedeutet insbesondere oder schließt insbesondere mit ein, dass die vorhanden Container-Engines und Container ermittelt und eine Topologie bzw. Hierarchie der Container-Engines ermittelt wird. Es sei angemerkt, dass unter einer Container-Konfiguration auch ein Container-Deployment oder deutsch Container-Einsatz zu verstehen sein bzw. eine Container-Konfiguration ein Container-Deployment bzw- -Einsatz umfassen kann.
  • Das erfindungsgemäß vorgesehene Discovery-Modul überwacht bevorzugt das Betriebssystem und die Container-Engines. Die Überwachung erfolgt zweckmäßigerweise weitestgehend bzw. voll automatisch.
  • Das Discovery-Modul ist besonders bevorzugt auf dem System vorgesehen, dessen Container-Engines und zugehörige Container zu erfassen sind. Das Discovery-Modul kann beispielsweise in Software oder in Hardware oder in einer Kombination aus Software und Hardware implementiert sein. Ein Discovery-Modul kann beispielsweise als Software-Module auf dem System implementiert sein. Es kann ein "einfacher" Prozess sein, der bevorzugt in das System integriert oder installiert ist. Es kann beispielsweise auch seinerseits als Container installiert und ausgeführt werden.
  • Ist für mehrere Systeme eine Container-Discovery erwünscht bzw. erforderlich, ist bevorzugt jedem System ein eigenes Discovery-Modul zugeordnet, insbesondere auf jedem System ein eigenes Discovery-Modul implementiert.
  • Von dem Discovery-Modul werden die auf dem (jeweiligen) System vorhandenen Container-Engines erfasst. Container-Engines können beispielsweise anhand deren Namen (z.B. "dockerd") bzw. anhand von Teilen von deren Namen erkannt werden. Das Discovery-Modul kann in vorteilhafter Ausführung entsprechend ausgebildet und/oder eingerichtet sein. Es ist auch möglich, dass das Discovery-Modul eine Liste mit bekannten Namen bzw. bekannten Teilen von Namen von Container-Engine-Prozessen im Prozessbaum des Betriebssystems heranzieht. Container-Engines können alternativ oder zusätzlich auch über bekannte Prozesseigenschaften dieser gefunden werden. Es kann auch bekannt sein, welche Größe diese aufweisen, bzw. in welchem Bereich deren Größe liegt. Dann kann eine Suche bzw. Identifikation über die Größe erfolgen. Das Discovery-Modul kann in Weiterbildung entsprechend ausgebildet und/oder eingerichtet sein.
  • Besonders bevorzugt werden in Schritt a) auch die Prozesskennungen der Container-Engine-Prozesse der Container-Engines ermittelt.
  • Das Ergebnis der Suche bzw. der Container-Engine-Erfassung ist insbesondere eine Liste von Prozesskennungen aktuell laufender Container-Engines, insbesondere aller aktuell laufender Container-Engines.
  • Für die erfassten Container-Engines werden von dem Discovery-Modul in Schritt b) Steuerkanäle ermittelt, über welche die Container-Engines angesprochen werden können bzw. könnten. Diese Steuerkanäle können auch als mögliche Steuerkanäle erachtet und bezeichnet werden. Steuerkanäle können beispielsweise durch sogenannte Unix Sockets, insbesondere Control Unix Sockets gegeben sein. Zu Unix Sockets siehe beispielsweise https://de.wikipedia.org/wiki/POSIX_local_inter-process_communication_socket.
  • Vorteilhafter Weise ist das Ergebnis für jede einzelne Container-Engine zunächst eine eigene (zweckmäßiger Weise geordnete) Liste von potenziellen, möglichen Steuerkanälen, über die die jeweilige Container-Engine angesprochen werden könnte. Je nach Art einer Container Engine existieren möglicherweise mehrere Steuerkanäle für diese, wobei jeder Steuerkanal möglicherweise andere Funktionen bereitstellt. Es kann sein, dass nicht jeder Steuerkanal die Funktionalität bereitstellt, um auf die Liste der Container einer Container-Engine zuzugreifen.
  • Es kann vorgesehen sein, dass in Schritt b) das Ermitteln der Steuerkanäle einschließt, dass in Mount-Namensräume der Container-Engines jeweils diejenigen Steuerkanäle, insbesondere Unix Sockets, bevorzugt zusammen mit ihren inode-Nummern und ihren Pfaden im Dateisystem erfasst bzw. ermittelt werden, die sich im Zustand "listen" befinden. Das Erfassen bzw. Ermitteln der Steuerkanäle, insbesondere Unix Sockets kann dabei anhand von Informationen aus /sys/net/unix erfolgen. Unter http://man7.org/linux/man-pages/man2/listen.2.html beispielsweise ist die API-Funktion "listen(2)" beschrieben, mit der u.a. ein Unix Socket in den Zustand LISTEN versetzt wird.
  • Bevorzugt werden anschließend der Reihe nach Handle, insbesondere Dateideskriptoren ("fd"), der Container-Engines anhand ihrer inode-Nummern darauf bzw. dahingehend geprüft, ob sie auf einen der zuvor ermittelten, sich im Zustand "listen" befindlichen Steuerkanäle, insbesondere Unix Sockets, verweisen. Dabei wird insbesondere auf offene Handle, bevorzugt offene Dateideskriptoren abgestellt. Weiter bevorzugt werden nur diejenigen Steuerkanäle als Steuerkanäle bzw. mögliche Steuerkanäle erachtet und erfasst, für welche dies zutrifft, welche also auf einen der zuvor ermittelten Steuerkanäle im Zustand "listen" verweisen.
  • Zu inode-Nummern (auch Inodenummern geschrieben) siehe beispielsweise https://de.wikipedia.org/wiki/Inode.
  • Die Mount-Namensräume (englisch: mount namespaces) sind insbesondere - in an sich aus dem Stand der Technik vorbekannter Weise - Namensräume des Betriebssystems bzw. Betriebssystem-Kernels, beispielsweise Linux- bzw. Linux-Kernel-Namensräume (siehe z.B. https://en.wikipedia.org/wiki/Linux_namespaces). Zu Handlen siehe zum Beispiel https://de.wikipedia.org/wiki/Handle und zu Dateideskriptoren (englisch: file descriptors, abgekürzt fd) beispielsweise https://en.wikipedia.org/wiki/File_descriptor. Dateideskriptoren sind insbesondere sozusagen "Anfasser" für Datenkanäle zu Dateien, Geräten, Unix sockets, etc.
  • In Schritt c) werden von dem Discovery-Modul zu den von diesem erfassten Container-Engines gehörige Container ermittelt. Bevorzugt werden alle Container von allen Container-Engines ermittelt. Es ist natürlich möglich, dass der Versuch der Container-Ermittlung für wenigstens eine der Engines fehlschlägt. Somit kann es durchaus sein, dass nur für einige, ggf. sogar nur für eine Engine die zugehörigen Container erfasst werden.
  • Zweckmäßiger Weise werden auch die zu den Containern gehörigen Prozesskennungen ermittelt, sowie bevorzugt zu den Containern gehörige Namen, insbesondere Namen, die Container aus applikativer Sicht und/oder anwenderseitig gegeben wurden.
  • In besonders bevorzugter Ausgestaltung wird in Schritt c) für die oder die jeweilige Container-Engine in dem Mount-Namensraum dieser versucht, über den oder die Steuerkanäle die Container-Engine zu kontaktieren und den oder die dieser zugeordneten Container abzufragen. Diejenigen Steuerkanäle, über welche dies gelingt, können als geeignete Steuerkanäle aufgefasst und bezeichnet werden. Sofern möglich, werden zweckmäßiger Weise über den oder die für die (jeweilige) Container-Enge ermittelten (möglichen) Steuerkanäle die zugehörigen Container sowie bevorzugt jeweils die Prozesskennungen und Namen dieser abgefragt.
  • Um dies für mehrere, insbesondere alle Container-Engines durchzuführen, kann der Reihe nach in die Mount-Namensräume von mehreren, etwa zwei oder mehr, bevorzugt allen Container-Engines gewechselt werden, wobei jeweils für den Fall, dass die einer Container-Engine zugeordneten Container sowie bevorzugt deren Prozesskennungen und Namen ausgelesen werden konnten oder auch über keinen der Steuerkanäle der Container-Engine deren Container ausgelesen werden konnten, in den Mount-Namensraum der nächsten Container-Engine gewechselt und versucht wird, die zugeordneten Container dieser zu ermitteln.
  • So kann der Reihe nach von Mount-Namensraum zu Mount-Namensraum der laufenden Container-Engines gewechselt werden, bis alle vorhandenen Engines durch sind. Nach der letzten Container-Engine findet zweckmäßiger Weise kein weiterer Wechsel mehr statt.
  • Zur Ermittlung von Hierarchie- bzw. Topologie-Informationen wird bevorzugt die Verteilung der zu Containern gehörigen Container-Prozesskennungen über den Prozessbaum des Betriebssystems herangezogen.
  • In Schritt d) wird von dem Discovery-Modul für eine oder mehrere der Container-Engines ein Pfad erstellt. Bevorzugt wird für jede erfasste Engine ein Pfad erstellt. Es ist natürlich denkbar, dass dies für wenigstens eine der erfassten Engines nicht möglich ist, beispielsweise, weil es bereits nicht möglich war, einen oder mehrere Steuerkanäle für diese zu finden bzw. deren Container nicht über diese erfasst werden konnten.
  • Unter einem Pfad ist insbesondere eine hierarchische Kennung bzw. eine Kennung zu verstehen, aus der eine Hierarchie bzw. Hierarchie-Informationen abzuleiten ist bzw. sind, insbesondere aufgrund der Reihenfolge von in dem Pfad bzw. der Kennung enthaltenen Bestandteilen. Im Rahmen der vorliegenden Anmeldung ist unter einer hierarchischen Information bzw. Hierarchieinformation für eine Container-Engine insbesondere eine bzw. die Information zu verstehen, ob die Container-Engine Matrjoschka-artig in einen oder mehrere Container "verschachtelt" ist oder nicht, was man zweckmäßiger Weise dem für die Container-Engine erstellten Pfad entnehmen kann, insbesondere auch, "wie viele Container tief" die Container-Engine liegt. Ein Pfad kann durch einen hierarchischen Namen mit anderen Worten Hierarchienamen gegeben sein. Insbesondere aus dem Vergleich bzw. der Betrachtung der Pfade mehrerer, bevorzugt aller vorhandener Container-Engines kann die gesamte Hierarchie bzw. Topologie ermittelt bzw. dargestellt bzw. abgeleitet werden.
  • Besonders bevorzugt wird in dem Prozessbaum ausgehend von der Prozesskennung der jeweils betrachteten Container-Engine in Richtung der Wurzel des Prozessbaums gesucht, und für jede zu einem der in Schritt c) ermittelten Container gehörende Prozesskennung (Container-Prozesskennung) wird eine Kennung desjenigen Containers, dessen Container-Prozesskennung (jeweils) gefunden wurde, dem bisherigen, zu Beginn der Suche insbesondere leeren Pfad hinzugefügt, bevorzugt vorangestellt.
  • Es ist prinzipiell möglich, dass der jeweilige Pfad auch noch den bzw. eine Kennung, insbesondere den bzw. einen Namen der Container-Engine erhält, der zum Beispiel "dockerd" lauten kann. Für das vorgenannte Beispiel würde sich dann als Pfad "dockerd/outer" ergeben.
  • Es sei angemerkt, dass es sich bei der bzw. den Kennungen von Containern und/oder von Container-Engines, die den Pfaden hinzugefügt, also für die Pfaderstellung genutzt werden prinzipiell um Kennungen bzw. Kennzeichnungen bzw. Bezeichnungen beliebiger Art handeln kann. Besonders bevorzugt handelt es sich um Namen der Container und/oder Container-Engines, über welche diese unterscheidbar sind. Bei den Namen kann es sich um Wörter handeln. Die Namen können z.B. ausschließlich Buchstaben umfassen, dies ist jedoch nicht zwingend erforderlich. Namen können prinzipiell alternativ oder zusätzlich zum Beispiel auch Ziffern oder andere Zeichen aufweisen.
  • Es sei angemerkt, dass alternativ oder zusätzlich zu Namen als Kennungen der Container und/oder Container-Engines prinzipiell auch deren Prozesskennungen für die Pfade verwendet werden können. Insbesondere da sich diese ggf. auch ändern können, ist es in der Regel jedoch vorteilhaft anderen Kennungen, bevorzugt Container-(Engine-)Namen in die Pfade aufzunehmen, besonders bevorzugt solche, die von einem Anwender vergeben wurden und/oder die auch für den Fall, dass ein Container beendet und anschließend neu gestartet wird, gleich bleiben.
  • Der Name eines Containers wird bevorzugt von der jeweiligen Container-Engine verwaltet, zu welcher der Containergehört, und kann beispielsweise auch automatisch generiert oder auch durch ein Container-Orchestrierungs-System vorgegeben werden bzw. worden sein.
  • Weiterhin können alternativ oder zusätzlich dazu, dass Namen der Container als Kennungen in die Pfade aufgenommen, also für die Pfaderstellung genutzt werden, beispielsweise auch UUIDs und/oder UIDs als Kennungen der Container zum Einsatz kommen. UUID steht dabei in an sich bekannter Weise für Universally Unique Identifier (siehe beispielsweise https://de.wikipedia.org/wiki/Universally_Unique_Identifier) und UID für Unique Identifier.
  • Es ist auch nicht ausgeschlossen, dass jeweils mehrere Kennungen, die einem Container bzw. einer Container-Engine zugeordnet sind, dem (jeweiligen) Pfad hinzugefügt werden. In der Regel wird jedoch eine Kennung, etwa der Name ausreichen. Entsprechend wird bevorzugt pro gefundener Container-Prozesskennung genau eine Kennung des zugehörigen Containers in den (jeweiligen) Pfad aufgenommen.
  • Eine besonders bevorzugte Ausführungsform zeichnet sich ferner dadurch aus, dass in Schritt d) für die oder die jeweilige Container-Engine zunächst ein leerer Pfad oder Ursprungspfad angenommen und insbesondere zunächst als leerer Pfad oder Ursprungspfad initialisiert wird (beispielsweise: Python: p = ""; Golang: p := "", usw.). Für den Fall, dass für eine Container-Engine eine oder mehrere Container-Prozesskennungen gefunden werden, kann dann beispielsweise die Kennung, insbesondere der Name bzw. können dann beispielsweise die Kennungen, insbesondere die Namen der zugehörigen Container dem (jeweiligen) leeren Pfad bzw. Ursprungspfad hinzugefügt werden. Für den Fall, dass für eine Container-Engine hingegen keine Container-Prozesskennungen gefunden wird, wird dieser Engine zweckmäßiger Weise der leere Pfad bzw. Ursprungspfad zugeordnet. Ein leerer Pfad bzw. Ursprungspfad kann beispielsweise durch "" oder "/" gegeben sein.
  • Der Pfad der oder der jeweiligen Container-Engine ist insbesondere die Aneinanderreihung der Kennungen, insbesondere Namen der bei dem "Klettern" entlang des Prozessbaums bzw. Prozessbaum-Astes gefundenen Container bevorzugt in umgekehrter Reihenfolge. Wenn beispielsweise ein Container die Kennung bzw. der Name "outer" zugewiesen bekam, und dieser eine Container-Engine umfasst bzw. beinhaltet, dann bekommt die beinhaltete Container-Engine - und bevorzugt auch die dieser zugeordneten, insbesondere die von dieser verwalteten Container - den Pfad "outer" zugeordnet.
  • Wenn in Schritt d) für eine Container-Engine mehr als eine Container-Prozesskennung in dem Prozessbaum gefunden wird, etwa zwei oder drei oder mehr Container-Prozesskennungen gefunden werden, werden die zugehörigen Kennungen, insbesondere Namen besonders bevorzugt in umgekehrter Reihenfolge in den Pfad aufgenommen als die Container-Prozesskennungen ausgehend von der Prozesskennung der Container-Engine in Richtung der Prozessbaumwurzel in dem Prozessbaum vorhanden sind. Dies entspricht insbesondere der zum Auffinden der Container-Prozesskennungen umgekehrten Reihenfolge. Das bedeutet insbesondere, dass die Kennung, etwa der Name des zu der zuletzt gefundenen Container-Prozesskennung gehörigen Containers ganz links in der Pfadbezeichnung steht, derjenige der zuerst gefundenen hingegen ganz rechts.
  • Die Suche in dem Prozessbaum erfolgt zweckmäßiger Weise so lange, bis die oberste Prozesskennung des Prozessbaums bzw. die Wurzel erreicht ist. Damit ist die Suche für die betrachtete Container-Engine beendet und der Pfad fertig. Wird auf dem Weg von der Prozesskennung der betrachteten Container-Engine bis zur Wurzel keine Prozesskennung eines Containers gefunden, bedeutet dies, dass die Container-Engine nicht ihrerseits in einem Container liegt, sozusagen nicht in einen (oder auch mehrere) Container verschachtelt ist.
  • Es kann vorteilhaft sein zu vermeiden, dass zwei oder mehr der Container-Engines der gleiche Pfad zugeordnet wird.
  • In weiterer vorteilhafter Ausgestaltung ist daher vorgesehen, dass für den Fall, dass für die Container-Engines erstellten Pfade zwei oder mehr identische Pfade umfassen, eine Vereinzelung der Pfade durchgeführt wird. Die Vereinzelung der Pfade kann beispielsweise erfolgen, indem (jeweils) identischen Pfaden unterschiedliche zusätzliche Pfadbestandteile hinzugefügt werden. Als zusätzliche Pfadbestandteile zum Erhalt einer Vereinzelung kommen beispielsweise die Prozesskennung und/oder der Name der Container-Engine, für welche der jeweilige Pfad erstellt wurde, in Frage. Dies ist rein beispielhaft zu verstehen und es können selbstverständlich auch andere Bestandteile in identische Pfade eingefügt werden, um diese zu vereinzeln. Die einzige Anforderung ist, dass durch die Vereinzelungs-Maßnahme aus zwei oder mehr identischen Pfaden zwei oder mehr verschiedene Pfade erhalten werden.
  • Zum Erhalt der Pfadvereinzelung zusätzliche Bestandteile werden bevorzugt am hinteren, rechten Ende des Pfades hinzugefügt.
  • Der Fall, dass in Schritt d) für zwei oder auch mehr Container-Engines der gleiche Pfad erstellt wird, tritt insbesondere dann auf, wenn zwei oder mehr Container-Engines nebeneinander (Side-by-Side) in einem Container - oder auch auf der obersten Hierarchieebene - liegen. In diesem Fall werden bei dem "Klettern" entlang des Prozessbaums die gleichen Container-Prozesskennungen - oder auch keine Prozesskennungen - gefunden und entsprechend den Pfaden die gleichen Kennungen, insbesondere Namen der zugehörigen Container - oder auch keine Kennungen bzw. Namen - hinzugefügt, so das sich zwei oder auch mehr gleiche Pfade ergeben.
  • In bevorzugter Ausgestaltung prüft das Discovery-Modul insbesondere im Anschluss an die Erstellung aller Pfade in Schritt d), ob Pfade mehrfach vorhanden sind. Ergibt die Prüfung, dass dem so ist, vereinzelt bevorzugt das Discovery-Modul die Pfade.
  • Die Pfad-Vereinzelung erfolgt in besonders vorteilhafter Ausgestaltung derart, dass mit den kürzesten identischen Pfaden begonnen wird. Wird bzw. wurde zum Beispiel zwei oder mehr Container-Engines jeweils ein "leerer" Pfad bzw. ein Ursprungspfad zugeordnet, z.B. "/" oder "", werden bevorzugt zunächst diese vereinzelt und im Anschluss gegebenenfalls vorhandenen längere Pfade, zum Beispiel "/Outer" bzw. "/Outer/Inner".
  • Zweckmäßiger Weise werden für die Vereinzelung in kürzeren Pfaden durchgeführte Anpassungen in gegebenenfalls vorhandene, von den kürzeren Pfaden abhängige länger Pfade übernommen. Befindet sich beispielsweise eine Container-Engine mit dem Namen "A" in der obersten Hierarchie-Ebene und wird dieser der Pfad "/" zugeordnet und vereinzelt, indem die Prozesskennung dieser Container-Engine, z.B. "42", dem Pfad hinzugefügt wird, wodurch dann z.B. "/42" erhalten würde, und liegt in einem Container dieser Engine eine weitere Container-Engine, für welche entsprechend den Pfad "/A" in Schritt d) erstellt wurde, wird dieser abhängige Pfad "/A" bevorzugt zu "/42/A" angepasst.
  • In vorteilhafter Ausgestaltung überprüft das Discovery-Modul, nachdem es ein erstes Mal zwei oder auch mehr insbesondere kürzeste identische Pfade gefunden und vereinzelt und gegebenenfalls davon abhängige Pfade entsprechend angepasst hat, wenigstens ein weiteres Mal, ob noch identische Pfade vorhanden sind und vereinzelt dann auch diese. Dies kann so oft wiederholt werden, bis keine identischen Pfade mehr gefunden werden.
  • Eine weitere besonders vorteilhafte Ausführungsform zeichnet sich ferner dadurch aus, dass die in Schritt d) für die oder die jeweilige Container-Engine ermittelten und gegebenenfalls vereinzelten Pfade gespeichert werden, beispielsweise in dem Discovery-Modul bzw. einem Datenmodell des Discovery-Moduls. Ein Datenmodell ist bevorzugt durch die Pfade zusammen mit ihrer Zuordnung zu den einzelnen Containern und Container-Engines gegeben bzw. umfasst dies.
  • Alternativ oder zusätzlich wird der der bzw. werden die in Schritt d) für die oder die jeweilige Container-Engine ermittelten und gegebenenfalls vereinzelten Pfade in den Daten des oder der zugehörigen Container gespeichert. Bevorzugt wird in den Daten jedes einer Container-Engine zugeordneten Containers der Pfad der jeweiligen Engine abgelegt. So wird es möglich, dass insbesondere auch später noch eine einfache und eindeutige Zuordnung (jeweils) zwischen einem einzelnen Container und seiner Container-Engine zur Verfügung steht.
  • Dann kann wenigstens eine weitere Instanz, beispielsweise wenigstens ein Diagnose-Werkzeug, etwa ein solches, das die ermittelte Topologie einem Benutzer textuell oder grafisch anzeigt, auf von dem Discovery-Modul ermittelte und/oder bereitgestellte Daten, insbesondere auf ein von dem Discovery-Modul bereitgestelltes Informations- bzw. Datenmodell zugreifen.
  • Auf die bereitgestellten Daten kann beispielsweise auch von einem externen Plugin für das Aufzeichnen von Netzwerkverkehr (sog. Extcaps) zugegriffen werden. Ein solches, beispielsweise ein Wireshark-Plugin, kann ein Datenmodell des Discovery-Moduls z.B. verwenden, um einem Anwender eine Liste verfügbarer Container (insbesondere einschließlich deren Namen und Pfaden) zu präsentieren.
  • Mit anderen Worten kann ein Verfahren zur Diagnose des Netzwerkverkehrs durchgeführt werden, bei dem auf Daten zugegriffen wird, die im Rahmen der Durchführung des erfindungsgemäßen Verfahrens zur Bestimmung einer Container-Konfiguration insbesondere von dem Discovery-Modul gespeichert wurden.
  • Der Zugriff kann beispielsweise über ein REST API erfolgen. REST steht dabei für Representational State Transfer (siehe beispielsweise https://de.wikipedia.org/wiki/Representational_State_Transfer ) und API für Application Programming Interface (deutsch: Anwenderprogrammierschnittstelle, siehe beispielsweise https://de.wikipedia.org/wiki/Programmierschnittstelle) .
  • Das erfindungsgemäße System kann in vorteilhafter Ausgestaltung ausgebildet und/oder eingerichtet sein, um eines oder mehrere der vorstehend beschriebenen bevorzugten Merkmale zu realisieren. Soweit die vorstehen beschrieben Merkmale das Discovery-Modul betreffen, gilt, dass das Discovery-Modul in bevorzugter Weiterbildung entsprechend ausgebildet und/oder eingerichtet sein kann. Das erfindungsgemäße System kann entsprechend der abhängigen Verfahrensansprüche weitergebildet sein.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist ein Computerprogramm umfassend Programmcode-Mittel, die bei der Ausführung des Programms auf wenigstens einem Computer den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Verfahrens durchzuführen.
  • Darüber hinaus betrifft die Erfindung ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigstens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Verfahrens durchzuführen.
  • Bei dem computerlesbaren Medium kann es sich beispielsweise um eine CD-ROM oder DVD oder einen USB oder Flash Speicher handeln. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht ausschließlich ein körperliches Medium zu verstehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.
  • Weitere Merkmale und Vorteile der vorliegenden Erfindung werden anhand der nachfolgenden Beschreibung erfindungsgemäßer Ausführungsformen unter Bezugnahme auf die beiliegende Zeichnung deutlich. Darin ist
    • Figur 1
    eine rein schematische Darstellung eines Ausführungsbeispiels eines erfindungsgemäßen Systems;
    Figur 2
    ein rein schematisches Diagramm zu einem Ausführungsbeispiel des erfindungsgemäßen Verfahrens;
    Figur 3
    eine rein schematische Darstellung des Prozessbaums des Systems aus Figur 1 mit darunter dargestellten Container-Engines und Containern des Systems;
    Figur 4
    die Darstellung aus Figur 3, wobei für die Container und Container-Engines die ermittelten Pfade eingetragen sind; und
    Figur 5
    die Darstellung gemäß Figur 4 für den Fall, dass identische Pfade vereinzelt werden.
  • Die Figur 1 zeigt in rein schematischer, stark vereinfachter Darstellung ein Ausführungsbeispiel eines erfindungsgemäßen Systems S. Vorliegend handelt es sich bei diesem um ein Industrial-Edge-Gerät, welches einen Arbeitsknoten eines industriellen Clusters bildet. Der Cluster umfasst bevorzugt in an sich bekannter Weise eine Mehrzahl von Systemen 1 der in Figur 1 dargestellten Art, die beispielsweise an einem industriellen Netzwerk, etwa einer industriellen Automatisierungsanlage, teilnehmen. Das System 1 bzw. die Systeme 1 sind vorliegend jeweils durch einen Industrie-Computer gegeben, der eine Edge-Computing Funktion ausführt.
  • Dies ist nicht einschränkend zu verstehen. Ein erfindungsgemäßes System kann alternativ dazu beispielsweise auch durch eine virtuelle Maschine (VM) gegeben sein. Ein Cluster kann mehrere virtuelle Maschinen als Arbeitsknoten umfassen, die jeweils ein Ausführungsbeispiel eines erfindungsgemäßen Systems darstellen.
  • Das System S weist genau ein Betriebssystem OS auf, welches bei dem dargestellten Beispiel durch Linux gegeben ist.
  • Auf dem System S sind mehrere Software-Container, vorliegend Docker-Container C1-C7 vorhanden, die im Folgenden kurz als Container C bezeichnet werden. Die Container C1-C7 werden nicht von einer, sondern von mehreren Container-Engines CE1-CE4 verwaltet. Dabei ist jeder Container C1-C6 genau einer der Container-Engines CE1-CE4 zugeordnet und wird von dieser verwaltet. Bei dem gezeigten Beispiel gehören zu der Container-Engine CE1 die Container C1 und C2, zu der Container-Engine CE2 die Container C3 und C4, zu der Container-Engine CE3 die Container C5 und C6 und zu der Container-Engine CE4 der Container C7.
  • Es sein angemerkt, dass in den Figuren aus Gründen der Übersichtlichkeit Container-Engines CE1-CE4 mit gestrichelten und Container C1-C7 mit strichpunktierten Linien dargestellt sind.
  • Die Container-Engines CE1-CE4 sind vorliegend durch Docker-Engines gegeben. Die Docker-Engines CE1-CE4 umfassen vorliegend jeweils einen Docker Daemon, einen Container Daemon und runC.
  • Es gilt ferner, dass sich Container-Engines CE1-CE4 sowohl in Side-by-Side-Anordnung als auch in Container-in-Container-Anordnung befinden. Einerseits liegen die Container-Engines CE1 Und CE2 in einer Hierarchieebene nebeneinander, also "Side-by-Side". Andererseits liegt die Container-Engine CE3 in dem Container C4 der Container-Engine CE2 und die Container-Engine CE4 liegt in dem Container C6 der Container-Engine CE3. Die Container-Engines CE2, CE3 und CE4 sind somit in einer Matrjoschka-artigen "ineinander geschachtelte" Anordnung, liegen mit anderen Worten Container-in-Container.
  • Durch die erfindungsgemäße Vorgehensweise wird eine automatische Container-Discovery auch in dieser komplexen Systemkonfiguration mit mehreren Container-Engines CE1-CE4 in gemischten Anordnungen Seite-an-Seite und Container-in-Container möglich.
  • Hierfür weist das System S ein Discovery-Modul D auf. Es sei angemerkt, dass, auch wenn in der Figur 1 zwei Module D schematisch dargestellt sind, auf dem System S nur ein solches Modul D vorgesehen ist. Ein Discovery-Modul D kann beispielsweise ein "einfacher" Prozess sein, der in das System S integriert oder installiert ist. Ein Discovery-Modul D kann aber beispielsweise auch seinerseits als Container installiert und ausgeführt werden. Die Figur 1 zeigt beide dieser Möglichkeiten, indem das Modul D einmal in einem Container gezeigt ist, nämlich in dem Container C1, sowie einmal außerhalb der Container C1-C6 in Figur 1 ganz links.
  • Das Discovery-Modul D kann in beiden Varianten Software-implementiert sein, wobei dies nicht einschränkend zu verstehen ist.
  • Bevorzugt weist jedes einen Arbeitsknoten des Clusters darstellende System S ein eigenes Discovery-Modul D für die Container-Discovery auf.
  • Mit dem Discovery-Modul D werden die im Folgenden beschriebenen Schritte eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens ausgeführt, wozu das Discovery-Modul D entsprechend ausgebildet und eingerichtet ist.
  • Das Discovery-Modul D überwacht das Betriebssystem OS und die Container-Engines CE1-CE4. Mit diesem werden die auf dem System S vorhandenen Container-Engines CE1-CE4 erfasst. Hierfür werden in dem Prozessbaum PT (siehe Figuren 3 und 4) des Betriebssystems OS des Systems S zu den Container-Engines CE1-CE4 gehörige Container-Engine-Prozesse PZ1-PZ4 und die zugehörigen Prozesskennungen PID ermittelt. In den Figuren 3 und 4 sind die PIDs in dem Prozessbau PT eingetragen, wobei diese Werte rein beispielhaft zu verstehen sind. In den Figuren 3 und 4 sind für die Container-Engines CE1-CE4 und die zugehörigen Container C1-C7 die PIDs und Pfade P bzw. Namen N in einem mit dem Bezugszeichen der jeweiligen Engine CE1-CE4 bzw. des jeweiligen Containers C1-C7 versehenen Blockelement dargestellt.
  • Container-Engines CE1-CE4 können beispielsweise anhand deren Namen (z.B. "dockerd") erkannt werden. Es ist auch möglich, dass das Discovery-Modul D eine Liste mit bekannten Namen von Container-Engine-Prozessen PZ1-PZ4 im Prozessbaum PT des Betriebssystems OS heranzieht. Container-Engines CE1-CE4 können alternativ oder zusätzlich auch über bekannte Prozesseigenschaften gefunden werden. Es kann auch bekannt sein, welche Größe diese aufweisen, bzw. in welchem Bereich deren Größe liegt. Dann kann eine Suche bzw. Identifikation über die Größe erfolgen. Das Discovery-Modul kann in Weiterbildung entsprechend ausgebildet und/oder eingerichtet sein.
  • Das Ergebnis der Suche bzw. der Container-Engine-Erfassung ist vorliegend eine Liste von Prozesskennungen PZ1-PZ4 aller aktuell auf dem System S laufender Container-Engines CE1-CE4.
  • Für die erfassten Container-Engines CE1-C4 werden von dem Discovery-Modul in einem nächsten Schritt (Schritt b)) Steuerkanäle SK, vorliegend Control Unix Sockets (siehe Figur 2) ermittelt, über welche die Container-Engines CE1-CE4 angesprochen werden können. Diese Steuerkanäle SK werden vorliegend auch als mögliche Steuerkanäle erachtet und bezeichnet.
  • Das Ermitteln der möglichen Steuerkanäle SK in Schritt b) schließt vorliegend mit ein, dass in Mount-Namensräumen der Container-Engines CE1-CE4 jeweils diejenigen Steuerkanäle SK, konkret Control Unix Sockets, bevorzugt zusammen mit ihren inode-Nummern und ihren Pfaden im Dateisystem erfasst bzw. ermittelt werden, die sich im Zustand "listen" befinden. Dabei wird bevorzugt der Reihe nach vorübergehend in die Mount-Namensräume der Container-Engines CE1-CE4 gewechselt. Das Erfassen bzw. Ermitteln der Steuerkanäle SK kann anhand von Informationen aus /sys/net/unix UXT (siehe Figur 2) erfolgen. UXT steht dabei für Unix (domain) socket Table.
  • Anschließend werden der Reihe nach alle aktuell offenen Dateideskriptoren (englisch: file descriptors, abgekürzt fd) der Container-Engines CE1-CE4 anhand ihrer inode-Nummern dahingehend geprüft, ob sie auf einen der im vorherigen Schritt ermittelten Steuerkanäle SK im Zustand "listen" verweisen. Dateideskriptoren sind dabei sozusagen "Anfasser" für Datenkanäle zu Dateien, Geräten, Unix Sockets etc.
  • In diesem Zusammenhang sei rein beispielhaft folgendes ausgeführt. CE1 habe, wie vorliegend, die PID 42. CE1 möge aktuell die Dateideskriptoren (file descriptors) 0-18 geöffnet haben, d.h. /proc/42/fd/ enthält die Kindknoten "0" bis "19". Der Dateideskriptor "6" (/proc/42/fd/6) verweist auf den Unix socket mit der inode-Nummer 29368 (bspw. ermitteln via "readlink /proc/42/fd/6"), der Dateideskriptor "19" auf den Unix socket mit der inode-Nummer 228971.
  • Die Tabelle(n) der Unix sockets /proc/net/unix hat z.B. den folgenden Text-Aufbau:
    Num RefCount Protocol Flags Type St Inode Path
    ffff95e3a8ed8400: 00000002 00000000 00010000 0001 01 29368
    ...
    /var/run/docker.sock
    ...
  • Hier findet sich nun der Unix socket mit der inode-NUmmer 29368. Er ist im Dateisystem als "/var/run/docker.sock" erreichbar. Der Status "01" weist ihn als "LISTENING" aus.
  • Der Unix socket mit der inode number 228971 verweist zwar auch auf "/var/run/docker.sock", ist aber im Zustand "03" "CONNECTED".
  • Das bedeutet, der Unix socket mit der inode-Nummer 29368 würde als möglicher Steuerkanal SK erachtet, derjenige mit der inode-Nummer 228971 hingegen nicht.
  • Das Ergebnis ist für jede einzelne Container-Engine CE1-CE4 bzw. jedes einzelne Container-Engine-Exemplar CE1-CE4 zunächst eine eigene (geordnete) Liste von potenziellen, also möglichen Steuerkanälen, über die die jeweilige Container-Engine CE1-CE4 angesprochen werden könnte. Je nach Art einer Container-Engine CE1-CE4 existieren möglicherweise mehrere Steuerkanäle SK für diese, wobei jeder Steuerkanal SK möglicherweise andere Funktionen bereitstellt. Es kann sein, dass nicht jeder Steuerkanal SK die Funktionalität bereitstellt, um auf die Liste der Container C1-C7 einer Container-Engine CE1-CE4 zuzugreifen.
  • Im nächsten Schritt (Schritt c)) werden von dem Discovery-Modul D unter Nutzung zumindest einiger der Steuerkanäle SK zu den von diesem erfassten Container-Engines CE1-CE4 gehörige Container C1-C7 sowie deren Prozesskennungen PIDs und Namen N ermittelt. Nach Möglichkeit werden alle Container C1-C7 von allen Container-Engines Ce1-CE4 nebst zugehöriger PIDs und Namen ermittelt.
  • Dabei wird für die jeweilige Container-Engine CE1-CE4 in dem Mount-Namensraum dieser versucht, über den oder die möglichen Steuerkanäle SK die Container-Engine CE1-CE4 zu kontaktieren und den oder die dieser zugeordneten Container C1-C7, deren PIDs und Namen N abzufragen. Diejenigen Steuerkanäle SK, über welche dies gelingt, können als geeignete Steuerkanäle SK erachtet und bezeichnet werden.
  • Dabei wird der Reihe nach in die Mount-Namensräume von allen Container-Engines CE1-CE4 gewechselt. Für den Fall, dass die einer Container-Engine CE1-CE4 zugeordneten Container C1-C7 ausgelesen werden konnten oder aber über keinen der möglichen Steuerkanäle SK einer Container-Engine CE1-CE4 deren Container C1-C7 ausgelesen werden können bzw. konnten, wird jeweils in den Mount-Namensraum der nächsten Container-Engine CE1-CE4 gewechselt und versucht, die zugeordneten Container C1-C7 dieser zu ermitteln. So kann der Reihe nach von Mount-Namensraum zu Mount-Namensraum der laufenden Container-Engines CE1-CE4 gewechselt werden, bis alle vorhandenen Engines CE1-CE4 durch sind. Nach der letzten Container-Engine CE1-CE4 findet zweckmäßiger Weise kein weiterer Wechsel mehr statt.
  • In der Figur 3 ist unterhalb der Container-Engines CE1-CE4 rein schematisch von der jeweiligen Engine CE1-CE4 verwalteter Content dargestellt, konkret sind hier nochmals die Container C1-C7 der Engines CE1-CE4 mit deren PIDs und Namen N gezeigt.
  • In Schritt d) wird von dem Discovery-Modul D (nach Möglichkeit) für alle Container-Engines CE1-CE4 ein Pfad P (siehe Figur 3) erstellt. Es sei angemerkt, dass es passieren kann, dass dies für wenigstens eine der erfassten Engines CE1-CE4 nicht möglich ist, beispielsweise, weil es bereits nicht möglich war, geeignete Steuerkanäle SK für diese zu finden bzw. deren Container zu erfassen.
  • Unter einem Pfad P ist insbesondere eine hierarchische Kennung bzw. eine Kennung zu verstehen, aus der eine Hierarchie bzw. Hierarchie-Informationen abzuleiten ist bzw. sind, insbesondere aufgrund der Reihenfolge von in dem Pfad P bzw. der Kennung enthaltenen Bestandteilen.
  • Dabei wird in dem Prozessbaum PT ausgehend von der Prozesskennung PID der jeweils betrachteten Container-Engine CE1-CE4 in Richtung der Wurzel R des Prozessbaums PT gesucht, und für jede zu einem der in Schritt c) ermittelten Container C1-C7 gehörende Prozesskennung PID (Container-Prozesskennung) wird ein bzw. der Name desjenigen Containers C1-C7, dessen Container-Prozesskennung PID (jeweils) gefunden wurde, dem bisherigen, zu Beginn der Suche insbesondere leeren Pfad hinzugefügt, bevorzugt vorangestellt.
  • Der Name eines Containers C1-C7 wird bevorzugt von der jeweiligen Container-Engine CE1-CE4 verwaltet, zu welcher der Container C1-C7 gehört, und kann beispielsweise automatisch generiert oder auch durch ein Container-Orchestrierungs-System vorgegeben werden bzw. sein.
  • Vorliegend wird für die jeweilige Container-Engine CE1-CE4 zunächst ein leerer Pfad bzw. Ursprungspfad, beispielsweise "" oder "/", angenommen und insbesondere initialisiert. Für den Fall, dass für eine Container-Engine CE1-CE4 eine oder mehrere Container-Prozesskennungen PID gefunden werden, kann dann beispielsweise der Name bzw. können dann beispielsweise die Namen der zugehörigen Container C1-C7 dem (jeweiligen) leeren Pfad hinzugefügt werden. Für den Fall, dass für eine Container-Engine CE1-CE4 hingegen keine Container-Prozesskennungen PID gefunden wird, wird dieser Engine CE1-CE4 zweckmäßiger Weise der leere Pfad zugeordnet.
  • Wenn dabei für eine Container-Engine CE1-CE4 in dem Prozessbaum PT in Richtung der Wurzel R mehr als eine Container-Prozesskennung PID gefunden wird, werden die zugehörigen Namen besonders bevorzugt in umgekehrter Reihenfolge in den Pfad P aufgenommen als die Container-Prozesskennungen PID ausgehend von der betrachteten Prozesskennung PID der Container-Engine CE1-CE4 in Richtung der Prozessbaumwurzel R in dem Prozessbaum PT vorhanden sind. Dies entspricht insbesondere der zu Auffinden der Container-Prozesskennungen PID umgekehrten Reihenfolge.
  • Dies ist vorliegend für die Container-Engine CE4 der Fall. Diese hat bei dem dargestellten Beispiel die PID 902 (siehe Figuren 3 und 4). Ausgehend von dieser und in Richtung der Wurzel R befinden sich im Prozessbaum PT noch die Container-Prozesskennungen 800, also die PID des Containers C6 und die Container-Prozesskennung 80, also die PID des Containers C4 (vgl. insbesondere Figur 4 oben, in der die Container C4 und C6 über dem Prozessbaum PT dargestellt sind und rechts davon nochmals die zugehörigen PIDs und Namen N). Der Container C6 hat den Namen "I" (inner) und der Container C4 den Namen "O" (outer). Damit ergibt sich für die Engine CE4 mit der PID 902 der Pfad P = "/O/I". Der Pfad der Container-Engine CE4 ist mit anderen Worten die Aneinanderreihung der Namen der bei dem "Klettern" entlang des Prozessbaums PT bzw. Prozessbaum-Astes gefundenen Container C1-C7 bevorzugt in umgekehrter Reihenfolge.
  • Die Suche in dem Prozessbaum PT für die jeweilige Engine CE1-CE4 erfolgt zweckmäßiger Weise so lange, bis die oberste Prozesskennung PID des Prozessbaums PT bzw. die Wurzel R (vorliegend PID=1, siehe Figuren 3 und 4) erreicht ist. Damit ist die Suche für die jeweils betrachtete Container-Engine CE1-CE4 beendet und deren Pfad P fertig. Es sei angemerkt, dass in den Figuren 3-5 links der Prozesskennungen PID der Container-Engines CE1-CE4 mit PPID=1 nochmals dargestellt ist, dass die Prozesskennung des zugehörigen Elternprozesses 1 lautet, es sich also um die oberste Prozesskennung PID handelt.
  • Bei dem gezeigten Beispiel gibt es sozusagen zwei Verschachtelungs-Ebenen, da die Engine CE3 in einem Container C4 der Engine CE2 liegt und die Engine CE4 wiederum in einem Container C6 der Engine CE3. Es existieren somit drei Hierarchie-Ebenen, die der Engines CE1 und CE2, die der Engine CE3 und die der Engine CE4. Bei dem Beispiel hat der Container C4 den Namen "O", da er in diesem Szenario der äußere ("Outer") Container mit Engine CE3 ist und der Container C6 den Namen "I", weil er der innere ("Inner") Container mit Engine CE4 ist.
  • Für die Engine CE3 mit der PID 85, welche nur in den Container CE4 "geschachtelt" ist, ergibt sich dabei der Pfad P ="/O", da vor dieser im Prozessbaum in Richtung der Wurzel R nur die Container-PID 80 des Containers C4 mit dem Namen "O" liegt.
  • In den Figuren sind auch die weiteren Containernamen neben "O" und "I" eingetragen, die hier "A", "B" und "C" lauten. Es sein betont, dass diese - genau wie die Namen "O" und "I" rein beispielhaft zu verstehen sind.
  • Es ist prinzipiell möglich, dass der Pfad P auch noch den bzw. einen "Namen" der Container-Engine erhält, der zum Beispiel "dockerd" lauten kann. Dann würde man z.B. "/dockerd" anstatt "" bzw. "/dockerd/O" anstatt "/O" erhalten.
  • Wird auf dem Weg von der Prozesskennung PID der betrachteten Container-Engine CE1-CE4 bis zur Wurzel R keine Prozesskennung PID eines Containers C1-C7 gefunden, bedeutet dies, dass die Container-Engine CE1-CE4 nicht ihrerseits in einem Container C1-C7 liegt, sozusagen nicht in einen (oder auch mehrere) Container C1-C7 verschachtelt ist. Dies ist bei dem dargestellten Beispiel für die Container-Engines CE1 und CE2 der Fall. Für diese mit den PIDs 42 bzw. 45 ergibt sich ein leerer Pfad bzw. Ursprungspfad P, vorliegend P = "/".
  • Es kann vorteilhaft sein zu vermeiden, dass zwei oder mehr der Container-Engines CE1-CE4 der gleiche Pfad zugeordnet wird. Entsprechend kann vorgesehen sein, dass für den Fall, dass für die Container-Engines CE1-CE4 erstellten Pfade P zwei oder mehr identische Pfade P umfassen, eine Vereinzelung der Pfade P durchgeführt wird. Bei dem beschriebenen Beispiel ist für die Container-Engines CE1 und CE2 der gleiche Pfad P erstellt worden, nämlich für beide der "leere" bzw. "Ursprungspfad" "/", da diese beiden Engines nebeneinander in der obersten Hierarchie-Ebene liegen.
  • Das Discovery-Modul D prüft bevorzugt im Anschluss an die Erstellung aller Pfade P in Schritt d), ob Pfade P mehrfach vorhanden sind. Ergibt die Prüfung, dass dem so ist, kann das Discovery-Modul D identische Pfade P vereinzeln.
  • Die Vereinzelung der Pfade P kann beispielsweise erfolgen, indem (jeweils) identischen Pfaden P unterschiedliche zusätzliche Pfadbestandteile hinzugefügt werden. Als zusätzliche Pfadbestandteile zum Erhalt einer Vereinzelung kommen beispielsweise die Prozesskennung PID und/oder der Name der Container-Engine CE1-CE4, für welche der jeweilige Pfad P erstellt wurde, in Frage. Dies ist rein beispielhaft zu verstehen und es können selbstverständlich auch andere Bestandteile in identische Pfade P eingefügt werden, um diese zu vereinzeln. Die einzige Anforderung ist, dass durch die Vereinzelungs-Maßnahme aus zwei oder mehr identischen Pfaden P zwei oder mehr verschiedene Pfade erhalten werden.
  • Vorliegend werden den beiden identischen Pfaden P von CE1 und CE2 zur Vereinzelung die PIDs der Engines CE1 und CE2 hinzugefügt. Hierdurch ergibt sich für die Container-Engine CE1 als Pfad P "/42" und für die Engine CE2 als Pfad P "/45", man erhält also voneinander verschiedene, vereinzelte Pfade P.
  • Zweckmäßiger Weise werden für die Vereinzelung in kürzeren Pfaden P durchgeführte Anpassungen in gegebenenfalls vorhandene, von den kürzeren Pfaden P abhängige länger Pfade P übernommen. Bei dem dargestellten Ausführungsbeispiel kann bevorzugt die für die Engine CE2 für die Vereinzelung durchgeführte Anpassung in die Pfade der Engines CE3 und CE4 übernommen werden, die beide in Containern C4, C6 liegen, die der Engine CE2 - in einfacher oder zweifacher "Verschachtelung" unterlagert sind (vgl. insbesondere Figur 1). Durch die Übernahme der Vereinzelungs-Maßnahme auch in diese abhängigen Pfade P, würde sich dann für die Engine CE3 der Pfad "/45/O" und für die Engine CE4 der Pfad "/45/O/I" ergeben.
  • Es sei angemerkt, dass für den Fall, dass alternativ zu dem dargestellten Beispiel mehre identische Pfade P auch unterschiedlicher Länge erstellt werden, z.B. zwei Pfade "/" und zwei Pfade "/O", die Pfad-Vereinzelung besonders bevorzugt derart erfolgt, dass mit den kürzesten identischen Pfaden P begonnen wird.
  • Weiterhin sei angemerkt, dass zum Erhalt der Pfadvereinzelung zusätzliche Bestandteile bevorzugt am hinteren, rechten Ende des jeweiligen Pfades P hinzugefügt werden, wie vorstehend am Beispiel des leeren bzw. Ursprungspfads "/", dem rechts die PID 42 bzw. 45 angehängt wurde, dargestellt.
  • In vorteilhafter Ausgestaltung überprüft das Discovery-Modul D, nachdem es ein erstes Mal zwei oder auch mehr insbesondere kürzeste identische Pfade P gefunden und vereinzelt und gegebenenfalls davon abhängige Pfade P entsprechend angepasst hat, wenigstens ein weiteres Mal, ob noch identische Pfade P vorhanden sind und vereinzelt ggf. auch diese. Dies kann so oft wiederholt werden, bis keine identischen Pfade P mehr von dem Discovery-Modul D gefunden werden.
  • Um ein mögliches Beispiel zu nennen, sei angenommen, in dem Container C6 würde sich neben der Container-Engine CE4 noch eine weitere Engine (Side-by-Side) befinden. Diese hätte dann ebenfalls den Pfad "/45/O/I", was das Discovery-Modul D erkennen würde und es wäre eine weitere Vereinzelungsmaßnahme erforderlich. Das Discovery-Modul D könnte dann beispielsweise erneut die PID der betreffenden Container-Engines in die Pfade P hinzufügen, bevorzugt an deren rechtem Ende. Davon ausgehend, dass die weitere, ebenfalls in dem Container C6 liegende Engine die PID 905 hat, was beispielhaft zu verstehen ist, würden sich die vereinzelten Pfade "/45/O/I/902" für die Engine CE4 und "/45/O/I/905" für die weitere Engine im gleichen Container C6 ergeben.
  • Das Discovery-Modul D erstellt ein Datenmodell M (siehe Figuren 1 und 2), das alle ermittelten Container C1-C7 aufführt. In vorteilhafter Ausgestaltung werden von dem Discovery-Modul D die für die Container-Engines CE1-CE4 ermittelten - und ggf. vereinzelten - Pfade P in den Daten des oder der zugehörigen Container C1-C7 gespeichert. Dabei wird in den Daten jedes Containers C1-C7 der Pfad P der jeweiligen Engine CE1-CE4 abgelegt. Diese Datensätze enthalten die Informationen pro Container C1-C7, die von den Container-Engines CE1-Ce4 zuvor abgefragt wurden. Die Pfade P sind in der Figur 4 in der jeweiligen Container-Engine CE1-CE4 und den zu dieser zugehörigen Containern C1-C7 eingetragen. So wird es möglich, dass insbesondere auch später noch eine einfache und eindeutige Zuordnung (jeweils) zwischen einem einzelnen Container C1-C7 und seiner Container-Engine CE1-CE4 zur Verfügung steht.
  • Werden Pfade P vereinzelt, werden zweckmäßiger Weise die vereinzelten Pfade P in dem Datenmodell M des Discovery-Moduls D und/oder in den Daten der betreffenden Container C1-C7 gespeichert. Für das vorstehend beschriebene Beispiel würde- in dem Falle, dass die vorstehend beispielhaft beschriebene Vereinzelung erfolgt - für die gespeicherten Daten das gelten, was in Figur 5 gezeigt ist.
  • Auf die bereitgestellten Daten M kann dann beispielsweise von einem externen Plugin für das Aufzeichnen von Netzwerkverkehr (sog. Extcaps) zugegriffen werden. Ein solches, beispielsweise ein Wireshark-Plugin, kann das Datenmodell M des Discovery-Moduls D z.B. verwenden, um einem Anwender eine Liste verfügbarer Container C1-C7 (insbesondere einschließlich deren Namen N und Pfaden P) zu präsentieren.
  • Der Zugriff kann beispielsweise über ein REST API erfolgen. REST steht dabei für Representational State Transfer und API für Application Programming Interface. In der Figur 1 ist dieser Zugriff durch mit API versehene Pfeile schematisch angedeutet.
  • Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.

Claims (16)

  1. Verfahren zur Bestimmung einer Container-Konfiguration eines Systems (S), wobei das System (S) ein Betriebssystem (OS) aufweist und auf dem System (S) mehrere Software-Container (C1-C7) vorhanden sind, die von mehreren Container-Engines (CE1-CE4) verwaltet werden, bei dem mittels eines Discovery-Moduls (D)
    a) die Container-Engines (CE1-CE4) erfasst werden, wobei in einem Prozessbaum (PT) des Betriebssystems (OS) des Systems (S)zu den Container-Engines (CE1-CE4) gehörige Container-Engine-Prozesse (PZ1-PZ4) ermittelt werden,
    b) für die erfassten Container-Engines (CE1-CE4) Steuerkanäle (SK) ermittelt werden, über welche die Container-Engines (CE1-CE4) angesprochen werden können,
    c) unter Nutzung zumindest einiger der Steuerkanäle (SK) ermittelt wird, welche Container (C1-C7) zu welchen Container-Engines (CE1-CE4) gehören und welche Prozesskennungen (PID) (N) die Container (C1-C7) jeweils aufweisen, und
    d) für eine oder mehrere der Container-Engines (CE1-CE4) ein Pfad (P) erstellt wird, wobei ermittelt wird, ob in dem Prozessbaum (PT) ausgehend von der Prozesskennung (PID) der oder der jeweiligen Container-Engine (CE1-CE4) in Richtung der Prozessbaumwurzel (R) eine oder mehrere Prozesskennungen (PID) vorhanden sind, welche jeweils zu einem der in Schritt c) ermittelten Container (C1-C7) gehören, Container-Prozesskennungen, und für den Fall, dass eine oder mehrere Container-Prozesskennungen (PID) vorhanden sind, eine Kennung (N) des zugehörigen Containers (C1-C7) bzw. Kennungen (N) der zugehörigen Container (C1-C7) in den Pfad (P) der oder der jeweiligen Container-Engine (CE1-CE4) aufgenommen wird bzw. werden.
  2. Verfahren nach Anspruch 1,
    dadurch gekennzeichnet, dass
    in Schritt a) Prozesskennungen (PID) der Container-Engine-Prozesse (PIZ1-Piz4) der Container-Engines (CE1-CE4) ermittelt werden.
  3. Verfahren nach Anspruch 1 oder 2,
    dadurch gekennzeichnet, dass
    in Schritt d) für die oder die jeweilige Container-Engine (CE1-CE4) zunächst ein leerer Pfad (P) oder Ursprungspfad (P) angenommen wird, und für den Fall, dass für eine Container-Engine (CE1-CE4) eine oder mehrere Container-Prozesskennungen (PID) gefunden werden, die Kennung bzw. die Kennungen (N) der zugehörigen Container (C1-C7) dem leeren Pfad (P) hinzugefügt wird bzw. werden, und für den Fall, dass für eine Container-Engine (CE1-CE4) keine Container-Prozesskennungen (PID) gefunden werden, dieser der leere Pfad (P) zugeordnet wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass,
    wenn in Schritt d) für eine Container-Engine (CE1-CE4) mehr als eine Container-Prozesskennung (PID) gefunden wird, die zugehörigen Kennungen (N) in umgekehrter Reihenfolge in den Pfad (P) aufgenommen werden als die Container-Prozesskennungen (PID) ausgehend von der Prozesskennung (PID) der Container-Engine (CE1-CE4) in Richtung der Prozessbaumwurzel (R) in dem Prozessbaum (PT) vorhanden sind.
  5. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass
    wenigstens zwei der Container-Engines (CE1-CE4) in einer Side-by-Side-Anordnung und/oder wenigstens zwei der Container-Engines (CE1-CE4) in einer Container-in-Container-Anordnung vorgesehen sind.
  6. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass
    in Schritt b) das Ermitteln der Steuerkanäle (SK) einschließt, dass in Mount-Namensräumen der Container-Engines (CE1-CE4) jeweils diejenigen Steuerkanäle (SK), insbesondere Unix Sockets, bevorzugt zusammen mit ihren inode-Nummern und ihren Pfaden im Dateisystem ermittelt werden, die sich im Zustand "listen" befinden.
  7. Verfahren nach Anspruch 6,
    dadurch gekennzeichnet, dass
    in Schritt b) das Ermitteln der Steuerkanäle (SK) einschließt, dass Handle, insbesondere Dateideskriptoren der Container-Engines anhand ihrer inode-Nummern darauf geprüft werden, ob sie auf einen der ermittelten, sich im Zustand "listen" befindlichen Steuerkanäle (SK) verweisen.
  8. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass
    in Schritt c) für die oder die jeweilige Container-Engine (CE1-CE4) in dem Mount-Namensraum dieser versucht wird, über den oder die Steuerkanäle (SK) die Container-Engine (CE1-CE4) zu kontaktieren und den oder die dieser zugeordneten Container (C1-C7) abzufragen.
  9. Verfahren nach Anspruch 8,
    dadurch gekennzeichnet, dass
    der Reihe nach in die Mount-Namensräume von zwei oder mehr Container-Engines (CE1-CE4) gewechselt wird, wobei jeweils für den Fall, dass die einer Container-Engine (CE1-CE4) zugeordneten Container (C1-C7) ausgelesen werden konnten oder über keinen der Steuerkanäle (SK) der Container-Engine (CE1-CE4) deren Container (C1-C7) ausgelesen werden konnten, in den Mount-Namensraum der nächsten Container-Engine (CE1-CE4) gewechselt und versucht wird, die zugeordneten Container (C1-C7) dieser zu ermitteln.
  10. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass
    für den Fall, dass die in Schritt d) für die Container-Engines erstellten Pfade zwei oder mehr identische Pfade umfassen, eine Vereinzelung der Pfade durchgeführt wird.
  11. Verfahren nach Anspruch 10,
    dadurch gekennzeichnet, dass
    die Vereinzelung erfolgt, indem identischen Pfaden unterschiedliche zusätzliche Pfadbestandteile hinzugefügt werden.
  12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
    der oder die in Schritt d) für die oder die jeweilige Container-Engine (CE1-CE4) ermittelten Pfade und gegebenenfalls vereinzelten (P) gespeichert werden, insbesondere in dem Discovery-Modul (D) und/oder in den Daten des oder der zu der jeweiligen Container-Engine (CE1-CE4) gehörigen Container (C1-C7).
  13. Verfahren nach einem der vorhergehenden Ansprüche,
    dadurch gekennzeichnet, dass
    das Discovery-Modul (D) ein Datenmodell (M) erstellt, das alle in Schritt c) ermittelten Container (C1-C7) aufführt.
  14. System (S), auf dem mehrere Software-Container (C1-C7) vorhanden sind, die von mehreren Container-Engines (CE1-CE4) verwaltet werden, wobei das System (S) ein Betriebssystem (OS) umfasst und ein Discovery-Modul (D), das dazu ausgebildet und/oder eingerichtet ist,
    a) die Container-Engines (CE1-CE4) zu erfassen, wobei in einem Prozessbaum (PT) des Betriebssystems (OS) des Systems (S) zu den Container-Engines (CE1-CE4) gehörige Container-Engine-Prozesse (PZ1-PZ4) ermittelt werden,
    b) für die erfassten Container-Engines (CE1-CE4) Steuerkanäle (SK) zu ermitteln, über welche die Container-Engines (CE1-CE4) angesprochen werden können,
    c) unter Nutzung zumindest einiger der Steuerkanäle (SK) zu ermitteln, welche Container (C1-C7) zu welchen Container-Engines (CE1-CE4) gehören und welche Prozesskennungen (PID) die Container (C1-C7) jeweils aufweisen, und
    d) für eine oder mehrere der Container-Engines (CE1-CE4) einen Pfad (P) zu erstellen, wobei ermittelt wird, ob in dem Prozessbaum (PT) ausgehend von der Prozesskennung (PID) der oder der jeweiligen Container-Engine (CE1-CE4) in Richtung der Prozessbaumwurzel (R) eine oder mehrere Prozesskennungen (PID) vorhanden sind, welche jeweils zu einem der in Schritt c) ermittelten Container (C1-C7) gehören, Container-Prozesskennungen, und für den Fall, dass eine oder mehrere Container-Prozesskennungen (PID) vorhanden sind, eine Kennung (N) des zugehörigen Containers (C1-C7) bzw. Kennungen (N) der zugehörigen Container (C1-C7) in den Pfad (P) der oder der jeweiligen Container-Engine (CE1-CE4) aufgenommen wird bzw. werden.
  15. Computerprogramm umfassend Programmcode-Mittel, die bei der Ausführung des Programms auf wenigstens einem Computer den wenigstens einen Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 13 durchzuführen.
  16. Computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigstens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 13 durchzuführen.
EP19198405.3A 2019-09-19 2019-09-19 Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium Withdrawn EP3796161A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19198405.3A EP3796161A1 (de) 2019-09-19 2019-09-19 Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19198405.3A EP3796161A1 (de) 2019-09-19 2019-09-19 Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium

Publications (1)

Publication Number Publication Date
EP3796161A1 true EP3796161A1 (de) 2021-03-24

Family

ID=68062813

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19198405.3A Withdrawn EP3796161A1 (de) 2019-09-19 2019-09-19 Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium

Country Status (1)

Country Link
EP (1) EP3796161A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4300337A1 (de) * 2022-06-30 2024-01-03 Siemens Aktiengesellschaft Verfahren und system zur bereitstellung von steuerungsanwendungen für industrielle automatisierungsgeräte

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170063722A1 (en) * 2015-08-28 2017-03-02 Internation Business Machines Corporation Managing a shared pool of configurable computing resources which has a set of containers
EP3267351A1 (de) 2016-07-07 2018-01-10 Gemalto Sa Methode für das sichere verwalten eines docker image

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170063722A1 (en) * 2015-08-28 2017-03-02 Internation Business Machines Corporation Managing a shared pool of configurable computing resources which has a set of containers
EP3267351A1 (de) 2016-07-07 2018-01-10 Gemalto Sa Methode für das sichere verwalten eines docker image

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "docker | Docker Documentation", 24 July 2019 (2019-07-24), XP055672216, Retrieved from the Internet <URL:https://web.archive.org/web/20190724051500/https://docs.docker.com/engine/reference/commandline/docker/> [retrieved on 20200227] *
ANONYMOUS: "Linux man pages: alphabetic list of all pages", ARCHIVE.ORG, 20 August 2019 (2019-08-20), pages 1 - 129, XP055672194, Retrieved from the Internet <URL:https://web.archive.org/web/20190820170312/http://man7.org/linux/man-pages/dir_all_alphabetic.html> [retrieved on 20200227] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4300337A1 (de) * 2022-06-30 2024-01-03 Siemens Aktiengesellschaft Verfahren und system zur bereitstellung von steuerungsanwendungen für industrielle automatisierungsgeräte

Similar Documents

Publication Publication Date Title
DE112018004222T5 (de) Datenbankaufteilung
DE102016104478A1 (de) Kryptographische Verfahren, die Arbeitsnachweise in Systemen untereinander verbundener Knoten realisieren
DE4305522C2 (de) Einrichtung zur rechnergestützten Diagnose eines aus Modulen bestehenden technischen Systems
DE202014010938U1 (de) Omega-Namen: Namenserzeugung und -ableitung
DE112012000693T5 (de) Ausführen einer Vielzahl von Instanzen einer Anwendung
DE102010011658A1 (de) Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE102012218699A1 (de) Passives überwachen virtueller systeme mittels agentenlosem offline-indexieren
DE112018006540T5 (de) Dynamisches ersetzen eines aufrufs einer software-bibliothek durch einen aufruf eines beschleunigers
DE102013001196A1 (de) Verfahren zum Bereitstellen einer Benutzerschnittstelle, Computersystem und Computerprogrammprodukt
DE102012221814A1 (de) Neuanordnung von Software-Abbildern auf der Grundlage von deren vorhergesagter Verwendung
EP3796161A1 (de) Verfahren zur bestimmung einer container-konfiguration eines systems, system, computerprogramm und computerlesbares medium
DE112010004086T5 (de) System, Programm und Verfahren zum Bilden von Konfigurationsinformationen über Komponenten von Systemen, die Komponenten enthalten, die für das Erfassen von Konfigurationsinformationen eingeschränkt ist
EP3028182B1 (de) Verfahren und system zur synchronisation von daten
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
WO2021037379A1 (de) Verfahren zum betreiben eines clusters, cluster-arbeitsknoten, cluster, netzwerk, computerprogramm und computerlesbares medium
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
EP1536328A2 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
WO2021037378A1 (de) Verfahren zum automatischen markieren, cluster-arbeitsknoten, cluster, netzwerk, computerprogramm und computerlesbares medium
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek
DE102021200191B3 (de) Verfahren zum Verarbeiten von Konfigurations-Daten einer Vielzahl von Entitäten, damit zusammenwirkende Verfahren und Vorrichtungen sowie Computerprogrammprodukt und Signalfolge
DE102013108309A1 (de) Verfahren zum Konnektieren von Objekten in einer Softwareanwendung
DE112016005363T5 (de) Verteilte betriebssystemfunktionen für knoten in einem rack
EP2178267B1 (de) Verfahren zur Ausführung von Diensten in einem dezentralen Datennetz

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20210925