This glossary lists Apcera terms or general terms that are especially relevant to Apcera.
An inline policy decision that applies only to hooks.
The command line interface (CLI) tool for interacting with Apcera. See Installing and Using APC.
An association between a job and a service that allows the job to reach specific instances of the service. Service gateways maintain the information necessary to construct bindings. Also known as Service Binding.
A type of isolation context that can be treated as a traditional server.
The origin or destination of network traffic using a specified protocol. An endpoint corresponds to a URL (for example,
tcp://18.104.22.168:123) and is associated with some sort of service or other functionality.
An operation specific to a given protocol. For example, for databases there are events for each SQL command (
UPDATE, and so forth).
Custom code that acts as an endpoint for queries from a semantic pipeline. Any request going from a client to a service is subject to event handlers. The latter can optionally be constrained to certain protocol-specific event types. Hooks and notifications are types of event handlers.
Everything in an Apcera cluster, including jobs, services, and packages, has a fully-qualified name (FQN). An FQN contains a resource type, a namespace, and a local name, in the following format:
resource type::/namespace::local name
- Resource type identifies the type of object.
- Namespace provides a means of identifying an area for policy and permission control.
- Local name identifies the resource within the namespace.
An authoritative event that is invoked synchronously. It influences the decision to pass a request. Specify a hook in one of the following ways:
- Static (inline), also called an action.
- As a URL. The hook returns whether or not to proceed to the next hook as a
A job running on an Instance Manager node in an Apcera cluster. Also known as Job Instance.
An Instance Manager (IM) is an Apcera component that is responsible for running job instances. A production cluster contains two or more IMs, each running on a separate node in the cluster. Apcera balances the load for traffic to the cluster using random selection of IMs.
A container that isolates individual jobs (services, applications, stagers, semantic pipelines, service gateways) from other jobs running in the cluster. Isolation includes CPU, memory, file system, and visibility on the network. There is no outside access to or from an isolation context unless it is allowed by policy. Routes are added to an isolation context to allow ingress to services and are paired with bindings to allow egress from an isolation context.
A fundamental unit of work in Apcera. Every application, service, stager, semantic pipeline and service gateway running in Apcera is a job.
A connection between jobs using a URI that is managed and secured by Apcera. Also known as Job Link. Contrast with a binding, which connects a job to a service.
A JSON file that includes the start path, start command, dependencies, provides, and environment variables for a package.
environment - Specifies the environment variables that apply in the runtime environment.
dependencies - Resources that the package depends upon, based on the combination of type (such as operating system) and name (such as Linux).
provides - Specifies capabilities that this package is blessed to provide to the system ("blessed" indicates that the package is available to be referenced by packages that seek capabilities of the given type and name).
An object describing the methods presented by a service gateway to enable Apcera to automatically discover the service's functionality. Refer to the Service Gateway API for details.
A description of the policy group that a user, permission, and so forth belongs to. Namespaces can be set locally for each user and are used when setting policy permissions. Namespaces are neither created nor deleted. This means that jobs, packages, etc. can be created in any namespace which is allowed by policy. Namespaces are integral to configuring the behavior of a cluster and the jobs running in that cluster.
A non-authoritative event that is invoked asynchronously. It does not influence the connection to the service. Notifications are always handled by URLs.
A collection of binary data and metadata that make up an application or service (for example, the Ubuntu operating system, the Java runtime, a Capsule snapshot, a Ruby on Rails application, or a Bash script).
Binary data: Apcera determines at runtime if the data is gzip'd, bzip'd, or an uncompressed tar file.
Metadata: A JSON file that includes dependencies, provides, environment variables, and other information.
An aggregate expression of "who can do what to what" within Apcera. Method by which governance and security are enforced across the cluster.
Library embedded in each Apcera component to evaluate and execute policy.
A statement evaluated by the Policy Engine.
A service gateway's representation of the functionality it provides (for example, PostgreSQL server, Redis server, Memcache pool, Salesforce API).
A routable address – from inside or outside the Apcera cluster – that needs access to an isolation context. Routes allow inbound traffic to reach a specific port on which a job's process has a server listening.
Resource or set of resources to which a policy rule applies to. The scope of a realm can be:
- All resources of a type in the cluster (job::/)
- All resources of a type in a namespace (job::/name/space)
- An individual resource (job::/name/space::job/name)
A directive specifying that an event handler be deployed to a semantic pipeline. Rules are associated with a given service or service resource, and are deployed to all semantic pipelines that mediate access to the protected service or service resource.
A job that mediates service connections through awareness of wire protocol semantics. Access to any service can be configured to require a semantic pipeline. Apcera clusters can have multiple semantic pipelines.
A specific instance of a backend to which jobs may request bindings. A service backend can be external to Apcera or running inside it.
A job that configures connections between services and jobs.
A file-based snapshot of the state, disk data, and configuration of an isolation context at a specific point in time.
System-provided background component that is used to deploy and update sytem-provided jobs and resources.
An executable (job) that processes a package after it is uploaded to the system. Staging tasks can include compilation, bundling, checking and installing dependencies, unit testing, and virus scanning.
Applying a staging pipeline (series of stagers) to a package uploaded to the system. Runtime-specific staging tasks include compiling an application, downloading its dependencies, updating its configuration files, and specifying start commands.
A job that interacts with each of the individual stagers once an application package is uploaded. The staging coordinator URL is passed to the stager via the STAGER_URL environment variable. The stager interacts with the staging coordinator over HTTP.
A list of stagers that run in a specified order when deploying any application or service.
The cluster URL to which your apps and services will be deployed.
Your target is:
The web console is the web interface for managing your Apcera implementation. Each cluster provides a unique web console instance for interacting with the jobs, resources, and policies in that cluster.