Implementing Services

This section lists and describes the supported service types, and provides considerations for implementing services.

Apcera-provided service types

This section lists the service gateways provided by Apcera.


As supplied Apcera provides the following service types and gateways, configuration options, and semantic pipelines for integrating your apps with other applications and systems. Follow the link for the service type for details on how to implement that service.

Type Description Provider Required Semantic Pipeline Options
generic Generic service gateway for integrating external systems using a generic connection. No No nil
gnatsd Connect to NATS Server. No No nil
http Direct internet connection over HTTP using a semantic pipeline. No Yes nil
ipm IP Manager service gateway responsible for static IP services. Yes No ip
memcache Memcached caching service gateway. No Yes nil
mongodb MongoDB service gateway. No No persistence_provider
mysql MySQL database service gateway. Yes Yes database
network Service gateway to enable network egress from behind container firewall. No No domainname, ipnet, ipnets, protocol, portrange
nfs File share services using NFS. Yes No shared, version
postgres PostgreSQL database service gateway. Yes Yes database
rabbitmq RabbitMQ service gateway. No No persistence_provider
redis Redis key-value store service gateway. No Yes persistence_provider
s3 Amazon S3 service gateway. Yes No nil
smb SMB service gateway. Yes No shared


Apcera also provides custom service gateways that you can easily implement:

Type Description Provider Required Semantic Pipeline Options
ldap LDAP/S service gateway implementation using the Generic service gateway. Yes No nil
oracle Oracle custom serivce gateway implementation for integrating with Oracle DB. Yes No nil


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

Verifying service infrastructure

To view the available service gateways in your cluster, run the following APC command:

apc gateway list -ns /
Working in "/"
│ Name     │ Type     │ Namespace                │ Status  │ Instances │
│ generic  │ generic  │ /apcera/service-gateways │ started │ 1/1       │
│ gnatsd   │ gnatsd   │ /apcera/service-gateways │ started │ 1/1       │
│ http     │ http     │ /apcera/service-gateways │ started │ 1/1       │
│ ipm      │ ipm      │ /apcera/service-gateways │ started │ 1/1       │
│ memcache │ memcache │ /apcera/service-gateways │ started │ 1/1       │
│ mongodb  │ mongodb  │ /apcera/service-gateways │ started │ 1/1       │
│ mysql    │ mysql    │ /apcera/service-gateways │ started │ 1/1       │
│ network  │ network  │ /apcera/service-gateways │ started │ 1/1       │
│ nfs      │ nfs      │ /apcera/service-gateways │ started │ 1/1       │
│ postgres │ postgres │ /apcera/service-gateways │ started │ 1/1       │
│ rabbitmq │ rabbitmq │ /apcera/service-gateways │ started │ 1/1       │
│ redis    │ redis    │ /apcera/service-gateways │ started │ 1/1       │
│ s3       │ s3       │ /apcera/service-gateways │ started │ 1/1       │
│ smb      │ smb      │ /apcera/service-gateways │ started │ 1/1       │

You can also view the list of service gateways using the web console:


To verify the available semantic pipelines in your cluster:

apc pipeline list -ns /
Working in "/"
│ Name     │ Type │ Namespace                  │ Status │
│ http     │ job  │ /apcera/semantic-pipelines │ ready  │
│ memcache │ job  │ /apcera/semantic-pipelines │ ready  │
│ mysql    │ job  │ /apcera/semantic-pipelines │ ready  │
│ postgres │ job  │ /apcera/semantic-pipelines │ ready  │
│ redis    │ job  │ /apcera/semantic-pipelines │ ready  │

The following screenshot shows system-provided semantic pipelines as viewed in the web console.


Note the service gateways are in the started state, whereas the semantic pipelines are in the ready state (not started). When you bind a type of service to a job for which a semantic pipeline is available, an instance of the matching semantic pipeline is created and attached to the bound job.

Service persistence considerations

Service gateways come in different flavors or tiers. Some services require backend providers, other services connect to server instances running as jobs in the system.

In production you will likely run database providers externally, such as PostgreSQL RDS on AWS. Apcera may install servers for IPM and NFS in your cluster as system components. In production you can run a NFS cluster for HA.

The backends for some service types run as job instances in the system, such as MongoDB, RabbitMQ, and Redis. Since job (container) instances are ephemeral, you can use the persistence_provider option to back these server jobs with a NFS persistence layer.

You can create your own database jobs in the system. There are various ways to do this:

Once the job is created, you can bind it to the APCFS NFS provider for persistence and then register the job as a service gateway.

With the 2.2.0 release you can use the SMB service gateway to connect jobs to an external SMB server for data storage.

Semantic pipeline considerations

As indicated in the above table, Apcera provides semantic pipelines for several of the supported service types. Semantic pipeline selection is determined by the service gateway type used to create the service.

For example, when you bind a job to a service that was created with the mysql service gateway an instance of the MySQL semantic pipeline is created to broker the connection between the job and the MySQL instance.

If you want to connect a job to an existing MySQL database (not one created for you by the mysql service gateway) you can use the Generic Service Gateway:

apc service create mydb --type generic -- --url "mysql://user:pass@"

However, in this case, no semantic pipeline is created to broker the connection to the MySQL instance, and therefore the credentials provided to jobs bound to the service are the actual credentials, not ephemeral credentials.