System construction equipment

Abstract

To correct a difference in structure between construction information and a system in a manner matching a user's way of writing in the case of changing the construction of the system without the user changing the construction information.SOLUTION: A system construction device for building a system including infrastructure resources and setting values for the infrastructure resource on a predetermined execution environment, comprises: an input unit (a portal screen display unit) to which a desired requirement is input; a system source code creation unit that creates a first source code defining a system satisfying the desired requirement; a deployment unit that deploys the system on the execution environment; a setting change detection unit that detects, when the system built on the execution environment has been changed, a difference between a second source code defining the changed system and the first source code; and a setting change reflection unit that reflects the detected difference into the first source code. The setting change reflection unit reflects the difference into the first source code on the basis of coding rules applied to the first source code.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a system construction device that constructs a system on a predetermined execution environment. [Background technology]

[0002] In recent years, advances in cloud computing technology have led to the advancement of virtualization of IT (Information Technology) resources. This technological development has led to an increase in attention being paid to automated system construction techniques that utilize virtualization technologies such as virtual servers and containers, and Infrastructure as Code (IaC), which deploys systems based on source code and configuration files.

[0003] Patent Document 1 discloses a technique for automating resource deployment by converting an order sheet containing system requirements into source code. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2021-157612 [Patent Document 2] Japanese Patent Publication No. 2021-140372 Summary of the Invention [Problem to be solved by the invention]

[0005] By using the technology described in Patent Document 1, it becomes possible to automatically build a system according to the system requirements even when the user does not have coding knowledge. However, there is a problem that if the user changes the configuration of the deployed system without changing the source code, the source code of the target system and the configuration of the target system will differ.

[0006] Regarding this issue, Patent Document 2 describes a technique for detecting whether or not a system setting has been changed, and for reflecting the detected setting change in source code.

[0007] In Patent Document 2, the monitoring targets are the devices included in the system to be built, and there is a problem in that changes such as adding new devices to the system cannot be reflected in the source code. Also, since coding rules, which are the way source code is written, often differ from user to user, depending on the method of reflecting the changes in the source code, there is a risk that the coding rules of the modified source code may lack consistency. Therefore, in order to make source code management and user understanding easier, it is necessary to modify the source code so that it is consistent after reflecting the changes.

[0008] The present invention has been made in consideration of the above-mentioned problems, and aims to correct the differences between the source code and the system configuration in a manner that suits the user's writing style, including adding new resources to the system, when the user changes the system configuration without changing the source code. [Means for solving the problem]

[0009] The system construction device of the present invention is a system construction device that constructs a system including infrastructure resources and setting values ​​of the infrastructure resources on a specified execution environment, and includes an input unit that inputs a request for system construction that meets desired requirements, a system source code creation unit that creates first source code that defines a system that meets the desired requirements, a deployment unit that deploys and constructs the system on the execution environment based on the request, a setting change detection unit that, when the system constructed on the execution environment is changed, detects differences between the first source code and second source code that defines the changed system, and a setting change reflection unit that reflects the differences detected by the setting change detection unit in the first source code, and the setting change reflection unit reflects the differences in the first source code based on the coding rules applied to the first source code. [Effects of the Invention]

[0010] According to the system construction device of the present invention, when a user changes the system configuration without changing the system construction information, it is possible to correct the differences between the original system construction information and the changed system configuration while unifying the coding rules. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a hardware configuration diagram of a system construction device 100 according to a first embodiment. [Figure 2] FIG. 1 is a functional block diagram of a system construction device 100 according to a first embodiment. [Figure 3] 3 is a flowchart of a process executed by the system construction device 100 according to the first embodiment. [Figure 4] FIG. 4 is a diagram for explaining a specific example of step S101 in the flowchart of FIG. 3. [Figure 5A] FIG. 4 is a diagram for explaining a specific example of step S102 in the flowchart of FIG. 3. [Figure 5B] FIG. 4 is a diagram for explaining a specific example of step S103 in the flowchart of FIG. 3. [Figure 5C] FIG. 4 is a diagram for explaining a specific example of step S103 in the flowchart of FIG. 3. [Figure 6] FIG. 4 is a diagram showing an example of system source code relating to the deployment processing in steps S104 and S105 of FIG. 3. [Figure 7] 4 is a flowchart illustrating a specific example of steps S106 and S107 in the flowchart of FIG. 3. [Figure 8] 8 is a diagram for explaining 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. [Figure 9] 8 is a flowchart for explaining a specific example of step S209 in the flowchart of FIG. 7. [Figure 10] 10 is a flowchart of a process executed by a system construction device 100 according to a second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Example 1 1 shows an example of the hardware configuration of a system construction device 100 according to this embodiment. As shown in FIG. 1, the system construction device 100 includes hardware such as a calculation device 110, a storage device 120, an input / output I / F (Interface) 130, and a communication I / F (Interface) 140.

[0013] The arithmetic device 110 is, for example, a CPU (Central Processing Unit), and performs various functions described below through processing by the CPU.

[0014] The storage device 120 includes, for example, a random access memory (RAM) and a read only memory (ROM), and stores data used by the arithmetic device 110.

[0015] The input / output I / F 130 is, for example, a display having a touch panel function, and displays the processing results of the arithmetic device 110 and the user interface of a portal screen 210 (described later) on the screen.

[0016] The communication I / F 140 is, for example, a communication chip or a NIC (Network Interface Card), and is used for communication with an execution environment 280 and a user 201, which will be described later.

[0017] When each unit of the system construction device 100 receives data, the data may be received via the input / output I / F 130 or via the communication I / F 140 .

[0018] 2 is a functional block diagram showing an example of the configuration of each functional unit of the system construction device 100. The system construction device 100 is configured to include a portal screen 210, a repository 220, a system source code creation unit 230, a deployment unit 240, a setting change detection unit 250, a setting change reflection unit 260, and a coding rule storage unit 270.

[0019] In this embodiment, a deployment template 221 and source code of a module 222 are registered in advance in a specified repository 220. Examples of the repository 220 include GitHub (https: / / github.com / ) for cloud services and GitLab for OSS. Examples of source code will be described later with reference to FIG. 6.

[0020] Although FIG. 2 shows an example in which multiple templates 221 and modules 222 are managed in one repository 220, the repository 220 may be configured to be separate for each source code corresponding to multiple projects.

[0021] Here, the source code is used to build a specific system 281. For example, not only the configuration of one system 281 corresponding to one template 221, but also modules 222, which are a set of functions that make up part of the system 281, are included in the source code. In this case, a plurality of modules 222 are combined to create system source code for one system 281. Note that the various information to be managed and displayed by the device 100 includes the templates 221 and modules 222, which are source code for building the system 281, and the entities or references of the system source code.

[0022] The system construction device 100 displays a portal screen 210 on a display device (not shown) for a user 201 of the system construction device 100. Examples of the portal screen 210 will be described later with reference to FIGS. 4 and 5. The portal screen 210 is equipped with a CPU (not shown), which presents system candidates from templates 221 and modules 222 in a repository 220 according to the user's selection, as will be described later.

[0023] A user 201 selects a system 281 that they wish to build using a portal screen 210. For example, the user 201 inputs functional and non-functional requirements for a cloud service, and a pre-prepared template 221 is presented. The template 221 is a service that combines public cloud services, private cloud services, etc. that meet each requirement based on past performance.

[0024] Non-functional requirements may include network-related requirements, such as whether or not to use a public IP address, whether or not to use a firewall, whether or not to use an encryption function, etc., but are not limited to these and may include various other network-related requirements.

[0025] The functional requirements may include information indicating which of multiple types of clouds the execution environment 280 to be used is. In addition to the requirements described above, the functional requirements may include various requirements related to the purpose and infrastructure of the system 281.

[0026] Thereafter, the user customizes the presented template 221 by changing each infrastructure resource 283 of the template 221 to another infrastructure resource 283 that can realize the same function, or by adding or deleting infrastructure resources 283. After customization, the user selects the system 281 to be constructed by inputting setting values ​​282 required for each infrastructure resource 283 to be deployed from a parameter sheet or the like.

[0027] When a user 201 selects a system 281 that he or she wishes to build, a system source code creation unit 230 creates system source code using a template 221 and a module 222 of the system 281 selected from a repository 220 .

[0028] After creating the system source code, the deployment unit 240 executes a deployment process on the execution environment 280. The execution environment 280 is an environment for running the system 281. The execution environment 280 is, for example, a public cloud service, a private cloud service, or a cluster of IT resources managed by an orchestration tool such as OpenStack or Kubernetes. The execution environment 280 for running the system 281 selected by the user 201 may be specified by the user 201. In this case, the execution environment 280 may be a different execution environment for each user 201, or may be a single execution environment shared by all users 201.

[0029] As a result of the deployment process performed by the deployment unit 240, a system 281 including infrastructure resources 283, setting values ​​282 for the infrastructure resources 283, etc., is constructed in the execution environment 280 based on the system source code. Here, the infrastructure resources 283 may be one or more depending on the description of the system source code.

[0030] Then, the user 201 makes necessary changes to the constructed system 281 on the execution environment 280, and performs development (changes to the system 281) suited to the user's 201 purpose.

[0031] The setting change detection unit 250 detects whether or not there has been a setting change in the system 281 to be constructed. When there has been a setting change in the system 281, the setting change detection unit 250 detects and extracts the setting change content as a 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.

[0032] The setting change reflecting unit 260 reflects the difference detected by the setting change detecting unit 250 in the system source code created by the system source code creating unit 230, based on the coding rules stored in the coding rule storing unit 270. Here, the coding rules include, for example, that variable name definitions are derived from standard variable names provided by each vendor, and that variables such as IDs are not hard-coded.

[0033] In the following figures and explanations, the execution environment 280 is an IaaS (Infrastructure as a Service) public cloud, a public cloud service, Terraform is used as the deployment process, and the template 221 and module 222 are source code written in HCL (HashiCorp Configuration Language) defined by Terraform. However, this embodiment is not limited to the above configuration. For example, a combination of Kubernetes as the execution environment 280, containers as targets to be built in the execution environment 280, and Helm as the deployment process may be used.

[0034] 3 is a flowchart showing an example of processing executed by the system construction device 100 according to the first embodiment of the present invention. Each step in FIG. 3 will be described below. An overview of each step shown in FIG. 3 will be described below, and the details will be described later.

[0035] The user 101 inputs desired requirements (functional requirements and non-functional requirements) from the portal screen 210 (step S101).

[0036] On the portal screen 210, candidate systems 281 that realize the input functional requirements and non-functional requirements are presented (step 102).

[0037] The user 201 inputs information required to deploy the system 281 presented on the portal screen 210 (step S103). The required information is, for example, the setting values ​​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 address for fees incurred by the adoption and operation of the infrastructure resource 283. The setting values ​​282 may also be specified by the provider of each infrastructure resource 283. Furthermore, the user 201 may change each infrastructure resource 283 to a different infrastructure resource 283.

[0038] The system source code creation unit 230 generates a system source code using information on the infrastructure resources 283 included in the system 281 presented on the portal screen 210 and information required to deploy the system 281 as input (step S104).

[0039] The deployment unit 240 uses the system source code generated by the system source code creation unit 230 to build a system 281 on the execution environment 280 .

[0040] The setting change detection unit 250 monitors and detects whether the user 201 has directly changed the system 281. If a setting change is detected, the setting change detection unit 250 detects and extracts the change content (step S106). The setting change detection unit 250 may use any method to detect the change content. The setting change detection unit 250 may extract only the difference.

[0041] The setting change reflecting unit 260 refers to the coding rules adopted by the system source code creating unit 230, which are stored in the coding rule storage unit 270, and reflects the differences extracted by the setting change detecting unit 250 in the system source code. The processing ends with the above steps.

[0042] Fig. 4 is a diagram illustrating a specific example of a screen displayed on the portal screen 210 in step S101 of Fig. 3. As shown in Fig. 4, a requirement input screen 300 is displayed on the portal screen 210. On the portal screen 210, the user 201 selects on the requirement input screen 300 the purpose that the user wants to achieve with the system 281, the availability and system performance that the user wants for the system 281, and the network conditions under which the system will be operated.

[0043] FIG. 4 shows an example in which options for development, analysis, and collaboration are displayed under the item service type 301 as the purpose to be achieved by system 281. When user 201 changes the purpose to be achieved by system 281, the type of infrastructure resource 283 of system 281 displayed on portal screen 210 changes according to the purpose. As a specific example, when analysis type is selected, system 281 is designed to collect and analyze data. Such automation allows user 201 to reduce the amount of work normally required to design system 281. The options are merely examples, and other options may be used.

[0044] FIG. 4 shows an example of availability, where the availability item 302 displays options for production and PoC (Proof of Concept). Note that PoC refers to verification and demonstration in the preliminary stage of prototype development, with the aim of proving new concepts, theories, principles, and ideas. When user 201 changes the availability, the configuration and setting values ​​282 of infrastructure resources 283 of system 281 displayed on portal screen 210 change according to the selected availability. As a specific example, when production is selected, system 281 is deployed in multiple regions (for example, Tokyo and Osaka) and is designed to continue operating even if a disaster occurs in one region. In other words, redundancy is ensured. The options shown are just an example, and other options may be used.

[0045] 4 shows an example in which options of level 1, level 2, and level 3 are displayed for performance in the performance 303 item. When user 201 changes the performance, setting value 282 of infrastructure resource 283 of system 281 displayed on portal screen 210 changes according to the performance. As a specific example, when level 3 is selected, the model number of infrastructure resource 283 of system 281 is set to the most expensive model number. The options are merely examples, and other options may be used.

[0046] 4 shows an example in which, as a network condition, an item called "external connection 304" displays "with external connection" or "without external connection." When user 201 changes the network condition, infrastructure resources 283 and setting values ​​282 related to the network connection of system 281 displayed on portal screen 210 change according to the network condition. As a specific example, when "with external connection" is selected, a firewall is deployed as a network connection infrastructure resource, assuming an external connection. The options are merely examples, and other options may be used.

[0047] The requirements displayed in Fig. 4 are just an example, and other requirements may be used. Furthermore, in Fig. 4, instead of the objective to be achieved by the system 281, a past system 281 may be displayed as an option. In this case, the requirements when the past system 281 was deployed are input.

[0048] 5A is a diagram illustrating a specific example of the processing performed in step S102 in FIG. 3. The system construction device 100 presents, on the portal screen 210, a proposed system 281 that realizes the functional requirements and non-functional requirements input in step S101. The user 201 inputs information required 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 a different infrastructure resource 283.

[0049] Fig. 5B shows an example of a method for inputting information required to deploy the system 281 presented on the portal screen 210 in step S103 in Fig. 3. When "Parameter Input" is selected in Fig. 5A, a screen 301 shown in Fig. 5B is displayed. In this embodiment, an example is shown in which an Excel sheet containing various parameters required to deploy the infrastructure resource selected in Fig. 5A is uploaded as a parameter sheet, and setting values ​​282 required for each infrastructure resource 283 are input.

[0050] Fig. 5C shows an example of changing each service to a different service in step S103 in Fig. 3. When "Customize" is selected on screen 300 in Fig. 5A, screen 320 in Fig. 5C is displayed. In this embodiment, an example of changing the resource that stores data is shown. When the user selects a different resource, the resource is changed to the resource selected by the user.

[0051] Fig. 6 is a diagram showing an example of system source code related to the deployment process in steps S104 and S105 in Fig. 3. In this embodiment, a case where Terraform is used for the deployment process will be described. Terraform is an open-source automated infrastructure construction tool developed by HashiCorp.

[0052] The template 221 generally includes source code such as main.Tf (400) that defines what infrastructure resources 283 to deploy, a variable file in a format such as variables.Tf (410) that defines the variables to be assigned to each infrastructure resource 283 and their default values, and a variable input file in a format such as auto.input.tfvars (420) that defines the setting values ​​282 of the variables to be assigned to each infrastructure resource 283.

[0053] For example, statement 401 ("resource "aws_s3_bucket" "s3_bucket") means to deploy "aws_s3_bucket" as a resource. Also, statement 401 ("bucket = "${var.foo}") means to read statement 411 ("variable "foo"{}") defined in variables.Tf(410).

[0054] If no value is specified for the variable key "foo" during deployment, the default value "foo:1" is used. Note that if a different value, for example, the value "foo = "dev-var"" is specified for the variable key "foo" in auto.input.tfvars (420) during deployment, the description 411 will be generated as "foo:"dev-var"".

[0055] Additionally, the template file may contain programmatic elements, such as if statements. Terraform defines available programmatic elements, and the number of resources to be built can be controlled using a variable called count. If you specify the value "S3_count = 1" in auto.input.tfvars(420), one "resource "aws_s3_bucket" "s3_bucket"" will be generated. This allows you to customize resources by controlling the count based on the information entered in Figure 5B.

[0056] Based on the system source code generated in step S104, the deployment unit 240 deploys the infrastructure resource 283 on the execution environment 280 using a deployment tool.

[0057] Fig. 7 is a flowchart showing an example of a specific processing procedure in steps S106 and S107 in Fig. 3. Each step in Fig. 7 will be described below.

[0058] The setting change detection unit 250 detects that the user 201 has directly changed the system 281 on the execution environment 280 (step S201). As a specific example, when the system 281 is constructed in step S105 of Fig. 3, a reference source code may be obtained using a function for exporting the system 281 provided by the cloud vendor as the source code of each cloud vendor, and then the difference between the source code obtained by the sequential export function and the reference source code may be obtained.

[0059] The method for obtaining the differences is preferably to export and obtain them from the environment in which each system 281 is built, as described above. This is because each cloud vendor provides standard metadata indicating that the system 281 is the same, which also makes it possible to detect the addition of new devices to the system 281. Alternatively, when building the system 281 in step S105 of FIG. 2, metadata indicating that the systems are the same can be added.

[0060] Next, the setting change detection unit 250 checks whether a setting change has been detected (step S202). If a setting change has been detected, the process proceeds to step S203, and if a setting change has not been detected, the process ends.

[0061] If a setting change has occurred ("Yes" in step S202), the setting change detection unit 250 checks the type of setting change (step S203). There are two types of setting changes: a setting change related to the infrastructure resource 283 and a setting change related to the setting value 282 of the infrastructure resource 283. A setting change related to the infrastructure resource 283 may involve adding or deleting a new infrastructure resource 283, while a setting change related to the setting value 282 of the infrastructure resource 283 involves changing the setting value 282 of the infrastructure resource 283. If a setting change related to the infrastructure resource 283 is detected, the process proceeds to step S207; if a setting change related to the setting value 282 of the infrastructure resource 283 is detected, the process proceeds to step S204. The setting value 282 here refers to the parameter written in the parameter sheet shown in FIG. 5B.

[0062] If the setting change is a change to the setting value 282, the setting change reflecting unit 260 checks whether the setting change is related to an 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. As an example, assume that a VM (Virtual Machine) has been set as the infrastructure resource 283. Note that a VM is a virtual environment that is created on a physical hardware system (located off-premises or on-premises), has its own CPU, memory, network interface, and storage, and functions as a virtual computer system.

[0063] Suppose that the size of the VM is set to small in the part defining the VM as system source code. If the size of the VM is then manually changed to medium by the user 201, the size of the VM is determined to be the existing setting value 282 because it is a setting value 282 already defined as the system source code. Also, if a setting value not defined as the system source code, for example, a VM tag, is added, it is determined to be not the existing setting value 282 because it is a setting value 282 not defined as the system source code. If it is a setting change related to the existing setting value 282, the process proceeds to step S205; if not, the process proceeds to step S206.

[0064] 8 is a diagram illustrating a specific example of a method for determining an existing setting value 282 referenced in step S202. The system construction device 100 has information on which infrastructure resource 283 defines which variable as system source code. For example, if the infrastructure resource 283 is a VM, it is known that a certain variable is defined on lines 1-9 of the path ". / tempA," in the system source code, and is called on lines 10-20 of the path ". / module" in the system source code. Using this information, the name of the infrastructure resource 283 detected as a difference and its variable name are used as input to search for and determine whether they exist as existing setting values ​​282.

[0065] When a change to an existing setting value 282 is detected, the setting change reflecting unit 260 uses information about which infrastructure resource 283 defines which variable as system source code to change the current value of the corresponding setting value 282 to the difference setting value. This makes it possible to correct the setting change based on the original coding rules.

[0066] If no setting change of an existing parameter is detected, the setting change reflecting unit 260 uses information about which infrastructure resource 283 defines which variable in the system source code to add the corresponding setting value 282 to the system source code as a new setting value (step S206). Then, the process proceeds to step S205, where the setting value is set as the current setting value 282. This makes it possible to correct the setting change based on the original coding rules.

[0067] If the setting change is a change to the infrastructure resource 283, the setting change reflecting unit 260 checks whether the setting change is related to an existing infrastructure resource 283 (step S207). The existing infrastructure resource 283 refers to an infrastructure resource 283 that has already been defined in the system source code. For example, if the infrastructure resource 283 of a VM is defined as the system source code and the user 201 manually adds another VM, it 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 not to be an existing infrastructure resource 283. Furthermore, even if the added VM is not included in the current system source code, it is determined to be an existing infrastructure resource 283 if the source code of the infrastructure resource 283 of the VM is stored in the repository 220. If the setting change is related to an existing resource, the process proceeds to step S208; otherwise, the process proceeds to step S209.

[0068] If a setting change of an existing resource is detected ("Yes" in step S207), the setting change reflecting unit 260 adds the existing infrastructure resource 283 to the system source code (step S208). As a specific example, the source code program of each infrastructure resource 283 registered in advance in the repository 220 is searched for using the name of the added infrastructure resource 283 obtained as the difference. Then, the source code program of the identified infrastructure resource 283 is added to the system source code. Note that although the addition of an existing resource has been described here, the setting change may also be the deletion of a resource, in which case the part defining the relevant resource in the source code program can be deleted.

[0069] As described above, the source code program of the system source code includes a section that defines the infrastructure resources 283 to be used and a section that defines and sets the setting values ​​282 of the infrastructure resources 283. In other words, when a change is made to the system source code, a section that defines the infrastructure resources 283 of the registered source code program is added to the section in the system source code that defines the infrastructure resources 283 to be used. Also, a section that defines the variables to be used by the registered source code program is added to the section in the system source code that defines the variables to be used by the infrastructure resources 283. And a section that sets the setting values ​​282 to be used by the registered source code program is added to the section in the system source code that sets the setting values ​​282 to be used by the infrastructure resources 283.

[0070] Here, when setting the setting value 282 to be used, it is necessary to associate the variable names in the difference information with the variable names in the source code program. Several methods of association have been proposed in the past. For example, there is a method in which the variable names output in the difference information are associated with the variable names in the source code program manually in advance, and a method in which the similarity between the variable names output in the difference information and the variable names in the source code program is calculated and associated. This makes it possible to correct setting changes based on the original coding rules.

[0071] If no change in the settings of an existing resource is detected, that is, if the addition of a new infrastructure resource 283 is detected, the setting change reflecting unit 260 acquires the source code program of the new infrastructure resource 283, modifies it based on the coding rules, and adds it (step S209). This processing will be described in detail with reference to Fig. 9. Fig. 9 is a flowchart showing an example of a specific processing procedure in step S209. Each step in Fig. 9 will be described below.

[0072] The configuration change reflecting unit 260 searches for the source code program of the infrastructure resource 283 based on the name of the infrastructure resource 283 included in the difference information (step S301). As a specific example, Terraform provides an API (Application Programming Interface) for searches, and search results can be obtained by adding search parameters to a specific URL. As an example, a resource named "network" can be searched for by executing a GET method for "https: / / registry.terraform.io / v1 / modules / search?q=network." Alternatively, a shared repository managed by the organization to which the user 201 belongs may be set. Furthermore, an example of a source code program may be obtained by web scraping from a page describing the infrastructure resource listed on the official page of the infrastructure resource 283.

[0073] The setting change reflecting unit 260 examines the source code program of the acquired infrastructure resource 283 (step S302). As a specific example, when there are multiple source code program candidates for the resource acquired in step S301, there is a possibility that some of the candidates do not include the infrastructure resource. Therefore, the multiple candidate source code programs are analyzed to confirm whether they contain characters for the infrastructure resource. Then, source code programs that do not contain those characters are removed from the candidates. Alternatively, the candidates may be examined using metadata held by the source code program. As a specific example, a source code program with a large number of stars, which indicates its popularity, may be selected. In this way, one source code program is selected from the multiple acquired source code programs.

[0074] Then, the setting change reflecting unit 260 checks whether or not there are any candidates based on the examination performed in step S302 (step S303). If the number of candidates is 1, the process proceeds to step S304, and if the number of candidates is 0, the process ends.

[0075] If the number of candidates is one ("Yes" in step S303), the setting change reflecting unit 260 performs a detailed examination in step S302 and modifies one selected source code program (step S304). Here, modifying the source code program refers to rewriting the acquired source code program based on the coding rules specified by the user 201. A specific example of a coding rule is a method of converting variable names in the source code program in accordance with naming rules specified by the user 201. This is because, although setting item names are defined for resources in the construction tool, the variable names corresponding to those setting item names are named by the developer, and the naming rules are not necessarily uniform.

[0076] A code analysis of the source code program is performed for the relevant variable name. Several code analysis methods have been proposed in the past. For example, the source code program is lexically analyzed based on the grammar of the programming language and converted into a token string. The converted token string is then converted into a tree structure. Based on the resulting tree structure, the variable name is confirmed and converted in accordance with the naming rules. Specific examples include adding the resource name to the front of the setting item name and connecting it with an underscore, or using all uppercase letters.

[0077] Another example of a coding rule is to match the directory structure to the original source code program. For example, one method is to extract each resource into a separate source code program file and call each of them as a module. In this case, the directory structure differs between the method of calling the directory structure as a module and the method of realizing the directory structure in a single source code program. In the method of calling as a module, the acquired source code program is placed in a module directory, and the part that calls the acquired source code program is added to the original source code program.

[0078] The above has explained how the setting change reflecting unit 260 automatically adds a source code program, but the method is not necessarily limited to automatic addition. Alternatively, the user 201 may be notified, prompted to create a source code program for a new resource, and the created source code program may be acquired.

[0079] The system construction device 100 according to this embodiment detects setting changes in the system 281 and reflects the setting changes in the system source code based on coding rules. By correcting the setting changes based on coding rules, the reflection of the setting changes in the system 281 can be managed as a source code program as envisioned by the user 201. Therefore, the system construction device 100 can reduce the number of steps required to reflect setting changes, since it does not require extra work to automatically reflect manual setting changes made by the user 201 in the construction information, and it is not necessary to correct the automatic setting changes based on the system's own coding rules.

[0080] Furthermore, in the system construction device 100 according to this embodiment, the user 201 inputs functional requirements and non-functional requirements of the system 281 on the portal screen 210, and the system 281 that meets the requirements is presented, and the user 201 customizes it, automatically constructing the system 281. This allows the user 201 to create a system 281 that meets the requirements even if he or she has no knowledge of system 281 design or automatic construction technology for the system 281.

[0081] <Example 2> Next, a system construction device according to a second embodiment of the present invention will be described. In the first embodiment, an example was described in which a user 201 inputs functional requirements and non-functional requirements of a system 281 on a portal screen 210, a system 281 that satisfies the requirements is presented, and the user 201 customizes it. In the second embodiment, a requirements 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. As a result, even if the user 201 creates the system source code himself, for example, because he is familiar with automatic construction technology for the system 281, the system 281 can be constructed and managed based on the system source code.

[0082] 10 is a flowchart illustrating the procedure for the system construction device 100 to construct and manage a system in embodiment 2. Each step in FIG. 10 will be described below.

[0083] The system construction device 100 accepts system source code from the user 201 (step S401). As a specific example of a method of accepting the system source code, a screen similar to that shown in FIG. 5B may be displayed on the portal screen 210 so that the system source code can be uploaded. Alternatively, a text editor capable of writing the system source code may be displayed on the portal screen 210 so that the user 201 can write the system source code directly.

[0084] The deployment unit 240 performs deployment processing based on the system source code received in step S401 (step S402). This processing is the same as step S104 in FIG. 3. In this embodiment, the deployment processing may be performed by a user. In this case, an example of using Terrafrom is to build a system using a Terrafrom build command in the user's environment.

[0085] Steps S403 and S404 are the same as steps S106 and S107 in Fig. 3. In this embodiment, when the user 201 performs the deployment process, the user inputs information about the system 281 for which setting changes are to be detected and about construction information based on the system source code, and the setting changes are detected and reflected.

[0086] As described above, in the second embodiment of the present invention, a system is constructed based on the system source code written by the user 201. As a result, even if the user 201 is familiar with automatic system construction technology and wants to create the system source code himself, the system can be constructed and managed based on the system source code.

[0087] According to the embodiment of the present invention described above, the following advantageous effects are achieved. (1) A system construction device according to the present invention is a system construction device that constructs a system including infrastructure resources and configuration values ​​of the infrastructure resources on a specified execution environment, and includes an input unit that inputs a request for system construction that satisfies desired requirements, a system source code creation unit that creates first source code that defines a system that satisfies the desired requirements, a deployment unit that deploys and constructs the system on the execution environment based on the request, a setting change detection unit that, when the system constructed on the execution environment is changed, detects differences between the first source code and second source code that defines the changed system, and a setting change reflection unit that reflects the differences detected by the setting change detection unit in the first source code, and the setting change reflection unit reflects the differences in the first source code based on the coding rules applied to the first source code.

[0088] With the above configuration, when a user changes the system configuration without changing the system's construction information, it is possible to correct the difference between the original system construction information and the changed system construction information while unifying the coding rules.

[0089] (2) If the difference includes a change in a setting value, the setting change reflecting unit corrects the setting value of the second source code based on the coding rules, thereby correcting the first source code. Also, if the difference includes an addition of an infrastructure resource, the setting change reflecting unit acquires the source code of the added infrastructure resource, corrects the source code based on the coding rules, thereby correcting the first source code. This allows the corrections to be appropriately reflected regardless of the type of change made to the system source code.

[0090] (3) The configuration change detection unit determines whether the added infrastructure resource is a new infrastructure resource based on the metadata that identifies the system. This makes it possible to appropriately modify the source code even when a new resource that was not anticipated in the prior art has been added.

[0091] (4) The input unit includes a portal screen display unit, and the requirements include functional and non-functional requirements. The portal screen display unit presents the user with candidate systems that satisfy the input functional or non-functional requirements. This allows the user to select candidates by distinguishing between functional and non-functional requirements, improving user convenience. Furthermore, the automatic selection and presentation of candidate systems provides the user with the insight to add or modify desired requirements.

[0092] (5) The deployment unit creates the construction information for building the system selected by the user based on the user's selection from the presented system candidates, and builds the system in the execution environment. This enables rapid system construction by utilizing the information stored in the repository of the system construction device.

[0093] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations. [Explanation of symbols]

[0094] 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: Setting change detection section, 260: Setting change reflection section, 270: Coding rule storage section, 280: Execution environment, 281: System, 282: Setting value, 283: Infrastructure resource

Claims

1. A system construction device that constructs a system including infrastructure resources and setting values ​​of the infrastructure resources on a predetermined execution environment, an input unit for inputting a request for system construction that satisfies desired requirements; a system source code creation unit that creates a first source code that defines a system that satisfies the desired requirements; a deployment unit that deploys and builds the system on the execution environment based on the request; a setting change detection unit that detects, when the system constructed on the execution environment is changed, a difference between a second source code that defines the changed system and the first source code; a setting change reflecting unit that reflects the difference detected by the setting change detecting unit in the first source code, the setting change reflecting unit reflects the difference in the first source code based on a coding rule applied to the first source code; A system construction device characterized by:

2. 2. The system construction device according to claim 1, If the difference includes a change in the setting value, the setting change reflecting unit corrects the setting value of the second source code based on the coding rule, thereby correcting the first source code. A system construction device characterized by:

3. 2. The system construction device according to claim 1, When the difference includes the addition of the infrastructure resource, the setting change reflecting unit acquires source code of the added infrastructure resource, modifies the source code based on the coding rule, and modifies the first source code. A system construction device characterized by:

4. 4. The system construction device according to claim 3, The setting change detection unit, based on metadata that identifies the system, Determining whether the added infrastructure resource is a new infrastructure resource. A system construction device characterized by:

5. 2. The system construction device according to claim 1, the input unit includes a portal screen display unit, and the requirements include functional requirements and non-functional requirements; The portal screen display unit presents to the user candidate systems that satisfy the input functional requirements or non-functional requirements. A system construction device characterized by:

6. 6. The system construction device according to claim 5, The deployment unit creates construction information for constructing the system selected by the user based on the user's selection from the presented system candidates, and constructs the system on the execution environment. A system construction device characterized by:

Images