Le document traite du déploiement, de l'orchestration et de la sécurisation d'APIs, en présentant différents scénarios (startup, hybride, entreprise) correspondant à divers types de projets. Une méthodologie est décrite, ainsi qu'une comparaison de technologies telles que Docker, Kubernetes, et des outils d'IAM, mettant en avant des choix basés sur des critères de coût et de fonctionnalité. Les résultats montrent une préférence pour Keycloak pour les scénarios de startup en raison de sa simplicité et de sa gratuité, ainsi que des impressions positives sur les autres technologies évaluées.

1. Veille technologique
Déploiement, orchestration & sécurisation d’APIs
M1 APP
Steeven Alliel, Abdel Benamara, David Ekchajzer, Philippe Fidalgo, Mathieu Ridet, Sophia Yalap

2. I - Contexte
a) Existant
b) Méthodologie
c) Cahier des charges
II - Comparaison des technologies
a) Conteneurisation
b) Orchestration
c) Routage
d) Déploiement
e) IAM - Identity & Access Management
Plan
III - Scénarios
a) Scénario startup
b) Scénario hybride
c) Scénario entreprise
Conclusion

3. Glossaire
● On premise
● Cloud based
● IAM
● SSO
● SSL
● Conteneurisation
● Orchestration
● Routage
● API
● Déploiement
● Authentification
● Autorisation

4. Contexte

5. Existant - Micro-services

6. Existant - Déploiement

7. Existant - Accès & sécurisation

8. Méthodologie
Scénario Startup
Scénario facile à mettre en place, peu cher et ne nécessitant
pas d'équipe dédiée pour la maintenance. Le scénario est
adapté dans le cadre d'une startup ou d'un projet léger de
type POC.
Scénario Hybride
Scénario hybride avec orchestration. Le scénario est adapté
dans le cadre d'un petit projet industrialisé.
Scénario Entreprise
Scénario haut niveau avec orchestration idéale pour les
grosses entreprises nécessitant d'un support technique et
bénéficiant d'une équipe dédié au DevOps.

9. Cahier des charges
Le cahier des charges nous a permis de
pré-sélectionner certaines technologies
qui ont pu être analysées en détail
Nous avons ajouté le fait que les technologies
devaient être disponible “on premise” (sauf pour
le déploiement) puisque nous devrons les
implémenter sur des serveurs virtuels possédés

10. Technologies retenues
pour l’évaluation

11. Conteneurisation
3 technologies sont majoritairement utilisé dans l’industrie :
Nous n’avons pas fait de comparaison détaillée pour la conteneurisation car l'adoption de
Docker par la communauté est incomparable aux deux autres technologies.
Docker est le standard.
Si besoin, les noyaux des 3 technologies étant les mêmes, il est possible de migrer depuis
Docker sans problème.

12. Orchestration
On-premise Cloud-based
Seuls les orchestrateurs On-premise ont été retenus. En effet les solutions Cloud-based ne
correspondaient pas à ce qui était recherché pour notre projet, principalement à cause de
leur prix élevé contraire à notre focalisation sur le gratuit et l’open source.
Parmi les technologies comparées, on retrouve deux solutions utilisant Kubernetes car à
l’instar de Docker, Kubernetes s’est révélé être un standard depuis quelques années.

13. Routage
Nous avons décidé de comparer les routeurs aux orchestrateurs car ils répondent au besoin d’API
gateway énoncé dans le cahier des charges.
Même s’ils ne sont pas des orchestrateurs, il est nécessaire d’avoir des routeurs qui puissent gérer
facilement les conteneurs.
Il est important que nos conteneurs s'enregistrent eux-mêmes auprès de notre routeur pour que les
requêtes soient redirigées vers les applications dockerisées.

14. Déploiement
3 principales technologiques ont été retenues car elles représentent les
solutions les plus utilisées par la communauté tout étant facilement
interfaçables avec Github, le répertoire de code utilisé pour le projet.

15. IAM
Il existe une multitude d’outils IAM. Nos choix se sont portés
essentiellement sur ceux permettant le SSO et qui remontent
principalement dans les différents forums.
En plus de cela, le coût, les protocoles utilisés et la gestion des
droits/rôles ont été également des facteurs de choix importants.
Les technologies retenues sont :
1 2 3 4 5

16. Scénarios

17. Pondérations intéressantes
Scénario facile à mettre en place, peu cher et ne nécessitant pas
d'équipe dédiée pour la maintenance. Le scénario est adapté dans le
cadre d'une startup ou d'un projet léger de type POC.
Communauté
Traefik Labs Community
(https://community.traefik.io/)
3
Open source Oui 1
Facilité de maintenance Dashboard 3
Facilité de mise en place Quelques lignes de commande 3
Scalabilité Non 0
Facilité de micro-service
Ecoute l'API Docker pour détecter de nouveaux
services
2
Scénario Startup

18. 61/69 85/93 127/138
Scénario Startup - Résultats

20. Le choix de Keycloack
Suite à l’étude comparative notre choix s’est porté
sur Keycloak pour les trois scénarios pour ses
nombreux points forts :
● Gratuit & open source
● Configuration & maintenance simple
● Gestion des droits/rôles très optimisée
● Le tout en permettant l’utilisation des meilleurs protocoles et
standards d’authentification actuels

21. Prise en main & Impressions de Keycloack
Pré-requis :
docker run - p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:12.0.4
Démarrage :
Keycloak Admin Console
Interface web de Keycloak
Source : https://www.keycloak.org/getting-started/getting-started-docker

22. Tuto Installation et utilisation Traefik avec Docker :
Bien expliqué dans le tuto et bien documenté dans la doc Traefik et Docker
https://hub.docker.com/_/traefik
https://doc.traefik.io/traefik/getting-started/quick-start/
https://www.youtube.com/watch?v=ZOeNdC37OwE
Scénario Startup - Impressions
Facile d’installation, de
maintenance et d’utilisation.
Source :
https://github.com/padok-team/githu
b-actions-tutorial

23. Scénario hybride avec orchestration. Le scénario est adapté dans le
cadre d'un petit projet industrialisé.
Communauté Blog + Github + Events 3
Open source Github 3
Facilité de maintenance Dashboard 3
Facilité de mise en place Quelques lignes de commande 2
Scalabilité Natively from Kubernetes 2
Facilité de micro-service Natively from Kubernetes 2
Pondérations intéressantes
Scénario Hybride

24. 51/60 96/114 125/135
Scénario Hybride - Résultats

26. Scénario Hybride - Impressions
Source : https://kubernetes.io/fr/docs/tutorials/kubernetes-basics/
Ces tutoriels étaient très complets, facile à suivre et à prendre en main, notamment grâce à
la possibilité de suivre les enseignements directement en tapant les lignes de commande sur
un terminal connecté à l’instance de démonstration virtualisée sur un serveur distant.
Le temps estimé pour finir les 6 chapitres est de 3 à 4 heures.

27. Scénario Hybride
Source : https://medium.com/weekly-webtips/your-next-dockerized-spring-boot-application-with-travis-and-heroku-83800b3a3ad8
Technologie assez simple de prise en
main. Nécessite quelques connaissances
en CI/CD pour une mise en place et
maintenance facilitée. Malgré tout,
demeure assez simple d’utilisation
avec du paramètrage essentiellement
via des fichiers YAML de
configuration.

28. Scénario Entreprise
Pondérations intéressantes
Scénario haut niveau avec orchestration, idéale pour les
grosses entreprises nécessitant un support technique et
bénéficiant d'une équipe dédiée au DevOps.
Communauté
Grande communauté et réactivité aux bug remonté
par la communauté importante (DevOps)
2
Open source Open source 3
Facilité de maintenance
Dashboard dédié, paramétrage plus complexe pour
des cas plus spécifiques
1
Facilité de mise en place Quelques lignes de commande 1
Scalabilité Natively from Kubernetes 3
Facilité d’ajout de micro-service Natively from Kubernetes 1

29. 41/45 98/111 126/135
Scénario Entreprise

31. Scénario Entreprise
OpenShift est assez rapide à
prendre en main pour les
opérations de base notamment
grâce à la web console et la
vue topologique. Cependant,
pour les opérations plus
complexes, le paramétrage est
assez sensible.
https://learn.openshift.com

32. Scénario Entreprise
Jenkins est, globalement, assez
rapide à prendre en main grâce à ses
interfaces web de configuration.
Outil d’intégration continue très
complet notamment via l’ajout de
plugins très développé.
Source : https://www.tutorialspoint.com/jenkins/index.htm

33. Conclusion