NYC Identity Summit Tech Day: ForgeRock DevOps/Cloud Strategy

ForgeRock DevOps /
Cloud Strategy
Warren Strange
Director, 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

ForgeRock DevOps Goal
The agility of an IDaaS, with the flexibility of a custom solution
Flexibility / Power
SpeedofDeployment
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

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:nightly
forgerock/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 Features
Namespaces Instance isolation on a cluster. For example, dev, QA, Prod. Multi-tenancy of
a kind..
Integrated DNS Service discovery via DNS
Persistent Volumes
Persistent 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

More Related Content

What's hot (20)

Similar to NYC Identity Summit Tech Day: ForgeRock DevOps/Cloud Strategy (20)

More from ForgeRock (20)

Recently uploaded (20)

NYC Identity Summit Tech Day: ForgeRock DevOps/Cloud Strategy