diff --git a/content/about/_index.en.md b/content/about/_index.en.md index 57de0de..c545e18 100644 --- a/content/about/_index.en.md +++ b/content/about/_index.en.md @@ -1,29 +1,29 @@ # About Me -🚀 As a **Network Automation Specialist at Airbus** — a major player in the **aerospace industry** — I'm dedicated to **simplifying network operations**, **reducing errors**, and **strengthening reliability** through **smart and innovative automation strategies**. +As a Network Automation Specialist at Airbus, I work on simplifying network operations, reducing errors, and improving reliability through automation. -Before that, I built a **solid foundation in network engineering** at **Nokia and Orange**. Over time, my **passion for innovation** naturally led me toward **network automation** — and I never looked back! đŸ’ĄđŸ€– +Before that, I spent several years building a foundation in network engineering at Nokia and Orange. Over time, my interest in automation grew, and I moved into that field full-time. -I'm also a **big believer in continuous learning** 📚. Within my team, I encourage a **culture of collective growth**, **knowledge sharing**, and **constant curiosity**. Because in the end, **tech moves fast — and we have to keep up!** đŸŒ±âœš +I also believe in continuous learning. Within my team, I encourage knowledge sharing and curiosity, since the technology keeps moving and we have to keep up with it. -## Professional Journey +## Professional journey -đŸ§‘â€đŸ’» **Network Automation Specialist @ Airbus** +**Network Automation Specialist @ Airbus** -Since 2023, I've been working at **Airbus** in Toulouse as a **Connectivity Automation Technology Specialist**. My mission? ✹ **Making networks smarter and more reliable** through automation. It's about optimizing efficiency, reducing errors, and building robust systems — both in the air and on the ground! đŸŒâœˆïž +Since 2023, I've worked at Airbus in Toulouse as a Connectivity Automation Technology Specialist, making networks more reliable through automation, both in the air and on the ground. -🔧 **Over 6 Years at Nokia** +**Over 6 years at Nokia** -At **Nokia**, I specialized in **access network engineering**. I designed high-performance configurations, validated new technologies such as **5G and fiber**, and led customer projects. I also mentored teams and trained newcomers đŸ‘šâ€đŸ«. It was an excellent school for **architecture**, **reliability**, and **real-world problem-solving**. +At Nokia, I specialized in access network engineering. I designed high-performance configurations, validated new technologies such as 5G and fiber, and led customer projects. I also mentored teams and trained newcomers. It was a good school for architecture, reliability, and real-world problem-solving. -🧠 **My Networking Beginnings at Orange & Beyond** +**Networking beginnings at Orange and beyond** -I started my career at **Orange** as a **network technician**, where I learned the basics — from installing telecom equipment to troubleshooting complex connectivity issues 🔌. Before that, I also served in the **French National Gendarmerie** 👼, an experience that taught me discipline and teamwork. +I started my career at Orange as a network technician, where I learned the basics, from installing telecom equipment to troubleshooting connectivity issues. Before that, I served in the French National Gendarmerie, an experience that taught me discipline and teamwork. -💡 **From the Field to Automation** +**From the field to automation** -Over the years, I moved from **hands-on engineering** to **network automation**, driven by my passion for innovation đŸ€–. Today, I focus on **automating processes**, improving **scalability**, and guiding teams toward the **future of networking**. +Over the years, I moved from hands-on engineering to network automation, driven by my interest in the field. Today, I focus on automating processes and improving scalability, and I help teams adopt the tools that come with that shift. -📚 **Lifelong Learner & Team Spirit Advocate** +**Lifelong learner, team player** -I believe in **collective growth**. Whether through knowledge sharing, curiosity, or experimenting with new ideas, I always try to create an environment where **learning is part of everyday life** đŸŒ±. +I believe in collective growth. Whether through knowledge sharing, curiosity, or experimenting with new ideas, I try to create an environment where learning is part of everyday work. diff --git a/content/about/_index.fr.md b/content/about/_index.fr.md index a8c3d4c..b63bf6c 100644 --- a/content/about/_index.fr.md +++ b/content/about/_index.fr.md @@ -1,29 +1,29 @@ # À propos de moi -🚀 En tant que **spĂ©cialiste de l'automatisation rĂ©seau chez Airbus** — un acteur majeur du **secteur aĂ©ronautique** — je me consacre Ă  **simplifier les opĂ©rations rĂ©seau**, **rĂ©duire les erreurs** et **renforcer la fiabilitĂ©** grĂące Ă  des **stratĂ©gies d'automatisation intelligentes et innovantes**. +En tant que spĂ©cialiste de l'automatisation rĂ©seau chez Airbus, je travaille Ă  simplifier les opĂ©rations rĂ©seau, rĂ©duire les erreurs et renforcer la fiabilitĂ© grĂące Ă  l'automatisation. -Avant cela, j’ai construit une **solide base en ingĂ©nierie rĂ©seau** chez **Nokia et Orange**. Avec le temps, ma **passion pour l’innovation** m’a naturellement menĂ© vers l’**automatisation rĂ©seau** — et je ne suis jamais revenu en arriĂšre ! đŸ’ĄđŸ€– +Avant cela, j'ai construit une base en ingĂ©nierie rĂ©seau chez Nokia et Orange. Avec le temps, mon intĂ©rĂȘt pour l'automatisation a grandi, et j'en ai fait mon mĂ©tier Ă  plein temps. -Je suis aussi un **grand adepte de l’apprentissage continu** 📚. Au sein de mon Ă©quipe, j’encourage une **culture de la croissance collective**, du **partage des connaissances** et de la **curiositĂ© permanente**. Car au final, **la tech Ă©volue vite — et nous devons en faire autant !** đŸŒ±âœš +Je crois aussi en l'apprentissage continu. Au sein de mon Ă©quipe, j'encourage le partage des connaissances et la curiositĂ©, parce que la technologie change vite et qu'il faut suivre le rythme. ## Parcours professionnel -đŸ§‘â€đŸ’» **SpĂ©cialiste de l'automatisation rĂ©seau @ Airbus** +**SpĂ©cialiste de l'automatisation rĂ©seau @ Airbus** -Depuis 2023, je travaille chez **Airbus** Ă  Toulouse en tant que **Connectivity Automation Technology Specialist**. Ma mission ? ✹ **Rendre les rĂ©seaux plus intelligents et plus fiables** grĂące Ă  l’automatisation. Il s’agit d’optimiser l’efficacitĂ©, de rĂ©duire les erreurs et de construire des systĂšmes robustes — aussi bien dans les airs qu’au sol ! đŸŒâœˆïž +Depuis 2023, je travaille chez Airbus Ă  Toulouse en tant que Connectivity Automation Technology Specialist. Ma mission consiste Ă  rendre les rĂ©seaux plus fiables grĂące Ă  l'automatisation, aussi bien dans les airs qu'au sol. -🔧 **Plus de 6 ans chez Nokia** +**Plus de 6 ans chez Nokia** -Chez **Nokia**, je me suis spĂ©cialisĂ© dans l’**ingĂ©nierie des rĂ©seaux d’accĂšs**. J’ai conçu des configurations hautes performances, validĂ© de nouvelles technologies comme la **5G et la fibre**, et dirigĂ© des projets clients. J’ai aussi accompagnĂ© les Ă©quipes et formĂ© les nouveaux arrivants đŸ‘šâ€đŸ«. Ce fut une excellente Ă©cole pour l’**architecture**, la **fiabilitĂ©** et la **rĂ©solution de problĂšmes concrets**. +Chez Nokia, je me suis spĂ©cialisĂ© dans l'ingĂ©nierie des rĂ©seaux d'accĂšs. J'ai conçu des configurations hautes performances, validĂ© de nouvelles technologies comme la 5G et la fibre, et dirigĂ© des projets clients. J'ai aussi accompagnĂ© les Ă©quipes et formĂ© les nouveaux arrivants. Ce fut une bonne Ă©cole pour l'architecture, la fiabilitĂ© et la rĂ©solution de problĂšmes concrets. -🧠 **Mes dĂ©buts rĂ©seaux chez Orange & au-delĂ ** +**Mes dĂ©buts rĂ©seau chez Orange et au-delĂ ** -J’ai commencĂ© mon parcours chez **Orange** en tant que **technicien rĂ©seau**, oĂč j’ai appris les bases — de l’installation de matĂ©riel tĂ©lĂ©com Ă  la rĂ©solution de problĂšmes complexes de connectivitĂ© 🔌. Avant cela, j’ai Ă©galement servi dans la **Gendarmerie nationale** 👼, une expĂ©rience qui m’a appris la discipline et le travail en Ă©quipe. +J'ai commencĂ© mon parcours chez Orange en tant que technicien rĂ©seau, oĂč j'ai appris les bases, de l'installation de matĂ©riel tĂ©lĂ©com Ă  la rĂ©solution de problĂšmes de connectivitĂ©. Avant cela, j'ai servi dans la Gendarmerie nationale, une expĂ©rience qui m'a appris la discipline et le travail en Ă©quipe. -💡 **Du terrain Ă  l’automatisation** +**Du terrain Ă  l'automatisation** -Avec les annĂ©es, je suis passĂ© de l’**ingĂ©nierie pratique** Ă  l’**automatisation rĂ©seau**, poussĂ© par ma passion pour l’innovation đŸ€–. Aujourd’hui, je me concentre sur l’**automatisation des processus**, l’amĂ©lioration de la **scalabilitĂ©**, et l’accompagnement des Ă©quipes vers l’**avenir du rĂ©seau**. +Avec les annĂ©es, je suis passĂ© de l'ingĂ©nierie pratique Ă  l'automatisation rĂ©seau, poussĂ© par mon intĂ©rĂȘt pour ce domaine. Aujourd'hui, je me concentre sur l'automatisation des processus et l'amĂ©lioration de la scalabilitĂ©, et j'aide les Ă©quipes Ă  adopter les outils qui vont avec. -📚 **Apprenant Ă  vie & promoteur de l’esprit d’équipe** +**Apprendre toujours, en Ă©quipe** -Je crois en la **croissance collective**. Que ce soit par le partage de connaissances, la curiositĂ© ou l’expĂ©rimentation d’idĂ©es, j’essaie toujours de crĂ©er un environnement oĂč **apprendre fait partie du quotidien** đŸŒ±. +Je crois en la croissance collective. Que ce soit par le partage de connaissances, la curiositĂ© ou l'expĂ©rimentation, j'essaie de crĂ©er un environnement oĂč apprendre fait partie du quotidien. diff --git a/content/blog/aiops-observabilite-reseau-ia/index.en.md b/content/blog/aiops-observabilite-reseau-ia/index.en.md index b715421..0543f28 100644 --- a/content/blog/aiops-observabilite-reseau-ia/index.en.md +++ b/content/blog/aiops-observabilite-reseau-ia/index.en.md @@ -11,7 +11,7 @@ tags: - AI Agents --- -I just finished building a full observability stack on my EVPN/VXLAN lab: topology, telemetry, and near real-time visualization. While building it, I realized I wasn't just doing monitoring : I was preparing a network to one day be "seen" by an AI. This first article sets the frame for a five-part series: why observability is the mandatory prerequisite before plugging an agent into your infrastructure. +I just finished building a full observability stack on my EVPN/VXLAN lab: topology, telemetry, and near real-time visualization. While building it, I realized what I was actually doing: preparing a network to one day be "seen" by an AI. This first article sets the frame for a five-part series: why observability is the mandatory prerequisite before plugging an agent into your infrastructure. @@ -26,7 +26,7 @@ The result is a stack combining four building blocks: - a **time-series database** for metric storage; - a **visualization layer** automatically regenerated by cross-referencing topology and metrics. -It works today. But it's not the stack itself that made me write this article: it's a realization I had while building it. I wasn't just setting up monitoring : I was laying the foundations of a pipeline that could, one day, allow an AI agent to reason about my network. And that has a name. +It works today. But it's not the stack itself that made me write this article: it's a realization I had while building it. I wasn't just setting up monitoring, I was laying the foundations of a pipeline that could, one day, allow an AI agent to reason about my network. And that has a name. ## AIOps, not MLOps @@ -59,7 +59,7 @@ Observability, then, is not an end in itself. It's **the condition of possibilit What helped me structure all this was thinking in stacked layers, and accepting that you don't skip a step: 1. **Infrastructure first.** Is the base data reliable, complete, up to date? Topology, metrics, logs. -2. **The model next.** What's built on top: a correlation rule, a model, an LLM : does it receive quality inputs, and can its relevance be measured over time? +2. **The model next.** What's built on top, a correlation rule, a model, an LLM: does it receive quality inputs, and can its relevance be measured over time? 3. **Agent behavior last.** Can its answers and actions be trusted, and can they be audited? The order isn't negotiable. An agent built on top of a shaky layer 1 inherits all its weaknesses in cascade, with the added bonus of the illusion of reliability that comes from an assertive answer by construction. You can't make up for a poorly instrumented infrastructure with a better prompt. @@ -101,10 +101,10 @@ That's why observability comes first, and the agent comes last: not because AI i ## Resources ### Concepts -- [What is AIOps?](https://www.ibm.com/think/topics/aiops) : definition and origin of the term (Gartner) -- [Model Context Protocol : official documentation](https://modelcontextprotocol.io/docs/getting-started/intro) -- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) : the original announcement, which frames well the problem MCP solves -- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) : the reference article on context engineering, including the phenomenon of context window saturation +- [What is AIOps?](https://www.ibm.com/think/topics/aiops): definition and origin of the term (Gartner) +- [Model Context Protocol: official documentation](https://modelcontextprotocol.io/docs/getting-started/intro) +- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol): the original announcement, which frames well the problem MCP solves +- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents): the reference article on context engineering, including the phenomenon of context window saturation - *Observability Engineering* (O'Reilly, 2nd edition), Charity Majors, Liz Fong-Jones, George Miranda: the field's reference book, with a chapter dedicated to the rise of agents and LLMs ### My repo diff --git a/content/blog/aiops-observabilite-reseau-ia/index.fr.md b/content/blog/aiops-observabilite-reseau-ia/index.fr.md index 4903199..1284094 100644 --- a/content/blog/aiops-observabilite-reseau-ia/index.fr.md +++ b/content/blog/aiops-observabilite-reseau-ia/index.fr.md @@ -11,7 +11,7 @@ tags: - AI Agents --- -Je viens de terminer une stack d'observabilitĂ© complĂšte sur mon lab EVPN/VXLAN : topologie, tĂ©lĂ©mĂ©trie et visualisation en temps quasi rĂ©el. En la construisant, j'ai compris que je ne faisais pas juste du monitoring — je prĂ©parais un rĂ©seau Ă  ĂȘtre un jour « vu » par une IA. Ce premier article pose le cadre d'une sĂ©rie de cinq : pourquoi l'observabilitĂ© est le prĂ©alable obligĂ© avant de brancher un agent sur son infrastructure. +Je viens de terminer une stack d'observabilitĂ© complĂšte sur mon lab EVPN/VXLAN : topologie, tĂ©lĂ©mĂ©trie et visualisation en temps quasi rĂ©el. En la construisant, j'ai compris ce que je faisais rĂ©ellement : je prĂ©parais un rĂ©seau Ă  ĂȘtre un jour « vu » par une IA. Ce premier article pose le cadre d'une sĂ©rie de cinq : pourquoi l'observabilitĂ© est le prĂ©alable obligĂ© avant de brancher un agent sur son infrastructure. @@ -26,7 +26,7 @@ Le rĂ©sultat est une stack qui combine quatre briques : - une **base de sĂ©ries temporelles** pour le stockage des mĂ©triques ; - une **couche de visualisation** rĂ©gĂ©nĂ©rĂ©e automatiquement en croisant la topologie et les mĂ©triques. -C'est fonctionnel aujourd'hui. Mais ce n'est pas la stack elle-mĂȘme qui m'a fait Ă©crire cet article : c'est une prise de conscience en la construisant. Je ne posais pas seulement de la supervision : je posais les fondations d'un pipeline qui, un jour, pourrait permettre Ă  un agent IA de raisonner sur mon rĂ©seau. Et ça, ça a un nom. +C'est fonctionnel aujourd'hui. Mais ce n'est pas la stack elle-mĂȘme qui m'a fait Ă©crire cet article : c'est une prise de conscience en la construisant. Je ne posais pas seulement de la supervision, je posais les fondations d'un pipeline qui, un jour, pourrait permettre Ă  un agent IA de raisonner sur mon rĂ©seau. Et ça, ça a un nom. ## AIOps, pas MLOps diff --git a/content/blog/migration-gitlab-gitea/index.en.md b/content/blog/migration-gitlab-gitea/index.en.md index d2759de..9c71dc2 100644 --- a/content/blog/migration-gitlab-gitea/index.en.md +++ b/content/blog/migration-gitlab-gitea/index.en.md @@ -15,7 +15,7 @@ A write-up on building my personal infrastructure: migrating from GitHub to self -## Context and Motivations +## Context and motivations As a network engineer working in automation and orchestration, I've always needed an environment to experiment and learn in. Until recently, I used GitHub for my code and ContainerLab locally/on AWS via [DevPod](/documentation/devpod/) for my network simulations. @@ -26,11 +26,11 @@ But several needs emerged: - **Flexibility**: Being able to spin up network labs on demand without saturating my local machine - **Automation**: Scripting the complete provisioning of my environments -## The Overall Architecture +## The overall architecture ![Architecture](global_architecture.en.svg) -### Tech Stack +### Tech stack **Homelab**: - **Proxmox VE**: Hypervisor for VMs and LXC @@ -48,7 +48,7 @@ But several needs emerged: - **Instances**: Ephemeral network labs provisioned on demand - **Scaleway CLI**: Full automation -## Part 1: Migrating from GitHub to Self-Hosted Gitea +## Part 1: migrating from GitHub to self-hosted Gitea ### Why Gitea? @@ -81,7 +81,7 @@ The script: - Initial setup via the interface - Site URL: `https://gitea.arnodo.fr` -### Network Architecture: Wireguard + Nginx Proxy Manager +### Network architecture: Wireguard + Nginx Proxy Manager **The problem**: Gitea runs inside my homelab (private IP), but I want to access it from the Internet. @@ -186,7 +186,7 @@ scrape_configs: - CI/CD runner status - LXC CPU/RAM usage -### Migrating Code from GitHub +### Migrating code from GitHub Simple and fast: Use Gitea's import feature (Settings > New Migration > GitHub), which also migrates issues and releases. @@ -313,16 +313,16 @@ git push origin main The workflow triggers automatically, Hugo builds the site, and deploys it to Scaleway Object Storage. The site is instantly available via the CDN. -## Part 2: Network Labs on Scaleway +## Part 2: network labs on Scaleway -### The Problem +### The problem Running ContainerLab with several Arista EOS instances locally is: - **Resource-hungry**: 4-8 GB RAM per cEOS container - **Local-only**: No access from outside - **Conflict-prone**: With other Docker/K8s services -### The Solution: On-Demand Scaleway Instances +### The solution: on-demand Scaleway instances **Concept**: - Spin up a Scaleway instance whenever I need a lab @@ -330,7 +330,7 @@ Running ContainerLab with several Arista EOS instances locally is: - Destroy the instance after use - Billed by the hour (< €1 for a few hours of lab time) -### Automation Script: Scaleway CLI +### Automation script: Scaleway CLI I built a Bash script that manages the entire lifecycle of a lab instance. @@ -385,7 +385,7 @@ case "$1" in esac ``` -### Cloud-Init: Automatic Configuration +### Cloud-init: automatic configuration The `user_data.txt` file contains the cloud-init instructions to automatically provision the instance. @@ -413,7 +413,7 @@ runcmd: - cd /root/labs && containerlab deploy -t spine-leaf.clab.yml ``` -### Practical Usage +### Practical usage **Create a lab**: @@ -438,7 +438,7 @@ containerlab inspect ./scaleway-instance.sh delete ``` -### Raycast Integration +### Raycast integration To make things even simpler, I created a Raycast script that lets me manage my instances directly from my Mac. @@ -461,7 +461,7 @@ To make things even simpler, I created a Raycast script that lets me manage my i - `⌘ + Space` → "Scaleway Instance DEV1-S" → Creates the instance - `⌘ + Space` → "Scaleway Instance delete" → Deletes the instance -### Use Case: BGP/EVPN Lab with Arista +### Use case: BGP/EVPN lab with Arista **ContainerLab topology** (`spine-leaf.clab.yml`): @@ -499,11 +499,11 @@ topology: **Cost**: DEV1-S instance (2 vCPU, 2GB) = ~€0.015/hour. 4 hours of lab time = €0.06. -## Digital Sovereignty: Why It Matters +## Digital sovereignty: why it matters This hybrid infrastructure reflects a personal conviction about digital sovereignty. -### The Context +### The context In my work as a network engineer, I see how important it is to be in control of your own infrastructure. @@ -513,7 +513,7 @@ Choosing Scaleway (part of the Iliad group, French) and self-hosting Gitea means - **Reducing latency**: Datacenters in Paris - **Understanding**: Owning your entire chain end-to-end -### Learning by Doing +### Learning by doing As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me: - Apply Infrastructure as Code principles @@ -523,7 +523,7 @@ As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me: ## Assessment -### What Works Well +### What works well **Self-hosted Gitea**: - Very fast and stable @@ -546,7 +546,7 @@ As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me: - Free (a few cents/month for storage) - Built-in CDN = ultra-fast site -### The Challenges +### The challenges **Initial complexity**: - Wireguard + reverse proxy = learning curve @@ -561,7 +561,7 @@ As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me: - If the Dedibox goes down, Gitea becomes unreachable - Solution: failover with a second Dedibox or VPS (coming soon) -## Next Steps +## Next steps - **High availability**: A second Dedibox for failover - **Automatic backup**: Scripts to back up Gitea to Scaleway Object Storage @@ -571,16 +571,11 @@ As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me: ## Conclusion -This hybrid infrastructure (Proxmox homelab + Scaleway cloud) offers the best of both worlds: +This hybrid setup, Proxmox homelab plus Scaleway cloud, gives me control over sensitive data (code, configurations stay in the homelab), cloud resources for one-off needs, and everything hosted in France with European providers. -- **Control**: Sensitive data (code, configurations) stays in the homelab -- **Flexibility**: Cloud resources for one-off needs -- **Learning**: A complete environment to experiment in -- **Sovereignty**: Everything hosted in France, with European providers +Self-hosting hasn't saved me money (spoiler: I pay about as much as before, if not more). What it gave me is a deeper understanding of the systems I work with. -Self-hosting isn't just about costs (spoiler: I pay about as much as before, if not more), but about learning, mastery, and a deep understanding of systems. - -For a network or DevOps engineer, it's the ideal environment to reproduce professional use cases and build up skills. +For a network or DevOps engineer, it's a good environment to reproduce professional use cases and build up skills. ## Resources @@ -591,7 +586,7 @@ For a network or DevOps engineer, it's the ideal environment to reproduce profes - [ContainerLab](https://containerlab.dev/) - [Nginx Proxy Manager](https://nginxproxymanager.com/) -### My Repos +### My repos - [Blog Hugo](https://gitea.arnodo.fr/Damien/blog) - [Network Labs](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (ContainerLab topologies) - [Scaleway Scripts](https://gitea.arnodo.fr/Damien/scaleway-automation) diff --git a/content/blog/migration-gitlab-gitea/index.fr.md b/content/blog/migration-gitlab-gitea/index.fr.md index aea39b5..a3e6f04 100644 --- a/content/blog/migration-gitlab-gitea/index.fr.md +++ b/content/blog/migration-gitlab-gitea/index.fr.md @@ -15,7 +15,7 @@ Retour d'expĂ©rience sur la construction de mon infrastructure personnelle : mig -## Contexte et Motivations +## Contexte et motivations En tant qu'ingĂ©nieur rĂ©seau travaillant dans le domaine de l'automatisation et de l'orchestration, j'ai toujours eu besoin d'un environnement pour expĂ©rimenter et apprendre. Jusqu'Ă  rĂ©cemment, j'utilisais GitHub pour mon code et ContainerLab en local/AWS via [DevPod](/documentation/devpod/) pour mes simulations rĂ©seau. @@ -26,11 +26,11 @@ Mais plusieurs envies ont Ă©mergĂ© : - **FlexibilitĂ©** : Pouvoir lancer des labs rĂ©seau Ă  la demande sans saturer ma machine locale - **Automatisation** : Scripter le provisionnement complet de mes environnements -## L'Architecture Globale +## L'architecture globale ![Architecture](global_architecture.fr.svg) -### Stack Technique +### Stack technique **Homelab** : - **Proxmox VE** : Hyperviseur pour VMs et LXC @@ -48,7 +48,7 @@ Mais plusieurs envies ont Ă©mergĂ© : - **Instances** : Labs rĂ©seau Ă©phĂ©mĂšres provisionnĂ©s Ă  la demande - **Scaleway CLI** : Automatisation complĂšte -## Partie 1 : Migration GitHub → Gitea Auto-HĂ©bergĂ© +## Partie 1 : migration GitHub → Gitea auto-hĂ©bergĂ© ### Pourquoi Gitea ? @@ -81,7 +81,7 @@ Le script : - Configuration initiale via l'interface - URL du site : `https://gitea.arnodo.fr` -### Architecture RĂ©seau : Wireguard + Nginx Proxy Manager +### Architecture rĂ©seau : Wireguard + Nginx Proxy Manager **Le problĂšme** : Gitea tourne dans mon homelab (IP privĂ©e), mais je veux y accĂ©der depuis Internet. @@ -186,7 +186,7 @@ scrape_configs: - État des runners CI/CD - Utilisation CPU/RAM du LXC -### Migration du Code depuis GitHub +### Migration du code depuis GitHub Simple et rapide : Utiliser la fonction d'import de Gitea (Settings > New Migration > GitHub) qui migre aussi les issues et releases. @@ -197,7 +197,7 @@ Mon blog Hugo se dĂ©ploie automatiquement sur Scaleway Object Storage Ă  chaque **Installation de Gitea Runner** (https://docs.gitea.com/usage/actions/act-runner) -CrĂ©er l’utilisateur systĂšme runner : +CrĂ©er l'utilisateur systĂšme runner : ```bash useradd -r -m -d /var/lib/gitea-runner -s /bin/bash gitea-runner @@ -313,16 +313,16 @@ git push origin main Le workflow se dĂ©clenche automatiquement, Hugo gĂ©nĂšre le site, et le dĂ©ploie sur Scaleway Object Storage. Le site est accessible instantanĂ©ment via le CDN. -## Partie 2 : Labs RĂ©seau sur Scaleway +## Partie 2 : labs rĂ©seau sur Scaleway -### Le ProblĂšme +### Le problĂšme ContainerLab avec plusieurs Arista EOS en local, c'est : - **Gourmand** : 4-8 GB RAM par conteneur cEOS - **Local** : Pas d'accĂšs depuis l'extĂ©rieur - **Conflits** : Avec d'autres services Docker/K8s -### La Solution : Instances Scaleway Ă  la Demande +### La solution : instances Scaleway Ă  la demande **Concept** : - CrĂ©er une instance Scaleway quand j'ai besoin d'un lab @@ -330,7 +330,7 @@ ContainerLab avec plusieurs Arista EOS en local, c'est : - DĂ©truire l'instance aprĂšs utilisation - Facturation Ă  l'heure (< 1€ pour quelques heures de lab) -### Script d'Automatisation : Scaleway CLI +### Script d'automatisation : Scaleway CLI J'ai dĂ©veloppĂ© un script Bash qui gĂšre tout le cycle de vie d'une instance de lab. @@ -385,7 +385,7 @@ case "$1" in esac ``` -### Cloud-Init : Configuration Automatique +### Cloud-init : configuration automatique Le fichier `user_data.txt` contient les instructions cloud-init pour provisionner l'instance automatiquement. @@ -413,7 +413,7 @@ runcmd: - cd /root/labs && containerlab deploy -t spine-leaf.clab.yml ``` -### Utilisation Pratique +### Utilisation pratique **CrĂ©er un lab** : @@ -461,7 +461,7 @@ Pour simplifier encore plus, j'ai crĂ©Ă© un script Raycast qui me permet de gĂ©r - `⌘ + Space` → "Scaleway Instance DEV1-S" → CrĂ©e l'instance - `⌘ + Space` → "Scaleway Instance delete" → Supprime l'instance -### Cas d'Usage : Lab BGP/EVPN avec Arista +### Cas d'usage : lab BGP/EVPN avec Arista **Topologie ContainerLab** (`spine-leaf.clab.yml`) : @@ -499,11 +499,11 @@ topology: **CoĂ»t** : Instance DEV1-S (2 vCPU, 2GB) = ~0.015€/heure. 4 heures de lab = 0.06€. -## SouverainetĂ© NumĂ©rique : Pourquoi C'est Important +## SouverainetĂ© numĂ©rique : pourquoi c'est important Cette infrastructure hybride reflĂšte une conviction personnelle sur la souverainetĂ© numĂ©rique. -### Le Contexte +### Le contexte Dans mon travail d'ingĂ©nieur rĂ©seau, je vois l'importance de la maĂźtrise de ses infrastructures. @@ -513,7 +513,7 @@ Choisir Scaleway (groupe Iliad, français) et self-hoster Gitea, c'est : - **RĂ©duire la latence** : Datacenters Ă  Paris - **Comprendre** : MaĂźtriser sa chaĂźne complĂšte -### Apprentissage par la Pratique +### Apprentissage par la pratique En tant que professionnel du rĂ©seau (Arista, BGP/EVPN, automation), self-hoster me permet de : - Appliquer les principes Infrastructure as Code @@ -523,7 +523,7 @@ En tant que professionnel du rĂ©seau (Arista, BGP/EVPN, automation), self-hoster ## Bilan -### Ce qui Fonctionne Bien +### Ce qui fonctionne bien **Gitea auto-hĂ©bergĂ©** : - TrĂšs rapide et stable @@ -546,7 +546,7 @@ En tant que professionnel du rĂ©seau (Arista, BGP/EVPN, automation), self-hoster - Gratuit (quelques centimes/mois pour le stockage) - CDN intĂ©grĂ© = site ultra rapide -### Les DĂ©fis +### Les dĂ©fis **ComplexitĂ© initiale** : - Wireguard + reverse proxy = courbe d'apprentissage @@ -561,7 +561,7 @@ En tant que professionnel du rĂ©seau (Arista, BGP/EVPN, automation), self-hoster - Si la Dedibox tombe, Gitea n'est plus accessible - Solution : Failover avec une 2e Dedibox ou VPS (Ă  venir) -## Prochaines Étapes +## Prochaines Ă©tapes - **Haute disponibilitĂ©** : Seconde Dedibox pour du failover - **Backup automatique** : Scripts pour sauvegarder Gitea vers Scaleway Object Storage @@ -571,16 +571,11 @@ En tant que professionnel du rĂ©seau (Arista, BGP/EVPN, automation), self-hoster ## Conclusion -Cette infrastructure hybride (homelab Proxmox + cloud Scaleway) offre le meilleur des deux mondes : +Cette infrastructure hybride, homelab Proxmox plus cloud Scaleway, me donne le contrĂŽle sur les donnĂ©es sensibles (code, configurations restent dans le homelab), des ressources cloud pour les besoins ponctuels, et tout est hĂ©bergĂ© en France chez des acteurs europĂ©ens. -- **ContrĂŽle** : DonnĂ©es sensibles (code, configurations) dans le homelab -- **FlexibilitĂ©** : Ressources cloud pour les besoins ponctuels -- **Apprentissage** : Environnement complet pour expĂ©rimenter -- **SouverainetĂ©** : Tout hĂ©bergĂ© en France, chez des acteurs europĂ©ens +Le self-hosting ne m'a pas fait Ă©conomiser d'argent (spoiler : je paie autant qu'avant, voire plus). Ce qu'il m'apporte, c'est une comprĂ©hension plus profonde des systĂšmes avec lesquels je travaille. -Le self-hosting n'est pas qu'une question de coĂ»ts (spoiler : je paie autant qu'avant, voire plus), mais d'apprentissage, de maĂźtrise et de comprĂ©hension profonde des systĂšmes. - -Pour un ingĂ©nieur rĂ©seau ou DevOps, c'est l'environnement idĂ©al pour reproduire des cas d'usage professionnels et monter en compĂ©tences. +Pour un ingĂ©nieur rĂ©seau ou DevOps, c'est un bon environnement pour reproduire des cas d'usage professionnels et monter en compĂ©tences. ## Ressources @@ -591,7 +586,7 @@ Pour un ingĂ©nieur rĂ©seau ou DevOps, c'est l'environnement idĂ©al pour reprodui - [ContainerLab](https://containerlab.dev/) - [Nginx Proxy Manager](https://nginxproxymanager.com/) -### Mes Repos +### Mes repos - [Blog Hugo](https://gitea.arnodo.fr/Damien/blog) - [Network Labs](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (topologies ContainerLab) - [Scaleway Scripts](https://gitea.arnodo.fr/Damien/scaleway-automation) diff --git a/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md b/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md index e3a3def..89c15bf 100644 --- a/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md +++ b/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md @@ -12,44 +12,44 @@ In the fast-paced world of technology, understanding networking concepts can be Today, we're going to break down two important networking concepts: **VLAN** and **VXLAN**, using simple analogies and clear explanations. We'll also cover their limitations, real-world use cases, and a few technical notes for the more curious among you. -Let's dive in! 🚀 +Let's dive in. -## What is a VLAN? 🏱 +## What is a VLAN? **VLAN (Virtual Local Area Network)** is like organizing a large office building with several departments: Marketing, Sales, HR, and IT. To keep things orderly, each department gets its own floor. That way, people from Marketing stay on their floor, people from Sales stay on theirs, and so on. A **VLAN** works similarly for computer networks. It divides a large physical network into smaller, isolated networks. Each VLAN is like a separate floor for a department, allowing devices within the same VLAN to communicate easily while keeping traffic separate from other VLANs. -### Key points about VLAN ✅ +### Key points about VLAN - **Separation:** Keeps different groups (like departments) apart. - **Efficiency:** Reduces unnecessary traffic and potential network issues. - **Security:** Limits access and strengthens security by isolating groups. -### VLAN limitations ⚠ +### VLAN limitations - **ID limit:** Historically, a VLAN is identified on 12 bits, allowing up to 4094 VLANs (from 1 to 4094). For a large enterprise or a datacenter, this can turn out to be insufficient. - **Local isolation:** VLANs are mostly designed for local use (a single site or a set of locally connected switches). As soon as you want to extend this concept across multiple sites, you need more advanced solutions. -## What is VXLAN? 🌆 +## What is VXLAN? **VXLAN (Virtual Extensible LAN)** takes things further. Imagine your company grows and expands into several buildings across the city. You still want departments to feel as if they were on their own floors, even though they're now spread across different locations. To achieve this, you create a virtual system that connects all the floors across the buildings, so that Marketing on the 3rd floor of one building is still virtually connected to Marketing on the 3rd floor of another building. **VXLAN** does exactly that for networks. It extends VLANs across multiple physical locations using a technique called **tunneling**. This way, devices in the same VLAN can communicate as if they were on the same local network, even though they're geographically far apart. -### Key points about VXLAN ⭐ +### Key points about VXLAN - **Scalability:** Extends networks across different locations, and goes beyond the 4094 VLAN limit. - **Flexibility:** Enables larger, more dynamic network designs. - **Connectivity:** Ensures seamless communication across dispersed networks. -## A technical deep dive into VXLAN 🔍 +## A technical deep dive into VXLAN **VXLAN** was developed to address the limitations of traditional VLANs (scalability, geographic reach). It uses a 24-bit VXLAN network identifier (**VNI**) to identify up to **16 million** logical segments, far exceeding the 4094 VLAN limit. Because of virtualization, MAC address tables in datacenters can grow very large, while physical switches have limited capacity. VXLAN addresses this challenge by using **MAC-in-UDP** encapsulation, which allows Ethernet frames (layer 2) to be carried over an IP network (layer 3). -### How does it work? đŸ€” +### How does it work? The goal of **VXLAN** is to **extend layer 2** across a layer 3 (IP) network. This essentially "tricks" layer 3 into making the user or virtual machine believe it's still on the same local network (layer 2). @@ -64,7 +64,7 @@ The goal of **VXLAN** is to **extend layer 2** across a layer 3 (IP) network. Th By encapsulating layer 2 within layer 3, we get the benefits of IP routing (flexibility, scalability) while retaining the isolation and simplicity of layer 2 for applications and virtual machines. -### VXLAN explained through the container transport analogy 🚚 🚂 +### VXLAN explained through the container transport analogy #### 1. The trucks (lower layers) @@ -89,26 +89,26 @@ The train runs on rails (the **IP network**, layer 3). The rail tracks are alrea ![Container transport](transports.en.png#center) -## Real-world use cases 🏭 +## Real-world use cases - **Multi-datacenter:** To connect several geographically dispersed datacenters while keeping the feel of a single layer 2 network. - **Hybrid cloud:** Extend a corporate network to a public or private cloud provider without reconfiguring the entire addressing plan. - **Virtual machine migration:** Enable migration (VM Mobility) between remote sites without losing layer 2 connectivity. -- **Massive virtualization:** In very dense environments (e.g. hundreds of thousands of virtual machines), the 24-bit VNI identifier is essential. +- **Massive virtualization:** In very dense environments (e.g. hundreds of thousands of virtual machines), the 24-bit VNI identifier is necessary. -## Controlling VXLAN: BGP EVPN and other protocols đŸ€ +## Controlling VXLAN: BGP EVPN and other protocols In modern deployments, especially in datacenters, VXLAN isn't simply configured statically. It's often paired with a **control plane** via the **BGP EVPN (Ethernet VPN)** protocol. - **BGP EVPN:** Allows MAC and IP table information to be exchanged between devices, facilitating automation and scalability. - **Other technologies:** Historically, you could come across other overlay protocols (NVGRE, STT), but VXLAN has established itself as the de facto standard. -## Performance considerations ⚙ +## Performance considerations - **Encapsulation overhead:** VXLAN adds an extra header (8 bytes + UDP/IP header). This can impact the **maximum frame size (MTU)**, and it's often necessary to configure a **Jumbo MTU** (typically 9000 bytes) to avoid packet fragmentation. - **IP network resilience:** The reliability of the VXLAN tunnel depends on the quality of the underlying IP network (routes, congestion, etc.). -## Configuration example (for the curious) 💡 +## Configuration example (for the curious) Here's a **simplified excerpt** of a VXLAN configuration on a Cisco NX-OS device (syntax varies by vendor): @@ -127,23 +127,23 @@ interface nve1 *Note:* In more complex environments, the control plane is also configured (e.g. BGP EVPN). -## Summary 🎯 +## Summary - **VLAN** - It's like having separate floors for different departments in a building, keeping their activities isolated. 🏱 + It's like having separate floors for different departments in a building, keeping their activities isolated. \- **Main limitation**: 4094 VLANs maximum and a scope often limited to a single site. - **VXLAN** - It's like connecting those separate floors across multiple buildings, all while keeping the illusion that they're in the same building. 🌆 + It's like connecting those separate floors across multiple buildings, all while keeping the illusion that they're in the same building. \- **Key advantages**: Huge addressing capacity (16 million segments), L2 extension over L3, flexibility for virtualization and multi-site deployments. -**VXLAN** meets the need for large-scale isolation, overcomes the limitations of switch MAC address tables, and enables flexible service deployment. Furthermore, when paired with an efficient control plane (BGP EVPN), it greatly simplifies the management of modern **overlay** networks. +**VXLAN** meets the need for large-scale isolation and gets around the MAC address table limits of physical switches. Paired with a control plane like BGP EVPN, it simplifies the management of modern **overlay** networks. -### Conclusion 🏁 +### Conclusion -In short, if you're looking for **basic segmentation** for your local network, a **VLAN** is largely sufficient. But as soon as you want to link multiple sites, build a highly virtualized network, or go beyond the traditional 4094 VLAN limit, **VXLAN** becomes essential. +If you're looking for **basic segmentation** for your local network, a **VLAN** is largely sufficient. But as soon as you want to link multiple sites, build a highly virtualized network, or go beyond the traditional 4094 VLAN limit, you need **VXLAN**. -Whether you're a **network lab** enthusiast, a NetOps engineer, or simply curious about the inner workings of IT infrastructure, understanding these two concepts will help you better grasp the magic that happens as your data travels further and further, all while keeping the illusion of being "at home" on the same local network! +Whether you're a **network lab** enthusiast, a NetOps engineer, or simply curious about the inner workings of IT infrastructure, understanding these two concepts will help you grasp what happens as your data travels between sites, all while keeping the illusion of being "at home" on the same local network. > [!TIP] **Want to go further?** > diff --git a/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md b/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md index 2753e7e..08ae49a 100644 --- a/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md +++ b/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md @@ -10,69 +10,69 @@ cascade: Dans le monde rapide de la technologie, comprendre les concepts de rĂ©seau peut ĂȘtre intimidant, surtout si vous n'ĂȘtes pas un expert en la matiĂšre. Aujourd'hui, nous allons dĂ©composer deux concepts de rĂ©seau importants : **VLAN** et **VXLAN**, en utilisant des analogies simples et des explications claires. -Nous aborderons Ă©galement leurs limites, leurs cas d’usage concrets, ainsi que quelques notions techniques pour les plus curieux. +Nous aborderons Ă©galement leurs limites, leurs cas d'usage concrets, ainsi que quelques notions techniques pour les plus curieux. -Allons-y ! 🚀 +Allons-y ! -## Qu'est-ce qu'un VLAN ? 🏱 +## Qu'est-ce qu'un VLAN ? **VLAN (Virtual Local Area Network)**, ou RĂ©seau Local Virtuel, c'est comme organiser un grand immeuble de bureaux avec plusieurs dĂ©partements : Marketing, Ventes, RH, et Informatique. Pour maintenir l'ordre, chaque dĂ©partement obtient son propre Ă©tage. De cette maniĂšre, les personnes du Marketing restent Ă  leur Ă©tage, celles des Ventes au leur, et ainsi de suite. Un **VLAN** fonctionne de maniĂšre similaire pour les rĂ©seaux informatiques. Il divise un grand rĂ©seau physique en rĂ©seaux plus petits et isolĂ©s. Chaque VLAN est comme un Ă©tage sĂ©parĂ© pour un dĂ©partement, permettant aux dispositifs au sein du mĂȘme VLAN de communiquer facilement, tout en gardant le trafic sĂ©parĂ© des autres VLAN. -### Points clĂ©s sur le VLAN ✅ +### Points clĂ©s sur le VLAN - **SĂ©paration :** Garde les diffĂ©rents groupes (comme les dĂ©partements) sĂ©parĂ©s. - **EfficacitĂ© :** RĂ©duit le trafic inutile et les potentiels problĂšmes de rĂ©seau. - **SĂ©curitĂ© :** Limite l'accĂšs et renforce la sĂ©curitĂ© en isolant les groupes. -### Limites du VLAN ⚠ +### Limites du VLAN -- **Limite d’ID :** Historiquement, un VLAN est identifiĂ© sur 12 bits, permettant jusqu’à 4094 VLANs (de 1 Ă  4094). Pour une grande entreprise ou un datacenter, cela peut s’avĂ©rer insuffisant. -- **Isolation locale :** Les VLANs sont plutĂŽt conçus pour un usage local (un mĂȘme site ou un ensemble de switches connectĂ©s localement). DĂšs qu’on veut Ă©tendre ce concept Ă  plusieurs sites, on a besoin de solutions plus avancĂ©es. +- **Limite d'ID :** Historiquement, un VLAN est identifiĂ© sur 12 bits, permettant jusqu'Ă  4094 VLANs (de 1 Ă  4094). Pour une grande entreprise ou un datacenter, cela peut s'avĂ©rer insuffisant. +- **Isolation locale :** Les VLANs sont plutĂŽt conçus pour un usage local (un mĂȘme site ou un ensemble de switches connectĂ©s localement). DĂšs qu'on veut Ă©tendre ce concept Ă  plusieurs sites, on a besoin de solutions plus avancĂ©es. -## Qu'est-ce que le VXLAN ? 🌆 +## Qu'est-ce que le VXLAN ? **VXLAN (Virtual Extensible LAN)** va plus loin. Imaginez que votre entreprise grandisse et s'Ă©tende Ă  plusieurs immeubles Ă  travers la ville. Vous voulez toujours que les dĂ©partements se sentent comme s'ils Ă©taient sur leurs propres Ă©tages, mĂȘme s'ils sont maintenant rĂ©partis dans diffĂ©rents endroits. Pour ce faire, vous crĂ©ez un systĂšme virtuel qui connecte tous les Ă©tages Ă  travers les bĂątiments, de sorte que le Marketing au 3e Ă©tage d'un bĂątiment soit toujours virtuellement connectĂ© au Marketing du 3e Ă©tage d'un autre bĂątiment. Le **VXLAN** fait cela pour les rĂ©seaux. Il Ă©tend les VLANs Ă  travers plusieurs emplacements physiques en utilisant une technique appelĂ©e **tunneling**. Ainsi, les dispositifs dans le mĂȘme VLAN peuvent communiquer comme s'ils Ă©taient sur le mĂȘme rĂ©seau local, mĂȘme s'ils sont Ă©loignĂ©s gĂ©ographiquement. -### Points clĂ©s sur le VXLAN ⭐ +### Points clĂ©s sur le VXLAN - **ÉvolutivitĂ© :** Étend les rĂ©seaux Ă  diffĂ©rents emplacements, et dĂ©passe la limite de 4094 VLANs. - **FlexibilitĂ© :** Permet des conceptions de rĂ©seau plus grandes et dynamiques. - **ConnectivitĂ© :** Assure une communication fluide Ă  travers des rĂ©seaux dispersĂ©s. -## PlongĂ©e technique dans le VXLAN 🔍 +## PlongĂ©e technique dans le VXLAN Le **VXLAN** a Ă©tĂ© dĂ©veloppĂ© pour rĂ©pondre aux limites des VLANs traditionnels (scalabilitĂ©, Ă©tendue gĂ©ographique). Il utilise un identifiant de rĂ©seau VXLAN (**VNI**) de 24 bits pour identifier jusqu'Ă  **16 millions** de segments logiques, surpassant ainsi largement la limite de 4094 VLANs. -En raison de la virtualisation, les tables d'adresses MAC dans les datacenters peuvent devenir trĂšs grandes, tandis que les switches physiques ont des capacitĂ©s limitĂ©es. Le VXLAN rĂ©pond Ă  ce dĂ©fi en utilisant l’encapsulation **MAC-in-UDP**, permettant de transporter des trames Ethernet (couche 2) Ă  travers un rĂ©seau IP (couche 3). +En raison de la virtualisation, les tables d'adresses MAC dans les datacenters peuvent devenir trĂšs grandes, tandis que les switches physiques ont des capacitĂ©s limitĂ©es. Le VXLAN rĂ©pond Ă  ce dĂ©fi en utilisant l'encapsulation **MAC-in-UDP**, permettant de transporter des trames Ethernet (couche 2) Ă  travers un rĂ©seau IP (couche 3). -### Comment ça marche ? đŸ€” +### Comment ça marche ? -L’objectif du **VXLAN** est de **prolonger la couche 2** Ă  travers un rĂ©seau de couche 3 (IP). Cela revient Ă  « tromper » la couche 3 pour faire croire Ă  l’utilisateur ou Ă  la machine virtuelle qu’il est toujours dans le mĂȘme rĂ©seau local (couche 2). +L'objectif du **VXLAN** est de **prolonger la couche 2** Ă  travers un rĂ©seau de couche 3 (IP). Cela revient Ă  « tromper » la couche 3 pour faire croire Ă  l'utilisateur ou Ă  la machine virtuelle qu'il est toujours dans le mĂȘme rĂ©seau local (couche 2). > **En clair :** On encapsule les trames Ethernet (couche 2) dans un paquet UDP (couche 4), lui-mĂȘme transportĂ© par IP (couche 3). ![OSI Layers](media_layers.fr.png#center) -> [!NOTE]**Les couches “matĂ©rielles”** +> [!NOTE]**Les couches "matĂ©rielles"** > > - La couche **Liaison (2)** est communĂ©ment gĂ©rĂ©e par des switches. > - La couche **RĂ©seau (3)** est communĂ©ment gĂ©rĂ©e par des routeurs. -En encapsulant la couche 2 dans la couche 3, on profite des avantages du routage IP (souplesse, scalabilitĂ©) tout en conservant l’isolation et la simplicitĂ© de la couche 2 pour les applications et machines virtuelles. +En encapsulant la couche 2 dans la couche 3, on profite des avantages du routage IP (souplesse, scalabilitĂ©) tout en conservant l'isolation et la simplicitĂ© de la couche 2 pour les applications et machines virtuelles. -### VXLAN expliquĂ© par l’analogie du transport de conteneurs 🚚 🚂 +### VXLAN expliquĂ© par l'analogie du transport de conteneurs #### 1. Les camions (couches basses) -Imaginez des camions sur la route. Leur mission est d’acheminer des conteneurs (vos donnĂ©es) d’un point A Ă  un point B. Ces camions reprĂ©sentent la **couche Ethernet** (niveau 2), oĂč chaque vĂ©hicule (frame) possĂšde une « plaque d’immatriculation » (adresse MAC). +Imaginez des camions sur la route. Leur mission est d'acheminer des conteneurs (vos donnĂ©es) d'un point A Ă  un point B. Ces camions reprĂ©sentent la **couche Ethernet** (niveau 2), oĂč chaque vĂ©hicule (frame) possĂšde une « plaque d'immatriculation » (adresse MAC). #### 2. Le train (tunnel VXLAN) -Quand il s’agit de couvrir de plus longues distances ou de traverser des infrastructures variĂ©es, charger les camions sur un train devient plus efficace. Ici, **le train reprĂ©sente VXLAN** : il encapsule les camions (frames Ethernet) dans un wagon (le tunnel). Chaque train est identifiĂ© par un **VNI (VXLAN Network Identifier)**, un peu comme un numĂ©ro de convoi pour chaque ligne de fret. +Quand il s'agit de couvrir de plus longues distances ou de traverser des infrastructures variĂ©es, charger les camions sur un train devient plus efficace. Ici, **le train reprĂ©sente VXLAN** : il encapsule les camions (frames Ethernet) dans un wagon (le tunnel). Chaque train est identifiĂ© par un **VNI (VXLAN Network Identifier)**, un peu comme un numĂ©ro de convoi pour chaque ligne de fret. #### 3. Les voies ferrĂ©es (rĂ©seau IP) @@ -80,37 +80,37 @@ Le train roule sur des rails (le **rĂ©seau IP**, couche 3). Les voies ferrĂ©es s ### Points clĂ©s Ă  retenir -- **Superposition (Overlay)** : VXLAN est un systĂšme de transport « par-dessus » la couche 3 (les rails). Il permet d’interconnecter plusieurs rĂ©seaux de niveau 2 (les camions) comme s’ils n’en formaient qu’un seul. +- **Superposition (Overlay)** : VXLAN est un systĂšme de transport « par-dessus » la couche 3 (les rails). Il permet d'interconnecter plusieurs rĂ©seaux de niveau 2 (les camions) comme s'ils n'en formaient qu'un seul. - **Double adressage** : - - Les camions (frames Ethernet) s’identifient via des **adresses MAC** (plaque d’immatriculation). + - Les camions (frames Ethernet) s'identifient via des **adresses MAC** (plaque d'immatriculation). - Le train (tunnel VXLAN) utilise les **adresses IP** (plan de route) pour circuler sur les rails. -- **Isolation et segmentation** : Comme plusieurs trains peuvent rouler sur la mĂȘme ligne ferroviaire, il est possible d’exploiter diffĂ©rents tunnels VXLAN (chacun avec son VNI) sur la mĂȘme infrastructure IP. -- **ÉlasticitĂ© et fiabilitĂ©** : En s’appuyant sur la couche 3, VXLAN profite de toutes les optimisations du routage IP (recalcul d’itinĂ©raires, tolĂ©rance aux pannes, etc.). +- **Isolation et segmentation** : Comme plusieurs trains peuvent rouler sur la mĂȘme ligne ferroviaire, il est possible d'exploiter diffĂ©rents tunnels VXLAN (chacun avec son VNI) sur la mĂȘme infrastructure IP. +- **ÉlasticitĂ© et fiabilitĂ©** : En s'appuyant sur la couche 3, VXLAN profite de toutes les optimisations du routage IP (recalcul d'itinĂ©raires, tolĂ©rance aux pannes, etc.). ![Container transport](transports.fr.png#center) -## Cas d'usage concrets 🏭 +## Cas d'usage concrets -- **Multi-datacenter :** Pour connecter plusieurs centres de donnĂ©es gĂ©ographiquement dispersĂ©s, tout en gardant la sensation d’un rĂ©seau unique au niveau 2. -- **Cloud hybride :** Étendre un rĂ©seau d’entreprise vers un fournisseur de cloud public ou privĂ© sans reconfigurer tout le plan d’adressage. +- **Multi-datacenter :** Pour connecter plusieurs centres de donnĂ©es gĂ©ographiquement dispersĂ©s, tout en gardant la sensation d'un rĂ©seau unique au niveau 2. +- **Cloud hybride :** Étendre un rĂ©seau d'entreprise vers un fournisseur de cloud public ou privĂ© sans reconfigurer tout le plan d'adressage. - **Migration de machines virtuelles :** Permettre la migration (VM Mobility) entre sites distants sans perdre la connectivitĂ© de couche 2. -- **Virtualisation massive :** Dans les environnements trĂšs denses (par ex. des centaines de milliers de machines virtuelles), l’identifiant VNI de 24 bits est indispensable. +- **Virtualisation massive :** Dans les environnements trĂšs denses (par ex. des centaines de milliers de machines virtuelles), l'identifiant VNI de 24 bits devient nĂ©cessaire. -## ContrĂŽle du VXLAN : BGP EVPN et autres protocoles đŸ€ +## ContrĂŽle du VXLAN : BGP EVPN et autres protocoles -Dans les dĂ©ploiements modernes, surtout en datacenter, le VXLAN n’est pas simplement configurĂ© de maniĂšre statique. Il est souvent associĂ© Ă  un **contrĂŽle de plan** via le protocole **BGP EVPN (Ethernet VPN)**. +Dans les dĂ©ploiements modernes, surtout en datacenter, le VXLAN n'est pas simplement configurĂ© de maniĂšre statique. Il est souvent associĂ© Ă  un **contrĂŽle de plan** via le protocole **BGP EVPN (Ethernet VPN)**. -- **BGP EVPN :** Permet d’échanger les informations de tables MAC et IP entre les Ă©quipements, facilitant l’automatisation et l’évolutivitĂ©. -- **Autres technologies :** Historiquement, on pouvait croiser d’autres protocoles d’overlay (NVGRE, STT), mais VXLAN s’est imposĂ© comme standard de fait. +- **BGP EVPN :** Permet d'Ă©changer les informations de tables MAC et IP entre les Ă©quipements, facilitant l'automatisation et l'Ă©volutivitĂ©. +- **Autres technologies :** Historiquement, on pouvait croiser d'autres protocoles d'overlay (NVGRE, STT), mais VXLAN s'est imposĂ© comme standard de fait. -## ConsidĂ©rations de performance ⚙ +## ConsidĂ©rations de performance -- **Surcharge d’encapsulation :** Le VXLAN ajoute un en-tĂȘte supplĂ©mentaire (8 octets + en-tĂȘte UDP/IP). Cela peut impacter la **taille maximale de trame (MTU)** et il faut souvent configurer un **Jumbo MTU** (gĂ©nĂ©ralement 9000 octets) pour Ă©viter la fragmentation des paquets. +- **Surcharge d'encapsulation :** Le VXLAN ajoute un en-tĂȘte supplĂ©mentaire (8 octets + en-tĂȘte UDP/IP). Cela peut impacter la **taille maximale de trame (MTU)** et il faut souvent configurer un **Jumbo MTU** (gĂ©nĂ©ralement 9000 octets) pour Ă©viter la fragmentation des paquets. - **RĂ©silience du rĂ©seau IP :** La fiabilitĂ© du tunnel VXLAN dĂ©pend de la qualitĂ© du rĂ©seau IP sous-jacent (routes, congestion, etc.). -## Exemple de configuration (pour les plus curieux) 💡 +## Exemple de configuration (pour les plus curieux) -Voici un **extrait simplifiĂ©** d’une configuration VXLAN sur un Ă©quipement Cisco NX-OS (les syntaxes varient selon les constructeurs) : +Voici un **extrait simplifiĂ©** d'une configuration VXLAN sur un Ă©quipement Cisco NX-OS (les syntaxes varient selon les constructeurs) : ```plaintext interface nve1 @@ -121,32 +121,32 @@ interface nve1 mcast-group 239.1.1.1 ``` -- **interface nve1 :** On crĂ©e une interface “NVE” (Network Virtualization Endpoint) pour gĂ©rer l'encapsulation VXLAN. -- **source-interface loopback1 :** L’adresse IP de l’interface loopback1 sera utilisĂ©e pour Ă©tablir les tunnels. +- **interface nve1 :** On crĂ©e une interface "NVE" (Network Virtualization Endpoint) pour gĂ©rer l'encapsulation VXLAN. +- **source-interface loopback1 :** L'adresse IP de l'interface loopback1 sera utilisĂ©e pour Ă©tablir les tunnels. - **member vni 5001 :** On associe un VNI (VXLAN Network Identifier) Ă  notre overlay rĂ©seau. *Note :* Dans les environnements plus complexes, on configure Ă©galement le plan de contrĂŽle (par ex. BGP EVPN). -## En rĂ©sumĂ© 🎯 +## En rĂ©sumĂ© - **VLAN** - C’est comme avoir des Ă©tages sĂ©parĂ©s pour diffĂ©rents dĂ©partements dans un bĂątiment, en gardant leurs activitĂ©s isolĂ©es. 🏱 + C'est comme avoir des Ă©tages sĂ©parĂ©s pour diffĂ©rents dĂ©partements dans un bĂątiment, en gardant leurs activitĂ©s isolĂ©es. \- **Limite majeure** : 4094 VLANs maximum et une portĂ©e souvent limitĂ©e Ă  un mĂȘme site. - **VXLAN** - C’est comme connecter ces Ă©tages sĂ©parĂ©s Ă  travers plusieurs bĂątiments, tout en gardant l’illusion qu’ils se trouvent dans un mĂȘme immeuble. 🌆 - \- **Avantages clĂ©s** : Énorme capacitĂ© d’adressage (16 millions de segments), extension L2 sur L3, flexibilitĂ© pour la virtualisation et le multi-site. + C'est comme connecter ces Ă©tages sĂ©parĂ©s Ă  travers plusieurs bĂątiments, tout en gardant l'illusion qu'ils se trouvent dans un mĂȘme immeuble. + \- **Avantages clĂ©s** : Énorme capacitĂ© d'adressage (16 millions de segments), extension L2 sur L3, flexibilitĂ© pour la virtualisation et le multi-site. -Le **VXLAN** rĂ©pond aux besoins d'isolation Ă  grande Ă©chelle, dĂ©passe les limitations des tables d'adresses MAC des commutateurs et permet un dĂ©ploiement flexible des services. De plus, associĂ© Ă  un plan de contrĂŽle efficace (BGP EVPN), il simplifie grandement la gestion des rĂ©seaux modernes en **overlay**. +Le **VXLAN** rĂ©pond aux besoins d'isolation Ă  grande Ă©chelle et dĂ©passe les limitations des tables d'adresses MAC des commutateurs. AssociĂ© Ă  un plan de contrĂŽle comme BGP EVPN, il simplifie la gestion des rĂ©seaux modernes en **overlay**. -### Conclusion 🏁 +### Conclusion -En bref, si vous recherchez une **segmentation de base** pour votre rĂ©seau local, un **VLAN** est largement suffisant. Mais dĂšs lors que vous voulez relier plusieurs sites, crĂ©er un rĂ©seau hautement virtualisĂ©, ou dĂ©passer la limite traditionnelle de 4094 VLANs, le **VXLAN** devient incontournable. +Si vous recherchez une **segmentation de base** pour votre rĂ©seau local, un **VLAN** est largement suffisant. Mais dĂšs lors que vous voulez relier plusieurs sites, crĂ©er un rĂ©seau hautement virtualisĂ©, ou dĂ©passer la limite traditionnelle de 4094 VLANs, le **VXLAN** devient incontournable. -Que vous soyez un passionnĂ© de **Lab rĂ©seau**, un ingĂ©nieur NetOps, ou tout simplement curieux des dessous de l’infrastructure informatique, comprendre ces deux notions vous aidera Ă  mieux apprĂ©hender la magie qui se dĂ©roule lorsque vos donnĂ©es circulent de plus en plus loin, tout en conservant l’illusion d’ĂȘtre “chez soi” sur le mĂȘme rĂ©seau local ! +Que vous soyez un passionnĂ© de **Lab rĂ©seau**, un ingĂ©nieur NetOps, ou tout simplement curieux des dessous de l'infrastructure informatique, comprendre ces deux notions vous aidera Ă  mieux saisir ce qui se passe lorsque vos donnĂ©es circulent de plus en plus loin, tout en conservant l'illusion d'ĂȘtre "chez soi" sur le mĂȘme rĂ©seau local ! -> [!TIP] **Envie d’aller plus loin ?** +> [!TIP] **Envie d'aller plus loin ?** > > - Regardez du cĂŽtĂ© du **BGP EVPN** pour le plan de contrĂŽle du VXLAN. > - Explorez la **configuration Jumbo MTU** pour optimiser vos performances. -> - Comparez VXLAN avec d’autres protocoles (NVGRE, GENEVE) pour comprendre les choix de design rĂ©seau. +> - Comparez VXLAN avec d'autres protocoles (NVGRE, GENEVE) pour comprendre les choix de design rĂ©seau. diff --git a/content/documentation/devpod/_index.en.md b/content/documentation/devpod/_index.en.md index 8865b3a..4509c4c 100644 --- a/content/documentation/devpod/_index.en.md +++ b/content/documentation/devpod/_index.en.md @@ -11,13 +11,13 @@ cascade: - [DevPod](https://devpod.sh/docs/what-is-devpod) ⚙ - [DevContainer](https://containers.dev) 🐳 -## Introduction 🚀 +## Introduction In this article, I want to introduce a fantastic tool that belongs to the same family as GitPod and Codespaces: **DevPod**! It lets you create development environments effortlessly — without getting locked in to a single provider. 🔒❌ DevPod is based on the **DevContainer** architecture and uses the specifications contained in a [devcontainer.json](https://containers.dev) file to launch your development environment. Personally, I use it to quickly deploy network mockups with ContainerLab. đŸ’»đŸ§° -## What is a DevContainer? đŸ€” +## What is a DevContainer? A development container (often called a "dev container") lets you use a container as a full-fledged development environment. (Check out the official [containers.dev](https://containers.dev) documentation for more details.) @@ -56,13 +56,13 @@ The cornerstone of the DevContainer is the `devcontainer.json` file. For example DevContainers are great for local development, but sometimes you need more power — maybe your workloads are huge, or you want to run specialized labs. That's where **DevPod** comes in. đŸ’Ș **So you can easily deploy labs to the Cloud** -## What is DevPod? đŸ€– +## What is DevPod? **DevPod** is an open-source tool that lets you launch development environments either on your local machine or in the cloud provider of your choice. Think of it as a self-hosted, highly customizable version of GitHub Codespaces. 🎉 In my day-to-day networking adventures, I deploy ContainerLab-based setups with DevContainers on AWS. Let's see how you can use DevPod to do exactly that (details on ContainerLab will follow in another article, I promise!). 😜 -## AWS Provider 🌐 +## AWS provider DevPod uses **Providers**, which are configuration modules that define where and how DevPod launches your environment. Here's the list of providers: @@ -74,7 +74,7 @@ We're going to focus on the **AWS Provider** — even though there are plenty of Before you panic at all these settings, don't worry. If you're just doing a bit of experimenting, the default values will usually do the job. 🙌 -> [!NOTE] **The perks of open source** 🎁 +> [!NOTE] **The perks of open source** > > The fact that DevPod is open-source means you can peek under the hood to see exactly how it works. Check out the AWS code [here](https://github.com/loft-sh/devpod-provider-aws/tree/main) if you're curious. @@ -136,7 +136,7 @@ You'll need to create an IAM user and attach an IAM policy to it that grants jus - **Route 53 (optional):** - `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets` -## AWS Configuration đŸ—ïž +## AWS configuration I usually use the AWS web console to set this up, but you can absolutely do it via the CLI too. @@ -249,7 +249,7 @@ Go back to **Users** → **devpod-tool-user** → **Permissions** to confirm tha **Bonus**: Note your **VPC ID** (in the VPC section on AWS). You'll need it when configuring DevPod. -## Configuring DevPod đŸ› ïž +## Configuring DevPod ### 1. Configure the AWS profile @@ -279,7 +279,7 @@ Click **Add Provider**. ![added_new_provider](new_provider.en.png#center) -## Testing a deployment đŸ§Ș +## Testing a deployment ### Deploy @@ -310,8 +310,8 @@ Deleting the workspace removes all AWS resources associated with that environmen ![Delete Instance](delete_instance.en.png#center) -## Conclusion 💡 +## Conclusion -By combining **DevContainers** and **DevPod** on **AWS**, you can build flexible, self-managed development environments that scale with your needs — without being locked into vendor-specific platforms. Say goodbye to "It works on my machine!" issues and hello to frictionless coding. 🚀✹ +By combining **DevContainers** and **DevPod** on **AWS**, you can build flexible, self-managed development environments that scale with your needs, without being locked into vendor-specific platforms. Say goodbye to "It works on my machine!" issues and hello to frictionless coding. -Have fun! 🎉 +Have fun! diff --git a/content/documentation/devpod/_index.fr.md b/content/documentation/devpod/_index.fr.md index a87e1fd..5aea2a7 100644 --- a/content/documentation/devpod/_index.fr.md +++ b/content/documentation/devpod/_index.fr.md @@ -11,13 +11,13 @@ cascade: - [DevPod](https://devpod.sh/docs/what-is-devpod) ⚙ - [DevContainer](https://containers.dev) 🐳 -## Introduction 🚀 +## Introduction Dans cet article, je souhaite prĂ©senter un outil fantastique qui fait partie de la mĂȘme famille que GitPod et Codespaces : **DevPod** ! Il vous permet de crĂ©er des environnements de dĂ©veloppement sans effort — sans se retrouver bloquĂ© par un fournisseur. 🔒❌ DevPod est basĂ© sur l'architecture **DevContainer** et utilise les spĂ©cifications contenues dans un fichier [devcontainer.json](https://containers.dev) pour lancer votre environnement de dĂ©veloppement. Personnellement, je l'utilise pour dĂ©ployer rapidement des maquette rĂ©seau avec ContainerLab. đŸ’»đŸ§° -## Qu'est-ce qu'un DevContainer ? đŸ€” +## Qu'est-ce qu'un DevContainer ? Un conteneur de dĂ©veloppement (souvent appelĂ© « dev container ») vous permet d'utiliser un conteneur comme un environnement de dĂ©veloppement complet. (Consultez la documentation officielle de [containers.dev](https://containers.dev) pour plus de dĂ©tails.) @@ -56,13 +56,13 @@ La pierre angulaire du DevContainer est le fichier `devcontainer.json`. Par exem Les DevContainers sont formidables pour le dĂ©veloppement local, mais parfois vous avez besoin de plus de puissance — peut-ĂȘtre que vos charges de travail sont Ă©normes, ou que vous souhaitez exĂ©cuter des laboratoires spĂ©cialisĂ©s. C'est lĂ  qu'intervient **DevPod**. đŸ’Ș **Pour pouvoir dĂ©ployer facilement des laboratoires sur le Cloud** -## Qu'est-ce que DevPod ? đŸ€– +## Qu'est-ce que DevPod ? **DevPod** est un outil open-source qui vous permet de lancer des environnements de dĂ©veloppement soit sur votre machine locale, soit dans le cloud de votre choix. Imaginez une version auto-hĂ©bergĂ©e et ultra-personnalisable de GitHub Codespaces. 🎉 Dans mes aventures quotidiennes en rĂ©seau, je dĂ©ploie des configurations basĂ©es sur ContainerLab avec des DevContainers sur AWS. Voyons comment vous pouvez utiliser DevPod pour faire exactement cela (les dĂ©tails sur ContainerLab suivront dans un autre article, promis !). 😜 -## Fournisseur AWS 🌐 +## Fournisseur AWS DevPod utilise des **Providers** (fournisseurs), qui sont des modules de configuration dĂ©finissant oĂč et comment DevPod lance votre environnement. Voici la liste des fournisseurs : @@ -74,7 +74,7 @@ Nous allons nous concentrer sur le **Provider AWS** — bien qu'il existe de nom Avant de paniquer devant tous ces rĂ©glages, ne vous inquiĂ©tez pas. Si vous ne faites que quelques expĂ©rimentations, les valeurs par dĂ©faut conviennent gĂ©nĂ©ralement. 🙌 -> [!NOTE] **Les avantages de l'open-source** 🎁 +> [!NOTE] **Les avantages de l'open-source** > > Le fait que DevPod soit open-source signifie que vous pouvez jeter un Ɠil sous le capot pour voir exactement comment il fonctionne. Consultez le code AWS [ici](https://github.com/loft-sh/devpod-provider-aws/tree/main) si vous ĂȘtes curieux. @@ -136,7 +136,7 @@ Vous devrez crĂ©er un utilisateur IAM et lui attacher une politique IAM qui acco - **Route 53 (optionnel) :** - `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets` -## Configuration AWS đŸ—ïž +## Configuration AWS J'utilise gĂ©nĂ©ralement la console web AWS pour configurer cela, mais vous pouvez tout Ă  fait le faire via la CLI. @@ -249,7 +249,7 @@ Retournez dans **Users** → **devpod-tool-user** → **Permissions** pour confi **Bonus** : Notez votre **ID VPC** (dans la section VPC sur AWS). Vous en aurez besoin lors de la configuration de DevPod. -## Configurer DevPod đŸ› ïž +## Configurer DevPod ### 1. Configurer le profil AWS @@ -279,7 +279,7 @@ Cliquez sur **Add Provider**. ![added_new_provider](new_provider.fr.png#center) -## Tester un dĂ©ploiement đŸ§Ș +## Tester un dĂ©ploiement ### DĂ©ployer @@ -310,8 +310,8 @@ Supprimer le workspace supprime toutes les ressources AWS associĂ©es Ă  cet envi ![Delete Instance](delete_instance.fr.png#center) -## Conclusion 💡 +## Conclusion -En combinant **DevContainers** et **DevPod** sur **AWS**, vous pouvez crĂ©er des environnements de dĂ©veloppement flexibles et autogĂ©rĂ©s qui Ă©voluent avec votre croissance — sans ĂȘtre enfermĂ© dans des plateformes spĂ©cifiques Ă  un fournisseur. Dites adieu aux problĂšmes du « Ça marche sur ma machine ! » et accueillez un codage sans friction. 🚀✹ +En combinant **DevContainers** et **DevPod** sur **AWS**, vous pouvez crĂ©er des environnements de dĂ©veloppement flexibles et autogĂ©rĂ©s qui Ă©voluent avec votre croissance, sans ĂȘtre enfermĂ© dans des plateformes spĂ©cifiques Ă  un fournisseur. Dites adieu aux problĂšmes du « Ça marche sur ma machine ! » et accueillez un codage sans friction. -Amusez-vous bien ! 🎉 +Amusez-vous bien ! diff --git a/content/documentation/securitĂ©/cadenas_vert/ssl.en.md b/content/documentation/securitĂ©/cadenas_vert/ssl.en.md index 386c439..def74f4 100644 --- a/content/documentation/securitĂ©/cadenas_vert/ssl.en.md +++ b/content/documentation/securitĂ©/cadenas_vert/ssl.en.md @@ -6,7 +6,7 @@ cascade: type: docs --- -## Introduction: The Padlock, Your Trust Indicator đŸ•”ïžâ€â™‚ïžâœš +## Introduction: the padlock, your trust indicator You've seen it thousands of times, haven't you? That little **green padlock** (or sometimes gray, depending on your browser and the site) that shows up next to a website's address in your navigation bar. You click on it, you look at it, you think "cool, it's secure," and you move on. @@ -15,15 +15,15 @@ You've seen it thousands of times, haven't you? That little **green padlock** (o But... do you really know what it means? đŸ€” All the **mechanics that kick in** just so this little symbol appears? It's much more than a simple icon! It's the visible part of an iceberg. \ **So, what's our mission today? 🚀** -We're going to roll up our sleeves and analyze what happens "under the hood"! Promise: we'll explain **clearly, simply, and without indigestible jargon** what actually happens when this padlock appears. We'll dissect together how it helps us know whether we can trust a site and why it's absolutely **ESSENTIAL** for our "security". +We're going to roll up our sleeves and analyze what happens "under the hood"! Promise: we'll explain **clearly, simply, and without indigestible jargon** what actually happens when this padlock appears. We'll dissect together how it helps us know whether we can trust a site and why it matters for our "security". Get ready, because you'll see that behind this little padlock hides a complex dance of certificates, secret keys, and handshakes... And by the end, you'll never look at this little symbol the same way again. -## Part 1: The SSL Certificate 💳 +## Part 1: the SSL certificate So, this famous SSL certificate, what exactly is it? Hang on tight, because it's the first piece of the puzzle! -### What is it? đŸ€” +### What is it? Imagine the SSL certificate (or TLS, we'll get to that!) as the **official digital ID card of a website**. When you present it to the police 👼, it proves who you are. \ Well, for a website, it's the same thing! @@ -37,7 +37,7 @@ It's the first guarantee that you're not being fooled by a well-disguised phishi > But since "SSL" remained popular (a bit like calling any tissue a "Kleenex"), it's still widely used. \ > In this article, we'll juggle between "SSL certificate" and "TLS certificate", but know that we're really talking about the modern, secure technology! -### Who Issues It? The Certificate Authority (CA) đŸ›ïž +### Who issues it? The certificate authority (CA) But who makes and distributes these ID cards? These are the **Certificate Authorities (CA)**. \ Think of them as **"town halls"**. @@ -54,17 +54,17 @@ And how does your browser (Chrome, Firefox, Safari...) know it can trust a CA? I > * **EV (Extended Validation):** The top of the top in verification! The CA conducts a thorough investigation into the company's identity. In the past, this often resulted in the company name being displayed in green next to the padlock. Today, browsers tend to simplify this display, but the rigor of the verification remains. > The little padlock will be there for all these types, but additional information about the organization may be visible by clicking on it for OV/EV certificates. -### What Does It Contain? 📜 +### What does it contain? Concretely, what do we find in this famous digital ID card? The essential information is: -* **The domain name concerned:** For example, `notebook.arnodo.fr`. This is crucial to make sure you're in the right place. +* **The domain name concerned:** For example, `notebook.arnodo.fr`. This confirms you're in the right place. * **The name of the owning organization:** Especially visible and verified for OV and EV certificates. This gives you an idea of who's behind the site. * **The server's public key:** 🔑 This is an ultra-important piece of code! We'll see its role in Part 2, but remember it's here, snugly stored in the certificate. It's a bit like the address of our mailbox. * **The CA's digital signature:** This is the official stamp of the "town hall" (the CA) that proves the certificate is authentic and hasn't been modified or forged since it was issued. * **The validity dates:** Like your driver's license or your passport, a certificate has a start date and an end date. An expired certificate is a big NO đŸš© for your browser! -### How Does Your Browser Verify It? â±ïžđŸ’š +### How does your browser verify it? All that's great, but how does your browser manage to verify all this in the blink of an eye (often in just a few milliseconds!) when you land on a site? It's a well-oiled little dance, a sort of express "check-up": @@ -73,7 +73,7 @@ All that's great, but how does your browser manage to verify all this in the bli 3. **Not on the blacklist (revocation):** The browser makes sure the certificate hasn't been revoked. "Revoked?" Yes, that means canceled before its expiration date. This can happen if, for example, the site got hacked and its private key (the server's secret, more on that soon) was compromised. The CA then publishes lists of canceled certificates (called CRL or via OCSP) that browsers consult. 4. **Right site, right certificate:** It checks that the domain name indicated in the certificate (for example `www.yourfavoritesite.com`) matches EXACTLY the site you're trying to reach. No cheating or identity fraud! -🏁 **The Verdict:** +**The verdict:** * **If everything's OK 👍:** The little green padlock (or gray, depending on the browser) proudly displays itself! The connection is deemed safe, and you can browse, buy, or enter your information with a (relatively) peaceful mind. * **If something's off 👎:** Your browser will sound the alarm! 🚹 You'll see a very visible warning message (something like "Your connection is not private", "Security alert", etc.). @@ -83,13 +83,13 @@ All that's great, but how does your browser manage to verify all this in the bli And that's it for the ID card! But this is only the beginning. Now that we know the site really is what it claims to be, how do we make sure our exchanges with it stay secret? That's where the magic of keys comes in... and that's the topic of our next part! -## Part 2: The Dance of the Keys 💃🔑 +## Part 2: the dance of the keys Alright, now we know the site really is what it claims to be thanks to its ID card (the SSL/TLS certificate, remember?). That's great, but it's not enough! If our exchanges with this site travel in plain text over the internet, any nosy person (or hacker đŸŽâ€â˜ ïž) could read them. Not great if you're sending your credit card number or your most secret passwords! That's where the second phase of the magic kicks in: **data encryption**. And for that, we're going to witness a real "dance of the keys"! -### Introduction to the Magic: Asymmetric Cryptography +### Introduction to the magic: asymmetric cryptography For our data to become illegible gibberish to others, we use a brilliant concept called **asymmetric cryptography**. What's that? It's the idea of having not one, but **two digital keys** that work together, like an inseparable duo: @@ -98,7 +98,7 @@ For our data to become illegible gibberish to others, we use a brilliant concept In short: what's encrypted (locked) with the public key can ONLY be decrypted (unlocked) by the corresponding private key. And vice versa (although for our "handshake", it's mostly the first direction that interests us). Clever, isn't it? -### The Simplified SSL/TLS "Handshake" +### The simplified SSL/TLS "handshake" Now that we have our keys, how do your browser and the server agree to talk secretly? Thanks to an initial negotiation, a sort of coded "handshake" called the **SSL/TLS Handshake**. Here are the steps, simplified so as not to give you a headache: @@ -117,12 +117,12 @@ From this moment on, **all the data exchanged** between your browser and the ser The communication is now secure, encrypted end-to-end! 🔒 You can relax, your secrets are (normally) well kept! -## Part 3: Why Is All This Essential For You? đŸ›ĄïžđŸŒ +## Part 3: why does this matter to you? OK, we've seen the site's ID card (the certificate) and the secret dance of keys to encrypt our conversations (the SSL/TLS handshake). \ But concretely, why go through all this trouble? -### For You, as a User +### For you, as a user When you browse a site proudly displaying this padlock (and thus using HTTPS), you benefit from several vital protections: @@ -139,29 +139,29 @@ When you browse a site proudly displaying this padlock (and thus using HTTPS), y 3. **Authentication 🆔: You're Really Talking to the Right Counter!** Thanks to the SSL/TLS certificate, you have much better assurance that you're communicating **with the legitimate site and not with a fraudulent clone**. -### For Website Owners 👑 +### For website owners If you have a website, setting up HTTPS is no longer a "nice-to-have", it has become a "must-have". Here's why: -1. **Building Trust (and Increasing Conversions!) đŸ˜ŠâžĄïžđŸ’°** - The padlock immediately reassures your visitors. They see that you take their security seriously. This is absolutely crucial for e-commerce (who would want to enter their bank details on an unsecured site?), online banking services, or any site collecting the slightest bit of personal data. An unsecured site can scare visitors away before they've even explored your content, directly impacting your credibility and, potentially, your sales or your goals. +1. **Building trust (and increasing conversions)** + The padlock immediately reassures your visitors. They see that you take their security seriously. This matters a lot for e-commerce (who would want to enter their bank details on an unsecured site?), online banking services, or any site collecting the slightest bit of personal data. An unsecured site can scare visitors away before they've even explored your content, directly impacting your credibility and, potentially, your sales or your goals. -2. **Improving Search Engine Optimization (SEO) 📈: Google Loves Secure Sites!** +2. **Improving search engine optimization (SEO): Google loves secure sites** For several years now, Google and other search engines have **actively favored HTTPS sites** in their search results. Switching your site to HTTPS can therefore give you a little boost in the rankings. Conversely, not doing so could penalize you. -3. **Protecting Your Users (and Your Reputation!) đŸ›Ąïž** +3. **Protecting your users (and your reputation)** By securing exchanges, you protect your users against the theft of their personal data. Avoiding a data leak or identity theft that would originate from a security flaw on your site also means protecting your own reputation. Bad press on this subject can be devastating. -4. **Regulatory Compliance ⚖: Sometimes, It's the Law!** +4. **Regulatory compliance: sometimes, it's the law** For certain activities and in certain regions (think GDPR in Europe, for example), securing the personal data collected and processed is a **legal obligation**. Failing to comply can result in heavy penalties. HTTPS is one of the fundamental building blocks of this compliance. -In short, this little padlock is a sign of respect toward your users, a mark of seriousness for your business, and a protection for everyone. Not bad for such a small icon, right? 😉 +This little padlock is a sign of respect toward your users and a mark of seriousness for your business. Not bad for such a small icon, right? -## Conclusion đŸ›Ąïžâœš +## Conclusion So, this little green (or gray) padlock we've dissected from every angle, it's ultimately much more than a simple graphic detail, isn't it? As we've seen, it's the **visible part of an ingenious and complex system** working hard behind the scenes. -To sum up our journey in a few words: +Quick recap: * It starts with a **digital ID card** (the SSL/TLS certificate) that assures us the site really is what it claims to be, issued by a trusted "web town hall" (the Certificate Authority). * Then, there's a **cryptographic "dance of the keys"** (the public key to encrypt a secret, the private key to decrypt it) that allows your browser and the server to agree on a unique secret code (the session key). @@ -181,7 +181,7 @@ In short, this padlock is the most visible manifestation of this **personal digi Get into the habit of **always checking for the presence of this padlock** (and hence "HTTPS" in the address) before entering any sensitive information or downloading anything on a website. Don't hesitate to **click on it for more information** if you have any doubt. And above all, be **extremely vigilant about security warning messages** that your browser might display. They're there for a good reason! -> [!NOTE]Key and Certificate File Formats +> [!NOTE] Key and certificate file formats > > You'll often encounter different file formats for keys and certificates. Here are the most common ones: > diff --git a/content/documentation/securitĂ©/cadenas_vert/ssl.fr.md b/content/documentation/securitĂ©/cadenas_vert/ssl.fr.md index ab322f1..1a470d9 100644 --- a/content/documentation/securitĂ©/cadenas_vert/ssl.fr.md +++ b/content/documentation/securitĂ©/cadenas_vert/ssl.fr.md @@ -6,7 +6,7 @@ cascade: type: docs --- -## Introduction : Le Cadenas, Votre Indice de Confiance đŸ•”ïžâ€â™‚ïžâœš +## Introduction : le cadenas, votre indice de confiance Vous l'avez vu des milliers de fois, n'est-ce pas ? Ce petit **cadenas vert** (ou parfois gris, selon votre navigateur et le site) qui se prĂ©sente Ă  cĂŽtĂ© de l'adresse d'un site web dans votre barre de navigation. On clique dessus, on le voit, on se dit "cool, c'est sĂ©curisĂ©", et on passe Ă  autre chose. @@ -15,15 +15,15 @@ Vous l'avez vu des milliers de fois, n'est-ce pas ? Ce petit **cadenas vert** (o Mais... savez-vous vraiment ce qu'il signifie ? đŸ€” Toute la **mĂ©canique qui se dĂ©clenche** rien que pour que ce petit symbole s'affiche ? C'est bien plus qu'une simple icĂŽne ! C'est la partie visible d'un iceberg. \ **Alors, quelle est notre mission aujourd'hui ? 🚀** -On va enfiler nos gants et analyser se qu'il se passe "sous le capot" ! Promis, on va expliquer de façon **claire, simple, et sans jargon indigeste** ce qui se passe rĂ©ellement quand ce cadenas apparaĂźt. On va dĂ©cortiquer ensemble comment il nous aide Ă  savoir si on peut faire confiance Ă  un site et pourquoi c'est absolument **ESSENTIEL** pour notre "sĂ©curitĂ©". +On va enfiler nos gants et analyser ce qu'il se passe "sous le capot" ! Promis, on va expliquer de façon **claire, simple, et sans jargon indigeste** ce qui se passe rĂ©ellement quand ce cadenas apparaĂźt. On va dĂ©cortiquer ensemble comment il nous aide Ă  savoir si on peut faire confiance Ă  un site et pourquoi ça compte pour notre "sĂ©curitĂ©". PrĂ©parez-vous, car vous allez voir que derriĂšre ce petit cadenas se cache une danse complexe de certificats, de clĂ©s secrĂštes, et de poignĂ©es de main... Et Ă  la fin, vous ne regarderez plus jamais ce petit symbole de la mĂȘme maniĂšre. -## Partie 1 : Le Certificat SSL 💳 +## Partie 1 : le certificat SSL Alors, ce fameux certificat SSL, c'est quoi au juste ? Accrochez-vous, car c'est la premiĂšre piĂšce du puzzle ! -### Qu'est-ce que c'est ? đŸ€” +### Qu'est-ce que c'est ? Imaginez le certificat SSL (ou TLS, on y reviendra !) comme la **carte d'identitĂ© numĂ©rique officielle d'un site web**. Quand vous la prĂ©sentez Ă  la gendarmerie 👼, elle prouve qui vous ĂȘtes. \ Eh bien, pour un site web, c'est pareil ! @@ -37,7 +37,7 @@ C'est la premiĂšre garantie que vous n'ĂȘtes pas en train de vous faire avoir pa > Mais comme "SSL" est restĂ© populaire (un peu comme "Frigidaire" pour parler d'un rĂ©frigĂ©rateur), on l'utilise encore beaucoup. \ > Dans cet article, on jonglera entre "certificat SSL" et "certificat TLS", mais sachez qu'on parle bien de la technologie moderne et sĂ©curisĂ©e ! -### Qui le dĂ©livre ? L'AutoritĂ© de Certification (CA) đŸ›ïž +### Qui le dĂ©livre ? L'autoritĂ© de certification (CA) Mais qui fabrique et distribue ces cartes d'identitĂ© ? Ce sont les **AutoritĂ©s de Certification (CA)**. \ Pensez Ă  elles comme Ă  des **"mairies"**. @@ -54,17 +54,17 @@ Et comment votre navigateur (Chrome, Firefox, Safari...) sait-il qu'il peut fair > * **EV (Extended Validation) :** Le top du top de la vĂ©rification ! La CA mĂšne une enquĂȘte approfondie sur l'identitĂ© de l'entreprise. Avant, cela se traduisait souvent par l'affichage du nom de l'entreprise en vert Ă  cĂŽtĂ© du cadenas. Aujourd'hui, les navigateurs tendent Ă  simplifier cet affichage, mais la rigueur de la vĂ©rification reste. > Le petit cadenas sera lĂ  pour tous ces types, mais des informations supplĂ©mentaires sur l'organisation peuvent ĂȘtre visibles en cliquant dessus pour les certificats OV/EV. -### Que contient-il 📜 +### Que contient-il ? ConcrĂštement, qu'est-ce qu'on trouve dans cette fameuse carte d'identitĂ© numĂ©rique ? Les informations essentielles sont : -* **Le nom du domaine concernĂ© :** Par exemple, `notebook.arnodo.fr`. C'est crucial pour s'assurer que vous ĂȘtes au bon endroit. +* **Le nom du domaine concernĂ© :** Par exemple, `notebook.arnodo.fr`. Cela permet de s'assurer que vous ĂȘtes au bon endroit. * **Le nom de l'organisation propriĂ©taire :** Surtout visible et vĂ©rifiĂ© pour les certificats OV et EV. Ça vous donne une idĂ©e de qui est derriĂšre le site. * **La clĂ© publique du serveur :** 🔑 C'est un morceau de code ultra-important ! On va voir son rĂŽle dans la partie 2, mais retenez qu'elle est ici, bien au chaud dans le certificat. C'est un peu l'adresse de notre boĂźte aux lettres. * **La signature numĂ©rique de la CA :** C'est le tampon officiel de la "mairie" (la CA) qui prouve que le certificat est authentique et n'a pas Ă©tĂ© modifiĂ© ou falsifiĂ© depuis sa dĂ©livrance. * **Les dates de validitĂ© :** Comme votre permis de conduire ou votre passeport, un certificat a une date de dĂ©but et une date de fin. Un certificat expirĂ©, c'est un gros NON đŸš© pour votre navigateur ! -### Comment votre navigateur le vĂ©rifie-t-il ? â±ïžđŸ’š +### Comment votre navigateur le vĂ©rifie-t-il ? Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vĂ©rifier tout ça en un clin d'Ɠil (souvent en quelques millisecondes Ă  peine !) quand vous arrivez sur un site ? C'est une petite danse bien huilĂ©e, une sorte de "check-up" express : @@ -73,7 +73,7 @@ Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vĂ©rifier 3. **Pas sur la liste noire (rĂ©vocation) :** Le navigateur s'assure que le certificat n'a pas Ă©tĂ© rĂ©voquĂ©. "RĂ©voquĂ© ?" Oui, ça veut dire annulĂ© avant sa date d'expiration. Ça peut arriver si, par exemple, le site s'est fait pirater et que sa clĂ© privĂ©e (le secret du serveur, on en reparle bientĂŽt) a Ă©tĂ© compromise. La CA publie alors des listes de certificats annulĂ©s (appelĂ©es CRL ou via OCSP) que les navigateurs consultent. 4. **Bon site, bon certificat :** Il vĂ©rifie que le nom de domaine indiquĂ© dans le certificat (par exemple `www.votresiteprefere.com`) correspond EXACTEMENT au site que vous essayez de joindre. Pas de triche ou d'arnaque Ă  l'identitĂ© ! -🏁 **Le Verdict :** +**Le verdict :** * **Si tout est OK 👍 :** Le petit cadenas vert (ou gris, selon le navigateur) s'affiche fiĂšrement ! La connexion est jugĂ©e sĂ»re, et vous pouvez naviguer, acheter, ou entrer vos informations l'esprit (relativement) tranquille. * **Si quelque chose cloche 👎 :** Votre navigateur va tirer la sonnette d'alarme ! 🚹 Vous verrez un message d'avertissement bien visible (du genre "Votre connexion n'est pas privĂ©e", "Alerte de sĂ©curitĂ©", etc.). @@ -83,13 +83,13 @@ Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vĂ©rifier Et voilĂ  pour la carte d'identitĂ© ! Mais ce n'est que le dĂ©but. Maintenant qu'on sait que le site est bien qui il prĂ©tend ĂȘtre, comment fait-on pour que nos Ă©changes avec lui restent secrets ? C'est lĂ  qu'intervient la magie des clĂ©s... et c'est le sujet de notre prochaine partie ! -## Partie 2 : La Danse des ClĂ©s 💃🔑 +## Partie 2 : la danse des clĂ©s Bon, maintenant on sait que le site est bien celui qu'il prĂ©tend ĂȘtre grĂące Ă  sa carte d'identitĂ© (le certificat SSL/TLS, vous vous souvenez ?). C'est super, mais ça ne suffit pas ! Si nos Ă©changes avec ce site se baladent en clair sur internet, n'importe quel petit curieux (ou pirate đŸŽâ€â˜ ïž) pourrait les lire. Pas top si vous envoyez votre numĂ©ro de carte bleue ou vos mots de passe les plus secrets ! C'est lĂ  qu'intervient la deuxiĂšme phase de la magie : **le chiffrement des donnĂ©es**. Et pour ça, on va assister Ă  une vĂ©ritable "danse des clĂ©s" ! -### Introduction Ă  la Magie : La Cryptographie AsymĂ©trique +### Introduction Ă  la magie : la cryptographie asymĂ©trique Pour que nos donnĂ©es deviennent un charabia illisible pour les autres, on utilise un concept gĂ©nial appelĂ© **cryptographie asymĂ©trique**. KĂ©sako ? C'est l'idĂ©e d'avoir non pas une, mais **deux clĂ©s numĂ©riques** qui fonctionnent ensemble, comme un duo insĂ©parable : @@ -117,12 +117,12 @@ Maintenant qu'on a nos clĂ©s, comment votre navigateur et le serveur se mettent- La communication est dĂ©sormais sĂ©curisĂ©e, chiffrĂ©e de bout en bout ! 🔒 Vous pouvez souffler, vos secrets sont (normalement) bien gardĂ©s ! -## Partie 3 : Pourquoi Tout Cela Est Essentiel Pour Vous ? đŸ›ĄïžđŸŒ +## Partie 3 : pourquoi cela compte pour vous ? OK, on a vu la carte d'identitĂ© du site (le certificat) et la danse secrĂšte des clĂ©s pour chiffrer nos conversations (le handshake SSL/TLS). \ Mais concrĂštement, pourquoi se donner autant de mal ? -### Pour Vous, en Tant qu'Utilisateur +### Pour vous, en tant qu'utilisateur Quand vous naviguez sur un site affichant fiĂšrement ce cadenas (et donc utilisant HTTPS), vous bĂ©nĂ©ficiez de plusieurs protections vitales : @@ -139,25 +139,25 @@ Quand vous naviguez sur un site affichant fiĂšrement ce cadenas (et donc utilisa 3. **Authentification 🆔 : Vous Parlez Bien au Bon Guichet !** GrĂące au certificat SSL/TLS, vous avez une bien meilleure assurance que vous communiquez **avec le site lĂ©gitime et non avec un clone frauduleux**. -### Pour les PropriĂ©taires de Sites Web 👑 +### Pour les propriĂ©taires de sites web Si vous avez un site web, mettre en place HTTPS n'est plus un "nice-to-have", c'est devenu un "must-have". Voici pourquoi : -1. **Instaurer la Confiance (et Augmenter les Conversions !) đŸ˜ŠâžĄïžđŸ’°** - Le cadenas rassure immĂ©diatement vos visiteurs. Ils voient que vous prenez leur sĂ©curitĂ© au sĂ©rieux. C'est absolument crucial pour l'e-commerce (qui voudrait entrer ses infos bancaires sur un site non sĂ©curisĂ© ?), les services bancaires en ligne, ou tout site qui collecte la moindre donnĂ©e personnelle. Un site non sĂ©curisĂ© peut faire fuir les visiteurs avant mĂȘme qu'ils n'aient explorĂ© votre contenu, impactant directement votre crĂ©dibilitĂ© et, potentiellement, vos ventes ou vos objectifs. +1. **Instaurer la confiance (et augmenter les conversions)** + Le cadenas rassure immĂ©diatement vos visiteurs. Ils voient que vous prenez leur sĂ©curitĂ© au sĂ©rieux. Cela compte beaucoup pour l'e-commerce (qui voudrait entrer ses infos bancaires sur un site non sĂ©curisĂ© ?), les services bancaires en ligne, ou tout site qui collecte la moindre donnĂ©e personnelle. Un site non sĂ©curisĂ© peut faire fuir les visiteurs avant mĂȘme qu'ils n'aient explorĂ© votre contenu, impactant directement votre crĂ©dibilitĂ© et, potentiellement, vos ventes ou vos objectifs. -2. **AmĂ©liorer le RĂ©fĂ©rencement (SEO) 📈 : Google Aime les Sites SĂ©curisĂ©s !** +2. **AmĂ©liorer le rĂ©fĂ©rencement (SEO) : Google aime les sites sĂ©curisĂ©s** Depuis plusieurs annĂ©es, Google et d'autres moteurs de recherche **favorisent activement les sites en HTTPS** dans leurs rĂ©sultats de recherche. Passer votre site en HTTPS peut donc vous donner un petit coup de pouce dans les classements. À l'inverse, ne pas le faire pourrait vous pĂ©naliser. -3. **ProtĂ©ger Vos Utilisateurs (et Votre RĂ©putation !) đŸ›Ąïž** +3. **ProtĂ©ger vos utilisateurs (et votre rĂ©putation)** En sĂ©curisant les Ă©changes, vous protĂ©gez vos utilisateurs contre le vol de leurs donnĂ©es personnelles. Éviter une fuite de donnĂ©es ou une usurpation d'identitĂ© qui aurait pour origine une faille de sĂ©curitĂ© sur votre site, c'est aussi protĂ©ger votre propre rĂ©putation. Une mauvaise presse Ă  ce sujet peut ĂȘtre dĂ©vastatrice. -4. **ConformitĂ© RĂ©glementaire ⚖ : Parfois, C'est la Loi !** +4. **ConformitĂ© rĂ©glementaire : parfois, c'est la loi** Pour certaines activitĂ©s et dans certaines rĂ©gions (pensez au RGPD en Europe, par exemple), la sĂ©curisation des donnĂ©es personnelles collectĂ©es et traitĂ©es est une **obligation lĂ©gale**. Ne pas s'y conformer peut entraĂźner de lourdes sanctions. HTTPS est une des briques fondamentales de cette conformitĂ©. -En bref, ce petit cadenas, c'est un signe de respect envers vos utilisateurs, un gage de sĂ©rieux pour votre activitĂ©, et une protection pour tout le monde. Pas mal pour une si petite icĂŽne, non ? 😉 +Ce petit cadenas est un signe de respect envers vos utilisateurs et un gage de sĂ©rieux pour votre activitĂ©. Pas mal pour une si petite icĂŽne, non ? -## Conclusion đŸ›Ąïžâœš +## Conclusion Alors, ce petit cadenas vert (ou gris) qu'on a dĂ©cortiquĂ© sous toutes ses coutures, c'est finalement bien plus qu'un simple dĂ©tail graphique, n'est-ce pas ? On l'a vu, c'est la **partie visible d'un ingĂ©nieux et complexe systĂšme** qui travaille d'arrache-pied en coulisses. @@ -181,7 +181,7 @@ Bref, ce cadenas est la manifestation la plus visible de ce **garde du corps num Prenez l'habitude de **toujours vĂ©rifier la prĂ©sence de ce cadenas** (et donc du "HTTPS" dans l'adresse) avant de saisir la moindre information sensible ou de tĂ©lĂ©charger quoi que ce soit sur un site web. N'hĂ©sitez pas Ă  **cliquer dessus pour obtenir plus d'informations** si vous avez un doute. Et surtout, soyez **extrĂȘmement vigilants face aux messages d'avertissement de sĂ©curitĂ©** que votre navigateur pourrait afficher. Ils sont lĂ  pour une bonne raison ! -> [!NOTE]Les Formats de Fichiers des ClĂ©s et Certificats +> [!NOTE] Les formats de fichiers des clĂ©s et certificats > > Vous rencontrerez souvent diffĂ©rents formats de fichiers pour les clĂ©s et certificats. Voici les plus courants : > diff --git a/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.en.md b/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.en.md index e64ff0d..69af9fd 100644 --- a/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.en.md +++ b/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.en.md @@ -141,7 +141,7 @@ TLS interception is not a technical decision to be taken lightly. It involves ac In a corporate setting, implementing SSL Bumping must be accompanied by strict rules: - **Transparency**: Users must be informed that their professional traffic is being analyzed (generally via the IT charter). -- **Exceptions (Bypass)**: It's essential to configure the proxy to not intercept certain categories of sites, particularly banking and healthcare services, in order to respect employees' privacy. +- **Exceptions (Bypass)**: The proxy needs to be configured to not intercept certain categories of sites, particularly banking and healthcare services, in order to respect employees' privacy. - **CA Security**: The private key of the internal certificate authority must be protected drastically. If it's compromised, an attacker could generate valid fake certificates across the entire IT fleet. ## Conclusion diff --git a/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.md b/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.md index 029d911..f303240 100644 --- a/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.md +++ b/content/documentation/securitĂ©/ssl_bumping/ssl_bumping.md @@ -141,7 +141,7 @@ L'interception TLS n'est pas une dĂ©cision technique Ă  prendre Ă  la lĂ©gĂšre. En entreprise, la mise en place du SSL Bumping doit s'accompagner de rĂšgles strictes : - **Transparence** : Les utilisateurs doivent ĂȘtre informĂ©s que leur trafic professionnel est analysĂ© (gĂ©nĂ©ralement via la charte informatique). -- **Exceptions (Bypass)** : Il est indispensable de configurer le proxy pour ne pas intercepter certaines catĂ©gories de sites, notamment les banques et les services de santĂ©, afin de respecter la vie privĂ©e des collaborateurs. +- **Exceptions (Bypass)** : Le proxy doit ĂȘtre configurĂ© pour ne pas intercepter certaines catĂ©gories de sites, notamment les banques et les services de santĂ©, afin de respecter la vie privĂ©e des collaborateurs. - **SĂ©curitĂ© de la CA** : La clĂ© privĂ©e de l'autoritĂ© de certification interne doit ĂȘtre protĂ©gĂ©e de maniĂšre drastique. Si elle est compromise, un attaquant pourrait gĂ©nĂ©rer de faux certificats valides sur tout le parc informatique. ## Conclusion diff --git a/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.en.md b/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.en.md index 5131c6a..bd2b164 100644 --- a/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.en.md +++ b/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.en.md @@ -6,11 +6,11 @@ cascade: type: docs --- -## Introduction 📚 +## Introduction In this article, we're going to explore how to automate the deployment of a VXLAN infrastructure by relying on **Netbox** as our single source of truth (*Source of Truth*) and its **"Render Config"** feature. -The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.** 💡 +The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.** To illustrate this approach, we'll use the example of a fictional site, **"Paris"**, designed according to clear and precise standardization rules. This standardization will allow us to: @@ -18,17 +18,17 @@ To illustrate this approach, we'll use the example of a fictional site, **"Paris 2. **Generate** the network device configurations based on the information centralized in Netbox. 3. **Validate** the proper operation of this automated infrastructure using a **NetLab** lab environment running on ContainerLab. -Through this concrete example, we'll highlight the fact that standardization isn't a constraint, but rather the **essential foundation** for successful automation and simplified, efficient network management. +Through this concrete example, we'll show that standardization isn't a constraint, but the foundation for successful automation and simpler, more efficient network management. > [!NOTE] **CookBook** > All of the actions explained in this article are described [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates). > This article will **not** provide a step-by-step guide, but will provide links to the Cookbook, which does. -## The Concept of the Standardized Site ⚙ +## The concept of the standardized site Effective automation of a network infrastructure relies on a solid foundation of standardization. To illustrate this principle, we've defined a **standard site** model, characterized by a precise structure and precise connectivity rules. Our "Paris" site will be a concrete instance of this standardized model. -### Typical Structure of a Standard Site 🏱 +### Typical structure of a standard site A standard site is defined by the following elements: @@ -36,7 +36,7 @@ A standard site is defined by the following elements: * **One to Five Single-Story Buildings:** Each building is dedicated to hosting a single customer (although the same customers can be spread across multiple buildings). Each standard building is equipped with an access switch for local connectivity and a single leaf for connecting to the fabric. -### Standard Leaf Connectivity 🔗 +### Standard leaf connectivity In a standard site, the connection of leaf devices to the spines follows these rules: @@ -50,7 +50,7 @@ In a standard site, the connection of leaf devices to the spines follows these r > For the purposes of this **Proof of Concept**, we opted for a simplified architecture without advanced redundancy at the leaf-spine connection level. > The main goal is to demonstrate automation based on this standardized structure. -### IP Addressing Plan for the "Paris" Site 🌐 +### IP addressing plan for the "Paris" site For our "Paris" site, we'll use the following Netbox prefix containers, which fit into our overall addressing strategy: @@ -70,13 +70,13 @@ For our "Paris" site, we'll use the following Netbox prefix containers, which fi These "Container" type prefixes are specific to the "Paris" site and will be used by our automation scripts to assign IP addresses to the various devices and customers at this site, in accordance with the standard structure we've defined. -## The "Paris" Site: An Instance of Our Standardized Model 📍 +## The "Paris" site: an instance of our standardized model Our "Paris" site strictly follows the structure and rules defined in our standard site model. It will therefore include a server room with the two spines and can host up to five single-story buildings, each equipped with a leaf and an access switch, connected according to the established conventions. The IP addressing for "Paris" will come from the standard prefix containers we've defined. This standardization is the key that will allow us to automate the creation and configuration of our "Paris" site infrastructure using the scripts we're about to present. -## Test Environment +## Test environment The POC will run on ContainerLab, so it's necessary to refer to [this article](../../documentation/devpod) to easily reproduce the installation and the tools. @@ -89,11 +89,11 @@ We'll be using: For more details, [here's the installation documentation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md) -## Scripting: Automation in Action! ⚙ +## Scripting: automation in action Now we get to the heart of the matter: how we use scripts to automate the creation of our VXLAN fabric by relying on Netbox. We'll look at two main scripts that do most of the heavy lifting! -### Step 1: Preparing Netbox with `import.py` đŸ› ïž +### Step 1: preparing Netbox with `import.py` Before we build our network, we need to prepare our "Source of Truth," Netbox. The [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) script is here for that! It will inject into Netbox the basic information for our "Paris" site and the models for our devices. @@ -122,19 +122,19 @@ Make sure to replace `http://localhost:8080` with your Netbox address and `YOUR_ > [!TIP] > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) -### Step 2: Building the VXLAN Fabric with `Create_Fabric/main.py` 🚀 +### Step 2: building the VXLAN fabric with `Create_Fabric/main.py` Now that Netbox is ready, we move on to building our network with the `Create_Fabric/main.py` script. This script will create all the devices, connect them, and assign them IP addresses, all while following our standardized model for the "Paris" site. **The Script's Steps:** -1. **Ready Check? ✅** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations! -2. **Choosing the Site: "Paris" Of Course! đŸ‡«đŸ‡·** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices. -3. **Bringing Out the Spines (x2) đŸ’Ș** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`. -4. **Leaf/Access Pairs per Building đŸąâžĄïž** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`). -5. **Automatic Cabling đŸ§¶** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables! -6. **IP Distribution đŸ—ș** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks). -7. **ASN Assignment đŸ·ïž** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox. +1. **Ready check.** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations. +2. **Choosing the site: "Paris" of course.** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices. +3. **Bringing out the spines (x2).** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`. +4. **Leaf/access pairs per building.** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`). +5. **Automatic cabling.** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables. +6. **IP distribution.** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks). +7. **ASN assignment.** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox. ```bash uv run Create_Fabric/main.py @@ -150,7 +150,7 @@ Existing Sites: Choose site number or 'new': 1 ``` -**The Result? 🎉** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured! +**The result?** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured. > [!NOTE] Netbox Plugin > The configuration can easily be visualized with the help of the plugin: [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views) @@ -160,13 +160,13 @@ Choose site number or 'new': 1 > [!TIP] > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric) -### Step 3: Configuring Our Customers with `Create_Fabric/add_customers.py` đŸ§‘â€đŸ’» +### Step 3: configuring our customers with `Create_Fabric/add_customers.py` -At this point, the fabric is functional, but no customer is configured yet. What does that mean? đŸ€” It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet. +At this point, the fabric is functional, but no customer is configured yet. What does that mean? It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet. -In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI). đŸąâžĄïžđŸ§‘â€đŸ’» +In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI). -To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. 📋 Here's an example of it running: +To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. Here's an example of it running: ```bash ❯ uv run Create_Fabric/add_customers.py @@ -198,7 +198,7 @@ Available Locations: Select locations (comma-separated indices): 1,3 ``` -Once this information is provided, the script takes care of automating several actions in Netbox ✹: +Once this information is provided, the script takes care of automating several actions in Netbox: * Creation of the tenant (representing the customer). * Assignment of buildings (locations) to the tenant. @@ -206,22 +206,22 @@ Once this information is provided, the script takes care of automating several a * Logical configuration of the associated VXLAN/VLAN elements. * Assignment of specific interfaces on the access devices for this customer. -Once Netbox is properly populated with all this customer data 📊, it then becomes possible to extract the final, ready-to-use network configuration from it. ⚙ +Once Netbox is properly populated with all this customer data, it then becomes possible to extract the final, ready-to-use network configuration from it. -## The Magic of Templates: Netbox and Jinja2 Take the Stage ✹ +## Generating configs with Netbox and Jinja2 templates Now that we have our network inventory all set up in Netbox, how do we tell our devices how to configure themselves? That's where **Render Config** and **Jinja2 templates** come in! > [!TIP] Templates > The templates used are available [here](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates). -### Jinja Templates: Our Configuration Recipes 📝 +### Jinja templates: our configuration recipes -1. **What Are Render Configs, Anyway? đŸ€”** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices. +1. **What are Render Configs, anyway?** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices. -2. **Jinja2: Our Recipe Language đŸ—Łïž** To write these configuration "recipes," Netbox uses a super powerful engine called Jinja2. It's a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox. +2. **Jinja2: our recipe language.** To write these configuration "recipes," Netbox uses a powerful engine called Jinja2, a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox. -3. **A Quick Look at a Recipe 📜** Let's take an example of a Jinja2 template for one of our leafs: +3. **A quick look at a recipe.** Let's take an example of a Jinja2 template for one of our leafs: ```jinja hostname {{ device.name }} @@ -242,7 +242,7 @@ Now that we have our network inventory all set up in Netbox, how do we tell our See those things between double curly braces `{{ ... }}`? Those are our variables! For example, `{{ device.name }}` will be replaced with the name of our leaf, and `{{ interface.name }}` with the name of each interface. We can even add conditions (`{% if ... %}`) and loops (`{% for ... %}`) to adapt the configuration. -4. **How Netbox Prepares the Dish 🍳** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens: +4. **How Netbox prepares the dish.** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens: * It looks up all the information about this leaf: its name, its interfaces, its IPs, its connections, its ASN, etc. * It takes the Jinja2 template that we've associated with the "leaf" role. @@ -252,11 +252,11 @@ Now that we have our network inventory all set up in Netbox, how do we tell our > [!TIP] > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates) -### From Netbox to the Lab: Looking and Doing It by Hand for Now đŸ–„ïžâžĄïžđŸ’» +### From Netbox to the lab: doing it by hand for now Now that we know how Netbox generates the configurations, let's see how we use them in our Containerlab lab. -1. **Taking a Look at the Configuration in Netbox 👀** To view the configuration generated by Netbox for a device, it's simple: +1. **Taking a look at the configuration in Netbox.** To view the configuration generated by Netbox for a device, it's simple: * In the Netbox interface, go to **Devices**. * Click on the device you're interested in (for example, one of our leafs). @@ -264,27 +264,27 @@ Now that we know how Netbox generates the configurations, let's see how we use t ![PA01 Leaf Configuration]() -2. **The Human Touch in Containerlab đŸ–ïž** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (but that's fine for a demo!): +2. **The human touch in Containerlab.** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (fine for a demo): * We connect to each cEOS device in our lab via SSH (for example, using the Containerlab VSCode extension as we saw in the [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)). * We copy the configuration we viewed in Netbox (the **Render Config** tab). * And we paste it into the cEOS device's command-line interface (in configuration mode, of course!). -3. **What's Next? Future Perspectives 🚀** Of course, this copy-paste step isn't the pinnacle of automation! But it's a first step toward seeing how Netbox can be our central brain. In the future, we could imagine tools like Ansible or NAPALM connecting to Netbox, retrieving these generated configurations, and automatically applying them to our devices. That's a path for future adventures in automation! 😉 +3. **What's next?** This copy-paste step isn't the pinnacle of automation, but it's a first step toward seeing how Netbox can be our central brain. Down the line, tools like Ansible or NAPALM could connect to Netbox, retrieve these generated configurations, and apply them to our devices automatically. -## Validating Communication ✅ +## Validating communication -### Ping âšœ +### Ping In the cookbook, we chose to configure 2 customers each in 2 different buildings, which lets us run a **ping**. As a reminder: -1. 🟠 Orange: +1. Orange: * Subnet: 10.0.0.0/24 * Hosts: * PA1: 10.0.0.10 * PA3: 10.0.0.20 -2. 🟣 Purple +2. Purple * Subnet: 10.0.1.0/24 * Hosts: * PA2: 10.0.1.10 @@ -305,7 +305,7 @@ PING 10.0.0.20 (10.0.0.20): 56 data bytes ... ``` -### Packet Capture +### Packet capture To go further, it's also possible to use Wireshark, which is available by default in the devcontainer, with the help of Edgeshark. For more information, I'll point you to the article on [My First Lab](../../netlab/first_lab/#utiliser-edgeshark-) @@ -316,11 +316,9 @@ And then, via VSCode, it's possible to launch Wireshark directly: ![Capture Wireshark](wireshark_eth2_leaf1.en.png) -## Conclusion ✹ +## Conclusion -To sum up our journey, we've seen how Netbox becomes our best ally đŸ„‡ for automating the VXLAN network. -The key is to start from **a standardized foundation** 📐 — that's what allows Netbox to generate our configurations almost entirely on its own, thanks to Jinja2 templates. +Netbox turns out to be a solid ally for automating the VXLAN network. +The key is starting from a standardized foundation: that's what lets Netbox generate our configurations almost entirely on its own, using Jinja2 templates. -Even though, for now, we're still doing a bit of copy-pasting đŸ–ïž, the potential is huge! Having all our information centralized in Netbox is the first step toward truly simplifying our network management and opening the door to full automation. Standardization isn't a constraint, but a springboard toward greater efficiency. ✅ - -This is only the beginning! Think about what comes next: automatically deploying these configs, managing more complex networks... Automation is here, accessible, ready to save you precious time. 🚀đŸ’Ș +We're still copying and pasting the last step by hand, but centralizing all our information in Netbox is the first move toward simplifying network management and opening the door to full automation. Next up: deploying these configs automatically and handling more complex networks. diff --git a/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.fr.md b/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.fr.md index 0dbbdbd..f11f95f 100644 --- a/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.fr.md +++ b/content/netlab/automatisation rĂ©seau/vxlan_automation/_index.fr.md @@ -6,7 +6,7 @@ cascade: type: docs --- -## Introduction 📚 +## Introduction Dans cet article, nous allons explorer comment automatiser le dĂ©ploiement d'une infrastructure VXLAN en nous appuyant sur **Netbox** comme source unique de vĂ©ritĂ© (*Source of Truth*) et sa fonctionnalitĂ© de **"Render Config"**. @@ -18,17 +18,17 @@ Pour illustrer cette approche, nous allons prendre l'exemple d'un site fictif, * 2. **GĂ©nĂ©rer** les configurations des Ă©quipements rĂ©seau en se basant sur les informations centralisĂ©es dans Netbox. 3. **Valider** le bon fonctionnement de cette infrastructure automatisĂ©e Ă  l'aide d'un environnement de laboratoire **NetLab** sous ContainerLab. -À travers cet exemple concret, nous mettrons en lumiĂšre que la standardisation n'est pas une contrainte, mais plutĂŽt le **socle indispensable** pour une automatisation rĂ©ussie et une gestion rĂ©seau simplifiĂ©e et efficace. +À travers cet exemple concret, nous montrerons que la standardisation n'est pas une contrainte, mais le socle d'une automatisation rĂ©ussie et d'une gestion rĂ©seau simplifiĂ©e et efficace. > [!NOTE] **CookBook** > L'ensemble des actions expliquĂ©es dans cet article sont dĂ©crites [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates). > Cette article **ne** nous fournira **pas** un guide Ă©tape par Ă©tape, mais fournira les liens vers le Cookbook qui lui, le fourni. -## Le Concept du Site StandardisĂ© ⚙ +## Le concept du site standardisĂ© L'automatisation efficace d'une infrastructure rĂ©seau repose sur une base solide de standardisation. Pour illustrer ce principe, nous avons dĂ©fini un modĂšle de **site standard**, caractĂ©risĂ© par une structure et des rĂšgles de connectivitĂ© prĂ©cises. Notre site "Paris" sera une instance concrĂšte de ce modĂšle standardisĂ©. -### Structure Type d'un Site Standard 🏱 +### Structure type d'un site standard Un site standard est dĂ©fini par les Ă©lĂ©ments suivants : @@ -36,7 +36,7 @@ Un site standard est dĂ©fini par les Ă©lĂ©ments suivants : * **Un Ă  Cinq BĂątiments Plain-Pied :** Chaque bĂątiment est dĂ©diĂ© Ă  l'hĂ©bergement d'un seul client (bien que les mĂȘmes clients puissent ĂȘtre rĂ©partis sur plusieurs bĂątiments). Chaque bĂątiment standard est Ă©quipĂ© d'un switch d'accĂšs pour la connectivitĂ© locale et d'un unique leaf pour la connexion Ă  la fabric. -### ConnectivitĂ© Standard des Leafs 🔗 +### ConnectivitĂ© standard des leafs Dans un site standard, la connexion des Ă©quipements leaf aux spines suit les rĂšgles suivantes : @@ -50,7 +50,7 @@ Dans un site standard, la connexion des Ă©quipements leaf aux spines suit les r > Pour les besoins de ce **Proof of Concept**, nous avons optĂ© pour une architecture simplifiĂ©e sans redondance avancĂ©e au niveau des connexions leaf-spine. > L'objectif principal est de dĂ©montrer l'automatisation basĂ©e sur cette structure standardisĂ©e. -### Plan d'Adressage IP pour le Site "Paris" 🌐 +### Plan d'adressage IP pour le site "Paris" Pour notre site "Paris", nous allons utiliser les conteneurs de prĂ©fixes Netbox suivants, qui s'inscrivent dans notre stratĂ©gie d'adressage globale : @@ -70,15 +70,15 @@ Pour notre site "Paris", nous allons utiliser les conteneurs de prĂ©fixes Netbox Ces prĂ©fixes de type "Conteneur" sont spĂ©cifiques au site de "Paris" et seront utilisĂ©s par nos scripts d'automatisation pour attribuer les adresses IP aux diffĂ©rents Ă©quipements et clients de ce site, en respectant la structure standard que nous avons dĂ©finie. -## Le Site "Paris" : Une Instance de Notre ModĂšle StandardisĂ© 📍 +## Le site "Paris" : une instance de notre modĂšle standardisĂ© Notre site "Paris" suit scrupuleusement la structure et les rĂšgles dĂ©finies dans notre modĂšle de site standard. Il comprendra donc une salle serveur avec les deux spines et pourra accueillir jusqu'Ă  cinq bĂątiments plain-pied, chacun Ă©quipĂ© d'un leaf et d'un switch d'accĂšs, connectĂ©s selon les conventions Ă©tablies. L'adressage IP de "Paris" sera issu des conteneurs de prĂ©fixes standard que nous avons dĂ©finis. Cette standardisation est la clĂ© qui nous permettra d'automatiser la crĂ©ation et la configuration de l'infrastructure de notre site "Paris" Ă  l'aide des scripts que nous allons prĂ©senter ensuite. -## Environment de test +## Environnement de test -Le POC se jouera sur ContainerLab, il est donc nĂ©cessaire de se refĂ©rencer Ă  [cette article](../../documentation/devpod) afin de facilement reproduire l'installation et les outils. +Le POC se joue sur ContainerLab, il est donc nĂ©cessaire de se rĂ©fĂ©rer Ă  [cet article](../../documentation/devpod) pour reproduire facilement l'installation et les outils. Nous utiliserons : @@ -87,29 +87,29 @@ Nous utiliserons : * Netbox * Plugin : netbox_topology_views -Pour plus de dĂ©tails, [voici la documentationation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md) +Pour plus de dĂ©tails, [voici la documentation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md) -## Scripting : L'Automatisation en Action ! ⚙ +## Scripting : l'automatisation en action Maintenant, on entre dans le vif du sujet : comment on utilise des scripts pour automatiser la crĂ©ation de notre fabric VXLAN en s'appuyant sur Netbox. On va voir deux scripts principaux qui font le gros du boulot ! -### Étape 1 : On PrĂ©pare Netbox avec `import.py` đŸ› ïž +### Étape 1 : on prĂ©pare Netbox avec `import.py` Avant de construire notre rĂ©seau, il faut prĂ©parer notre "Source of Truth", Netbox. Le script [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) est lĂ  pour ça ! Il va injecter dans Netbox les infos de base de notre site "Paris" et les modĂšles de nos Ă©quipements. -**Les IngrĂ©dients du Script :** +**Les ingrĂ©dients du script :** * **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml) :** La carte d'identitĂ© de nos Ă©quipements (spines, leafs, access cEOS) avec leurs caractĂ©ristiques (nombre d'interfaces, types, etc.). * **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml) :** Les infos de notre site "Paris" (rĂ©gion Europe, ville Paris) et les plans de nos blocs d'adresses IP (pour l'underlay, les loopbacks et nos clients). -**Ce Que Fait le Script :** +**Ce que fait le script :** * Il lit le fichier `devices_model.yml` et crĂ©e les modĂšles d'Ă©quipements correspondants dans Netbox. C'est comme enregistrer les types de matĂ©riel qu'on va utiliser. * Il lit le fichier `IPAM/subnet.yml` et crĂ©e : * La rĂ©gion "Europe" et le site "Paris". * Les blocs d'adresses IP qu'on va utiliser pour notre rĂ©seau Ă  Paris (nos "prĂ©fixes conteneurs"). -**Comment on Lance la Machine :** +**Comment on lance la machine :** On ouvre notre terminal et on tape la commande : @@ -122,19 +122,19 @@ Remplace bien `http://localhost:8080` par l'adresse de ton Netbox et `YOUR_TOKEN > [!TIP] > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) -### Étape 2 : On Monte la Fabric VXLAN avec `Create_Fabric/main.py` 🚀 +### Étape 2 : on monte la fabric VXLAN avec `Create_Fabric/main.py` Maintenant que Netbox est prĂȘt, on passe Ă  la construction de notre rĂ©seau avec le script `Create_Fabric/main.py`. Ce script va crĂ©er tous les Ă©quipements, les connecter et leur attribuer des adresses IP, le tout en suivant notre modĂšle standardisĂ© pour le site "Paris". -**Les Étapes du Script :** +**Les Ă©tapes du script :** -1. **VĂ©rification des PrĂȘts ? ✅** Le script commence par vĂ©rifier si tout ce dont il a besoin existe dans Netbox (les rĂŽles des Ă©quipements, les rĂŽles IP, les types d'Ă©quipements). On ne veut pas commencer Ă  construire sur des bases instables ! -2. **Choix du Terrain : "Paris" Évidemment ! đŸ‡«đŸ‡·** Le script nous demande sur quel site on travaille. On sĂ©lectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos Ă©quipements. -3. **On Sort les Spines (x2) đŸ’Ș** Le script crĂ©e nos deux spines dans Netbox, en utilisant le bon modĂšle et le rĂŽle "spine". Ils sont baptisĂ©s `padc_sp1_00` et `padc_sp2_00`. -4. **Les Paires Leaf/Access par BĂątiment đŸąâžĄïž** Pour chaque bĂątiment de "Paris" (jusqu'Ă  5), le script crĂ©e une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accĂšs (par exemple `pa01_sw1_00`). -5. **CĂąblage Automatique đŸ§¶** Le script connecte virtuellement les Ă©quipements dans Netbox en suivant nos rĂšgles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les cĂąbles ! -6. **Distribution des IPs đŸ—ș** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les Ă©quipements et des /32 pour les loopbacks). -7. **Attribution des ASNs đŸ·ïž** Pour finir, le script donne un numĂ©ro d'AS Ă  chaque spine et Ă  chaque leaf pour le routage BGP. Ces numĂ©ros sont enregistrĂ©s dans un champ spĂ©cial "ASN" dans Netbox. +1. **VĂ©rification prĂ©alable.** Le script commence par vĂ©rifier si tout ce dont il a besoin existe dans Netbox (les rĂŽles des Ă©quipements, les rĂŽles IP, les types d'Ă©quipements). On ne veut pas commencer Ă  construire sur des bases instables. +2. **Choix du site : "Paris" Ă©videmment.** Le script nous demande sur quel site on travaille. On sĂ©lectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos Ă©quipements. +3. **On sort les spines (x2).** Le script crĂ©e nos deux spines dans Netbox, en utilisant le bon modĂšle et le rĂŽle "spine". Ils sont baptisĂ©s `padc_sp1_00` et `padc_sp2_00`. +4. **Les paires leaf/access par bĂątiment.** Pour chaque bĂątiment de "Paris" (jusqu'Ă  5), le script crĂ©e une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accĂšs (par exemple `pa01_sw1_00`). +5. **CĂąblage automatique.** Le script connecte virtuellement les Ă©quipements dans Netbox en suivant nos rĂšgles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les cĂąbles. +6. **Distribution des IPs.** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les Ă©quipements et des /32 pour les loopbacks). +7. **Attribution des ASNs.** Pour finir, le script donne un numĂ©ro d'AS Ă  chaque spine et Ă  chaque leaf pour le routage BGP. Ces numĂ©ros sont enregistrĂ©s dans un champ spĂ©cial "ASN" dans Netbox. ```bash uv run Create_Fabric/main.py @@ -150,7 +150,7 @@ Existing Sites: Choose site number or 'new': 1 ``` -**Le RĂ©sultat ? 🎉** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" crĂ©Ă©e et connectĂ©e dans Netbox, prĂȘte Ă  ĂȘtre configurĂ©e ! +**Le rĂ©sultat ?** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" crĂ©Ă©e et connectĂ©e dans Netbox, prĂȘte Ă  ĂȘtre configurĂ©e. > [!NOTE] Netbox Plugin > La configuration est facilement visualisable avec l'aide du plugin : [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views) @@ -160,13 +160,13 @@ Choose site number or 'new': 1 > [!TIP] > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric) -### Étape 3 : On configure nos clients avec `Create_Fabric/add_customers.py` đŸ§‘â€đŸ’» +### Étape 3 : on configure nos clients avec `Create_Fabric/add_customers.py` -À ce niveau, la fabric est fonctionnelle, mais aucun client n'est configurĂ©. Qu'est-ce que cela signifie ? đŸ€” Cela veut dire que l'*underlay* – la base de notre rĂ©seau – est configurĂ© sur Netbox, et qu'il est possible de gĂ©nĂ©rer une configuration pour dĂ©ployer le BGP et configurer les AS. Cependant, les switches d'accĂšs et les leafs ne sont pas encore prĂȘts Ă  accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore. +À ce niveau, la fabric est fonctionnelle, mais aucun client n'est configurĂ©. Qu'est-ce que cela signifie ? Cela veut dire que l'*underlay* – la base de notre rĂ©seau – est configurĂ© sur Netbox, et qu'il est possible de gĂ©nĂ©rer une configuration pour dĂ©ployer le BGP et configurer les AS. Cependant, les switches d'accĂšs et les leafs ne sont pas encore prĂȘts Ă  accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore. -Dans notre approche standardisĂ©e, chaque bĂątiment est conçu pour accueillir **un** "client". Un client peut ĂȘtre, par exemple, une Ă©quipe spĂ©cifique au sein de l'entreprise ou un prestataire externe. À chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant). đŸąâžĄïžđŸ§‘â€đŸ’» +Dans notre approche standardisĂ©e, chaque bĂątiment est conçu pour accueillir **un** "client". Un client peut ĂȘtre, par exemple, une Ă©quipe spĂ©cifique au sein de l'entreprise ou un prestataire externe. À chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant). -Pour rĂ©aliser cette configuration client, nous utilisons un script dĂ©diĂ© : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas Ă  pas en nous demandant le VLAN et le VNI Ă  attribuer, ainsi que le ou les bĂątiments oĂč sont basĂ©s nos clients. 📋 Voici un exemple de son exĂ©cution : +Pour rĂ©aliser cette configuration client, nous utilisons un script dĂ©diĂ© : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas Ă  pas en nous demandant le VLAN et le VNI Ă  attribuer, ainsi que le ou les bĂątiments oĂč sont basĂ©s nos clients. Voici un exemple de son exĂ©cution : ```bash ❯ uv run Create_Fabric/add_customers.py @@ -198,7 +198,7 @@ Available Locations: Select locations (comma-separated indices): 1,3 ``` -Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox ✹ : +Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox : * La crĂ©ation du tenant (reprĂ©sentant le client). * L'attribution des bĂątiments (locations) au tenant. @@ -206,22 +206,22 @@ Une fois ces informations fournies, le script se charge d'automatiser plusieurs * La configuration logique des Ă©lĂ©ments VXLAN/VLAN associĂ©s. * L'attribution des interfaces spĂ©cifiques sur les Ă©quipements d'accĂšs pour ce client. -Une fois Netbox correctement renseignĂ© avec toutes ces donnĂ©es clients 📊, il devient alors possible d'en extraire la configuration rĂ©seau finale prĂȘte Ă  l'emploi. ⚙ +Une fois Netbox correctement renseignĂ© avec toutes ces donnĂ©es clients, il devient alors possible d'en extraire la configuration rĂ©seau finale prĂȘte Ă  l'emploi. -## La Magie des Templates : Netbox et Jinja2 Entrent en ScĂšne ✹ +## GĂ©nĂ©rer les configurations avec Netbox et Jinja2 Maintenant qu'on a notre inventaire rĂ©seau au top dans Netbox, comment on dit Ă  nos Ă©quipements comment se configurer ? C'est lĂ  qu'interviennent les **Render Config** et les **templates Jinja2** ! > [!TIP] Templates > Les templates utilisĂ©s sont prĂ©sents [ici](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates). -### Les Templates Jinja : Nos Recettes de Configuration 📝 +### Les templates Jinja : nos recettes de configuration -1. **Les Render Config, KĂ©sako ? đŸ€”** Imagine Netbox comme un chef cuisinier qui a tous les ingrĂ©dients (nos Ă©quipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa maniĂšre de transformer ces ingrĂ©dients en plats prĂ©parĂ©s, c'est-Ă -dire des fichiers de configuration pour nos Ă©quipements rĂ©seau. +1. **Les Render Config, kĂ©sako ?** Imagine Netbox comme un chef cuisinier qui a tous les ingrĂ©dients (nos Ă©quipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa maniĂšre de transformer ces ingrĂ©dients en plats prĂ©parĂ©s, c'est-Ă -dire des fichiers de configuration pour nos Ă©quipements rĂ©seau. -2. **Jinja2 : Notre Langage de Recettes đŸ—Łïž** Pour Ă©crire ces "recettes" de configuration, Netbox utilise un moteur super puissant appelĂ© Jinja2. C'est un peu comme un langage de programmation simple qui nous permet de crĂ©er des modĂšles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos Ă©quipements dans Netbox. +2. **Jinja2 : notre langage de recettes.** Pour Ă©crire ces "recettes" de configuration, Netbox utilise un moteur puissant appelĂ© Jinja2, un peu comme un langage de programmation simple qui nous permet de crĂ©er des modĂšles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos Ă©quipements dans Netbox. -3. **Un Petit Coup d'ƒil Ă  une Recette 📜** Prenons un exemple de template Jinja2 pour un de nos leafs : +3. **Un petit coup d'Ɠil Ă  une recette.** Prenons un exemple de template Jinja2 pour un de nos leafs : ```jinja hostname {{ device.name }} @@ -242,7 +242,7 @@ Maintenant qu'on a notre inventaire rĂ©seau au top dans Netbox, comment on dit Vous voyez les trucs entre doubles accolades `{{ ... }}` ? Ce sont nos variables ! Par exemple, `{{ device.name }}` sera remplacĂ© par le nom de notre leaf, et `{{ interface.name }}` par le nom de chaque interface. On peut mĂȘme faire des conditions (`{% if ... %}`) et des boucles (`{% for ... %}`) pour adapter la configuration. -4. **Comment Netbox PrĂ©pare le Plat 🍳** Quand on demande Ă  Netbox de gĂ©nĂ©rer la configuration pour un Ă©quipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe : +4. **Comment Netbox prĂ©pare le plat.** Quand on demande Ă  Netbox de gĂ©nĂ©rer la configuration pour un Ă©quipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe : * Il va chercher toutes les infos sur ce leaf : son nom, ses interfaces, ses IPs, ses connexions, son ASN, etc. * Il prend le template Jinja2 qu'on a associĂ© au rĂŽle "leaf". @@ -252,11 +252,11 @@ Maintenant qu'on a notre inventaire rĂ©seau au top dans Netbox, comment on dit > [!TIP] > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates) -### De Netbox au Lab : On Regarde et On Fait Ă  la Main pour l'Instant đŸ–„ïžâžĄïžđŸ’» +### De Netbox au lab : on fait Ă  la main pour l'instant Maintenant qu'on sait comment Netbox gĂ©nĂšre les configurations, voyons comment on les utilise dans notre lab Containerlab. -1. **On Jette un ƒil Ă  la Configuration dans Netbox 👀** Pour voir la configuration gĂ©nĂ©rĂ©e par Netbox pour un Ă©quipement, c'est simple : +1. **On jette un Ɠil Ă  la configuration dans Netbox.** Pour voir la configuration gĂ©nĂ©rĂ©e par Netbox pour un Ă©quipement, c'est simple : * Dans l'interface de Netbox, on va dans **Devices**. * On clique sur l'Ă©quipement qui nous intĂ©resse (par exemple, un de nos leafs). @@ -264,27 +264,27 @@ Maintenant qu'on sait comment Netbox gĂ©nĂšre les configurations, voyons comment ![PA01 Leaf Configuration]() -2. **La Touche Humaine dans Containerlab đŸ–ïž** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations Ă  nos Ă©quipements dans Containerlab. Donc, on va faire Ă  l'ancienne (mais c'est pour la dĂ©mo !) : +2. **La touche humaine dans Containerlab.** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations Ă  nos Ă©quipements dans Containerlab. Donc, on va faire Ă  l'ancienne (mais c'est bien suffisant pour la dĂ©mo) : * On se connecte Ă  chaque Ă©quipement cEOS de notre lab via SSH (par exemple, en utilisant l'extension VSCode Containerlab comme on l'a vu dans le [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)). * On copie la configuration qu'on a visualisĂ©e dans Netbox (l'onglet **Render Config**). * Et on la colle dans l'interface de ligne de commande de l'Ă©quipement cEOS (en mode configuration, bien sĂ»r !). -3. **Et AprĂšs ? Les Perspectives d'Évolution 🚀** Bien sĂ»r, cette Ă©tape de copier-coller, c'est pas le top de l'automatisation ! Mais c'est une premiĂšre Ă©tape pour voir comment Netbox peut ĂȘtre notre cerveau central. Dans le futur, on pourrait imaginer des outils comme Ansible ou NAPALM qui se connecteraient Ă  Netbox, rĂ©cupĂ©reraient ces configurations gĂ©nĂ©rĂ©es et les appliqueraient automatiquement Ă  nos Ă©quipements. C'est une piste pour de prochaines aventures dans l'automatisation ! 😉 +3. **Et aprĂšs ?** Cette Ă©tape de copier-coller n'est pas le sommet de l'automatisation, mais c'est une premiĂšre Ă©tape pour voir comment Netbox peut devenir notre cerveau central. Plus tard, des outils comme Ansible ou NAPALM pourraient se connecter Ă  Netbox, rĂ©cupĂ©rer ces configurations gĂ©nĂ©rĂ©es et les appliquer automatiquement Ă  nos Ă©quipements. -## Validation de la communication ✅ +## Validation de la communication -### Ping âšœ +### Ping -Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 batiments diffĂ©rent, ce qui nous permet de rĂ©alisĂ© un **ping**, pour rappel : +Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 bĂątiments diffĂ©rents, ce qui nous permet de rĂ©aliser un **ping**, pour rappel : -1. 🟠 Orange: - * Sous RĂ©seau: 10.0.0.0/24 - * Hosts: - * PA1: 10.0.0.10 - * PA3: 10.0.0.20 +1. Orange : + * Sous-rĂ©seau : 10.0.0.0/24 + * Hosts : + * PA1 : 10.0.0.10 + * PA3 : 10.0.0.20 -2. 🟣 Purple +2. Purple * Sous RĂ©seau: 10.0.1.0/24 * Hosts: * PA2: 10.0.1.10 @@ -316,11 +316,9 @@ Et ensuite, via VSCode, il est possible de lancer wireshark directement : ![Capture Wireshark](wireshark_eth2_leaf1.png) -## Conclusion ✹ +## Conclusion -Pour rĂ©sumer notre parcours, on a vu comment Netbox devient notre super alliĂ© đŸ„‡ pour automatiser le rĂ©seau VXLAN. -La clĂ©, c'est de partir d'**une base standardisĂ©e** 📐, c'est ce qui permet Ă  Netbox de gĂ©nĂ©rer nos configurations presque tout seul grĂące aux templates Jinja2. +Netbox devient un alliĂ© solide pour automatiser le rĂ©seau VXLAN. +La clĂ©, c'est de partir d'une base standardisĂ©e : c'est ce qui permet Ă  Netbox de gĂ©nĂ©rer nos configurations presque tout seul grĂące aux templates Jinja2. -MĂȘme si, pour l'instant, on fait encore un peu de copier-coller đŸ–ïž, le potentiel est immense ! Avoir toutes nos infos centralisĂ©es dans Netbox, c'est la premiĂšre Ă©tape pour vraiment simplifier la gestion de notre rĂ©seau et ouvrir la porte Ă  une automatisation complĂšte. La standardisation n'est pas une contrainte, mais le tremplin vers plus d'efficacitĂ©. ✅ - -Ce n'est que le dĂ©but ! Pensez Ă  la suite : dĂ©ployer ces configs automatiquement, gĂ©rer des rĂ©seaux plus complexes... L'automatisation est lĂ , accessible, prĂȘte Ă  vous faire gagner un temps prĂ©cieux. 🚀đŸ’Ș +On fait encore un peu de copier-coller sur la derniĂšre Ă©tape, mais centraliser toutes nos infos dans Netbox est la premiĂšre Ă©tape pour simplifier la gestion de notre rĂ©seau et ouvrir la porte Ă  une automatisation complĂšte. La suite : dĂ©ployer ces configurations automatiquement et gĂ©rer des rĂ©seaux plus complexes. diff --git a/content/netlab/first_lab/_index.en.md b/content/netlab/first_lab/_index.en.md index 5f89305..bca0073 100644 --- a/content/netlab/first_lab/_index.en.md +++ b/content/netlab/first_lab/_index.en.md @@ -8,11 +8,11 @@ cascade: type: docs --- -## Introduction 📚 +## Introduction -In this article, we're going to explore how to set up our very first Containerlab netlab using **DevPod**. -We'll focus on using a cloud provider, in this case **AWS**, to host our project. -Why the **Cloud**? Because network labs can consume a huge amount of resources, and we need to be able to deploy, stop, and destroy them quickly, both for performance and cost efficiency. 💡💰 +In this article, we're going to set up our very first Containerlab netlab using **DevPod**. +We'll use a cloud provider, in this case **AWS**, to host our project. +Why the cloud? Because network labs can consume a huge amount of resources, and we need to deploy, stop, and destroy them quickly, both for performance and cost. We'll achieve this by combining: @@ -20,20 +20,17 @@ We'll achieve this by combining: - **DevContainer** - **Containerlab** -In addition, we'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main goal is to deploy this lab on AWS with DevPod. -Let's get to it! 🚀😊 +We'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our goal is to deploy this lab on AWS with DevPod. -## Prerequisites 🔧 +## Prerequisites -Before starting, a few important steps need to be taken: +Before starting, a few things need to be in place: -1. **AWS Environment Authorization**: - Make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/). 🔑 +1. AWS environment authorization: make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/). -2. **Containerlab Topology**: - We need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology. đŸ—ș +2. Containerlab topology: we need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology. -## Containerlab Topology 🔄 +## Containerlab topology Our lab will simulate a VXLAN topology consisting of: @@ -82,7 +79,7 @@ topology: - endpoints: ["leaf2:eth2", "host2:eth1"] ``` -### Breaking Down the Topology 🧐 +### Breaking down the topology 1. **Name and Structure**: - `name: vxlan-evpn-irb` – This is the name of the lab. @@ -108,18 +105,17 @@ topology: - `leaf1:eth2` ↔ `host1:eth1` - `leaf2:eth2` ↔ `host2:eth1` -This topology represents a typical spine-leaf architecture, common in datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. đŸ”—đŸ’» +This topology is a typical spine-leaf architecture, common in datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. -## Deploying the Lab đŸ› ïž +## Deploying the lab We'll deploy the lab with **DevPod** in two ways: -### 1. Using the Repository đŸ“„ +### 1. Using the repository -1. **Validate the AWS Provider Configuration**: - Make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/). ✅ +1. Validate the AWS provider configuration: make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/). -2. **Create a Workspace**: +2. Create a workspace: - Go to the **Workspace** tab and click **Create Workspace**. - Specify the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). - Select **AWS** as the provider. @@ -128,40 +124,33 @@ We'll deploy the lab with **DevPod** in two ways: ![DevPod Configuration](devpod_configuration.en.png#center) -### 2. Using a Local Folder đŸ—‚ïž +### 2. Using a local folder -If you prefer to use your local repository: - -- The only difference is in the **Workspace source**. -- Simply point it to your local repository. +If you prefer to use your local repository, the only difference is in the **Workspace source**: simply point it to your local repository. ![DevPod Configuration - Local](devpod_configuration_local.en.png#center) -## Starting the Lab 🎬 +## Starting the lab -> [!WARNING] cEOS Images -> The lab uses **cEOS image v4.32.0.1F**. -> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download). ⚠ +> [!WARNING] cEOS images +> The lab uses **cEOS image v4.32.0.1F**. +> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download). -1. **Import the cEOS Image**: - Save the cEOS image into your `network_images` folder by dragging and dropping it into VSCode. - Import the image using the following command: +1. Import the cEOS image: save the cEOS image into your `network_images` folder by dragging and dropping it into VSCode. Import the image using the following command: ```bash docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F ``` -2. **Deploy the Lab**: - Deploy the lab using Containerlab: +2. Deploy the lab using Containerlab: ```bash sudo containerlab deploy -t lab_vxlan.yml ``` - Follow the CLI instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). đŸ”§đŸ–„ïž + Follow the CLI instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). -3. **Visualize the Architecture**: - Check the deployed topology using Containerlab's graphical view: +3. Visualize the architecture: check the deployed topology using Containerlab's graphical view. ```bash containerlab graph -t lab_vxlan.yml @@ -171,13 +160,13 @@ If you prefer to use your local repository: ![Graph View](Graph_view.en.png#center) -## Using EdgeShark 🩈 +## Using EdgeShark -EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally. 📡🔍 +EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally. For more information, check out the [EdgeShark getting started guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin). -### Configuring EdgeShark in the DevContainer 🐳 +### Configuring EdgeShark in the DevContainer In the **DevContainer** configuration, the following `postCreateCommand` was added: @@ -185,9 +174,9 @@ In the **DevContainer** configuration, the following `postCreateCommand` was add sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml ``` -This command downloads a Docker Compose file to make it easier to use EdgeShark. 🚀 +This command downloads a Docker Compose file to make it easier to use EdgeShark. -### Launching EdgeShark ⚡ +### Launching EdgeShark To start EdgeShark, run: @@ -198,22 +187,13 @@ DOCKER_DEFAULT_PLATFORM= docker compose up -d Access EdgeShark via [localhost:5001](http://localhost:5001). -- **EdgeShark View**: +- EdgeShark view: ![EdgeShark View](edgeshark.en.png#center) -- **Integration with Wireshark**: - By clicking the Wireshark icon in EdgeShark, you can launch Wireshark locally. - ![EdgeShark Interface](edgeshark_interface.en.png#center) +- Integration with Wireshark: clicking the Wireshark icon in EdgeShark launches Wireshark locally. + ![EdgeShark Interface](edgeshark_interface.en.png#center) ![EdgeShark and Wireshark](edge_wireshark.en.png#center) -## Conclusion 🎉 +## Conclusion -In this article, we walked through the steps to deploy a VXLAN EVPN lab using Containerlab, DevPod, and AWS. We covered the following key points: - -- **Setting up the prerequisites** for AWS and Containerlab. 🔑 -- **Creating a detailed topology file** for a spine-leaf architecture. đŸ—ș -- **Deploying the lab** using both a GitHub repository and a local folder. đŸ“„đŸ—‚ïž -- **Starting the lab** with Docker and Containerlab. 🚀🐳 -- **Using EdgeShark** to capture packets and integrate Wireshark for in-depth analysis. 🩈🔍 - -By following these steps, you'll be able to easily deploy and manage a scalable network lab environment in the cloud. Happy networking, and enjoy your lab adventures! 😄🎊 +That covers the full setup: prerequisites, the VXLAN topology, deploying the lab with DevPod on AWS, and capturing traffic with EdgeShark and Wireshark. From here you have a working spine-leaf lab you can tear down and redeploy whenever you need it. diff --git a/content/netlab/first_lab/_index.fr.md b/content/netlab/first_lab/_index.fr.md index d0b197a..e06579f 100644 --- a/content/netlab/first_lab/_index.fr.md +++ b/content/netlab/first_lab/_index.fr.md @@ -8,11 +8,11 @@ cascade: type: docs --- -## Introduction 📚 +## Introduction -Dans cet article, nous allons explorer comment installer notre tout premier netlab Containerlab en utilisant **DevPod**. -Nous nous concentrerons sur l'utilisation d'un fournisseur cloud, en l'occurrence **AWS**, pour hĂ©berger notre projet. -Pourquoi le **Cloud** ? Parce que les labs rĂ©seau peuvent consommer Ă©normĂ©ment de ressources, et nous avons besoin de pouvoir les dĂ©ployer, les arrĂȘter et les dĂ©truire rapidement, tant pour la performance que pour l'efficacitĂ© financiĂšre. 💡💰 +Dans cet article, nous allons installer notre tout premier netlab Containerlab en utilisant **DevPod**. +Nous utiliserons un fournisseur cloud, en l'occurrence **AWS**, pour hĂ©berger notre projet. +Pourquoi le cloud ? Parce que les labs rĂ©seau peuvent consommer Ă©normĂ©ment de ressources, et nous avons besoin de pouvoir les dĂ©ployer, les arrĂȘter et les dĂ©truire rapidement, tant pour la performance que pour le coĂ»t. Nous y parviendrons en combinant : @@ -20,20 +20,17 @@ Nous y parviendrons en combinant : - **DevContainer** - **Containerlab** -De plus, nous utiliserons une topologie simple que vous pouvez retrouver sur mon [dĂ©pĂŽt GitHub](https://github.com/darnodo/VXLAN-EVPN). Notre objectif principal est de dĂ©ployer ce lab sur AWS avec DevPod. -Allons-y, c'est parti ! 🚀😊 +Nous utiliserons une topologie simple que vous pouvez retrouver sur mon [dĂ©pĂŽt GitHub](https://github.com/darnodo/VXLAN-EVPN). Notre objectif est de dĂ©ployer ce lab sur AWS avec DevPod. -## PrĂ©requis 🔧 +## PrĂ©requis -Avant de commencer, quelques Ă©tapes importantes sont Ă  rĂ©aliser : +Avant de commencer, quelques Ă©lĂ©ments doivent ĂȘtre en place : -1. **Autorisation de l'environnement AWS** : - Assurez-vous que DevPod est autorisĂ© Ă  accĂ©der Ă  votre environnement AWS. Pour un guide dĂ©taillĂ© sur la configuration de DevPod avec AWS, consultez mon article sur ce [sujet](../../documentation/devpod/). 🔑 +1. Autorisation de l'environnement AWS : assurez-vous que DevPod est autorisĂ© Ă  accĂ©der Ă  votre environnement AWS. Pour un guide dĂ©taillĂ© sur la configuration de DevPod avec AWS, consultez mon article sur ce [sujet](../../documentation/devpod/). -2. **Topologie Containerlab** : - Nous avons besoin d'un fichier de topologie comprĂ©hensible par Containerlab. Dans notre cas, nous crĂ©ons une topologie VXLAN simple. đŸ—ș +2. Topologie Containerlab : nous avons besoin d'un fichier de topologie comprĂ©hensible par Containerlab. Dans notre cas, nous crĂ©ons une topologie VXLAN simple. -## Topologie Containerlab 🔄 +## Topologie Containerlab Notre lab simulera une topologie VXLAN comprenant : @@ -82,7 +79,7 @@ topology: - endpoints: ["leaf2:eth2", "host2:eth1"] ``` -### DĂ©cryptage de la Topologie 🧐 +### DĂ©cryptage de la topologie 1. **Nom et Structure** : - `name: vxlan-evpn-irb` – C'est le nom du lab. @@ -108,18 +105,17 @@ topology: - `leaf1:eth2` ↔ `host1:eth1` - `leaf2:eth2` ↔ `host2:eth1` -Cette topologie reprĂ©sente une architecture spine-leaf typique, courante dans les datacenters pour permettre une connectivitĂ© en couche 2 et en couche 3 avec des configurations VXLAN EVPN. đŸ”—đŸ’» +Cette topologie est une architecture spine-leaf typique, courante dans les datacenters pour permettre une connectivitĂ© en couche 2 et en couche 3 avec des configurations VXLAN EVPN. -## DĂ©ployer le Lab đŸ› ïž +## DĂ©ployer le lab Nous allons dĂ©ployer le lab avec **DevPod** de deux maniĂšres : -### 1. En Utilisant le DĂ©pĂŽt đŸ“„ +### 1. En utilisant le dĂ©pĂŽt -1. **Valider la configuration du fournisseur AWS** : - Assurez-vous que votre fournisseur AWS est correctement configurĂ©. Plus de dĂ©tails [ici](../../documentation/devpod/). ✅ +1. Valider la configuration du fournisseur AWS : assurez-vous que votre fournisseur AWS est correctement configurĂ©. Plus de dĂ©tails [ici](../../documentation/devpod/). -2. **CrĂ©er un Workspace** : +2. CrĂ©er un workspace : - Rendez-vous dans l'onglet **Workspace** et cliquez sur **Create Workspace**. - Indiquez la **source du Workspace** : utilisez le [dĂ©pĂŽt GitHub](https://github.com/darnodo/VXLAN-EVPN). - SĂ©lectionnez **AWS** comme fournisseur. @@ -128,40 +124,33 @@ Nous allons dĂ©ployer le lab avec **DevPod** de deux maniĂšres : ![Configuration DevPod](devpod_configuration.fr.png#center) -### 2. En Utilisant un Dossier Local đŸ—‚ïž +### 2. En utilisant un dossier local -Si vous prĂ©fĂ©rez utiliser votre dĂ©pĂŽt local : - -- La seule diffĂ©rence se trouve dans la **source du Workspace**. -- Il vous suffit de le pointer vers votre dĂ©pĂŽt local. +Si vous prĂ©fĂ©rez utiliser votre dĂ©pĂŽt local, la seule diffĂ©rence se trouve dans la **source du Workspace** : il suffit de le pointer vers votre dĂ©pĂŽt local. ![Configuration DevPod - Local](devpod_configuration_local.fr.png#center) -## DĂ©marrer le Lab 🎬 +## DĂ©marrer le lab -> [!WARNING] Images cEOS -> Le lab utilise l'**image cEOS v4.32.0.1F**. -> Pour tĂ©lĂ©charger cette image, rendez-vous sur la [page de tĂ©lĂ©chargement Arista](https://www.arista.com/en/support/software-download). ⚠ +> [!WARNING] Images cEOS +> Le lab utilise l'**image cEOS v4.32.0.1F**. +> Pour tĂ©lĂ©charger cette image, rendez-vous sur la [page de tĂ©lĂ©chargement Arista](https://www.arista.com/en/support/software-download). -1. **Importer l'image cEOS** : - Enregistrez l'image cEOS dans votre dossier `network_images` en la glissant-dĂ©posant dans VSCode. - Importez l'image en utilisant la commande suivante : +1. Importer l'image cEOS : enregistrez l'image cEOS dans votre dossier `network_images` en la glissant-dĂ©posant dans VSCode. Importez l'image en utilisant la commande suivante : ```bash docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F ``` -2. **DĂ©ployer le Lab** : - DĂ©ployez le lab en utilisant Containerlab : +2. DĂ©ployer le lab en utilisant Containerlab : ```bash sudo containerlab deploy -t lab_vxlan.yml ``` - Suivez les instructions du CLI pour configurer vos pĂ©riphĂ©riques. Pour des Ă©tapes de configuration dĂ©taillĂ©es, consultez [ce guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). đŸ”§đŸ–„ïž + Suivez les instructions du CLI pour configurer vos pĂ©riphĂ©riques. Pour des Ă©tapes de configuration dĂ©taillĂ©es, consultez [ce guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). -3. **Visualiser l'Architecture** : - VĂ©rifiez la topologie dĂ©ployĂ©e grĂące Ă  la vue graphique de Containerlab : +3. Visualiser l'architecture : vĂ©rifiez la topologie dĂ©ployĂ©e grĂące Ă  la vue graphique de Containerlab. ```bash containerlab graph -t lab_vxlan.yml @@ -171,13 +160,13 @@ Si vous prĂ©fĂ©rez utiliser votre dĂ©pĂŽt local : ![Vue Graphique](Graph_view.fr.png#center) -## Utiliser EdgeShark 🩈 +## Utiliser EdgeShark -EdgeShark est un outil web qui permet de capturer des paquets depuis votre environnement de lab. Il redirige les captures du lab vers Wireshark exĂ©cutĂ© localement. 📡🔍 +EdgeShark est un outil web qui permet de capturer des paquets depuis votre environnement de lab. Il redirige les captures du lab vers Wireshark exĂ©cutĂ© localement. Pour plus d'informations, consultez le [guide de dĂ©marrage d'EdgeShark](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin). -### Configuration d'EdgeShark dans le DevContainer 🐳 +### Configuration d'EdgeShark dans le DevContainer Dans la configuration du **DevContainer**, la commande `postCreateCommand` suivante a Ă©tĂ© ajoutĂ©e : @@ -185,9 +174,9 @@ Dans la configuration du **DevContainer**, la commande `postCreateCommand` suiva sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml ``` -Cette commande tĂ©lĂ©charge un fichier Docker Compose pour faciliter l'utilisation d'EdgeShark. 🚀 +Cette commande tĂ©lĂ©charge un fichier Docker Compose pour faciliter l'utilisation d'EdgeShark. -### Lancer EdgeShark ⚡ +### Lancer EdgeShark Pour dĂ©marrer EdgeShark, exĂ©cutez : @@ -198,22 +187,13 @@ DOCKER_DEFAULT_PLATFORM= docker compose up -d AccĂ©dez Ă  EdgeShark via [localhost:5001](http://localhost:5001). -- **Vue d'EdgeShark** : +- Vue d'EdgeShark : ![Vue d'EdgeShark](edgeshark.fr.png#center) -- **IntĂ©gration avec Wireshark** : - En cliquant sur l'icĂŽne Wireshark dans EdgeShark, vous pouvez lancer Wireshark localement. - ![Interface EdgeShark](edgeshark_interface.fr.png#center) +- IntĂ©gration avec Wireshark : cliquer sur l'icĂŽne Wireshark dans EdgeShark lance Wireshark localement. + ![Interface EdgeShark](edgeshark_interface.fr.png#center) ![EdgeShark et Wireshark](edge_wireshark.fr.png#center) -## Conclusion 🎉 +## Conclusion -Dans cet article, nous avons parcouru les Ă©tapes pour dĂ©ployer un lab VXLAN EVPN en utilisant Containerlab, DevPod et AWS. Nous avons abordĂ© les points clĂ©s suivants : - -- **Mise en place des prĂ©requis** pour AWS et Containerlab. 🔑 -- **CrĂ©ation d'un fichier de topologie dĂ©taillĂ©** pour une architecture spine-leaf. đŸ—ș -- **DĂ©ploiement du lab** en utilisant Ă  la fois un dĂ©pĂŽt GitHub et un dossier local. đŸ“„đŸ—‚ïž -- **DĂ©marrage du lab** avec Docker et Containerlab. 🚀🐳 -- **Utilisation d'EdgeShark** pour capturer des paquets et intĂ©grer Wireshark pour une analyse approfondie. 🩈🔍 - -En suivant ces Ă©tapes, vous pourrez dĂ©ployer et gĂ©rer facilement un environnement de lab rĂ©seau Ă©volutif dans le cloud. Bon networking et profitez bien de vos aventures en lab ! 😄🎊 +VoilĂ  pour l'ensemble de la mise en place : prĂ©requis, topologie VXLAN, dĂ©ploiement du lab avec DevPod sur AWS, et capture de trafic avec EdgeShark et Wireshark. Vous disposez maintenant d'un lab spine-leaf fonctionnel, que vous pouvez dĂ©truire et redĂ©ployer selon vos besoins. diff --git a/content/netlab/netlab.en.md b/content/netlab/netlab.en.md index b0f9067..79be91a 100644 --- a/content/netlab/netlab.en.md +++ b/content/netlab/netlab.en.md @@ -7,7 +7,7 @@ cascade: ## Introduction -📡 In a world where computer networks play an ever-growing role in our daily lives, understanding the principles and logic that drive them is becoming increasingly essential. +Computer networks are everywhere in daily life now, and understanding how they work matters more than it used to. Virtual network labs (also known as "NetLab" or "Virtual Network Lab") are an ideal approach to teaching these concepts, allowing us to simulate complex network environments and experiment risk-free. @@ -15,21 +15,21 @@ I want to share with you how my "NetLabs" work, which will regularly be linked t As part of NetLab, these will mainly be deployed using the ContainerLab tool. For more complex architectures, we'll use GNS3. -## What is ContainerLab? đŸ› ïž +## What is ContainerLab? -ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. With it, you can simulate a multitude of complex network architectures, with equipment such as routers, switches, servers, and other network devices. +ContainerLab is an open-source tool for building complete virtual network labs. With it, you can simulate complex network architectures, with equipment such as routers, switches, servers, and other network devices. This platform offers great flexibility in designing exercises, making it possible to cover various topics such as learning network protocols, security, or device configuration. Users can therefore focus on analyzing and solving problems without worrying about the underlying technical details. Installing ContainerLab won't be covered here, but all the information is available on the official website [here](https://containerlab.dev/install/). -## What is GNS3? đŸ’» +## What is GNS3? GNS3, or Graphical Network Simulator-3, is open-source software mainly used for the **simulation** and **emulation** of computer networks. It allows network engineers, students, and professionals to design, test, and troubleshoot complex networks in a virtual environment before deploying them in the real world. GNS3 is particularly appreciated for its ability to integrate various network hardware and software, such as Cisco routers and switches, as well as virtual machines, to create realistic network topologies. As before, installing GNS3 won't be covered here; for more information, the documentation is available [here](https://docs.gns3.com/docs/). -## GNS3 vs ContainerLab ⚔ +## GNS3 vs ContainerLab GNS3 and ContainerLab are two powerful tools for network simulation and emulation, but they differ in their approach, features, and main use cases. Here's a quick comparison between the two: @@ -37,31 +37,31 @@ GNS3 and ContainerLab are two powerful tools for network simulation and emulatio **Advantages:** -1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build network topologies. -2. **Multivendor Support:** It supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines. -3. **Flexibility:** GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis. -4. **Active Community:** A large community of users and developers provides extensive support and a wealth of online resources. +1. Intuitive graphical interface: GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build network topologies. +2. Multivendor support: it supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines. +3. Flexibility: GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis. +4. Active community: a large community of users and developers provides support and online resources. **Drawbacks:** -1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies. -2. **Configuration Complexity:** Initial setup can be complex, especially for new users. +1. System resources: GNS3 can be resource-intensive, especially when emulating complex devices or large topologies. +2. Configuration complexity: initial setup can be complex, especially for new users. ### ContainerLab **Advantages:** -1. **Lightweight and Performant:** ContainerLab uses containers to emulate network devices, making it lighter and more performant than VM-based solutions. -2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier. -3. **Simplified Configuration:** Topologies are defined via YAML files, making configuration simpler and scriptable. -4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments. +1. Lightweight and performant: ContainerLab uses containers to emulate network devices, making it lighter and faster than VM-based solutions. +2. Automation and DevOps: it integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier. +3. Simplified configuration: topologies are defined via YAML files, making configuration simpler and scriptable. +4. Support for modern technologies: it supports Docker and Kubernetes, offering more flexibility for cloud-native environments. **Drawbacks:** -1. **Less Multivendor Support:** While ContainerLab supports several types of network containers, it may not have the same level of multivendor support as GNS3. -2. **Learning Curve:** For those unfamiliar with containerization concepts, the learning curve can be steeper. +1. Less multivendor support: while ContainerLab supports several types of network containers, it may not match GNS3's level of multivendor support. +2. Learning curve: for those unfamiliar with containerization concepts, the learning curve can be steeper. -## Conclusion 📊 +## Conclusion **GNS3** is ideal for those looking for an intuitive graphical interface and broad device support, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is better suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation. diff --git a/content/netlab/netlab.fr.md b/content/netlab/netlab.fr.md index 2f7221d..6b24481 100644 --- a/content/netlab/netlab.fr.md +++ b/content/netlab/netlab.fr.md @@ -7,7 +7,7 @@ cascade: ## Introduction -📡 Dans un monde oĂč les rĂ©seaux informatiques jouent un rĂŽle croissant dans notre vie quotidienne, la comprĂ©hension des principes et de la logique qui les animent devient de plus en plus essentielle. +Les rĂ©seaux informatiques sont partout dans notre vie quotidienne, et comprendre les principes qui les font fonctionner compte plus qu'avant. Les laboratoires rĂ©seau virtuels (en anglais "NetLab" ou "Virtual Network Lab") constituent une approche idĂ©ale pour enseigner ces concepts, nous permettant de simuler des environnements rĂ©seaux complexes et d'expĂ©rimenter sans risques. @@ -15,21 +15,21 @@ Je souhaite partager avec vous le fonctionnement de mes "NetLabs", qui seront r Dans le cadre des NetLab, ceux-ci seront principalement dĂ©ployĂ©s via l'outil ContainerLab. Pour les architectures plus complexes, nous utiliserons GNS3. -## Qu'est-ce que ContainerLab ? đŸ› ïž +## Qu'est-ce que ContainerLab ? -ContainerLab est un outil open-source puissant qui permet la crĂ©ation de laboratoires rĂ©seau virtuels complets. GrĂące Ă  son utilisation, on peut simuler une multitude d'architectures rĂ©seaux complexes, avec des Ă©quipements tels que les routeurs, commutateurs, serveurs et autres appareils rĂ©seau. +ContainerLab est un outil open-source qui permet de crĂ©er des laboratoires rĂ©seau virtuels complets. On peut simuler des architectures rĂ©seaux complexes, avec des Ă©quipements tels que les routeurs, commutateurs, serveurs et autres appareils rĂ©seau. Cette plateforme offre une grande flexibilitĂ© dans la conception des exercices, permettant l'abordage de diffĂ©rents sujets tels que l'apprentissage de protocoles rĂ©seau, de sĂ©curitĂ© ou encore de configurations d'Ă©quipements. Les utilisateurs peuvent ainsi se concentrer sur l'analyse et la rĂ©solution de problĂšmes sans s'inquiĂ©ter des dĂ©tails techniques sous-jacents. L'installation de ContainerLab ne sera pas prĂ©sentĂ©e ici, mais toutes les informations sont prĂ©sentes sur le site officiel [ici](https://containerlab.dev/install/). -## Qu'est-ce que GNS3 ? đŸ’» +## Qu'est-ce que GNS3 ? GNS3, ou Graphical Network Simulator-3, est un logiciel open-source utilisĂ© principalement pour la **simulation** et l'**Ă©mulation** de rĂ©seaux informatiques. Il permet aux ingĂ©nieurs rĂ©seaux, aux Ă©tudiants et aux professionnels de concevoir, tester et dĂ©panner des rĂ©seaux complexes dans un environnement virtuel avant de les dĂ©ployer dans le monde rĂ©el. GNS3 est particuliĂšrement apprĂ©ciĂ© pour sa capacitĂ© Ă  intĂ©grer divers matĂ©riels et logiciels rĂ©seau, tels que les routeurs et commutateurs Cisco, ainsi que des machines virtuelles pour crĂ©er des topologies rĂ©seau rĂ©alistes. Comme prĂ©cĂ©demment, l'installation de GNS3 ne sera pas Ă©voquĂ©e, pour plus d'information, la documentation est prĂ©sente [ici](https://docs.gns3.com/docs/). -## GNS3 vs ContainerLab ⚔ +## GNS3 vs ContainerLab GNS3 et ContainerLab sont deux outils puissants pour la simulation et l'Ă©mulation de rĂ©seaux, mais ils diffĂšrent dans leur approche, leurs fonctionnalitĂ©s et leurs cas d'utilisation principaux. Voici un rapide comparatif entre les deux : @@ -37,31 +37,31 @@ GNS3 et ContainerLab sont deux outils puissants pour la simulation et l'Ă©mulati **Avantages :** -1. **Interface Graphique Intuitive :** GNS3 offre une interface graphique conviviale permet aux utilisateurs de glisser-dĂ©poser des composants pour crĂ©er des topologies rĂ©seau. -2. **Support Multivendor :** Il supporte une large gamme de matĂ©riels et logiciels rĂ©seau, y compris les routeurs et commutateurs Cisco, ainsi que des machines virtuelles. -3. **FlexibilitĂ© :** GNS3 peut ĂȘtre utilisĂ© sur Windows, macOS et Linux, et il intĂšgre bien d'autres outils comme Wireshark pour l'analyse de trafic. -4. **CommunautĂ© Active :** Une grande communautĂ© d'utilisateurs et de dĂ©veloppeurs offre un vaste support et une multitude de ressources en ligne. +1. Interface graphique intuitive : GNS3 offre une interface graphique conviviale qui permet aux utilisateurs de glisser-dĂ©poser des composants pour crĂ©er des topologies rĂ©seau. +2. Support multivendor : il supporte une large gamme de matĂ©riels et logiciels rĂ©seau, y compris les routeurs et commutateurs Cisco, ainsi que des machines virtuelles. +3. FlexibilitĂ© : GNS3 peut ĂȘtre utilisĂ© sur Windows, macOS et Linux, et il s'intĂšgre bien avec d'autres outils comme Wireshark pour l'analyse de trafic. +4. CommunautĂ© active : une grande communautĂ© d'utilisateurs et de dĂ©veloppeurs offre du support et des ressources en ligne. **InconvĂ©nients :** -1. **Ressources SystĂšmes :** GNS3 peut ĂȘtre gourmand en ressources, surtout lorsqu'il Ă©mule des dispositifs complexes ou de grandes topologies. -2. **ComplexitĂ© de Configuration :** La configuration initiale peut ĂȘtre complexe, surtout pour les nouveaux utilisateurs. +1. Ressources systĂšmes : GNS3 peut ĂȘtre gourmand en ressources, surtout lorsqu'il Ă©mule des dispositifs complexes ou de grandes topologies. +2. ComplexitĂ© de configuration : la configuration initiale peut ĂȘtre complexe, surtout pour les nouveaux utilisateurs. ### ContainerLab **Avantages :** -1. **LĂ©gĂšretĂ© et Performance :** ContainerLab utilise des conteneurs pour Ă©muler les dispositifs rĂ©seau, ce qui le rend plus lĂ©ger et performant que les solutions basĂ©es sur des machines virtuelles. -2. **Automatisation et DevOps :** Il s'intĂšgre bien avec les outils DevOps et d'automatisation comme Ansible, facilitant ainsi le dĂ©ploiement automatisĂ© et la gestion de rĂ©seaux. -3. **Configuration SimplifiĂ©e :** Les topologies sont dĂ©finies via des fichiers YAML, rendant la configuration plus simple et scriptable. -4. **Support de Technologies Modernes :** Il supporte des technologies modernes comme Docker et Kubernetes, offrant ainsi une plus grande flexibilitĂ© pour les environnements cloud-native. +1. LĂ©gĂšretĂ© et performance : ContainerLab utilise des conteneurs pour Ă©muler les dispositifs rĂ©seau, ce qui le rend plus lĂ©ger et plus rapide que les solutions basĂ©es sur des machines virtuelles. +2. Automatisation et DevOps : il s'intĂšgre bien avec les outils DevOps et d'automatisation comme Ansible, ce qui facilite le dĂ©ploiement automatisĂ© et la gestion de rĂ©seaux. +3. Configuration simplifiĂ©e : les topologies sont dĂ©finies via des fichiers YAML, ce qui rend la configuration plus simple et scriptable. +4. Support de technologies modernes : il supporte Docker et Kubernetes, offrant plus de flexibilitĂ© pour les environnements cloud-native. **InconvĂ©nients :** -1. **Moins de Support Multivendor :** Bien que ContainerLab supporte plusieurs types de conteneurs rĂ©seau, il peut ne pas avoir le mĂȘme niveau de support multivendor que GNS3. -2. **Courbe d'Apprentissage :** Pour ceux qui ne sont pas familiers avec les concepts de conteneurisation, la courbe d'apprentissage peut ĂȘtre plus raide. +1. Moins de support multivendor : bien que ContainerLab supporte plusieurs types de conteneurs rĂ©seau, il n'a pas toujours le mĂȘme niveau de support multivendor que GNS3. +2. Courbe d'apprentissage : pour ceux qui ne sont pas familiers avec les concepts de conteneurisation, la courbe d'apprentissage peut ĂȘtre plus raide. -## Conclusion 📊 +## Conclusion **GNS3** est idĂ©al pour ceux qui recherchent une interface graphique intuitive et un large support de dispositifs rĂ©seau, particuliĂšrement utile pour les Ă©tudiants et les ingĂ©nieurs rĂ©seau traditionnels. **ContainerLab**, en revanche, est plus adaptĂ© aux environnements modernes et aux pratiques DevOps, offrant une solution lĂ©gĂšre et scriptable pour la simulation de rĂ©seaux. diff --git a/content/netlab/sĂ©curitĂ©/stepca.en.md b/content/netlab/sĂ©curitĂ©/stepca.en.md index 7f98cf0..7341d17 100644 --- a/content/netlab/sĂ©curitĂ©/stepca.en.md +++ b/content/netlab/sĂ©curitĂ©/stepca.en.md @@ -6,45 +6,38 @@ cascade: type: docs --- -## 🔗 Sources +## Sources -- [📖 Official Documentation](https://smallstep.com/docs/tutorials/) -- [đŸ› ïž Step-CA as a systemd Service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/) -- [🔐 Certificate Management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/) +- [Official documentation](https://smallstep.com/docs/tutorials/) +- [Step-CA as a systemd service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/) +- [Certificate management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/) -## đŸ€– About Step-CA +## About Step-CA -Step-CA is a clever toolset developed by Smallstep, a company specializing in secure identity management and certificate automation. 🚀 -Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security! +Step-CA is a toolset developed by Smallstep, a company specializing in secure identity management and certificate automation. +Its mission is to simplify setting up and managing your own certificate authorities (CAs). -### Key Features +### Key features -1. **Certificate Authority Management** 🔑 - Easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro. +1. Certificate authority management: easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations. -2. **Secure Key Management** đŸ›Ąïž - Follows best practices for securely storing and managing keys, ensuring your cryptographic keys stay protected from unauthorized access. +2. Secure key management: follows best practices for securely storing and managing keys, so your cryptographic keys stay protected from unauthorized access. -3. **Automation and Scalability** ⚙ - Ideal for small to large-scale deployments. Take advantage of APIs and integrations that automate certificate issuance, renewal, and revocation for a smooth lifecycle. +3. Automation and scalability: works for small to large-scale deployments. APIs and integrations automate certificate issuance, renewal, and revocation across the lifecycle. -4. **Enhanced Security** 🔒 - Through the use of modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, providing robust encryption and digital signatures. +4. Modern cryptography: Step-CA supports industry-standard X.509 certificates using modern cryptographic algorithms and protocols for encryption and digital signatures. -5. **Infrastructure Integration** 🌐 - Integrates seamlessly with your existing tools and systems. Supports various authentication methods such as username/password, MFA, and external identity providers. +5. Infrastructure integration: integrates with your existing tools and systems, and supports various authentication methods such as username/password, MFA, and external identity providers. -6. **Auditability and Compliance** 📜 - With comprehensive logging and auditing capabilities, you can track certificate activity and meet compliance requirements with ease. +6. Auditability and compliance: comprehensive logging and auditing let you track certificate activity and meet compliance requirements. -7. **Developer-Friendly APIs** đŸ‘©â€đŸ’»đŸ‘šâ€đŸ’» - APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows. +7. Developer-friendly APIs: APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows. -**In short:** Step-CA by Smallstep is designed to make certificate authority management both fun and hassle-free. Thanks to its secure, scalable, and user-friendly features, you can easily manage your certificates' lifecycle while protecting your infrastructure! +Step-CA by Smallstep is built to make certificate authority management straightforward: you manage your certificates' lifecycle while keeping your infrastructure protected. -## 🚀 Installation +## Installation -### 🔧 Binary Installation +### Binary installation #### 1. Step CLI @@ -60,7 +53,7 @@ wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_ sudo dpkg -i step-ca_0.24.1_amd64.deb ``` -#### 3. Creating a Dedicated User +#### 3. Creating a dedicated user ```bash adduser adminCA @@ -81,8 +74,8 @@ What would you like to name the CA's first provisioner? Choose a password for your CA keys and the first provisioner. ✔ [leave empty and we will generate one] : -Generating root certificate... done! 🎉 -Generating intermediate certificate... done! 🎊 +Generating root certificate... done! +Generating intermediate certificate... done! ✔ Root certificate: /home/adminCA/.step/certs/root_ca.crt ✔ Root private key: /home/adminCA/.step/secrets/root_ca_key @@ -95,7 +88,7 @@ Generating intermediate certificate... done! 🎊 Your PKI is ready to go. To generate certificates for individual services, see `step help ca`. -💌 **FEEDBACK** +**Feedback:** The step utility is not instrumented for usage statistics. It does not contact a central server. Your feedback is, however, extremely valuable! Please consider writing to feedback@smallstep.com, joining GitHub Discussions, or joining us on Discord at [https://u.step.sm/discord](https://u.step.sm/discord). ``` @@ -111,10 +104,10 @@ step-ca .step/config/ca.json $ step ca provisioner add acme --type ACME ✔ CA Configuration: /home/adminCA/.step/config/ca.json -Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 ) or restart the step-ca process. 🎉 +Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 ) or restart the step-ca process. ``` -#### Running Step-CA as a systemd Service +#### Running Step-CA as a systemd service Create a file: @@ -155,7 +148,7 @@ systemctl daemon-reload systemctl start step-ca.service ``` -### 🐳 Docker Installation +### Docker installation ```bash docker run -it -v step:/home/step \ @@ -167,11 +160,11 @@ docker run -it -v step:/home/step \ smallstep/step-ca ``` -## 🔑 Accessing the CA from Another Client +## Accessing the CA from another client -> [!NOTE] Adjust the port based on your installation: +> [!NOTE] Adjust the port based on your installation: > -> - **Binary:** port **443** +> - **Binary:** port **443** > - **Docker:** port **9000** Install the Step CLI: @@ -226,7 +219,7 @@ step certificate install $(step path)/certs/root_ca.crt --- -### 📝 Obtaining a Certificate +### Obtaining a certificate ```bash admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key diff --git a/content/netlab/sĂ©curitĂ©/stepca.fr.md b/content/netlab/sĂ©curitĂ©/stepca.fr.md index ca06c22..fd8798b 100644 --- a/content/netlab/sĂ©curitĂ©/stepca.fr.md +++ b/content/netlab/sĂ©curitĂ©/stepca.fr.md @@ -6,45 +6,38 @@ cascade: type: docs --- -## 🔗 Sources +## Sources -- [📖 Documentation Officielle](https://smallstep.com/docs/tutorials/) -- [đŸ› ïž Step-CA en tant que Service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/) -- [🔐 Gestion des Certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/) +- [Documentation officielle](https://smallstep.com/docs/tutorials/) +- [Step-CA en tant que service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/) +- [Gestion des certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/) -## đŸ€– À propos de Step-CA +## À propos de Step-CA -Step-CA est un ensemble d'outils astucieux dĂ©veloppĂ© par Smallstep, une entreprise spĂ©cialisĂ©e dans la gestion sĂ©curisĂ©e des identitĂ©s et l'automatisation des certificats. 🚀 -Sa mission ? Simplifier la mise en place et la gestion de vos propres autoritĂ©s de certification (AC) avec facilitĂ© et sĂ©curitĂ© ! +Step-CA est un ensemble d'outils dĂ©veloppĂ© par Smallstep, une entreprise spĂ©cialisĂ©e dans la gestion sĂ©curisĂ©e des identitĂ©s et l'automatisation des certificats. +Sa mission est de simplifier la mise en place et la gestion de vos propres autoritĂ©s de certification (AC). ### Principales fonctionnalitĂ©s -1. **Gestion des AutoritĂ©s de Certification** 🔑 - Configurez et gĂ©rez facilement vos propres AC. CrĂ©ez des AC racines et intermĂ©diaires, dĂ©livrez des certificats et gĂ©rez les rĂ©vocations comme un pro. +1. Gestion des autoritĂ©s de certification : configurez et gĂ©rez facilement vos propres AC. CrĂ©ez des AC racines et intermĂ©diaires, dĂ©livrez des certificats et gĂ©rez les rĂ©vocations. -2. **Gestion SĂ©curisĂ©e des ClĂ©s** đŸ›Ąïž - Respecte les bonnes pratiques pour le stockage et la gestion sĂ©curisĂ©s des clĂ©s, garantissant que vos clĂ©s cryptographiques restent protĂ©gĂ©es contre les accĂšs non autorisĂ©s. +2. Gestion sĂ©curisĂ©e des clĂ©s : respecte les bonnes pratiques pour le stockage et la gestion des clĂ©s, afin que vos clĂ©s cryptographiques restent protĂ©gĂ©es contre les accĂšs non autorisĂ©s. -3. **Automatisation et ScalabilitĂ©** ⚙ - IdĂ©al pour les dĂ©ploiements de petite Ă  grande envergure. Profitez des API et intĂ©grations qui automatisent la dĂ©livrance, le renouvellement et la rĂ©vocation des certificats pour un cycle de vie sans accrocs. +3. Automatisation et scalabilitĂ© : adaptĂ© aux dĂ©ploiements de petite Ă  grande envergure. Les API et intĂ©grations automatisent la dĂ©livrance, le renouvellement et la rĂ©vocation des certificats tout au long du cycle de vie. -4. **SĂ©curitĂ© RenforcĂ©e** 🔒 - GrĂące Ă  l'utilisation d'algorithmes et de protocoles cryptographiques modernes, Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, offrant un chiffrement robuste et des signatures numĂ©riques. +4. Cryptographie moderne : Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, avec des algorithmes et protocoles cryptographiques modernes pour le chiffrement et les signatures numĂ©riques. -5. **IntĂ©gration avec l'Infrastructure** 🌐 - S'intĂšgre parfaitement avec vos outils et systĂšmes existants. Prend en charge diverses mĂ©thodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identitĂ© externes. +5. IntĂ©gration avec l'infrastructure : s'intĂšgre avec vos outils et systĂšmes existants, et prend en charge diverses mĂ©thodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identitĂ© externes. -6. **AuditabilitĂ© et ConformitĂ©** 📜 - Avec des capacitĂ©s complĂštes de journalisation et d'audit, vous pouvez suivre les activitĂ©s des certificats et satisfaire aux exigences de conformitĂ© en toute simplicitĂ©. +6. AuditabilitĂ© et conformitĂ© : la journalisation et l'audit complets permettent de suivre les activitĂ©s des certificats et de rĂ©pondre aux exigences de conformitĂ©. -7. **API Conviviales pour les DĂ©veloppeurs** đŸ‘©â€đŸ’»đŸ‘šâ€đŸ’» - Des API et SDK conçus pour les dĂ©veloppeurs facilitent l'intĂ©gration de la gestion des certificats dans vos applications et flux de travail personnalisĂ©s. +7. API conviviales pour les dĂ©veloppeurs : des API et SDK conçus pour les dĂ©veloppeurs facilitent l'intĂ©gration de la gestion des certificats dans vos applications et flux de travail personnalisĂ©s. -**En rĂ©sumĂ© :** Step-CA de Smallstep est conçu pour rendre la gestion des autoritĂ©s de certification Ă  la fois ludique et sans tracas. GrĂące Ă  ses fonctionnalitĂ©s sĂ©curisĂ©es, scalables et conviviales, vous pouvez gĂ©rer facilement le cycle de vie de vos certificats tout en protĂ©geant votre infrastructure ! +Step-CA de Smallstep est conçu pour rendre la gestion des autoritĂ©s de certification simple : vous gĂ©rez le cycle de vie de vos certificats tout en protĂ©geant votre infrastructure. -## 🚀 Installation +## Installation -### 🔧 Installation Binaire +### Installation binaire #### 1. Step CLI @@ -60,7 +53,7 @@ wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_ sudo dpkg -i step-ca_0.24.1_amd64.deb ``` -#### 3. CrĂ©ation d'un Utilisateur SpĂ©cifique +#### 3. CrĂ©ation d'un utilisateur dĂ©diĂ© ```bash adduser adminCA @@ -81,8 +74,8 @@ Quel nom souhaitez-vous donner au premier provisionneur de l'AC ? Choisissez un mot de passe pour vos clĂ©s AC et le premier provisionneur. ✔ [laissez vide et nous en gĂ©nĂ©rerons un] : -GĂ©nĂ©ration du certificat racine... fait ! 🎉 -GĂ©nĂ©ration du certificat intermĂ©diaire... fait ! 🎊 +GĂ©nĂ©ration du certificat racine... fait ! +GĂ©nĂ©ration du certificat intermĂ©diaire... fait ! ✔ Certificat racine : /home/adminCA/.step/certs/root_ca.crt ✔ ClĂ© privĂ©e racine : /home/adminCA/.step/secrets/root_ca_key @@ -95,7 +88,7 @@ GĂ©nĂ©ration du certificat intermĂ©diaire... fait ! 🎊 Votre PKI est prĂȘte ! Pour gĂ©nĂ©rer des certificats pour des services individuels, consultez `step help ca`. -💌 **RETROACTION** +**Retours :** L'utilitaire step n'est pas instrumentĂ© pour les statistiques d'utilisation. Il ne contacte pas un serveur central. Toutefois, vos retours sont trĂšs prĂ©cieux ! N'hĂ©sitez pas Ă  nous Ă©crire Ă  feedback@smallstep.com, rejoindre les Discussions GitHub ou nous rejoindre sur Discord Ă  [https://u.step.sm/discord](https://u.step.sm/discord). ``` @@ -111,10 +104,10 @@ step-ca .step/config/ca.json $ step ca provisioner add acme --type ACME ✔ Configuration de l'AC : /home/adminCA/.step/config/ca.json -SuccĂšs ! La configuration de votre `step-ca` a Ă©tĂ© mise Ă  jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 ) ou redĂ©marrez le processus step-ca. 🎉 +SuccĂšs ! La configuration de votre `step-ca` a Ă©tĂ© mise Ă  jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 ) ou redĂ©marrez le processus step-ca. ``` -#### ExĂ©cuter Step-CA en tant que Service systemd +#### ExĂ©cuter Step-CA en tant que service systemd CrĂ©ez un fichier : @@ -155,7 +148,7 @@ systemctl daemon-reload systemctl start step-ca.service ``` -### 🐳 Installation avec Docker +### Installation avec Docker ```bash docker run -it -v step:/home/step \ @@ -167,11 +160,11 @@ docker run -it -v step:/home/step \ smallstep/step-ca ``` -## 🔑 AccĂšs Ă  l'AC avec un Autre Client +## AccĂšs Ă  l'AC avec un autre client -> [!NOTE] Adaptez le port en fonction de votre installation : +> [!NOTE] Adaptez le port en fonction de votre installation : > -> - **Binaire :** port **443** +> - **Binaire :** port **443** > - **Docker :** port **9000** Installez le Step CLI : @@ -226,7 +219,7 @@ step certificate install $(step path)/certs/root_ca.crt --- -### 📝 Obtenir un Certificat +### Obtenir un certificat ```bash admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key