A step runtime is made up of the following components:
Nodes: To run any step in a pipeline, you need a build node (a virtual machine) where the step will execute. An administrator user must provide nodes and attach them to Pipelines in the JFrog Platform Deployment. A node can be on any infrastructure that you choose to use, whether it is from a cloud provider (such as AWS, GCP, or Azure), or on your own infrastructure if your security policies require your operations to remain behind your own firewall.
Node Pools: Node Pools logically group nodes to make them available to execute the steps in a pipeline. This enables an administrator user to group nodes according to their processor architecture and baseline operating system. It enables pipelines to run on specific node pools, and to run steps simultaneously on different build nodes. Node pools can contain nodes of two distinct types:
Static Nodes: Static nodes are configured and provided by administrator users to a node pool. They operate in perpetuity, and are available to execute steps at any time. Static nodes are especially useful if you need to run your operations on build nodes in your own data center. You may need to do this if you have security policies that prohibit your code from leaving your firewall, or if your jobs require access to internal resources that are not accessible from the internet. You can also attach build nodes from a cloud provider, although you will incur charges even when the build node is idle.
Dynamic Nodes: Dynamic nodes are on-demand compute environments that are spun up on a cloud provider when needed, and destroyed when seen to be idle. This is an efficient method that helps minimize compute costs. Dynamic nodes are connected through a dynamic node integration that connects to an IaaS provider such as Amazon or Google.
Runtime Images: A runtime image is a preconfigured Docker image that includes all the necessary components and settings to run your pipeline steps in a container.