This document discusses using DevOps tools and practices with ForgeRock identity platforms. It begins by explaining the needs of different roles that DevOps aims to address. It then covers topics like elastic scaling of ForgeRock, different DevOps tools available, and ForgeRock's role in supporting DevOps. The document demonstrates configuring all ForgeRock components like OpenIDM, OpenAM, OpenDJ and OpenIG using Ansible. It discusses experiences using tools like Docker and the benefits of containers. Finally, it presents a proposal to run OpenAM on Kubernetes and leverage its capabilities for container orchestration.

1. Adventures in DevOps
Warren Strange
Director, Sales Engineering
warren.strange@forgerock.com

2. DevOps in a nutshell….
source: HTTP://XKCD.COM/974/

3. Why DevOps?
Copyright © Identity Summit 2015, all rights reserved.
• Developer: “I want a development box”
• QA tester: “I want to test a complex configuration that mirrors
production”
• Sys Admin: “I want a reliable, repeatable production configuration”
• Potential Customer: “I want a demonstration of how your product
works”
• ForgeRock University “I want to quickly create lab environments for 30
students”

4. Elasticity
Copyright © Identity Summit 2015, all rights reserved.
• The ForgeRock platform scales extremely well
vertically with a small number of nodes
• Easy to scale up / down through virtualization, adding
more CPU, RAM, etc
• OpenAM 13 stateless sessions provide new horizontal
scaling options

5. Which tool?

6. What role can ForgeRock Play?
• Make our products more “DevOps” friendly. E.g:
– OpenAM 13 REST configuration service
– Reduce file system dependencies
– Commons project to implement keystore in OpenDJ
– More flexible logging options (e.g. syslog)
• Longer term: move towards 12factor architecture
• What we can’t do is pick a “winner” in the DevOps tools game
• Community: How can we facilitate more sharing?

7. Enough Talk. Let’s see some DevOps
• https://github.com/ForgeRock/frstack
• Ansible / Vagrant project to install all of the ForgeRock components
– OpenIDM - identity lifecycle management
– OpenAM - access management
– OpenDJ - directory services
– OpenIG - identity gateway
– OpenAM Agent - policy enforcement point
J

8. Demo of frstack ( 5 min)

9. Things I learned so far...
• Normalizing environments is painful e.g. Apache on
CentOS/RHEL is not quite the same as Ubuntu/Debian
• More flexible == more brittle e.g. OpenDJ CLI
arguments changed slightly from 2.x to 3.x.
• Not a lot of sharing right now...
– Are DevOps assets too specific to an organization?
– Takes too much time to clean up and document
DevOps assets?

10. Containers gone wild
J
• Docker = “Micro VMs”
– Includes all dependencies
– One process per container
– Similar to BSD Jails, Solaris
Zones
• Docker in Production?
– Still not for the faint of heart...

11. Kubernetes
J
• Containers alone are not sufficient. They
need orchestration, container networking,
service lookup, rolling upgrades, placement
(affinity / non-affinity)
• Created by Google, based on 10+ years of
experience running containers at scale
• Container agnostic (Docker, Rocket, etc)
• Open source project

13. Demo of Docker (5 min)

14. Docker - What I learned
• Great for developers and “throw away” environments
• Docker fits best for 12factor, stateless applications
• Externalize persistence - it’s a lot of work to “pull apart”
applications
• Docker “data volumes”: How do you guarantee your
container is running on a node that has the data?
• Kubernetes data volumes are a higher level abstraction.
They are a network resource, not tied to a node
implemented using Google Persistent Disk, NFS, iSCSI
J

15. Questions?
J

16. DevOps Resources
Ansible http://www.ansible.com/resources
Jake’s Amazing
OpenIDM Vagrant
project
https://github.com/jakefeasel/openidm-
boilerplate/
frstack project https://github.com/ForgeRock/frstack
Puppet Module https://github.com/ConductAS/puppet-
openam
Kubernetes http://kubernetes.io

17. Thank You!
Warren Strange
Director, Sales Engineering
warren.strange@forgerock.com

18. Big Idea: OpenAM on Kubernetes
• Strategy
– Vanilla OpenAM / Tomcat Docker container, with no “personality”
– External OpenDJ config/CTS store
– K8 data volume holds ~/openam configuration directory
• Keystore, logs, bootstrap, service definitions
– Bootstrap script tweaks .openamcfg/ to point to the above k8 volume
• Use static DNS names for cluster networking
– openam-hosta.localdomain wired for SFO to openam-
hostb.localdomain
• Use realms, DNS aliases to “personalize” for target environment
– realm /acme, dns alias: acme.com
J