Kubernetes et les technologies cloud sont aujourd'hui les standards pour déployer des applications de toutes sortes dans le cloud: api, batchs, microservices et même des monolithes! Ils apportent des solutions à beaucoup de problèmes mais aussi une grande complexité. Il peut donc être très difficile pour les développeurs et concepteurs d'identifier les contraintes de telles architectures. Dans cette présentation, vous (re)découvrirez dix astuces et conseils que j'ai pu appliquer et qui m'ont aidé dans mes derniers projets. Ces derniers traiteront : de l'environnement de l'application du choix des solutions techologiques du développement des contraintes de conception liées à K8S et plus encore !

1. Checklist pour concevoir
une application dans le
cloud
10 conseils à l'attention des concepteurs
Alexandre Touret / @touret_alex

2. Alexandre Touret
Architecte / Développeur
#Java #API #CI
#Software_Craftsmanship
2
@touret_alex https://blog.touret.info

3. Un peu de
contexte ...
1.

4. 4

5. Technologies
utilisées
5

6. En avez vous
VRAIMENT
besoin ?

7. Application gestion
Périmètre maîtrisé
Déploiement déjà automatisé
7

8. Quelles sont les
contraintes techniques?
Avez-vous des SLOs contraignantes?
(ex. disponibilité supérieure à 99%)
Avez vous vraiment besoin de scaler dynamiquement votre
application ?
8

9. Mise à disposition
d’environnements
9
Avez vous besoin de délivrer des environnements à la
demande (et très rapidement)?

10. Les bases de
Docker & Cie

11. 11

12. Il vous faudra
connaître
12

13. 13

14. Le contexte

15. « les organisations qui conçoivent
des systèmes [...] tendent
inévitablement à produire des
designs qui sont des copies de la
structure de communication de
leur organisation. »
— M. Conway
15

16. Quel est le RACI ?
Est-ce que votre organisation est compatible ?
16
RACI &
Responsabilités

17. Les
applications
stateless et les
autres ...

18. 18
Codebase
One codebase tracked in revision
control, many deploys
Dependencies
Explicitly declare and isolate
dependencies
Config
Store config in the environment
Backing Services
Treat backing services as attached
resources
Build, release, run
Strictly separate build and run
stages
Backing Services
Treat backing services as attached
resources
Processes
Execute the app as one or more
stateless processes
Port Binding
Export services via port binding
Disposability
Maximize robustness with fast
startup and graceful shutdown
Dev/prod parity
Keep development, staging, and
production as similar as possible
Logs
Treat logs as event streams
Admin processes
Run admin/management tasks as
one-off processes
Source: https://12factors.net

19. 19
Pour une API

20. Démarrage
(rapide) de
l’application

21. 21

22. Bien choisir ses
frameworks et
environnements
d’exécution

23. 23

24. 24
Items à identifier
✓ Rapidité du démarrage
✓ Gestion des arrêts
✓ Capacité à s’intégrer dans Docker et K8S
✓ Observabilité
✓ Mémoire et CPU utilisées
✓ Gestion des dépendances et du patch management

25. TOMCAT vs FAT JARS
→ Un compromis Production - Équipes de développement
25

26. L’ observabilité

27. Adresser sur ce sujet
dès la conception !
Ne pas attendre la mise en production :)
Exposer via des endpoints REST l’état de votre système
Faire attention aux FRAMEWORKS utilisés
27

28. liveness &
readiness probes
livenessProbe:
failureThreshold: 3
httpGet:
path: /actuator/health/liveness
port: http
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
28
readinessProbe:
failureThreshold: 3
httpGet:
path: /actuator/health/readiness
port: http
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 30
successThreshold: 1
timeoutSeconds: 1

29. Spring Actuator
management.health.probes.enabled=true
LivenessStateHealthIndicator & ReadinessStateHealthIndicator
29

30. 30
@Component
public class MongoDBActuatorHealthIndicator implements HealthIndicator {
[...]
@Override
public Health health() {
// ping database
}
@Override
public Health getHealth(boolean includeDetails) {
if (!includeDetails) {
return health();
} else {
var statuses = mongoDBHealthService.findStatusForAllConfigurations();
return Health.status(checkStatus(statuses)).withDetails(statuses).build();
}
}
[...]
}

31. Monitoring
▪ Prometheus
▪ Grafana
31

32. La CI/CD

33. Étapes à intégrer
dans votre chaîne
✓ Tests unitaires + intégration
✓ Création d’image Docker automatique
✓ “Smoke tests” de l’image crée
✓ Déploiement continu de la branche develop
✓ Déploiement de vos charts HELM (linter?)
✓ Déploiement d’une release
✓ ... 33

34. Exemple
Migration Spring Boot, Tomcat, JDK
Testé en local → Dev → Recette
⇒ En 1 jour
34

35. La
configuration

36. 36
▪ Variables d’environnement
▪ Config Maps
▪ Secrets

37. Les variables
d’environnement
spec:
containers:
- env:
- name: JAVA_OPTS
value: >-
-XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0
-Dfile.encoding=UTF-8 -
Djava.security.egd=file:/dev/./urandom
37

38. Les config maps
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2021-03-11T18:38:34Z
name: my-config-map
[...]
data:
JAVA_OPTS: >-
-XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0
-Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/./urandom
38

39. Quid des fichiers
de configuration ?
On peut les spécifier “comme des variables” directement
dans les config maps
On peut les externaliser
39

40. Les fichiers dans
les config maps
volumeMounts:
- mountPath: /config
name: configuration-volume
readOnly: true
[...]
volumes:
- configMap:
defaultMode: 420
name: configuration
name: configuration-volume
40
apiVersion: v1
kind: ConfigMap
[...]
data:
my.conf: {{- (.Files.Glob
"conf/*").AsConfig | nindent 2 }}

41. Externaliser les
valeurs
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
labels:
[...]
spec:
maxReplicas: {{ .Values.myapp.maxReplicaCount }}
minReplicas: {{ .Values.myapp.minReplicaCount }}
[...]
targetCPUUtilizationPercentage: {{ .Values.myapp.replicationThreesold }} 41

42. Le fichier
values.yml
myapp:
minReplicaCount: "2"
maxReplicaCount: "6"
replicationThreesold: 80
42

43. Les templates de
fichier
apiVersion: v1
kind: ConfigMap
metadata:
name: configuration
labels:
[...]
data:
application.properties:
|-
{{ tpl (.Files.Get "conf/application.properties") . | nindent 4}}
43

44. Les templates
Le fichier application.properties
logging.level.org.hibernate.stat={{
.Values.configmap.application.org_hib
ernate_stat }}
logging.level.org.springframework.sec
urity={{
.Values.configmap.application.org_spr
ingframework_security }}
44
Le fichier values.yml
configmap:
application:
org_hibernate_stat: ERROR
org_springframework_security:
ERROR

45. Les fichiers
binaires
apiVersion: v1
# Definition of secrets
kind: Secret
[...]
type: Opaque
# Inclusion of binary configuration files
data:
my_keystore.jks: {{ .Files.Get "secrets/my_keystore.jks" | b64enc }}
45

46. Logger
efficacement

47. L’utilisation des
logs
Dans la console:
kubectl logs --tail
Agrégateur de logs (ex. ELK)
47

48. Flux de sortie des
containers Docker
stdout & stderr
Inutile de configurer la sortie vers des fichiers
48

49. Bonnes pratiques
Indiquer dans vos LOGS:
Les éléments de votre conteneur (Image, containerID,...)
Les éléments de contexte K8S (IP POD, ID POD,
namespace,...)
Log4j Docker Support – Log4j Kubernetes Support
49

50. Pour aller plus loin
Vous pouvez logger et tracer les appels à vos APIS:
Requête, ID de l’appelant, ID de corrélation,...
zalando/logbook: An extensible Java library for HTTP request and response
logging
50

51. Merci!
Des questions?
@touret_alex
51
11 mars 2021

52. Sharing is caring!
Tweettez @TheCloudFirstIO #TCF21
et tentez de gagnez vos stickers collector !
10 gagnants seront tirés
au sort dans la journée

53. Cette session vous a plu ?
Faites-nous votre retour,
et gagnez peut-être l’un des
30 packs stickers collector!
https://feedback.thecloudfirst.io