The article from Unsloth.ai explores the evolution of Reinforcement Learning (RL) in the context of agentic AI, emphasizing the shift from static data learning to dynamic, experience-driven systems. It highlights the critical role of RL environments, which define permissible actions, state changes, and success metrics. The piece discusses the transition from traditional RL methods like PPO to more efficient algorithms such as GRPO and DPO, and introduces tools like NVIDIA NeMo Gym and Unsloth for building scalable RL workflows. The article also outlines the importance of environment design, verification logic, and the hybrid use of Supervised Fine-Tuning (SFT) and RL for training AI models effectively.

The Evolution of Reinforcement Learning (RL) in Agentic AI

Reinforcement Learning (RL) has been a cornerstone of AI development for decades, powering everything from early control systems to modern game-playing agents and large language models (LLMs). However, as AI systems become more agentic—capable of multi-step reasoning, tool use, and autonomous decision-making—RL is evolving to meet new challenges. This shift marks the dawn of the "Era of Experience," where AI learns from interaction rather than just static datasets.

Why RL Environments Are Central to Agentic AI

At its core, RL is about teaching a model to learn through trial, feedback, and improvement. The key components of an RL workflow include:

• Policy Model: The AI agent that makes decisions.
• Training Algorithm: The method used to update the model (e.g., PPO, GRPO, DPO).
• Environment: The simulated or real-world space where the agent operates, defining:
  • Permissible actions (what the agent can do).
  • State changes (how the world responds).
  • Success metrics (how performance is measured).

The environment acts as the contract between learning and behavior, shaping how an agent improves over time. Unlike traditional supervised learning, where models are trained on fixed datasets, RL environments allow agents to explore, adapt, and recover from failures dynamically.

When to Use RL vs. Supervised Fine-Tuning (SFT)

Supervised Fine-Tuning (SFT): Best for Clear, Demonstrated Behaviors

• Use Case: When you can provide explicit examples of desired behavior (e.g., instruction-response pairs).
• Strengths:
  • Teaches format and style effectively.
  • Works well for single-step tasks (e.g., text summarization, translation).
• Limitations:
  • Struggles with multi-step reasoning (e.g., planning, tool use).
  • Requires large, high-quality datasets of demonstrations.

Reinforcement Learning (RL): Best for Complex, Verifiable Tasks

• Use Case: When you need an agent to explore and optimize for a goal (e.g., math, coding, tool use).
• Strengths:
  • Resilient to edge cases (learns from failure).
  • Optimizes for long-term outcomes (e.g., multi-step tool use).
  • Works with verifiable rewards (e.g., unit test passes, correct answers).
• Limitations:
  • Computationally expensive (requires many rollouts).
  • Harder to stabilize (reward design is critical).

Hybrid Approach: SFT + RL

• Many modern AI systems (e.g., NVIDIA Nemotron 3) use SFT first to ground the model, then RL for refinement.
• This balances efficiency (SFT) with generalization (RL).

Modern RL Algorithms: From PPO to GRPO and DPO

Traditional RL: Proximal Policy Optimization (PPO)

• How it works: Uses a policy model, reward model, and critic model to optimize actions.
• Challenges:
  • Resource-intensive (requires multiple models).
  • Hard to scale for complex tasks.

Direct Preference Optimization (DPO)

• How it works: Treats alignment as a classification problem on static preference data.
• Strengths:
  • Simpler than PPO (no RL loop).
  • Works well for single-step tasks (e.g., chatbot responses).
• Limitations:
  • No exploration (can’t discover new strategies).
  • Poor for multi-step reasoning (e.g., tool use, planning).

Group Relative Policy Optimization (GRPO)

• How it works: An optimized version of PPO that replaces the critic model with group-based scoring.
• Strengths:
  • More efficient than PPO (fewer models).
  • Works with verifiable rewards (e.g., unit tests, deterministic checks).
  • Better for agentic workflows (multi-step reasoning).

Reinforcement Learning from Verifiable Rewards (RLVR)

• Key Idea: Shifts focus from subjective scoring (e.g., human feedback) to explicit verification (e.g., code execution, tool correctness).
• Why it matters:
  • More reliable (avoids bias in human ratings).
  • Scalable (works with automated checks).

Building RL Environments: Key Components

1. Defining the Task

• The goal the agent must accomplish (e.g., sending an email, solving a math problem).
• Example (Workplace Assistant):

  User query: "Send an email to [email protected] with the subject 'Team Meeting' and body 'Let's meet tomorrow at 2pm.'"
  Expected tool call:
  email_send_email(
    recipient="[email protected]",
    subject="Team Meeting",
    body="Let's meet tomorrow at 2pm."
  )
  

2. Generating Task Data

• Real-world data: Curated prompts and ground-truth answers.
• Synthetic data: Generated using tools like NeMo Data Designer (e.g., 5,000 Python coding problems with unit tests).

3. Environment Design

An RL environment consists of:

• Agent: The AI model making decisions.
• Resources Server: The "world" the agent interacts with (e.g., tools, databases).
• Verification Logic: Determines success/failure (e.g., unit tests, reward functions).

Example: Agent Server Pseudocode

async def run(task_data):
    # 1. Initialize episode
    resource_server.seed_session(task_data)
    # 2. Run the agent loop
    response = self.responses(task_data.prompt, task_data.tools)
    # 3. Grade the result
    reward = resource_server.verify(response, task_data.ground_truth)
    return response, reward

async def responses(prompt, tools):
    conversation = prompt
    step = 0
    while step < max_steps:
        model_output = model_server.responses(conversation, tools)
        conversation.append(model_output)
        if model_output is text:
            break  # Model is done
        for tool_call in model_output.function_calls:
            result = resource_server.post(f"/{tool_call.name}", tool_call.arguments)
            conversation.append(result)
        step += 1
    return conversation

Example: Resources Server

class MyResourceServer(SimpleResourcesServer):
    async def seed_session(self, session_id, initial_data):
        # Initialize the sandbox for this rollout
        self.state[session_id] = initialize_environment(initial_data)
    
    async def my_custom_tool(self, session_id, tool_args):
        # Execute an action in the environment
        result = execute_action(self.state[session_id], tool_args)
        return result

4. Verification Logic

• Binary Rewards (0/1): Simple pass/fail checks (e.g., unit test passes).
• Continuous Rewards (-∞ to +∞): Granular feedback (e.g., partial credit for near-correct answers).
• Best Practices:
  • Deterministic checks (e.g., code execution) are more reliable than subjective scoring.
  • Sandboxed execution (e.g., running generated code in a safe environment).
  • LLM-as-a-judge (for open-ended tasks where exact matches are hard).

Tools for Building RL Workflows

1. NVIDIA NeMo Gym

• Purpose: Open-source library for building and scaling RL environments.
• Key Features:
  • Decouples rollout collection from training (scalable to thousands of parallel environments).
  • Standardizes trajectories (OpenAI Responses API format).
  • Manages resource lifecycles (e.g., session state, tool servers).
• Use Cases:
  • Training Nemotron 3 models.
  • Building scientific agents (e.g., hypothesis testing, simulations).

2. Unsloth

• Purpose: Efficient RL training framework for fine-tuning LLMs.
• Key Features:
  • Optimized for GRPO and PPO.
  • Works with NeMo Gym rollouts.
  • Supports PyTorch-native stacks.

3. NVIDIA NeMo RL

• Purpose: Training library for RL algorithms (e.g., GRPO).
• Key Features:
  • Integrates with NeMo Gym.
  • Scalable for large models.

4. Hugging Face TRL

• Purpose: Training library for RLHF (Reinforcement Learning from Human Feedback).
• Key Features:
  • Supports PPO, DPO, and other algorithms.
  • Works with NeMo Gym environments.

Real-World Applications of RL Environments

1. NVIDIA Nemotron 3

• Use Case: Training agentic AI models for multi-step reasoning.
• Approach:
  • SFT first (to ground the model).
  • RL refinement (using NeMo Gym environments).
  • Verification logic prioritizes correct trajectories (e.g., tool use, planning).

2. Scientific Agents (Edison Scientific + NVIDIA)

• Use Case: Training agents to explore hypotheses, run simulations, and analyze data.
• Approach:
  • NeMo Gym + Aviary Gym for domain-specific environments.
  • Deterministic feedback (e.g., simulation results).

3. Coding Assistants

• Use Case: Training models to write, debug, and optimize code.
• Approach:
  • Synthetic data generation (e.g., 5,000 Python problems with unit tests).
  • RL training (e.g., GRPO for verifiable correctness).

Getting Started with RL Environments

Step 1: Define Your Task

• What should the agent accomplish? (e.g., send emails, solve math problems, write code).
• What tools does it need? (e.g., databases, APIs, sandboxes).

Step 2: Design the Environment

• Agent: How will it generate actions? (e.g., text, tool calls).
• Resources Server: What external state does it interact with? (e.g., tools, databases).
• Verification Logic: How will success be measured? (e.g., unit tests, reward functions).

Step 3: Generate Rollouts

• Use NeMo Gym to run parallel environments at scale.
• Collect trajectories (sequences of states, actions, rewards).

Step 4: Train the Model

• Use Unsloth, NeMo RL, or Hugging Face TRL to optimize the policy.
• Iterate: generate rollouts → verify outcomes → update policy → re-evaluate.

Step 5: Deploy and Refine

• Test in real-world scenarios.
• Improve verification logic based on edge cases.
• Scale up with more data and compute.

The Future of RL in Agentic AI

The Era of Experience is just beginning. As RL environments become more sophisticated and accessible, we can expect:

• More autonomous agents (e.g., AI that plans, reasons, and uses tools).
• Better generalization (agents that adapt to new tasks without retraining).
• Scalable, verifiable AI (replacing subjective feedback with deterministic checks).

Tools like NeMo Gym, Unsloth, and NeMo RL are making it easier than ever to build these systems. The key takeaway? The environment defines the contract for intelligence—and mastering it is the next frontier in AI.

Extra links

• https://developer.nvidia.com/blog/training-scientific-agents-with-reinforcement-learning/
• https://huggingface.co/docs/trl/index
• https://github.com/NVIDIA/NeMo-Gym
• https://unsloth.ai/blog/grpo-training

L’article Reinforcement Learning environments and how to build them est apparu en premier sur Xavki.

SeaweedFS is an open-source, distributed file system designed for high scalability and fast file access. It efficiently stores billions of files with minimal metadata overhead (40 bytes per file) and supports features like replication, erasure coding, cloud integration, and POSIX-compatible directories. Built for simplicity, it offers O(1) disk read operations, making it ideal for small files while also handling large files via chunking. SeaweedFS includes tools like S3-compatible APIs, WebDAV, and Kubernetes CSI support, and is licensed under Apache 2.0.

What is SeaweedFS? 🌊📁

SeaweedFS is a distributed file system designed to store and serve billions of files efficiently while maintaining high performance. It is open-source (Apache 2.0 licensed) and optimized for small files, though it can handle large files via chunking. Unlike traditional file systems, SeaweedFS minimizes metadata overhead and avoids bottlenecks by distributing file metadata across volume servers rather than centralizing it.

Core Features ✨

1. High Scalability & Performance

• Stores billions of files with minimal overhead (just 40 bytes per file for metadata).
• O(1) disk read operations—files are accessed in a single disk read, making it extremely fast for small files.
• Linear scalability—add more volume servers to increase storage capacity without complex rebalancing.

2. Distributed Architecture

• Master Server: Manages volume locations (static metadata) and assigns file IDs.
• Volume Servers: Store actual file data and manage file metadata (volume ID, offset, size).
• Filer (Optional): Adds directory structures and POSIX attributes using external databases (MySQL, PostgreSQL, Redis, etc.).

3. Replication & Data Protection

• Configurable replication (e.g., same rack, different data center, or hybrid setups).
• Erasure coding for warm data (reduces storage costs while maintaining availability).
• Rack-aware and data-center-aware placement for fault tolerance.

4. Cloud & Hybrid Storage Integration

• Hot data (frequently accessed) stays on local servers for speed.
• Warm data (less frequently accessed) is offloaded to cloud storage (AWS S3, Google Cloud, Azure, etc.) with O(1) access time.
• Cost-efficient—minimizes cloud API costs by reducing unnecessary cloud access.

5. Multiple Access Methods

• S3-compatible API (works with AWS CLI, SDKs, and tools like MinIO).
• WebDAV (mount as a network drive on Windows/Mac).
• Hadoop/Spark/Flink integration (via Hadoop Compatible File System).
• FUSE support (mount as a local filesystem).
• REST API for direct HTTP uploads/downloads.

6. Enterprise-Grade Features

• Automatic failover (no single point of failure).
• TTL (Time-to-Live) for files (auto-deletion after expiration).
• Encryption (AES-256-GCM) for secure storage.
• Compression (automatic based on MIME type).
• Active-Active Replication (cross-cluster sync for high availability).

How SeaweedFS Works 🔧

1. File Storage & Retrieval

• Uploading a File

  • Client requests a file ID (fid) from the master server.
  • Master returns a volume ID + server URL.
  • Client uploads the file to the assigned volume server via HTTP.
  • File metadata (volume ID, offset, size) is stored on the volume server.

• Downloading a File

  • Client queries the master for the volume server location using the file’s volume ID.
  • Client retrieves the file directly from the volume server via HTTP.

2. Volume Management

• Each volume is 32GB and can store many small files.
• Volumes are statically assigned to files, making lookups O(1) (no complex hashing).
• Replication is applied at the volume level (e.g., replicate a volume across 3 servers).

3. Filer (Directory Support)

• The Filer is a separate service that adds directory structures.
• Uses external databases (MySQL, PostgreSQL, Redis, etc.) to store directory metadata.
• Supports POSIX attributes (permissions, timestamps, etc.).

Comparison with Other File Systems 🆚

| Feature | SeaweedFS | HDFS | GlusterFS | Ceph | MinIO |
|———————–|———————————–|——————————-|——————————-|——————————-|——————————-|
| Optimized For | Small files, high concurrency | Large files, batch processing | General-purpose | General-purpose | S3-compatible object storage |
| Metadata Overhead | 40 bytes per file | High (centralized namenode) | Moderate | High (CRUSH algorithm) | Moderate |
| Scalability | Linear, no rebalancing | Limited by namenode | Limited by hashing | Complex (CRUSH) | Limited by sharding |
| Cloud Integration | Yes (hot/warm tiering) | Limited | No | Yes | Yes (native) |
| POSIX Support | Yes (via Filer) | Yes | Yes | Yes | No |
| Erasure Coding | Yes (warm data only) | No | No | Yes | Yes (always on) |

Performance Benchmarks 🚀

• Write 1M x 1KB files (16 concurrent connections):
  • 15,708 requests/sec (16.2 MB/s).
• Read 1M files randomly (16 concurrent connections):
  • 47,019 requests/sec (48.5 MB/s).
• Mixed workload (GET/PUT/DELETE/STAT):
  • 3.3 GB/s throughput (550 objects/sec).

Getting Started 🛠️

1. Quick Setup (Single Node)

# Download the binary
wget https://github.com/seaweedfs/seaweedfs/releases/latest/download/weed_linux_amd64.tar.gz
tar -xvf weed_linux_amd64.tar.gz

# Start a mini cluster (master + volume + filer + S3)
./weed mini -dir=/data

• Access UIs:
  • Master: http://localhost:9333
  • Filer: http://localhost:8888
  • S3: http://localhost:8333

2. Production Setup (Multi-Node)

# Start master
./weed master

# Start volume servers
./weed volume -dir=/data1 -max=5 -master=localhost:9333 -port=8080
./weed volume -dir=/data2 -max=10 -master=localhost:9333 -port=8081

# Start filer (optional)
./weed filer -master=localhost:9333

3. Using S3 API

export AWS_ACCESS_KEY_ID=admin
export AWS_SECRET_ACCESS_KEY=key

# Start S3 gateway
./weed server -dir=/data -s3

# Use AWS CLI
aws s3 --endpoint=http://localhost:8333 ls

Use Cases 🎯

✅ Media Storage (images, videos, thumbnails)
✅ Log & Backup Storage (efficient small file handling)
✅ Hybrid Cloud Storage (local + cloud tiering)
✅ Kubernetes Persistent Storage (via CSI driver)
✅ S3-Compatible Object Storage (cheaper alternative to AWS S3)
✅ High-Performance File Serving (CDN-like speed for static assets)

Enterprise Edition 🏢

• Self-healing storage format (better data protection).
• Priority support & consulting.
• Advanced monitoring & management tools.
• Visit seaweedfs.com for details.

Community & Support 🤝

• GitHub: https://github.com/seaweedfs/seaweedfs
• Slack: SeaweedFS Slack
• Twitter: @seaweedfs
• Documentation: Wiki
• Sponsorship: Patreon

Why Choose SeaweedFS? 🏆

✔ Blazing fast (O(1) disk reads, optimized for small files).
✔ Simple & scalable (no complex rebalancing, just add servers).
✔ Cloud-friendly (hot/warm tiering, cost-efficient).
✔ Flexible (S3, WebDAV, FUSE, Hadoop, Kubernetes support).
✔ Open-source & enterprise-ready (Apache 2.0 + paid support).

Extra links

• https://github.com/seaweedfs/seaweedfs/wiki
• https://github.com/seaweedfs/seaweedfs/blob/master/README.md
• https://www.seaweedfs.com/
• https://github.com/seaweedfs/seaweedfs#quick-start

L’article GitHub – seaweedfs/seaweedfs est apparu en premier sur Xavki.

Kueue is an open-source, cloud-native job queueing system designed for Kubernetes, catering to batch, HPC, AI/ML, and similar workloads. It enables organizations to create multi-tenant batch services with resource quotas and hierarchical sharing, ensuring efficient resource allocation across teams. Kueue integrates seamlessly with Kubernetes tools like kube-scheduler and cluster-autoscaler, supporting both on-premises and cloud environments with dynamic and heterogeneous resources. The project welcomes contributions via GitHub Pull Requests.

What is Kueue? 🚀

Kueue is a Kubernetes-native job queueing system built to manage batch workloads, high-performance computing (HPC), AI/ML training, and other similar applications. It helps organizations optimize resource usage by enforcing quotas, prioritizing jobs, and ensuring fair sharing across multiple teams or tenants.

Key Features of Kueue ✨

• Multi-Tenancy & Resource Quotas

  • Define resource quotas (CPU, memory, GPUs) for teams or departments.
  • Enforce hierarchical sharing to prevent resource starvation and ensure fairness.
  • Example: Team A gets 50% of cluster resources, Team B gets 30%, and Team C gets 20%.

• Job Scheduling & Prioritization

  • Decides when jobs should wait (queueing) and when/where they should run (scheduling).
  • Works alongside Kubernetes’ kube-scheduler for optimal placement.
  • Supports preemption (higher-priority jobs can interrupt lower-priority ones).

• Dynamic & Heterogeneous Resource Support

  • Works in on-premises and cloud environments.
  • Handles heterogeneous resources (e.g., different GPU types, spot instances).
  • Integrates with cluster-autoscaler to dynamically provision resources as needed.

• Seamless Kubernetes Integration

  • Built to work with standard Kubernetes tools (e.g., kube-scheduler, cluster-autoscaler).
  • No need for custom schedulers—Kueue extends existing Kubernetes functionality.

• Open-Source & Community-Driven

  • Hosted on GitHub with a Pull Request-based contribution model.
  • Welcomes new contributors and users to improve the project.

How Kueue Works 🔧

1. Job Submission

   • Users submit batch jobs (e.g., AI training, data processing) to Kueue.
   • Jobs are assigned to queues based on team, priority, or resource requirements.

2. Quota Enforcement

   • Kueue checks if the job fits within the available quota for the team/tenant.
   • If resources are available, the job proceeds; otherwise, it waits in the queue.

3. Scheduling & Execution

   • Kueue works with kube-scheduler to place jobs on suitable nodes.
   • If resources are scarce, preemption may occur (higher-priority jobs take precedence).

4. Dynamic Scaling (Optional)

   • If integrated with cluster-autoscaler, Kueue can trigger auto-scaling to meet demand.

Use Cases 🎯

• AI/ML Training

  • Manage GPU/TPU resources efficiently across multiple teams.
  • Prevent resource hogging by enforcing quotas.

• High-Performance Computing (HPC)

  • Schedule large-scale simulations or data processing jobs.
  • Ensure fair sharing in shared HPC clusters.

• Batch Processing

  • Run ETL (Extract, Transform, Load) jobs at scale.
  • Optimize resource usage for cost savings.

• Multi-Tenant Kubernetes Clusters

  • Share a single cluster among multiple teams without conflicts.
  • Enforce resource limits to prevent noisy neighbors.

Getting Started with Kueue 🛠️

• Installation

  • Kueue can be installed via Helm or kubectl (YAML manifests).
  • Requires Kubernetes 1.22+.

• Configuration

  • Define resource quotas (e.g., CPU, memory, GPUs).
  • Set up queues for different teams or job types.

• Submitting Jobs

  • Jobs are submitted as Kubernetes Custom Resources (CRDs).
  • Example: kubectl apply -f job.yaml

• Monitoring & Logging

  • Use Kubernetes-native tools (e.g., kubectl get jobs, Prometheus, Grafana).

Why Choose Kueue? 🏆

✅ Built for Kubernetes – No need for external job schedulers.
✅ Multi-Tenancy Support – Fair resource sharing across teams.
✅ Dynamic & Cloud-Friendly – Works with autoscaling and heterogeneous resources.
✅ Open-Source & Extensible – Customize and contribute to the project.
✅ Cost-Effective – Optimize resource usage to reduce cloud spending.

Limitations & Considerations ⚠️

• Learning Curve – Requires familiarity with Kubernetes concepts.
• Not a Replacement for All Schedulers – Best suited for batch/HPC/AI workloads (not real-time apps).
• Community-Driven – Features depend on contributions and community adoption.

Extra links

• https://github.com/kubernetes-sigs/kueue
• https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
• https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
• https://helm.sh/docs/intro/install/

L’article Kueue est apparu en premier sur Xavki.

This article provides a step-by-step guide to deploying Traefik, a modern reverse proxy and load balancer, on a Talos Linux Kubernetes cluster using Helm. It covers prerequisites like a running Talos cluster, kubectl, and Helm, then walks through installing Gateway API CRDs, Traefik via Helm, configuring a Gateway, deploying a test application (whoami), setting up an HTTPRoute, and testing the setup. The guide ensures Traefik is properly integrated with Kubernetes’ Gateway API for managing external traffic.

Deploying Traefik on a Talos Kubernetes Cluster: A Step-by-Step Guide

This guide explains how to deploy Traefik, a popular cloud-native reverse proxy and load balancer, on a Talos Linux Kubernetes cluster using Helm and the Gateway API. Traefik simplifies routing external traffic to services in your cluster while providing features like load balancing, TLS termination, and observability.

Prerequisites

Before starting, ensure you have the following:

• A running Talos Kubernetes cluster (see Getting Started or Production Cluster guides).
• kubectl installed and configured to interact with your cluster.
• Helm installed locally (follow the Helm installation guide).

Verify your setup by running:

kubectl get nodes

Step 1: Install Gateway API CRDs and Traefik RBAC

The Gateway API (a Kubernetes-native way to manage ingress traffic) is not included by default in Kubernetes. This step installs:

• Custom Resource Definitions (CRDs) for Gateway, HTTPRoute, and other Gateway API resources.
• RBAC permissions for Traefik to manage these resources.

Run the following commands:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

Step 2: Install Traefik via Helm

Traefik is installed using its official Helm chart. Here’s how:

1. Create a values.yaml file to enable the Gateway API provider (Traefik’s integration with Kubernetes Gateway API):

   providers:
     kubernetesGateway:
       enabled: true
   

2. Add the Traefik Helm repository and install Traefik:

   helm repo add traefik https://traefik.github.io/charts
   helm repo update
   helm install traefik traefik/traefik -f values.yaml
   

   • When installed with kubernetesGateway enabled, Traefik automatically creates a GatewayClass named traefik, so you don’t need to define it manually.

Step 3: Create a Gateway

A Gateway defines how external traffic enters your cluster. In this example, we configure Traefik to listen for HTTP traffic on port 8000.

Create a gateway.yaml file:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 8000
      protocol: HTTP

Apply it:

kubectl apply -f gateway.yaml

Step 4: Deploy a Test Application

To verify Traefik’s routing, deploy a simple whoami application (a lightweight HTTP server that returns request details).

Create a whoami.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: whoami

Apply it:

kubectl apply -f whoami.yaml

Step 5: Create an HTTPRoute

An HTTPRoute maps incoming traffic from the Gateway to the whoami service.

Create an httproute.yaml file:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: whoami
          port: 80

Apply it:

kubectl apply -f httproute.yaml

Step 6: Test the Setup

Verify that Traefik is correctly routing traffic:

1. Forward the Traefik service locally to port 8000:

   kubectl port-forward svc/traefik 8000:8000
   

2. Send a test request to the whoami application:

   curl http://localhost:8000
   

   • You should see a response with details about the request (e.g., hostname, IP, headers).

Key Takeaways

• Traefik simplifies ingress management in Kubernetes by integrating with the Gateway API.
• Helm makes installation easy, with customizable configurations via values.yaml.
• Testing with whoami ensures your routing setup works before deploying real applications.
• Gateway API is the future of Kubernetes ingress, replacing older Ingress resources with a more flexible and powerful model.

For production use, consider:

• Enabling TLS termination for HTTPS traffic.
• Configuring load balancing and rate limiting.
• Monitoring Traefik with Prometheus and Grafana.

Extra links

• https://doc.traefik.io/traefik/providers/kubernetes-gateway/
• https://gateway-api.sigs.k8s.io/
• https://www.talos.dev/v1.6/introduction/getting-started/
• https://helm.sh/docs/intro/using_helm/

L’article Deploy Traefik as a Gateway API – Sidero Documentation est apparu en premier sur Xavki.

KWOK (pronounced /kwɔk/) is a toolkit designed to simulate large-scale Kubernetes clusters efficiently. It stands for Kubernetes WithOut Kubelet, meaning it mimics the behavior of Kubernetes nodes and pods without running the actual kubelet agent on each node. This approach drastically reduces resource consumption, enabling users to simulate thousands of nodes on a single machine like a laptop.

Key Features of KWOK

1. Lightweight and Resource-Efficient

• Simulates thousands of nodes and pods with minimal CPU and memory usage.
• Can reliably maintain 1,000 nodes and 100,000 pods on a single machine.
• Ideal for development, testing, and learning without needing cloud resources or physical hardware.

2. Fast Cluster Management

• Creates or deletes clusters and nodes instantly, without waiting for boot or provisioning.
• Capable of simulating 20 nodes or pods per second, making it highly efficient for rapid testing.

3. Compatibility with Kubernetes Ecosystem

• Works seamlessly with any tool or client that interacts with Kubernetes APIs, such as:
  • kubectl for cluster management.
  • helm for package management.
  • kui for visualizing Kubernetes resources.
• Ensures that existing workflows and automation scripts remain functional.

4. Portability Across Platforms

• No specific hardware or software requirements.
• Can be run using:
  • Pre-built Docker or Nerdctl images.
  • Binaries available for all major platforms (Linux, macOS, Windows).
• Easy to install and integrate into existing environments.

5. Flexibility for Testing and Development

• Allows customization of:
  • Node properties (e.g., types, labels, taints, capacities, conditions).
  • Pod behaviors and statuses (e.g., simulating crashes, resource constraints, or network issues).
• Enables testing of edge cases, failure scenarios, and scalability without risking real infrastructure.

Tools Provided by KWOK

1. kwok

• The core component responsible for simulating the lifecycle of:
  • Fake nodes (e.g., mimicking real node behaviors like heartbeats, status updates).
  • Pods (e.g., simulating pod creation, deletion, and status changes).
  • Other Kubernetes API resources (e.g., deployments, services).
• Ensures that the simulated environment behaves like a real Kubernetes cluster.

2. kwokctl

• A command-line interface (CLI) tool designed to:
  • Streamline the creation and management of clusters with simulated nodes.
  • Simplify tasks like cluster setup, teardown, and configuration.
  • Provide an easy-to-use interface for developers and testers.

Use Cases for KWOK

1. Development and Testing

• Developers can test their applications in a large-scale environment without needing access to cloud resources.
• Useful for validating scalability, performance, and resilience of Kubernetes workloads.

2. Learning and Education

• Ideal for Kubernetes beginners to experiment with cluster management, node behaviors, and pod lifecycles.
• Enables hands-on learning without the complexity of setting up real clusters.

3. CI/CD Pipelines

• Integrate KWOK into continuous integration/continuous deployment (CI/CD) pipelines to test Kubernetes manifests, Helm charts, or custom operators.
• Simulate failure scenarios (e.g., node crashes, network partitions) to validate application robustness.

4. Research and Experimentation

• Researchers can use KWOK to study Kubernetes behavior at scale without incurring high costs.
• Useful for experimenting with new Kubernetes features, plugins, or custom controllers in a controlled environment.

How to Get Started with KWOK

1. Installation

• Using Binaries: Download the latest release from the KWOK GitHub repository and add it to your PATH.
• Using Docker/Nerdctl: Pull the pre-built image and run it in a container.

2. Creating a Cluster

• Use kwokctl to create a cluster with simulated nodes:

  kwokctl create cluster --name my-cluster
  

• Verify the cluster status using kubectl:

  kubectl get nodes
  

3. Simulating Workloads

• Deploy pods, deployments, or other Kubernetes resources as you would in a real cluster.
• Use kwok to simulate node or pod behaviors (e.g., marking nodes as NotReady).

4. Customizing Simulations

• Configure node properties (e.g., labels, taints) or pod behaviors (e.g., crashes) using YAML files or CLI flags.
• Test edge cases by simulating resource constraints, network issues, or node failures.

Community and Contribution

1. Getting Involved

• Join the Kubernetes Slack workspace and participate in:
  • #kwok for general usage discussions.
  • #kwok-dev for development-related conversations.
• Contribute to the project by:
  • Opening issues or pull requests on the KWOK GitHub repository.
  • Participating in discussions or reviewing documentation.

2. Governance

• KWOK is part of the Kubernetes SIGs (Special Interest Groups) community.
• Participation is governed by the Kubernetes Code of Conduct.

Limitations and Considerations

• Not a Replacement for Real Clusters: KWOK is designed for simulation and testing, not for production workloads.
• Limited Real-World Behavior: While KWOK mimics node and pod behaviors, it may not replicate all real-world scenarios (e.g., hardware failures, network latency).
• API Compatibility: KWOK focuses on Kubernetes API compatibility but may not support all custom resources or third-party integrations.

Conclusion

KWOK is a powerful toolkit for anyone working with Kubernetes who needs to simulate large-scale clusters efficiently. Whether you’re a developer, tester, researcher, or learner, KWOK provides a low-resource, fast, and flexible way to experiment with Kubernetes without the overhead of real infrastructure. Its compatibility with existing Kubernetes tools and ease of use make it an invaluable addition to the Kubernetes ecosystem.

L’article GitHub – kubernetes-sigs/kwok: Kubernetes WithOut Kubelet – Simulates thousands of Nodes and Clusters. est apparu en premier sur Xavki.

La version précédente a été vu plusieurs centaines de milliers de fois et c’est donc délicat de renouveler quelque chose que l’on a déjà fait. Donc on va essayer de donner le meilleur pour donner un coup de boost à la fois technique et pédagogique. Depuis cette précédente version qui date de plus de 4ans, j’ai pas mal découvert de nouvelles choses et j’ai aussi pu m’essayer à former vraiment pas mal de personnes.

Apprendre aux autres à apprendre un technologie et surtout à la comprendre c’est vraiment une de mes passions fortes. J’ai la chance d’avoir pu pratiquer cet exercice devant des publics variés et c’est là où l’on apprend soi-même. Comment faire accrocher les gens (je en parle pas de donner envie à des élèves amis plutôt de trouver les mots et l’angle qui passionera les gens et leur donneront le déclic) et faire en sorte que de doute façon ils perceront par eux-même les plus profonds secrets d’une techno.

Bref, en cette fin d’année 2024, je me suis dit “bon on va remettre ça et on va reposer tout du mieux que l’on peut”.

Préambule à kubernetes ? pourquoi on en est là ??

Dans ce cadre j’ai même décidé de faire une vidéo tutoriel de type préambule. Elle permet de resituer le pourquoi kubernetes en est là de nos jours ? Pourquoi il faut l’avoir dans sa trousse à outil de devops ?

Certains se serviront de cette formation pour des certifications mais celles-ci ne sont qu’un projet pour atteindre un objectif : se sentir à l’aise avec cette technologie pour l’intégrer dans sa carrière.

Voici donc cette vidéo qui j’espère vous donnera envie de percer et posera les bases de votre formation pour débuter avec kubernetes.

Kubernetes avec un peu d’histoire

Et donc après avoir posé ces bases, je vous propose de fair eun peu d’histoire et de comprendre cette communauté autour de kubernetes. Encore une vidéo qui n’a pas un lien direct dans la technologie mais qui prépare le terrain.

En gros cette seconde vidéo, revient sur les solutions qu’apporte kubernetes.

Voici donc pour les deux premières vidéos. Nous y allons tranquillement avec la volonté de bien poser tout cela pour acquérir des compétences solides et ainsi transformer notre carrière.

Car comme je peux vous le dire que l’on aime ou non kubernetes, il devient et est devenu intégré dans de nombreuses entreprises et ce n’est pas fini. C’est ainsi et c’est pourquoi vous devez en tant que devops, sre, sysadmin oui encore dev acquérir des connaissances je pense.

L’article Mise à jour de la formation kubernetes, c’est partie !!! est apparu en premier sur Xavki.

Je suis tombé dans le cloud public

Hé bingo !!! J’ai craqué. Infomaniak m’a proposé de bénéficier d’un compte chez eux et j’ai cédé à la tentation. L’idée a été aussi de se dire comment fusionner des choses que j’ai trouvé intéressantes au cours des dernières années. Genre Consul c’est un outil bien sympa.

Au début, je me suis dit ok mais faut pas que ça soit trop couteux en temps. Et puis finalement de fil en aiguille ben là encore j’ai craqué un peu je pense. Car je me suis dit, pourquoi ne pas refaire le coup de la playlist “devenir devops” avec un truc qui explique sommairement chaque outil qui entre en jeu et l’explication de la conception au fil de la playlist.

Au final, pour le moment on a peut être fait la moitié de l’infrastructure et on en est à 50 tutoriels cloud.

Mais comme j’ai pas réussi à trouver quelque chose de similaire sur le web je me suis motiver pour le faire.

Et des outils sympas

Forcément qui dit infrastructure sympa dit outil sympas… mais ça doit rester efficace et simple (autant que possible).

Alors que va-t-on y trouver ?

• terraform : pour le provisionning
• ansible : pour la configuration
• openvpn : comme petit vpn
• consul : pour plein de choses cool (dns interne, auto-configuration, registry de services…)
• victoriametrics : pour la stack de monitoring (aucune autre ne fait le poids ahaha)
• grafana : pour la visualisation des métriques des logs et des traces
• karma, alertmanager : pour l’alerting
• vector : pour la collecte des logs (j’étais partie sur fluentbit mais bon l’avenir c’est vector)
• loki : pour stocker les logs (on verra pour victorialogs plus tard)
• tempo : pour les traces mais c’est inutile dans notre cas
• mattermost : pour avoir notre petit slack perso
• postgresql : pour le mattermost (et peut êtr epour le keycloak)
• gitlab : pour avoir notre propre isntance et stocker nos codes pour ntore future startup 😉
• traefik : pour le routing et les certificats tls Let’s Encrypt.

Et puis, et puis… kubernetes et son inclusion de manière transparente dans notre infra avec consul-catalog, kube-router etc…

Bref on va bien se marrer et si vous n’êtes pas abonné faites-le car ça va swinguer.

La playlist est ici !!!

L’article Une infrastructure cloud en mode tutoriel de A à Z est apparu en premier sur Xavki.

Partons du contexte actuel

L’informatique est un domaine qui explose à vitesse fulgurante. Le web vient juste de prendre +25% de traffic par rapport à l’année précédente selon Cloudflare. Doit-on s’en réjouir ? pas trop pour l’avenir de l’humanité mais c’est ainsi parfois il faut accepté la fatalité pour tenter de la compenser.

D’un point de vue impact, +25% sur le traffic ne pose pas de problème direct (réseau…) et de la part direct de la consommation d’énergie. Non, c’est ce que cela déclenche en cascade derrière… les logs, les métriques… maintenant les traces…

Donc non, ce n’est pas sans impact contrairement à ce que l’on peut se dire en première lecture. Ajoutons à cela que ce traffic représente qu’une activité support à l’industrie de la sur-consommation, bien le signale devrait être presque alarmant.

Bref peu importe, on a fait nos choix de société comme dirait l’autre.

Maintenant zoomons

La tendance actuelle est à l’observabilité. Personnellement j’adore cela mais là encore il faut quand même se poser 2 secondes.

Il faut du monitoring c’est clair, des logs aussi… et à nuancer en fonction du besoin.

Des traces, ah là déjà, à l’échelle globale des entreprises (petites, moyennes et grandes) cela est déjà à nuancer beaucoup plus. Pour certaines oui, pour d’autres c’est complètement overkill et c’est cela pour beaucoup beaucoup d’entreprises malgré tout.

Finalement, c’est le rôle premier de l’Ingénieur de savoir mettre ce qu’il faut là où il faut (pas plus pas moins).

On pourrait même se dire que pousser à al production en masse de ces métriques, logs et traces ne sert-il pas les producteurs de SaaS. Car les gros volumes posent plus de difficultés à manager.

Donc dans ce contexte, il faut une technologie qui soit disruptive comme on dit… c’est à dire qui révolutionne sont domaine d’une manière ou d’une autre.

Et c’est un peu le cas de Victoria Metrics !!!

VictoriaMetrics, l’ovni dans l’écosystème des métriques

Alors en guise d’exemple, je pourrais vous citer plein de chiffres que j’ai pu découvrir à droite et à gauche (7 fois moins de ram que prometheus, 10 fois moins de stockage que influxdb…). Mais il suffit de regarder les profils des entreprises utilisatrices pour bien comprendre que la performance n’est pas un problème et même totalement sont point fort.

A titre perso, il suffit simplement de me dire que victoriametrics s’est inspiré de l’architecture de clickhouse pour se spécialiser encore plus dans la métrique et je suis convaincu direct. J’ai pratiqué clickhouse mais regardez ce tableau et vous comprendrez que l’on est là aussi sur un ovni.

Alors la perf c’est bien mais souvent ça fini en truc pas facile à manager et maintenir pour de petites entreprises ou des boites moins tech, ne disposant pas des compétences (en nombre, en finance, en connaissances…).

Ben c’est là où c’est finalement encore plus magique.

VictoriaMetrics dispose de 2 modes :

• le single binaire avec un all in one qui permet à la fois de lire, écrire et stocker sans réfléchir et avec des performances déjà assez folles pour de très très nombreuses entreprises (l’idée est de vous dissuader de passer au mode extrème pour rien).
• le mode cluster… en microservices. Un binaire pour chaque fonction : lecture, écriture, stockage etc… Ce mode permet en plus de la haute disponibilité avec des performances de dingos.

Attention edit : à nuancer il ne permet pas une haute dispo complète. VictoriaMetrics ne permet pas la perte d’un serveur ou des disks. Il faut avoir accès à du stockage distribué pour le moment ou mettre en place les backups pour accepter une restauration (une perte de données sera certainement possible).

… à côté ils ont aussi un mode SaaS managé si vous le souhaitez.

Et permettre ces choix est fondamental je trouve.

Donc vous l’avez compris, pour moi, VictoriaMetrics permet de mitiger les problèmes cités en début d’article.

Et VictoriaMetrics relève des défis jamais creusés

Premier défi c’est l’interropérabilité comme certaines personnes. A savoir, la possibilité de prendre différents formats en entrée comme :

• openmetrics
• influxdb
• graphite
• http
• csv
• …

Second défi, les grandes cardinalités, vous savez le multiplicateur qui fait que l’on peut éclater un prometheus sans forcer. A savoir les différentes combinaisons des labels et nom des métriques qui augmentent considérablement le nombre de données à brasser pour obtenir des résultats et les stocker facilement :

<métrique> x <label1> x <label2> x <label3> x … x <labeln>

A ce jeu c’est de loin le plus fort encore une fois.

Conclusion

Voici donc pour la présentation. Vous pouvez le retrouver sur la chaine Xavki ou sur cette page en mode tutoriels. Et la bonne news finale c’est aussi que victoriametrics travaille sur VictoriaLogs boom !!!

L’article VictoriaMetrics : comment réduire à néan prometheus et thanos à la fois :) est apparu en premier sur Xavki.

Rien de fou mais juste un assemblage de ce que j’ai vu de mieux dans mes expériences professionnelles précédentes et aussi ma veille. Cela ne veut pas dire que c’est le mieux mais disons que ça permet de se faire une idée sur les choses et d’en discuter.

Bien sûr l’objectif va être de vous partager cela sous forme de tutoriels avec une approche pas à pas comme d’habitude à la fois sur la manière dont les choses sont pensées et sur les minimum requis pour les outils utilisés.

Et pour le moment, il y a déjà pas mal d’outils dans cette infrastructure :

• openvpn : pour ne pas accéder à ces machines via des ip publiques
• terraform : pour le provisionning
• ansible : pour la configuration
• openstack : pour son utilisation (merci à infomaniak)
• consul : la registry des serveurs et services fournissant les dns et l’auto-configuration de traefik
• traefik : le reverse-proxy français et qui gère le Let’s Encrypt
• victoriametrics : le stockage de métriques le plus performant du secteur
• loki : pour la centralisation de logs
• tempo : pour la centralisation des traces
• grafana : pour al visualisation
• gitlab : pour le dépôt de code et bien plus (on déploie bien sûr une instance auto-hébergée)
• alertmanager/karma : pour l’alerting généré par vmalert

Et encore beaucoup d’autres choses à venir (webmail, chat, wiki…).

Donc vous comprenez pourquoi pour le moment on me voit moins sur la chaine mais pour autant je me tourne vraiment pas les pouces.

Bref, comme toujours cela est venu d’un truc qui m’a tourné dans la tête. Pourquoi on ne trouve pas ce genre de chose sur le web. Pourquoi pas de tutos alors que plein de gens seraient 10k fois mieux placés à réaliser ce type de projet. Mieux certaines sociétés y trouveraient un intérêt financier. Je pense que c’est là où parfois l’opensource se perd.

Alors tout cela arrive très bientôt. Laissez moi juste le temps pour affiner tout cela est en faire un rendu correct.

Quelques copies d’écrans

Donc abonnez-vous à la chaine si ce n’est pas déjà fait car lorsque ça va sortir ça va être bien sympa j’espère !!!

L’article Infrastructure automatisée et des services fondamentaux est apparu en premier sur Xavki.

Mais voilà, vous avez su insister, Zabbix a aussi bien évolué et faire une “formation” permettrait au moins de mieux pouvoir soutenir les points de comparaisons avec d’autres outils déjà présents sur la chaine. Comme par exemple prometheus que vous pouvez déjà retrouver dans une playlist de presque 60 tutos gratuits (et bientôt VictoriaMetrics qui me parait tellement porteur).

Donc nous voici partie pour plusieurs vidéos Zabbix pour les débutants dont je fais partie. Aujourd’hui nous découvrirons Zabbix c’est quoi, quelques définitions à connaître et enfin l’installation d’un serveur.

C’est quoi Zabbix ?

Zabbix a été créé en Alexei Vladishev avec une toute première version en 2001. S’en est suivi la création d’une société du même nom en 2005. Cela n’empêche pas Zabbix d’être un outil de monitoring opensource, principalement basé sur du C et du php.

A la différence de prometheus qui est principalement un moteur de base de données et de règles avec une interface graphique rudimentaire (on se penche toujours vers grafana pour disposer d’une interface graphique), Zabbix lui ne dispose pas de base de données mais permet de se connecter à mariadb, postgresql et d’autres. En revanche Zabbix c’est un ensemble de service dont un serveur responsable du stockage avec l’outil de base de données choisi et aussi une interface graphique… bien sûr on y retrouve de nombreux services de types monitoring : alerting, templating, dashboard, découvertes de serveurs à monitorer, proxies…

Bien sûr vous pouvez retrouver les classiques :

• le github : https://github.com/zabbix/zabbix
• le site officiel : https://www.zabbix.com/

Et petit clin d’oeil à Steve si vous être en France :

• la société IZI-IT sépcialiste de Zabbix : https://izi-it.io/
• et le channel discord zabbix france : https://discord.com/invite/hvauXEQ

Pour ce qui est des tutos zabbix et des éléments de support qui vont avec vous les retrouverez ici :

• dépôt gitlab xavki
• playlist youtube zabbix

Zabbix fonctionne sur la plupart des système d’exploitation, vous ne devriez pas avoir de problème de ce côté là.

Les principaux concurrents de Zabbix :

• prometheus
• nagios
• centreon
• victoria metrics
• …

Néanmoins à la différence de prometheus, Zabbix fonctionne en mode push c’est à dire que des agents envoient leurs données sur el serveur central (prometheus lui va chercher la donnée en la scrapant).

Quelques définitions et concepts

J’aime bien faire cela dans un peu toutes les playlists, poser les définitions. J’espère ne pas dénaturer les choses en simplifiant mais cela permet à toutes et à tous d’utiliser le même langage dans la suite des vidéos.

• le serveur : c’est lui qui a la charge de gérer la base de données (mysql, mariadb, postgresql, oracle…) et la plupart des processus de calculs.

• le frontend : avec soit un apache ou un nginx, le frontend permet de fournir l’interface graphique en communiquant avec le serveur (backend).

• les agents : actif ou non (on verrra cela plus tard), ils ont la charge de collecter les métriques sur les serveurs cibles (généralement par le biais de scripts), on peut aussi parler de sonde Zabbix.

• une macro : terme un peu trompeur qui est finalement une variable générique, par exemple {$HOSTNAME}.

• le Low Level Discovery (LLD) : mécanisme de découverte d’éléments à monitorer (par exemple des interfaces réseaux)

• un template : terme un peu trompeur car il englobe l’ensemble des éléments pouvant être générique et contenant des variables, par exemple les métriques collectées pour un profil de host (linux ou autre…). Ces templates permettent de configurer zabbix sur certains aspects une seule fois sans avoir à répéter pour chaque cible l’opération.

• un trigger : seuil pour une métrique qui déclenchera une action.

• un webhook : une action d’envoi d’un signal vers une applicatif externe.

• le proxy zabbix : agent intermédiaire spécialisé dans la collecte de métrique sur des devices ne pouvant pas accueillir un agent standard.

Installation du serveur Zabbix couplé à un serveur Postgresql

Alors comme nous l’avons évoqué plus haut dans cet article, nous allons utiliser Postgresql avec Zabbix. Il va donc falloir dans un premier temps installer un serveur postgresql. Dans l’idéal et dans un environnement de production, il faudrait avoir de la haute disponibilité ou au moins avoir des backups sérieux pour éviter trop de perte de données en cas de crash de la base de données.

Passons donc à l’installation de postgresql :

apt install -y postgresql
pg_ctlcluster 14 main start

Ensuite on va créer le user et la database :

sudo -u postgres psql -c "create database zabbix;"
sudo -u postgres psql -c "create user zabbix with password 'password';"
sudo -u postgres psql -c "grant ALL privileges on database zabbix to zabbix;"

Puis nous allons permettre la connexion depuis l’extérieur :

echo "listen_addresses = '*'" >> /etc/postgresql/14/main/postgresql.conf
echo "host zabbix all 192.168.0.1/16 md5" >> /etc/postgresql/14/main/pg_hba.conf
systemctl restart postgresql

Donc avec ça on peut à la fois utiliser un serveur postgres externe ou sur la même machine. Dans mon cas, je vais utiliser un serveur externe.

Maintenant passons à l’installation du serveur zabbix :

wget https://repo.zabbix.com/zabbix/6.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.0-4+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_6.0-4+ubuntu22.04_all.deb sudo apt update -qq 2>&1 >/dev/null
sudo apt install -y zabbix-server-pgsql zabbix-frontend-php php8.1-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent postgresql-client
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | PGPASSWORD="password" psql -h zpg1 -U zabbix zabbix
sed -i s/"#.*server_name.*"/" server_name zabbix.xavki; "/g /etc/zabbix/nginx.conf
echo "DBPassword=password" >> /etc/zabbix/zabbix_server.conf echo "DBHost=zpg1" >> /etc/zabbix/zabbix_server.conf
systemctl restart zabbix-server zabbix-agent nginx php8.1-fpm
systemctl enable zabbix-server zabbix-agent nginx php8.1-fpm

Dans mon cas de figure, le dns utilisé est zabbix.xavki. La base de données se situe sur le serveur zpg1. Vous pouvez donc ouvrir votre navigateur et vous rendre sur cette url.

Il vous restera ensuite à confirmer les coordonnées de la base de données au frontend.

L’article Les tutos pour débuter avec Zabbix c’est partie !!! est apparu en premier sur Xavki.

Avec la production d’un tutoriel docker, je me suis posé un peu plus de question… Mais quelle est la différence entre docker attach et docker exec ? Est-ce que cette différence est importante ??

FInalement, je considère cette différence comme peu importante… si ce n’est qu’elle permet de mieux comprendre comment on interagit avec docker (ou d’autres outils comme podman). Et ça c’est cool !!!

Bon venons-en justement à ce sujet.

Docker exec il fait quoi ?

La commande exec de docker est souvent utilisé par les débutants et perso c’est celle que je préfère. Mais finalement ques-ce qui se passe derrière ?

Si vous voulez trouver un bon article plus détaillé, je vous invite à lire cette article : Containers 101: attach vs. exec – what’s the difference?

Alors si vous avez suivi les tutoriels docker précédents, cela est assez simple à comprendre. Souvenez vous pour débuter nous avions vu la notion de namespaces réseau notamment.

Ces namespaces permettent de faire tourner un processus linux dans un environnement donné et précis (réseau, hostname, user, montage…).

Et là où le exec est magique c’est que cette commande ne fait que créer un second conteneur… dans exactement le même contexte (environnement). Ainsi, on a vraiment l’impression d’être dans le conteneur comme l’on dit souvent. Du coup c’est un abus de langage car on est à côté dans un autre conteneur mais juste dans le même réseau, le même hostname, user…

Donc ça c’est pour le docker exec… Passons à docker attach qui peut plaire aux fans de linux :).

Docker attach le man in the middle du conteneur !!!

Attach lui est assez marrant. Sur un processus donné sous linux, vous disposez de stdin, stdout, stderr… d’ailleurs vous pouvez les retrouver dans /proc sous les identifiants de vos processus. En gros c’est la libIO de linux qui permet de gérer ces flux.

Le conteneur c’est un processus comme un autre sur votre machine. Il dispose donc de ses propres flux précités.

Imaginez donc que vous soyez en mesure d’écouter le stdout du conteneur… Vous seriez en mesure de voir les sorties du processus du conteneur.

Imaginez également que vous soyez connecté à stdin du conteneur (processus)… idem vous seriez en mesure d’envoyer des commandes au processus de ce conteneur…

Bingo c’est docker attach, il permet de streamer tout ce qui sort et tout ce qui rentre dans le processus du conteneur docker.

Donc la finalité de attach ou de exec est à peu près la même pour debuguer, tester etc. Les méthodes sont par contre assez différentes. A vous de choisir la votre.

L’article Attach ou Exec ??? est apparu en premier sur Xavki.

Mais finalement comment créer une image docker ? Quelles bonnes pratiques mettre en oeuvre ?

Créer une image par un commit de conteneur, c’est possible ??!!

Alors autant le dire tout de suite c’est possible mais ce n’est pas une grande idée. En effet, comme nous allons le voir par la suite il vaut mieux privilégier les Dockerfile. Ces fichiers descriptifs de la constitution d’une image permettent de les créer et s’agissant de fichiers, on peut donc les gitter et ainsi les versionner et les partager. Ce n’est pas le cas avec les commit de conteneurs.

Néanmoins, cela reste très intéressant de savoir que l’on peut partir d’un conteneur docker pour créer une image. Parfois, cela peut même vous enlever une sacrée épingle du pied.

Alors comment faire ?

Vous devez vous en douter, la CLI de docker va nous fournir une commande magique : docker commit.

Donc partons d’un conteneur existant :

docker run -d --name c1 nginx:latest

Puis on va faire une modification anodine dedans :

docker exec -ti c1 bash
touch /xavki.txt

Maintenant resortons du conteneur puis créons une image à l’aide de la commande docker commit. Pour cela, il nous faut l’id du conteneur et on définira un nom d’image et un tag.

docker commit <id_conteneur> <nom_image:tag_image>
docker commit a5zea5ef myimage:v1.0.0

Et maintenant vous pouvez vérifier que votre moteur docker local trouve bien cette nouvelle image docker avec un docker ps.

Puis vous pouvez lancer un nouveau conteneur avec cette image :

docker run -d --name c2 myimage:v1.0.0

Et vous rendre dedans pour lancer un ls du fichier que nous avions créé dansnotre conteneur c1 et donc présent de base dans notre nouvelle image.

docker exec -ti c1 ls /xavki.txt

Bingo !!! Vous venez de créer votre première image docker !!!

Comme je vous disez il vaut mieux utiliser le Dockerfile mais néanmoins docker commit est assez pratique :

• pour débuguer
• pour tester
• pour recréer une image quand on a perdu le Dockerfile
• … bref pour bidouiller

Mais le mieux reste le Dockerfile

Layers d’une image docker

Les images docker repose sur le principe de base des images et des conteneurs : le Copy On Write

C’est quoi ce truc ??

Considérons qu’une image pour être crée doit se faire au fur et à mesure d’instruction (cf ci-dessous avec le Dockerfile). Au fur et à mesure que l’on joue ces instructions on empile des couches successivent, les unes sur les autres.

C’est ce que l’on appelle les layers. Une fois que l’on a dit se principe il est facile de comprendre une différence importante entre une image et un conteneur d’un point de vue filesystème (en plus du principe de base de processus que l’on a déjà vu précédemment).

Une image docker est une succession de couches en Lecture seule. Et un conteneur est un layer en écriture sur ces couches en lecture. D’où le docker commit qui est finalement la validation (le commit) de cette couche en écriture pour le rendre en lecture seul et ainsi constituer une image.

Pour mieux s’en rendre compte il existe une commande peu utilisé : docker diff <nom_conteneur>. Avec cette commande lancé sur un conteneur vous pourrez voir les modifications qui votn être commitées. Magique ;).

Comment créer une image docker avec un Dockerfile ?

Alors une fois que l’on a dit cela on se dit ok mais c’est quoi ces instructions ? C’est la que l’on retrouve le Dockerfile (avec un D majuscule hein 😉 ).

Un dockerfile c’est un fichier plat avec en début de ligne une instruction écrite en majuscule puis un espace suivi de ces paramètres par exemple :

RUN apt install -y git

Donc maintenant voyons les principales instructions que vous pouvez retrouver facilement dans la documentation docker ici :

• RUN : lancer des commandes shell
• FROM déclarer une image source
• ARG déclarer une variable utilisable uniquement durant le build docker
• ENV : délcarer une variable d’environnement utilisable durant le build et lors de l’utilisation du conteneur
• COPY : pour copier des fichiers et des répertoires de l’extérieur de l’image (ou d’une autre image) dans l’image en cours de création
• ADD : idem COPY mais avec la possiblité de télécharger des documents par url
• CMD : définitions des options de la commandes principales du conteneurs (processus du conteneur)
• ENTRYPOINT : définition de la commande principale du conteneur issu de l’image

Par exemple :

FROM python@sha256:2659ee0e84fab5bd62a4d9cbe5b6750285e79d6d6ec00d8e128352dad956f096

# Labels
LABEL version=v1.0.0
LABEL owner=xavki-app

# Env vars
ENV FLASK_APP=app.py
ENV FLASK_ENV=dev

ARG APP_USER=xavki

# Create a dedicated user

RUN adduser -D ${APP_USER}

# Directory
WORKDIR /app

# Copy & install requirements
RUN apk add --no-cache curl=8.0.1-r0

USER ${APP_USER}:${APP_USER}
COPY --chown=xavki  requirements.txt requirements.txt
RUN pip3 install --no-cache-dir -r requirements.txt

# Copy all files
COPY --chown=xavki . .

# Expose port
EXPOSE 5000

CMD ["python", "-m", "flask", "run", "--host=0.0.0.0"]

Et je vous propose de mettre en place de bonnes pratiques pour créer vos images docker

• Choisir une image légère && minimalist (multistage plus tard)
• Définir précisément le tag de image ou le digest
• Suppression des caches APT, APK… && /var/cache/xxx
• Grouper les layers (surtout pour les installations et utiliser && )
• Utiliser .dockerignore (secrets, fichiers sensibles et inutiles…)
• Utiliser plutôt COPY à la place de ADD (datas exterieures)
• Créer un utilisateur par défaut
• Utiliser cet utilisateur aux bons endroits USER && CMD
• Supprimer éventuellement des éléments installés (avec précision)
• Eviter à tout prix le tag latest
• Vérifier le FROM (registries vérifiées, image maintenue, contrôle des couches)
• Ou pousser ? registry publique ou privée
• Eviter le monolith : bases de données + apps + statics…
• Utiliser un linter (hadolint, clair…) – docker run –rm -i hadolint/hadolint < Dockerfile
• Ne pas pousser des secrets dedans (mot de passe, clefs, certificats…)
• Variabiliser qunad même…
• Eviter les outils de debug qui souvent sont néfastes pour la sécu (telnet, tcpdump, netcat…)
• Définir des règles sur les labels (standardiser: équipes, langage, version…)
• Vérifier la vulnérabilité (Clair, Falco…)
• Méfiez vous des COPY vraiment…
• Définir un WORKDIR
• Vérifier la possiblité du multistage-build
• Versionner c’est bien… et maintenir c’est mieux !!!

Mais quand même la commande pour créer notre image ??

Alors on a un dockerfile mais comment créer une image ?

C’est très simple avec docker build. Cette commande est assez magique et contient notamment de très bonnes fonctionnalités de cache par défaut pour éviter de reconstruire certains layers déjà existants.

Basiquement on peut lancer :

docker build -t myimage:v.1.0.0 .

Et voilà !!! Vous avez maintenant localement votre image myimage avec le tag v1.0.0

Et bien sûr pour découvrir les plus de 1500 tutos, rendez-vous sur la chaine Xavki

L’article Création d’une image docker: principes et bonnes pratiques est apparu en premier sur Xavki.

Eh oui on va installer un bridge, 2 namespaces et 2 vethernets.

Alors le but c’est de créer un script qui va nous permettre de créer la structure suivante :

Et on va faire original, on va créer un bridge nommé Xavki0 !! La gloire éternel merci Linux !!

Première choses les variables de tout ce petit monde…

Alors voici les variables que l’on définit dans la partie haute de notre script bash :

#!/usr/bin/bash

## Variables Namespace
NS1="x1"
NS2="x2"

## Variables vethernet
VETH1="xeth1"
VETH2="xeth2"

## Variables interface des conteneurs
VPEER1="xpeer1"
VPEER2="xpeer2"

# Variables ip des conteneurs
VPEER_ADDR1="10.11.0.10"
VPEER_ADDR2="10.11.0.20"

## Variables du bridge
BR_ADDR="10.11.0.1"
BR_DEV="xavki0"

Première chose les 2 namespaces x1 et x2 qui sont les deux boites isolées d’un point de vue réseau. Et c’est important, aujourd’hui on ne voit que l’isolation réseau. Donc on va considérer que cela pourrait s’apparenter à 2 conteneurs si on ne regarde que la partie réseau.

Ensuite pour connecter ces deux namespaces à notre bridge, il faut un cable. Ce cable, il est virtuellement forcément, ce sont ce que l’on appelle des vethernets : xeth1 et xeth2.

Et pour chaque namespace comme dans nos conteneurs, il nous faut une interface virtuelle les vpeers : xpeer1 et xpeer2.

Pour chacune de ces interfaces, il nous faut une ip pour chaque : 10.11.0.10 et 10.11.0.20.

Bon et enfin, il nous faut un bridge xavki0 et l’adresse de ce bridge, en l’occurence l’ip1 de notre cidr (range d’ip).

Maintenant créons tout ces éléments réseaux

## Création des namespaces
ip netns add $NS1
ip netns add $NS2

##Création des vethernet (cables) & interfaces
ip link add ${VETH1} type veth peer name ${VPEER1}
ip link add ${VETH2} type veth peer name ${VPEER2}

## Ajout des interfaces au namespace
ip link set ${VPEER1} netns ${NS1}
ip link set ${VPEER2} netns ${NS2}

## Activation des vethernet
ip link set ${VETH1} up
ip link set ${VETH2} up

A noter particulièrement que pour la création des vethernets on précise le nim mais aussi les vpeers. nos fameuses interfaces vituelles de chaque namespace. Ensuite, on va ajouter ces vpeers à nos namespaces. Et enfin on va activer nos vethernet.

Vous remarquerez que l’on a pas tout créé 😉

Ajout des ip dans les namespaces

Alors pour l’instant c’est bien tout cela mais on a pas d’ip dans nos namespaces : ni loopback (127.0.0.1), ni nos fameuses ip définies dans nos variables au début. Bon ben go…

## Activation des interfaces dans les namespaces
ip netns exec ${NS1} ip link set lo up
ip netns exec ${NS2} ip link set lo up
ip netns exec ${NS1} ip link set ${VPEER1} up
ip netns exec ${NS2} ip link set ${VPEER2} up

Et là vous voyez que notre commande ip avec son argument netns ne sert pas qu’à créer des namespaces… Non en fait elle permet de lancer les commandes de votre choix dans le contexte du namespace que vous allez préciser. On pourrait lancer un LS mais là on décide d’activer nos fameuses ip… Donc pour vérifier on pourrait passer un “ip a” plutôt que ip link set…

Maintenant ces ip on va les attribuer à nos interfaces de chacun de nos namespaces :

## Ajout des ip pour chaque interface
ip netns exec ${NS1} ip addr add ${VPEER_ADDR1}/16 dev ${VPEER1}
ip netns exec ${NS2} ip addr add ${VPEER_ADDR2}/16 dev ${VPEER2}

Et je dirais que classiquement on fait cela avec ‘ip addr add’ et le device en question. Remarquez aussi que l’on choisit ici de définir un masque /16.

Et notre bridge associé à nos namespaces ???

Ah quand même on vient pour avoir un bridge et on l’a toujours pas créé. Alors voilà ce que l’on fait :

## Création et activation du bridge
ip link add ${BR_DEV} type bridge
ip link set ${BR_DEV} up

## Ajout des vethernet au bridge
ip link set ${VETH1} master ${BR_DEV}
ip link set ${VETH2} master ${BR_DEV}

## Ajout de l'ip du bridge
ip addr add ${BR_ADDR}/16 dev ${BR_DEV}

On créé le bridge et on le rend up (active).

On y branche nos deux câbles virtuels (souvenez vous ils sont déjà branchés de l’autre côté à l’interface de nos namespaces).

Et ensuite on définit le CIDR ou range d’ip c’est à dire notre /16 et du coup l’ip qui sera attribué à ce bridge au niveau de notre host.

Router le traffic via le bridge

Alors c’est bien d’avoir de IP, des vethernet et tout le bazard mais quand je suis dans un namespace je ne sait pas par où passer pour communiquer à l’extérieur… Et ien on va ajouter des routes dans nos namespaces et donc dans notre cas pour faire simple on va juste avoir des routes par défaut :

## Ajout des routes poru chaque namespace pour passer par le bridge
ip netns exec ${NS1} ip route add default via ${BR_ADDR}
ip netns exec ${NS2} ip route add default via ${BR_ADDR}

Et pour accéder à internet !!! (à l’extérieur du host plutôt)

Oui c’est toujours cette fameuse question : comment je fais pour accéder à internet.

Et bien on va autoriser l’ip_forwarding au niveau de notre noyau linux. Et surtout on va utiliser iptables pour faire ce que l’on appelle un masquerade pour encapsuler nos paquets qui sortent et savoir dans quel namespace il doivent rentrer (par quelle interface plus précisément).

## Accès externe
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s ${BR_ADDR}/16 ! -o ${BR_DEV} -j MASQUERADE

Et bim c’est terminé !!! Tout le script est ici.

Voilà j’espère que cela a été assez clair. Vous avez bien sûr la vidéo. Et n’hésitez pas à faire connaître : le blog, la chaine et le podcast !!!

L’article Bridge, namespaces et vethernet comme docker0 est apparu en premier sur Xavki.

Dès que l’on dit réseau, souvent, on commence par avoir des frissons lol. Pourtant dans le cas de docker, je trouve que justement c’est tellement sympa à découvrir qu’en plus de se former à la conteneurisation vous vous formerez à un peu plus que ça (les éléments systèmes ntafis à Linux mais rarement utilisés comme les namespaces). Mais bon commençons par le commencement.

Comme je dis toujours, il faut savoir marcher avant de courrir mais si parfois en IT c’est pas forcément ce qui est le plus courrant.

Débutons par une histoire de ports

Si on va souvent parler des bridges et notamment du Docker0, assez souvent on va vous parler de ports. Comment tu exposes le port machin ? C’est quoi le port du conteneur ? Quel est le mapping des ports de l’applicatif xx ?… Et même souvent parfois avec des erreurs de termes employés. Par exemple, on utilise souvent le terme exposition de port … mais il s’agit de publication de port (ne vous inquiétez pas je le fais tout le temps ça).

Alors avant de parler de ports, on va retenir que docker dispose de différents mode en terme de réseau :

• bridge
• host
• overlay
• none
• macvlan…

On va pour le moment se focaliser sur lebridge docker. Par défaut, il se nomme docker0.

La difficulté avec docker c’est que chaque conteneur dispose d’une IP à travers ce bridge et au sein du réseau de la machine sur laquelle le conteneur est déployé. Or ces ip ne sont pas fixes. Pour des raisons d’arrêts et de redémarrages souvent, ces IP de conteneurs vont changer. Donc la première règle est de ne pas s’y habituer et de la utiliser.

Du coup on se dit ok on ne va pas utiliser les ip mais comment on fait. Alors il existe différentes solutions : le mapping de ports entre le conteneur et le host, les DNS, l’API/socket docker.

Pour commencer on va parler du mapping de ports. Il s’agit simplement de se dire que l’on va faire correspondre un port du conteneur par exemple le 80 pour un conteneur nginx et un port de la machine host (par exemple 8080).

Ainsi, pour taper sur le conteneur nginx de l’extérieur de la machine :

• je curl l’ip de ma machine host 12.168.10.20:8080
• et grâce à des règles iptables mise en place automatiquement par docker je finis par curl le 172.17.0.2:80 du conteneur

Ce n’est pas toujours recommandé mais c’est très très souvent utilisé pour de multiples raisons dont la simplicité.

Ainsi le bridge permet de mettre en place le réseau suivant :

Et pour notre mapping, voici comment on peut se le représenter :

Alors c’est cool mais comment fait-on cela ??

Deux méthodes : le publish simple et le publish all…

Pour un publish simple, on peu appliquer notre modèle précédent avec la ligne de commande suivante :

docker run -d --name c1 -p 8080:80 nginx:latest

Et doc le 8080 de notre machine host redirige vers le 80 du conteneur c1.

Sinon et c’est nettement moins sympa on peut faire un publish all avec cette cli :

docker run -d --name c1 -P nginx:latest

Et là on voit moins ce que l’on fait. D’une part il faut que l’image nginx ait prévu d’exposer un port avec la clause EXPOSE (dans le Dockerfile on reverra cela plus tard). D’autre part, les ports exposés seront mappés avec des ports aléatoires de la machine host à partir de 32000. C’est pas aussi fun hein 😉

On peut en retenir donc que l’on publie un port mais on ne l’expose pas. L’xposition ne revient qu’à une simple déclaration mais ça ne dit pas ce que l’on en fait.

Créez votre propre bridge !!

Voilà pour ce qui est des ports et maintenant on va découvrir un outil bien sympa à savoir docker network, une CLI dédiée à la gestion des réseaux docker et notamment des bridges.

Ainsi vous allez pouvoir créer votre propre bridge avec une simple commande. Par exemple pour créer un bridge xavki0, on utilisera :

docker network create --driver=bridge --subnet=192.168.0.0/24 xavki0

et pour l’utiliser en lançant un conteneur c’est très simple :

docker run -d --name c1 --network xavki0 nginx:latest

Et alors le truc cool une fois que vous affectez un réseau à un conteneur c’est que si vous ajoutez un autre conteneur à ce même réseau vous pourrez bénéficier d’une résolution dns entre les 2 conteneurs par leur nom. Cool ça non ??

Et on peut aussi reconfigurer le bridge docker0 !!

Les choses ne s’arrête pas là car on peut configurer assez largement les bridges : dns, gateway, cidr…

On peut aussi reconfigurer le bridge docker0 pour lui faire utiliser un autre range d’IP. Pour cela il suffit de créer un fichier dans /etc/docker/daemon.json contenant le paramètre bip :

{
"bip": "10.10.0.1/16"
}

Et vous pouvez aussi faire en sorte que lors de la création d’un bridge, vous pourrez lui définir le nom que vous retrouverez dans un ifconfig ou un ip a. Pour cela il suffit de passer l’option

docker network create -o com.docker.network.bridge.name=xavki0 xavki0

Allé dans un autre post et une autre vidéo on découvrira comment créer ses briges, namespaces et vethernet manuellement.

L’article Ce que vous devez savoir sur docker et ses réseaux est apparu en premier sur Xavki.

Et pour cela il faut se dire que pour lancer un conteneur ou interagir avec lui on va utiliser différents outils, constituant différentes couches. Et pour les ordonner, on va les classer du haut niveau c’est à dire votre CLI vers le bas niveaux ce sont les fonctionnalités linux fondamentales.

Docker CLI

C’est votre ligne de commande avec laquelle vous intéragissez dans le terminal. Vous pouvez donc faire à peu près le maximum de ce qui est possible avec elle.

Pourtant ça ne reste qu’une CLI, une sorte de wrapper à laquelle on va demander des choses et qui exécutera des commandes plus complexes pour nous.

Docker Engine (DockerD)

Alors là on utilise un premier container runtime c’est à dire un outil qui permet de lancer des conteneurs. Mais là encore ce n’est pas lui qui les lance réellement.

Lui il va interagir avec des couches plus basses et ajouter à ces couches des fonctionnalités. On parle aussi de Container Manager.

DockerD c’est notamment lui qui permet les inspects, les builds, la gestion des images simplifiées que permet docker (car en dessous c’est un poil plus complexe).

ContainerD

On est toujours dans une couche considérée comme un container runtime de haut niveau.

Containerd permet de lancer des conteneurs via la couche en dessous et de gérer la partie communication à travers les réseaux, le bridge principal.

RunC

Ah le voilà le container runtime de bas niveau que l’on utilise lorsque l’on tape des commandes avec docker.

RunC est écrit en golang et permet de lancer des conteneurs. C’est à celà que l’on considère que c’est un conteneur de bas niveau.

Mais c’est pas lui qui a les fonctions les plus essentielles ;).

Cgroups et Namespaces

Eh oui finalement sans les Control Groups (CGroups) et les Namespaces, nada. Docker ne peut rien faire et RunC non plus.

Ces outils sont natifs du noay linux.

Les cgroups permettent la gestion et la répartition des ressources sur un host : cpu, mémoire, io, bande passante…

Les namespaces permettent de cloisonner les processus : IPC, PID, UTS…

Et… vous pouvez les utiliser sur des processus standards sur linux sans faire appelle aux conteneurs. Mais bon cela on le reverra plus tard.

Si cet article vous a plu n’hésitez pas à parler de la chaine Xavki autour de vous.

L’article Les moteurs de conteneurs hauts et bas niveaux est apparu en premier sur Xavki.