Runtime Containers

Abstract

To provide methods and systems of efficiently configuring and deploying execution environments for software applications.SOLUTION: A method includes: receiving a bootstrap execution environment from a data store; executing the bootstrap execution environment; determining whether an enhanced execution environment is available from the data store; receiving the enhanced execution environment from the data store when the enhanced execution environment is available from the data store; enhancing the bootstrap execution environment based on the enhanced execution environment; executing the software application; enhancing the bootstrap execution environment based on the manifest of dependencies to create the enhanced execution environment, when the enhanced execution environment is not available from the data store; storing the enhanced execution environment in the data store; and executing the software application.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] Technical Field The present disclosure relates to efficiently configuring and deploying execution environments for software applications. [Background technology]

[0002] background Container technology offers the promise of rapidly scaling applications and services without incurring the significant overhead associated with traditional virtualization environments. Source code for software applications may be developed and tested within a software development environment prior to deployment to run within a container. Container builders are publicly available to build output containers from input source code. These container builders generally include instructions and build tools that describe how to package the source code into a corresponding container for deployment. Container builders often generate heavy container images that include both build-time tools such as software development kits, compilers, and / or debuggers, as well as a runtime environment for running the output container. These heavy container images are larger and include content / components that are not required during deployment and delivery to customers. For example, including a compiler in a deployed container is unnecessary as it not only adds weight to the container but also introduces attack vectors and security vulnerabilities to the packaged deployment. A lighter-weight execution environment includes only the components / content required to support an application or service. However, this streamlining of the execution environment may come at the cost of increased configuration burden. Software development platforms may not be optimized for configuring and deploying application execution environments. Furthermore, software developers may not be skilled or knowledgeable in configuring and deploying lightweight execution environments, or may not have the authority to configure or deploy execution environments. As a result, software developers who wish to deploy applications in lightweight execution environments face inefficiencies. Summary of the Invention [Means for solving the problem]

[0003] overview Aspects of the disclosure relate to configuring and deploying execution environments for software applications. One aspect provides a method that includes receiving, in data processing hardware, a bootstrap execution environment from a data store, the bootstrap execution environment including the software application having a manifestation of dependencies. The method further includes causing the data processing hardware to execute the bootstrap execution environment and perform operations including determining whether an extended execution environment is available from the data store. If the extended execution environment is available from the data store, the operations further include receiving the extended execution environment from the data store, extending the bootstrap execution environment based on the extended execution environment, and executing the software application. If the extended execution environment is not available from the data store, the operations include extending the bootstrap execution environment based on the manifestation of dependencies to create an extended execution environment, storing the extended execution environment in the data store, and executing the software application.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In an implementation of, the method includes the data processing hardware annotating the extended execution environment in a data store to indicate at least one of a version of the software application, an operating system version associated with the extended execution environment, or a processor architecture associated with the extended execution environment. Determining whether the extended execution environment is available from the data store may include determining whether the extended execution environment is compatible with at least one of the software application, an operating system version associated with the bootstrap execution environment, or a processor architecture associated with the bootstrap execution environment.

[0005] The method may further include receiving a build request for the software application at the data processing hardware, the data processing hardware configuring a bootstrap execution environment based on the software application, and the data processing hardware storing the bootstrap execution environment in a data store. Extending the bootstrap execution environment based on the dependency manifest may include installing application dependencies. In some examples, the software application is one of a JavaScript application, a Python application, or a Ruby application. The application dependencies may include at least one of a support library, an architecture-specific binary module, or a module compiled at run time. In some implementations, the method includes extending the bootstrap execution environment based on the dependency manifest to create an extended execution environment, and then identifying an updated set of files including files added or modified by extending the bootstrap execution environment based on the dependency manifest. Storing the extended execution environment in a data store may include storing the updated set of files in the data store. In some examples, the bootstrap execution environment includes a container image, and the data store includes a container registry.

[0006] Another aspect of the disclosure provides a system for configuring and deploying an execution environment for a software application. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving a bootstrap execution environment from a data store, the bootstrap execution environment including the software application having a manifestation of dependencies. The operations further include executing the bootstrap execution environment and causing the data processing hardware to perform further operations including determining whether an extended execution environment is available from the data store. If the extended execution environment is available from the data store, the operations further include receiving the extended execution environment from the data store, extending the bootstrap execution environment based on the extended execution environment, and executing the software application. If the extended execution environment is not available from the data store, the operations include extending the bootstrap execution environment based on the manifestation of dependencies to create an extended execution environment, storing the extended execution environment in the data store, and executing the software application.

[0007] Implementations of the present disclosure may include one or more of the following optional features: In some implementations, the operations further include annotating the extended execution environment in the data store to indicate at least one of a version of the software application, an operating system version associated with the extended execution environment, or a processor architecture associated with the extended execution environment. Determining whether the extended execution environment is available from the data store may include determining whether the extended execution environment is available to the user. The method may include determining whether the bootstrapping execution environment is compatible with at least one of the software application, the operating system version associated with the bootstrap execution environment, or the processor architecture associated with the bootstrap execution environment.

[0008] The operations may further include receiving a build request for the software application, configuring a bootstrap execution environment based on the software application, and storing the bootstrap execution environment in a data store. Extending the bootstrap execution environment based on the dependency manifest may include installing application dependencies. In some examples, the software application is one of a JavaScript application, a Python application, or a Ruby application. The application dependencies may include at least one of a support library, an architecture-specific binary module, or a module compiled at run time. In some implementations, the operations include extending the bootstrap execution environment based on the dependency manifest to create an extended execution environment, and then identifying an updated set of files including files added or modified by extending the bootstrap execution environment based on the dependency manifest. Storing the extended execution environment in a data store may include storing the updated set of files in the data store. In some examples, the bootstrap execution environment includes a container image, and the data store includes a container registry.

[0009] The details of one or more implementations of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will become apparent from the description and drawings, and from the claims. [Brief description of the drawings]

[0010] [Figure 1]FIG. 1 is a schematic diagram of an exemplary environment for configuring and deploying an application execution environment. [Figure 2A] 1 is a schematic diagram of a manifestation of a software application and corresponding dependencies. [Figure 2B] 1 is a schematic diagram of a manifestation of a software application and corresponding dependencies. [Figure 2C] 1 is a schematic diagram of a manifestation of a software application and corresponding dependencies. [Figure 3A] FIG. 1 is a schematic diagram of establishing an execution environment for executing software applications. [Figure 3B] FIG. 1 is a schematic diagram of establishing an execution environment for executing software applications. [Figure 3C] FIG. 1 is a schematic diagram of establishing an execution environment for executing software applications. [Figure 3D] FIG. 1 is a schematic diagram of establishing an execution environment for executing software applications. [Figure 3E] FIG. 1 is a schematic diagram of establishing an execution environment for executing software applications. [Figure 4] 1 is a flowchart of an example arrangement of operations for a method of configuring and deploying an execution environment for a software application. [Diagram 5] FIG. 1 is a schematic diagram of an exemplary computing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Like reference numbers in the various drawings indicate like elements. Detailed Description A software application may be developed in a software development environment and then deployed to be operational in an application execution environment. Containers are emerging as a preferred application execution environment for deploying software applications. Container technology offers the promise of rapidly scaling applications and services without incurring the significant overhead associated with traditional virtualization environments. Multiple containerized applications may run on a single host computer and access the same underlying operating system. Furthermore, containerized applications may run on a variety of underlying operating systems and / or computer or processor architectures. Container builders are publicly available to build container images from input source code. These container builders typically generate heavy container images that include build-time tools such as software development kits, compilers, and / or debuggers, as well as the runtime environment required to run the software application. These heavy container images are large and often contain unnecessary content / components when deployed / distributed. For example, including a compiler in a deployed container is unnecessary as it adds weight to the container and introduces attack vectors and security vulnerabilities to the packaged deployment. Configuring and deploying a container image requires time, effort, and skill. Container images may need to be reconfigured every time a software application is updated. Frequent reconfigurations increase the cost and effort of software development.

[0012] A lighter-weight execution environment includes only the components / content required to support an application or service, for example, without software development content / components. However, specialized skills or knowledge may be required to configure and deploy a lighter-weight execution environment. Configuration may require identifying software development content / components to be omitted and identifying necessary run-time content / components to be included in the execution environment. In short, an application execution environment may be substantially different from a software development environment. For example, a software development environment may include a web browser, an email client, a revision control system, and / or a graphical display optimized to facilitate software development. However, an application execution environment may be optimized for reliable and efficient execution of deployed applications. A software developer may not be skilled or knowledgeable in configuring and deploying a lightweight execution environment, or may not have the authority to configure or deploy an execution environment.

[0013] Container builders are publicly available to build generic container images without requiring deep mastery of container configuration best practices. However, these container builders build containers from static images. That is, the static container image includes an environment for the initial or "bootstrap" execution of the application. While this approach may be sufficient for architecture-independent or architecture-compatible software applications, software applications may run more efficiently after customizing or extending their execution environment. For example, software applications may dynamically install content such as architecture-specific binary modules, support libraries, or other files, or the application runtime environment may compile source code or bytecode into architecture-specific machine code to improve application performance. Thus, generic container building tools that build containers from static images lack the ability to capture these dynamic runtime extensions or update the container image to reflect the runtime architecture-specific extensions. Applications may require customization or extensions to be made to the container image. Each time the application is restarted, these runtime extensions are executed again. Running a heavyweight container configuration tool within the container may be able to capture these dynamic runtime extensions, at the cost of adding weight and requiring time, effort, and skill to configure and / or deploy the container. Implementations herein are directed to methods and systems for efficiently configuring and deploying a secure execution environment (e.g., a container) for a software application, including capturing dynamic and / or architecture-specific extensions tailored to the execution environment by the software application for use in subsequent executions of the software application.

[0014] 1, in some implementations, the system 100 includes developer devices 110, 110a-n associated with a software developer 10 that may communicate with a remote system 140, for example, via a network 130. The remote system 140 may be a distributed system (e.g., a cloud environment) having scalable / elastic resources 142. The resources 142 include computing resources (e.g., data processing hardware) 144 and / or storage resources (e.g., memory hardware) 146. The software developer 10 may use the developer device 110 to develop a software application 200 for execution on the remote system 140. The remote system 140 also executes a container builder 300 to build one or more secure execution environments 310, 320 (e.g., containers) for executing the software application 200 on the remote system 140, regardless of how the software application 200 was developed / created by the developer 10. In contrast to generic container building tools (e.g., Docker) that require the developer 10 to provide configuration associated with instructions for building a container to run the software application 200, the container builder 300 is configured to automatically configure a bootstrap execution environment 310 (e.g., bootstrap container 310) based on the software application 200 received from the developer device 110 during the configuration phase 301. Here, the bootstrap execution environment 310 is associated with a static container image having static content. In particular, in contrast to the workflow used in generic container building tools (e.g., Docker), the configuration phase 301 configures a static image associated with the bootstrap execution environment 310 without executing commands to create dynamic content. The bootstrap execution environment 310 may include tooling 316 for building or configuring the execution environments 310, 320. In some implementations, the tooling 316 is a set of command line tools for creating, configuring, and managing containers.Other forms of tooling 316 are possible, including remote and / or web-based services. In some implementations, the container builder 300 configures the bootstrap execution environment 310 to include a set of startup instructions 318. The startup instructions 318 define the steps the container builder 300 takes when executing the bootstrap execution environment 310. The use of the tooling 316 and startup instructions 318 is described in more detail below with reference to Figures 3A-3E.

[0015] Thereafter, during the execution phase 302, the container builder 300 is configured to run / execute the bootstrap execution environment 310 to build / create the extended execution environment 320 with the dynamic content (e.g., application dependencies 322). Specifically, the container builder 300 builds the extended execution environment 320 for the software application 200 by extending the bootstrap execution environment 310 with the dynamic content (e.g., application dependencies 322). That is, during the execution phase 302, the container builder 300 executes the software application 200 within the bootstrap execution environment 310. The container builder 300 and / or the software application 200 creates a manifest 2 of the software application's 200 dependencies. 12, thereby extending the bootstrap execution environment 310 with the dynamic content 322 to create an extended execution environment 320. As a result, the container builder 300 enables the developer 10 to build, and optionally deploy, the extended execution environment 320, including the dynamic content 322, for running the software application 200 on the remote system 140, without requiring the developer 10 to provide a configuration (e.g., a Docker file) that provides instructions on how the static and dynamic content should be written into an image to build a container.

[0016] In some implementations, the remote system 140 includes a data store 150 that stores one or more bootstrap execution environments 310, 310a-n and one or more extended execution environments 320, 320a-n within memory hardware 146, 520 (FIG. 5). In some examples, the data store 150 includes a container registry, with each execution environment 310, 320 associated with a respective containerized software application 200. In these examples, the bootstrap execution environment 310 may be referred to as a "bootstrap container" that is associated with a static image having static content (e.g., a manifest of dependencies 212), and the extended execution environment 320 may be referred to as an "extended container" that is associated with a container image having content 322 (e.g., application dependencies) that is dynamically created during execution of the bootstrap execution environment 310 (e.g., during the execution phase 302). Each execution environment 310, 320 may include an identifier 314 (e.g., a tag) that identifies the software application 200 associated with the execution environment 310, 320. The extended execution environment 320 may also include metadata 324 that describes aspects of the extended execution environment 320, such as the operating system version and / or processor architecture of the remote system 140 on which the extended execution environment 320 was built.

[0017] In the illustrated example, the container builder 300 receives a build request 180 from the developer device 110 to build an execution environment 310, 320 for a software application 200 developed locally by the developer 10. The build request 180 may simply include the software application 200, including the manifest of dependencies 212. The build request 180 may also include an identifier 314 (e.g., a tag) that identifies the software application 200 in addition to or instead of the software application 200, and the container builder 300 may use the identifier 314 to retrieve a bootstrap execution environment 310 associated with the software application 200 from the data store 150. Here, the bootstrap execution environment 310 is associated with a static image that includes only information about the content.

[0018] As described in more detail below, after receiving the bootstrap execution environment 310, the container builder 300 may execute the bootstrap execution environment 310 and determine whether an extended execution environment 320 is available from the data store 150, e.g., whether it was previously created and stored in the data store 150. If the extended execution environment 320 is available, the container builder 300 may retrieve at least the application dependencies 322 (e.g., dynamic content) associated with the extended execution environment 320 from the data store 150 and extend the bootstrap execution environment 310 with the application dependencies 322 dynamically created during a previous initial execution of the bootstrap execution environment 310. The bootstrap execution environment 310 may include tooling 316 for building or configuring the execution environments 310, 320. In some examples, the bootstrap execution environment 310 uses the tooling 316 to configure the extended execution environment 320 and store the extended execution environment 320 in the data store 150. In this scenario, the bootstrap execution environment 310 performs all the steps necessary to create the extended execution environment 320. Because it has already been run once, subsequent instances running the bootstrap execution environment 310 will not need to run startup commands to create dynamic content (e.g., application dependencies) because the dynamic content can simply and more efficiently be retrieved from the data store 150.

[0019] The term software application 200 (i.e., software resource) may refer to computer software that causes a computing device (e.g., data processing hardware 144, 500 (FIG. 5)) to perform a task. Thus, software application 200 may correspond to any type or form of software, file, and / or executable code that may be installed, executed, deployed, and / or otherwise implemented on a distributed system (e.g., remote system 140). In some examples, software application 200 may be referred to as an "application," "app," or "program." Exemplary applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, web browser applications, media streaming applications, social networking applications, security applications, and gaming applications. Software application 200 may be implemented in a variety of programming languages, including C / C++, Java, Python, Ruby, Perl, etc. The application may be expressed in one or more programming languages, including high level and structured programming languages ​​such as C / C++ applications, Java (registered trademark), or JavaScript®. The software application 200 may be referred to as a JavaScript application, a Python application, a Ruby application, a Perl application, or a JavaScript application. The software application 200 may be expressed in other forms, frameworks, and / or programming languages. For example, the software application 200 may be developed in the Node.js framework. The generated JavaScript application can be a Node.js application or a JavaScript application. This is sometimes called "cation."

[0020] In some examples, the software application 200 includes a dependency manifest 212 or list. The dependency manifest (interchangeably referred to as a "dependency manifest") 212 may list files and / or software libraries or modules that are used or accessed by the software application 200 during execution on the remote system 140. The dependency manifest 212 may include architecture-specific and / or programming language-specific support libraries used by the software application 200. For example, the dependency manifest 212 may include the NumPy scientific computing library for the Python programming language. The dependency manifest 212 may include a dependency package. The dependency manifest 212 may be explicitly configured by the software developer 10 to configure the execution environment 310, 320 on the remote system 140. In some examples, the dependency manifest 212 is implied by the software application 200. For example, the software application 200 may include statements that require or import supporting libraries. The software application 200 may include a statement that states "requests dependency on URL parsing support library ("urlib")". Collectively, the Such statements may be considered part of the dependency manifest 212.

[0021] The bootstrap execution environment 310 may include the software application 200 in a complete file system including everything needed to initially run the software application 200, e.g., code, runtime, system tools, and libraries, so that the software application 200 can run consistently regardless of the operating environment. The remote system 140 may build a bootstrap execution environment 310 based on the developer application 200. In this case, the remote system 140 may receive the bootstrap execution environment 310 from the developer device 110a-n and store the bootstrap execution environment 310 in the data store 150. In these examples, the build request 180 received from the developer device 110 may include the bootstrap execution environment 310. The execution environments 310, 320 stored in the data store 150 may be indexed and / or cataloged and / or assigned an identifier 314 for later retrieval from the data store 150. The data store 150 may represent the identifier 314 assigned to each execution environment 310, 320 with a "tag" or other annotation to facilitate subsequent search and retrieval. The identifier 314 may identify the software application 200 associated with the execution environment and / or may specifically identify the execution environment 310, 320. Thus, a build request 180 from a developer device 110a-n may include one or more identifiers 314 that identify the software application 200 and / or the bootstrap execution environment 310. The data store 150 may include security features such as authentication to protect against unauthorized access to the execution environments 310, 320 or the software application 200.

[0022] 2A-2C are schematic diagrams of software applications 200, 200a-c and their respective manifests of dependencies 212, 212a-c. FIG. 2A illustrates an example Ruby software application 200a that includes a ".gemspec" file that lists a manifest of dependencies 212a that includes runtime commands for dynamically creating application dependencies 322. Here, the application dependencies 322 of the Ruby software application 200a are dynamically created upon execution of the manifest of dependencies 212a in the bootstrap execution environment 310, and are generated using URL processing (curl) and JSON data. In some examples, the ".gemspec" file includes statements indicating a preferred range of versions or specific versions of application dependencies 322 to be dynamically created when the Ruby software application 200a is executed in the bootstrap execution environment 310. Here, the ".gemspec" file indicates that version 0.0.9 and version 1.7.3 are application dependencies 322 for the Ruby software application 200a. In some examples, the ".gemspec" file includes the statement "s.add_dependency('json', '~>2.1')" to indicate that a json support library greater than 2.1 but less than 3.0 is an application dependency 322 for the Ruby software application 200a. The container builder 300 determines whether the Ruby software application 200a is running in the bootstrap execution environment 310. When executed within the bootstrap execution environment 310, the bootstrap execution environment 310 may be extended by creating application dependencies 322 based on the manifest of dependencies 212 listed in the ".gemspec" file. Other techniques for extending the bootstrap execution environment 310 for the Ruby software application 200a are also possible. The container builder 300 may store the extended execution environment 320 in the data store 150.

[0023] 2B, an exemplary Node.js software application (e.g., JavaScript application 200b) is shown. The Node.js software application 200b includes a package manager (npm) command that lists a dependency manifest 212b that includes runtime commands for dynamically creating application dependencies 322. where the package manager command is the database (mysql) package. The page is a Node.js software application 200b bootstraps the execution environment 3 10. In some examples, the container builder 300 may include a Node.js software package 322 that may be dynamically created when the container builder 300 is executed on the Node.js software. When the software application 200b is executed within the bootstrap execution environment 310, The bootstrap execution environment 310 is extended by executing package manager commands to dynamically create application dependencies 322. The application 200b includes a JavaScript statement that further lists a manifest of dependencies 212, where the JavaScript statement indicates that cryptography ("crypto") and database ("mysql") support libraries are also application dependencies 322 that will be dynamically created when the Node.js software application 200b is executed in the bootstrap execution environment 310. In some examples, the container builder 300 executes the Node.js software application 200b in a JavaScript engine that includes a just-in-time (JIT) compiler. The container builder 300 In order to extend the bootstrap execution environment 310, the JIT compiler is In some implementations, the container builder 300 may execute package manager commands to compile the Node.js software application 200b into more efficient machine code, such as into modules that are compiled at run time. 200b to execute the Node.js software application 200b. Application dependencies 322 may be created dynamically. Other techniques are possible for extending the bootstrap execution environment 310 for application 200b. The container builder 300 may store the extended execution environment 320 in the data store 150.

[0024] Referring to FIG. 2B, an exemplary Python software application 200c is shown. Similar to the Node.js software application 200b, the Python software application The application 200c includes package manager (pip) commands that list the dependency manifest 212, which includes run-time commands for dynamically creating application dependencies 322. Here, the package manager commands include commands for the web framework, The Python software application 200c indicates that the django package is an application dependency 322 that will be dynamically created when the Python software application 200c is executed in the bootstrap execution environment 310. The Python software application 200c includes a Python statement that further lists the manifest 212 of application dependencies, where the Python statement indicates that the django specific version (django==1.11.0, django-braces==0.2.1, django-model-utils==1.1.0, django-oauth2-provider==0.2.4, djangorestframework==2.3.1) support libraries are also application dependencies 322 that will be dynamically created when the Python software application 200c is executed in the bootstrap execution environment 310. In some implementations, the container builder 300 executes the package manager command and executes the Python software application 200c to dynamically create the application dependencies 322 for the Python software application 200c. Other techniques for extending the bootstrap execution environment 310 for the Python software application 200c are possible. The container builder 300 may store the extended execution environment 320 in the data store 150.

[0025] 3A-3E show schematic diagrams of a container builder 300 that builds an extended execution environment 320 for a software application 200. Referring to FIG. 3A, a configuration phase 301 (FIG. 1) of the container builder 300 is shown. In some examples, the container builder 300 receives a build request 180, where the build request 180 simply includes the software application 200, including a manifest of dependencies 212. During the configuration phase 301, the container builder 300 configures and builds a bootstrap execution environment 310 for the software application 200. The bootstrap execution environment 310 is a complete file system that includes everything needed to initially run the software application 200, e.g., code, runtime, system tools, and libraries, so that the software application 200 can run consistently regardless of the operating environment. In some examples, the container builder 300 constructs a static image (e.g., the bootstrap execution environment 310) without creating dynamic content, i.e., without runtime architecture-specific and / or dynamic application dependencies 322.

[0026] The container builder 300 can configure the bootstrap execution environment 310 to include tooling 316 for building or configuring the execution environments 310, 320. In some implementations, the tooling 316 is a set of command line tools for creating, configuring, and managing containers. The tooling 316 may also be capable of storing the extended execution environment 320 in the data store 150. For example, FIG. 3A shows the container builder 300 storing the bootstrap execution environment 310 in the data store 150. As described in more detail below with respect to the execution phase 302, the tooling 316 may also be capable of interacting with the data store 150, for example, to determine whether the extended execution environment 320 is available. In some examples, the tooling 316 is capable of execution environment introspection. That is, the tooling 316 may be capable of determining which files in the bootstrap execution environment 310 have been added or modified during the process of extending an execution environment, for example, the bootstrap execution environment 310, to create the extended execution environment 320. In some implementations, the container builder 300 configures the bootstrap execution environment 310 to include a set of startup instructions 318. The startup instructions 318 define operations (e.g., steps) for the container builder 300 to perform when executing the bootstrap execution environment 310 during the execution phase 302. The container builder 300 may use tooling 316 included in the bootstrap execution environment 310 when executing the steps of the startup instructions 318. The container builder 300 can use the tooling 316 to upload a container image including the bootstrap execution environment 310 to a container registry (e.g., data store 150). The container builder 300 can add an identifier 314 (e.g., a tag) to the bootstrap execution environment 310 that identifies the software application 200 associated with the bootstrap execution environment 310. The identifier 314 can facilitate subsequent search and retrieval.

[0027] 3B, the container builder 300 executes the bootstrap execution environment 310 during the execution phase 302. The container builder 300 may receive the bootstrap execution environment 310 (e.g., using the identifier 314) from the data store 150 after building / creating / configuring the bootstrap execution environment 310 during the configuration phase 301 (FIG. 3A). In some examples, the container builder 300 executes the bootstrap execution environment 310 immediately during the execution phase 302 upon creating / configuring the bootstrap execution environment 310 during the configuration phase 301. The bootstrap execution environment 310 may include the software application 200 including the manifest of dependencies 212. In the illustrated example, the container builder 300 executes the bootstrap execution environment 310, causing the container builder 300 to execute a launch instruction 318. The launch instruction 318 may include determining whether an associated extended execution environment 320 is available from the data store 150. 3B, the data store 150 does not initially include the extended execution environment 320. Thus, while executing the launch instruction 318, the container builder 300 determines that the associated extended execution environment 320 is not available from the data store 150. For example, the container builder 300 may query the data store 150 using the identifier 314 to determine whether the data store 150 includes the associated extended execution environment 320. The identifier 314 may be associated with a version of the software application 200. In some examples, the container builder 300 may determine that the version number of the software application 200 associated with the bootstrap execution environment 310 (and included in the build request 180) is not available from the stored extended execution environment 320. If the version is not the same as that of the software application 200, it is determined that the extended execution environment 320 is not available.

[0028] If the container builder 300 determines that the associated extended execution environment 320 is not available from the data store 150, the launch instructions 318 include operations / steps for extending the bootstrap execution environment 310 based on the dependency manifest 212. The container builder 300 may extend the bootstrap execution environment 310 to build / create / configure the extended execution environment 320. The container builder 300 may extend the bootstrap execution environment 310 by installing (e.g., downloading, copying, compiling) the application dependencies 322. In some examples, the container builder 300 installs the application dependencies 322 before executing the software application 200. As described above, the container builder 300 may execute commands, such as package manager commands, included in the dependency manifest 212 to create (e.g., install) the application dependencies 322. In some examples, the container builder 300 executes the software application 200 to create the application dependencies 322. The container builder 300 may execute / run the software application 200 to cause the software application 200 to execute statements that require or import support libraries, files, or other application dependencies 322. Thus, the container builder 300 extends the bootstrap execution environment 310 with the imported application dependencies 322 to create an extended execution environment 320. The container builder 300 may execute the software application 200 to compile application source code or common intermediate language (CIL), such as bytecode, into architecture-specific machine code or binary code. For example, the container builder 300 may execute the software application 200 in a JIT execution engine.The JIT engine may compile modules of the software application 200 into JIT compiled modules containing efficient machine code when the modules of the software application 200 are first loaded or accessed. In some implementations, the container builder 300 creates some application dependencies 322 before executing the software application 200 and creates other application dependencies 322 by executing / running the software application 200. The container builder 300 may use other techniques to dynamically create the application dependencies 322.

[0029] The dynamic content (e.g., application dependencies 322) may be architecture-specific. That is, the application dependencies 322 may be compatible with a particular processor architecture and / or a particular operating system version associated with the bootstrap execution environment 310 executed by the container builder 300 to create the application dependencies 322. For example, the application dependencies 322 may include files or modules that include efficient architecture-specific machine or binary code and / or runtime compiled modules created by a JIT execution engine. In some implementations, after the container builder 300 extends the bootstrap execution environment 310 to include the dynamically created application dependencies 322, the extended execution environment 320 no longer needs to execute the steps of the launch instructions 318 associated with creating the application dependencies 322. Thus, the container builder 300 may omit the launch instructions 318 from the extended execution environment 320. The container builder 300 adds metadata 324 to the extended execution environment 320 that indicates the operating system version and / or the processor architecture associated with the bootstrap execution environment 310 that created the extended execution environment 320. In some examples, the architecture-specific content (e.g., application dependencies 322) includes metadata indicating the operating system version and / or processor architecture associated with the bootstrap execution environment 310. The container construct may use other techniques to create / configure the extended execution environment 320.

[0030] FIG. 3B also shows the container builder 300 executing further steps of the launch instructions 318, including storing the extended execution environment 320 in the data store 150. In some implementations, the container builder 300 uses the tooling 316 to store the extended execution environment 320. For example, the data store 150 may include a container registry. The container builder 300 can use the tooling 316 to create a container image that includes the extended execution environment 320. The extended execution environment 320 may include the content of the bootstrap execution environment 310 (e.g., static content) and the application dependencies 322 (dynamic content) created by the container builder 300. The container builder 300 may further use the tooling 316 to upload the container image that includes the extended execution environment 320 to a container registry (e.g., data store 150). The launch instructions 318 may further include tagging, annotating, indexing, or otherwise identifying the extended execution environment 320 to facilitate search and retrieval. For example, the launch instructions 318 may include adding an identifier 314 to the extended execution environment 320. For example, the identifier 314 may indicate that the data store 150 includes the extended execution environment 320 associated with a version of the software application 200. The container builder 300 may add metadata 324 to the extended execution environment 320 to indicate aspects of the extended execution environment 320, such as the operating system version and / or processor architecture of the remote system 140 on which the extended execution environment 320 executes. For example, the container builder 300 may "tag" or annotate the extended execution environment 320 with the metadata 324. In one example, the container builder 300 tags the extended execution environment 320 with metadata 324 indicating that the extended execution environment 320 was created on an Ubuntu LINUX system running on the "x86_64" architecture. Other metadata 324 conventions or content may be used as well.

[0031] 3C, the container builder 300 may store the differences between the bootstrap execution environment 310 and the extended execution environment 320 in the data store 150. That is, the container builder 300 may store only the dynamically created application dependencies 322 in the data store 150, for example, to save space in the data store 150. Here, the dynamically created application dependencies 322 for the extended execution environment may be stored in the data store 150 and may include associated identifiers 314 (e.g., for later search and retrieval of the application dependencies) and / or associated metadata 324 (e.g., to indicate aspects such as the operating system version and / or processor architecture of the remote system 140 for executing the extended execution environment 320 associated with the dynamically created application dependencies). For example, the launch instructions 318 may include introspection to determine the differences between the bootstrap execution environment 310 and the extended execution environment 320 by identifying the application dependencies 322 that were updated or dynamically created during the execution phase 302. That is, the container builder 300 may determine / identify application dependencies 322 that correspond to files that have been added or modified by extending the bootstrap execution environment 310. The container builder 300 may use tooling 316 included in the bootstrap execution environment 310 to determine / identify the updated set of files, i.e., the application dependencies 322 that correspond to files that have been added or modified by extending the bootstrap execution environment 310. In some implementations, the container builder 300 may use standard operating system commands or programming interfaces to determine files that were added or modified by extending the bootstrap execution environment 310 based on the manifest of dependencies 212. For example, the container builder 300 may use a UNIX "find" command to recursively search for files that have changed. The container builder 300 may use other techniques to determine extensions to the bootstrap execution environment 310. In some implementations, the container builder 300 may use a UNIX "tar" file based on recently added or modified files. The container builder 300 creates a tar file in the extended execution environment 320. and tag the "tar" file as an extended execution The environment 320 may indicate that it does not include a fully executable extended execution environment 320, but rather a delta that includes only the application dependencies 322. When the bootstrap execution environment 310 is then executed, the container builder 300 creates the bootstrap execution environment based on the application dependencies 322 in the “tar” file received from the data store 150. The row environment 310 may be expanded.

[0032] In contrast to the example shown in FIG. 3B where the container builder determined that the associated extended execution environment 320 is not available from the data store 150, FIG. 3D illustrates the container builder 300, while executing the launch instruction 318, determining that the associated extended execution environment 320 is available from the data store 150 (e.g., the data store 150 includes the associated extended execution environment 320). In some examples, the container builder 300 has previously created the extended execution environment 320 and stored it in the data store 150. The previously created execution environment 320 may include an identifier 314 that associates the extended execution environment 320 with a version of the software application 200. The container builder 300 may determine that the extended execution environment 320 is available if the extended execution environment 320 includes a “tag” (e.g., identifier 314) that indicates that the extended execution environment 320 includes a preferred version (e.g., version number) of the software application 200. In some examples, the version number includes a major version number and a minor version number. In these examples, the container builder 300 may determine that if the major software version number of the software application 200 associated with the bootstrap execution environment 310 is the same as the major version of the software application 200 associated with the stored extended execution environment 320, then the associated extended execution environment 320 is available from the data store 150.

[0033] The associated extended execution environment 320 may include metadata 324 indicating aspects of the extended execution environment 320, such as the operating system version and / or processor architecture of the remote system 140 used to build the extended execution environment 320. The extended execution environment 320 may include annotations or tags that include the metadata 324. The container builder 300 may determine that the extended execution environment 320 is available if the extended execution environment 320 includes metadata 324 indicating that aspects of the extended execution environment 320 are suitable, such as the operating system version and / or processor architecture of the remote system 140 that built the extended execution environment 320. For example, the container builder 300 may determine that the extended execution environment 320 is not available from the data store 150 when the metadata 324 indicates a processor architecture that is incompatible with the bootstrap execution environment 310 (e.g., incompatible with the remote system 140 that runs the bootstrap execution environment 310). In this example, the container builder 300 creates a bootstrap execution environment 310 by extending the bootstrap execution environment 310 based on the manifest of dependencies 212, as described above with reference to FIG. 3B. The container builder 300 may then proceed to execute the launch instruction 318 according to the metadata 324 associated with the extended execution environment 320. Alternatively, the container builder 300 may determine that the extended execution environment 320 is available from the data store 150 when the metadata 324 associated with the extended execution environment 320 indicates an operating system version and processor architecture that is compatible with the bootstrap execution environment 310. The container builder 300 may use other techniques to determine whether the extended execution environment 320 is available from the data store 150. The container builder 300 may use tooling 316 included in the bootstrap execution environment 310 to determine whether the associated extended execution environment 320 is available. For example, the data store 150 may include a container registry. In this example, the tooling 316 may be able to search for a suitable extended execution environment 320 in a container registry (e.g., the data store 150). The tool may search for the extended execution environment 320 using the software version identifier 314 and / or metadata 324, or using other techniques to determine that a suitable extended execution environment 320 is available from the data store 150.

[0034] In the illustrated example, once the container builder 300 determines that an associated extended execution environment 320 is available from the data store 150, the container builder 300 receives the extended execution environment 320 from the data store 150 and extends the bootstrap execution environment 310 based on the extended execution environment 320. The container builder 300 may receive the extended execution environment 320 by downloading the extended execution environment 320 including the software application 200 from the data store 150 and extend the bootstrap execution environment 310 by simply executing the downloaded extended execution environment 320 having dynamic content (e.g., application dependencies 322) instead of the bootstrap execution environment 310 having only static content. In another example, instead of executing the downloaded extended execution environment 320, the container builder 300 extends the bootstrap execution environment 310 based on the application dependencies 322 included in the downloaded extended execution environment 320. For example, the container builder 300 may use the tooling 316 to download and install application dependencies 322 into the bootstrap execution environment 310 from an associated extended execution environment 320 in the data store 150. Extending the bootstrap execution environment 310 based on the extended execution environment 320 may be more efficient than extending the bootstrap execution environment 310 based on the manifest of dependencies 212.

[0035] As described above with respect to FIG. 3C, the container builder 300 may store the differences (i.e., the dynamically created application dependencies 322) between the bootstrap execution environment 310 and the extended execution environment 320 in the data store 150. Referring to FIG. 3E, when the container builder 300 executes the launch instructions 318 regarding whether the associated extended execution environment 320 is available from the data store 150, the container builder 300 may determine that a suitable difference is available from the data store 150. Here, the difference may include, for example, a container image including application dependencies 322 that were dynamically created, compiled, downloaded, or otherwise marshaled during a previous execution of the software application 200 in the bootstrap execution environment 310. As previously described, the container builder 300 may use the identifier 314 of the received bootstrap execution environment 310 to search for the associated difference including the application dependencies 322 in the data store 150. For example, the container builder 300 may determine that a difference is available from the data store 150 when the difference includes a “tag” (e.g., identifier 314) indicating that the difference was created using the same operating system version and / or the same processor architecture as the remote system 140. A container image (e.g., The container builder 300 may extend the bootstrap execution environment 310 based on application dependencies 322 included in the container image received from the data store 150. The container builder 300 may use the tooling 316 to download the container image from the data store 150 and extend the bootstrap execution environment 310 by installing the application dependencies 322. For example, the container builder 300 may extract the application dependencies 322 from a "tar" file. The ruler 300 may use other techniques to extend the bootstrap execution environment 310 based on the extended execution environment 320.

[0036] In some examples, after extending the bootstrap execution environment 310 during the execution phase 302, the container builder 300 executes the software application 200. Alternatively, the container builder 300 may execute the software application 200 within the bootstrap execution environment 310 to create the application dependencies 322 (i.e., create the extended execution environment 320). In this example, the software application 200 may continue in the extended execution environment 320. In other words, the order of steps / actions of the launch instructions 318, e.g., the steps of creating the extended execution environment 320 and executing the software application 200, may be changed from the example shown.

[0037] 4 provides a flowchart of an example configuration of operations for a method 400 of executing a software application 200 in an application execution environment. The software application may be one of a JavaScript application, a Python application, or a Ruby application. At operation 402, the method 400 includes receiving, at the data processing hardware 144 (e.g., the container builder 300), a bootstrap execution environment 310 from the data store 150. The bootstrap execution environment 310 includes the software application 200, which includes a manifest of dependencies 212. In some implementations, the data store 150 includes a container registry that stores a container image that includes the bootstrap execution environment 310.

[0038] At operation 404, the method 400 includes the data processing hardware 144 executing the bootstrap execution environment 310 to cause the data processing hardware 144 to perform an operation (e.g., by executing startup instructions 318 associated with the bootstrap execution environment 310). At operation 406, the method 400 includes determining whether the extended execution environment 320 is available from the data store 150. For example, determining whether the extended execution environment 320 is available from the data store 150 may include determining whether the extended execution environment 320 is compatible with at least one of the software application 200, an operating system version associated with the bootstrap execution environment 320, or a processor architecture associated with the bootstrap execution environment 320.

[0039] If the extended execution environment 320 is available from the data store 150, the method 400 includes receiving the extended execution environment 320 from the data store 150, at operation 408. After receiving the extended execution environment 320 from the data store 150, the method 400 includes extending the bootstrap execution environment 310 based on the extended execution environment 320, at operation 410. For example, extending the bootstrap execution environment 310 may include installing application dependencies 322 based on the extended execution environment 320. The application dependencies 322 may include, for example, a set of application dependencies 322 that may be associated with a support library 324. The execution environment 320 may include at least one of a library, an architecture-specific binary module, or a module compiled at run time. After extending the bootstrap execution environment 310 based on the extended execution environment 320, the method 400 includes, at operation 416, executing the software application 200.

[0040] If the extended execution environment 320 is not available from the data store 150, the method 400 includes, at operation 412, extending the bootstrap execution environment 310 based on the manifest of dependencies 212 to create the extended execution environment 320. After extending the bootstrap execution environment 310 based on the manifest of dependencies 212 to create the extended execution environment 320, the method 400 includes, at operation 414, storing the extended execution environment 320 in the data store 150. In some implementations, the method 400 also includes the data processing hardware 144 annotating the extended execution environment 320 in the data store 150 to indicate at least one of a version of the software application 200, an operating system version associated with the extended execution environment 320, or a processor architecture associated with the extended execution environment 320. After storing the extended execution environment 320 in the data store 150, the method 400 includes, at operation 416, executing the software application 200.

[0041] 5 is a schematic diagram of an exemplary computing device 500 that may be used to implement the systems and methods described herein (e.g., method 400). Computing device 500 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely exemplary and are not intended to limit the implementation of the invention as described and / or claimed in this document.

[0042] Computing device 500 includes a processor 510 (also referred to as data processing hardware), a memory 520 (also referred to as memory hardware), a storage device 530, a high-speed interface / controller 540 that connects to memory 520 and a high-speed expansion port 550, and a low-speed interface / controller 560 that connects to a low-speed bus 570 and storage device 530. Each of components 510, 520, 530, 540, 550, and 560 may be interconnected using various buses and implemented on a common motherboard or in other manners as desired. Processor 510 can process instructions for execution within computing device 500, including instructions stored in memory 520 or storage device 530, to display graphical information for a graphical user interface (GUI) on an external input / output device, such as a display 580 coupled to high-speed interface 540. In other implementations, multiple processors and / or multiple buses may be used along with multiple memories and types of memories as desired. Also, multiple computing devices 500 may be connected, with each device providing a portion of the required operations (eg, as a bank of servers, as a group of blade servers, or as a multi-processor system).

[0043] The memory 520 stores information non-transiently within the computing device 500. The memory 520 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. The non-transient memory 520 is a physical device used to temporarily or permanently store programs (e.g., sequences of instructions) or data (e.g., program state information) for use by the computing device 500. Examples of non-volatile memory include, but are not limited to, flash memory and read only memory (ROM) / programmable read only memory (PROM) / erasable programmable read only memory (EPROM) / electronically erasable programmable read only memory (EEPROM) (e.g., typically used for firmware such as boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0044] The storage device 530 can provide mass storage for the computing device 500. In some implementations, the storage device 530 is a computer-readable medium. In various different implementations, the storage device 530 may be an array of devices including a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or a device in a storage area network or other configuration. In further implementations, the computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as the methods described above. The information carrier is a computer-readable medium or a machine-readable medium, such as the memory 520, the storage device 530, or a memory on the processor 510.

[0045] The high-speed controller 540 manages bandwidth-intensive operations for the computing device 500, and the low-speed controller 560 manages less bandwidth-intensive operations. Such role assignments are merely exemplary. In some implementations, the high-speed controller 540 is coupled to the memory 520, the display 580 (e.g., through a graphics processor or accelerator), and a high-speed expansion port 550 that may accept various expansion cards (not shown). In some implementations, the low-speed controller 560 is coupled to the storage device 530 and to the low-speed expansion port 590. The low-speed expansion port 590 may accept various communication ports (e.g., USB, Bluetooth, Ethernet, etc.). .net, wireless Ethernet), and may be coupled, for example via a network adapter, to one or more input / output devices such as a keyboard, pointing device, scanner, or a networking device such as a switch or router.

[0046] The computing device 500 may be realized in a number of different forms, as shown in the figure, such as a standard server 500a, or multiple times within a group of such servers 500a, as a laptop computer 500b, or as part of a rack server system 500c.

[0047] Various implementations of the systems and techniques described herein may be implemented in digital electronic and / or optical circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs executable and / or interpretable on a programmable system that includes at least one programmable processor, which may be special purpose or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0048] These computer programs (programs, software, software applications) A programmable program (also known as an instruction or code) contains machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus and / or device (e.g., magnetic disks, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0049] The processes and logic flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic flows may also be implemented by special purpose logic circuitry, for example, an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Processors suitable for executing computer programs include, by way of example, both general purpose and special purpose microprocessors, as well as any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory, or both. The essential elements of a computer are a processor for executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, such as, for example, a magnetic disk, a magneto-optical disk, or an optical disk, or be operatively coupled to receive data from or transfer data to the one or more mass storage devices, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include, by way of example, all forms of non-volatile memory, media, and memory devices, including semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0050] To provide for user interaction, one or more aspects of the present disclosure may be implemented on a computer having a display device, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen, for displaying information to a user, and optionally a keyboard and a pointing device, such as a mouse or trackball, by which a user can provide input to the computer. Other types of devices may also be used to provide user interaction, for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic input, speech input, or tactile input. In addition, the computer may interact with a user by sending documents to and receiving documents from a device used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0051] Although several implementations have been described, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Other implementations are within the scope of the claims.

Claims

1. 1. A computer-implemented method that, when executed on data processing hardware, causes the data processing hardware to perform operations, the operations comprising: receiving a request from a developer device to build an execution environment for a software application developed locally on the developer device, the software application including a manifest of dependencies, the request including an identifier that identifies a storage location of the software application in a data store, the operations further comprising: retrieving the software application from the data store using the identifier; and determining that an associated execution environment does not exist for the software application in the data store; based on a determination that there is no associated execution environment for the software application in the data store; configuring a bootstrap execution environment for the software application using the manifest of dependencies; executing the software application in the bootstrap execution environment to generate an extended execution environment including a set of application dependencies; storing the extended execution environment in the data store; and executing the software application in the enhanced execution environment.

2. 10. The computer-implemented method of claim 1, wherein configuring the bootstrap execution environment for the software application occurs without the use of a configuration file.

3. The computer-implemented method of claim 2 , wherein the configuration file comprises a Docker file.

4. The computer-implemented method of any one of claims 1 to 3, wherein the software application comprises a Ruby application.

5. The computer-implemented method of any one of claims 1 to 3, wherein the software application comprises a Node.js application.

6. The computer-implemented method of any one of claims 1 to 3, wherein the software application comprises a Python application.

7. Retrieving the software application from the data store using the identifier includes: determining that the developer device is authorized to access the software application from the data store; and obtaining the software application from the data store based on determining that the developer device is authorized to access the software application from the data store.

8. The computer-implemented method of any preceding claim, wherein the manifest of dependencies includes one or more software libraries for the software application.

9. The computer-implemented method of any one of claims 1 to 8, wherein executing the software application in the extended execution environment comprises executing the software application on a remote system.

10. The computer-implemented method of any preceding claim, wherein the data store includes a container registry.

11. 1. A system comprising: Data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed by the data processing hardware, cause the data processing hardware to perform operations, the operations including: receiving a request from a developer device to build an execution environment for a software application developed locally on the developer device, the software application including a manifest of dependencies, the request including an identifier that identifies a storage location of the software application in a data store, the operations further comprising: retrieving the software application from the data store using the identifier; and determining that an associated execution environment does not exist for the software application in the data store; based on a determination that there is no associated execution environment for the software application in the data store; configuring a bootstrap execution environment for the software application using the manifest of dependencies; executing the software application in the bootstrap execution environment to generate an extended execution environment including a set of application dependencies; storing the extended execution environment in the data store; and executing the software application in the enhanced execution environment.

12. The system of claim 11 , wherein configuring the bootstrap execution environment for the software application occurs without the use of a configuration file.

13. The system of claim 12 , wherein the configuration file comprises a Dockerfile.

14. The system of any one of claims 11 to 13, wherein the software application comprises a Ruby application.

15. The system of any one of claims 11 to 13, wherein the software application comprises a Node.js application.

16. The system of any one of claims 11 to 13, wherein the software application comprises a Python application.

17. Retrieving the software application from the data store using the identifier includes: determining that the developer device is authorized to access the software application from the data store; and obtaining the software application from the data store based on determining that the developer device is authorized to access the software application from the data store.

18. The system of any one of claims 11 to 17, wherein the manifest of dependencies includes one or more software libraries for the software application.

19. The system of any one of claims 11 to 18, wherein executing the software application in the extended execution environment comprises executing the software application on a remote system.

20. The system of any one of claims 11 to 19, wherein the data store includes a container registry.

21. A program causing said data processing hardware to carry out the method according to any one of claims 1 to 10.

Images