docs/sections/blueprints/PGaaS.rst

   1 PostgreSQL as a Service
   2 ============
   3
   4 PostgreSQL as a Service comes in two flavors: all-in-one blueprint, and
   5 separate disk/cluster/database blueprints to separate the management of
   6 the lifetime of those constituent parts. Both are provided for use.
   7
   8 Why Two Flavors?
   9 ------------
  10
  11 The reason there are two flavors of blueprints lays in the difference in
  12 lifetime management of the constituent parts.
  13
  14 For example, a database usually needs to have persistent storage, which
  15 in these blueprints comes from Cinder storage volumes. The primitives
  16 used in these blueprints assume that the lifetime of the Cinder storage
  17 volumes matches the lifetime of the blueprint deployment. So when the
  18 blueprint goes away, any Cinder storage volume allocated in the
  19 blueprint also goes away.
  20
  21 Similarly, a database's lifetime may be the same time as an application's
  22 lifetime. When the application is undeployed, the associated database should
  23 be deployed too. OR, the database should have a lifetime beyond the scope
  24 of the applications that are writing to it or reading from it.
  25
  26 The Blueprints for PG Services and Cinder
  27 ------------
  28
  29 The all-in-one blueprint PGaaS.yaml assumes that the PG servers and Cinder volumes can be allocated and
  30 deallocated together. This PGaaS.yaml blueprint creates a cluster named "pstg" by default.
  31
  32 Alternatively, you can split them apart into separate steps, using PGaaS-disk.yaml to allocate the
  33 Cinder volume, and PGaaS-cluster.yaml to allocate a PG cluster. Create the Cinder volume first using
  34 PGaaS-disk.yaml, and then use PGaaS-cluster.yaml to create the cluster. The PG cluster can be
  35 redeployed without affecting the data on the Cinder volumes.
  36
  37 The Blueprints for Databases
  38 ------------
  39
  40 The PGaaS-database.yaml blueprint shows how a database can be created separately from any application
  41 that uses it. That database will remain present until the PGaaS-database.yaml blueprint is
  42 undeployed. The PGaaS-getdbinfo.yaml file demonstrates how an application would access the credentials
  43 needed to access a given database on a given PostgreSQL cluster.
  44
  45 If the lifetime of your database is tied to the lifetime of your application, use a block similar to what
  46 is in PGaaS-database.yaml to allocate the database, and use the attributes as shown in PGaaS-getdbinfo.yaml
  47 to access the credentials.