DevOps Unleashed: Strategies that Speed Deployments

© 2016 ForgeRock. All rights reserved.

DevOps Unleashed: Strategies that Speed

Deployments

Warren Strange Director, Engineering, ForgeRock

Jessica Morrison

Director, Product Marketing, ForgeRock


Agenda

• DevOps / Container options and strategies • ForgeRock Identity Platform - Container roadmap • Using container-oriented technologies • Demo (time permitting) • Q & A


2010 Founded

10 Offices worldwide with headquarters in San Francisco

350+ Employees

450+ Customers

30+ Countries

$52M Funding to date (thru Series C) by Accel Partners, Foundation Capital and Meritech Capital Partners

ForgeRock The leading, next-generation, identity security software platform.


From Simply Managing Identities to Managing Complex Relationships

Identity Access Management Identity Relationship Management Customers (millions)

On-premises

People

Applications and data

PCs

Endpoints

Workforce (thousands)

Partners and Suppliers

Customers (millions)

On-premises Public Cloud

Private Cloud

People

Things (Tens of millions)

Applications and data

PCs Phones Tablets Smart

Watches Endpoints

Source: Forrester Research


Authoriza*on Federa*on

Iden*ty Workflow Self Service

Authen*ca*on

Iden*ty Synchroniza*on

Adap*ve Risk

Directory Services

User-‐Managed Access

Iden*ty Gateway

The ForgeRock Identity Platform Built from the OpenAM, OpenDJ, OpenIDM, and OpenIG Open Source Projects


ForgeRock DevOps Goal The agility of an IDaaS, with the flexibility of a custom solution

Flexibility / Power

Spee

d of

Dep

loym

ent

IDaaS

Legacy

IDaaS in a box


ForgeRock DevOps Focus • Core engineering work required to make products more

“12Factor” like •  Requires intimate knowledge of internals of OpenAM / OpenDJ /

OpenIDM / OpenIG •  Where ForgeRock can have the most impact

• Container friendly •  Reduced file system dependencies •  Externalize state •  Useful Configuration import / export (json / yaml)


Areas we are not focusing on •  Configuration Management tooling

•  Chef, Puppet, Ansible, Salt stack, CF Engine, etc. •  Too many choices for us to pick the right one •  This is where the community can help

• CM tools can paper over complexity •  We want to focus on simplifying •  Example: Clustering for OpenAM


OpenAM 14 Epics •  “Autonomous Servers”

•  No cross-talk, no special servers •  CTS become sole source of state for all tokens

•  No “home” server concept

•  Scale up / down by adding more servers • Further Stateless Session enhancements

•  Any server can issue a token, any server can validate it •  Remove further restrictions of Stateless sessions in AM 13.5. e.g. SAML

•  Stateless OAuth 2.0 (13.5)


OpenAM Epics •  REST based Configuration API

•  SDK based on API descriptors •  ssoadm-ng “amster”

•  REST / JSON Configuration tool

• Reduced file system dependencies •  Audit framework to send audit data off-container •  Trace / Debug to stdout

• Agents 5 •  Eliminate callback architecture

•  Websocket based notification channel


OpenDJ •  Single persistence engine for the entire stack

•  The one component that is most “pet” like • OpenDJ 3.0 introduced

•  Pluggable backends •  Foundational work for possible alternate backends

•  Example of what is possible: •  Memory based with snapshots (example: short lived access tokens )

• OpenDJ 4.x •  Directory Proxy + Sharding

•  Key for OpenAM CTS scale out


OpenIDM •  OpenIDM is already REST/JSON Friendly! •  API descriptors for REST / Swagger docs •  Flexible audit log destinations (commons audit) •  Simplified clustering (no primary node) •  Enhancements

•  Boot from ENV Vars •  Improved Configuration Import / Export, conf/* file management

•  Export / Version / Import •  OpenDJ as a repository

•  Single persistence engine for the stack


Docker 101 •  Like a “mini-VM”

•  Everything needed to run a process is baked into the container. •  The base O/S layer, JVM, libraries, patches, web container, etc..

• Massive adoption • Containers have been around forever (Mainframes / Solaris

Zones / BSD Jails). Why has Docker Exploded? •  Right time, right place •  Docker Hub - distribution mechanism for sharing containers •  Ecosystem is in a virtuous cycle (more containers = more adoption )


Cargo Transport pre-1960s

From http://pointful.github.io/docker-intro/#/4


Dependency Matrix from Hell


Solution: Intermodal Shipping Container


Docker is a container for code


ForgeRock & Docker •  Why are we doing this?

•  Normalizes platform we need to QA & test •  Provides “curated” components known to scale / work well •  Pre-integrates components

•  Phase 1 (Winter release) •  Support for customers deploying with Docker •  Provide reference Dockerfiles / Kubernetes Manifest Samples

• Phase 2 •  Provide reference Docker images

•  Distribution mechanism TBD (Docker Hub, quay.io, or ForgeRock registry)

•  Reference Kubernetes manifests


Kubernetes 101

J

•  Provides the things that Docker is missing: •  Orchestration, container networking, service lookup, rolling

upgrades, bin packing, placement (affinity / non-affinity) •  Self healing, horizontal pod scaling

•  Created by Google, based on 10+ years of experience running containers at scale

•  Container agnostic (Docker, Rocket, Windows!) •  Platform / Cloud agnostic

•  Runs on AWS, Azure, Google, OpenStack, VMWare, ... •  Open source project with broad support & momentum

•  One of the most active project on github (> 5K forks, 855 contributors)

•  Supported by Google, Redhat, Microsoft, CNCF + many others


Kubernetes


OpenAM OpenAM OpenAM

DJ DJ DJ

OpenIDM OpenIDM

OpenIDM

OpenIG OpenIG

PV SSD

kind: Deployment spec: replicas: 1 template: metadata: name: openig labels: name: openig spec: containers: - name: openig image: forgerock/openig volumes: - name: keystore secret: secretName: openig

manifests describe components and their relationships

kind: Service name: opendj ports: - port: 389 name: ldap targetPort: 389

persistent volumes abstract storage

The same manifests work on any cloud! AWS, Azure, Google, VMWare, etc.

Kubernetes Manifests describe a “virtual” ForgeRock Deployment


Deployment Models • Mutable Configuration

•  The traditional way it is done •  Allow changes to production servers

•  Use scripted procedures, run books, documentation for controls •  Automation via Chef, Puppet, etc.

•  Our customers will be doing this for many years •  We need to make it easy

•  Immutable Configuration •  Not as common, but growing fast •  Influenced by the way that Facebook, Netflix, Google, etc. deploy

services

mutant


Immutable • No runtime changes to production configuration •  Ideally enforced by

•  Read only configuration stores •  Immutable Docker containers

• To make a change, you must build and re-deploy a new image •  Impossible without automation (Jenkins, CI tools, etc.) • Benefits

•  No config drift, Phoenix servers, Repeatable Deployments, Canary Deployments


GIT Configuration Jenkins CI

config change

build image

deploy to Kubernetes

Demo: Automated Deployment of Immutable Containers

Image is fully “baked” (Immutable)

export config from development

scripted config


Configuration as Code Git branching model for dev, test, QA, production Question: What is the difference between QA and Production? git checkout qa git diff production Think of how long it would take to build config versioning / diffing into each products


Feedback wanted What are your plans for Docker? Have you looked at orchestration frameworks such as Mesos / Kubernetes / Docker Swarm / Amazon ? What is your desired Docker support model?

• Would you run ForgeRock curated & tested Docker images, or is your preference to create your own Docker images?


Resources https://goo.gl/DOD9pv

• Links to ForgeRock Dockerfiles, Kubernetes manifests, etc.: https://wikis.forgerock.org/confluence/display/DC/ForgeRock+DevOps+and+Cloud+Resources

• ForgeRock DevOps Forum: https://forgerock.org/topic/links-to-docker-kubernetes-resources/

• Subscribe to Identity Disorder podcast on iTunes •  Episode 2: It’s a DevOps World, We Just Live in It

• Talk to me: [email protected] • Follow us on Twitter: @ForgeRock


Q & A


Thank You

Software

DevOps Unleashed: Strategies that Speed Deployments