Using a9s MongoDB

This topic describes how to use a9s MongoDB .

Use a9s MongoDB with an Application

To use a9s MongoDB with an application, create a service instance and bind the service instance to your application. For more information on managing service instances, see Managing Service Instances with the cf CLI.

View the a9s MongoDB Service

After the service is installed, you can see the a9s-mongodb and its service plans appear in your CF marketplace. Run cf marketplace to see the service listing:

$ cf marketplace
Getting services from marketplace in org test / space test as admin...
OK
service      plans                                           description
a9s-mongodb  mongodb-single-small, mongodb-cluster-small,    This is the a9s MongoDB 32 service.
             mongodb-single-big, mongodb-cluster-big

Create a Service Instance

To provision a MongoDB database, run cf create-service. For example:

$ cf create-service a9s-mongodb mongodb-single-small my-mongodb-service

Depending on your infrastructure and service broker utilization, it may take several minutes to create the service instance.

Run the cf services command to view the creation status. This command displays a list of all your service instances. To view the status of a specific service instance, run cf service NAME-OF-YOUR-SERVICE.

Bind an Application to a Service Instance

After your database is created, run cf bind-service to bind the service to your application:

$ cf bind-service a9s-mongodb-app my-mongodb-service

Restage or Restart Your Application

To enable your application to access the service instance, run cf restage or cf restart to restage or restart your application.

Obtain Service Instance Access Credentials

After a service instance is bound to an application, the credentials of your MongoDB database are stored in the environment variables of the application. Run cf env APP-NAME to display the environment variables.

You can find the credentials in the VCAP_SERVICES key.

$ cf env a9s-mongodb-app
Getting env variables for app a9s-mongodb-app in org test / space test as admin...
OK

System-Provided:
{
 "VCAP_SERVICES": {
  "a9s-mongodb": [
   {
    "credentials": {
     "default_database": "d22906",
     "hosts": [
      "EXAMPLE-HOST"
     ],
     "password": "EXAMPLE-PASSWORD",
     "uri": "EXAMPLE-URI",
     "username": "EXAMPLE-USERNAME"
    },
    "label": "a9s-mongodb",
    "name": "my-mongodb-service",
    "plan": "mongodb-single-small",
    "tags": [
     "nosql",
     "database",
     "document store",
     "eventual consistent"
    ]
   }
  ]
 }
}
...

You can use the host, username and password values to connect to your database with a MongoDB client.

Best Practices

There are some best practices for using service binding information in apps in a separate document.

Delete an a9s MongoDB Service Instance

WARNING: Before deleting a service instance, you must backup data stored in your database. This operation cannot be undone and all the data is lost when the service is deleted.

Before you can delete a service instance, you must unbind it from all apps.

List Available Services

Run cf services to list your available services.

$ cf services

Getting services in org test / space test as admin...
OK

name                 service       plan                   bound apps        last operation
my-mongodb-service   a9s-mongodb   mongodb-single-small   a9s-mongodb-app   create succeeded

This example shows that my-mongodb-service is bound to the a9s-mongodb-app application.

Unbind a Service Instance

Run cf unbind-service to unbind the service from your application.

$ cf unbind-service a9s-mongodb-app my-mongodb-service

Delete a Service Instance

After unbinding the service, it is no longer bound to an application. Run cf delete-service to delete the service:

$ cf delete-service my-mongodb-service

It may take several minutes to delete the service. Deleting a service deprovisions the corresponding infrastructure resources. Run the cf services command to view the deletion status.

Upgrade the Service Instance to another Service Plan

Once created, you can upgrade your service instance to another, larger service plan. A larger service plan provides more CPU, RAM and storage. For more information, see the Update a Service Instance of the Managing Service Instances with the cf CLI topic.

$ cf update-service my-mongodb-service -p a-bigger-plan

Here are the plans you can upgrade to depending on the one you are currently using:

  • If you are currently using the mongodb-single-small plan, you can upgrade to the mongodb-single-big plan.

  • If you are currently using the mongodb-cluster-small plan, you can upgrade to the mongodb-cluster-big plan.

Add a Graphite Endpoint

If you want to monitor your service with Graphite, you can set an endpoint to where to information will be sent with the cf update-service command. This command expects the -c flag and a JSON string containing the graphite and metrics_prefix keys. Depending on your graphite provider the metrics_prefix might require that each metrics must start with an API key in their name. You can also change the interval within the data is send to the endpoint. Do to this modify interval the default is 10s.

$ cf update-service my-mongodb-service -c '{ "graphite": ["yourspace.your-graphite-endpoint.com:12345"], "metrics_prefix": "your-api-key.my-cluster-mongodb", "interval": "5"}'

Add a Syslog Endpoint

The cf update-service command used with the -c flag can let you stream your syslog to a third-party service. In this case, the command expects a JSON string containing the syslog key. You can also change the interval for the syslog with the same key than for the graphite endpoint interval.

$ cf update-service my-mongodb-service -c '{ "syslog": ["logs4.your-syslog-endpoint.com:54321"], "interval": "5" }'

Cloud Foundry Application Security Groups

This topic describes how to check whether a security group was created.

Each a9s Data Service will automatically create and update Cloud Foundry security groups in order to protected service instances to be accessed by applications not running in the same Cloud Foundry applications space. To get a better understanding about Security Groups you can have a look on the Understanding Application Security Groups topic.

Get Service Instance GUID

Run cf service INSTANCE_NAME --guid to get the guid of the service instance.

$ cf service my-mongodb --guid
ca16f111-5073-40b7-973a-156c75dd3028

Check available Security Groups

To see all available security groups use cf security-groups.

$cf security-groups
Getting security groups as demo@anynines.com
OK

     Name                                         Organization     Space
#0   public_networks
#1   dns
#2   tcp_open
#3   guard_432fb752-876d-443b-a311-a075f4df2237   demonstrations   demo
#4   guard_ca16f111-5073-40b7-973a-156c75dd3028   demonstrations   demo

There we can see a security group with the named guard_ca16f111-5073-40b7-973a-156c75dd3028 was successfully created.

NOTE: in some circumstances the connection between the application and the service instance is not possible, in this case check if a security group was created.

Backup and Restore Service Instances

a9s MongoDB provides an easy way to create backups and restore if needed. For a more detailed description, please see the a9s Service Dashboard documentation.

Make a Service Instance Locally Available

It is possible to access any of the a9s Data Services locally. That means you can connect with a local client to the service for any purpose such as debugging. CF provides a smart way to create SSH forward tunnels via a pushed application. For more information about this feature see the Accessing Apps with SSH section of the CF documentation.

First of all you must have an application bound to the service. How to do this see Bind an Application to a Service Instance.

NOTE: cf ssh support must be enabled in the platform. Ask your administrator if you are not sure.

Get The Service Url and Credentials

When you follow this instructions Obtain Service Instance Access Credentials you will get the hostname of the service and the user credentials.

$ cf env a9s-mongodb-app
Getting env variables for app a9s-mongodb-app in org test / space test as admin...
OK

System-Provided:
{
  "VCAP_SERVICES": {
   "a9s-mongodb": [
    {
      "credentials": {
       "host": [
        "d67901c.service.dc1.a9svs"
       ],
       "password": "a9s-brk-usr",
       "username": "a9s-password"
     },
     "label": "a9s-mongodb",
     "name": "my-mongodb-service",
     "plan": "mongodb-cluster-small"
    }
   ]
  }
}
...

Notice the host d67901c.service.dc1.a9svs, the username a9s-brk-usr and the password a9s-password. You will need this in the next step.

Create a Tunnel to The Service

With the cf ssh as mentioned before you can create a ssh forward tunnel to the management dashboard. Use port 27017 to connect to the a9s MongoDB Instance.

$ cf ssh a9s-mongodb-app -L 27017:d67901c.service.dc1.a9svs:27017
vcap@956aaf4e-6da9-4f69-4b1d-8e631a403312:~$

When the ssh tunnel is open you can access the instance over the address localhost:27017.

NOTE: Don't forget to close the session with exit.

Service keys

To gain access to the service manually rather than binding apps to it you can use service keys.

Creating a service key

To create a key to the service instance mongodb1 call nykey run:

cf create-service-key mongodb1 mykey

Listing service keys

To list all the keys for the mongodb1 service instance run this:

cf service-keys mongodb1

Accessing service keys

To obtain the key mykey from the mongodb1 service instance run:

cf service-key mongodb1 mykey

Deleting service keys

To delete a service key mykey from the service instance mongodb1 run:

cf delete-service-key mongodb1 mykey

Creating a Fork of a Service Instance

The procedure of forking a service instance involves creating a backup of a service instance, modifying the backup a bit, and restoring it to a different service instance. This can also be used to migrate to a newer MongoDB version. For a migration, it is recommended to make sure that no new data is written into MongoDB during the procedure (e.g. stop the app bound to it prior to starting with these steps).

For this process you will need a service instance you want to fork, and a new service instance(s) you want to fork to. For help creating new service instances look at the Create a Service Instance section. You can get a list of all of your a9s-mongodb service instances by running the following:

cf s | grep a9s-mongodb

The output should be a table of your a9s-mongodb instances:

mongodb1   a9s-mongodb34   mongodb-nano                create succeeded
mongodb2   a9s-mongodb34   mongodb-nano                create succeeded

In this guide we will be forking from mongodb1 to mongodb2.

Now, you have established which service instances you will be operating on, you will need service keys. For information on creating, obtaining and managing service keys see the Service keys section.

The next thing to do is to log into the service instance dashboard to set the encryption password (if it hasn't already been set and create a backup. To find your dashboard URL, for the instance you want to fork from (mongodb1 in this example), run this:

cf service mongodb1 | grep -E '^|dashboard:.*' --color='always'

Then log into the dashboard using your Cloud Foundry credentials.

Make sure you set a encryption password for the backups using the service instance dashboard (Change Backup Settings). Create a backup using the dashboard. Download the backup to your local machine. The filename will be something like racsd92baee-1522222422893. Decrypt the backup and write its contents to a file:

$ cat racsd92baee-1522222422893 | openssl enc -aes256 -d -pass 'pass:mytopsecretpassword' | gunzip -c > backup.tar

For the next steps you will need the MongoDB tools. You can install them by following the official MongoDB installation manual.

To upload the backup to the new fork service instance you will need to create a tunnel, for port 27017, using and app bound to the new service instance. As you are creating a new instance, that you likely don't want connected to production until it has the data, its advisable to deploy a small demo app for tunneling through (you can dispose of it later). A small app can be found here https://github.com/anynines/simple_node_mongo_example , you will need to edit the manifest, then follow the section Make a Service Instance Locally Available.

Before the backup data can be restored you must extract it.

tar -vxf backup.tar

Extracting the backup will create a folder that contains the files needed for the restore. You will see the folder name with the output from the tar command. The folder name will look something like racsd92baee-1522222422893.

To run the restore you will need the credentials for the service instance that will become a fork. In this example the credentials can be found like this:

cf service-key mongodb2 mykey

Then carry out the restore.

Single

$ mongorestore --uri="mongodb://<username>:<password>@localhost:27017/<default_database>" \
--gzip --archive=<output-file>.gz --nsInclude='<original-default_database>.*' \
--nsFrom='<original-default_database>.*' --nsTo='<default_database>.*'

Example:

$ mongorestore --uri="mongodb://a9s-brk-usr-733e61a812ea27627f991d91f4a6b48db5631294:a9se1d35f1466318718cb508be4856d33631fd8c4b9@localhost:27018/mod94cfad" \
--gzip --archive=/tmp/mydump.gz --nsInclude='mod3ce8d.*' --nsFrom='mod3ce8d.*' --nsTo='mod94cfad.*'

If this is an SSL instance, remember to add the SSL options:

$ mongorestore --uri="mongodb://<username>:<password>@localhost:27017/<db-name>" \
--gzip --archive=<output-file>.gz --nsInclude='<original-default_database>.*' \
--nsFrom='<original-default_database>.*' --nsTo='<default_database>.*' --ssl \
--sslAllowInvalidCertificates

For information on restoration commands see the Official MongoDB documentation.

Cluster

Due to the way backups are created on a cluster, it is necessary to have SSH access to the virtual machine.

Stop the secondary instances and then the primary. Cleanup the data directory on all instances, and copy the backup.tar file inside the primary, after that extract it to the data directory and start the services:

# rm -rf /var/vcap/store/mongodbXX/*
# cat backup.tar | tar  -x -C /var/vcap/store/mongodbXX
# rm -f /var/vcap/store/mongodbXX/mongod.lock
# monit start all

After starting the primary, start all secondary nodes.

Your data has now been restored from one service instance to another. Don't forget to close your ssh tunnel and clean up any temporary app instances, no longer required keys...

Setup Disk Usage Alerts

Each service comes with the a9s Parachute. This component monitors ephemeral and persistent disk usage. See the a9s Parachute documentation how to configure the component.

Enable AppDynamics support

This feature is disabled by default. You can ask your operator to enable this feature for your service instance. When enabled, any user created in the MongoDB instance will have the required privileges as described here.

Any service binding (cf bind-service) created before AppDynamics support was enabled will have to be re-created (execute cf unbind-service followed by cf bind-service). This is due to the fact the CloudFoundry currently does not support implementing logic that will automate this process.