WO2023218875A1 - システム構築装置 - Google Patents

システム構築装置 Download PDF

Info

Publication number
WO2023218875A1
WO2023218875A1 PCT/JP2023/015440 JP2023015440W WO2023218875A1 WO 2023218875 A1 WO2023218875 A1 WO 2023218875A1 JP 2023015440 W JP2023015440 W JP 2023015440W WO 2023218875 A1 WO2023218875 A1 WO 2023218875A1
Authority
WO
WIPO (PCT)
Prior art keywords
source code
construction device
unit
user
system construction
Prior art date
Application number
PCT/JP2023/015440
Other languages
English (en)
French (fr)
Inventor
大生 伊藤
Original Assignee
日立Astemo株式会社
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 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to CN202380019637.2A priority Critical patent/CN118633076A/zh
Publication of WO2023218875A1 publication Critical patent/WO2023218875A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment

Definitions

  • the present invention relates to a system construction device that constructs a system on a predetermined execution environment.
  • Patent Document 1 a technology is disclosed that automates the deployment of resources by converting the order sheet into source code based on the order sheet in which system requirements are described.
  • Patent Document 1 By using the technology described in Patent Document 1, it is possible to automatically construct a system in accordance with system requirements even if the user does not have coding knowledge. On the other hand, when a user changes the configuration of a deployed system without changing the source code, there is a problem in that the source code of the target system and the configuration of the target system are different.
  • Patent Document 2 describes a technique for detecting the presence or absence of a system setting change and reflecting the detected setting change in the source code.
  • Patent Document 2 devices included in a system to be constructed are monitored, and there is a problem in that changes such as adding new devices to the system cannot be reflected in the source code. Further, since coding rules for writing source code often differ depending on the user, there is a risk that coding rules for modified source code may lack consistency depending on how the code is reflected in the source code. Therefore, in order to facilitate source code management and user understanding, it is necessary to modify the source code so that it is consistent after reflection.
  • the present invention was made in view of the above-mentioned problems, and it is possible to change the user's writing style, including adding new resources to the system, when the user changes the system configuration without changing the source code.
  • the purpose is to correct the differences between the source code and system configuration.
  • a system construction device is a system construction device that constructs a system including infrastructure resources and setting values for the infrastructure resources on a predetermined execution environment, and inputs a request for system construction that satisfies desired requirements.
  • a system source code creation part that creates a first source code that defines a system that satisfies desired requirements; a deployment part that deploys and builds the system based on the requirements on the execution environment; a configuration change detection unit that detects a difference between a second source code and a first source code that define the changed system when the system built on the system is changed;
  • a settings change reflection unit that reflects the difference in the first source code, the setting change reflection unit reflects the difference in the first source code based on the coding rule applied to the first source code.
  • the original system construction information and the changed system can be combined with the original system construction information in a form with unified coding rules. Differences with the configuration can be corrected.
  • FIG. 1 is a hardware configuration diagram of a system construction device 100 according to a first embodiment.
  • FIG. 1 is a functional block configuration diagram of a system construction device 100 according to a first embodiment.
  • 5 is a flowchart of processing executed by the system construction device 100 according to the first embodiment.
  • FIG. 4 is a diagram illustrating a specific example of step S101 in the flowchart of FIG. 3.
  • 4 is a diagram illustrating a specific example of step S102 in the flowchart of FIG. 3.
  • FIG. 4 is a diagram illustrating a specific example of step S103 in the flowchart of FIG. 3.
  • FIG. 4 is a diagram illustrating a specific example of step S103 in the flowchart of FIG. 3.
  • FIG. 4 is a diagram illustrating a specific example of step S103 in the flowchart of FIG. 3.
  • FIG. 4 is a diagram illustrating an example of system source code related to the deployment process in step S104 and step S105 in FIG. 3.
  • FIG. 4 is a flowchart illustrating a specific example of steps S106 and S107 in the flowchart of FIG. 3.
  • 8 is a diagram illustrating a specific example of a method for determining an existing setting value 282, which is referred to in step S202 in the flowchart of FIG. 7.
  • FIG. 8 is a flowchart illustrating a specific example of step S209 in the flowchart of FIG. 7.
  • 7 is a flowchart of processing executed by the system construction device 100 according to the second embodiment.
  • FIG. 1 shows an example of the hardware configuration of a system construction apparatus 100 according to this embodiment.
  • the system construction device 100 includes hardware such as an arithmetic unit 110, a storage device 120, an input/output I/F (Interface) 130, and a communication I/F (Interface) 140.
  • hardware such as an arithmetic unit 110, a storage device 120, an input/output I/F (Interface) 130, and a communication I/F (Interface) 140.
  • the arithmetic device 110 is, for example, a CPU (Central Processing Unit), and performs various functions described below through processing by the CPU.
  • a CPU Central Processing Unit
  • the storage device 120 includes, for example, a RAM (Random Access Memory) and a ROM (Read Only Memory), and stores data used by the arithmetic device 110.
  • a RAM Random Access Memory
  • ROM Read Only Memory
  • the input/output I/F 130 is, for example, a display having a touch panel function, and displays processing results by the arithmetic device 110 and a user interface of a portal screen 210, which will be described later, on the screen.
  • the communication I/F 140 is, for example, a communication chip or NIC (Network Interface Card), and is used for communication with an execution environment 280 and a user 201, which will be described later.
  • NIC Network Interface Card
  • the data When each part of the system construction device 100 accepts data, the data may be accepted via the input/output I/F 130, or the data may be accepted via the communication I/F 140.
  • FIG. 2 is a functional block diagram showing an example of the configuration of each functional unit included in the system construction device 100.
  • the system construction device 100 includes a portal screen 210, a repository 220, a system source code creation section 230, a deployment section 240, a settings change detection section 250, a settings change reflection section 260, and a coding rule storage section 270. It consists of:
  • the source code of the deployment template 221 and module 222 is registered in advance in the designated repository 220.
  • Examples of the repository 220 include GitHub (https://github.com/) for cloud services and GitLab for OSS. An example of the source code will be described later using FIG. 6.
  • FIG. 2 shows an example in which multiple templates 221 and modules 222 are managed by one repository 220, the repository 220 may be separated for each source code corresponding to each of multiple projects. It's okay.
  • the source code is used to construct a specific system 281.
  • the source code includes not only a configuration in which one system 281 corresponds to one template 221, but also a module 222 that is a set of functions that constitute a part of the system 281.
  • the system source code of one system 281 is created by combining a plurality of modules 222.
  • the various types of information to be managed and displayed by the device 100 include the template 221 and the module 222, which are the source code for constructing the system 281, the entity or reference of the system source code, and the like.
  • the system construction device 100 displays a portal screen 210 to the user 201 of the system construction device 100 on a display device (not shown).
  • An example of the portal screen 210 will be described later using FIGS. 4 and 5.
  • the portal screen 210 is equipped with a CPU (not shown), and presents system candidates from templates 221 and modules 222 in the repository 220 according to the user's selection, as will be described later.
  • the user 201 uses the portal screen 210 to select the system 281 that he wishes to construct this time. For example, the user 201 inputs functional requirements and non-functional requirements of the cloud service, and presents a template 221 prepared in advance.
  • the template 221 is a service that is a combination of public cloud services, private cloud services, etc. that satisfy each requirement based on past performance.
  • Non-functional requirements may include requirements regarding the network.
  • Examples of network-related requirements include whether to use a public IP, whether to use a firewall, whether to use an encryption function, etc., but are not limited to these, and may include various network-related requirements.
  • the functional requirements may include information indicating whether the execution environment 280 to be used is one of multiple types of clouds.
  • the functional requirements may include various requirements related to the purpose and infrastructure of the system 281.
  • each infrastructure resource 283 of the presented template 221 is changed to another infrastructure resource 283 that can realize a similar function, or infrastructure resources 283 are added or deleted to customize.
  • the system 281 to be constructed is selected by inputting the setting values 282 required for each infrastructure resource 283 to be deployed from a parameter sheet or the like.
  • the system source code creation unit 230 creates the system source code using the template 221 and module 222 of the selected system 281 from the repository 220.
  • Execution environment 280 is an environment for operating system 281.
  • the execution environment 280 is, for example, a public cloud service, a private cloud service, a cluster of IT resources managed by an orchestration tool such as OpenStack, Kubernetes, or the like.
  • the execution environment 280 for operating the system 281 selected by the user 201 may be specified by the user 201.
  • the execution environment 280 may be a different execution environment for each user 201, or one execution environment may be shared.
  • a system 281 is constructed in the execution environment 280, including an infrastructure resource 283, a setting value 282 of the infrastructure resource 283, etc. based on the system source code.
  • the user 201 makes necessary changes to the constructed system 281 on the execution environment 280, and performs development (changes to the system 281) suitable for the user 201's purpose.
  • the setting change detection unit 250 detects whether there is a setting change in the system 281 to be constructed. When there is a change in the settings of the system 281, the settings change detection unit 250 detects the difference between the configuration of the system 281 defined by the system source code created by the system source code creation unit 230 and the current system 281 in the execution environment. Detect and extract settings changes.
  • the settings change reflection unit 260 reflects the difference detected by the settings change detection unit 250 in the system source code created by the system source code creation unit 230 based on the coding rule stored in the coding rule storage unit 270.
  • the coding rules include, for example, being derived from standard variable names provided by each vendor as variable name definitions, and that variables such as IDs are not hard-coded.
  • the execution environment 280 is an IaaS (Infrastructure as a Service) public cloud
  • the deployment process is Terrafrom
  • the template 221 and module 222 are HCL (HCL)
  • HCL HCL
  • the execution environment 280 may be Kubernetes
  • the object to be built in the execution environment 280 may be a container
  • the deployment process may be Helm.
  • FIG. 3 is a flowchart illustrating an example of processing executed by the system construction apparatus 100 according to the first embodiment of the present invention. Each step in FIG. 3 will be explained below. Further, an outline of each step shown in FIG. 3 will be explained below, and details thereof will be described later.
  • the user 101 inputs desired requirements (functional requirements and non-functional requirements) from the portal screen 210 (step S101).
  • the user 201 inputs information necessary to deploy the system 281 presented on the portal screen 210 (step S103).
  • the necessary information is, for example, the setting value 282 of each infrastructure resource 283 included in the system 281.
  • the setting values 282 include, for example, the name of each infrastructure resource 283 and the billing destination for fees generated by employing and operating the infrastructure resource 283.
  • the setting value 282 may be defined by the provider of each infrastructure resource 283.
  • the user 201 may change each infrastructure resource 283 to another infrastructure resource 283.
  • the system source code generation unit 230 generates a system source code by inputting information on infrastructure resources 283 included in the system 281 presented on the portal screen 210 and information necessary for deploying the system 281 (step S104).
  • the deployment unit 240 constructs a system 281 on the execution environment 280 using the system source code generated by the system source code creation unit 230.
  • the setting change detection unit 250 monitors and detects whether the user 201 directly changes the system 281. If a setting change is detected, the setting change detection unit 250 detects and extracts the change (step S106). The setting change detection unit 250 may detect the changed contents using any method. The setting change detection unit 250 may extract only the difference.
  • the settings change reflection unit 260 refers to the coding rules adopted by the system source code creation unit 230, which are stored in the coding rule storage unit 270, and reflects the differences extracted by the settings change detection unit 250 in the system source code. The process ends with the above steps.
  • FIG. 4 is a diagram illustrating a specific example of the screen displayed on the portal screen 210 in step S101 of FIG. 3.
  • a requirement input screen 300 is displayed on the portal screen 210.
  • the user 201 selects, on the portal screen 210, the purpose to be achieved by the system 281, the availability and performance required for the system 281, and the network conditions for operating the system on the requirement input screen 300.
  • FIG. 4 an example is shown in which options such as development type, analysis type, and cooperation type are displayed in the service type 301 as the purpose to be achieved by the system 281.
  • options such as development type, analysis type, and cooperation type are displayed in the service type 301 as the purpose to be achieved by the system 281.
  • the types of infrastructure resources 283 of the system 281 displayed on the portal screen 210 change according to the purpose.
  • system 281 is designed to collect data and perform analysis.
  • Such automation allows the user 201 to reduce the number of steps normally required in designing the system 281.
  • the options are just examples, and other options may be used.
  • FIG. 4 an example is shown in which options for production and PoC (Proof of Concept) are displayed in the item Availability 302 as availability.
  • PoC refers to verification and demonstration at the pre-prototype development stage for the purpose of verifying new concepts, theories, principles, and ideas.
  • the configuration and setting values 282 of the infrastructure resources 283 of the system 281 displayed on the portal screen 210 change according to the selected availability. For example, if production use is selected, the system 281 is distributed and deployed in multiple regions (for example, Tokyo and Osaka), so that the system 281 continues to operate even if a disaster occurs in one region. Designed to. In other words, redundancy is ensured. This option is just one example, and other options may be used.
  • FIG. 4 an example is shown in which options of level 1, level 2, and level 3 are displayed in the item of performance 303 as performance.
  • the setting value 282 of the infrastructure resource 283 of the system 281 displayed on the portal screen 210 changes according to the performance.
  • the model number of the infrastructure resource 283 of the system 281 is set to the most expensive model number.
  • the options are just examples, and other options may be used.
  • an example is shown in which, as a network condition, an item called external connection 304 displays whether there is an external connection or there is no external connection.
  • the infrastructure resources 283 and setting values 282 related to the network connection of the system 281 displayed on the portal screen 210 change according to the network conditions.
  • a firewall is deployed as a network connection infrastructure resource assuming external connection.
  • the options are just examples, and other options may be used.
  • the requirements displayed in FIG. 4 are just examples, and other requirements may be used. Furthermore, in FIG. 4, instead of the purpose desired to be achieved by the system 281, the past system 281 may be displayed as an option. In that case, the requirements when the past system 281 was deployed are input.
  • FIG. 5A is a diagram illustrating a specific example of the process performed in step S102 in FIG. 3.
  • the system construction device 100 presents on the portal screen 210 a system 281 plan that realizes the functional requirements and non-functional requirements input in step S101.
  • the user 201 inputs information necessary to deploy the system 281 presented on the portal screen 210 (see FIG. 5B). Furthermore, the user 201 may change each infrastructure resource 283 to another infrastructure resource 283.
  • FIG. 5B is an example of a method for inputting information necessary to deploy the system 281 presented on the portal screen 210 in step S103 in FIG. 3.
  • a screen 301 shown in FIG. 5B is displayed.
  • an Excel sheet containing various parameters necessary for deploying the infrastructure resource selected in FIG. 5A is uploaded as a parameter sheet, and the settings required for each infrastructure resource 283 are uploaded.
  • An example of inputting the value 282 is shown.
  • FIG. 5C is an example of changing each service to another service in step S103 in FIG. 3.
  • screen 320 in FIG. 5C is displayed.
  • an example was shown in which a resource for storing data is changed. If the user selects another resource, the resource is changed to the user's selected resource.
  • FIG. 6 is a diagram showing an example of the system source code related to the deployment process in step S104 and step S105 in FIG. 3.
  • Terrafrom is used for the deployment process.
  • Terraform is an open source automatic infrastructure construction tool developed by HashiCorp.
  • the template 221 generally includes a main.
  • a source code such as Tf (400), variables.
  • a variable file in a format such as Tf (410) and auto. input. and a variable input file in a format such as tfvars(420).
  • the template file may include program elements, such as if statements.
  • the deployment unit 240 deploys the infrastructure resource 283 on the execution environment 280 using the deployment tool based on the system source code generated in step S104.
  • FIG. 7 is a flowchart showing an example of a specific processing procedure in step S106 and step S107 in FIG. Each step in FIG. 7 will be explained below.
  • the setting change detection unit 250 detects that the user 201 has directly changed the system 281 on the execution environment 280 (step S201).
  • the standard source code is created using a function to export the system 281 prepared by the cloud vendor as the source code of each cloud vendor. After the acquisition, the difference between the acquired source code and the reference source code may be acquired using the sequential export function.
  • each cloud vendor provides metadata as standard indicating that the system 281 is the same, and this makes it possible to detect the addition of new equipment to the system 281.
  • each cloud vendor provides metadata as standard indicating that the system 281 is the same, and this makes it possible to detect the addition of new equipment to the system 281.
  • the setting change detection unit 250 checks whether a setting change has been detected (step S202). If a setting change is detected, the process advances to step S203; if a setting change is not detected, the process ends.
  • step S203 the setting change detection unit 250 checks the type of setting change.
  • settings changes related to the infrastructure resource 283 include adding or deleting a new infrastructure resource 283, and setting changes regarding the setting value 282 of the infrastructure resource 283 include changing the setting value 282 of the infrastructure resource 283. It is. If a setting change regarding the infrastructure resource 283 is detected, the process advances to step S207, and if a setting change regarding the setting value 282 of the infrastructure resource 283 is detected, the process advances to step S204.
  • the set value 282 here is a parameter written on the parameter sheet shown in FIG. 5B.
  • the setting change reflection unit 260 checks whether the setting change is related to the existing setting value 282 (step S204).
  • the existing setting value 282 refers to a setting value 282 that has already been defined in the system source code.
  • a VM Virtual Machine
  • a VM is a virtual environment that is created on a physical hardware system (off-premises or on-premises), has its own CPU, memory, network interface, and storage, and functions as a virtual computer system.
  • the VM size is set to small in the part where the VM is defined as the system source code. After that, when the VM size is manually changed to medium by the user 201, the VM size is determined to be the existing setting value 282 because it is the setting value 282 that has already been defined as the system source code. . Further, if a setting value that is not defined as the system source code, for example, a VM tag is added, it is determined that the setting value 282 is not an existing setting value 282 because it is not defined as the system source code. If the setting is to be changed regarding the existing setting value 282, the process advances to step S205; otherwise, the process advances to step S206.
  • FIG. 8 is a diagram illustrating a specific example of a method for determining the existing setting value 282, which is referred to in step S202.
  • the system construction device 100 has information as a system source code as to which infrastructure resource 283 defines which variable. For example, if the infrastructure resource 283 is a VM, a certain variable is defined in lines 1-9 of the path "./tempA,” in the system source code, and a variable is defined in the path "./module" in the system source code. You can see that it is called on lines 10-20 of the path. By using this, the infrastructure resource 283 name detected as a difference and its variable name are input, and it is searched and determined whether the existing setting value 282 exists.
  • the setting change reflection unit 260 updates the current setting value of the corresponding setting value 282 using information about which infrastructure resource 283 defines which variable as the system source code. Change the value to the difference setting value. This allows configuration changes to be modified based on the original coding rules.
  • the setting change reflection unit 260 uses the information about which infrastructure resource 283 defines which variable as the system source code to update the corresponding setting value 282 as a new setting value. It is added to the system source code (step S206). After that, the process advances to step S205, and the current setting value 282 is set. This allows configuration changes to be modified based on the original coding rules.
  • the setting change reflection unit 260 checks whether the setting change is related to an existing infrastructure resource 283 (step S207).
  • Existing infrastructure resources 283 refer to infrastructure resources 283 that have already been defined in the system source code. For example, if the infrastructure resource 283 of a VM is defined as a system source code, and the user 201 manually adds another VM, the VM is determined to be an existing infrastructure resource 283. Furthermore, if a new VM that is not defined as an infrastructure resource 283 is added, it is determined that it is not an existing infrastructure resource 283.
  • the process advances to step S208; otherwise, the process advances to step S209.
  • the configuration change reflection unit 260 adds the existing infrastructure resource 283 to the system source code (step S208).
  • the source code program of each infrastructure resource 283 registered in the repository 220 in advance is searched using the name of the added infrastructure resource 283 obtained as a difference. Thereafter, the source code program of the identified infrastructure resource 283 is added to the system source code.
  • the setting change may also be the deletion of a resource, in which case it is sufficient to delete the portion that defines the relevant resource in the source code program.
  • the source code program of the system source code includes a part that defines the infrastructure resources 283 to be used and a part that defines and sets the setting values 282 of the infrastructure resources 283. That is, when there is a change in the system source code, a part that defines the infrastructure resource 283 of the registered source code program is added to the part that defines the infrastructure resource 283 to be used in the system source code. . Further, a part defining variables used by the registered source code program is added to a part defining variables used by the infrastructure resource 283 in the system source code. Then, a portion for setting the setting value 282 used by the registered source code program is added to each portion of the system source code for setting the setting value 282 used by the infrastructure resource 283.
  • mapping methods have been proposed in the past. For example, there is a method of manually associating variable names output as difference information with variable names of the source code program, or a method of calculating the similarity between variable names output as difference information and variable names of the source code program. and how to do so. This allows configuration changes to be modified based on the original coding rules.
  • FIG. 9 is a flowchart showing an example of a specific processing procedure in step S209. Each step in FIG. 9 will be explained below.
  • the setting change reflection unit 260 searches for the source code program of the corresponding infrastructure resource 283 from the name of the infrastructure resource 283 included in the difference information (step S301).
  • Terraform publishes an API (Application Programming Interface) for searching, and it is possible to obtain search results by adding search parameters to a specific URL.
  • a shared repository may be set up that is managed by an organization to which the user 201 belongs.
  • an example of a source code program may be obtained by web scraping from a page explaining the relevant infrastructure resource described in the official page of the relevant infrastructure resource 283.
  • the setting change reflection unit 260 examines the source code program of the acquired infrastructure resource 283 (step S302).
  • the source code program of the acquired infrastructure resource 283 it is a possibility that there is a source code program among the candidates that does not include the corresponding infrastructure resource. Therefore, multiple candidate source code programs are analyzed to check whether they contain the characters of the corresponding infrastructure resource. After that, source code programs that do not include that character are deleted from the candidates.
  • candidates may be examined using metadata possessed by the source code program.
  • a source code program with a large number of stars indicating the popularity of the source code program may be selected. Thereby, one source code program is selected from a plurality of acquired source code programs.
  • the setting change reflection unit 260 checks whether a candidate exists based on the scrutiny performed in step S302 (step S303). If the number of candidates is 1, the process advances to step S304, and if the number of candidates is 0, the process ends.
  • step S304 modifying the source code program refers to rewriting the obtained source code program based on the coding rule specified by the user 201.
  • a specific example of the coding rule is a method of converting variable names in a source code program according to a naming rule specified by the user 201. This is because although configuration item names are defined for resources in the construction tool, the variable names for those configuration item names are named by the developer, so the naming rules are not necessarily unified. This is because there is no
  • a source code program is lexically analyzed based on the grammar of the programming language and converted into a token string. Convert the converted token string to a tree structure. Based on the tree structure of the conversion result, check the variable names and perform conversion according to the naming rules. For example, adding the resource name to the front of the setting item name and connecting it with an underscore, or using all uppercase letters.
  • Another example of a coding rule is to match the directory structure to the original source code program. For example, there is a method of cutting out each resource as a separate source code program file and calling each resource as a module.
  • the directory structure differs depending on the method of calling the directory structure as a module and the method of realizing the directory structure with one source code program.
  • the obtained source code program is placed on the module directory, and the part that calls the obtained source code program is added to the original source code program.
  • the setting change reflection unit 260 automatically adds a source code program, but the method is not necessarily limited to automatic addition, and other users 201 are notified and the user 201 is informed of the new resource. It is also possible to prompt the user to create a source code program and obtain the created source code program.
  • the system construction device 100 detects a change in the settings of the system 281, and reflects the change in setting to the system source code based on the coding rule.
  • the system construction device 100 does not require extra man-hours to automatically reflect settings changes made manually by the user 201 in the construction information, and the system construction device 100 does not require any extra man-hours to automatically reflect settings changes made manually by the user 201 in the construction information. Since there is no need to make corrections based on coding rules, the number of man-hours required to reflect setting changes can be reduced.
  • the user 201 inputs the functional requirements and non-functional requirements of the system 281 on the portal screen 210, presents the system 281 that meets the requirements, and the user 201 customizes the system 281. Then, the system 281 is automatically constructed. Thereby, even if the user 201 has no knowledge of the design of the system 281 or the automatic construction technology of the system 281, the user 201 can create the system 281 that meets the requirements.
  • Example 2 Next, a system construction apparatus according to a second embodiment of the present invention will be described.
  • the user 201 inputs the functional requirements and non-functional requirements of the system 281 on the portal screen 210, the system 281 that satisfies the requirements is presented, and the user 201 customizes the system 281.
  • a requirement input screen is not displayed on the portal screen 210, and the system is constructed based on the system source code written by the user 201. This makes it possible to create and manage the system 281 based on the system source code even if the user 201 creates the system source code himself, such as when the user 201 is familiar with automatic construction technology for the system 281. can.
  • FIG. 10 is a flowchart illustrating a procedure for the system construction device 100 to construct and manage a system in the second embodiment. Each step in FIG. 10 will be explained below.
  • the system construction device 100 receives the system source code from the user 201 (step S401).
  • a screen similar to that shown in FIG. 5B may be displayed on the portal screen 210 to allow uploading of the system source code.
  • a text editor capable of writing system source code may be displayed on the portal screen 210, and the user 201 may directly write the system source code.
  • the deployment unit 240 performs deployment processing based on the system source code received in step S401 (step S402). This process is similar to step S104 in FIG.
  • the user may perform the deployment process.
  • a system is constructed using Terrafrom construction commands in the user's environment.
  • Steps S403 and S404 are similar to steps S106 and S107 in FIG. 3.
  • the user when the user 201 performs the deployment process, the user inputs information regarding the system 281 for which configuration changes are to be detected and construction information based on system source code, and the configuration changes are detected and reflected.
  • a system is constructed based on the system source code written by the user 201.
  • the system can be created and managed based on the system source code.
  • a system construction device is a system construction device that constructs a system including infrastructure resources and setting values for the infrastructure resources on a predetermined execution environment, and is capable of building a system that satisfies desired requirements.
  • An input section for inputting requests, a system source code creation section for creating a first source code that defines a system that satisfies desired requirements, and a deployment section for deploying and building a system on the execution environment based on the requests.
  • a settings change detection unit detects a difference between a second source code and a first source code that define the changed system; and a settings change detection unit.
  • a settings change reflection unit that reflects the detected difference in the first source code
  • the setting change reflection unit reflects the difference in the first source code based on a coding rule applied to the first source code.
  • the setting change reflection unit corrects the setting value in the second source code based on the coding rule, and corrects the first source code. Furthermore, if the difference includes the addition of an infrastructure resource, the configuration change reflection unit obtains the source code of the added infrastructure resource, modifies the source code based on the coding rules, and updates the first source code. Correct. This allows any changes made to the system source code to be reflected appropriately.
  • the settings change detection unit determines whether the added infrastructure resource is a new infrastructure resource based on metadata that specifies the system. This makes it possible to appropriately modify the source code even if a new resource is added that was not anticipated in the prior art.
  • the input section includes a portal screen display section, the requirements include functional requirements and non-functional requirements, and the portal screen display section presents the user with system candidates that satisfy the input functional requirements or non-functional requirements. do. This allows the user to select candidates by separating functional requirements and non-functional requirements, improving convenience for the user. Additionally, desired requirements can be added to the user by automatically selecting and presenting system candidates. It becomes possible to give notice for correction.
  • the deploying unit creates construction information for constructing the system selected by the user based on the user's selection of the presented system candidates, and constructs the system on the execution environment. Thereby, it is possible to realize rapid system construction by utilizing the information stored in the repository of the system construction device.
  • the present invention is not limited to the embodiments described above, and includes various modifications.
  • the above-described embodiments have been described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to having all the configurations described.
  • System construction device 100: System construction device, 210: Portal screen (input section/portal screen display section), 220: Repository, 230: System source code creation section, 240: Deployment section, 250: Settings change detection section, 260: Settings change reflection section , 270: Coding rule storage section, 280: Execution environment, 281: System, 282: Setting value, 283: Infrastructure resource

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。

Description

システム構築装置
 本発明は、所定の実行環境上にシステムを構築するシステム構築装置に関する。
 近年、クラウドコンピューティング技術の発展に伴い、IT(Information Technology)リソースの仮想化が進んでいる。こうした技術の発達により、仮想サーバやコンテナなどの仮想化技術とソースコードや設定ファイルなどに基づいてシステムをデプロイするIaC(Infrastructure as Code)とを活用したシステムの自動構築技術が注目されている。
 特許文献1の技術によれば、システム要件が記載されたオーダーシートに基づいて、オーダーシートをソースコードに変換しリソースのデプロイを自動化する技術が開示されている。
特開第2021-157612号公報 特開第2021-140372号公報
 特許文献1に記載の技術を用いることで、ユーザがコーディング知識を持ち合わせていない場合においても、システム要件に合わせてシステムを自動構築することが可能となる。一方で、ユーザがソースコードを変更せずに、デプロイされたシステムの構成を変更した場合に、対象システムのソースコードと、対象システムの構成が異なるという課題がある。
 この課題に関して、特許文献2は、システムの設定変更の有無を検出し、検出された設定変更をソースコードに反映する技術を記載している。
 特許文献2においては、構築対象システムが備える機器を監視対象としており、システムに新規機器を追加するような変更に対してソースコードに反映することができないという課題がある。また、ソースコードの書き方であるコーディングルールはユーザによって異なることが多いため、ソースコードへの反映方法によっては、修正されたソースコードのコーディングルールが一貫性に欠けてしまうおそれがある。したがって、ソースコードの管理やユーザの理解を容易にする目的で、反映したのちにソースコードが一貫性を有するように修正する必要がある。
 本発明は、以上のような課題に鑑みてなされたものであり、ユーザがソースコードを変更せず、システムの構成を変更した場合に、システムへの新規リソース追加も含めて、ユーザの書き方に合わせた形で、ソースコードとシステムの構成の差異を修正することを目的とする。
 本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。
 本発明に係るシステム構築装置によれば、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構成との差異を修正することができる。
実施例1に係るシステム構築装置100のハードウェア構成図。 実施例1に係るシステム構築装置100の機能ブロック構成図。 実施例1に係るシステム構築装置100が実行する処理のフローチャート。 図3のフローチャート中のステップS101の具体例を説明する図。 図3のフローチャート中のステップS102の具体例を説明する図。 図3のフローチャート中のステップS103の具体例を説明する図。 図3のフローチャート中のステップS103の具体例を説明する図。 図3のステップS104とステップS105のデプロイ処理に係るシステムソースコードの一例を示す図。 図3のフローチャート中のステップS106とS107の具体例を説明するフローチャート。 図7のフローチャート中のステップS202において参照される、既存の設定値282の判断方法について具体例を説明する図。 図7のフローチャート中のステップS209の具体例を説明するフローチャート。 実施例2に係るシステム構築装置100が実行する処理のフローチャート。
<実施例1>
 図1は、本実施例に係るシステム構築装置100のハードウェア構成の一例を示している。システム構築装置100は、図1に示すように、演算装置110と、記憶装置120と、入出力I/F(Interface)130と、通信I/F(Interface)140等のハードウェアを備える。
 演算装置110は例えばCPU(Central Processing Unit)であり、CPUによる処理によって後述する種々の機能を発揮する。
 記憶装置120は、例えばRAM(Random Access Memory)及びROM(Read Only Memory)を含み、演算装置110が用いるデータを格納する。
 入出力I/F130は、例えばタッチパネル機能を有するディスプレイであり、演算装置110による処理結果や後述するポータル画面210のユーザインターフェースを画面上に表示する。
 通信I/F140は、例えば通信チップ又はNIC(Network Interface Card)であり、後述する実行環境280や利用者201との間の通信に用いる。
 システム構築装置100の各部がデータを受け付ける場合、入出力I/F130を介してデータを受け付けても良く、また、通信I/F140を介してデータを受け付けても良い。
 図2は、システム構築装置100が有する各機能部の構成の一例を示す機能ブロック図である。システム構築装置100は、ポータル画面210と、リポジトリ220と、システムソースコード作成部230と、デプロイ部240と、設定変更検出部250と、設定変更反映部260と、コーディングルール保存部270と、を含んで構成される。
 本実施例では、あらかじめデプロイ用のテンプレート221やモジュール222のソースコードが指定されたリポジトリ220に登録されている。リポジトリ220の例としては、クラウドサービスでは、GitHub(https://github.com/)、OSSでは、GitLabといったものである。ソースコードの例については、図6を用いて後述する。
 なお、図2では、複数のテンプレート221とモジュール222を、1つのリポジトリ220で管理する例を示しているが、複数のプロジェクトのそれぞれに対応するソースコードごとにリポジトリ220が分かれている構成であってもよい。
 ここで、ソースコードとは、特定のシステム281を構築するために活用されるものである。例えば、1つのシステム281が1つのテンプレート221に対応する構成だけでなく、システム281の一部を構成するひとまとまりの機能であるモジュール222もソースコードに含まれる。その際は、複数のモジュール222を組み合わせて1つのシステム281のシステムソースコードを作成する。なお、本装置100で管理したり表示したりするための各種の情報には、システム281を構築するためのソースコードであるテンプレート221やモジュール222、システムソースコードの実体または参照等が含まれる。
 システム構築装置100は、システム構築装置100の利用者201に対してポータル画面210を不図示の表示装置上に表示する。ポータル画面210の例については、図4と図5を用いて後述する。また。ポータル画面210には不図示のCPUが搭載されており、リポジトリ220内のテンプレート221及びモジュール222から、後述するように利用者の選択に従ってシステムの候補を提示する。
 利用者201は、ポータル画面210を用いて今回、構築したいシステム281を選択する。例えば、利用者201がクラウドサービスの機能要件及び非機能要件を入力し、事前に用意されたテンプレート221を提示する。テンプレート221は、過去の実績に基づき各要件を満たすパブリッククラウドサービス、プライベートクラウドサービスなどが組み合わされたサービスである。
 非機能要件は、ネットワークに関する要件を含んでよい。ネットワークに関する要件として、パブリックIPの利用の有無、ファイアウォール利用の有無、暗号化機能の利用の有無、等が例として挙げられるが、これらに限らず、ネットワークに関する様々な要件を含んでよい。
 機能要件は、利用する実行環境280が、複数種類のクラウドのうちのいずれかであるかを示す情報を含んでもよい。機能要件は、上述した要件の他、システム281の目的、インフラに関連する様々な要件を含んでよい。
 その後、提示されたテンプレート221の各インフラストラクチャーリソース283を同様の機能を実現可能な別インフラストラクチャーリソース283に変更したり、インフラストラクチャーリソース283の追加や削除を行い、カスタマイズする。そして、カスタマイズ後に、各インフラストラクチャーリソース283がデプロイするために必要とする設定値282をパラメタシートなどから入力することで、構築したいシステム281が選択される。
 利用者201が構築したいシステム281を選択すると、システムソースコード作成部230が、リポジトリ220から選択されたシステム281のテンプレート221やモジュール222を用いてシステムソースコードを作成する。
 システムソースコードを作成後、デプロイ部240は実行環境280上にデプロイ処理を実施する。実行環境280は、システム281を動作させるための環境である。実行環境280は、例えば、パブリッククラウドサービス、プライベートクラウドサービス、OpenStack、Kubernetes等のオーケストレーションツールで管理されるITリソースのクラスタ等である。また、利用者201が選択したシステム281を動作させる実行環境280については、利用者201が指定する形式であってもよい。このとき実行環境280は、利用者201毎に異なる実行環境であってもよいし、1つの実行環境を共用する形であってもよい。
 デプロイ部240によるデプロイ処理が行われた結果、実行環境280には、システムソースコードに基づいてインフラストラクチャーリソース283、インフラストラクチャーリソース283の設定値282等を含む、システム281が構築される。ここで、インフラストラクチャーリソース283は、システムソースコードの記述に応じて、1または複数であってよい。
 そして、利用者201は、実行環境280上で、構築されたシステム281に必要な変更を加え、利用者201の用途にあった開発(システム281に対する変更)を行う。
 設定変更検出部250は、構築対象のシステム281の設定変更の有無を検出する。設定変更検出部250は、システム281の設定変更が有る場合に、システムソースコード作成部230が作成したシステムソースコードによって定義されるシステム281の構成と実行環境上における現在のシステム281との差分として設定変更内容を検出・抽出する。
 設定変更反映部260は、コーディングルール保存部270に保存されたコーディングルールに基づいて、設定変更検出部250が検出した差分をシステムソースコード作成部230が作成したシステムソースコードに反映させる。ここで、コーディングルールは例えば、変数名の定義として各ベンダーが提示する標準的な変数名から派生したものであることや、IDなどの変数がハードコーディングされていないことなどが挙げられる。
 なお、以降の図および説明では、実行環境280としては、パブリッククラウドサービスのIaaS(Infrastructure as a Service)パブリッククラウド、デプロイ処理としては、Terrafrom、テンプレート221やモジュール222としては、Terraformが規定するHCL(HashiCorp Configuration Language)で記述されたソースコードを例に挙げて説明する。しかしながら、本実施例は、上述の構成に限られるものではない。例えば、実行環境280としては、Kubernetes、実行環境280に構築する対象としては、コンテナ、デプロイ処理としては、Helmといった組合せを採用してもよい。
 図3は、本発明の実施例1に係るシステム構築装置100が実行する処理の一例を示すフローチャートである。以下図3の各ステップについて説明する。また、以下では図3に示す各ステップの概要を説明し、その詳細については後述する。
 利用者101は、ポータル画面210から所望の要件(機能要件及び非機能要件)を入力する(ステップS101)。
 ポータル画面210上には、入力された機能要件および非機能要件を実現するシステム281の候補が提示される(ステップ102)。
 利用者201は、ポータル画面210に提示されたシステム281をデプロイするために必要な情報を入力する(ステップS103)。必要な情報は、例えば、システム281に含まれる各インフラストラクチャーリソース283の設定値282である。設定値282としては例えば、各インフラストラクチャーリソース283の名前やインフラストラクチャーリソース283の採用・運用により発生する料金の請求先などが含まれる。また各インフラストラクチャーリソース283の提供者により規定されている設定値282であってもよい。さらに、利用者201は各インフラストラクチャーリソース283を別のインフラストラクチャーリソース283へ変更してもよい。
 システムソースコード作成部230は、ポータル画面210に提示されたシステム281に含まれるインフラストラクチャーリソース283の情報とそのシステム281をデプロイするために必要な情報を入力として、システムソースコードを生成する(ステップS104)。
 デプロイ部240は、システムソースコード作成部230が生成したシステムソースコードを用いて、システム281を実行環境280上に構築する。
 設定変更検出部250は、利用者201がシステム281を直接変更したか否かを監視・検出する。そして、設定変更が検出された場合、設定変更検出部250は、変更内容を検出・抽出する(ステップS106)。設定変更検出部250は、どのような手法により変更された内容を検出しても良い。設定変更検出部250は、差分のみを抽出しても良い。
 設定変更反映部260は、コーディングルール保存部270に保存された、システムソースコード作成部230が採用したコーディングルールを参照し、設定変更検出部250が抽出した差分をシステムソースコードに反映させる。以上の工程により処理は終了する。
 図4は、図3のステップS101においてポータル画面210上に表示される画面の具体例を説明する図である。図4に示すように、ポータル画面210上には要件入力画面300が表示される。利用者201はポータル画面210上で、システム281で実現したい目的や、システム281に求める可用性とシステムの性能、システムを運用するネットワーク条件を要件入力画面300上で選択する。
 図4においては、システム281によって実現したい目的として、サービス類型301という項目で開発型や分析型、連携型の選択肢を表示する例を示した。利用者201がシステム281で実現したい目的を変更すると、ポータル画面210上で表示されるシステム281のインフラストラクチャーリソース283の種類がその目的にしたがって変化する。具体例としては、分析型が選択された場合に、システム281がデータを収集し分析を行うように設計される。このような自動化により利用者201は、通常システム281の設計でかかる工数を低減することができる。選択肢は一例であり、その他の選択肢であってもよい。
 図4においては、可用性として、可用性302という項目で本番向けやPoC(Proof of Concept)向けの選択肢を表示する例を示した。なお、PoCとは、新しい概念や理論、原理、アイディアの実証を目的とした、試作開発の前段階における検証やデモンストレーションのことをいう。利用者201が可用性を変更すると、ポータル画面210上で表示されるシステム281のインフラストラクチャーリソース283の構成や設定値282が選択された可用性にしたがって変化する。具体例としては、本番向けが選択された場合に、システム281が複数のリージョン(例えば東京と大阪)に分散してデプロイされ、あるリージョンで災害が起きた際にもシステム281が動作し続けるように設計される。すなわち冗長性が担保される。選択肢は1例であり、その他の選択肢であってもよい。
 図4においては、性能として、性能303の項目でレベル1やレベル2、レベル3の選択肢を表示する例を示した。利用者201が性能を変更すると、ポータル画面210上で表示されるシステム281のインフラストラクチャーリソース283の設定値282がその性能にしたがって変化する。具体例としては、レベル3が選択された場合に、システム281のインフラストラクチャーリソース283の型番が最も高価な型番に設定される。選択肢は一例であり、その他の選択肢であってもよい。
 図4においては、ネットワークの条件として、外部接続304という項目で外部接続ありや外部接続なしを表示する例を示した。利用者201がネットワークの条件を変更すると、ポータル画面210上で表示されるシステム281のネットワーク接続に関するインフラストラクチャーリソース283と設定値282がそのネットワークの条件にしたがって変化する。具体例としては、外部接続ありが選択された場合に、外部接続を前提として、ネットワーク接続インフラストラクチャーリソースとしてファイアウォールがデプロイされる。選択肢は一例であり、その他の選択肢であってもよい。
 図4に表示される要件は、一例であり、その他の要件であってもよい。さらには、図4においては、システム281で実現したい目的の代わりに、過去のシステム281を選択肢として表示をしてもよい。その場合、過去のシステム281をデプロイした際の要件が入力される。
 図5Aは、図3におけるステップS102において行われる処理の具体例を説明する図である。システム構築装置100は、ステップS101で入力された機能要件および非機能要件を実現するシステム281案をポータル画面210上に提示する。利用者201は、ポータル画面210に提示されたシステム281をデプロイするために必要な情報を入力する(図5B参照)。さらには、利用者201は各インフラストラクチャーリソース283を別のインフラストラクチャーリソース283へ変更してもよい。
 図5Bは、図3におけるステップS103においてポータル画面210に提示されたシステム281をデプロイするために必要な情報を入力する方法の一例である。図5Aにおいて「パラメタ入力」を選択すると、図5Bに示す画面301が表示される。そして、本実施例においては、図5Aで選択されているインフラストラクチャーリソースをデプロイするために必要な各種パラメタが記載されたエクセルシートをパラメタシートとしてアップロードし、各インフラストラクチャーリソース283が必要とする設定値282を入力する例を示した。
 図5Cは、図3におけるステップS103において各サービスを別のサービスへ変更する際の例である。図5Aの画面300上で「カスタマイズ」を選択すると、図5Cの画面320が表示される。本実施例においては、データを格納するリソースを変更する例を示した。ユーザが別のリソースを選択すると、ユーザが選択したリソースに変更される。
 図6は、図3のステップS104とステップS105のデプロイ処理に係るシステムソースコードの一例を示す図である。本実施例においては、デプロイ処理としては、Terrafromを用いる場合について説明する。Terraformとは、HashiCorp社により開発されているオープンソースのインフラ自動構築ツールである。
 テンプレート221は、一般に、どのようなインフラストラクチャーリソース283をデプロイするのかを定義するmain.Tf(400)のようなソースコードと、各インフラストラクチャーリソース283に与える変数および当該変数のデフォルト値が定義されたvariables.Tf(410)のような形式である変数ファイルと、各インフラストラクチャーリソース283に与える変数の設定値282が定義されたauto.input.tfvars(420)のような形式である変数入力ファイルとを含む。
 例えば、記述401(「resource “aws_s3_bucket”“s3_bucket”」)は、リソースとして「aws_s3_bucket」をデプロイすることを意味している。また、記述401(「bucket = “${var.foo}”」)は、variables.Tf(410)に定義された記述411(「variable “foo”{}」)を読み込むことを意味している。
 そして、デプロイ処理時に、変数key「foo」の変数に値を指定しなければ、デフォルト値である「foo:1」が用いられる。なお、デプロイ処理時に、別の値、例えば、変数key「foo」の変数に、auto.input.tfvars(420)内で値「foo = “dev-var”」を指定すれば、記述411は、「foo:“dev-var”」のように生成される。
 さらに、テンプレートファイルには、プログラム的な要素、例えば、if文を含んでいてもよい。Terraformでは、使用可能なプログラム的な要素が定義されており、countという変数によって、リソースを何個構築するかを制御できる。auto.input.tfvars(420)内で値「S3_count = 1」を指定すれば、「resource “aws_s3_bucket” “s3_bucket”」は一つ生成される。これにより、図5Bで入力された情報に基づいてカウントを制御することにより、リソースをカスタマイズすることができる。
 以上、ステップS104で生成されたシステムソースコードに基づいてデプロイ部240はデプロイツールを用いて実行環境280上にインフラストラクチャーリソース283をデプロイさせる。
 図7は、図3におけるステップS106とステップS107における具体的な処理手順の一例を示すフローチャートである。以下図7の各ステップについて説明する。
 設定変更検出部250は、利用者201がシステム281を実行環境280上で直接変更したことを検出する(ステップS201)。具体例としては、図3のステップS105にてシステム281が構築された際に、クラウドベンダーが用意しているシステム281を各クラウドベンダーのソースコードとしてエクスポートする機能を用いて基準となるソースコードを取得した後に、逐次エクスポート機能により取得したソースコードと基準となるソースコードとの差分を取得してもよい。
 差分の取得方法としては、上述のように各システム281が構築されている環境からエクスポートして取得することが望ましい。各クラウドベンダーが同じシステム281であることを示すメタデータを標準で用意しており、それによってシステム281への新規機器の追加の検知も可能になるからである。また、図2のステップS105にてシステム281を構築する際に、同じシステムであることを示すメタデータを付与することによっても可能である。
 続いて、設定変更検出部250は、設定変更が検出されたかどうかを確認する(ステップS202)。設定変更が検出された場合は、ステップS203に進み、設定変更が検出されなかった場合は、処理を終了する。
 設定変更があった場合(ステップS202で“Yes”)、設定変更検出部250は、設定変更の種類を確認する(ステップS203)。設定変更の種類には、インフラストラクチャーリソース283に関する設定変更とインフラストラクチャーリソース283の設定値282に関する設定変更の2種類が存在する。インフラストラクチャーリソース283に関する設定変更としては、新規にインフラストラクチャーリソース283を追加、削除する場合があり、インフラストラクチャーリソース283の設定値282に関する設定変更は、インフラストラクチャーリソース283の設定値282を変更した場合である。インフラストラクチャーリソース283に関する設定変更が検出された場合は、ステップS207に進み、インフラストラクチャーリソース283の設定値282に関する設定変更が検出された場合は、ステップS204に進む。なお、ここでいう設定値282とは、図5Bに示したパラメタシートに記載されたパラメタである。
 設定変更が設定値282の変更であった場合、設定変更反映部260は、既存の設定値282に関する設定変更かどうかを確認する(ステップS204)。既存の設定値282とは、システムソースコードの中ですでに定義されている設定値282のことを示す。一例としては、VM(Virtual Machine)をインフラストラクチャーリソース283として設定していた場合を想定する。なお、VMとは物理ハードウェアシステム上に作成され (場所はオフプレミスまたはオンプレミス)、固有の CPU、メモリー、ネットワーク・インタフェース、ストレージを持ち、仮想コンピュータシステムとして機能する仮想環境のことである。
 そして、VMをシステムソースコードとして定義している部分で、VMのサイズをsmallと設定していたとする。その後、利用者201によって手動でVMのサイズがmediumに変更された場合、VMのサイズはシステムソースコードとしてすでに定義されている設定値282であるため、既存の設定値282であると判断される。また、システムソースコードとして定義されていない設定値、例えばVMのタグを追加した場合は、システムソースコードとして定義されていない設定値282であるため、既存の設定値282ではないと判断される。既存の設定値282に関する設定変更の場合は、ステップS205に進み、そうではない場合は、ステップS206に進む。
 図8は、ステップS202において参照される、既存の設定値282の判断方法について具体例を説明する図である。システム構築装置100は、システムソースコードとしてどのインフラストラクチャーリソース283がどの変数を定義しているかという情報を持つ。例えば、インフラストラクチャーリソース283がVMである場合、ある変数がシステムソースコードの「./tempA,」というパスの1-9行目に定義されており、また、システムソースコードの「./module」というパスの10-20行目で呼び出されていることがわかる。これを用いることで、差分として検出されたインフラストラクチャーリソース283名とその変数名を入力として、既存の設定値282として存在するかどうかを検索し、判断する。
 既存の設定値282の設定変更が検出された場合、設定変更反映部260は、システムソースコードとしてどのインフラストラクチャーリソース283がどの変数を定義しているかという情報を用いて、該当設定値282の現在値を差分の設定値に変更する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
 既存のパラメタの設定変更が検出されない場合、設定変更反映部260は、システムソースコードとしてどのインフラストラクチャーリソース283がどの変数を定義しているかという情報を用いて、該当設定値282を新規設定値としてシステムソースコードに追加する(ステップS206)。その後、ステップS205に進み、現在の設定値282に設定する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
 設定変更がインフラストラクチャーリソース283の変更であった場合、設定変更反映部260は、既存のインフラストラクチャーリソース283に関する設定変更かどうかを確認する(ステップS207)。既存のインフラストラクチャーリソース283とは、システムソースコードの中ですでに定義されているインフラストラクチャーリソース283のことを示す。一例としては、VMのインフラストラクチャーリソース283をシステムソースコードとして定義していた場合、利用者201が手動で別のVMを追加した場合、既存のインフラストラクチャーリソース283であると判断される。また、インフラストラクチャーリソース283として定義されていない新たなVMを追加した場合は、既存のインフラストラクチャーリソース283ではないと判断される。さらに、追加されたVMが現状のシステムソースコードに含まれていない場合であっても、VMのインフラストラクチャーリソース283のソースコードをリポジトリ220内にとして持っている場合には、既存のインフラストラクチャーリソース283であると判断される。既存のリソースに関する設定変更の場合は、ステップS208に進み、そうではない場合は、ステップS209に進む。
 既存のリソースの設定変更が検出された場合(ステップS207で“Yes”)、設定変更反映部260は、システムソースコードに既存のインフラストラクチャーリソース283の追加を行う(ステップS208)。具体例としては、差分として得られた追加されたインフラストラクチャーリソース283の名前を用いて、あらかじめリポジトリ220に登録された各インフラストラクチャーリソース283のソースコードプログラムを検索する。その後、特定されたインフラストラクチャーリソース283のソースコードプログラムをシステムソースコードに追加する。なお、ここでは既存リソースの追加について説明したが、設定変更がリソースの削除である場合もあり、その場合にはソースコードプログラム内の該当するリソースを定義する部分を削除すればよい。
 上述の通り、システムソースコードのソースコードプログラムには、使用するインフラストラクチャーリソース283を定義する部分と、インフラストラクチャーリソース283の設定値282を定義、設定する部分が存在する。すなわち、システムソースコードに変更があった場合には、システムソースコード内の、使用するインフラストラクチャーリソース283を定義する部分に、登録されたソースコードプログラムのインフラストラクチャーリソース283を定義する部分を追加する。また、システムソースコード内の、インフラストラクチャーリソース283で使用する変数を定義する部分に、登録されたソースコードプログラムの使用する変数を定義する部分を追加する。そして、システムソースコード内の、インフラストラクチャーリソース283で使用する設定値282を設定する部分に、登録されたソースコードプログラムの使用する設定値282を設定する部分を、それぞれ追加する。
 ここで、使用する設定値282を設定する部分に関しては、差分情報の変数名とソースコードプログラムでの変数名の対応付けを行う必要がある。対応付けの方法は従来いくつか提案されている。例えば、差分情報で出力される変数名とソースコードプログラムの変数名の対応付けを予め人手により行う方法、差分情報で出力される変数名とソースコードプログラムの変数名の類似度を計算し対応付けを行う方法などである。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
 既存のリソースの設定変更が検出されない場合、すなわち、新規のインフラストラクチャーリソース283の追加が検出された場合には、設定変更反映部260は、新規のインフラストラクチャーリソース283のソースコードプログラムの取得を行い、コードディングルールに基づいて修正を行い、追加を行う(ステップS209)。この処理について図9を用いて詳述する。図9は、ステップS209における具体的な処理手順の一例を示すフローチャートである。以下図9の各ステップについて説明する。
 設定変更反映部260は、差分情報が含むインフラストラクチャーリソース283の名前から該当インフラストラクチャーリソース283のソースコードプログラムを検索する(ステップS301)。これは、具体例としては、Terraformでは検索のためのAPI(Application Programming Interface)が公開されており、特定のURLに検索用のパラメタを追加して、検索結果を取得することができる。一例としては、「https://registry.terraform.io/v1/modules/search?q=network」に対し、GETメソッドを行うことにより、「network」という名前のリソースを検索することができる。また、利用者201が所属する団体で管理する共有リポジトリを設定してもよい。さらに、該当インフラストラクチャーリソース283の公式ページに記載されている該当インフラストラクチャーリソースを説明するページからソースコードプログラムの例をウェブスクレイピングにより取得してもよい。
 設定変更反映部260は、取得されたインフラストラクチャーリソース283のソースコードプログラムの精査を行う(ステップS302)。具体例としては、ステップS301で取得されたリソースのソースコードプログラムの候補が複数ある場合に、候補の中には、該当のインフラストラクチャーリソースを含まないソースコードプログラムが存在する可能性がある。そのため、複数候補のソースコードプログラムの解析を行い、該当インフラストラクチャーリソースの文字を含んでいるかを確認する。そのあと、その文字を含んでいないソースコードプログラムを候補から削除する。また、ソースコードプログラムが持つメタデータを用いて候補を精査してもよい。具体例としては、ソースコードプログラムの人気度を示すスターの数が多いものを選択してもよい。これにより、複数の取得されたソースコードプログラムから一つのソースコードプログラムを選択する。
 そして、設定変更反映部260は、ステップS302で行った精査により候補が存在するかどうかを確認する(ステップS303)。候補数が1の場合は、ステップS304に進み、候補数が0の場合は、処理を終了する。
 候補数が1であった場合(ステップS303で“Yes”)、設定変更反映部260は、ステップS302で精査を行い一つ選択されたソースコードプログラムの修正を行う(ステップS304)。ここで、ソースコードプログラムの修正とは、利用者201が指定したコーディングルールに基づいて、取得したソースコードプログラムを書き換えることを指す。コーディングルールの具体例としては、ソースコードプログラムの変数名を利用者201が指定する命名規則に従って変換する方法がある。これは、構築ツールでリソースに対して設定項目名は定義されているが、その設定項目名に対しての変数名は開発者が命名を行うため、その命名規則が統一されているとは限らないためである。
 該当の変数名について、ソースコードプログラムのコード解析を行う。コード解析の手法は、従来いくつか提案されている。例えば、ソースコードプログラムをプログラミング言語の文法に基づいて字句解析を行い、トークン列に変換する。変換したトークン列から木構造に変換する。変換結果の木構造を基づいて、変数名を確認し、命名規則に則って変換を行う。具体例としては、設定項目名にリソース名を前に追加しアンダーバーでつなげることや、すべて大文字にすることなどである。
 また、コーディングルールの他の例としては、ディレクトリ構成をもとのソースコードプログラムに合わせるというものがある。例えば、ソースコードプログラムとして、各リソースを別のソースコードプログラムファイルとして切り出して、それぞれをモジュールとして呼び出しを行う方式が存在する。その場合、ディレクトリ構成をモジュールとして呼び出しを行う方式と、一つのソースコードプログラムでディレクトリ構成を実現する方式でディレクトリ構成は異なる。モジュールとして呼び出しを行う方式の場合は、取得したソースコードプログラムをモジュールディレクトリ上に配置を行い、取得したソースコードプログラムを呼び出す部分を元々のソースコードプログラムに追加する。
 以上、設定変更反映部260が自動でソースコードプログラムの追加を行う説明を行ったが、方法は必ずしも自動追加に限るものではなく、その他利用者201に通知を行い、利用者201に新規リソースのソースコードプログラムを作成するように促し、作成されたソースコードプログラムを取得する形でもよい。
 本実施例に係るシステム構築装置100は、システム281の設定変更を検出し、その設定変更をコーディングルールに基づいてシステムソースコードへ反映する。コーディングルールに基づいて設定変更を修正することにより、システム281の設定変更の反映について利用者201が想定したソースコードプログラムとして管理できる。したがってシステム構築装置100は、利用者201が手動で設定変更を行った場合の構築情報への反映を自動で行うために余分な工数をかけることなく、また、自動の設定変更に対して自らのコーディングルールに基づいて修正する必要がないので、設定変更の反映作業の工数を抑制することができる。
 また、本実施例に係るシステム構築装置100においては、利用者201がポータル画面210上でシステム281の機能要件と非機能要件を入力し、要件を満たすシステム281を提示し、利用者201がカスタマイズし、システム281の構築を自動で行う。これにより、利用者201はシステム281の設計やシステム281の自動構築技術の知識がない場合でも、要件にあったシステム281を作成することができる。
<実施例2>
 次に、本発明の実施例2に係るシステム構築装置について説明する。実施例1においては、利用者201がポータル画面210上でシステム281の機能要件と非機能要件を入力し、要件を満たすシステム281を提示し、利用者201がカスタマイズする例を説明した。実施例2では、ポータル画面210上での要件入力画面の表示を行わず、利用者201が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者201がシステム281の自動構築技術に精通しているなど、利用者201が自らシステムソースコードを作成する場合においても、システムソースコードに基づいてシステム281を作成、管理することができる。
 図10は、本実施形態2においてシステム構築装置100がシステムを構築し管理する手順を説明するフローチャートである。以下図10の各ステップについて説明する。
 システム構築装置100は、利用者201からシステムソースコードを受け付ける(ステップS401)。受け付け方法の具体例としては、ポータル画面210上に図5Bと同様の画面を表示して、システムソースコードをアップロード可能にしてもよい。また、ポータル画面210にシステムソースコードを記述可能なテキストエディタを表示し、利用者201が直接システムソースコードを記述してもよい。
 デプロイ部240は、ステップS401で受け付けたシステムソースコードに基づいてデプロイ処理を行う(ステップS402)。この処理は図3のステップS104と同様である。本実施例においては、デプロイ処理をユーザが行ってもよい。その場合、Terrafromを用いる例としては、ユーザの環境でTerrafromの構築コマンドを用いてシステムの構築を行う。
 ステップS403及びS404は、図3のステップS106及びS107と同様である。本実施例において、デプロイ処理を利用者201が行った場合、設定変更を検出する対象のシステム281とシステムソースコードによる構築情報に関する情報をユーザが入力を行い、設定変更の検出と反映を行う。
 以上説明したように、本発明の実施例2では、利用者201が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者201がシステムの自動構築技術に精通しているなど、利用者201が自らシステムソースコードを作成したい場合においても、システムソースコードに基づいてシステムを作成、管理することができる。
 以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
(1)本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。
 上記構成により、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構築情報との差異を修正することができる。
(2)差分に設定値の変更が含まれる場合に、設定変更反映部は、第二ソースコードの設定値をコーディングルールに基づいて修正し、第一ソースコードを修正する。また、差分にインフラストラクチャーリソースの追加が含まれる場合に、設定変更反映部は、追加されたインフラストラクチャーリソースのソースコードを取得し、該ソースコードをコーディングルールに基づいて修正し、第一ソースコードを修正する。これにより、システムのソースコードに加えられる変更がどのような種類であっても、適切に修正を反映させることができる。
(3)設定変更検出部は、システムを特定するメタデータに基づいて、追加されたインフラストラクチャーリソースが新規のインフラストラクチャーリソースであるか否か判定する。これにより、従来技術において想定されていなかった新規リソースの追加が行われていた場合にも、適切にソースコードを修正することが可能になる。
(4)入力部はポータル画面表示部を含み、要件は機能要件と非機能要件とを含み、ポータル画面表示部は、入力された機能要件または非機能要件を満たすシステムの候補を利用者に提示する。これにより、利用者が機能要件と非機能要件とを切り分けて候補を選択することが可能になり、利用者にとって利便性が向上する。さらに、システムの候補が自動的に選択・提示されることにより、利用者に対して所望の要件を追加。修正するための気づきを与えることが可能になる。
(5)デプロイ部は、提示されたシステムの候補に対する利用者の選択に基づいて、利用者が選択したシステムを構築するための構築情報を作成し、システムを実行環境上に構築する。これにより、システム構築装置のリポジトリ内に保存された情報を活用して、迅速なシステム構築を実現できる。
 本発明は、前述した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
100:システム構築装置、210:ポータル画面(入力部・ポータル画面表示部)、220:リポジトリ、230:システムソースコード作成部、240:デプロイ部、250:設定変更検出部、260:設定変更反映部、270:コーディングルール保存部、280:実行環境、281:システム、282:設定値、283:インフラストラクチャーリソース

Claims (6)

  1.  所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、
     所望の要件を満たすシステム構築の要求を入力する入力部と、
     前記所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、
     前記実行環境上に、前記システムを前記要求に基づいてデプロイして構築するデプロイ部と、
     前記実行環境上に構築された前記システムが変更された場合に、変更された該システムを定義する第二ソースコードと前記第一ソースコードとの差分を検出する設定変更検出部と、
     前記設定変更検出部により検出された前記差分を前記第一ソースコードに反映させる設定変更反映部と、を備え、
     前記設定変更反映部は、前記第一ソースコードに適用されたコーディングルールに基づいて前記差分を前記第一ソースコードに反映させる、
     ことを特徴とするシステム構築装置。
  2.  請求項1に記載のシステム構築装置であって、
     前記差分に前記設定値の変更が含まれる場合に、前記設定変更反映部は、前記第二ソースコードの設定値を前記コーディングルールに基づいて修正し、前記第一ソースコードを修正する
     ことを特徴とするシステム構築装置。
  3.  請求項1に記載のシステム構築装置であって、
     前記差分に前記インフラストラクチャーリソースの追加が含まれる場合に、前記設定変更反映部は、追加された前記インフラストラクチャーリソースのソースコードを取得し、該ソースコードを前記コーディングルールに基づいて修正し、前記第一ソースコードを修正する
     ことを特徴とするシステム構築装置。
  4.  請求項3に記載のシステム構築装置であって、
     前記設定変更検出部は、前記システムを特定するメタデータに基づいて、
     追加された前記インフラストラクチャーリソースが新規のインフラストラクチャーリソースであるか否か判定する
     ことを特徴とするシステム構築装置。
  5.  請求項1に記載のシステム構築装置であって、
     前記入力部はポータル画面表示部を含み、前記要件は機能要件と非機能要件とを含み、 前記ポータル画面表示部は、入力された前記機能要件または前記非機能要件を満たすシステムの候補を利用者に提示する
     ことを特徴とするシステム構築装置。
  6.  請求項5に記載のシステム構築装置であって、
     前記デプロイ部は、前記提示されたシステムの候補に対する前記利用者の選択に基づいて、前記利用者が選択したシステムを構築するための構築情報を作成し、前記システムを前記実行環境上に構築する
     ことを特徴とするシステム構築装置。
PCT/JP2023/015440 2022-05-13 2023-04-18 システム構築装置 WO2023218875A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202380019637.2A CN118633076A (zh) 2022-05-13 2023-04-18 系统构建装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-079548 2022-05-13
JP2022079548A JP2023167974A (ja) 2022-05-13 2022-05-13 システム構築装置

Publications (1)

Publication Number Publication Date
WO2023218875A1 true WO2023218875A1 (ja) 2023-11-16

Family

ID=88730261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/015440 WO2023218875A1 (ja) 2022-05-13 2023-04-18 システム構築装置

Country Status (3)

Country Link
JP (1) JP2023167974A (ja)
CN (1) CN118633076A (ja)
WO (1) WO2023218875A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006018735A (ja) * 2004-07-05 2006-01-19 Hitachi Software Eng Co Ltd コーディング規準遵守状況監視システム
JP2007200125A (ja) * 2006-01-27 2007-08-09 Fujitsu Ltd コーディング規約選択プログラム
JP2020042679A (ja) * 2018-09-12 2020-03-19 株式会社日立製作所 ビジュアルプログラミングツールを用いてフローを作成することを支援する装置および方法
JP2021140372A (ja) 2020-03-04 2021-09-16 三菱電機インフォメーションネットワーク株式会社 構成管理装置、構成管理方法、及び、構成管理プログラム
JP2021157612A (ja) 2020-03-27 2021-10-07 ソフトバンク株式会社 情報処理システム、プログラム、及び情報処理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006018735A (ja) * 2004-07-05 2006-01-19 Hitachi Software Eng Co Ltd コーディング規準遵守状況監視システム
JP2007200125A (ja) * 2006-01-27 2007-08-09 Fujitsu Ltd コーディング規約選択プログラム
JP2020042679A (ja) * 2018-09-12 2020-03-19 株式会社日立製作所 ビジュアルプログラミングツールを用いてフローを作成することを支援する装置および方法
JP2021140372A (ja) 2020-03-04 2021-09-16 三菱電機インフォメーションネットワーク株式会社 構成管理装置、構成管理方法、及び、構成管理プログラム
JP2021157612A (ja) 2020-03-27 2021-10-07 ソフトバンク株式会社 情報処理システム、プログラム、及び情報処理方法

Also Published As

Publication number Publication date
JP2023167974A (ja) 2023-11-24
CN118633076A (zh) 2024-09-10

Similar Documents

Publication Publication Date Title
US20210240734A1 (en) Deployment of container-based computer environments
US10324709B2 (en) Apparatus and method for validating application deployment topology in cloud computing environment
CN108304201B (zh) 对象更新方法、装置及设备
US11385892B1 (en) Optimal software architecture recommendations by an application modernization service
US10901804B2 (en) Apparatus and method to select services for executing a user program based on a code pattern included therein
US11237822B2 (en) Intelligent discovery and application of API changes for application migration
US20120072903A1 (en) Multi-image migration system and method
US10574724B2 (en) Automatic discovery of management nodes and generation of CLI using HA module
JPH0944361A (ja) アプリケーション・プログラムのネットワーク導入のための導入計画オブジェクト
JPH0934723A (ja) ネットワークでのアプリケーション・プログラムの導入のための導入計画オブジェクトのコミット
CN112214980B (zh) 树结构模板的定制和推荐
US11714625B2 (en) Generating applications for versatile platform deployment
CN114064024A (zh) 微应用的开发方法、装置、设备、存储介质及程序产品
CN111930290B (zh) 资源部署方法及装置
WO2016145009A1 (en) Method and system for rapid deployment and execution of customized functionality across multiple distinct platforms
CN105765533A (zh) 用于固件虚拟化的方法和装置
US11704119B2 (en) Migrating infrastructure as code between different cloud providers
CN118228698A (zh) 动态表单生成方法、装置、设备及存储介质
CN111722881B (zh) 一种容器云平台的资源扩展方法、系统及装置
CN113268232B (zh) 一种页面皮肤生成方法、装置和计算机可读存储介质
WO2023218875A1 (ja) システム構築装置
WO2023151397A1 (zh) 应用程序部署方法、装置、设备及介质
US20200081700A1 (en) Intention-based command optimization
CN112948264B (zh) 测试任务的执行方法及装置、系统、存储介质、电子装置
JP2019109874A (ja) 情報処理方法、情報処理装置および情報処理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23803357

Country of ref document: EP

Kind code of ref document: A1