Wednesday, February 13, 2019

JTD-DesignerSeries-19-Dataweave-101


A brief Context
Integration Platform, at its core is a transformation engine that should support robust data mapping features and enables streamline communication between different components of connecting systems and processes. Mulesoft, platform traditionally supported mapping tasks with the component architecture and designed a DataMapper as their first pass to data transformation activities. As the platform matured, Mulesoft coupled the transformation engine with Mule runtime to design a elegant and lightweight expression language based on JSON syntax, Dataweave.


Dataweave Environment
Design time capabilities of Dataweave lets you define the message metadata which is automatically detected with Datasense. It also accepts several mime-types set at design time on different message processors and defaults to application /java. Explicitly setting the mime type in variable and payload processor parses the java string into standard content. A simple data mapping file has a header and an expression. Header section specifies the dataweave version & output mime-type and generally mapping is form semi-literal expression of Dataweave Object.

Dataweave Fundus
a) Dataweave not just support simple mappings but address advance transformation usecases like Normalization, Grouping, Joins, Partitioning, Pivots, Filtering.
a) Dataweave expressions can be of simple types like string, boolean, arrays [1,2,3], and objects (key/value pairs). Keys and Values in object can be expressed as expressions that return string literal for key and any expression for a value.
b) payload is a reserved key word that references the incoming data to the transform component and dot operator can be used to access the payload elements which can be array / or other objects.
c) Map operator allows you to iterate through each array element and '$' can be used to reference each element in the array.
d) filter keyword can be used on the payload or after map operator to to transform the desired dataset / or can be used after the transform expression to render the desired results.
e) When operator can be used to support conditional logic which can operate on values of incoming fields.
f) GroupBy operator can be used to aggregate the results based on the value of incoming field. Aggregated record can further iterate over the field array by using the another map operator.
g) Dataweave engine normalizes the variable references to payload, flowVars, sessionVars, recordVars, inboundProperties or outboundProperties to a canonical dataweave format specified with mime type (application/dw) irrespective of mime type of the incoming data.
h) Dataweave Engine separates the rendering process by taking the transformed canonical dataweave format and render it in a output mime type specified in the header.
 
Expressions
There are 7 basic expressions in dataweave:
a) Literal: "Hello World", [1,2,3], {firstname: "John", lastname: "Doe"}
b) Variable Reference: payload
c) Semi Literal: {people: payload map {name: $.firstname ++ $.lastname}}
d) Selector: lets you navigate to data elements by specifying dot operator on Objects(payload.firstnaname) and index parameters on an array ([1..-1]). You can specify multi key selectors to iterate over the nested object and result in an array.
e) Function Call
f) Flow Invocation
g) Compound: Typically when you use operators along with expression, you end up writing compound expressions to support advanced transformation usecases like iteration, filtering and conditional logic.

Pointers
Integration Platform, at its core is a transformation engine that should support robust
a) https://github.com/madajee/dataweave-2-101.git
b) https://blogs.mulesoft.com/dev/getting-started-with-dataweave-part-1/
c) https://blogs.mulesoft.com/dev/getting-started-with-dataweave-part-2/

Friday, January 4, 2019

JTD-DesignerSeries-18-Kafka-101


A brief Prep-up
Data Integration over the last 2 decades has been classified as Batch (ETL & Data warehouse) and Realtime (EAI with ESBs & queues) with data persistence technology being the relational DBs. However there are new trends that are demanding complete revamp of these traditional solutions.
a) Relational DBs are augmented with No-SQL distributed databases like MongoDB, Cassandra etc.
b) IOT solutions are connecting billions of devices & sensors and use cases like website tracking produce large datasets that have to be stored for providing analytical capabilities by Big Data solutions like Hadoop.
c) Ubiquitous publishing of streams needs solutions like data pipelines which can cleanse and transform data in realtime before generating the final content.

Data Integration in modern landscape is revamp with streaming platform which is real-time and scalable.




----------------------->
Transition - Streaming 
Platform
------------------------>



So, Data Integration solution in modern landscape has following needs:

a) It should able to to process high volume diverse data in an event centric way, so that you are able to process structured as well unstructured data from different channels like web, mobile, IOT sensors, APIs.

b) It should enable forward compatible architecture, which should allow you to add stream processing applications that need to process the same data differently to support different use cases.

c) Streaming Platform should able to scale out and provide low latency.


Apache Kafka - A Distributed Streaming Platform

With this modern central stream platform, all data is represented as streams, and streams of data is stored and processed through the platform to provide for modern data integration needs.

a) It can serve as a real-time scalable messaging bus and allows applications to publish and subscribe to streams of records.

b) It can store streams of data in a fault-tolerant, durable way and allows for features like message ordering, replay for a point in time.

c) It can process streams of data and allows you to create data pipelines for feeding clean data into all data processing destinations like Hadoop, No-SQL DBs. Streaming Apps can implement the transformation needs of a destination application.

Kafka is based on a concept of persistent, replicated, writehead, append only record log, and every record is identified by a unique index called an offset. Writes are immutable and are only appends, whereas readers can use the offset to index into the record set can can read messages in order.

Kafka runs as a cluster of one of more servers that can span multiple data centers. It stores streams of records in categories called topics. Each record consists of a key, value and a timestamp.


Kafka APIs
a) Producer API - Allows applications to publish streams of records to one or more kafka topics.

b) Consumer API - Allows an application to subscribe to one of more topics and process the stream of records produced to them.

c) Streams API - Allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.

d) Connector API - Allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.

Updates to Follow

Jeetans-MacBook-Pro:dirKafka home$ kafka-topics.sh
Create, delete, describe, or change a topic.
Option                                   Description                            
------                                   -----------                            
--alter                                  Alter the number of partitions,      

Friday, December 21, 2018

JTD-DesignerSeries-17-MongoDB-101


A brief Context
Relational Databases with its three decades of legacy, have provided robust monolith applications. MongoDB on the other hand, has created no-sql DB engine that allow you to work with your data anyway you want, scale in & scale out with your workloads and run it anywhere by deploying on a single node or on different clouds. MongoDB is a document based DB engine that provides drivers in languages like Python, Javascript, Ruby, Java and allows you to quickly build modern applications.

Architecture

mongod is a daemon, a core runtime process of MongoDB designed with architectural layers of MQL, Document Data Model and Storage Layer, that accepts connection requests and persist data to the hard drives.

MongoDB Query Language (MQL) - Data & operations send by client drivers in the form of BSON messages are translated to mongoDB instructions by this layer. It provides different operators & aggregation engine to support CRUD activities.

MongoDB Document Data Model - This layer is responsible for applying the CRUD operations in a distributed replicas & its data structures by handling requirements related to replication, durability.

Storage Layer - This layer handles the disk level system calls on a single node while also providing things like compression, encryption. Wired Tiger is a default storage engine for MongoDB.

Security & Admin are traversal layers for user management & database admin activities.

MongoDB is a distributed DBMS and supports high availability & automatic failover with a replication mechanism between primary & secondary nodes in a replica set. MongoDB manages scalability needs with mongos managing shards of replica sets.


Documents & Data Structures

Data in mongoDB is stored in a hierarchical structure with database at the top level with one of more collections. Then there are documents in the collections and multiple documents represent your data set. MongoDB stores JSON documents as binary representation of JSON (BSON). Drivers for different languages returns documents in JSON format and responsible for translation from BSON to JSON format.

CRUD Operations
a) Create new documents in a collection.
db.users.insertOne({name:"sue", age: 26, status: "pending"})

b) Retrieve documents in a collection with query filters.
db.users.find({age: {$gt: 18}})

c) Modify existing documents in a collection.
db.users.updateMany({age: {$lt: 18}}, {$set: { status: "reject"}})

d) Remove documents from a collection.
db.users.deleteMany({status: "reject"})


Aggregation Framework
Modeled on the concept of data processing pipelines, pipelines are composition of several stages that operate on documents and filter & transforms them into aggregated results.

Syntax:
db.userColl.aggregate([{stage1}, {stage2}, {stage3}], {options})


Replication
Replication provides redundancy and increases data availability.With multiple copies of data on a different server, replication provides level of fault tolerance against the loss of single database server. A replica set in MongoDB is a group of mongod processes that maintain the same data set. MongoDB uses statement based replication mechanism, a process by which DB operations are translated to idempotent op log entries in the primary node which are then used by secondary for replicating data.

Sharding
Database growth can be supported by either vertical scaling or horizontal scaling. Vertical scaling resorts to approach of increasing CPU on a single node, whereas horizontal scaling is an approach of splitting data across multiple nodes.
Sharding is a method of dividing data across multiple replicas based on a shard key. MongoDB implements sharding by routing queries through the mongos and storing metadata and configuration settings in Config Servers.
It is quite important to pick a good shard key based on the cardinality [High], frequency [Low], monotonic change [Avoid]. In some cases, it may be beneficial to use the hashed shard key but then you loose the ability to target a range query and mongos will always perform scatter gather query.

Storage
Storage Engine is a component that manages how data is stored to the disk. Wired Tiger is the default storage engine for MongoDB but there are other options like In-Memory, MMAPv1. WiredTiger supports atomicity at a document level during the write operations and creates checkpoint after writing snapshot data to the disk. MongoDB can recover from a last checkpoint in case of failure writing the new checkpoint and can refer to journal to replay all the data between the checkpoints. With WiredTiger MongoDB supports compression for all collections and indexes.

Monday, December 10, 2018

JTD-DesignerSeries-16-JavaScript-101


A Brief on Web applications
Let's simply say that anything that runs from a browser with a URL is a web application, and complexity can vary based on the content that the browser presents to the user. HTML / CSS helps creative teams design beautiful static content whereas Javascript helps UI programmers manipulate the DOM to create dynamic content & behavior. JS Engine is a runtime that interprets the Javascript code and can be a part of browser as V8 in chrome or other runtime server environment like NodeJS

Basic Notion
a) JS Engine creates a global execution context, along with a global object referenced by this variable, which in case of browser happens to be a window object. At a global execution context, reference to Outer Environment is null.
b) Execution Context has a creation phase before the execution phase, and hoisting, a part of creation phase, allocates memory space for the variables & functions, so that they are available in the execution phase irrespective of where they are written lexically in an execution context.
c) Each invocation of a function creates an execution context, and execution stack controls the layering of execution context with global execution context as the base of the stack.
d) Each execution context has its own variable environment, and can uniquely assigned a value irrespective of the same variable name.Though, when variable is not declared in the function context, it goes down the scope chain referenced by outer environment of execution context. Scope chain depends upon the lexical environment, which means where the function physically written in the JS file.

Objects
a) Objects are collections of name/value pairs and names can again be collection of name/value pairs. Objects have properties [primitive types, objects] & methods [function] and you can access the them with the dot operator.
b) Object Literals is a preferred way of creating objects. [var person = { firstname: John, lastname: Doe };]
c) Javascript Object Notiation (JSON), a ubiquitous data exchange standard over the internet for webapps can be easily converted to object literal & vice-versa in Javascript.
var jsonString = JSON.stringify(jsObjectLiteral);
var jsObjectLiteral = JSON.parse(jsonString);
d) Objects are being passed as reference & all primitives types are passed by value. When you mutate an object by adding a property, all references to that object will able to access the new property.


Functions
a) In Javascript, functions are a special type of objects, with optional property: 'name' & invocable property: 'code as the function body.
b) Functions are first class in Javascript, which means they can be assigned to variables, created on the fly, passed as parameters, just like other Javascript types.
c) Usually 'this' variable references the global object inside a function but when function is defined as a property method of an object, 'this' variable references the object that contains the method definition rather than global object. A common pattern is that you can mutate the object in function by using the this variable and best practice is to assign this to a self variable.
d) Immediately Invoked Function Expression (IIFE) is an anonymous function expression wrapped in parentheses, and created & invoked on the fly as first class function.
(function(name) {var greeting = "Inside IIFE: Hello "; console.log(greeting + ' ' + name); }('John'));

Closures
As functions can be passed around & can be returned from another function in Javascript, Closures, a feature of JS language, allows the returned function to close in the variables during its execution. For eg:

function parentClosure(varClosure) {
return function () {
console.log("Closing in on " + varClosure + " created in parent function and claimed in child");
}
}

var childClosure = parentClosure('patang');
childClosure();

When the anonymous function returned by the parentClosure('patang') function, patang / kite was created in parentClosure function variable environment and even though parentClosure function was done executing, JS engine provided patang assigned to varClosure variable to the childClosure function when it was invoked.

This phenomenon of keeping the scope chain intact until execution context closed in all of the variables is termed as closures.

Callback
A process of passing first-class function as a parameter to function and invocation of a parameter function after the complete execution of a function is called a callback. For eg: Timeout function will output "Hello Callback" after 3 sec by invoking an anonymous function passed as its parameter.
setTimeout(function() {console.log("Hello Callback")}, 3000);

Prototypal Inheritance
Inheritance, in object oriented languages like Java, is an approach with derived class gets access to properties and methods of the base class. Every object in Javascript has a proto object and automatically gets access to the properties & method attached to its proto object. It also goes down in the prototype chain if the property or method is attached to its immediate proto object.

Monday, November 26, 2018

JTD-DesignerSeries-15-Micorservices-101


A brief Context
Past decade is about SOA architectures, SOAP protocol which provided a standard way of platform neutral communication between applications in an enterprise environment. SOA services are usually deployed as application packages on application servers running on VMs, but SOA business & architectures initiatives evolved to support reusability, composability, portability, service discovery etc.

Cloud computing, container based docker support, Restful Architecture & Tooling & success stories like Netflix, are suggesting to design application features as small autonomous deployable containers that can be created, destroyed, scaled independently. This approach of dividing monoliths into small services, or creating platforms backed by 1000s of small services working together, improved & released iteratively with CI/CD can be defined as Microservices.

Enterprises are getting several benefits by adopting microservices & cloud computing like cost, time to market, automation but there is a significant design challenges & management complexity that has to be embraced along with it.

Heroku suggested 12-factor app design practices for cloud native applications, which can constrain architects & developers to Microservices architecture.


12-Factor App Methodology
Apps developed with 12-Factor design generally employs immutable infrastructure [containers rather than VMs], ephemeral applications [non-persistent, can be deleted or restarted], declarative setup [IAAS, Deployments with desired state], and automation at scale [fault-tolerance, auto-scaling, self-healing] and are considered more scalable, maintainable, portable.

I. Codebase
It suggests that you should use version control in proper way, just to say that a single repository per application. In a literal sense, you shouldn't entangle the commits across application to maintain clean isolation at source code level.

II. Dependencies
It is more likely that modules / or services will have dependencies, but a suggested approach to explicitly declared in a pom.xml [Java / Maven] or package.json [NodeJS]. Jars / or node modules shouldn't be checked into code repositories & manually included in the application.

III. Config
Configuration are things that changes between environments like DB URLs, credentials should not be part of the code, rather defined as config strings in properties file and the runtime environment provides values to these config variables.

IV. Backing Services
Consider things like Postgres DB, Redis as attachable resources, and one of the pattern is to treat these resources as external resources, maybe use a CName to map the DB URL, and for sure use config vars that gets URL from the runtime environment.

V. Build, Release, Run
As you push code to the repository, build process should create a single artifact [jar with mvn install, container with docker build], which then picks up the environment specific configurations to create an deployable image. Once the release it tagged, runtime will run that application image [java -jar myApp.jar / node app.js]

VI. Processes
It is quite important that service design doesn't rely on application between restarts, rather have the application pull the current state from persisted storage like Redis or DB like MongoDB.

VII. Port Binding
Traditional application deployment rely on server container for request routing which means that request are received at a specific listener on the server, but in modern application development, port mapping is managed as a service inside the application itself.

VIII. Concurrency
It may help to design the application as processes that may scale out easily depending upon the availability of worker nodes, rather than just always scaling up during peak loads.

IX. Disposability
This refers to a fast startup, responsive service with a graceful shutdown. Microservices are treated more as cattle, pay as you need them with cloud resources and are not really pets as the application servers have been over last decade.

X. Dev/Prod Parity
This principle is quite important as it advocates that the app dev environment is same as your app prod environment along with other envs in between. As all the code & dependencies is packaged in a same image that runs everywhere, it solves the problem of that it worked on my machine.

XI. Logs
It suggests that keeping the logging process separate from application processes and treat logs as events.

XII. Admin Processes
One-time admin tasks like migrating DBs, generating reports should be run just like other application processes as containers etc.


Guiding Principles in Microservices Architecture
It will be nice to have some high level overarching principles that you can rely on while designing your small autonomous microservices. Sam Newman explained quite well in conferences and it is worthwhile to make some notes out of it.


I. Modelled around Business Domain
It helps to design microservice for each feature / capability of a platform / or application. Instead of designing services in horizontal layers like system, process, UI; it is better to design across vertical business layer.

II. Culture of Automation
As there is large number of deployable units, automation is way to manage containers at scale. It is quite important that to enable small teams that provision their infrastructure, manage & operate their service. Org should adopt CI/CD tools to automate deployments & releases as much as possible.

III. Hide Implementation Details
In microservice architecture, service design will also define the bounded context and API layer will manage the exposed data rather than multiple services hitting the same objects / or tables.

IV. Decentralize All the Things
It is about service teams making their own smart decisions, and sharing best practices without centralized governance, and keeping messaging & middleware as dumb pipes business context creeping into gateway services.

IV. Deploy Independently
This directly relates to deployable dependencies and whether the service is running on VM / or as a container image. In SOA ecosystem, developer can develop independently but have to wait for scheduled deployment & releases, and a progressive approach is developed to reduce dependencies while evolving towards microservice architectures. You also want to run

IV. Consumer First
It is about getting feedback as you develop your APIs, and in the SOAP driven webservices, there is a WSDL document which is a spec driven way of telling about how to use your service. Similarly there are API documentation tools like Swagger & registries that provides a way of calling & discovering the service to your consumers.

IV. Isolate Failure
As you design many microservices, you have to think about how not to fail the application when a service fails to accept request or brought down. Pattern like circuit breaker, appropriate timeouts helps increase the resiliency of your application.

IV. Highly Observable
It is about understanding your deployed system, monitoring it as it runs & providing a faster & easier way to troubleshoot issues. It is suggested to have a log aggregation system which collects logs from all your services & provides some kind of query framework against the aggregated logs. Another design approach is to create a correlationID that traverses along the path of transaction & can provide a runtime view of the service model.

Sunday, November 25, 2018

JTD-DesignerSeries-14-Kubernetes-101


A brief Prep-up
Though, DockerFile has standardized the application containerization format, complex features usually require multiple containers communicating together. Containers are light weight operating system virtualization, and an application can be packed in a docker image at build/release time. With containers deployed across different IAAS vendorslike AWS, Google, Microsoft & opensource Openstack, Kubernetes provides a portable, extensible open source platform for managing containerized workloads in a streamline way across the IAAS landscape. For eg: Deployment Kubernetes Object provides a JSON spec that allows you to create the infrastructure for your application / service on anywhere running with Kubernetes Cluster. Kubernetes is an extensible framework that allows vendors to build tools to support things like Dashboard, Visualizer, Operator.

An example of this "Kubernetes Operator for MongoDB" mentioned in my precious post
[https://integrationshift.blogspot.com/2018/11/jtd-designerseries-13.html]each other.


Concepts
Kubernetes Object - A persistent entity that defines the cluster workload & desired state of the cluster. For eg: Kubernetes Deployment Object represents an application running on the cluster with 3 replicas as the desired cluster state.

Pods: It is a basic building block, that represents a running process in the cluster. An idea of pod is to provide a layer of abstraction around container image to enable communication by managing network & storage layer. One Container per Pod is a most common Kubernetes usecase, but Pod can contain multiple co-located containers that are tightly coupled & need to share resources. As Pods are ephemeral disposable entities, Kubernetes uses controllers to manage the lifecycle of Pods.

Controller: It can create & manage multiple Pods for you, handling replication & rollouts to provide self-healing capabilities at cluster scope. Usually pod specification are included in objects like ReplicaSet, StatelfuSets, Deployments that helps Kubernetes controllers manage the runtime state of pods.

Kubernetes Architecture
At a really high level abstraction, Kubernetes documentation categorizes components as follows:
Master Components - Usually specifies the cluster control plane, and provides administration & management features. [kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager].

Node Components - Runs on every node, maintaining running nodes and providing the kubernetes runtime environment. [kubelet, kube-proxy, container runtime]


Links
a) https://kubernetes.io/

Sunday, November 18, 2018

JTD-DesignerSeries-13-KubernetesOperatorForMongoDB-101


A Brief on Containerization
Generally transporting goods involves packaging & shipping containers that move between different modes of transportation by different shipping companies to deliver your goods at the doorstep. critical business functions. Modern software techniques like microservices divide software applications into smaller independent functions that are build, packaged, scaled & managed independently as isolated containers. Containers can mentioned as operating system level virtualization method for running multiple isolated linux systems on a host with a single linux kernel.


Docker has become the de-facto standard for managing container images defined using Dockerfile, and allows that to run on any machine with Docker Install. However complex application require container orchestration solutions, like Kubernetes, that can manage the lifecycle of containers & how these containers communicate can each other.

A Brief on Kubernetes
Kubernetes is an open source platform for managing containerized workloads & services. Kubernetes, with support from major cloud vendors, has emerged as the de-facto standard for container orchestration governed by Cloud Native Computing Foundation a.k.a CNCF. Kubernetes, born at Google, has a backing from large open source community has quite an advantage compared to other products like Docker Swarm, Apache Mesos.
Master node in a kubernetes cluster contains services to support the Rest API, scheduler & controller manager. Each cluster contain one or more worker node, which contain the components to communicate with master node & also manage the containers running on the node. Worker node run containers managed as a logical layer represented by Pod.


A Brief on MongoDB Ops Manager & Operator
Ops Manager 4.0 contains a specialized component called MongoDB Ops Manager Kubernetes operator, simply referred as Operator. Operator Implementation, now part of Kubernetes framework, is a continuously running lightweight process deployed as a Pod with single container.


Operator defines & registers the custom types within the Kubernetes cluster, which allows operator to receive notification about the events occurring on the registered types. Notifications such as object creation or object deletion allow Operator to trigger custom logic on Kubernetes tasks, such as add mongod replica set to the Ops Manager project. Operator essentially acts as a proxy between the Kubernetes & Ops Manager to perform the needed tasks against each system. Helm, which is a tool for managing packaging & deployment in Kubernetes, can be used to deploy an operator Pod with a helm chart.


Lab - Setup Kubernetes Cluster with MongoDB


Pre-requisite Step: Virtual Box, Docker, Kubectl, Minikube, Helm



Virtual Box: virtualbox --help

Docker: docker version










Kubectl: kubectl version



Minikube: minikube version

Helm: helm version



Step: MiniKube

minikube start
minikube status

eval $(minikube docker-env) - This sets the shell environment variables so that docker points to the registry running inside the kubernetes cluster. Running docker images will list the kubernetes images deployed in the minikube cluster.


Lab - Kubernetes Operator

a) Create a MongoDB namespace.

Jeetans-MacBook-Pro:dirKubernetes home$ kubectl create namespace mongodb
namespace/mongodb created

b) Configure Kubectl to mongodb namespace
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl config set-context $(kubectl config current-context) --namespace=mongodb

Context "minikube" modified.

c) Check for deployed resources in mongodb namespace.
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl get all

No resources found.

d) Clone MongoDB-Enterprise-Kubernetes repository
Jeetans-MacBook-Pro:dirKubernetes home$ git clone https://github.com/mongodb/mongodb-enterprise-kubernetes
Cloning into 'mongodb-enterprise-kubernetes'...
remote: Enumerating objects: 21, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 132 (delta 8), reused 14 (delta 6), pack-reused 111
Receiving objects: 100% (132/132), 29.71 KiB | 2.29 MiB/s, done.
Resolving deltas: 100% (52/52), done.
Jeetans-MacBook-Pro:dirKubernetes home$ ls
mongodb-enterprise-kubernetes

d) Create a service account for helm
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl create serviceaccount --namespace kube-system tiller
serviceaccount/tiller created

e) Create a cluster role binding for the account
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller-cluster-rule created

f) Initialize the helm system
Jeetans-MacBook-Pro:dirKubernetes home$ helm init --service-account tiller
Creating /Users/home/.helm 
Creating /Users/home/.helm/repository 
Creating /Users/home/.helm/repository/cache 
Creating /Users/home/.helm/repository/local 
Creating /Users/home/.helm/plugins 
Creating /Users/home/.helm/starters 
Creating /Users/home/.helm/cache/archive 
Creating /Users/home/.helm/repository/repositories.yaml 
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com 
Adding local repo with URL: http://127.0.0.1:8879/charts 
$HELM_HOME has been configured at /Users/home/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

g) Create a secret & verify it with describe command.
$ kubectl -n mongodb create secret generic my-credentials --from-literal="user=some@example.com" --from-literal="publicApiKey=my-public-api-key"

secret/madajeeblog-credentials created
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl describe secrets/madajeeblog-credentials -n mongodb
Name:         madajeeblog-credentials
Namespace:    mongodb
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
publicApiKey:  36 bytes
user:          21 bytes

i) Install the operator with helm chart.
Jeetans-MacBook-Pro:mongodb-enterprise-kubernetes home$ helm install helm_chart/ --name mongodb-enterprise
NAME:   mongodb-enterprise
LAST DEPLOYED: Sun Nov 18 09:33:07 2018
NAMESPACE: mongodb
STATUS: DEPLOYED

RESOURCES:
==> v1/ServiceAccount
NAME                         AGE
mongodb-enterprise-operator  1s

==> v1beta1/CustomResourceDefinition
mongodbstandalones.mongodb.com      1s
mongodbreplicasets.mongodb.com      1s
mongodbshardedclusters.mongodb.com  1s

==> v1/Role
mongodb-enterprise-operator  1s

==> v1/RoleBinding
mongodb-enterprise-operator  1s

==> v1/Deployment
mongodb-enterprise-operator  1s

==> v1/Pod(related)

NAME                                          READY  STATUS             RESTARTS  AGE
mongodb-enterprise-operator-74fbcbd9b7-p944v  0/1    ContainerCreating  0         1s

i) Operator is up & running.

Jeetans-MacBook-Pro:mongodb-enterprise-kubernetes home$ kubectl get all
NAME                                               READY   STATUS    RESTARTS   AGE
pod/mongodb-enterprise-operator-74fbcbd9b7-p944v   1/1     Running   0          9m

NAME                                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mongodb-enterprise-operator   1         1         1            1           9m

NAME                                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/mongodb-enterprise-operator-74fbcbd9b7   1         1         1       9m
Jeetans-MacBook-Pro:mongodb-enterprise-kubernetes home$ 


Lab - MongoDB Ops Manager
a) Simple Test Ops Manager - Deployment with one pod with container running a mongoDB instance for Ops Manager application DB, another container running an instance of Ops Manager.
Jeetans-MacBook-Pro:dirKubernetes home$ curl -OL https://raw.githubusercontent.com/jasonmimick/mongodb-openshift-dev-preview/master/simple-test-opsmanager-k8s/simple-test-opsmgr.yaml

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  3228  100  3228    0     0  14934      0 --:--:-- --:--:-- --:--:-- 14944

b) Use kubectl & downloaded yaml configuration to create an instance of Ops Manager.
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl create -f simple-test-opsmgr.yaml
persistentvolume/mongodb-opsmgr-appdb-pv-volume created
persistentvolumeclaim/mongodb-opsmgr-appdb-pv-claim created
persistentvolume/mongodb-opsmgr-config-pv-volume created
persistentvolumeclaim/mongodb-opsmgr-config-pv-claim created
secret/mongodb-opsmgr-global-admin created
service/mongodb-opsmgr created
deployment.apps/mongodb-opsmgr created

c) Ops Manager is up & running.
Jeetans-MacBook-Pro:dirKubernetes home$ kubectl get all
NAME                                               READY   STATUS             RESTARTS   AGE
pod/mongodb-enterprise-operator-74fbcbd9b7-p944v   1/1     Running            0          5h
pod/mongodb-opsmgr-8c44d98f8-97jvs                 0/2     Running            0          1m

NAME                     TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/mongodb-opsmgr   NodePort   10.100.253.9   <none>        8080:30080/TCP   1m

NAME                                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mongodb-enterprise-operator   1         1         1            1           5h
deployment.apps/mongodb-opsmgr                1         1         1            0           1m

NAME                                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/mongodb-enterprise-operator-74fbcbd9b7   1         1         1       5h
replicaset.apps/mongodb-opsmgr-8c44d98f8                 1         1         0       1m
Jeetans-MacBook-Pro:dirKubernetes home$ 

c) Ops Manager runtime contains the configuration for creation of config map, projects & secrets objects.
d) Create a mongoDB replica set config file with appropriate project, credentials & namespace.
e) Run the config file to create a replica set which have mongod container pod as its members. Container Pods will be associated with the Stateful Sets.
f) You can then connect to the mongoDB replica set with the minikube IP & exposed external port from a kubernetes replica set service.





Thanks