nyc identity summit tech day: forgerock devops/cloud strategy


ForgeRock DevOps / Cloud Strategy

Warren StrangeDirector, Customer Engineering

NY Identity Summit 2016


Why DevOps?

Expectations for time to value are changing • Months -> Weeks -> Days

The rise of “12 factor” apps & Continuous Integration • Before: Deploy new features yearly• Now: Deploy new features weekly

Shift towards cloud deployments and containers• AWS, Azure, Google, OpenStack, etc.• Docker / Kubernetes

http://12factor.net/


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

Flexibility / Power

Spee

d of

Dep

loym

ent

IDaaS

Legacy


What is “DevOps” Friendly?• Installation / management is easily automated• Products self tuning / self configuring• Infrastructure as code

• Repeatable and automated deployments

• Useful configuration file formats• Toolable / templatable • Human friendly (not a dump of an internal data structure)

• Phoenix servers• Blow one up, and another one rises to take its place


ForgeRock DevOps Focus

• Core engineering work required to make products more “12Factor” like

• Requires deep & intimate knowledge of internals of OpenAM / OpenDJ / OpenIDM / OpenIG

• Where ForgeRock can have the most impact

• Container friendly• Reduced file system dependencies• Externalize state • Dynamic configuration

http://12factor.net/


Roadmap: OpenAM 14 • “Autonomous Servers”

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

• No “home” server concept• Scale up / down by adding more servers

• Stateless Sessions• Any server can issue a token, any server can validate it

• Extension of Stateless sessions in AM 13• Stateless OAuth 2.0


Roadmap: OpenAM 14• REST based Configuration

• ssoadm-ng • REST / JSON Configuration

• Reduced file system dependencies• Boot using ENV vars (Docker requirement)

• Agents• Boot from ENV vars


Roadmap: OpenDJ

• Single persistence engine for the entire stack• The one component that is most “pet” like

• OpenDJ 3.0• Pluggable backends • Foundational work for future alternate backends

• Memory based with snapshots (example: short lived access tokens )


Roadmap: OpenIDM

• Boot from ENV Vars• Flexible audit log destinations (commons audit)• Improved Configuration Import / Export

• Export / Version / Import• Improved conf/* file management

• Clearly separate product config from customizations• Template environment variables

• OpenDJ as a repository


Containers

• Phase 1• ForgeRock will support customers deploying with

Docker • Provide sample Dockerfiles / Kubernetes Manifests

• Phase 2• Provide reference Docker images• Distribution mechanism TBD


Feedback Needed• What are your biggest challenges in deployment / management?

• Help us prioritize our efforts

• What is your application AuthN / AuthZ strategy?• Reverse proxy + HTTP headers - AuthZ at proxy• Policy Agents (Java EE or .Net)• OpenID Connect / SAML

• Directly consume OIDC tokens • AuthZ - use scopes plus custom logic?

• Application landscape • Java, .Net, NodeJS, Ruby, other?


Container Questions

• 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?


Additional Material


Docker Tips• Docker on Mac• Remember it is running in a VM! “localhost” is relative

to the VM, not your laptop • To find the IP of your VM host-only network use Kitematic or

docker-machine ip• Docker Volumes are relative to your guest VM, not your

laptop• Virtualbox can mount /Users/

• How do I shell into an running image?• docker ps to get the image id• docker exec -it image-id /bin/bash


Docker Registries vs. Repositories

• Registry:• Service responsible for hosting and distributing docker images.

• Docker Hub is the most popular public registry. • Others include quay.io (CoreOS team), gcr.io (Google)• Private registries

• Repository • Collection of Docker Images. For example “forgerock” • Tags• Images are tagged with a version. Example “dev”, “1.0”


Image Naming Format

{registry}/{repository}/{image}:{tag}Examples

docker pull quay.io/kubespray/kubernetes-dashboard:latest

docker pull java:8u72-jre

Registry defaults to “hub.docker.com” if omited (Docker Hub)Repository defaults to _ (“official” repo) if omitted

docker pull java

Tag defaults to “latest” if not specified


Tags

• Arbitrary schema (invent your own)• By convention, a release version or git hash• “latest” is a synonym for “the most recent version”Example:

forgerock/openidm:latest

forgerock/openidm:nightlyforgerock/openam:13.0.1

Using “latest” is OK for development. Not good for production.• Does not create repeatable deployment


Image Considerations

• Do not use proprietary base images!

FROM some-repo/oracle-jdk

FROM java:jre8 • Consolidate RUN commands to keep image size down


Building Container Friendly Apps • Base container should be quite “generic”

• Personality is gained at runtime• Avoid hostname / IP address dependencies • One service, one container• Stateless over stateful

• Throw away the container and create a new one• Log / trace to stdout as a default

• Avoids needing to write special log collectors for each service• Externalize persistence

• State stored externally (database, DJ)• Be tolerant of service startup order and availability

• Example: service starts before the database is ready• Database goes down, comes back up


Kubernetes

• Provides orchestration, container networking, service lookup, rolling upgrades, bin packing, placement (affinity / non-affinity)

• Self healing, horizontal scaling• Created by Google, based on 10+ years of experience running

containers at scale• Container agnostic (Docker, Rocket, LXC)• Open source project

• Adopted by cncf.io • IP transferred to the Linux Foundation

• Github PR Stats (one month)• Kubernetes: 213 merged, 461 active• Docker Swarm: 61 merged, 20 active• Cloudfoundry-release + bosh: 17 merged, 8 active

J


Kubernetes Concepts / Terms

Nodes Servers that run pods

Pods Collection of containers that logically belong together. Scheduled together. Ports must be unique within a pod

Services Abstraction that defines logical set of pods and how to access them. Pod IPs are not stable over time. Service provide a Virtual / Stable IP to access backend pods


Kubernetes FeaturesNamespaces Instance isolation on a cluster. For example, dev, QA, Prod. Multi-tenancy of

a kind..

Integrated DNS Service discovery via DNS

Persistent VolumesPersistent Volume Claims

Abstraction for persistent data volumes attached to containers. For example - postgres data files, OpenDJ backends.

Secrets / Secret volumes Special Volume type used to securely distribute secrets to your containers. Secrets can be passwords, keys, keystores, etc. This removes secrets from the containers themselves.

Replication Controllers Monitor service availability, restarting failed services as required. Autoscaling support

Ingres API HTTP (Layer 7) and Network load balancing (Layer 3) built in

Jobs API Manage Jobs (one time processes)

Rolling Upgrades Manage upgrade of clusters and services


Kubernetes Tips

• Easy to use, hard to install • Recommended (in relative order)• GKE (Hosted Kubernetes as a service)• Linux - follow local install instructions• Kmachine • https://github.com/TheNewNormal/kube-solo-osx

nyc identity summit tech day: forgerock devops/cloud strategy

Software