Implementing Services

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

• Apcera-provided service types
  • Default
  • Custom
  • API
• Verifying service infrastructure
• Service persistence considerations
• Semantic pipeline considerations

Apcera-provided service types

This section lists the service gateways provided by Apcera.

Default

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.

Custom

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

API

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:

• Create a Postgres service from an Apcera Package
• Create a MySQL service from a Docker image
• Create a MySQL service from an Apcera Capsule

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@192.168.10.28:3306/db_name"

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.