Structure des repositories

---

Table des matières

1. Principes d'organisation
2. Structure avec Kustomize
3. Structure avec Helm
4. Mono-repo vs Multi-repo
5. Conventions de nommage
6. Exercices pratiques

---

1 - Principes d'organisation

Objectifs

Objectif	Pourquoi
Clarté	Trouver rapidement ce qu'on cherche
Séparation	Isoler les environnements
Réutilisabilité	DRY (Don't Repeat Yourself)
Permissions	Contrôler qui peut modifier quoi

Structure type

gitops-repo/
├── README.md
├── .gitignore
├── apps/                    # Applications métier
│   ├── frontend/
│   ├── backend/
│   └── worker/
├── infrastructure/          # Composants plateforme
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
├── clusters/               # Configuration par cluster
│   ├── dev/
│   ├── staging/
│   └── prod/
└── base/                   # Ressources partagées
    └── namespaces/

Séparation App vs Infra

🔝 Retour à la table des matières

---

2 - Structure avec Kustomize

Base + Overlays

apps/
└── myapp/
    ├── base/
    │   ├── kustomization.yaml
    │   ├── deployment.yaml
    │   ├── service.yaml
    │   └── configmap.yaml
    └── overlays/
        ├── dev/
        │   ├── kustomization.yaml
        │   └── replicas-patch.yaml
        ├── staging/
        │   ├── kustomization.yaml
        │   └── replicas-patch.yaml
        └── prod/
            ├── kustomization.yaml
            ├── replicas-patch.yaml
            └── resources-patch.yaml

Base (ressources communes)

# apps/myapp/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yaml
  - service.yaml
  - configmap.yaml

commonLabels:
  app: myapp

# apps/myapp/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1  # Valeur par défaut
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:latest
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"

Overlay (personnalisation par env)

# apps/myapp/overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: production

resources:
  - ../../base

patches:
  - path: replicas-patch.yaml
  - path: resources-patch.yaml

images:
  - name: myapp
    newTag: v1.2.3

# apps/myapp/overlays/prod/replicas-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 5

# apps/myapp/overlays/prod/resources-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
        - name: myapp
          resources:
            requests:
              memory: "512Mi"
              cpu: "500m"
            limits:
              memory: "1Gi"
              cpu: "1"

Tester Kustomize

# Voir le rendu final
kustomize build apps/myapp/overlays/prod

# Avec kubectl
kubectl kustomize apps/myapp/overlays/prod

🔝 Retour à la table des matières

---

3 - Structure avec Helm

Charts et Values

apps/
└── myapp/
    ├── Chart.yaml
    ├── values.yaml           # Valeurs par défaut
    ├── values-dev.yaml
    ├── values-staging.yaml
    ├── values-prod.yaml
    └── templates/
        ├── deployment.yaml
        ├── service.yaml
        └── configmap.yaml

Ou référencer des charts externes

apps/
└── myapp/
    ├── dev/
    │   └── helmrelease.yaml
    ├── staging/
    │   └── helmrelease.yaml
    └── prod/
        └── helmrelease.yaml

HelmRelease (Flux)

# apps/myapp/prod/helmrelease.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: myapp
  namespace: production
spec:
  interval: 5m
  chart:
    spec:
      chart: myapp
      version: 1.2.3
      sourceRef:
        kind: HelmRepository
        name: internal-charts
  values:
    replicaCount: 5
    image:
      tag: v1.2.3
    resources:
      requests:
        memory: 512Mi

ArgoCD avec Helm

# Application ArgoCD avec Helm
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod
spec:
  source:
    repoURL: https://github.com/org/gitops-repo
    path: apps/myapp
    helm:
      valueFiles:
        - values-prod.yaml

🔝 Retour à la table des matières

---

4 - Mono-repo vs Multi-repo

Mono-repo

gitops-monorepo/
├── apps/
│   ├── app1/
│   ├── app2/
│   └── app3/
├── infrastructure/
└── clusters/

Avantages	Inconvénients
Vue unifiée	Permissions complexes
Atomic changes	Repo volumineux
CI/CD simplifié	Blast radius large

Multi-repo

org/gitops-apps-team-a
org/gitops-apps-team-b
org/gitops-infrastructure
org/gitops-cluster-prod

Avantages	Inconvénients
Permissions fines	Vue fragmentée
Équipes autonomes	Coordination difficile
Blast radius limité	Duplication

Hybride recommandé

# Repo 1: Infrastructure (platform team)
gitops-infrastructure/
├── cert-manager/
├── ingress/
└── monitoring/

# Repo 2: Applications (dev teams)
gitops-apps/
├── team-a/
│   ├── service1/
│   └── service2/
└── team-b/
    └── service3/

# Repo 3: Clusters (platform team)
gitops-clusters/
├── dev/
├── staging/
└── prod/

🔝 Retour à la table des matières

---

5 - Conventions de nommage

Fichiers

# Ressources Kubernetes
deployment.yaml          # Bon
myapp-deployment.yaml    # Acceptable
myapp.deployment.yaml    # Acceptable

# Patches Kustomize
replicas-patch.yaml
resources-patch.yaml
ingress-patch.yaml

# Values Helm
values.yaml              # Base
values-dev.yaml          # Par environnement
values-prod.yaml

Dossiers

# Style kebab-case
apps/my-awesome-app/     # Bon
apps/my_awesome_app/     # Moins standard
apps/MyAwesomeApp/       # À éviter

# Environnements
overlays/dev/
overlays/staging/
overlays/prod/
# ou
environments/development/
environments/staging/
environments/production/

Commits

# Format
<type>(<scope>): <description>

# Types
feat:     Nouvelle fonctionnalité
fix:      Correction de bug
chore:    Maintenance
docs:     Documentation
refactor: Refactoring

# Exemples
feat(frontend): deploy v2.3.0
fix(backend): increase memory to 1Gi
chore(deps): update nginx-ingress to 1.9.0

Branches

# Pour les PR
feature/add-new-service
fix/increase-backend-memory
chore/update-monitoring

# Environnements (si branch per env)
main        # Production
staging
develop

🔝 Retour à la table des matières

---

6 - Exercices pratiques

Quiz

Q1. Quelle est la différence entre base et overlays dans Kustomize ?

Réponse

• base : Ressources communes partagées entre tous les environnements
• overlays : Personnalisations spécifiques par environnement (dev, staging, prod)

Q2. Quand préférer Kustomize vs Helm ?

Réponse

• Kustomize : Manifests simples, patches légers, pas de templating complexe
• Helm : Charts complexes, variables nombreuses, charts externes à utiliser

Exercice : Structurer un repo

Créez la structure pour :

• 3 microservices
• 2 environnements (dev, prod)
• Utilisation de Kustomize

Solution

gitops-repo/
├── apps/
│   ├── api/
│   │   ├── base/
│   │   │   ├── kustomization.yaml
│   │   │   ├── deployment.yaml
│   │   │   └── service.yaml
│   │   └── overlays/
│   │       ├── dev/
│   │       │   └── kustomization.yaml
│   │       └── prod/
│   │           └── kustomization.yaml
│   ├── frontend/
│   │   ├── base/
│   │   └── overlays/
│   │       ├── dev/
│   │       └── prod/
│   └── worker/
│       ├── base/
│       └── overlays/
│           ├── dev/
│           └── prod/
└── clusters/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

🔝 Retour à la table des matières

---

Points clés à retenir

• Séparer apps et infrastructure
• Kustomize : base + overlays pour éviter la duplication
• Helm : pour les charts complexes ou externes
• Mono-repo pour petites équipes, Multi-repo pour grandes orgs
• Conventions de nommage et commits cohérentes

🔝 Retour à la table des matières

---

← Chapitre précédent | Chapitre suivant : Gestion des secrets →