Remplacement diagrammes PDF par PNG, ajout note Docker Swarm, traductions complètes
- Replace PDF diagrams with PNG images for inline display in docs - Add infrastructure diagram to Homelab actuel category page - Add network diagram to single-machine HA homelab page - Add Docker Swarm vs Kubernetes decision note in docker-compose page - Complete English translations for homepage tagline - Translate homepage tagline dynamically using Docusaurus i18n - Remove PDF diagram files from static assets (homelab-actuel-infra.pdf, homelab-futur-network.pdf) - Add new documentation pages: Docker Compose, Ansible playbooks, Traefik - Add Future Homelab pages: single-machine HA and 3-node Proxmox cluster - Remove example pages and notions category - Update sidebar configuration
This commit is contained in:
parent
cb1640c1cc
commit
ed2cca8c0e
27 changed files with 1482 additions and 636 deletions
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Docker and Docker Compose
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
Docker is a **containerization platform** that allows packaging applications and their dependencies into lightweight and isolated containers.
|
||||
|
||||
## What is Docker?
|
||||
|
||||
A container is a standardized software unit that contains:
|
||||
- The application itself
|
||||
- All its dependencies (libraries, runtime, system tools)
|
||||
- An isolated filesystem
|
||||
- Environment variables and configuration
|
||||
|
||||
**Difference with virtual machines**:
|
||||
- **Container**: Shares the host OS kernel, starts in seconds, very lightweight (~MB)
|
||||
- **VM**: Emulates a complete OS, starts in minutes, heavier (~GB)
|
||||
|
||||
## Docker Compose: Simplified orchestration
|
||||
|
||||
Docker Compose is an **orchestration tool** for defining and managing multi-container applications.
|
||||
|
||||
### Why Docker Compose?
|
||||
|
||||
- **Declarative configuration**: Everything defined in a `compose.yml` file
|
||||
- **Grouped management**: Start/stop all services with one command
|
||||
- **Automatic networks**: Containers communicate easily between them
|
||||
- **Persistent volumes**: Simple storage management
|
||||
- **Environment variables**: Flexible configuration via `.env` files
|
||||
|
||||
## Configuration examples
|
||||
|
||||
My Docker Compose stacks are available in the Ansible repository under `stacks/`. Key examples include:
|
||||
- **Traefik**: Advanced reverse proxy with two instances (public and private)
|
||||
- **Photoprism**: Application with database (app + DB)
|
||||
- **Mobilizon**: Multi-container application with multiple networks
|
||||
- **Vaultwarden**: Security-focused configuration
|
||||
|
||||
## Patterns and best practices
|
||||
|
||||
1. **External network `traefik_network`**: All services share a common Docker network
|
||||
2. **Traefik labels**: Dynamic configuration via Docker labels
|
||||
3. **Environment variables with .env files**: Secrets extracted from Compose files
|
||||
4. **Dual exposure**: local and production access for each service
|
||||
5. **Restart policies**: `unless-stopped` for resilience
|
||||
6. **Watchtower for monitoring**: Watchtower is used **only for notifications** of available image updates. Updates are performed **manually** to maintain control over changes. In the [Future Homelab](../homelab-futur/index.md), automated update management will be implemented via Renovate Bot integrated directly with Forgejo.
|
||||
|
||||
## Benefits for a homelab
|
||||
|
||||
- **Simplicity**: Readable and maintainable YAML files
|
||||
- **Performance**: Instant service startup, low overhead
|
||||
- **Flexibility**: Easy to add/remove services
|
||||
- **Rich ecosystem**: Docker Hub with thousands of ready-to-use images
|
||||
|
||||
## Why not Docker Swarm?
|
||||
|
||||
When considering the evolution of my infrastructure, **Docker Swarm** was evaluated as an alternative to Kubernetes for container orchestration.
|
||||
|
||||
### Docker Swarm: a tempting but outdated choice
|
||||
|
||||
**Advantages of Docker Swarm**:
|
||||
- Natively integrated with Docker (no additional installation)
|
||||
- Simpler configuration than Kubernetes
|
||||
- Gentler learning curve
|
||||
- Uses Docker Compose files directly (with some adaptations)
|
||||
- Less resource-intensive than Kubernetes
|
||||
|
||||
**Why I didn't choose it**:
|
||||
|
||||
1. **Kubernetes is the industry standard**: The vast majority of companies use Kubernetes in production. Learning K8S provides skills directly transferable to the professional world.
|
||||
|
||||
2. **Ecosystem and community**: Kubernetes benefits from a much richer ecosystem (Helm, operators, numerous DevOps tools) and a much larger community.
|
||||
|
||||
3. **Advanced features**: Kubernetes offers capabilities that Docker Swarm doesn't have:
|
||||
- More advanced rolling updates and rollbacks
|
||||
- Fine-grained resource management (CPU/RAM limits, requests)
|
||||
- More elaborate network policies
|
||||
- Native GitOps support (ArgoCD, Flux)
|
||||
- Better integrated distributed storage (CSI drivers)
|
||||
|
||||
4. **Evolution and support**: Docker Inc. has clearly oriented its development toward Kubernetes rather than Swarm. Swarm is maintained, but no longer evolves much.
|
||||
|
||||
5. **Learning objective**: My goal being to acquire modern DevOps skills, mastering Kubernetes is a better long-term investment.
|
||||
|
||||
**Conclusion**: Although Docker Swarm is simpler and sufficient for many homelabs, I preferred to invest directly in learning Kubernetes, which has become the essential standard for container orchestration.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Current Homelab category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to document a service or configuration of the current homelab.
|
||||
|
||||
## Docker Compose Configuration
|
||||
|
||||
Example service configuration:
|
||||
|
||||
```yaml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
example-service:
|
||||
image: nginx:latest
|
||||
container_name: example
|
||||
ports:
|
||||
- "8080:80"
|
||||
volumes:
|
||||
- ./config:/etc/nginx/conf.d
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
## Ansible Playbook
|
||||
|
||||
Deployment example with Ansible:
|
||||
|
||||
```yaml
|
||||
---
|
||||
- name: Deploy example service
|
||||
hosts: homelab
|
||||
become: yes
|
||||
|
||||
tasks:
|
||||
- name: Copy docker-compose file
|
||||
copy:
|
||||
src: docker-compose.yml
|
||||
dest: /opt/example/docker-compose.yml
|
||||
|
||||
- name: Start the service
|
||||
command: docker-compose up -d
|
||||
args:
|
||||
chdir: /opt/example
|
||||
```
|
||||
|
||||
## Maintenance
|
||||
|
||||
Important maintenance points:
|
||||
|
||||
- Regular backups
|
||||
- Docker image updates
|
||||
- Log monitoring
|
||||
- Restore testing
|
||||
|
|
@ -15,17 +15,31 @@ My current homelab uses a simple and effective approach:
|
|||
|
||||
## Architecture
|
||||
|
||||
### Infrastructure Diagram
|
||||
|
||||
The diagram illustrates the complete architecture of my current homelab, including:
|
||||
- Network infrastructure with the main server
|
||||
- Deployed Docker services
|
||||
- Traefik configuration for the reverse proxy (public and private instances)
|
||||
- Connections between different components
|
||||
- Local DNS configuration with dnsmasq
|
||||
|
||||
|
||||
|
||||
### Physical/Virtual Infrastructure
|
||||
- Dedicated servers or VMs
|
||||
- Secure local network
|
||||
- Storage and backups
|
||||
- Ubuntu Server dedicated server
|
||||
- Secure local network with local DNS (dnsmasq)
|
||||
- Unified storage with MergerFS
|
||||
- Firewall with firewalld
|
||||
|
||||
### Tech Stack
|
||||
- **OS**: Linux (Debian/Ubuntu)
|
||||
- **OS**: Linux (Ubuntu Server)
|
||||
- **Containerization**: Docker & Docker Compose
|
||||
- **Automation**: Ansible playbooks
|
||||
- **Reverse proxy**: Traefik or Nginx
|
||||
- **Monitoring**: Prometheus, Grafana
|
||||
- **Reverse proxy**: Traefik v3 (public and private instances)
|
||||
- **Security**: CrowdSec, TLS with Let's Encrypt
|
||||
- **Monitoring**: Beszel, Uptime Kuma
|
||||
- **Local DNS**: dnsmasq for resolving *.local.tellserv.fr
|
||||
|
||||
## Deployed Services
|
||||
|
||||
|
|
@ -41,18 +55,39 @@ The documentation details:
|
|||
- Simple to set up and maintain
|
||||
- Ansible enables complete automation
|
||||
- Docker Compose facilitates service management
|
||||
- Reproducible and versioned with Git
|
||||
- Ideal for progressive automation learning
|
||||
|
||||
## Limitations
|
||||
|
||||
- Limited scalability
|
||||
- No native high availability
|
||||
- Manual orchestration for certain tasks
|
||||
This infrastructure has several important limitations that motivate the evolution toward a new approach (see "Future Homelab" section).
|
||||
|
||||
These limitations motivate the evolution towards Kubernetes (see "Future Homelab" section).
|
||||
### Initial Absence of Git Versioning
|
||||
|
||||
## Articles
|
||||
One of the main limitations of this initial approach was the **absence of infrastructure versioning with Git**. At this stage of my journey, I had not yet mastered the DevOps philosophy and infrastructure code management best practices.
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
**Consequences of this limitation:**
|
||||
- No history of configuration changes
|
||||
- Difficult to roll back in case of problems
|
||||
- No traceability of modifications
|
||||
- Complex collaboration
|
||||
- Absence of code review process
|
||||
- Risk of divergence between documentation and reality
|
||||
|
||||
<DocCardList />
|
||||
This gap was an **important lesson** that led me to:
|
||||
1. Progressively correct this infrastructure by versioning Ansible playbooks and Docker Compose files
|
||||
2. Adopt Git and DevOps practices for all my future projects
|
||||
3. Integrate the "Infrastructure as Code" philosophy from the design phase
|
||||
|
||||
**Important note**: The Git repository [Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose) was created **after the fact** to present the work done. In the initial practice, Git, automated tests, and CI/CD were not used due to lack of knowledge at the time.
|
||||
|
||||
Git versioning is now in place for this infrastructure, but the architecture itself remains limited (see below).
|
||||
|
||||
### Technical Architecture Limitations
|
||||
|
||||
- **Limited scalability**: Single-machine infrastructure without load distribution capability
|
||||
- **No high availability**: Single point of failure (SPOF)
|
||||
- **Manual orchestration**: Some tasks still require manual intervention
|
||||
- **Initially absent CI/CD**: Manual deployments via Ansible (no automation on Git push)
|
||||
- **Limited testing**: No automatic validation of changes before deployment
|
||||
|
||||
These limitations motivate the evolution toward Kubernetes (K3S) and a complete Infrastructure as Code approach with CI/CD (see [Future Homelab](../homelab-futur/index.md) section).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Ansible Playbooks
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
Ansible is an open-source IT automation tool that enables configuration management, deployment, and infrastructure orchestration. In a homelab context, Ansible has become essential for maintaining reproducible and documented infrastructure.
|
||||
|
||||
## What is Ansible?
|
||||
|
||||
Ansible is an **Infrastructure as Code (IaC)** tool that allows you to:
|
||||
- **Automate** repetitive system administration tasks
|
||||
- **Standardize** configurations across multiple machines
|
||||
- **Document** infrastructure in executable format (code is documentation)
|
||||
- **Reproduce** identical environments easily
|
||||
- **Version** infrastructure with Git
|
||||
|
||||
## Project structure
|
||||
|
||||
My Ansible infrastructure is available:
|
||||
- **Online repository**: [https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose)
|
||||
|
||||
## Ansible roles
|
||||
|
||||
The infrastructure uses several roles:
|
||||
- **common**: Base system configuration, dnsmasq, firewalld, MergerFS
|
||||
- **cockpit**: Web admin interface
|
||||
- **docker**: Docker Engine installation and configuration
|
||||
- **services**: Docker stack deployment
|
||||
|
||||
## Secrets management
|
||||
|
||||
Secrets are encrypted with Ansible Vault and injected via Jinja2 templates into `.env` files.
|
||||
|
||||
## Benefits of this approach
|
||||
|
||||
1. **Reproducibility**: Infrastructure can be recreated identically in minutes
|
||||
2. **Living documentation**: Ansible code documents the infrastructure precisely
|
||||
3. **Complete automation**: No need to SSH for deployment or updates
|
||||
4. **Security**: Secrets are encrypted and never committed in plain text
|
||||
|
||||
## Current Limitations
|
||||
|
||||
Despite its many advantages, this approach has limitations:
|
||||
|
||||
1. **Late versioning**: The Git repository [Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose) was created **after the fact** to present the work. In the initial practice, Git, automated tests, and CI/CD were not used due to lack of knowledge at the time.
|
||||
2. **No automated tests**: No automatic playbook validation (Molecule, integration tests)
|
||||
3. **Single-machine infrastructure**: Ansible is designed to manage multiple servers, but I only manage one
|
||||
4. **No CI/CD integration**: Deployments are manual, no automated pipeline
|
||||
|
||||
These limitations will be addressed in the [Future Homelab](../homelab-futur/index.md) with the adoption of Kubernetes and GitOps.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Traefik - Modern Reverse Proxy
|
||||
|
||||
:::info
|
||||
This page will be completed soon with detailed Traefik configuration.
|
||||
:::
|
||||
|
||||
## Coming soon
|
||||
|
||||
- Detailed configuration of two Traefik instances (public and private)
|
||||
- SSL certificate management with Let's Encrypt
|
||||
- CrowdSec integration for security
|
||||
- Middleware configuration
|
||||
- Routing and domain management
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# 3-Node Proxmox Cluster: A True HA Homelab
|
||||
|
||||
Documentation coming soon...
|
||||
|
||||
## Target Architecture
|
||||
|
||||
This page will be completed with details of the final 3-node Proxmox cluster architecture.
|
||||
|
|
@ -1,153 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Future Homelab category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to document Kubernetes configurations and deployments for the future homelab.
|
||||
|
||||
## Kubernetes Deployment
|
||||
|
||||
Example deployment manifest:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: production
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: example
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: example
|
||||
spec:
|
||||
containers:
|
||||
- name: app
|
||||
image: nginx:latest
|
||||
ports:
|
||||
- containerPort: 80
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
namespace: production
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
type: ClusterIP
|
||||
```
|
||||
|
||||
## OpenTofu Configuration
|
||||
|
||||
Example infrastructure resource:
|
||||
|
||||
```hcl
|
||||
resource "kubernetes_namespace" "production" {
|
||||
metadata {
|
||||
name = "production"
|
||||
labels = {
|
||||
environment = "production"
|
||||
managed-by = "opentofu"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
resource "kubernetes_deployment" "example" {
|
||||
metadata {
|
||||
name = "example-app"
|
||||
namespace = kubernetes_namespace.production.metadata[0].name
|
||||
}
|
||||
|
||||
spec {
|
||||
replicas = 3
|
||||
|
||||
selector {
|
||||
match_labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
template {
|
||||
metadata {
|
||||
labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
spec {
|
||||
container {
|
||||
image = "nginx:latest"
|
||||
name = "app"
|
||||
|
||||
resources {
|
||||
limits = {
|
||||
cpu = "100m"
|
||||
memory = "128Mi"
|
||||
}
|
||||
requests = {
|
||||
cpu = "50m"
|
||||
memory = "64Mi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GitOps with ArgoCD
|
||||
|
||||
ArgoCD Application configuration:
|
||||
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: argocd
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://forgejo.tellserv.fr/Tellsanguis/k8s-manifests.git
|
||||
targetRevision: HEAD
|
||||
path: apps/example
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: production
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
```
|
||||
|
||||
## Observability
|
||||
|
||||
Monitoring points for this service:
|
||||
|
||||
- Prometheus metrics exposed on `/metrics`
|
||||
- Logs aggregated in Loki
|
||||
- Distributed traces with Tempo
|
||||
- Alerts configured in Prometheus AlertManager
|
||||
|
|
@ -70,9 +70,3 @@ This migration represents:
|
|||
- **Practical learning**: Experimentation in real conditions
|
||||
- **Technical evolution**: Moving to modern and scalable solutions
|
||||
- **Portfolio**: Demonstration of advanced DevOps skills
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
|
|
|
|||
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# First Version: Single-Machine "HA" Homelab (Initial Project)
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
## Introduction
|
||||
|
||||
**Important note**: This page describes the **initial project** I had planned to experiment with Kubernetes. This project **evolved** into a different final decision: a 3-node Proxmox cluster (see [3-Node Proxmox Cluster](./cluster-3-noeuds-proxmox.md)).
|
||||
|
||||
The initial idea was to create a **transitional step** toward a complete distributed infrastructure, experimenting with Kubernetes (K3S), Infrastructure as Code (OpenTofu/Terraform), Git, and CI/CD pipelines, while remaining on a single physical machine.
|
||||
|
||||
## Objectives
|
||||
|
||||
### Practical Learning
|
||||
|
||||
This single-machine infrastructure allows acquiring hands-on experience with:
|
||||
- **Kubernetes (K3S)**: Installation, configuration, and management
|
||||
- **Infrastructure as Code**: OpenTofu/Terraform for declarative infrastructure
|
||||
- **GitOps and CI/CD**: Automated deployments with Forgejo Actions
|
||||
- **Observability**: Prometheus, Grafana, Loki stack
|
||||
|
||||
## Network Architecture
|
||||
|
||||
|
||||
|
||||
## What Can Be Learned
|
||||
|
||||
This single-machine infrastructure allows acquiring essential skills:
|
||||
- Kubernetes deployments and management
|
||||
- DevOps practices (IaC, GitOps, CI/CD)
|
||||
- Monitoring and logging
|
||||
- Automation with Ansible and OpenTofu
|
||||
|
||||
## Limitations of This Approach
|
||||
|
||||
### 1. No Real High Availability (HA)
|
||||
|
||||
**Main limitation**: With a single machine, there is **no redundancy**:
|
||||
- Single point of failure (SPOF)
|
||||
- Maintenance requires downtime
|
||||
- No automatic failover
|
||||
|
||||
### 2. Distributed Storage Impossible to Test
|
||||
|
||||
**Critical limitation**: Distributed storage (Ceph, Linstor DRBD, Longhorn with replication) requires **at least 3 nodes**:
|
||||
- **Ceph**: Requires 3 nodes minimum (ideally 5+) for quorum and replication
|
||||
- **Linstor DRBD**: Needs multiple nodes for synchronous data replication
|
||||
- **Longhorn** (replication): Cannot replicate data to other nodes
|
||||
|
||||
### 3. Limited Scalability
|
||||
|
||||
- Cannot add worker nodes to increase capacity
|
||||
- Hardware limitations of single machine
|
||||
- No experience with horizontal auto-scaling
|
||||
|
||||
### 4. Simplified Network
|
||||
|
||||
- All pods on the same physical machine
|
||||
- Negligible network latency
|
||||
- No multi-node CNI complexity
|
||||
|
||||
### 5. No Realistic Failure Simulation
|
||||
|
||||
- Cannot simulate node failure
|
||||
- No automatic failover testing
|
||||
- No disaster recovery validation
|
||||
|
||||
## Why Start with Single Machine?
|
||||
|
||||
Despite limitations, this approach has **significant advantages**:
|
||||
|
||||
### 1. Cost and Simplicity
|
||||
|
||||
- Reduced investment (no need to buy 3-5 servers immediately)
|
||||
- Lower power consumption
|
||||
- Simplified maintenance
|
||||
|
||||
### 2. Progressive Learning Curve
|
||||
|
||||
- Manageable complexity
|
||||
- Simplified debugging
|
||||
- Less costly mistakes
|
||||
|
||||
### 3. Architecture Validation
|
||||
|
||||
- Test which services work well on K8S
|
||||
- Optimize resource configurations
|
||||
- Identify incompatibilities before scaling
|
||||
|
||||
### 4. Preparation for Evolution
|
||||
|
||||
This version serves as a **foundation** for the complete cluster:
|
||||
- Reusable IaC code
|
||||
- Tested and validated Kubernetes manifests
|
||||
- Operational CI/CD pipelines
|
||||
|
||||
## Evolution Toward Real Cluster
|
||||
|
||||
Once stabilized, evolution toward multi-node cluster becomes natural:
|
||||
|
||||
**Minimum for functional HA cluster**:
|
||||
- 3 nodes (1 control plane + 2 workers, or 3 mixed nodes)
|
||||
- Gigabit network switch
|
||||
- Distributed storage (Ceph ideally requires 5 nodes)
|
||||
|
||||
**Migration strategy**:
|
||||
1. Add second node to existing cluster
|
||||
2. Test pod distribution between nodes
|
||||
3. Add third node to enable HA
|
||||
4. Deploy Ceph or Linstor for distributed storage
|
||||
5. Migrate critical workloads with replication
|
||||
|
||||
## Conclusion
|
||||
|
||||
This single-machine "HA" version is an **essential pedagogical step** before deploying a real Kubernetes cluster:
|
||||
|
||||
**Positive points**:
|
||||
- Learn Kubernetes without multi-node complexity
|
||||
- Validate architecture and configurations
|
||||
- Reduced cost and simplified maintenance
|
||||
- Solid foundation to evolve toward complete cluster
|
||||
|
||||
**Assumed limitations**:
|
||||
- No real high availability
|
||||
- Distributed storage impossible to test (Ceph, Linstor)
|
||||
- Limited scalability
|
||||
- No realistic failure simulation
|
||||
|
||||
This approach allows **methodical progression** toward a complete cloud-native infrastructure while mastering each step of the process.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Concepts category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to structure content in a category. It can contain:
|
||||
|
||||
- Detailed explanations
|
||||
- Code examples
|
||||
- Diagrams
|
||||
- References
|
||||
|
||||
## Usage
|
||||
|
||||
You can duplicate this page to create new articles in this category.
|
||||
|
||||
### Configuration
|
||||
|
||||
To add a new page, create a `.md` file in the `docs/notions/` folder with the appropriate front matter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
```
|
||||
|
||||
### Content
|
||||
|
||||
Content can be written in Markdown or MDX to include custom React components.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
This section groups fundamental technical concepts and notions used in my projects.
|
||||
|
||||
## Objective
|
||||
|
||||
Document and explain key concepts to:
|
||||
- Facilitate understanding of technical choices
|
||||
- Serve as reference for projects
|
||||
- Share theoretical and practical knowledge
|
||||
|
||||
## Topics Covered
|
||||
|
||||
Covered concepts include:
|
||||
|
||||
### Infrastructure
|
||||
- Virtualization and containerization
|
||||
- Networking and security
|
||||
- Storage and backup
|
||||
|
||||
### Automation
|
||||
- Infrastructure as Code (IaC)
|
||||
- Configuration Management
|
||||
- CI/CD and pipelines
|
||||
|
||||
### DevOps
|
||||
- GitOps and versioning
|
||||
- Observability (monitoring, logging, tracing)
|
||||
- Practices and methodologies
|
||||
|
||||
### Orchestration
|
||||
- Kubernetes and containers
|
||||
- Service mesh
|
||||
- Load balancing and scaling
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
Loading…
Add table
Add a link
Reference in a new issue