diff --git a/content/_index.fr.md b/content/_index.fr.md index d50472e..330d052 100644 --- a/content/_index.fr.md +++ b/content/_index.fr.md @@ -9,7 +9,7 @@ layout: hextra-home
{{< hextra/hero-headline >}} - Bloc Note Personnel + BlocNote Personnel pour les NetDevOps et SRE {{< /hextra/hero-headline >}}
@@ -43,3 +43,10 @@ layout: hextra-home style="background: radial-gradient(ellipse at 50% 80%,rgba(203, 28, 66, 0.1),hsla(0,0%,100%,0));" >}} {{< /hextra/feature-grid >}} + +
+

+ Technologies utilisés +

+ Technologies utilisées +
diff --git a/content/_index.md b/content/_index.md deleted file mode 100644 index a97f877..0000000 --- a/content/_index.md +++ /dev/null @@ -1,45 +0,0 @@ ---- - -title: Damien's NoteBook -layout: hextra-home - ---- - - - -
-{{< hextra/hero-headline >}} - Personal Notebook - for NetDevOps and SRE -{{< /hextra/hero-headline >}} -
- -
-{{< hextra/hero-subtitle style="margin:.3rem 0 2rem 0">}} - Documentation and NetLab to Deploy, - Tests and Practice 🚀 -{{< /hextra/hero-subtitle >}} -
- -
- -{{< hextra/feature-grid >}} - {{< hextra/feature-card - title="Documentations" - subtitle="List of documentation and explanation about Network or System concept" - link="documentation" - class="hx-aspect-auto md:hx-aspect-[1.1/1] max-md:hx-min-h-[340px]" - image="/images/documentation.png" - imageClass="hx-top-[40%] hx-left-[24px] hx-w-[180%] sm:hx-w-[110%] dark:hx-opacity-80" - style="background: radial-gradient(ellipse at 50% 80%,rgba(58, 56, 113, 0.1),hsla(0,0%,100%,0));" - >}} - {{< hextra/feature-card - title="NetLab" - subtitle="Labs to practice" - link="netlab" - class="hx-aspect-auto md:hx-aspect-[1.1/1] max-lg:hx-min-h-[340px]" - image="/images/netlab.png" - imageClass="hx-top-[40%] hx-left-[36px] hx-w-[180%] sm:hx-w-[110%] dark:hx-opacity-80" - style="background: radial-gradient(ellipse at 50% 80%,rgba(203, 28, 66, 0.1),hsla(0,0%,100%,0));" - >}} -{{< /hextra/feature-grid >}} diff --git a/content/about/index.fr.md b/content/about/index.fr.md index 10e3d40..a8c3d4c 100644 --- a/content/about/index.fr.md +++ b/content/about/index.fr.md @@ -1,31 +1,29 @@ ---- -title: A Propos -toc: false ---- -## Travail et missions d'un NetDevOps 🖥️🛠️📡 +# À propos de moi -Le métier de NetDevOps est relativement nouveau dans l'industrie informatique. Il combine les compétences des développeurs et des opérations réseau pour fournir une infrastructure réseau agile et robuste, et améliorer la qualité de l'expérience utilisateur. Dans cet article, nous allons explorer les missions et les compétences d'un NetDevOps. +🚀 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**. -NetDevOps, ou Network Development Operations, est un concept basé sur l'intégration de la culture DevOps dans la gestion et la maintenance des réseaux informatiques. Il s'agit d'appliquer les pratiques DevOps à la gestion des réseaux, telles que l'automatisation, la collaboration et l'amélioration continue. +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 ! 💡🤖 -## Missions 🎯 +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 !** 🌱✨ -Les missions d'un NetDevOps sont multiples et variées. En voici quelques-unes : +## Parcours professionnel -1. Développement et déploiement d'infrastructures réseau 🏗️ : Le NetDevOps développe des infrastructures réseau évolutives et flexibles. Il travaille en étroite collaboration avec les équipes de développement et d'opérations pour mettre en œuvre des solutions répondant aux besoins de l'entreprise. Le NetDevOps est également responsable de la configuration et du déploiement des équipements réseau. -2. Automatisation des tâches réseau 🤖 : L'automatisation est un élément clé du travail de NetDevOps. Il utilise des outils d'automatisation pour simplifier et accélérer les tâches répétitives telles que la configuration, la mise à jour, la surveillance et la maintenance du réseau. -3. Gestion de la sécurité réseau 🔒 : La sécurité est une préoccupation majeure pour les entreprises. Le NetDevOps travaille en collaboration avec les équipes de sécurité pour mettre en œuvre des solutions protégeant le réseau contre les cyberattaques. Il établit également des protocoles de sécurité pour garantir la confidentialité et l'intégrité des données. -4. Surveillance des performances réseau 🕵️ : Le NetDevOps surveille en continu les performances du réseau pour identifier d'éventuels problèmes et prendre les mesures nécessaires pour les résoudre. Il analyse les données de performance pour optimiser les performances du réseau. +🧑‍💻 **Spécialiste de l'automatisation réseau @ Airbus** -## Compétences 🤹 +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 ! 🌐✈️ -Les compétences d'un NetDevOps sont variées et comprennent : +🔧 **Plus de 6 ans chez Nokia** -1. Connaissance approfondie des technologies réseau 📚 : Le NetDevOps doit avoir une connaissance approfondie des technologies réseau telles que les protocoles de routage, les VLAN, les VPN, les pare-feu, etc. -2. Compétences en développement 🧑‍💻 : Le NetDevOps doit avoir des compétences en développement pour créer des scripts et automatiser les tâches réseau. -3. Compétences en gestion de projet 📅 : Le NetDevOps doit avoir des compétences en gestion de projet pour gérer les projets de développement et de déploiement d'infrastructures réseau. -4. Compétences en communication 🗣️ : Le NetDevOps doit avoir de bonnes compétences en communication pour collaborer avec les équipes de développement et d'opérations, ainsi qu'avec les parties prenantes de l'entreprise. +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**. -## Conclusion 📝 +🧠 **Mes débuts réseaux chez Orange & au-delà** -En conclusion, le métier de NetDevOps est essentiel pour fournir une infrastructure réseau agile et robuste répondant aux besoins de l'entreprise. Le NetDevOps doit avoir une connaissance approfondie des technologies réseau, des compétences en développement, des compétences en gestion de projet et des compétences en communication pour réussir dans ce domaine. 🌟 +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. + +💡 **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**. + +📚 **Apprenant à vie & promoteur de l’esprit d’é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** 🌱. diff --git a/content/about/index.md b/content/about/index.md deleted file mode 100644 index cde5b09..0000000 --- a/content/about/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: About -toc: false ---- - -## Job and Missions of a NetDevOps 🖥️🛠️📡 - -NetDevOps is a relatively new job in the IT industry. It combines the skills of developers and network operations to provide agile and robust network infrastructure, and improve the quality of the user experience. In this article, we will explore the missions and skills of a NetDevOps. - -NetDevOps, or Network Development Operations, is a concept that is based on the integration of the DevOps culture into the management and maintenance of computer networks. It involves applying DevOps practices to network management, such as automation, collaboration, and continuous improvement. - -## Missions 🎯 - -The missions of a NetDevOps are multiple and varied. Here are some of them: - -1. Development and deployment of network infrastructures 🏗️: The NetDevOps develops scalable and flexible network infrastructures. They work closely with development and operations teams to implement solutions that meet the needs of the business. The NetDevOps is also responsible for configuring and deploying network equipment. -2. Automation of network tasks 🤖: Automation is a key element of the NetDevOps job. They use automation tools to simplify and speed up repetitive tasks such as configuration, updating, monitoring, and maintenance of the network. -3. Network security management 🔒: Security is a major concern for businesses. NetDevOps works collaboratively with security teams to implement solutions that protect the network from cyberattacks. They also establish security protocols to ensure the confidentiality and integrity of data. -4. Monitor network performance 🕵️: The NetDevOps continuously monitors network performance to identify any potential issues and take necessary actions to resolve them. They analyze performance data to optimize network performance. - -## Skills 🤹 - -The skills of a NetDevOps are varied and include: - -1. In-depth knowledge of network technologies 📚: The NetDevOps must have an in-depth knowledge of network technologies such as routing protocols, VLANs, VPNs, firewalls, etc. -2. Development skills 🧑‍💻: The NetDevOps must have development skills to create scripts and automate network tasks. -3. Project management skills 📅: The NetDevOps must have project management skills to manage network infrastructure development and deployment projects. -4. Communication skills 🗣️: The NetDevOps must have good communication skills to collaborate with development and operations teams, as well as stakeholders in the business. - -## Conclusion 📝 - -In conclusion, the NetDevOps job is essential to providing an agile and robust network infrastructure that meets the needs of the business. NetDevOps must have an in-depth knowledge of network technologies, development skills, project management skills, and communication skills to succeed in this field. 🌟 diff --git a/content/documentation/VXLAN/Beginners/media_layers.png b/content/documentation/VXLAN/Beginners/media_layers.png deleted file mode 100644 index 472eb66..0000000 Binary files a/content/documentation/VXLAN/Beginners/media_layers.png and /dev/null differ diff --git a/content/documentation/VXLAN/Beginners/transports.png b/content/documentation/VXLAN/Beginners/transports.png deleted file mode 100644 index d9bbf14..0000000 Binary files a/content/documentation/VXLAN/Beginners/transports.png and /dev/null differ diff --git a/content/documentation/VXLAN/Beginners/vxlan-for-beginners.md b/content/documentation/VXLAN/Beginners/vxlan-for-beginners.md deleted file mode 100644 index c193bff..0000000 --- a/content/documentation/VXLAN/Beginners/vxlan-for-beginners.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -title: "VXLAN for Beginners" -date: 2024-08-01T20:00:00+02:00 -cascade: - type: docs ---- - -## Understanding VLAN and VXLAN: Simplified for Non-Technicians - -In the fast-paced world of technology, understanding networking concepts can be intimidating, especially if you’re not an expert in the field. - -Today, we’ll break down two important network concepts: **VLAN** and **VXLAN**, using simple analogies and clear explanations. - -We’ll also cover their limitations, real-world use cases, and some technical points for the more curious readers. - -Let’s go! 🚀 - -## What is a VLAN? 🏢 - -**VLAN (Virtual Local Area Network)** is like organizing a large office building with multiple departments: Marketing, Sales, HR, and IT. To keep things orderly, each department gets its own floor. This way, Marketing stays on its floor, Sales stays 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 ✅ - -- **Segregation:** Keeps different groups (like departments) separate. -- **Efficiency:** Reduces unnecessary traffic and potential network issues. -- **Security:** Limits access and enhances security by isolating groups. - -### VLAN Limitations ⚠️ - -- **ID Limit:** Historically, a VLAN is identified by a 12-bit field, allowing up to 4094 VLANs (1 to 4094). For a large company or a datacenter, this might be insufficient. -- **Local Isolation:** VLANs are primarily designed for local use (on the same site or a connected set of switches). Extending this concept to multiple sites requires more advanced solutions. - -## What is VXLAN? 🌆 - -**VXLAN (Virtual Extensible LAN)** goes further. Imagine your company grows and expands to multiple office buildings across the city. You still want each department to feel as if it’s on its own floor, even though they’re now spread out across different locations. To do this, you create a virtual system that connects all floors across 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 this for networks. It extends VLANs across multiple physical locations using a technique called **tunneling**. This allows devices in the same VLAN to communicate as if they were on the same local network, even if they’re geographically distant. - -### Key points about VXLAN ⭐ - -- **Scalability:** Extends networks to different locations and surpasses the 4094 VLAN limit. -- **Flexibility:** Enables larger, more dynamic network designs. -- **Connectivity:** Ensures seamless communication across dispersed networks. - -## Technical Dive into VXLAN 🔍 - -**VXLAN** was developed to address the limitations of traditional VLANs (scalability, geographic reach). It uses a **VNI** (VXLAN Network Identifier) with 24 bits to identify up to **16 million** logical segments, far exceeding the 4094 VLAN limit. - -Due to 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, allowing Ethernet frames (Layer 2) to be transported over an IP network (Layer 3). - -### How does it work? 🤔 - -The goal of **VXLAN** is to **extend Layer 2** across a Layer 3 (IP) network. Essentially, it “tricks” Layer 3 into believing that the user or virtual machine is still on the same local (Layer 2) network. - -> **In simple terms:** Ethernet frames (Layer 2) are encapsulated inside a UDP packet (Layer 4), which is then carried by IP (Layer 3). - -![OSI Layers](media_layers.png#center) - -> [!NOTE] **The “Physical” Layers** -> -> - The **Link Layer (Layer 2)** is typically managed by switches. -> - The **Network Layer (Layer 3)** is typically managed by routers. - -By encapsulating Layer 2 inside Layer 3, you benefit from the advantages of IP routing (flexibility, scalability) while preserving the isolation and simplicity of Layer 2 for applications and virtual machines. - -### VXLAN Explained by the Container Transport Analogy 🚚 🚂 - -#### 1. Trucks (lower layers) - -Imagine trucks on the road. Their job is to transport containers (your data) from Point A to Point B. These trucks represent the **Ethernet layer** (Layer 2), where each vehicle (frame) has a “license plate” (MAC address). - -#### 2. The Train (VXLAN tunnel) - -When it’s time to travel longer distances or through different infrastructures, loading the trucks onto a train becomes more efficient. Here, **the train represents VXLAN**: it encapsulates the trucks (Ethernet frames) into a wagon (the tunnel). Each train is identified by a **VNI (VXLAN Network Identifier)**, much like a convoy number for each freight line. - -#### 3. The Railway Tracks (IP network) - -The train runs on rails (the **IP network**, Layer 3). The railroad is already built and managed to find the best path; it ensures route convergence and can reroute traffic in case of issues (breakdowns, congestion, etc.). Similarly, the IP network automatically selects the optimal path to transport VXLAN packets. - -### Key Takeaways - -- **Overlay:** VXLAN is a transport system “on top of” Layer 3 (the rails). It interconnects multiple Layer 2 networks (the trucks) as if they were just one. -- **Dual Addressing:** - - Trucks (Ethernet frames) are identified by **MAC addresses** (license plates). - - The train (VXLAN tunnel) uses **IP addresses** (routing plans) to travel on the rails. -- **Isolation and Segmentation:** Just like multiple trains can run on the same railway line, you can have several VXLAN tunnels (each with its own VNI) over the same IP infrastructure. -- **Elasticity and Reliability:** By relying on Layer 3, VXLAN takes advantage of all IP routing optimizations (route recalculations, fault tolerance, etc.). - -![Container transport](transports.png#center) - -## Real-World Use Cases 🏭 - -- **Multi-datacenter:** For connecting multiple geographically dispersed data centers while preserving the feel of a single Layer 2 network. -- **Hybrid Cloud:** Extending a corporate network to a public or private cloud provider without reconfiguring the entire address plan. -- **Virtual Machine Migration:** Enabling VM mobility between distant sites without losing Layer 2 connectivity. -- **Massive Virtualization:** In highly dense environments (e.g., hundreds of thousands of virtual machines), the 24-bit VNI is indispensable. - -## VXLAN Control: BGP EVPN and Other Protocols 🤝 - -In modern deployments, especially in data centers, VXLAN isn’t just configured statically. It’s often paired with a **control plane** via **BGP EVPN (Ethernet VPN)**. - -- **BGP EVPN:** Exchanges MAC and IP table information between devices, facilitating automation and scalability. -- **Other Technologies:** Historically, other overlay protocols (NVGRE, STT) existed, but VXLAN has become the de facto standard. - -## Performance Considerations ⚙️ - -- **Encapsulation Overhead:** VXLAN adds an extra header (8 bytes + UDP/IP header). This can affect the **Maximum Transmission Unit (MTU)** size, often requiring **Jumbo MTU** (usually 9000 bytes) to avoid packet fragmentation. -- **Resilience of the IP Network:** The tunnel’s reliability depends on the underlying IP network’s quality (routes, congestion, etc.). - -## Example Configuration (for the curious) 💡 - -Below is a **simplified excerpt** of a VXLAN configuration on a Cisco NX-OS device (syntax can vary by vendor): - -```plaintext -interface nve1 - no shutdown - source-interface loopback1 - member vni 5001 - ingress-replication protocol static - mcast-group 239.1.1.1 -``` - -- **interface nve1:** Creates an “NVE” (Network Virtualization Endpoint) interface to handle VXLAN encapsulation. -- **source-interface loopback1:** The IP address of loopback1 is used to establish tunnels. -- **member vni 5001:** Associates a specific VXLAN Network Identifier (VNI) with the overlay network. - -*Note:* In more complex environments, the control plane (e.g., BGP EVPN) is also configured. - -## Summary 🎯 - -- **VLAN** - It’s like having separate floors for different departments in a building, keeping their activities isolated. 🏢 - \- **Major limitation:** A maximum of 4094 VLANs and scope often limited to a single site. - -- **VXLAN** - It’s like connecting those separate floors across multiple buildings while maintaining the illusion they’re in one building. 🌆 - \- **Key advantages:** Huge addressing capability (16 million segments), L2 extension over L3, flexibility for virtualization and multi-site. - -**VXLAN** addresses the need for large-scale isolation, overcomes the limitations of switch MAC address tables, and allows for flexible deployment of services. Paired with an efficient control plane (BGP EVPN), it greatly simplifies the management of modern overlay networks. - -### Conclusion 🏁 - -In short, if you need **basic segmentation** for your local network, **VLAN** is more than enough. But as soon as you want to connect multiple sites, build a highly virtualized network, or exceed the traditional 4094 VLAN limit, **VXLAN** becomes essential. - -Whether you’re a **network lab** enthusiast, a NetOps engineer, or simply curious about the underlying infrastructure, understanding these two concepts will help you better grasp the magic that happens when your data travels farther and farther while preserving the illusion of being “at home” on the same local network! - -> [!TIP] **Want to learn more?** -> -> - Check out **BGP EVPN** for VXLAN’s control plane. -> - Look into **Jumbo MTU configuration** to optimize performance. -> - Compare VXLAN with other protocols (NVGRE, GENEVE) to understand network design choices. diff --git a/content/documentation/VXLAN/_index.md b/content/documentation/VXLAN/_index.md deleted file mode 100644 index e69de29..0000000 diff --git a/content/documentation/_index.md b/content/documentation/_index.md deleted file mode 100644 index bb87841..0000000 --- a/content/documentation/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Documentation -cascade: - type: docs ---- - - - -{{< hextra/hero-subtitle >}} - Comprehensive Documentation and Step-by-Step "How-To" Guides -{{< /hextra/hero-subtitle >}} - -{{< cards >}} - {{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="How to install ContainerLab" icon="endpoints" >}} - {{< card link="https://devpod.sh" title="DevPod" subtitle="Easy way to deploy Lab" icon="git" >}} -{{< /cards >}} diff --git a/content/documentation/devpod/_index.md b/content/documentation/devpod/_index.md deleted file mode 100644 index 4dabc37..0000000 --- a/content/documentation/devpod/_index.md +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: "DevPod on AWS" -date: 2025-02-11T20:00:00+02:00 -weight: 1 -cascade: - type: docs ---- - -## Sources - -- [DevPod](https://devpod.sh/docs/what-is-devpod) ⚙️ -- [DevContainer](https://containers.dev) 🐳 - -## Introduction 🚀 - -In this article, I’d like to showcase a fantastic tool that sits in the same family as GitPod and Codespaces: **DevPod**! It empowers you to create development environments effortlessly—without getting locked into any particular vendor. 🔒❌ - -DevPod is based on **DevContainer** architecture and uses the specs found in a [devcontainer.json](https://containers.dev) file to spin up your dev setup. Personally, I love it for quickly and reliably deploying Network Labs with ContainerLab. 💻🧰 - -## What a DevContainer Is 🤔 - -A development container (often called a “dev container”) lets you use a container as a full-featured dev environment. (Check out the official [containers.dev documentation](https://containers.dev) for more details.) - -Let’s break it down: - -Have you ever heard the phrase “It works on my machine”? If you’re a developer, you’ve probably run headfirst into this problem when collaborating with others. But guess what? **DevContainers** solve the mystery of environment drift by providing consistent, reproducible Docker-based environments. Bye-bye setup headaches! 💆‍♀️ - -Using DevContainers, you just need: - -1. A `.devcontainer` folder in your project. -2. A `devcontainer.json` file that tells VS Code how to configure the container. -3. Docker installed locally - -The backbone of the DevContainer is the `devcontainer.json` file. For example: - -```json -{ - "name": "Python DevContainer", - "image": "mcr.microsoft.com/devcontainers/python:3.10", - "features": { - "docker-in-docker": "latest" - }, - "extensions": [ - "ms-python.python", - "ms-azuretools.vscode-docker" - ] -} -``` - -**What’s happening here?** 🕵️‍♀️ - -- **"image"** – This uses a Python 3.10 environment that’s ready to go. -- **"features"** – This adds Docker support inside the container. -- **"extensions"** – Installs useful Python and Docker extensions in VS Code. - -DevContainers are awesome for local dev, but sometimes you need more muscle—maybe your workloads are huge, or you want to run specialized labs. That’s where **DevPod** comes in. 💪 -**To be able to deployed lab easily on Cloud** - -## What DevPod Is 🤖 - -**DevPod** is an open-source tool that lets you spin up dev environments either on your local machine or in the cloud of your choice. Imagine a self-hosted, super-customizable version of GitHub Codespaces. 🎉 - -In my day-to-day networking escapades, I deploy ContainerLab-based setups with DevContainers on AWS. Let’s see how you can use DevPod to do exactly that (ContainerLab details will follow in another post, I promise!). 😜 - -## AWS Provider 🌐 - -DevPod uses **Providers**, which are like configuration modules that define where and how DevPod launches your environment. Here’s the Provider list: - -![Provider_list](provider.png#center) - -We’ll focus on the **AWS Provider**—though there are many config options: - -![Provider_list](aws_options.png#center) - -Before you freak out at all those toggles, don’t worry. If it’s just you tinkering, the defaults are usually fine. 🙌 - -> [!NOTE] **Open Source Perks** 🎁 -> -> Being open-source means you can pop the hood and see exactly how DevPod works. Check out the AWS code [here](https://github.com/loft-sh/devpod-provider-aws/tree/main) if you’re curious. - -## How the AWS Code Works - -Let’s break down what DevPod will do on AWS by looking at the [aws.go code](https://github.com/loft-sh/devpod-provider-aws/blob/main/pkg/aws/aws.go). From a high-level, it handles: - -1. **Initialization**: Reading configuration and setting up AWS SDK clients (with custom credentials if needed). -2. **Networking**: Finding or creating the appropriate subnet, VPC, and security groups. -3. **AMI Selection**: Choosing a suitable AMI (defaulting to a recent Ubuntu 22.04 image) and determining the root device. -4. **IAM Setup**: Ensuring an appropriate instance role and instance profile exist, complete with policies. -5. **Instance Lifecycle**: Creating, starting, stopping, checking status, and deleting instances. -6. **User Data Injection**: Generating a script (embedded as Base64) that configures the instance (sets up users and SSH keys) on first boot. -7. **Optional DNS**: Managing Route 53 records for the instance if the configuration calls for it. - -From my perspective, two points stand out as potentially the most critical: - -- **(#4) IAM Setup** -- **(#6) User Data Injection** - -### Why are #4 and #6 “Tricky”? - -- **IAM Setup** is primarily handled by the `CreateDevpodInstanceProfile` function. It creates a role named `devpod-ec2-role` that can do the following: - - **EC2 Operations**: For example, it can describe or stop instances—particularly the instance associated with itself. - - **SSM Operations**: By attaching the AmazonSSMManagedInstanceCore policy, the instance can be managed by AWS Systems Manager. - - **KMS Operations (Optional)**: If configured, it can perform `kms:Decrypt` on a specific KMS key, helpful for handling session data or secrets. - -- **User Data Injection** is basically a startup script inserted into the instance as Base64. That script sets up a `devpod` user with sudo rights, creates SSH folders, and plops your public key in place. In the code, [it looks like](https://github.com/loft-sh/devpod-provider-aws/blob/9d2730c34ecee40cb42596c602381b92ad9c6682/pkg/aws/aws.go#L967-L980): - -```bash -useradd devpod -d /home/devpod -mkdir -p /home/devpod -if grep -q sudo /etc/groups; then - usermod -aG sudo devpod -elif grep -q wheel /etc/groups; then - usermod -aG wheel devpod -fi - -echo "devpod ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/91-devpod -mkdir -p /home/devpod/.ssh -echo " + string(publicKey) + " >> /home/devpod/.ssh/authorized_keys -chmod 0700 /home/devpod/.ssh -chmod 0600 /home/devpod/.ssh/authorized_keys -chown -R devpod:devpod /home/devpod -``` - -Since DevPod is open source, you can easily check this out yourself. It’s a great learning tool if you’re curious about the nuts and bolts! 🔩 - -## IAM Roles and Policies - -You’ll need to set up an IAM user and attach an IAM policy that grants just enough permissions for DevPod. For example: - -- **EC2 Actions:** - - Describe: `ec2:DescribeSubnets`, `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups` - - Manage Instances: `ec2:RunInstances`, `ec2:StartInstances`, `ec2:StopInstances`, `ec2:TerminateInstances`, `ec2:CancelSpotInstanceRequests` - - Security Groups & Tags: `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTags` -- **IAM Actions:** - - `iam:GetInstanceProfile`, `iam:CreateRole`, `iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreateInstanceProfile`, `iam:AddRoleToInstanceProfile` -- **Route 53 (Optional):** - - `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets` - -## AWS Configuration 🏗️ - -I typically use the AWS web console to set this up, but you can absolutely do it all via CLI. - -### Step 1: Log in to the AWS Console - -1. Head to [AWS Management Console](https://aws.amazon.com/console/). -2. Use an account with the proper rights to create IAM resources. - -### Step 2: Create a Custom IAM Policy - -#### **A. Go to the IAM Console** - -- In the AWS menu, find **IAM**. - -#### **B. Create a New Policy** - -1. Click **Policies** on the left. -2. Press **Create policy**. - -#### **C. Switch to the JSON Tab** - -- Paste in something like this, adjusting if needed: - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "EC2Actions", - "Effect": "Allow", - "Action": [ - "ec2:DescribeSubnets", - "ec2:DescribeVpcs", - "ec2:DescribeImages", - "ec2:DescribeInstances", - "ec2:DescribeSecurityGroups", - "ec2:RunInstances", - "ec2:StartInstances", - "ec2:StopInstances", - "ec2:TerminateInstances", - "ec2:CancelSpotInstanceRequests", - "ec2:CreateSecurityGroup", - "ec2:AuthorizeSecurityGroupIngress", - "ec2:CreateTags", - "ec2:DeleteTags" - ], - "Resource": "*" - }, - { - "Sid": "IAMActions", - "Effect": "Allow", - "Action": [ - "iam:GetInstanceProfile", - "iam:CreateRole", - "iam:PutRolePolicy", - "iam:AttachRolePolicy", - "iam:CreateInstanceProfile", - "iam:AddRoleToInstanceProfile" - ], - "Resource": "*" - }, - { - "Sid": "Route53Actions", - "Effect": "Allow", - "Action": [ - "route53:ListHostedZones", - "route53:GetHostedZone", - "route53:ChangeResourceRecordSets" - ], - "Resource": "*" - } - ] -} -``` - -- Click **Next** (tags optional), then **Next: Review**. - -#### **D. Review and Create** - -1. Name it `DevpodToolPolicy` (or whatever you like). -2. Optional description. -3. Click **Create policy**. - -### Step 3: Create/Update the IAM User - -#### **A. Create a New User (If Needed)** - -1. Click **Users** in IAM. -2. **Add user**. -3. Name it (e.g., `devpod-tool-user`). -4. Choose **Programmatic access** if you want CLI access. 🤖 -5. **Next**. - -#### **B. Attach Your New Policy** - -1. On the permissions page, pick **Attach policies directly**. -2. Check `DevpodToolPolicy`. -3. Click **Create**. -4. That’s it! - -### Step 4: Verify & Done - -Head back to **Users** → **devpod-tool-user** → **Permissions** to confirm `DevpodToolPolicy` is attached. ✅ - -### Step 5: Use Those Credentials - -- If you created a programmatic user, make sure you note the **Access Key ID** and **Secret Access Key**. - -![devpod_user_sumup](devpod_user.png#center) - -**Bonus**: Keep track of your **VPC ID** (under the VPC service in AWS). You’ll need it when setting up DevPod. - -## Configure DevPod 🛠️ - -### 1. Configure AWS Profile - -```bash -aws configure --profile Devpod -``` - -When prompted: - -1. Access Key ID -2. Secret Access Key -3. Default region (e.g., `eu-west-1`) -4. Output format (I usually leave it blank.) - -### 2. Add Profile to DevPod - -1. In DevPod, create a new provider and pick **AWS**. -2. Select the **AWS region** (e.g., `eu-west-1`). -3. Expand AWS options. -4. **AWS Disk Size**: maybe 40GB to start. -5. **Instance Type**: e.g., `t2.small`. -6. **AWS Profile**: select `Devpod` (or the name you chose). -7. **AWS VPC ID**: add your VPC. -8. You can leave the rest as defaults. - -Click **Add Provider**. - -![added_new_provider](new_provider.png#center) - -## Testing a Deployment 🧪 - -### Deploy - -We’ll run a quick test using one of the prebuilt Docker images: - -1. Go to **Workspaces** in DevPod. -2. Click **Create Workspace**. -3. Pick your new **AWS** provider. -4. Choose your preferred IDE (VS Code, etc.). -5. On the right, pick a quickstart example (e.g., Python). 🐍 -6. Click **Create Workspace**. - -![new_worspace](new_worskapce.png#center) - -Wait a few moments, and your cloud-based environment will pop up in VS Code. 🎊 - -![vscode](vscode.png#center) - -### Stop - -When you’re not using it, click **Stop** to shut down the EC2 instance. You’ll only pay for storage—no compute time. Great for the wallet. 💰 - -![Stopped Instance](stopped_instance.png#center) - -### Delete - -Deleting the workspace removes all AWS resources for that environment, so you won’t pay a dime. But you’ll have to redeploy if you want to use it again. ♻️ - -![Delete Instance](delete_instance.png#center) - -## Conclusion 💡 - -By combining **DevContainers** and **DevPod** on **AWS**, you can build flexible, self-managed dev environments that scale as you grow—without getting boxed in by vendor-specific platforms. Wave goodbye to “It works on my machine!” woes, and say hello to frictionless coding. 🚀✨ - -Happy building and exploring! 🎉 diff --git a/content/documentation/devpod/aws_options.png b/content/documentation/devpod/aws_options.png deleted file mode 100644 index 894b6fd..0000000 Binary files a/content/documentation/devpod/aws_options.png and /dev/null differ diff --git a/content/documentation/devpod/delete_instance.png b/content/documentation/devpod/delete_instance.png deleted file mode 100644 index 616f618..0000000 Binary files a/content/documentation/devpod/delete_instance.png and /dev/null differ diff --git a/content/documentation/devpod/devpod_user.png b/content/documentation/devpod/devpod_user.png deleted file mode 100644 index 4f3ba2c..0000000 Binary files a/content/documentation/devpod/devpod_user.png and /dev/null differ diff --git a/content/documentation/devpod/new_provider.png b/content/documentation/devpod/new_provider.png deleted file mode 100644 index cf8b1ac..0000000 Binary files a/content/documentation/devpod/new_provider.png and /dev/null differ diff --git a/content/documentation/devpod/new_worskapce.png b/content/documentation/devpod/new_worskapce.png deleted file mode 100644 index 46d56e2..0000000 Binary files a/content/documentation/devpod/new_worskapce.png and /dev/null differ diff --git a/content/documentation/devpod/provider.png b/content/documentation/devpod/provider.png deleted file mode 100644 index 629f3c7..0000000 Binary files a/content/documentation/devpod/provider.png and /dev/null differ diff --git a/content/documentation/devpod/stopped_instance.png b/content/documentation/devpod/stopped_instance.png deleted file mode 100644 index e869662..0000000 Binary files a/content/documentation/devpod/stopped_instance.png and /dev/null differ diff --git a/content/documentation/devpod/vscode.png b/content/documentation/devpod/vscode.png deleted file mode 100644 index d256906..0000000 Binary files a/content/documentation/devpod/vscode.png and /dev/null differ diff --git a/content/documentation/stepca.md b/content/documentation/stepca.md deleted file mode 100644 index eb12be4..0000000 --- a/content/documentation/stepca.md +++ /dev/null @@ -1,312 +0,0 @@ ---- -title: "Self-Hosted Certificate Manager" -date: 2024-08-01T20:00:00+02:00 -weight: 2 -cascade: - type: docs ---- - -## 🔗 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/) -- [🔐 OpenSSL Certificate Management](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/) - -## 🤖 About Step-CA - -Step-CA is a nifty toolkit developed by Smallstep, a company that’s all about secure identity management and certificate automation. 🚀 Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security! - -### Key Features - -1. **Certificate Authority Management** 🔑 - Easily set up and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro. - -2. **Secure Key Management** 🛡️ - Best practices for secure key storage and management, ensuring your cryptographic keys stay safe and sound from unauthorized access. - -3. **Automation and Scalability** ⚙️ - Perfect for both small-scale and enterprise deployments. Enjoy APIs and integrations that automate certificate issuance, renewal, and revocation for a seamless lifecycle. - -4. **Enhanced Security** 🔒 - Using modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, offering robust encryption and digital signatures. - -5. **Integration with Infrastructure** 🌐 - Integrates smoothly with your existing tools and systems. Supports various authentication methods like username/password, MFA, and external identity providers. - -6. **Auditability and Compliance** 📜 - With comprehensive logging and auditing capabilities, you can track certificate activities and meet compliance requirements with ease. - -7. **Developer-Friendly APIs** 👩‍💻👨‍💻 - Developer-centric APIs and SDKs make it a breeze to integrate certificate management into your custom applications and workflows. - -**In a nutshell:** Step-CA from Smallstep is designed to make certificate authority management fun and hassle-free. With its secure, scalable, and user-friendly features, you can easily manage your certificate lifecycle while keeping your infrastructure safe and sound! - -## 🚀 Installation - -### 🔧 Binary Installation - -#### 1. Step CLI - -```bash -wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb -sudo dpkg -i step-cli_0.24.3_amd64.deb -``` - -#### 2. Step-CA - -```bash -wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_0.24.1_amd64.deb -sudo dpkg -i step-ca_0.24.1_amd64.deb -``` - -#### 3. Create a Specific User - -```bash -adduser adminCA -``` - -#### Configuration - -```bash -$ step ca init --password-file=password.txt -✔ Deployment Type: Standalone -What would you like to name your new PKI? -✔ (e.g. Smallstep): Lab -✔ (e.g. ca.example.com[,10.1.2.3,etc.]): ca.lab.loc, localhost, 192.168.1.101 -What IP and port will your new CA bind to? (:443 will bind to 0.0.0.0:443).1.101 -✔ (e.g. :443 or 127.0.0.1:443): :443 -What would you like to name the CA's first provisioner? -✔ (e.g. you@smallstep.com): contact@lab.loc -Choose a password for your CA keys and first provisioner. -✔ [leave empty and we'll generate one]: - -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 -✔ Root fingerprint: 7d754397c6897aa87d21e33c64daad7be087dc6fe18bf04627848ae1c8e26a4f -✔ Intermediate certificate: /home/adminCA/.step/certs/intermediate_ca.crt -✔ Intermediate private key: /home/adminCA/.step/secrets/intermediate_ca_key -✔ Database folder: /home/adminCA/.step/db -✔ Default configuration: /home/adminCA/.step/config/defaults.json -✔ Certificate Authority configuration: /home/adminCA/.step/config/ca.json - -Your PKI is all set! To generate certificates for individual services, check out `step help ca`. - -💌 **FEEDBACK** -The step utility is not instrumented for usage statistics. It doesn’t phone home. But your feedback is super valuable! Feel free to drop us a line at feedback@smallstep.com, join GitHub Discussions, or hop into our Discord at [https://u.step.sm/discord](https://u.step.sm/discord). -``` - -Start CA Step: - -```bash -step-ca .step/config/ca.json -``` - -#### Enable ACME - -```bash -$ step ca provisioner add acme --type ACME -✔ CA Configuration: /home/adminCA/.step/config/ca.json - -Success! Your `step-ca` config has been updated. To pick up the new configuration, SIGHUP (kill -1 ) or restart the step-ca process. 🎉 -``` - -#### Run Step-CA as a systemd Service - -Create a file: - -```bash -vim /etc/systemd/system/step-ca.service -``` - -Copy and paste the following: - -```config -[Unit] -Description=step-ca -After=syslog.target network.target - -[Service] -User=adminCA -Group=adminCA -ExecStart=/bin/sh -c '/bin/step-ca /home/adminCA/.step/config/ca.json --password-file=/home/step/.step/pwd >> /var/log/step-ca/output.log 2>&1' -Type=simple -Restart=on-failure -RestartSec=10 - -[Install] -WantedBy=multi-user.target -``` - -Create the log directory: - -```bash -mkdir -p /var/log/step-ca -chown -R adminCA:adminCA /var/log/step-ca -``` - -Reload the daemon: - -```bash -systemctl daemon-reload -systemctl start step-ca.service -``` - -### 🐳 Docker Installation - -```bash -docker run -it -v step:/home/step \ - -p 9000:9000 \ - -e "DOCKER_STEPCA_INIT_NAME=Lab" \ - -e "DOCKER_STEPCA_INIT_DNS_NAMES=caserver.lab.loc,localhost,192.168.1.101" \ - -e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \ - -e "DOCKER_STEPCA_INIT_ACME=true" \ - smallstep/step-ca -``` - -## 🔑 Access to CA with Another Client - -> [!NOTE] Adjust the port based on your installation: -> -> - **Binary:** port **443** -> - **Docker:** port **9000** - -Install the Step CLI: - -```bash -wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb -sudo dpkg -i step-cli_0.24.3_amd64.deb -``` - -Bootstrap your CA: - -```bash -step ca bootstrap --ca-url https://caserver.lab.loc:$PORT/ --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887 -``` - -> [!TIP] To get the **fingerprint**, simply run: -> -> ```bash -> step certificate fingerprint $(step path)/certs/root_ca.crt -> ``` -> -> For Docker, check the container logs. - -Example output: - -```bash -admin@User:~$ step ca bootstrap --ca-url https://caserver.lab.loc:$PORT --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887 -The root certificate has been saved in /home/admin/.step/certs/root_ca.crt. -The authority configuration has been saved in /home/admin/.step/config/defaults.json. -``` - -Install the certificate: - -```bash -step certificate install $(step path)/certs/root_ca.crt -``` - ---- - -> [!TIP] **Debian Installation:** -> -> - Copy individual CRT (PEM format) files to `/usr/local/share/ca-certificates/` -> - Files must be owned by `root:root` with mode `644` -> - Ensure the package `ca-certificates` is installed (if not, install it) -> - Then run as root: -> -> ```bash -> # /usr/sbin/update-ca-certificates -> ``` -> -> All certificates will be consolidated at: `/etc/ssl/certs/ca-certificates.crt` - ---- - -### 📝 Get a Certificate - -```bash -admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key -✔ Provisioner: contact@lab.loc (JWK) [kid: chyGkrZqp-BGSHUZ8v3jsPipegt2JLcC7y6RPq4OOkU] -Please enter the password to decrypt the provisioner key: -✔ CA: https://caserver.lab.loc:443 -✔ Certificate: srv.crt -✔ Private Key: srv.key -``` - ---- - -> [!TIP] To perform a health check: -> -> ```bash -> curl https://caserver.lab.loc:443/health -k -> ``` - ---- - -It might be necessary to customize the `ca.json` file to increase the minimum duration of the certificate validity. Check out the folder structure below: - -```bash -. -|-- certs -| |-- intermediate_ca.crt -| `-- root_ca.crt -|-- config -| |-- ca.json -| `-- defaults.json -|-- db -| |-- 000000.vlog -| |-- 000020.sst -| |-- KEYREGISTRY -| |-- LOCK -| `-- MANIFEST -|-- secrets -| |-- intermediate_ca_key -| |-- password -| `-- root_ca_key -`-- templates -``` - -Example `ca.json` file: - -```json -{ - "root": "/home/step/certs/root_ca.crt", - "federatedRoots": null, - "crt": "/home/step/certs/intermediate_ca.crt", - "key": "/home/step/secrets/intermediate_ca_key", - "address": ":9000", - "insecureAddress": "", - "dnsNames": [ - "caserver.lab.loc", - "caserver", - "localhost", - "192.168.1.200" - ], - "logger": { - "format": "text" - }, - "db": { - "type": "badgerv2", - "dataSource": "/home/step/db", - "badgerFileLoadingMode": "" - }, - "authority": { - "enableAdmin": true, - "claims": { - "maxTLSCertDuration": "4380h" - } - }, - "tls": { - "cipherSuites": [ - "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", - "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256" - ], - "minVersion": 1.2, - "maxVersion": 1.3, - "renegotiation": false - } -} -``` diff --git a/content/netlab/_index.md b/content/netlab/_index.md deleted file mode 100644 index 8d467fc..0000000 --- a/content/netlab/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Netlab" -cascade: - type: docs ---- - - - -{{< hextra/hero-subtitle >}} - Deep Dive using NetLab -{{< /hextra/hero-subtitle >}} - -{{< cards >}} - {{< card link="/Notebook/netlab/netlab/" title="What is a Netlab" subtitle="What and Why we use NetLab" icon="science" >}} - {{< card link="/Notebook/netlab/first_lab/" title="My First Lab" subtitle="How to deploy an NetLab using DevPod" icon="docker" >}} -{{< /cards >}} diff --git a/content/netlab/first_lab/_index.fr.md b/content/netlab/first_lab/_index.fr.md index f0311f9..b3b653c 100644 --- a/content/netlab/first_lab/_index.fr.md +++ b/content/netlab/first_lab/_index.fr.md @@ -1,7 +1,7 @@ --- title: "Mon Premier Lab" date: 2025-02-14T12:00:00+02:00 -weight: 1 +weight: 2 cascade: type: docs --- diff --git a/content/netlab/first_lab/_index.md b/content/netlab/first_lab/_index.md deleted file mode 100644 index bdac9bc..0000000 --- a/content/netlab/first_lab/_index.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -title: "My First Lab" -date: 2025-02-14T12:00:00+02:00 -weight: 1 -cascade: - type: docs ---- - -## Introduction 📚 - -In this article, we’ll explore how to install our very first Containerlab netlab using **DevPod**. We'll focus on leveraging a cloud provider—specifically **AWS**—to host our project. Why **Cloud**? Because network labs can consume a huge amount of resources, and we need the ability to deploy, stop, and destroy them quickly for both performance and financial efficiency. 💡💰 - -We'll achieve this using a combination of: - -- **DevPod** -- **DevContainer** -- **Containerlab** - -Additionally, we will use a small topology, which you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main objective is to deploy this lab on AWS using DevPod. Let's dive in and get started! 🚀😊 - -## Prerequisites 🔧 - -Before we get started, there are a couple of important steps to complete: - -1. **AWS Environment Authorization**: - Ensure that DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, please refer to my post on this [topic](/Notebook/documentation/devpod). 🔑 - -2. **Containerlab Topology**: - We need a topology file that Containerlab can understand. In our case, we're building a simple VXLAN topology. 🗺️ - -## Containerlab Topology 🔄 - -Our lab will simulate a VXLAN topology with: - -- **1 Spine switch** -- **2 Leaf switches** -- **2 Host nodes** - -The following diagram illustrates the VXLAN topology: - -![VXLAN Topology](VXLAN.svg#center) - -Below is the Containerlab topology file (`lab_vxlan.yml`) used for this setup: - -```yaml -name: vxlan-evpn-irb -topology: - nodes: - spine1: - kind: ceos - image: ceos:4.32.0.1F - mgmt-ipv4: 172.20.20.101 - leaf1: - kind: ceos - image: ceos:4.32.0.1F - mgmt-ipv4: 172.20.20.11 - leaf2: - kind: ceos - image: ceos:4.32.0.1F - mgmt-ipv4: 172.20.20.12 - host1: - kind: linux - image: alpine:latest - binds: - - hosts/h1_interfaces:/etc/network/interfaces - mgmt-ipv4: 172.20.20.21 - host2: - kind: linux - image: alpine:latest - binds: - - hosts/h2_interfaces:/etc/network/interfaces - mgmt-ipv4: 172.20.20.22 - links: - - endpoints: ["spine1:eth1", "leaf1:eth1"] - - endpoints: ["spine1:eth2", "leaf2:eth1"] - - endpoints: ["leaf1:eth2", "host1:eth1"] - - endpoints: ["leaf2:eth2", "host2:eth1"] -``` - -### Breaking Down the Topology 🧐 - -1. **Name and Structure**: - - `name: vxlan-evpn-irb` – This is the lab's name. - - The topology is divided into **nodes** (devices) and **links** (connections between devices). - -2. **Nodes**: - - **Spine Layer**: - - `spine1`: A containerized Arista cEOS switch using image version `4.32.0.1F`. - - **Management IP**: `172.20.20.101` - - **Leaf Layer**: - - `leaf1` and `leaf2`: Arista cEOS switches with the same image version. - - **Management IPs**: `172.20.20.11` and `172.20.20.12` - - **Host Layer**: - - `host1` and `host2`: Linux containers running Alpine Linux. - - They include custom network interface configurations mounted from the host. - - **Management IPs**: `172.20.20.21` and `172.20.20.22` - -3. **Links**: - - **Spine to Leaf**: - - `spine1:eth1` ↔ `leaf1:eth1` - - `spine1:eth2` ↔ `leaf2:eth1` - - **Leaf to Host**: - - `leaf1:eth2` ↔ `host1:eth1` - - `leaf2:eth2` ↔ `host2:eth1` - -This topology represents a typical spine-leaf architecture, common in data center networks to enable both Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. 🔗💻 - -## Deploy the Lab 🛠️ - -We will deploy the lab using **DevPod** in two ways: - -### 1. Using the Repository 📥 - -1. **Validate AWS Provider Configuration**: - Ensure that your AWS provider is correctly configured. More details can be found [here](/Notebook/documentation/devpod). ✅ - -2. **Create a Workspace**: - - Navigate to the **Workspace** tab and click on **Create Workspace**. - - Enter the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). - - Select **AWS** as the provider. - - Choose your default IDE. - - Finally, click on **Create Workspace**. - - ![DevPod Configuration](devpod_configuration.png#center) - -### 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. - - ![DevPod Configuration - Local](devpod_configuration_local.png#center) - -## Starting the Lab 🎬 - -> [!WARNING] cEOS Images -> The lab uses **cEOS image v4.32.0.1F**. -> To download this image, visit the [Arista download webpage](https://www.arista.com/en/support/software-download). ⚠️ - -1. **Import the cEOS Image**: - Save the cEOS image in 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: - - ```bash - sudo containerlab deploy -t lab_vxlan.yml - ``` - - Follow the CLI prompts to configure your devices. For detailed configuration steps, refer to [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️ - -3. **Visualize the Architecture**: - Validate the deployed topology using Containerlab’s graph view: - - ```bash - containerlab graph -t lab_vxlan.yml - ``` - - Ports (e.g., port 50080 as mentioned in the `devcontainer.json`) are forwarded. Access the graph view via [localhost](http://localhost:50080). - - ![Graph View](Graph_view.png#center) - -## Using EdgeShark 🦈 - -EdgeShark is a web UI tool that helps capture packets from your lab environment. It tunnels captures from the lab to Wireshark running locally. 📡🔍 - -For more details, check out [EdgeShark’s Getting Started Guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin). - -### EdgeShark Setup in the DevContainer 🐳 - -In the **DevContainer** configuration, the following `postCreateCommand` has been added: - -```bash -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 facilitate the use of EdgeShark. 🚀 - -### Running EdgeShark ⚡ - -To start EdgeShark, execute: - -```bash -cd /opt/edgeshark -DOCKER_DEFAULT_PLATFORM= docker compose up -d -``` - -Access EdgeShark via [localhost:5001](http://localhost:5001). - -- **EdgeShark View**: - ![Edgeshark View](edgeshark.png#center) - -- **Wireshark Integration**: - Using the Wireshark icon in EdgeShark, you can launch Wireshark locally. - ![Edgeshark Interface](edgeshark_interface.png#center) - ![Edgeshark and Wireshark](edge_wireshark.png#center) - -## 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 prerequisites** for AWS and Containerlab. 🔑 -- **Creating a detailed topology** file for a spine-leaf network. 🗺️ -- **Deploying the lab** using both repository and local methods. 📥🗂️ -- **Starting the lab** with Docker and Containerlab. 🚀🐳 -- **Using EdgeShark** to capture packets and integrate with Wireshark for detailed analysis. 🦈🔍 - -By following these steps, you can easily deploy and manage a scalable network lab environment in the cloud. Happy networking and enjoy your lab adventures! 😄🎊 diff --git a/content/netlab/netlab.fr.md b/content/netlab/netlab.fr.md index 9d10ba0..2f7221d 100644 --- a/content/netlab/netlab.fr.md +++ b/content/netlab/netlab.fr.md @@ -1,5 +1,6 @@ --- title: "Présentation des NetLabs" +weight: 1 cascade: type: docs --- diff --git a/content/netlab/netlab.md b/content/netlab/netlab.md deleted file mode 100644 index 362a3f4..0000000 --- a/content/netlab/netlab.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "What is a Netlab" -cascade: - type: docs ---- - -## Introduction - -📡 In a world where computer networks play an increasingly significant role in our daily lives, understanding the principles and logic that drive them becomes more and more essential. - -Virtual Network Labs (commonly referred to as "NetLab" or "Virtual Network Lab") are an ideal approach for teaching these concepts, allowing us to simulate complex network environments and experiment without risks. - -I would like to share with you how my "NetLabs" work, which will be regularly linked to documentary articles (in the category: **documentation**). They will allow us to practice, observe, or understand the operation of concepts explained theoretically beforehand. - -In the context of NetLabs, they will primarily be deployed via the ContainerLab tool. For more complex architectures, we will use GNS3. - -## What is ContainerLab? 🛠️ - -ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. By using it, one can simulate a multitude of complex network architectures, with equipment such as routers, switches, servers, and other network devices. - -This platform offers great flexibility in designing exercises, allowing the exploration of various topics such as learning network protocols, security, or configuring equipment. Users can thus focus on analysis and problem-solving without worrying about the underlying technical details. - -The installation of ContainerLab will not be presented here, but all information is available on the official website [here](https://containerlab.dev/install/). - -## What is GNS3? 💻 - -GNS3, or Graphical Network Simulator-3, is an open-source software primarily 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 previously mentioned, the installation of GNS3 will not be discussed here. For more information, the documentation is available [here](https://docs.gns3.com/docs/). - -## GNS3 vs ContainerLab ⚔️ - -GNS3 and ContainerLab are two powerful tools for network simulation and emulation, but they differ in their approach, features, and primary use cases. Here is a quick comparison between the two: - -### GNS3 - -**Advantages:** - -1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that allows users to drag and drop components to create 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. - -**Disadvantages:** - -1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies. -2. **Configuration Complexity:** The initial setup can be complex, particularly for new users. - -### ContainerLab - -**Advantages:** - -1. **Lightweight and Performance:** ContainerLab uses containers to emulate network devices, making it more lightweight and performant than solutions based on virtual machines. -2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, facilitating automated deployment and network management. -3. **Simplified Configuration:** Topologies are defined via YAML files, making the configuration simpler and scriptable. -4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments. - -**Disadvantages:** - -1. **Less Multivendor Support:** Although 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. - -## Conclusion 📊 - -**GNS3** is ideal for those looking for an intuitive graphical interface and broad support for network devices, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is more suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation. - -The choice between GNS3 and ContainerLab thus primarily depends on the specific needs of the user in terms of flexibility, performance, and integration with other tools and technologies. diff --git a/content/netlab/vxlan_automation/Site Standard.drawio.svg b/content/netlab/vxlan_automation/Site Standard.drawio.svg new file mode 100644 index 0000000..da1f1d3 --- /dev/null +++ b/content/netlab/vxlan_automation/Site Standard.drawio.svg @@ -0,0 +1,4 @@ + + + +
Datacenter

...

Spine 1
Spine 2
Leaf 1
Leaf 2
Leaf X
Access 1
Access 1
Access 1
 \ No newline at end of file diff --git a/content/netlab/vxlan_automation/_index.fr.md b/content/netlab/vxlan_automation/_index.fr.md new file mode 100644 index 0000000..78a2648 --- /dev/null +++ b/content/netlab/vxlan_automation/_index.fr.md @@ -0,0 +1,228 @@ +--- +title: Automatisation VXLAN avec Netbox +draft: true +date: 2025-04-02T20:00:00+02:00 +weight: 3 +cascade: + type: docs +--- + +## 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"**. + +L'idée principale de ce projet est de simplifier la gestion des configurations réseau en limitant le recours à des outils d'orchestration externes, qui peuvent parfois complexifier la gestion des inventaires. Nous allons démontrer comment Netbox peut générer automatiquement les configurations de nos équipements réseau à partir de modèles Jinja2, à condition de respecter un principe fondamental : **la standardisation de notre infrastructure.** 💡 + +Pour illustrer cette approche, nous allons prendre l'exemple d'un site fictif, **"Paris"**, conçu selon des règles de standardisation claires et précises. Cette normalisation nous permettra de : + +1. **Modéliser** l'ensemble de l'infrastructure du site "Paris" dans Netbox (bâtiments, clients, fabric). +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. + +Alors, prêt à découvrir comment la standardisation ouvre la voie à une automatisation intelligente de votre réseau VXLAN avec Netbox ? C'est parti ! 🚀😊 + +> [!NOTE] **CookBook** +> L'ensemble des actions décrites dans cet article sont expliqués [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates) +> Cette article nous fournira pas un guide étape par étape, mais fournira le lien vers le Cookbook qui lui, le fourni. + +## 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 🏢 + +Un site standard est défini par les éléments suivants : + +* **Une Salle Serveur Centrale :** Unique au sein du site, elle héberge les deux spines de la fabric (Spine 1 et Spine 2), constituant le cœur de l'infrastructure réseau. +* **Un à Cinq Bâtiments Plain-Pied :** Chaque bâtiment est dédié à l'hébergement d'un seul client (bien que des 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 🔗 + +Dans un site standard, la connexion des équipements leaf aux spines suit les règles suivantes : + +* **Interface Eth1 du Leaf :** Systématiquement connectée à l'interface Eth1 du Spine 1. +* **Interface Eth2 du Leaf :** Systématiquement connectée à l'interface Eth2 du Spine 2. +* **Interface Eth3 du Leaf :** Systématiquement dédiée à la connexion au switch d'accès présent dans le même bâtiment. + +![Site Standard]() + +> [!NOTE] Simplification pour le POC +> 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" 🌐 + +Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox suivants, qui s'inscrivent dans notre stratégie d'adressage globale : + +* **Location :** + * Région : Europe + * Ville : Paris +* **Conteneurs de Préfixes :** + * **UnderlayContainer (Paris) :** + * CIDR : `172.16.0.0/16` + * Description : "Préfixe conteneur pour le réseau Underlay du site de Paris" + * **LoopbackContainer (Paris) :** + * CIDR : `192.168.100.0/24` + * Description : "Préfixe conteneur pour les adresses Loopback des équipements du site de Paris" + * **CustomersContainer (Paris) :** + * CIDR : `10.0.0.0/8` + * Description : "Préfixe conteneur pour l'adressage des clients du site de Paris" + +Ces conteneurs de préfixes 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é 📍 + +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 + +Le POC se jouera sur ContainerLab, il est donc necessaire de se reférencer à [cette article](../../documentation/devpod) afin de facilement reproduire l'installation et les outils. + +Nous utiliserons : + +* ContainerLab +* Arista cEOS pour la partie Switch/routeur +* 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) + +## 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` 🛠️ + +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 :** + +* **[`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 :** + +* 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 gros blocs d'adresses IP qu'on va utiliser pour notre réseau à Paris (nos "conteneurs de préfixes"). + +**Comment on Lance la Machine :** + +On ouvre notre terminal et on tape la commande : + +```bash +uv run import.py http://localhost:8080 YOUR_TOKEN Devices/devices_model.yml IPAM/subnet.yml +``` + +Remplace bien `http://localhost:8080` par l'adresse de ton Netbox et `YOUR_TOKEN` par ton jeton d'API Netbox ! Une fois lancé, ce script met en place les fondations de notre automatisation. + +> [!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` 🚀 + +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 :** + +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. + +```bash +uv run Create_Fabric/main.py +NetBox URL: http://localhost:8080 +NetBox API Token: +Number of buildings (1-5): 4 +Spine device type slug: ceos +Leaf device type slug: ceos +Access switch device type slug: ceos + +Existing Sites: + 1. Paris (slug=paris) +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 ! C'est l'automatisation à son meilleur, rendue possible par notre approche standardisé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) + +![Topologie de Paris](fabric_topology.png) + +> [!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` 🧑‍💻 + +A ce niveau, la fabric est fonctionnelle, mais aucun client n'est configuré, mais qu'est-ce que ça veut dire !! 🙋 + + + +## La Magie des Templates : Netbox et Jinja2 Entrent en Scène ✨ + +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** ! + +### 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. + +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. + +3. **Un Petit Coup d'Œil à une Recette 📜** Prenons un exemple de template Jinja2 pour un de nos leafs : + + ```jinja + hostname {{ device.name }} + {% if device.custom_fields.ASN %} + router bgp {{ device.custom_fields.ASN }} + router-id {{ device.primary_ip4.address.split('/')[0] }} + {% endif %} + interface Loopback0 + ip address {{ device.primary_ip4.address }} + {% for interface in device.interfaces %} + interface {{ interface.name }} + description {{ interface.description }} + {% if interface.connected_interface %} + no shutdown + {% endif %} + {% endfor %} + ``` + + 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 : + + * 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". + * Il remplit tous les "trous" (les variables Jinja2) du template avec les infos spécifiques de notre `pa01_lf1_00`. + * Et hop ! Il nous sort un fichier de configuration texte prêt à être utilisé. + +> [!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 🖥️➡️💻 + +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 : + + * Dans l'interface de Netbox, on va dans **Devices**. + * On clique sur l'équipement qui nous intéresse (par exemple, un de nos leafs). + * Et là, on a un onglet magique : **Render Config** ! En cliquant dessus, on voit la configuration que Netbox a générée pour cet équipement en utilisant le template Jinja2 et ses propres données. + +2. **La Touche Humaine dans Containerlab 🖐️** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations à nos équipements cEOS dans Containerlab. Donc, on va faire à l'ancienne (mais c'est 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). + * 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 ! 😉 diff --git a/content/netlab/vxlan_automation/fabric_topology.png b/content/netlab/vxlan_automation/fabric_topology.png new file mode 100644 index 0000000..1728d99 Binary files /dev/null and b/content/netlab/vxlan_automation/fabric_topology.png differ diff --git a/hugo.yaml b/hugo.yaml index 506ac99..1fa23ad 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -1,15 +1,9 @@ -baseURL: "https://darnodo.github.io/Notebook/" +baseURL: "https://darnodo.github.io/Notebook" title: 🧑‍💻 Notebook theme: hextra -defaultContentLanguage: en -languages: - en: - languageName: English - weight: 1 - fr: - languageName: Français - weight: 2 +defaultContentLanguage: fr +languageCode: fr menu: main: @@ -40,7 +34,6 @@ params: # Logo logo: path: images/logo.svg - link: /Notebook/ width: 40 height: 20 # Search diff --git a/static/images/tech-banner.png b/static/images/tech-banner.png new file mode 100644 index 0000000..b6aba0a Binary files /dev/null and b/static/images/tech-banner.png differ