helm/examples/guestbook

Guestbook Example

Welcome to the Guestbook example. It shows you how to build and reuse parameterized templates.

Prerequisites

First, make sure DM is installed in your Kubernetes cluster and that the Guestbook example is deployed by following the instructions in the top level README.md.

Understanding the Guestbook example

Let's take a closer look at the configuration used by the Guestbook example.

Replicated services

The typical design pattern for microservices in Kubernetes is to create a replication controller and a service with the same selector, so that the service exposes ports from the pods managed by the replication controller.

We have created a parameterized template for this kind of replicated service called Replicated Service, and we use it three times in the Guestbook example.

The template is defined by a Python script. It also has a schema. Schemas are optional. If provided, they are used to validate template invocations that appear in configurations.

For more information about templates and schemas, see the design document.

The Guestbook application

The Guestbook application consists of 2 microservices: a front end and a Redis cluster.

The front end

The front end is a replicated service with 3 replicas:

- name: frontend
  type: https://raw.githubusercontent.com/kubernetes/application-dm-templates/common/replicatedservice/v1/replicatedservice.py
  properties:
    service_port: 80
    container_port: 80
    external_service: true
    replicas: 3
    image: gcr.io/google_containers/example-guestbook-php-redis:v3

(Note that we use the URL for a specific version of the template replicatedservice.py, not just the template name.)

The Redis cluster

The Redis cluster consists of two replicated services: a master with a single replica and the slaves with 2 replicas. It's defined by this template, which is a Jinja file with a schema.

{% set REDIS_PORT = 6379 %}
{% set WORKERS = properties['workers'] or 2 %}

resources:
- name: redis-master
  type: https://raw.githubusercontent.com/kubernetes/application-dm-templates/master/common/replicatedservice/v1/replicatedservice.py
  properties:
    # This has to be overwritten since service names are hard coded in the code
    service_name: redis-master
    service_port: {{ REDIS_PORT }}
    target_port: {{ REDIS_PORT }}
    container_port: {{ REDIS_PORT }}
    replicas: 1
    container_name: master
    image: redis

- name: redis-slave
  type: https://raw.githubusercontent.com/kubernetes/application-dm-templates/master/common/replicatedservice/v1/replicatedservice.py
  properties:
    # This has to be overwritten since service names are hard coded in the code
    service_name: redis-slave
    service_port: {{ REDIS_PORT }}
    container_port: {{ REDIS_PORT }}
    replicas: {{ WORKERS }}
    container_name: worker
    image: kubernetes/redis-slave:v2
    # An example of how to specify env variables.
    env:
    - name: GET_HOSTS_FROM
      value: env
    - name: REDIS_MASTER_SERVICE_HOST
      value: redis-master

Displaying types

You can see both the both primitive types and the templates you've deployed to the cluster using the deployed-types command:

dm deployed-types 

["Service","ReplicationController","redis.jinja","https://raw.githubusercontent.com/kubernetes/application-dm-templates/master/common/replicatedservice/v1/replicatedservice.py"]

This output shows 2 primitive types (Service and ReplicationController), and 2 templates (redis.jinja and one imported from github named replicatedservice.py).

You can also see where a specific type is being used with the deployed-instances command:

dm deployed-instances Service
[{"name":"frontend-service","type":"Service","deployment":"guestbook4","manifest":"manifest-1446682551242763329","path":"$.resources[0].resources[0]"},{"name":"redis-master","type":"Service","deployment":"guestbook4","manifest":"manifest-1446682551242763329","path":"$.resources[1].resources[0].resources[0]"},{"name":"redis-slave","type":"Service","deployment":"guestbook4","manifest":"manifest-1446682551242763329","path":"$.resources[1].resources[1].resources[0]"}]

This output describes the deployment and manifest, as well as the JSON paths to the instances of the type within the layout.

For more information about deployments, manifests and layouts, see the design document.