Interview Prep DevOps

Un processus est une instance indépendante d'un programme avec son propre espace mémoire. Un thread est une unité d'exécution au sein d'un processus qui partage le même espace mémoire. Les threads sont plus légers à créer et permettent le parallélisme au sein d'un même processus.

r=read(4), w=write(2), x=execute(1). Trois groupes : owner, group, others. chmod 755 = rwxr-xr-x. chmod +x ajoute l'exécution. Les permissions s'appliquent aux fichiers et répertoires (x = accéder au contenu du dossier).

/proc est un système de fichiers virtuel (pseudo-filesystem) qui expose les informations du kernel et des processus en cours. Chaque PID a un répertoire. /proc/cpuinfo, /proc/meminfo donnent les infos hardware. Il n'occupe pas d'espace disque réel.

Hard link : pointe directement vers l'inode du fichier, même données. Ne fonctionne pas cross-filesystem ni sur les répertoires. Soft link (symlink) : fichier spécial contenant le chemin vers la cible. Peut être cross-filesystem, peut pointer vers des dossiers, devient cassé si la cible est supprimée.

1) uptime (load average), 2) dmesg | tail (erreurs kernel), 3) vmstat 1 (CPU, mémoire, I/O), 4) iostat -x 1 (disque), 5) free -h (mémoire/swap), 6) top/htop (processus), 7) ss -tlnp (connexions réseau), 8) journalctl -p err (logs erreurs). Méthode USE : Utilisation, Saturation, Erreurs pour chaque ressource.

systemd est le système d'init et gestionnaire de services de Linux. Commandes : systemctl start/stop/restart/status service. systemctl enable pour le démarrage auto. journalctl -u service pour les logs. Les unit files sont dans /etc/systemd/system/.

Une image est un template read-only composé de layers. Un container est une instance en cours d'exécution d'une image avec une couche writable (copy-on-write). Analogie : l'image est la classe, le container est l'objet instancié.

Docker accumule des ressources inutilisées : images dangling (sans tag), containers arrêtés, volumes orphelins, networks inutilisés. docker system prune nettoie tout. docker image prune supprime les images dangling. Les layers partagées entre images ne sont supprimées que quand plus aucune image ne les référence.

Le multi-stage build utilise plusieurs FROM dans un Dockerfile. Chaque stage peut copier des artefacts du précédent avec COPY --from. Intérêt : image finale légère (sans les outils de build), meilleure sécurité (surface d'attaque réduite), build reproductible. Exemple : stage 1 compile en Go, stage 2 copie le binaire dans scratch.

Bridge (défaut) : réseau privé interne, containers communiquent via IP/DNS. Host : container utilise directement le réseau de l'hôte. Overlay : réseau multi-host pour Swarm/orchestration, encapsule le trafic via VXLAN. None : pas de réseau. Macvlan : donne une MAC address au container.

1) Image de base minimale (alpine, distroless), 2) USER non-root, 3) Scan de vulnérabilités (Trivy, Snyk), 4) .dockerignore, 5) Pas de secrets dans l'image, 6) Read-only filesystem, 7) Health checks, 8) Pin les versions (pas :latest), 9) Signer les images (Docker Content Trust), 10) Limiter les capabilities.

ENTRYPOINT définit la commande principale du container (difficilement overridable). CMD fournit les arguments par défaut. Avec ENTRYPOINT ['python'] et CMD ['app.py'], le container lance 'python app.py'. CMD seul peut être complètement overridé au docker run. Best practice : ENTRYPOINT pour le binaire, CMD pour les args par défaut.

Un Pod est la plus petite unité déployable dans K8s. Il contient un ou plusieurs containers qui partagent le même réseau (localhost), le même stockage (volumes) et le même lifecycle. Les containers dans un Pod sont co-schedulés sur le même node. Cas d'usage multi-container : sidecar (logging, proxy), init containers.

ClusterIP (défaut) : IP interne au cluster, accessible uniquement depuis l'intérieur. NodePort : expose sur un port statique de chaque node (30000-32767). LoadBalancer : provisionne un LB cloud externe. Le Service utilise des selectors pour router vers les Pods via kube-proxy (iptables/IPVS).

L'Ingress Controller est un reverse proxy (nginx, traefik, HAProxy) qui lit les ressources Ingress pour configurer le routage HTTP/HTTPS. Il gère le TLS termination, le path-based routing, le virtual hosting. Sans Ingress Controller déployé, les ressources Ingress n'ont aucun effet.

Le kube-scheduler assigne les Pods aux Nodes en deux phases : 1) Filtering : élimine les nodes qui ne répondent pas aux contraintes (resources, taints, affinity). 2) Scoring : classe les nodes restants selon des critères (spread, resource balance). On peut influencer avec nodeSelector, nodeAffinity, podAffinity, taints/tolerations, topology spread constraints.

Deployment : workloads stateless, rolling updates, Pods interchangeables. StatefulSet : workloads stateful, identité réseau stable (pod-0, pod-1), PVC par Pod, ordre de déploiement garanti (bases de données). DaemonSet : un Pod par node (monitoring, logging, networking). Chacun a son controller dans le control plane.

Les Secrets K8s natifs sont encodés en base64 (pas chiffré !). Solutions : 1) Encryption at rest (EncryptionConfiguration), 2) External Secrets Operator (AWS SM, Vault), 3) Sealed Secrets (chiffrement asymétrique), 4) SOPS, 5) Vault avec CSI driver. RBAC strict sur les secrets. Éviter de les monter en env vars (visibles dans /proc).

Liveness : le container est-il vivant ? Si fail → restart. Readiness : le container accepte-t-il du trafic ? Si fail → retiré du Service. Startup : le container a-t-il fini de démarrer ? Désactive les autres probes pendant le démarrage. Types : httpGet, tcpSocket, exec. Configurer initialDelaySeconds, periodSeconds, failureThreshold.

Le state (terraform.tfstate) est le mapping entre la configuration HCL et les ressources réelles. Il permet à Terraform de savoir ce qui existe, ce qui doit changer. Sans state = tout recréer. Remote state (S3, GCS) + locking (DynamoDB) pour le travail en équipe. Ne jamais commiter le state (contient des secrets).

plan : dry-run qui compare le state actuel avec la configuration désirée et affiche les changements prévus (+create, ~update, -destroy). apply : exécute réellement les changements. Best practice : toujours plan avant apply, utiliser -out=plan.tfplan pour garantir que l'apply correspond exactement au plan reviewé.

1) Modules réutilisables (modules/), 2) Environnements séparés (envs/dev, envs/prod) ou workspaces, 3) Remote backend avec locking, 4) Variables via tfvars par env, 5) CI/CD pipeline (plan en PR, apply après merge), 6) Terragrunt pour le DRY, 7) State par composant (réseau, compute, data séparés), 8) Policy as code (Sentinel, OPA).

Un module est un ensemble de fichiers .tf réutilisable. Structure : main.tf, variables.tf, outputs.tf. Appelé avec module block + source (local, git, registry). Les variables sont les inputs, les outputs exposent les valeurs. Best practices : versionner, documenter, tester avec terratest.

Le drift survient quand les ressources sont modifiées hors Terraform. terraform plan détecte le drift. terraform refresh met à jour le state (implicite depuis 0.15.4). Solutions : 1) Interdire les modifs manuelles, 2) Drift detection en CI (plan scheduled), 3) terraform import pour les ressources manuelles, 4) Alerting sur les changements non-Terraform.

CI (Continuous Integration) : merge fréquent + build + tests automatiques. CD (Continuous Delivery) : le code est toujours prêt à être déployé, mais le déploiement en prod est manuel. Continuous Deployment : le déploiement en prod est aussi automatique après les tests. Delivery = bouton, Deployment = full auto.

Deux environnements identiques (Blue=actuel, Green=nouveau). 1) Déployer la nouvelle version sur Green, 2) Tester Green, 3) Switcher le load balancer/DNS vers Green, 4) Blue devient le rollback. Avantages : rollback instantané, zero downtime. Inconvénient : double infrastructure, migration de données complexe.

Déployer la nouvelle version sur un petit pourcentage de trafic (ex: 5%), monitorer les métriques (erreurs, latence), puis augmenter progressivement. Outils : Istio, Flagger, Argo Rollouts. Avantages : détection précoce des problèmes, impact limité. Métriques clés : error rate, latency p99, saturation.

1) Secrets dans un vault (pas dans le repo), 2) SAST/DAST dans le pipeline, 3) Scan d'images (Trivy), 4) Signature des artefacts (Sigstore/Cosign), 5) RBAC sur le runner, 6) Audit logs, 7) Branch protection + code review, 8) Pinning des actions/images, 9) Network isolation des runners, 10) SBOM (Software Bill of Materials).

GitOps utilise Git comme source de vérité pour l'infrastructure et les applications. Un opérateur (ArgoCD, Flux) surveille le repo et synchronise l'état du cluster avec le repo. Push-based (CI applique) vs Pull-based (opérateur reconcilie). Avantages : auditabilité, rollback via git revert, déclaratif, self-healing.

GitHub Actions : YAML-based, marketplace d'actions, hosted runners, intégré à GitHub. GitLab CI : YAML, intégré à GitLab, runners self-hosted faciles, DevSecOps intégré. Jenkins : le plus flexible, Groovy pipelines, énorme écosystème de plugins, mais complexe à maintenir. Tendance : managed > self-hosted.

SLO (Service Level Objective) = cible de fiabilité mesurable. Basé sur des SLI (indicators) : disponibilité, latence, error rate. Exemple : 99.9% des requêtes < 200ms sur 30 jours. Error budget = 100% - SLO (ex: 0.1% = 43 min/mois de downtime autorisé). Si le budget est consommé → freeze des features, focus fiabilité.

Prometheus : TSDB qui scrape des métriques (pull model) via HTTP. PromQL pour les requêtes. Alertmanager pour les alertes. Grafana : visualisation, dashboards, supporte multiple datasources. Exporters : node_exporter (système), blackbox (endpoints), custom. Service discovery pour K8s. Retention limitée → Thanos/Mimir pour le long terme.

Métriques : données numériques agrégées dans le temps (CPU, requêtes/s). Logs : événements textuels horodatés (erreurs, actions). Traces : suivi d'une requête à travers les services (distributed tracing, spans). Les 3 piliers de l'observabilité. Outils : Prometheus (métriques), Loki/ELK (logs), Jaeger/Tempo (traces). Corrélation entre les trois = clé.

1) Alerter sur les symptômes, pas les causes, 2) Chaque alerte doit être actionnable, 3) Définir des niveaux (P1-P4), 4) Runbooks liés aux alertes, 5) Grouping et deduplication (Alertmanager), 6) Silences et inhibitions, 7) Review régulière des alertes (supprimer les inutiles), 8) On-call rotation (PagerDuty, OpsGenie), 9) SLO-based alerting (burn rate).

Les 4 Golden Signals (Google SRE) : 1) Latency : temps de réponse, 2) Traffic : demande sur le système (req/s), 3) Errors : taux d'erreurs, 4) Saturation : combien le système est 'plein' (CPU, mémoire, I/O). Alternative : méthode RED (Rate, Errors, Duration) pour les services, USE (Utilization, Saturation, Errors) pour les ressources.

Chaque utilisateur, processus ou service ne doit avoir que les permissions strictement nécessaires à son fonctionnement. Application : IAM roles granulaires, RBAC K8s, sudo limité, network policies restrictives, containers non-root. Réduire la surface d'attaque. Régulièrement auditer et révoquer les permissions inutilisées.

Handshake TLS : 1) Client Hello (cipher suites supportées), 2) Server Hello (certificat + cipher choisie), 3) Échange de clés (asymétrique → clé session), 4) Communication chiffrée (symétrique, AES). Le certificat est signé par une CA. Let's Encrypt pour les certs gratuits. TLS 1.3 = plus rapide (1-RTT handshake).

Zero Trust = 'never trust, always verify'. Pas de réseau de confiance. Chaque requête est authentifiée et autorisée. Implémentation : 1) Identity-based access (pas IP-based), 2) mTLS entre services, 3) Service mesh (Istio), 4) MFA, 5) Micro-segmentation réseau, 6) Continuous verification, 7) Least privilege, 8) Device posture checks.

1) RBAC strict, 2) Network Policies, 3) Pod Security Standards, 4) Secrets chiffrés, 5) Image scanning, 6) Admission controllers (OPA/Kyverno), 7) Audit logging, 8) mTLS (service mesh), 9) Pas de privileged containers, 10) Limiter les API server access, 11) Rotation des certificats, 12) Runtime security (Falco).

Authentification (AuthN) : vérifier l'identité (qui es-tu ?). Méthodes : password, token, certificat, MFA, SSO/OIDC. Autorisation (AuthZ) : vérifier les permissions (que peux-tu faire ?). Méthodes : RBAC, ABAC, ACL, policies. D'abord AuthN, puis AuthZ. Exemple K8s : ServiceAccount (AuthN) + Role/RoleBinding (AuthZ).

1) Vault (HashiCorp) : gestion centralisée, rotation, audit, dynamic secrets. 2) AWS Secrets Manager / GCP Secret Manager. 3) Sealed Secrets pour K8s. 4) SOPS pour les fichiers chiffrés dans Git. Principes : rotation régulière, audit d'accès, pas de secrets dans le code/images, injection à runtime (pas build time).

IaC = gérer l'infrastructure via du code déclaratif versionné. Outils : Terraform, Pulumi, CloudFormation, Ansible. Avantages : reproductibilité, versioning (git), review process, documentation vivante, automatisation, disaster recovery rapide. Impératif (Ansible) vs Déclaratif (Terraform). Immutable infra vs mutable.

CALMS : Culture (collaboration dev/ops), Automation (CI/CD, IaC), Lean (éliminer le gaspillage, flow), Measurement (métriques, feedback), Sharing (knowledge sharing, blameless postmortems). DevOps n'est pas un rôle mais une culture. DORA metrics : deployment frequency, lead time, MTTR, change failure rate.

1) Détection (monitoring, alerting), 2) Triage (severity P1-P4), 3) Communication (status page, Slack), 4) Mitigation (rollback, feature flag, scaling), 5) Root cause analysis, 6) Fix permanent, 7) Blameless postmortem (timeline, impact, actions), 8) Follow-up items. Outils : PagerDuty, incident.io. Commander/Communicator/Ops roles.

Platform Engineering construit une Internal Developer Platform (IDP) : self-service pour les devs (déploiement, environnements, monitoring). Backstage, Crossplane, Kratix. Diffère du DevOps : les devs n'ont pas besoin de comprendre l'infra en détail, la plateforme abstrait la complexité. Golden paths, pas de gatekeeping.

Monolithe : une seule app, simple à déployer/débugger, scaling vertical, couplage fort. Microservices : services indépendants, scaling granulaire, polyglotte, mais complexité opérationnelle (réseau, data consistency, observabilité). Commencer monolithe, migrer quand nécessaire. Le 'modular monolith' est un bon compromis.

Pratiquer des expériences contrôlées pour découvrir les faiblesses du système. Principes : hypothèse, blast radius limité, état stable, automatiser. Outils : Chaos Monkey (Netflix), Litmus, Gremlin, chaos-mesh. Types : kill pod, network latency, CPU stress, AZ failure. Game days pour l'équipe. Construire la confiance dans le système.

Les feature flags permettent d'activer/désactiver des fonctionnalités sans redéployer. Outils : LaunchDarkly, Unleash, Flagsmith, custom (DB/config). Types : release flags, experiment flags, ops flags, permission flags. Avantages : déploiement découplé du release, canary par feature, kill switch. Nettoyer les flags obsolètes !

GitFlow : branches develop, feature, release, hotfix. Complexe, merge conflicts, long-lived branches. Trunk-Based : tout le monde commit sur main/trunk, feature flags pour le WIP, branches très courtes (<1 jour). Trunk-based est recommandé par DORA (corrélé à la haute performance). CI/CD plus facile avec trunk-based.