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株式会社
Publication of WO2023218875A1 publication Critical patent/WO2023218875A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software 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

システム構築装置
　本発明は、所定の実行環境上にシステムを構築するシステム構築装置に関する。
　近年、クラウドコンピューティング技術の発展に伴い、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ）リソースの仮想化が進んでいる。こうした技術の発達により、仮想サーバやコンテナなどの仮想化技術とソースコードや設定ファイルなどに基づいてシステムをデプロイするＩａＣ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ａｓ　Ｃｏｄｅ）とを活用したシステムの自動構築技術が注目されている。
　特許文献１の技術によれば、システム要件が記載されたオーダーシートに基づいて、オーダーシートをソースコードに変換しリソースのデプロイを自動化する技術が開示されている。
特開第２０２１－１５７６１２号公報 特開第２０２１－１４０３７２号公報
　特許文献１に記載の技術を用いることで、ユーザがコーディング知識を持ち合わせていない場合においても、システム要件に合わせてシステムを自動構築することが可能となる。一方で、ユーザがソースコードを変更せずに、デプロイされたシステムの構成を変更した場合に、対象システムのソースコードと、対象システムの構成が異なるという課題がある。
　この課題に関して、特許文献２は、システムの設定変更の有無を検出し、検出された設定変更をソースコードに反映する技術を記載している。
　特許文献２においては、構築対象システムが備える機器を監視対象としており、システムに新規機器を追加するような変更に対してソースコードに反映することができないという課題がある。また、ソースコードの書き方であるコーディングルールはユーザによって異なることが多いため、ソースコードへの反映方法によっては、修正されたソースコードのコーディングルールが一貫性に欠けてしまうおそれがある。したがって、ソースコードの管理やユーザの理解を容易にする目的で、反映したのちにソースコードが一貫性を有するように修正する必要がある。
　本発明は、以上のような課題に鑑みてなされたものであり、ユーザがソースコードを変更せず、システムの構成を変更した場合に、システムへの新規リソース追加も含めて、ユーザの書き方に合わせた形で、ソースコードとシステムの構成の差異を修正することを目的とする。
　本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。
　本発明に係るシステム構築装置によれば、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構成との差異を修正することができる。
実施例１に係るシステム構築装置１００のハードウェア構成図。 実施例１に係るシステム構築装置１００の機能ブロック構成図。 実施例１に係るシステム構築装置１００が実行する処理のフローチャート。 図３のフローチャート中のステップＳ１０１の具体例を説明する図。 図３のフローチャート中のステップＳ１０２の具体例を説明する図。 図３のフローチャート中のステップＳ１０３の具体例を説明する図。 図３のフローチャート中のステップＳ１０３の具体例を説明する図。 図３のステップＳ１０４とステップＳ１０５のデプロイ処理に係るシステムソースコードの一例を示す図。 図３のフローチャート中のステップＳ１０６とＳ１０７の具体例を説明するフローチャート。 図７のフローチャート中のステップＳ２０２において参照される、既存の設定値２８２の判断方法について具体例を説明する図。 図７のフローチャート中のステップＳ２０９の具体例を説明するフローチャート。 実施例２に係るシステム構築装置１００が実行する処理のフローチャート。
＜実施例１＞
　図１は、本実施例に係るシステム構築装置１００のハードウェア構成の一例を示している。システム構築装置１００は、図１に示すように、演算装置１１０と、記憶装置１２０と、入出力Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１３０と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１４０等のハードウェアを備える。
　演算装置１１０は例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）であり、ＣＰＵによる処理によって後述する種々の機能を発揮する。
　記憶装置１２０は、例えばＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）及びＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）を含み、演算装置１１０が用いるデータを格納する。
　入出力Ｉ／Ｆ１３０は、例えばタッチパネル機能を有するディスプレイであり、演算装置１１０による処理結果や後述するポータル画面２１０のユーザインターフェースを画面上に表示する。
　通信Ｉ／Ｆ１４０は、例えば通信チップ又はＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）であり、後述する実行環境２８０や利用者２０１との間の通信に用いる。
　システム構築装置１００の各部がデータを受け付ける場合、入出力Ｉ／Ｆ１３０を介してデータを受け付けても良く、また、通信Ｉ／Ｆ１４０を介してデータを受け付けても良い。
　図２は、システム構築装置１００が有する各機能部の構成の一例を示す機能ブロック図である。システム構築装置１００は、ポータル画面２１０と、リポジトリ２２０と、システムソースコード作成部２３０と、デプロイ部２４０と、設定変更検出部２５０と、設定変更反映部２６０と、コーディングルール保存部２７０と、を含んで構成される。
　本実施例では、あらかじめデプロイ用のテンプレート２２１やモジュール２２２のソースコードが指定されたリポジトリ２２０に登録されている。リポジトリ２２０の例としては、クラウドサービスでは、ＧｉｔＨｕｂ（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／）、ＯＳＳでは、ＧｉｔＬａｂといったものである。ソースコードの例については、図６を用いて後述する。
　なお、図２では、複数のテンプレート２２１とモジュール２２２を、１つのリポジトリ２２０で管理する例を示しているが、複数のプロジェクトのそれぞれに対応するソースコードごとにリポジトリ２２０が分かれている構成であってもよい。
　ここで、ソースコードとは、特定のシステム２８１を構築するために活用されるものである。例えば、１つのシステム２８１が１つのテンプレート２２１に対応する構成だけでなく、システム２８１の一部を構成するひとまとまりの機能であるモジュール２２２もソースコードに含まれる。その際は、複数のモジュール２２２を組み合わせて１つのシステム２８１のシステムソースコードを作成する。なお、本装置１００で管理したり表示したりするための各種の情報には、システム２８１を構築するためのソースコードであるテンプレート２２１やモジュール２２２、システムソースコードの実体または参照等が含まれる。
　システム構築装置１００は、システム構築装置１００の利用者２０１に対してポータル画面２１０を不図示の表示装置上に表示する。ポータル画面２１０の例については、図４と図５を用いて後述する。また。ポータル画面２１０には不図示のＣＰＵが搭載されており、リポジトリ２２０内のテンプレート２２１及びモジュール２２２から、後述するように利用者の選択に従ってシステムの候補を提示する。
　利用者２０１は、ポータル画面２１０を用いて今回、構築したいシステム２８１を選択する。例えば、利用者２０１がクラウドサービスの機能要件及び非機能要件を入力し、事前に用意されたテンプレート２２１を提示する。テンプレート２２１は、過去の実績に基づき各要件を満たすパブリッククラウドサービス、プライベートクラウドサービスなどが組み合わされたサービスである。
　非機能要件は、ネットワークに関する要件を含んでよい。ネットワークに関する要件として、パブリックＩＰの利用の有無、ファイアウォール利用の有無、暗号化機能の利用の有無、等が例として挙げられるが、これらに限らず、ネットワークに関する様々な要件を含んでよい。
　機能要件は、利用する実行環境２８０が、複数種類のクラウドのうちのいずれかであるかを示す情報を含んでもよい。機能要件は、上述した要件の他、システム２８１の目的、インフラに関連する様々な要件を含んでよい。
　その後、提示されたテンプレート２２１の各インフラストラクチャーリソース２８３を同様の機能を実現可能な別インフラストラクチャーリソース２８３に変更したり、インフラストラクチャーリソース２８３の追加や削除を行い、カスタマイズする。そして、カスタマイズ後に、各インフラストラクチャーリソース２８３がデプロイするために必要とする設定値２８２をパラメタシートなどから入力することで、構築したいシステム２８１が選択される。
　利用者２０１が構築したいシステム２８１を選択すると、システムソースコード作成部２３０が、リポジトリ２２０から選択されたシステム２８１のテンプレート２２１やモジュール２２２を用いてシステムソースコードを作成する。
　システムソースコードを作成後、デプロイ部２４０は実行環境２８０上にデプロイ処理を実施する。実行環境２８０は、システム２８１を動作させるための環境である。実行環境２８０は、例えば、パブリッククラウドサービス、プライベートクラウドサービス、ＯｐｅｎＳｔａｃｋ、Ｋｕｂｅｒｎｅｔｅｓ等のオーケストレーションツールで管理されるＩＴリソースのクラスタ等である。また、利用者２０１が選択したシステム２８１を動作させる実行環境２８０については、利用者２０１が指定する形式であってもよい。このとき実行環境２８０は、利用者２０１毎に異なる実行環境であってもよいし、１つの実行環境を共用する形であってもよい。
　デプロイ部２４０によるデプロイ処理が行われた結果、実行環境２８０には、システムソースコードに基づいてインフラストラクチャーリソース２８３、インフラストラクチャーリソース２８３の設定値２８２等を含む、システム２８１が構築される。ここで、インフラストラクチャーリソース２８３は、システムソースコードの記述に応じて、１または複数であってよい。
　そして、利用者２０１は、実行環境２８０上で、構築されたシステム２８１に必要な変更を加え、利用者２０１の用途にあった開発（システム２８１に対する変更）を行う。
　設定変更検出部２５０は、構築対象のシステム２８１の設定変更の有無を検出する。設定変更検出部２５０は、システム２８１の設定変更が有る場合に、システムソースコード作成部２３０が作成したシステムソースコードによって定義されるシステム２８１の構成と実行環境上における現在のシステム２８１との差分として設定変更内容を検出・抽出する。
　設定変更反映部２６０は、コーディングルール保存部２７０に保存されたコーディングルールに基づいて、設定変更検出部２５０が検出した差分をシステムソースコード作成部２３０が作成したシステムソースコードに反映させる。ここで、コーディングルールは例えば、変数名の定義として各ベンダーが提示する標準的な変数名から派生したものであることや、ＩＤなどの変数がハードコーディングされていないことなどが挙げられる。
　なお、以降の図および説明では、実行環境２８０としては、パブリッククラウドサービスのＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）パブリッククラウド、デプロイ処理としては、Ｔｅｒｒａｆｒｏｍ、テンプレート２２１やモジュール２２２としては、Ｔｅｒｒａｆｏｒｍが規定するＨＣＬ（ＨａｓｈｉＣｏｒｐ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｌａｎｇｕａｇｅ）で記述されたソースコードを例に挙げて説明する。しかしながら、本実施例は、上述の構成に限られるものではない。例えば、実行環境２８０としては、Ｋｕｂｅｒｎｅｔｅｓ、実行環境２８０に構築する対象としては、コンテナ、デプロイ処理としては、Ｈｅｌｍといった組合せを採用してもよい。
　図３は、本発明の実施例１に係るシステム構築装置１００が実行する処理の一例を示すフローチャートである。以下図３の各ステップについて説明する。また、以下では図３に示す各ステップの概要を説明し、その詳細については後述する。
　利用者１０１は、ポータル画面２１０から所望の要件（機能要件及び非機能要件）を入力する（ステップＳ１０１）。
　ポータル画面２１０上には、入力された機能要件および非機能要件を実現するシステム２８１の候補が提示される（ステップ１０２）。
　利用者２０１は、ポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する（ステップＳ１０３）。必要な情報は、例えば、システム２８１に含まれる各インフラストラクチャーリソース２８３の設定値２８２である。設定値２８２としては例えば、各インフラストラクチャーリソース２８３の名前やインフラストラクチャーリソース２８３の採用・運用により発生する料金の請求先などが含まれる。また各インフラストラクチャーリソース２８３の提供者により規定されている設定値２８２であってもよい。さらに、利用者２０１は各インフラストラクチャーリソース２８３を別のインフラストラクチャーリソース２８３へ変更してもよい。
　システムソースコード作成部２３０は、ポータル画面２１０に提示されたシステム２８１に含まれるインフラストラクチャーリソース２８３の情報とそのシステム２８１をデプロイするために必要な情報を入力として、システムソースコードを生成する（ステップＳ１０４）。
　デプロイ部２４０は、システムソースコード作成部２３０が生成したシステムソースコードを用いて、システム２８１を実行環境２８０上に構築する。
　設定変更検出部２５０は、利用者２０１がシステム２８１を直接変更したか否かを監視・検出する。そして、設定変更が検出された場合、設定変更検出部２５０は、変更内容を検出・抽出する（ステップＳ１０６）。設定変更検出部２５０は、どのような手法により変更された内容を検出しても良い。設定変更検出部２５０は、差分のみを抽出しても良い。
　設定変更反映部２６０は、コーディングルール保存部２７０に保存された、システムソースコード作成部２３０が採用したコーディングルールを参照し、設定変更検出部２５０が抽出した差分をシステムソースコードに反映させる。以上の工程により処理は終了する。
　図４は、図３のステップＳ１０１においてポータル画面２１０上に表示される画面の具体例を説明する図である。図４に示すように、ポータル画面２１０上には要件入力画面３００が表示される。利用者２０１はポータル画面２１０上で、システム２８１で実現したい目的や、システム２８１に求める可用性とシステムの性能、システムを運用するネットワーク条件を要件入力画面３００上で選択する。
　図４においては、システム２８１によって実現したい目的として、サービス類型３０１という項目で開発型や分析型、連携型の選択肢を表示する例を示した。利用者２０１がシステム２８１で実現したい目的を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の種類がその目的にしたがって変化する。具体例としては、分析型が選択された場合に、システム２８１がデータを収集し分析を行うように設計される。このような自動化により利用者２０１は、通常システム２８１の設計でかかる工数を低減することができる。選択肢は一例であり、その他の選択肢であってもよい。
　図４においては、可用性として、可用性３０２という項目で本番向けやＰｏＣ（Ｐｒｏｏｆ　ｏｆ　Ｃｏｎｃｅｐｔ）向けの選択肢を表示する例を示した。なお、ＰｏＣとは、新しい概念や理論、原理、アイディアの実証を目的とした、試作開発の前段階における検証やデモンストレーションのことをいう。利用者２０１が可用性を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の構成や設定値２８２が選択された可用性にしたがって変化する。具体例としては、本番向けが選択された場合に、システム２８１が複数のリージョン（例えば東京と大阪）に分散してデプロイされ、あるリージョンで災害が起きた際にもシステム２８１が動作し続けるように設計される。すなわち冗長性が担保される。選択肢は１例であり、その他の選択肢であってもよい。
　図４においては、性能として、性能３０３の項目でレベル１やレベル２、レベル３の選択肢を表示する例を示した。利用者２０１が性能を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の設定値２８２がその性能にしたがって変化する。具体例としては、レベル３が選択された場合に、システム２８１のインフラストラクチャーリソース２８３の型番が最も高価な型番に設定される。選択肢は一例であり、その他の選択肢であってもよい。
　図４においては、ネットワークの条件として、外部接続３０４という項目で外部接続ありや外部接続なしを表示する例を示した。利用者２０１がネットワークの条件を変更すると、ポータル画面２１０上で表示されるシステム２８１のネットワーク接続に関するインフラストラクチャーリソース２８３と設定値２８２がそのネットワークの条件にしたがって変化する。具体例としては、外部接続ありが選択された場合に、外部接続を前提として、ネットワーク接続インフラストラクチャーリソースとしてファイアウォールがデプロイされる。選択肢は一例であり、その他の選択肢であってもよい。
　図４に表示される要件は、一例であり、その他の要件であってもよい。さらには、図４においては、システム２８１で実現したい目的の代わりに、過去のシステム２８１を選択肢として表示をしてもよい。その場合、過去のシステム２８１をデプロイした際の要件が入力される。
　図５Ａは、図３におけるステップＳ１０２において行われる処理の具体例を説明する図である。システム構築装置１００は、ステップＳ１０１で入力された機能要件および非機能要件を実現するシステム２８１案をポータル画面２１０上に提示する。利用者２０１は、ポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する（図５Ｂ参照）。さらには、利用者２０１は各インフラストラクチャーリソース２８３を別のインフラストラクチャーリソース２８３へ変更してもよい。
　図５Ｂは、図３におけるステップＳ１０３においてポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する方法の一例である。図５Ａにおいて「パラメタ入力」を選択すると、図５Ｂに示す画面３０１が表示される。そして、本実施例においては、図５Ａで選択されているインフラストラクチャーリソースをデプロイするために必要な各種パラメタが記載されたエクセルシートをパラメタシートとしてアップロードし、各インフラストラクチャーリソース２８３が必要とする設定値２８２を入力する例を示した。
　図５Ｃは、図３におけるステップＳ１０３において各サービスを別のサービスへ変更する際の例である。図５Ａの画面３００上で「カスタマイズ」を選択すると、図５Ｃの画面３２０が表示される。本実施例においては、データを格納するリソースを変更する例を示した。ユーザが別のリソースを選択すると、ユーザが選択したリソースに変更される。
　図６は、図３のステップＳ１０４とステップＳ１０５のデプロイ処理に係るシステムソースコードの一例を示す図である。本実施例においては、デプロイ処理としては、Ｔｅｒｒａｆｒｏｍを用いる場合について説明する。Ｔｅｒｒａｆｏｒｍとは、ＨａｓｈｉＣｏｒｐ社により開発されているオープンソースのインフラ自動構築ツールである。
　テンプレート２２１は、一般に、どのようなインフラストラクチャーリソース２８３をデプロイするのかを定義するｍａｉｎ．Ｔｆ（４００）のようなソースコードと、各インフラストラクチャーリソース２８３に与える変数および当該変数のデフォルト値が定義されたｖａｒｉａｂｌｅｓ．Ｔｆ（４１０）のような形式である変数ファイルと、各インフラストラクチャーリソース２８３に与える変数の設定値２８２が定義されたａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）のような形式である変数入力ファイルとを含む。
　例えば、記述４０１（「ｒｅｓｏｕｒｃｅ　“ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ”“ｓ３＿ｂｕｃｋｅｔ”」）は、リソースとして「ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ」をデプロイすることを意味している。また、記述４０１（「ｂｕｃｋｅｔ　＝　“＄｛ｖａｒ．ｆｏｏ｝”」）は、ｖａｒｉａｂｌｅｓ．Ｔｆ（４１０）に定義された記述４１１（「ｖａｒｉａｂｌｅ　“ｆｏｏ”｛｝」）を読み込むことを意味している。
　そして、デプロイ処理時に、変数ｋｅｙ「ｆｏｏ」の変数に値を指定しなければ、デフォルト値である「ｆｏｏ：１」が用いられる。なお、デプロイ処理時に、別の値、例えば、変数ｋｅｙ「ｆｏｏ」の変数に、ａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）内で値「ｆｏｏ　＝　“ｄｅｖ－ｖａｒ”」を指定すれば、記述４１１は、「ｆｏｏ：“ｄｅｖ－ｖａｒ”」のように生成される。
　さらに、テンプレートファイルには、プログラム的な要素、例えば、ｉｆ文を含んでいてもよい。Ｔｅｒｒａｆｏｒｍでは、使用可能なプログラム的な要素が定義されており、ｃｏｕｎｔという変数によって、リソースを何個構築するかを制御できる。ａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）内で値「Ｓ３＿ｃｏｕｎｔ　＝　１」を指定すれば、「ｒｅｓｏｕｒｃｅ　“ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ”　“ｓ３＿ｂｕｃｋｅｔ”」は一つ生成される。これにより、図５Ｂで入力された情報に基づいてカウントを制御することにより、リソースをカスタマイズすることができる。
　以上、ステップＳ１０４で生成されたシステムソースコードに基づいてデプロイ部２４０はデプロイツールを用いて実行環境２８０上にインフラストラクチャーリソース２８３をデプロイさせる。
　図７は、図３におけるステップＳ１０６とステップＳ１０７における具体的な処理手順の一例を示すフローチャートである。以下図７の各ステップについて説明する。
　設定変更検出部２５０は、利用者２０１がシステム２８１を実行環境２８０上で直接変更したことを検出する（ステップＳ２０１）。具体例としては、図３のステップＳ１０５にてシステム２８１が構築された際に、クラウドベンダーが用意しているシステム２８１を各クラウドベンダーのソースコードとしてエクスポートする機能を用いて基準となるソースコードを取得した後に、逐次エクスポート機能により取得したソースコードと基準となるソースコードとの差分を取得してもよい。
　差分の取得方法としては、上述のように各システム２８１が構築されている環境からエクスポートして取得することが望ましい。各クラウドベンダーが同じシステム２８１であることを示すメタデータを標準で用意しており、それによってシステム２８１への新規機器の追加の検知も可能になるからである。また、図２のステップＳ１０５にてシステム２８１を構築する際に、同じシステムであることを示すメタデータを付与することによっても可能である。
　続いて、設定変更検出部２５０は、設定変更が検出されたかどうかを確認する（ステップＳ２０２）。設定変更が検出された場合は、ステップＳ２０３に進み、設定変更が検出されなかった場合は、処理を終了する。
　設定変更があった場合（ステップＳ２０２で“Ｙｅｓ”）、設定変更検出部２５０は、設定変更の種類を確認する（ステップＳ２０３）。設定変更の種類には、インフラストラクチャーリソース２８３に関する設定変更とインフラストラクチャーリソース２８３の設定値２８２に関する設定変更の２種類が存在する。インフラストラクチャーリソース２８３に関する設定変更としては、新規にインフラストラクチャーリソース２８３を追加、削除する場合があり、インフラストラクチャーリソース２８３の設定値２８２に関する設定変更は、インフラストラクチャーリソース２８３の設定値２８２を変更した場合である。インフラストラクチャーリソース２８３に関する設定変更が検出された場合は、ステップＳ２０７に進み、インフラストラクチャーリソース２８３の設定値２８２に関する設定変更が検出された場合は、ステップＳ２０４に進む。なお、ここでいう設定値２８２とは、図５Ｂに示したパラメタシートに記載されたパラメタである。
　設定変更が設定値２８２の変更であった場合、設定変更反映部２６０は、既存の設定値２８２に関する設定変更かどうかを確認する（ステップＳ２０４）。既存の設定値２８２とは、システムソースコードの中ですでに定義されている設定値２８２のことを示す。一例としては、ＶＭ（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ）をインフラストラクチャーリソース２８３として設定していた場合を想定する。なお、ＶＭとは物理ハードウェアシステム上に作成され (場所はオフプレミスまたはオンプレミス)、固有の ＣＰＵ、メモリー、ネットワーク・インタフェース、ストレージを持ち、仮想コンピュータシステムとして機能する仮想環境のことである。
　そして、ＶＭをシステムソースコードとして定義している部分で、ＶＭのサイズをｓｍａｌｌと設定していたとする。その後、利用者２０１によって手動でＶＭのサイズがｍｅｄｉｕｍに変更された場合、ＶＭのサイズはシステムソースコードとしてすでに定義されている設定値２８２であるため、既存の設定値２８２であると判断される。また、システムソースコードとして定義されていない設定値、例えばＶＭのタグを追加した場合は、システムソースコードとして定義されていない設定値２８２であるため、既存の設定値２８２ではないと判断される。既存の設定値２８２に関する設定変更の場合は、ステップＳ２０５に進み、そうではない場合は、ステップＳ２０６に進む。
　図８は、ステップＳ２０２において参照される、既存の設定値２８２の判断方法について具体例を説明する図である。システム構築装置１００は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を持つ。例えば、インフラストラクチャーリソース２８３がＶＭである場合、ある変数がシステムソースコードの「．／ｔｅｍｐＡ，」というパスの１－９行目に定義されており、また、システムソースコードの「．／ｍｏｄｕｌｅ」というパスの１０－２０行目で呼び出されていることがわかる。これを用いることで、差分として検出されたインフラストラクチャーリソース２８３名とその変数名を入力として、既存の設定値２８２として存在するかどうかを検索し、判断する。
　既存の設定値２８２の設定変更が検出された場合、設定変更反映部２６０は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を用いて、該当設定値２８２の現在値を差分の設定値に変更する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
　既存のパラメタの設定変更が検出されない場合、設定変更反映部２６０は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を用いて、該当設定値２８２を新規設定値としてシステムソースコードに追加する（ステップＳ２０６）。その後、ステップＳ２０５に進み、現在の設定値２８２に設定する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
　設定変更がインフラストラクチャーリソース２８３の変更であった場合、設定変更反映部２６０は、既存のインフラストラクチャーリソース２８３に関する設定変更かどうかを確認する（ステップＳ２０７）。既存のインフラストラクチャーリソース２８３とは、システムソースコードの中ですでに定義されているインフラストラクチャーリソース２８３のことを示す。一例としては、ＶＭのインフラストラクチャーリソース２８３をシステムソースコードとして定義していた場合、利用者２０１が手動で別のＶＭを追加した場合、既存のインフラストラクチャーリソース２８３であると判断される。また、インフラストラクチャーリソース２８３として定義されていない新たなＶＭを追加した場合は、既存のインフラストラクチャーリソース２８３ではないと判断される。さらに、追加されたＶＭが現状のシステムソースコードに含まれていない場合であっても、ＶＭのインフラストラクチャーリソース２８３のソースコードをリポジトリ２２０内にとして持っている場合には、既存のインフラストラクチャーリソース２８３であると判断される。既存のリソースに関する設定変更の場合は、ステップＳ２０８に進み、そうではない場合は、ステップＳ２０９に進む。
　既存のリソースの設定変更が検出された場合（ステップＳ２０７で“Ｙｅｓ”）、設定変更反映部２６０は、システムソースコードに既存のインフラストラクチャーリソース２８３の追加を行う（ステップＳ２０８）。具体例としては、差分として得られた追加されたインフラストラクチャーリソース２８３の名前を用いて、あらかじめリポジトリ２２０に登録された各インフラストラクチャーリソース２８３のソースコードプログラムを検索する。その後、特定されたインフラストラクチャーリソース２８３のソースコードプログラムをシステムソースコードに追加する。なお、ここでは既存リソースの追加について説明したが、設定変更がリソースの削除である場合もあり、その場合にはソースコードプログラム内の該当するリソースを定義する部分を削除すればよい。
　上述の通り、システムソースコードのソースコードプログラムには、使用するインフラストラクチャーリソース２８３を定義する部分と、インフラストラクチャーリソース２８３の設定値２８２を定義、設定する部分が存在する。すなわち、システムソースコードに変更があった場合には、システムソースコード内の、使用するインフラストラクチャーリソース２８３を定義する部分に、登録されたソースコードプログラムのインフラストラクチャーリソース２８３を定義する部分を追加する。また、システムソースコード内の、インフラストラクチャーリソース２８３で使用する変数を定義する部分に、登録されたソースコードプログラムの使用する変数を定義する部分を追加する。そして、システムソースコード内の、インフラストラクチャーリソース２８３で使用する設定値２８２を設定する部分に、登録されたソースコードプログラムの使用する設定値２８２を設定する部分を、それぞれ追加する。
　ここで、使用する設定値２８２を設定する部分に関しては、差分情報の変数名とソースコードプログラムでの変数名の対応付けを行う必要がある。対応付けの方法は従来いくつか提案されている。例えば、差分情報で出力される変数名とソースコードプログラムの変数名の対応付けを予め人手により行う方法、差分情報で出力される変数名とソースコードプログラムの変数名の類似度を計算し対応付けを行う方法などである。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。
　既存のリソースの設定変更が検出されない場合、すなわち、新規のインフラストラクチャーリソース２８３の追加が検出された場合には、設定変更反映部２６０は、新規のインフラストラクチャーリソース２８３のソースコードプログラムの取得を行い、コードディングルールに基づいて修正を行い、追加を行う（ステップＳ２０９）。この処理について図９を用いて詳述する。図９は、ステップＳ２０９における具体的な処理手順の一例を示すフローチャートである。以下図９の各ステップについて説明する。
　設定変更反映部２６０は、差分情報が含むインフラストラクチャーリソース２８３の名前から該当インフラストラクチャーリソース２８３のソースコードプログラムを検索する（ステップＳ３０１）。これは、具体例としては、Ｔｅｒｒａｆｏｒｍでは検索のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）が公開されており、特定のＵＲＬに検索用のパラメタを追加して、検索結果を取得することができる。一例としては、「ｈｔｔｐｓ：／／ｒｅｇｉｓｔｒｙ．ｔｅｒｒａｆｏｒｍ．ｉｏ／ｖ１／ｍｏｄｕｌｅｓ／ｓｅａｒｃｈ？ｑ＝ｎｅｔｗｏｒｋ」に対し、ＧＥＴメソッドを行うことにより、「ｎｅｔｗｏｒｋ」という名前のリソースを検索することができる。また、利用者２０１が所属する団体で管理する共有リポジトリを設定してもよい。さらに、該当インフラストラクチャーリソース２８３の公式ページに記載されている該当インフラストラクチャーリソースを説明するページからソースコードプログラムの例をウェブスクレイピングにより取得してもよい。
　設定変更反映部２６０は、取得されたインフラストラクチャーリソース２８３のソースコードプログラムの精査を行う（ステップＳ３０２）。具体例としては、ステップＳ３０１で取得されたリソースのソースコードプログラムの候補が複数ある場合に、候補の中には、該当のインフラストラクチャーリソースを含まないソースコードプログラムが存在する可能性がある。そのため、複数候補のソースコードプログラムの解析を行い、該当インフラストラクチャーリソースの文字を含んでいるかを確認する。そのあと、その文字を含んでいないソースコードプログラムを候補から削除する。また、ソースコードプログラムが持つメタデータを用いて候補を精査してもよい。具体例としては、ソースコードプログラムの人気度を示すスターの数が多いものを選択してもよい。これにより、複数の取得されたソースコードプログラムから一つのソースコードプログラムを選択する。
　そして、設定変更反映部２６０は、ステップＳ３０２で行った精査により候補が存在するかどうかを確認する（ステップＳ３０３）。候補数が１の場合は、ステップＳ３０４に進み、候補数が０の場合は、処理を終了する。
　候補数が１であった場合（ステップＳ３０３で“Ｙｅｓ”）、設定変更反映部２６０は、ステップＳ３０２で精査を行い一つ選択されたソースコードプログラムの修正を行う（ステップＳ３０４）。ここで、ソースコードプログラムの修正とは、利用者２０１が指定したコーディングルールに基づいて、取得したソースコードプログラムを書き換えることを指す。コーディングルールの具体例としては、ソースコードプログラムの変数名を利用者２０１が指定する命名規則に従って変換する方法がある。これは、構築ツールでリソースに対して設定項目名は定義されているが、その設定項目名に対しての変数名は開発者が命名を行うため、その命名規則が統一されているとは限らないためである。
　該当の変数名について、ソースコードプログラムのコード解析を行う。コード解析の手法は、従来いくつか提案されている。例えば、ソースコードプログラムをプログラミング言語の文法に基づいて字句解析を行い、トークン列に変換する。変換したトークン列から木構造に変換する。変換結果の木構造を基づいて、変数名を確認し、命名規則に則って変換を行う。具体例としては、設定項目名にリソース名を前に追加しアンダーバーでつなげることや、すべて大文字にすることなどである。
　また、コーディングルールの他の例としては、ディレクトリ構成をもとのソースコードプログラムに合わせるというものがある。例えば、ソースコードプログラムとして、各リソースを別のソースコードプログラムファイルとして切り出して、それぞれをモジュールとして呼び出しを行う方式が存在する。その場合、ディレクトリ構成をモジュールとして呼び出しを行う方式と、一つのソースコードプログラムでディレクトリ構成を実現する方式でディレクトリ構成は異なる。モジュールとして呼び出しを行う方式の場合は、取得したソースコードプログラムをモジュールディレクトリ上に配置を行い、取得したソースコードプログラムを呼び出す部分を元々のソースコードプログラムに追加する。
　以上、設定変更反映部２６０が自動でソースコードプログラムの追加を行う説明を行ったが、方法は必ずしも自動追加に限るものではなく、その他利用者２０１に通知を行い、利用者２０１に新規リソースのソースコードプログラムを作成するように促し、作成されたソースコードプログラムを取得する形でもよい。
　本実施例に係るシステム構築装置１００は、システム２８１の設定変更を検出し、その設定変更をコーディングルールに基づいてシステムソースコードへ反映する。コーディングルールに基づいて設定変更を修正することにより、システム２８１の設定変更の反映について利用者２０１が想定したソースコードプログラムとして管理できる。したがってシステム構築装置１００は、利用者２０１が手動で設定変更を行った場合の構築情報への反映を自動で行うために余分な工数をかけることなく、また、自動の設定変更に対して自らのコーディングルールに基づいて修正する必要がないので、設定変更の反映作業の工数を抑制することができる。
　また、本実施例に係るシステム構築装置１００においては、利用者２０１がポータル画面２１０上でシステム２８１の機能要件と非機能要件を入力し、要件を満たすシステム２８１を提示し、利用者２０１がカスタマイズし、システム２８１の構築を自動で行う。これにより、利用者２０１はシステム２８１の設計やシステム２８１の自動構築技術の知識がない場合でも、要件にあったシステム２８１を作成することができる。
＜実施例２＞
　次に、本発明の実施例２に係るシステム構築装置について説明する。実施例１においては、利用者２０１がポータル画面２１０上でシステム２８１の機能要件と非機能要件を入力し、要件を満たすシステム２８１を提示し、利用者２０１がカスタマイズする例を説明した。実施例２では、ポータル画面２１０上での要件入力画面の表示を行わず、利用者２０１が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者２０１がシステム２８１の自動構築技術に精通しているなど、利用者２０１が自らシステムソースコードを作成する場合においても、システムソースコードに基づいてシステム２８１を作成、管理することができる。
　図１０は、本実施形態２においてシステム構築装置１００がシステムを構築し管理する手順を説明するフローチャートである。以下図１０の各ステップについて説明する。
　システム構築装置１００は、利用者２０１からシステムソースコードを受け付ける（ステップＳ４０１）。受け付け方法の具体例としては、ポータル画面２１０上に図５Ｂと同様の画面を表示して、システムソースコードをアップロード可能にしてもよい。また、ポータル画面２１０にシステムソースコードを記述可能なテキストエディタを表示し、利用者２０１が直接システムソースコードを記述してもよい。
　デプロイ部２４０は、ステップＳ４０１で受け付けたシステムソースコードに基づいてデプロイ処理を行う（ステップＳ４０２）。この処理は図３のステップＳ１０４と同様である。本実施例においては、デプロイ処理をユーザが行ってもよい。その場合、Ｔｅｒｒａｆｒｏｍを用いる例としては、ユーザの環境でＴｅｒｒａｆｒｏｍの構築コマンドを用いてシステムの構築を行う。
　ステップＳ４０３及びＳ４０４は、図３のステップＳ１０６及びＳ１０７と同様である。本実施例において、デプロイ処理を利用者２０１が行った場合、設定変更を検出する対象のシステム２８１とシステムソースコードによる構築情報に関する情報をユーザが入力を行い、設定変更の検出と反映を行う。
　以上説明したように、本発明の実施例２では、利用者２０１が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者２０１がシステムの自動構築技術に精通しているなど、利用者２０１が自らシステムソースコードを作成したい場合においても、システムソースコードに基づいてシステムを作成、管理することができる。
　以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。
　上記構成により、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構築情報との差異を修正することができる。
（２）差分に設定値の変更が含まれる場合に、設定変更反映部は、第二ソースコードの設定値をコーディングルールに基づいて修正し、第一ソースコードを修正する。また、差分にインフラストラクチャーリソースの追加が含まれる場合に、設定変更反映部は、追加されたインフラストラクチャーリソースのソースコードを取得し、該ソースコードをコーディングルールに基づいて修正し、第一ソースコードを修正する。これにより、システムのソースコードに加えられる変更がどのような種類であっても、適切に修正を反映させることができる。
（３）設定変更検出部は、システムを特定するメタデータに基づいて、追加されたインフラストラクチャーリソースが新規のインフラストラクチャーリソースであるか否か判定する。これにより、従来技術において想定されていなかった新規リソースの追加が行われていた場合にも、適切にソースコードを修正することが可能になる。
（４）入力部はポータル画面表示部を含み、要件は機能要件と非機能要件とを含み、ポータル画面表示部は、入力された機能要件または非機能要件を満たすシステムの候補を利用者に提示する。これにより、利用者が機能要件と非機能要件とを切り分けて候補を選択することが可能になり、利用者にとって利便性が向上する。さらに、システムの候補が自動的に選択・提示されることにより、利用者に対して所望の要件を追加。修正するための気づきを与えることが可能になる。
（５）デプロイ部は、提示されたシステムの候補に対する利用者の選択に基づいて、利用者が選択したシステムを構築するための構築情報を作成し、システムを実行環境上に構築する。これにより、システム構築装置のリポジトリ内に保存された情報を活用して、迅速なシステム構築を実現できる。
　本発明は、前述した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
１００：システム構築装置、２１０：ポータル画面（入力部・ポータル画面表示部）、２２０：リポジトリ、２３０：システムソースコード作成部、２４０：デプロイ部、２５０：設定変更検出部、２６０：設定変更反映部、２７０：コーディングルール保存部、２８０：実行環境、２８１：システム、２８２：設定値、２８３：インフラストラクチャーリソース

Claims (6)

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

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 (2)

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

Citations (4)

* 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 三菱電機インフォメーションネットワーク株式会社 構成管理装置、構成管理方法、及び、構成管理プログラム

Patent Citations (4)

* 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 三菱電機インフォメーションネットワーク株式会社 構成管理装置、構成管理方法、及び、構成管理プログラム

Also Published As

Publication number Publication date
JP2023167974A (ja) 2023-11-24

Similar Documents

Publication Publication Date Title
US11836158B2 (en) Deployment of container-based computer environments
CN108304201B (zh) 对象更新方法、装置及设备
US10831453B2 (en) Connectors framework
US8819672B2 (en) Multi-image migration system and method
US20180275984A1 (en) Apparatus and method for validating application deployment topology in cloud computing environment
US11385892B1 (en) Optimal software architecture recommendations by an application modernization service
US11237822B2 (en) Intelligent discovery and application of API changes for application migration
US10574724B2 (en) Automatic discovery of management nodes and generation of CLI using HA module
JPH0944361A (ja) アプリケーション・プログラムのネットワーク導入のための導入計画オブジェクト
JPH0934723A (ja) ネットワークでのアプリケーション・プログラムの導入のための導入計画オブジェクトのコミット
US10579354B2 (en) Method and system for rapid deployment and execution of customized functionality across multiple distinct platforms
US11714625B2 (en) Generating applications for versatile platform deployment
CN105765533A (zh) 用于固件虚拟化的方法和装置
CN111930290B (zh) 资源部署方法及装置
CN112214980A (zh) 树结构模板的定制和推荐
CN113268232B (zh) 一种页面皮肤生成方法、装置和计算机可读存储介质
CN112860247A (zh) 一种模型组件的自定义生成方法、装置、设备及介质
WO2023218875A1 (ja) システム構築装置
US20200081700A1 (en) Intention-based command optimization
US11704119B2 (en) Migrating infrastructure as code between different cloud providers
CN111722881B (zh) 一种容器云平台的资源扩展方法、系统及装置
CN114389936A (zh) 一种跨云多集群部署运维方法、系统、处理器和存储介质
JP2014164545A (ja) デプロイメント方法およびプログラム
CN115315696A (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