Skip to content

Example of 12factor implemented with Helm using sub-charts

License

Notifications You must be signed in to change notification settings

manquius/12factor

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

34 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Gradle Helm Docker License: MIT

12factor

Table of Contents

Introduction

12factor demo is a simplified example project to demonstrate the advantages of twelve-factor methodology on cloud based applications design.

It consist in two frontend RESTful services to produce and consume to a backend. By default it uses a Kafka backend, using a Redis service as a circuit breaker for High Availability.

It is build to be installed on a Kubernetes environment using Helm.

Pre-requisites

Recommended utilities

Docker-compose

docker-compose is a helper utility that simplifies the docker image builds.

It can also help to test integration locally. This example provides a docker-compose.yaml that can be use to verify twelve-factor methodology can be easily adapter to many environments and deployments.

However we recommend local Kubernetes implementation like:

A local Kubernetes implementation will help you to deploy and execute locally in the same way it will execute on production environments.

Metrics-server

metrics-server is necessary to implement horizontal pod autoscaler.

helm install metrics-server --namespace kube-system stable/metrics-server

Kubernetes Dashboard

The kubernetes dashboard will help you to manage your cluster in a local environment.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.1/aio/deploy/recommended.yaml

In order to access Kuberntes dashboard you must execute

kubectl proxy

And you will be able to access using your browser at:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

The Kubernetes Dashboard will ask for a token to access. You can get it executing:

kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user | awk '{print $1}')

Pulsar Admin API

In order to access Pulsar Admin API you must execute

kubectl proxy

Then you can access using the following URL:

http://localhost:8001/api/v1/namespaces/default/services/http:twelvefactor-pulsar-proxy:http/proxy/admin/

Installation

Before the first time you install the chart:

cd 12factor
helm dependency update
cd ..

And then each time you want to install

helm install twelvefactor ./12factor

Uninstallation

helm uninstall twelvefactor

Usage

This usage guidelines are thoght to be used on a local kubernetes environment. It may change if you deployed on diferent environments.

First, let configure the Kubernetes proxy:

kubectl proxy

Now you can call the different endpoints using cURL, or your favourite http client.

Producing

curl http://localhost:30001/topic/mytopic -d 'mymesage'

Consuming

curl http://localhost:30002/topic/mytopic

Health Check

curl http://localhost:30001/health
curl http://localhost:30002/health

High Availability

In order to test a system failure, Producer and Consumer services have an API that will make Health fail.

curl http://localhost:30001/health/hurt
curl http://localhost:30002/health/hurt

The instances that received those calls will be shutted down and new instances will be created to replace them.

Autoscaling

Producer and Consumer services can be configured to autoscale if high performance is required. To acheve this you must execute:

kubectl autoscale deployment twelvefactor-12factor-producer --cpu-percent=50 --min=2 --max=10
kubectl autoscale deployment twelvefactor-12factor-consumer --cpu-percent=50 --min=2 --max=10

Then you can test autoscaling with any Load Test tool. For a simple test you could try:

while true; do curl http://localhost:30001/topic/mytopic -d 'mymesage'; done
while true; do curl http://localhost:30002/topic/mytopic; done

Start your own 12factor project

  1. Indetify your use cases
  2. Define your interface
    • Validate usability.
    • Validate accessibility.
  3. Define your architecture
  4. Create your project
  5. Create your components
  6. Select your cloud service provider
  7. Choose your backend services (:confused: Yes, in this step)
  8. Deploy
  9. Perform integration tests
    • Execute the tests defined in step 2.
    • Execute performance tests.
    • Expose a beta to a limited public.
  10. Publish

Author

Fernando Ezequiel Mancuso (:bowtie:Manquius)

Collaborators

Contributing

Branch naming convention

Docker images version tags are taken from branch names, so the branch name must match the expected version for the image:

Example:

Branch 0.0.1 will generate the images:

  • manquius/12factor-producer:0.0.1
  • manquius/12factor-consumer:0.0.1

The same versions must be updated on:

License

MIT License

Copyright (c) 2020 Fernando Ezequiel Mancuso

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.