Is It Time To Rethink Running your Database In Docker?

kubernetes-illustration-4b2As long as Docker has existed, developers have been using it to run databases in development mode.  But once you get past development and test, the database experts have quickly crushed any thoughts of running containerized databases in production.  Why?  A variety of reasons: the vendor doesn’t support or endorse (or allow) it; DBAs don’t trust it; the storage is volatile; it’s faster and more stable on physical or dedicated virtual nodes; and so on.  These are all common and not irrational objections to containerizing your database.  But one vendor appears to be daring to go there: Couchbase has recently released the first version of the Couchbase Autonomous Operator for Kubernetes.  This means that a commercial database vendor sees the value of containers and kubernetes and wants to help you make it happen.

What is it?

The CouchbaseAutonomous Operator for Kubernetes (operator) is a vendor-supported way of running your database in kubernetes.  It provides support for many (not all at this point) management functions in the operator.  This means things like failover, rebalance, bucket creation, cluster topology, etc. are managed by the operator.  You simply tell it what you want, and the operator takes care of how to make that happen.  Now you can have your database by specification, rather than manual or even automated configuration.

Why is it important?

One reason this is so important is that Couchbase is taking the lead on supporting databases inside containers and kubernetes.   Other database vendors have been reluctant to support or endorse containerization.  This has led to reluctance by database architects to attempt to place their databases in containers or inside kubernetes, despite the fact that kubernetes and docker both provide significant value in ease of management, scaling and portability.  Lack of endorsement by the vendor tells the experts to stick with dedicated VMs or physical nodes.  We should note that performance will always be best in this case.  But scalability and ease of management can offset this when looking at total cost of ownership.

How does it work?

Let’s take a look at a simple specification for your cluster, expressed in YAML.

kind: CouchbaseCluster
  name: cb-demo
  namespace: cboperator
  baseImage: couchbase/server
  version: enterprise-5.5.2
  authSecret: cb-demo-auth
  exposeAdminConsole: true
    - data
    dataServiceMemoryQuota: 256
    indexServiceMemoryQuota: 256
    searchServiceMemoryQuota: 256
    eventingServiceMemoryQuota: 256
    analyticsServiceMemoryQuota: 1024
    indexStorageSetting: memory_optimized
    autoFailoverTimeout: 120
    autoFailoverMaxCount: 3
    autoFailoverOnDataDiskIssues: true
    autoFailoverOnDataDiskIssuesTimePeriod: 120
    autoFailoverServerGroup: false
    - name: bucket1
      type: couchbase
      memoryQuota: 128
      replicas: 1
      ioPriority: high
      evictionPolicy: fullEviction
      conflictResolution: seqno
      enableFlush: true
      enableIndexReplica: false
    - name: bucket2
      type: couchbase
      memoryQuota: 128
      replicas: 1
      ioPriority: high
      evictionPolicy: fullEviction
      conflictResolution: seqno
      enableFlush: true
      enableIndexReplica: false
    - size: 3
      name: all_services
        - data
        - index
        - query
        - search
        - eventing
        - analytics

You can see where we are telling kubernetes (and the operator running there) what version of Couchbase to deploy (lines 6 and 7), what username and password to use for the administrator (stored in a secret, line 9) and whether to expose the administration console (line 10).  Lines 13 through 24 set the memory options and other cluster-wide settings.  Next, we define 2 buckets (bucket1 and bucket2) in lines 25-43, setting type, replica count, etc.  Finally (lines 44-53), we outline the multi-dimensional scaling for our cluster.  In this case we simply have 3 nodes, each running the data, index, query, search, eventing and analytics services.  We could easily split these out into separate sets of services.

We deploy this into kubernetes using the cbopctl utility.  cbopctl works much like kubectl, but only has 3 verbs: create, apply and delete.  Using create, we can create our cluster by supplying the file name: cbopctl create -f mycluster.yml.  Once complete, we’ll have 3 pods running Couchbase (with the services listed in the YAML file). We can then edit the YAML file, and apply the changes.  So we could add a bucket and create another server group just for eventing and analytics.  The operator would then update the cluster for us (cbopctl apply -f mycluster.yml), picking and applying the correct set of Couchbase operations needed to bring the cluster into compliance with the YAML specification.

Also note, if you change the settings via the admin console, the operator will undo your work, since it must comply with your specification.

Once your cluster is running, you can find the admin console port with this command: kubectl -n cboperator describe cbc | grep  “Admin Console Port SSL:”, then access it on your cluster’s IP address.


It’s time to rethink whether your data can be managed in containers (especially for kubernetes).  Vendors are starting to release “official” docker images and Couchbase has one-upped them by creating their autonomous operator.  Give it a test run and see what you think.  Comments welcome.

Also check out Couchbase’s webinar covering the operator.

NOTE: Sign up here for Avalon’s DevOps mailing list to receive timely notification when we publish tips, tricks, and videos related to increasing your success with DevOps initiatives.

Sean Dowd is VP and Chief Architect at Avalon Consulting, LLC where he focuses on apps dev, open source, automation and enterprise architecture.  He has over 25 years experience in enterprise applications development and management.


About Sean Dowd

Sean Dowd is VP and Chief Architect at Avalon Consulting, LLC.

Leave a Comment