Working with Services

Many jobs running in Apcera rely on services provided by other programs. Apcera implements the client/server connection in such a way as to orchestrate and govern the entire system most effectively.

This section describes Apcera concepts and features for working with services, including:

Services overview

The basic client/server model calls for a connection between client and server. To an Apcera job this connection is always via a URI. When you establish a connection between a job and a service, Apcera supplies the job with a URI, which the job uses to communicate with the service according to the service's usual protocol. Connections to services that Apcera supports are implemented in a variety of ways.

Some services use providers. A provider is a specific resource at a specific location, such as a multi-tenant PostgreSQL database server on a specific machine, possibly outside the Apcera cluster.

For some services that do not use providers, Apcera creates a job to represent the service. This is the case, for example, with Memcache and Redis. Other services may be SaaS software hosted outside of Apcera accessible at a specific URI.

For some types of services, the URI provides unmonitored traffic between the job and a service. For other supported types of services, Apcera provides semantic pipelines.

Service gateways

Every service in Apcera has a service type, which serves as an index to a set of jobs called service gateways. Apcera provides the Service Gateway API for designing service gateways, but Apcera also supplies service gateways for many common service types (for example, MySQL, PostgreSQL, Redis, and Memcache) and for web services accessible via URIs.

Whenever you create a service, Apcera calls on the service gateway that corresponds to the service type. The service gateway provides the job with an appropriate URI and applies any rules that you give it. For example, when you create a service that provides network access, the service gateway applies rules you specify about which IP addresses a job bound to it can access.

The service gateway also informs Apcera what protocol the service requires. Apcera uses this information to determine whether it has a semantic pipeline for that protocol. After that, the service gateway has no further role in the connection.

Service bindings

A service is a representation within Apcera that a job can bind to. A connection between a job and a service is called a binding. The binding is specific to that job and service. Both the job and the service are subject to policies, and both policies must allow the connection in order for Apcera to create a binding.

To connect a job with a service, you first create a service of the appropriate type. The actual server may already exist somewhere, but you create an Apcera representation of it to connect to.

If the type of service uses a provider, you specify the provider to ensure that you connect to the correct location. For example, an Apcera cluster might have more than one registered provider of type postgres. To create a service of type postgres, you must specify which provider to use.

If the type of service does not use providers, you must specify the service type.

Dynamic binding

A service binding is represented as an environment variable whose value is a URI. The service binding URI is generated by an associated service gateway. The binding URI is a metadata decorated connection string that generally takes the following form:

protocol-scheme://username:password@hostname_or_IP:port/resource

Depending on the type of service and binding, the URI that the job uses points to one of the following:

  • The server, directly.

  • A job that the first job interacts directly with to obtain services.

  • An intermediary, or proxy, called a semantic pipeline, which understands the protocol reported by the service gateway and enables Apcera to regulate what passes between the job and the server.

The second and third of these bindings are dynamic. Their targets are within Apcera, which remaps them automatically if the targets move. This enables invisible and seamless scaling, load balancing, and replacement of failed components.

See Exploring service bindings for a tutorial on service bindings.

Service providers

Some services come from providers. Providers typically supply services like accounts on multi-tenant database servers or software as a service (SaaS) applications. They enable end users to provision services on demand.

In Apcera, a provider is an entity consisting of a resource and an endpoint (for example, the PostgreSQL database server on the Ubuntu machine called gandalf). Typically, an organization's IT administrators identify providers and register them with Apcera, which keeps a registry of providers.

Each provider has a service type and hence a service gateway. See Working with Providers.

Semantic pipelines

Whether the service uses a provider or not, Apcera can establish a semantic pipeline for supported protocols, that is, a job that filters traffic between the job and the service to enforce policies and to protect security credentials from accidental exposure. A semantic pipeline is tied to a specific protocol and understands the meaning of traffic using that protocol. It enforces the policies you define for interactions of that type. Thus, for example, the HTTP semantic pipeline can allow GETs and disallow PUTs. Or it can allow access to Facebook and deny access to Wikipedia.

See Working with Semantic Pipelines.

Starting with Apcera release 2.4, you can disable automatic semantic pipeline generation using policy. See disabling semantic pipelines for details.

Ephemeral credentials

An important aspect of connections through semantic pipelines is the way they handle the credentials that enable the job to access the server. Apcera performs credential remapping within the semantic pipeline. Apcera maintains the actual credentials and does not expose them to jobs. The credentials the job receives as part of the binding URI are specific to that job and binding. If the job inadvertently exposes them, little harm can come of it, because they are unrelated to the actual credentials. They are meaningful only to Apcera, and Apcera accepts them only from the job to which they were issued.

Not all semantic pipelines provided by Apcera support credential remapping. Typically, services with a single, well-defined authentication mechanism (username and password, for example) are good candidates, while those that support a variety of authentication mechanisms (such as HTTP) are not. Of the semantic pipelines provided by Apcera, the MySQL, PostgreSQL, and Redis semantic pipelines support ephemeral credentials; the HTTP and Memcache semantic pipelines do not.

Supported service types and gateways

There is a one-to-one correspondence between service type and service gateway. All services require the use of a service gateway. In addition, Apcera provides semantic pipelines for certain protocols supported by service gateways. See Supported Service Types for a complete list of service types and gateways.

If you want to use a service type not provided by default by Apcera, you can use the Service Gateway API to create a service type supporting the service you want to use. Apcera can handle the new service within its existing facilities.