Mise en place du CDK Forgeops:

Deuxième partie: déploiement de la plateforme en local.

18/05/2021

PRÉAMBULE:

Ce deuxième article a pour vocation de présenter une première approche sur la façon de déployer la plateforme ForgeRock sur Kubernetes. La plateforme ForgeRock Identity Platform TM peut être déployée de deux façons différentes, soit sur une machine en local (mais avec des possibilités moindres) soit dans le Cloud.

Dans notre cas, nous présenterons les étapes nécessaires pour déployer la plateforme en local grâce à l'utilisation de Minikube qui permet de mettre en place et de gérer le cluster Kubernetes. Cet environnement convient uniquement au développement et non à la mise en production.

Avant d'aller plus loin, il est fortement recommandé de lire notre premier article sur la configuration d'un environnement conteneurisé pour le déploiement de ForgeRock en local en cliquant ici.

Partie 1: configuration de l'environnement

Partie 2: déploiement du CDK forgeops en local (c'est ici)

Partie 3: personnalisation de la plateforme

Cet article puise ces sources de la documentation ForgeRock, pour plus de détails visiter le lien suivant : https://backstage.forgerock.com/docs/forgeops/7/start-here.html

DÉPLOIEMENT DU CDK:

La variable d'environnement suivante est nécessaire, il est nécessaire de la modifier afin de l'adapter à l'environnement de travail :

$ PATH_TO_FORGEOPS="/home/a3/forgeops"

Une fois l’environnement de développement configuré, la prochaine étape consiste à déployer la plateforme.

Exécutez la procédure suivante pour déployer ForgeRock Identity Platform dans l’espace de noms.

Aller dans le répertoire all:

$ cd ${PATH_TO_FORGEOPS}/kustomize/overlay/7.0/all

Ouvrir le fichier kustomization.yaml avec un éditeur de texte afin de le modifier comme suit:

namespace:default -> namespace: my-namespace

FQDN: default.iam.example.com -> my-namespace.iam.example.com

NB : le namespace et le FQDN ne doivent pas être les mêmes nécessairement. Par exemple, il est possible d’avoir namespace: my-namespace et FQDN : forgeops.iam.leviam.fr, le but étant d'éviter les confusions.

Enregistrer le fichier kustomization.yaml mis à jour.
Initialiser la zone de stockage (staging area) des profils de configuration avec le profil de configuration CDK. Cette étape consiste à copier le répertoire CDK dans une zone dite de stockage ou bien de transition afin de pouvoir travailler sur la plateforme sans modifier les paramètres de base. Cette staging area va justement servir pour la modification et la personnalisation de la plateforme et de facto des images docker.
Le script config.sh permet la mise en place de cette procédure. La commande config.sh init copie le profil de configuration CDK du répertoire principal pour les profils de configuration vers la zone de transition (staging area):

$ cd ${PATH_TO_FORGEOPS}/bin

$ ./config.sh init --profile cdk --version 7.0

source:https://backstage.forgerock.com/docs/forgeops/7/devops-develop.html

L’overwrite se fait grâce a la commande config.sh sync.

Pour plus de détails consulter la page suivante : https://github.com/ForgeRock/forgeops/blob/sustaining/7.0.x/README.md#managing-configurations

Dans le répertoire forgeops exécuter Skaffold pour créer des images Docker et déployer la plateforme d'identité ForgeRock:

$ cd ${PATH_TO_FORGEOPS}

$ skaffold run

ASTUCE À SAVOIR !

Dans le répertoire forgeops se trouve le fichier skaffold.yaml qui permet de lancer l'application. Skaffold permet justement de gérer différents profils et tous ces profils sont répertoriés dans le fichier skaffold.yaml. En effet, il est possible de ne pas forcement avoir besoin de toutes les ressources pour d'éventuels tests et de nécessiter uniquement de AM ou IDM par exemple. Ci-après un extrait du fichier skaffold.yaml montrant comment un profil est décrit.

# Sample profiles to launch / test just a specific product

- name: ig-only

build:

artifacts:

- *IG

tagPolicy:

sha256: {}

deploy:

kustomize:

path: ./kustomize/overlay/7.0/ig-only

- name: am-only

build:

artifacts:

- *AM

- *AMSTER

- *DS-CTS

- *DS-IDREPO

- *FORGEOPS-SECRETS

- *LDIF-IMPORTER

tagPolicy:

gitCommit: {}

deploy:

kustomize:

path: ./kustomize/overlay/7.0/am-only

Par conséquent, il suffira d'utiliser la commande skaffold run -p [PROFILE] afin de lancer le profil voulu qui correspond au besoin exprimé:

$ skaffold run -p am-only

En outre, il suffit juste d'explorer le fichier skaffold.yaml fournit lors du clonage du répertoire Git pour connaitre tous les profils disponibles. En revanche, il est également possible de modifier le fichier kustomization.yaml (décrit plus bas) et de supprimer et/ou ajouter les ressources voulues ainsi, uniquement les ressources spécifiées dans le fichier seront déployées.

COMMENT SE DÉROULE LE DÉPLOIEMENT ?

Pour déployer l’application, skaffold a besoin d’un fichier skaffold.yaml qu'il n’est pas nécessaire de modifier (qui se trouve dans le répertoire forgeops).

Ce fichier liste l'ensemble des profils de configurations disponibles pour déployer l'application en spécifiant les images Docker à construire et en spécifiant le répertoire où se trouve le fichier kustomization.yaml utilisé par kustomize pour stocker des instructions sur les modifications à apporter au jeu de ressources.

Par conséquent, lors de l’exécution de la commande skaffold run, skaffold utilise le fichier skaffold.yaml pour lancer l'application.

Dans le cas de figure présent, ce fichier permet de faire deux choses essentielles:

lancer le client Docker(1)
afin que celui-ci appelle le démon docker local(2)
- pour créer les images docker(qui sont "pull" de gcr.io/forgerock-io)(3)
- et utiliser kustomize(4)
- pour orchestrer le déploiement grâce a kubernetes(5).

Dans un premier temps, les images docker sont construites grâce à l’attribut build (cf. Default-artifacts définis plus haut dans le fichier) et dans un second temps le fichier de configuration kustomization.yaml est appelé (cf. ci-dessous dans annexe le contenu du fichier) et permet donc l’orchestration des ressources.

Dans le cas présent, lors de l’exécution de la commande run le profil par défaut est choisi.

source:https://backstage.forgerock.com/docs/forgeops/7/devops-minikube-cdk-concepts.html#figure-devops-implementation-deployment-minikube

Après le déploiement de l’application, voici un schéma montrant les pods qui ont été activés lors du déploiement.

Il est possible de les voir sur un terminal grâce à la commande:

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

admin-ui-67867b4766-db2vw 1/1 Running 0 20h

am-8bbf89b99-rpkng 1/1 Running 1 20h

amster-spxqv 0/1 Completed 0 20h

ds-cts-0 1/1 Running 0 20h

ds-idrepo-0 1/1 Running 0 20h

end-user-ui-6664576bdc-cwgs6 1/1 Running 0 20h

forgeops-secrets-d28mg 0/1 Completed 0 20h

idm-0 1/1 Running 1 20h

ldif-importer-t7gfw 0/1 Completed 0 20h

source:https://backstage.forgerock.com/docs/forgeops/7/devops-minikube-cdk-concepts.html#figure-devops-implementation-deployment-minikube

ACCÈS AUX CONSOLES D'ADMIN FORGEROCK:

Il est maintenant possible d'accéder aux outils permettant la personnalisation des images Docker de ForgeRock Identity Platform. Passer à l'interface utilisateur et à l'accès aux API pour plus d'informations sur l'utilisation des consoles d'administration et des API REST de ForgeRock à partir de l’environnement de développement. Une fois que tout est en place, l'accès à la plateforme se fait via l’URL suivante dans un navigateur (sur la machine virtuelle) https://my-namespace.iam.example.com/platform (dans mon cas de figure en fonction du FQDN choisi https://forgeops.iam.leviam.fr/platform):

Pour se connecter en tant qu'admin avec le nom d'utilisateur amadmin, il faut récupérer le mot de passe.

Pour ce faire, il faut lancer le script ./print-secrets.sh se trouvant dans le répertoire bin avec le paramètre amadmin passé en argument.

$ ./print-secrets.sh amadmin

interface de connexion de Frogerock AM

page d'accueil de la Forgerock stack

QUICK START: LISTE DES COMMANDES:

$ cd ${PATH_TO_FORGEOPS}/kustomize/overlay/7.0/all

$ cd ${PATH_TO_FORGEOPS}/bin

$ ./config.sh init --profile cdk --version 7.0

$ cd ${PATH_TO_FORGEOPS}

$ skaffold run

$ kubectl get pods

$ ./print-secrets.sh amadmin

PLUS DE DETAILS SUR LE FICHIER "kustomization.yaml":

Ce fichier représente la base du déploiement de la plateforme ForgeRock. Afin d'en appréhender correctement les concepts, il faut comprendre les ressources qui sont déployées. Le fichier kustomization.yaml est décrit ci-dessous et les ressources y sont expliquées juste après.

kustomization.yaml:

Espace de noms actif Kubernetes:
- Choix utilisateur: my-namespace
FQDN, le nom du réseau Minikube:
- Choix utilisateur: forgeops.iam.leviam.fr

namespace: my-namespace

commonLabels:

app.kubernetes.io/name: "forgerock"

resources:

- ../../../base/kustomizeConfig

- ../../../base/forgeops-secrets

- ../../../base/7.0/ds/cts

- ../../../base/7.0/ds/idrepo

- ../../../base/am

- ../../../base/amster

- ../../../base/idm

- ../../../base/end-user-ui

- ../../../base/login-ui

- ../../../base/admin-ui

- ../../../base/7.0/ingress

- ../../../base/ldif-importer

patchesStrategicMerge:

- |-

apiVersion: v1

kind: ConfigMap

metadata:

name: platform-config

data:

FQDN: forgeops.iam.leviam.fr

Explication des ressources:

kustomizeConfig: ressource permettant la configuration de l’outil kustomize
forgeops-secrets: génère un ensemble de secrets kubernetes (objet contenant une certaine quantité de données sensibles) utilisés par la plateforme.
ds-cts: héberge les sessions AM. Exécute le service d’annuaire LDAP utilisé par AM Core token service.
ds-idrepo: exécute plusieurs services d’annuaires. C’est un Directory Service (DS) configuré en référentiel d’identité.
am: ressource permettant la gestion des identités et des contrôles d’accès. Elle est connectée à un référentiel d’identité généralement un annuaire ldap. Elle permet de vérifier dans ids-repo le login et le mot de passe, c'est ce qui permet l'authentification
amster: interface en ligne de commande pour AM.
idm: gestion des identités orienté « provisionnement » c’est a dire avec propagation automatique des identités et des habilitations vers les ressources. En fait, c’est ce qui permet de connaître les identités, de connaitre les rôles qui leurs sont assignées ou plus simplement de référencer les habilitations.
ui-pods: les pods qui permettent l’accès aux interfaces utilisateurs :
- admin-ui
- end-user-ui
- login-ui
ingress: contrôle l’entrée sortie du cluster kubernetes.
ldif-importer: outil pour peupler l’annuaire avec des données.

L'application est maintenant déployée et prête à être customisée pour répondre aux besoins spécifiques.

Une prochaine fois, nous expliquerons comment créer des images Docker personnalisées afin de redéployer la plateforme (ici).