From 9c1a5efd0c9ea341af45267bc29eccad53456418 Mon Sep 17 00:00:00 2001 From: Smana Date: Fri, 28 Aug 2026 08:39:51 +0200 Subject: [PATCH 1/2] docs(posts): reflect cloud-native-ref refactor in past-year posts (en/fr) - cnref.ogenki.io is now the main link when referring to the project; GitHub demoted to a secondary source link - Crossplane composition links moved to the new Smana/crossplane-configuration repo (apis//kcl layout, ghcr.io/smana/crossplane-configuration-* packages) - Mention AWS EKS + GCP GKE support where the platform is described - Replace dead links: llm-platform-future-paths.md -> AI platform roadmap, postgresql-monitoring-architecture.md -> docs page, docs/decisions -> docs ADRs --- .../series/agentic_ai/ai-coding-agent/index.md | 8 ++++---- .../series/agentic_ai/ai-coding-tips/index.md | 6 +++--- .../agentic_ai/llm-self-hosted-stack/index.md | 17 +++++++++-------- .../en/post/series/observability/logs/index.md | 2 +- .../series/observability/postgresql/index.md | 16 ++++++++-------- .../post/series/observability/runlore/index.md | 6 +++--- .../series/agentic_ai/ai-coding-agent/index.md | 8 ++++---- .../series/agentic_ai/ai-coding-tips/index.md | 6 +++--- .../agentic_ai/llm-self-hosted-stack/index.md | 17 +++++++++-------- .../fr/post/series/observability/logs/index.md | 2 +- .../series/observability/postgresql/index.md | 16 ++++++++-------- .../post/series/observability/runlore/index.md | 6 +++--- 12 files changed, 56 insertions(+), 54 deletions(-) diff --git a/content/en/post/series/agentic_ai/ai-coding-agent/index.md b/content/en/post/series/agentic_ai/ai-coding-agent/index.md index f9d3d049..5b0de0e9 100644 --- a/content/en/post/series/agentic_ai/ai-coding-agent/index.md +++ b/content/en/post/series/agentic_ai/ai-coding-agent/index.md @@ -18,7 +18,7 @@ thumbnail = "thumbnail.png" +++ {{% notice info "Update 2026-08-18" %}} -After several months of using [Superpowers](https://github.com/obra/superpowers), I moved [cloud-native-ref](https://github.com/Smana/cloud-native-ref) over to it entirely: the in-house SDD variant described below is now retired. The reasoning behind it — platform constitution, review personas, verification against a real cluster — still holds; what changed is the mechanism. I cover this in [part 2 of the series](/post/series/agentic_ai/ai-coding-tips/). +After several months of using [Superpowers](https://github.com/obra/superpowers), I moved [cloud-native-ref](https://cnref.ogenki.io) over to it entirely: the in-house SDD variant described below is now retired. The reasoning behind it — platform constitution, review personas, verification against a real cluster — still holds; what changed is the mechanism. I cover this in [part 2 of the series](/post/series/agentic_ai/ai-coding-tips/). {{% /notice %}} We can all see it — AI is shaking things up in a major way. The field is evolving so fast that keeping up with every new development is nearly impossible. As for measuring the impact on our daily lives and how we work, it's still too early to tell. One thing is certain though: in tech, it's a **revolution**! @@ -40,7 +40,7 @@ Most importantly, I'll try to demonstrate through concrete examples that this ne -The examples below come from my work on the Cloud Native Ref repository. It's a full-fledged platform combining EKS, Cilium, VictoriaMetrics, Crossplane, Flux and many other tools. +The examples below come from my work on the Cloud Native Ref project (source on GitHub). It's a full-fledged platform running on both AWS EKS and GCP GKE, combining Cilium, VictoriaMetrics, Crossplane, Flux and many other tools. @@ -343,7 +343,7 @@ For those steeped in Kubernetes, here's an analogy 😉: the spec defines the ** {{% notice tip "My SDD variant for Platform Engineering" %}} > **Update 2026-08-18** — this in-house workflow has been replaced by [Superpowers](https://github.com/obra/superpowers). The section is kept as written: it describes what actually ran for several months. -For [cloud-native-ref](https://github.com/Smana/cloud-native-ref), I created a variant inspired by GitHub Spec Kit that I'm evolving over time. I'll admit it's still quite experimental, but the results are already impressive. +For [cloud-native-ref](https://cnref.ogenki.io), I created a variant inspired by GitHub Spec Kit that I'm evolving over time. I'll admit it's still quite experimental, but the results are already impressive. **🛡️ Platform Constitution** — Non-negotiable principles are codified in a [constitution](https://github.com/Smana/cloud-native-ref/blob/main/docs/platform-constitution.md): `xplane-*` prefix for IAM scoping, mandatory zero-trust networking, secrets via External Secrets only. Claude checks every spec and implementation against these rules. @@ -562,5 +562,5 @@ Given my affinity for open source, I'm looking at exploring open alternatives: * - [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — Anthropic Research ### Resources -- [Cloud Native Ref](https://github.com/Smana/cloud-native-ref) — My reference repo +- [Cloud Native Ref](https://cnref.ogenki.io) — My reference platform · [GitHub repo](https://github.com/Smana/cloud-native-ref) - [SWE-bench Leaderboards](https://www.swebench.com/) — Reference benchmark diff --git a/content/en/post/series/agentic_ai/ai-coding-tips/index.md b/content/en/post/series/agentic_ai/ai-coding-tips/index.md index d5faedf3..997b4299 100644 --- a/content/en/post/series/agentic_ai/ai-coding-tips/index.md +++ b/content/en/post/series/agentic_ai/ai-coding-tips/index.md @@ -41,7 +41,7 @@ Let's be honest: once you're used to Claude Code, expectations run high. I won't * **Skills**: specialized capabilities loaded on demand (creating PRs, security audits, writing designs) * **Subagents and hooks**: automatic triggers (desktop notification, pre-commit validation) and delegation to isolated contexts -* **SDD** with **superpowers**: I tried several flavours (github-specs, gsd); this is the one I settled on, for how simple it is to use while still guaranteeing a complete workflow that respects good practices — [cloud-native-ref](https://github.com/Smana/cloud-native-ref) moved over to it entirely in August 2026 +* **SDD** with **superpowers**: I tried several flavours (github-specs, gsd); this is the one I settled on, for how simple it is to use while still guaranteeing a complete workflow that respects good practices — [cloud-native-ref](https://cnref.ogenki.io) moved over to it entirely in August 2026 * **Automode** on POCs, with a careful review of the first iteration before letting it run This workflow plays to **Claude's specific strengths**: Opus reasoning on the critical passages, the 1M context window in beta, and very reliable _function-calling_. @@ -71,7 +71,7 @@ Files are **cumulative**: Claude loads all of them from most global to most loca ### What I put in mine -Here's what the `CLAUDE.md` for [cloud-native-ref](https://github.com/Smana/cloud-native-ref) actually contains: +Here's what the `CLAUDE.md` for [cloud-native-ref](https://github.com/Smana/cloud-native-ref/blob/main/CLAUDE.md) actually contains: - **Build/test/lint commands** — the first lines, so Claude knows how to validate its work - **Project conventions** — `xplane-*` prefix for IAM, Crossplane composition structure, KCL patterns @@ -80,7 +80,7 @@ Here's what the `CLAUDE.md` for [cloud-native-ref](https://github.com/Smana/clou What I **don't** put in it: exhaustive documentation (that's what [Skills](/post/series/agentic_ai/ai-coding-agent/#skills-unlocking-new-powers) are for), long code examples (I reference existing files instead), and obvious instructions Claude already knows. -Here's a condensed excerpt from the `CLAUDE.md` of [cloud-native-ref](https://github.com/Smana/cloud-native-ref) to illustrate: +Here's a condensed excerpt from the `CLAUDE.md` of [cloud-native-ref](https://github.com/Smana/cloud-native-ref/blob/main/CLAUDE.md) to illustrate: ```markdown ## Common Commands diff --git a/content/en/post/series/agentic_ai/llm-self-hosted-stack/index.md b/content/en/post/series/agentic_ai/llm-self-hosted-stack/index.md index d9397d33..cb9c56c2 100644 --- a/content/en/post/series/agentic_ai/llm-self-hosted-stack/index.md +++ b/content/en/post/series/agentic_ai/llm-self-hosted-stack/index.md @@ -38,7 +38,7 @@ This article aims to **lay the foundations** of an alternative meant to evolve a * Honestly evaluate what works, what doesn't, and what it really costs {{% notice tip "The reference repo" %}} -The whole stack is deployed via GitOps from [**cloud-native-ref**](https://github.com/Smana/cloud-native-ref) — beyond the LLM layer, the repo illustrates **a complete cloud-native ecosystem**: +The whole stack is deployed via GitOps from [**cloud-native-ref**](https://cnref.ogenki.io) ([source on GitHub](https://github.com/Smana/cloud-native-ref)) — beyond the LLM layer, the project illustrates **a complete cloud-native ecosystem**, running on both AWS EKS and GCP GKE: * **GitOps** — Flux, continuous reconciliation * **Platform engineering** — Crossplane (one YAML claim generates all the Kubernetes plumbing) @@ -67,7 +67,7 @@ The whole thing is driven by **GitOps** (Flux reconciles everything from [`cloud ## :electric_plug: The centerpiece: the `InferenceService` abstraction -If you've read some of [my previous articles](/post/crossplane_composition_functions/), you know I particularly like `Crossplane` for providing the right abstraction to end users. It's one of my essential components and lets me expose a **simple, fit-for-purpose interface**. I already have a few: `App`, `SQLInstance`, `EPI` — and now `InferenceService`. +If you've read some of [my previous articles](/post/crossplane_composition_functions/), you know I particularly like `Crossplane` for providing the right abstraction to end users. It's one of my essential components and lets me expose a **simple, fit-for-purpose interface**. I already have a few: `App`, `SQLInstance`, `EPI` — and now `InferenceService`. All of them are packaged and versioned in a dedicated repository: [crossplane-configuration](https://github.com/Smana/crossplane-configuration). ### Declaring a new model @@ -135,8 +135,8 @@ Four lines change. Flux reconciles, KEDA readjusts triggers, Karpenter provision {{% notice tip "KCL: version, test, validate a composition" %}} The composition isn't written as YAML patches (unreadable, untestable) but in [**KCL**](https://kcl-lang.io/) via the [function-kcl](https://github.com/crossplane-contrib/function-kcl) — a **typed** configuration language with **native assertions**. Three direct consequences: -* **Unit tests** — a [`main_test.k`](https://github.com/Smana/cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/kcl/inference-service/main_test.k) file validates each behavior (`kcl test` runs in CI on every PR). -* **Versioned OCI packaging** — the composition is published as an OCI image (`oci://ghcr.io/smana/cloud-native-ref/crossplane-inference-service:0.6.0`), referenced by immutable tag. +* **Unit tests** — a [`main_test.k`](https://github.com/Smana/crossplane-configuration/blob/main/apis/inferenceservice/kcl/main_test.k) file validates each behavior (`kcl test` runs in CI on every PR). +* **Versioned OCI packaging** — the composition is published as a Crossplane Configuration package (`ghcr.io/smana/crossplane-configuration-aws:v0.4.1`) from the dedicated [crossplane-configuration](https://github.com/Smana/crossplane-configuration) repository, referenced by immutable tag. * **Claim schema validated at the API server** — `kubectl apply` rejects inconsistent claims (e.g. `minReplicas > maxReplicas`) **before** the composition is even triggered. Versions, tests, schema — not just "YAML we copy-paste". @@ -425,7 +425,7 @@ Let's be clear: today I wouldn't trade my Claude ecosystem. Mainly for **financi That said, I would have liked to push my use of **OpenCode** further and migrate my Claude setup (skills, MCPs, sub-agents) onto that backend for good — that may be the topic of a future article dedicated to this open-source coding agent. -But I'm keeping the stack alive. The day a Qwen3-Coder-30B-A3B runs cleanly on a quantized L4 — a path documented in [`docs/llm-platform-future-paths.md`](https://github.com/Smana/cloud-native-ref/blob/main/docs/llm-platform-future-paths.md) — the swap will be a few-line PR. That's the **main point** of this demo: positioning yourself to **move fast when the time comes**, rather than scrambling to (re)build everything the day open-weight catches up to the frontier. +But I'm keeping the stack alive. The day a Qwen3-Coder-30B-A3B runs cleanly on a quantized L4 — a path documented in the [AI platform roadmap](https://cnref.ogenki.io/docs/platform/ai-platform/roadmap/) — the swap will be a few-line PR. That's the **main point** of this demo: positioning yourself to **move fast when the time comes**, rather than scrambling to (re)build everything the day open-weight catches up to the frontier. And this catch-up isn't only about models: the open-source serving layer evolves just as fast and regularly brings in capabilities previously reserved for proprietary solutions. For instance, [**vLLM-Omni**](https://github.com/vllm-project/vllm-omni) (first stable late 2025) extends `vLLM` to **omni-modality** (text, image, audio, video, as **inputs and outputs**) with the same OpenAI-compatible API, so it plugs directly into the platform described here. @@ -436,9 +436,10 @@ And this catch-up isn't only about models: the open-source serving layer evolves ## :bookmark: References ### Repos -- [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref) — The complete platform -- [`docs/decisions/`](https://github.com/Smana/cloud-native-ref/tree/main/docs/decisions) — ADRs (vLLM Production Stack, S3 Files…) -- [`docs/llm-platform-future-paths.md`](https://github.com/Smana/cloud-native-ref/blob/main/docs/llm-platform-future-paths.md) — Evolution paths +- [`cloud-native-ref`](https://cnref.ogenki.io) — The complete platform documentation · [source on GitHub](https://github.com/Smana/cloud-native-ref) +- [`crossplane-configuration`](https://github.com/Smana/crossplane-configuration) — The Crossplane compositions (`App`, `SQLInstance`, `InferenceService`…) +- [Architecture decisions](https://cnref.ogenki.io/docs/decisions/) — ADRs (vLLM Production Stack, S3 Files…) +- [AI platform roadmap](https://cnref.ogenki.io/docs/platform/ai-platform/roadmap/) — Evolution paths ### Technical components - [vLLM Production Stack](https://github.com/vllm-project/production-stack) — Production-grade LLM inference diff --git a/content/en/post/series/observability/logs/index.md b/content/en/post/series/observability/logs/index.md index 342b8460..5aada003 100644 --- a/content/en/post/series/observability/logs/index.md +++ b/content/en/post/series/observability/logs/index.md @@ -345,7 +345,7 @@ And start using the Web UI which is exposed using [Cilium and Gateway API resour {{% notice tip "⚙️ Deployment: where to find the full configuration" %}} -All the configuration used for writing this article can be found in the Cloud Native Ref repository.
+All the configuration used for writing this article can be found in the Cloud Native Ref project (source on GitHub).
The ambition of this project is to be able to quickly start a complete platform that applies best practices in terms of automation, monitoring, security, etc.
diff --git a/content/en/post/series/observability/postgresql/index.md b/content/en/post/series/observability/postgresql/index.md index 8df444d2..d1302a66 100644 --- a/content/en/post/series/observability/postgresql/index.md +++ b/content/en/post/series/observability/postgresql/index.md @@ -42,7 +42,7 @@ The metrics exposed include: -The examples in this article come from configurations available in the Cloud Native Ref repository.
+The examples in this article come from configurations available in the Cloud Native Ref project (source on GitHub).
It leverages several operators, including [CloudNativePG](https://cloudnative-pg.io/) for PostgreSQL management, [VictoriaMetrics](https://victoriametrics.com/) for metrics collection, and [VictoriaLogs](https://github.com/VictoriaMetrics/VictoriaLogs) for log collection. @@ -187,7 +187,7 @@ Thanks to CloudNativePG's "[Managed Extensions](https://cloudnative-pg.io/docume One of the key principles of platform engineering is providing the right level of abstraction to application developers. They shouldn't need to understand PostgreSQL internals or memorize 15+ PostgreSQL-specific configuration parameters. -This is where **Crossplane compositions** shine. In the Cloud Native Ref project, we use Crossplane with KCL (Kubernetes Configuration Language) to create a higher-level abstraction called `SQLInstance`. +This is where **Crossplane compositions** shine. In the Cloud Native Ref project, we use Crossplane with KCL (Kubernetes Configuration Language) to create a higher-level abstraction called `SQLInstance`. These compositions are packaged and versioned in a dedicated repository: [crossplane-configuration](https://github.com/Smana/crossplane-configuration). **Without Composition** (Raw CNPG Cluster): ```yaml @@ -243,7 +243,7 @@ spec: logStatement: none # Optional: none (default) / ddl / mod / all ``` -The Crossplane composition [**SQLInstance**](https://github.com/Smana/cloud-native-ref/tree/main/infrastructure/base/crossplane/configuration/kcl/cloudnativepg) handles all the complexity. +The Crossplane composition [**SQLInstance**](https://github.com/Smana/crossplane-configuration/tree/main/apis/sqlinstance) handles all the complexity. This composition approach provides several benefits: @@ -297,7 +297,7 @@ Here's what Vector does concretely - **transforming a PostgreSQL auto_explain lo #### 3-Step Pipeline -The Vector pipeline consists of **3 transforms** and **2 sinks** ([complete configuration](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/helmrelease-vlsingle.yaml#L62-L338)): +The Vector pipeline consists of **3 transforms** and **2 sinks** ([complete configuration](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/helmrelease-vlsingle.yaml)): **1. Parse CloudNativePG JSON logs** ```vrl @@ -379,7 +379,7 @@ This immediately suggests the need for an index on the `email` column. Understanding complex execution plans from logs can be challenging. This is where **[pev2](https://github.com/dalibo/pev2)** (PostgreSQL Explain Visualizer 2) becomes very useful. It's a web tool that transforms JSON execution plans into interactive, visual diagrams. -To ensure sensitive query data never leaves the network, pev2 is self-hosted in the cluster via the [App](https://github.com/Smana/cloud-native-ref/tree/main/infrastructure/base/crossplane/configuration/kcl/app) composition. This once again demonstrates the **platform abstraction level**: deploying a static web tool uses the same declarative API as a complete application with a database. +To ensure sensitive query data never leaves the network, pev2 is self-hosted in the cluster via the [App](https://github.com/Smana/crossplane-configuration/tree/main/apis/app) composition. This once again demonstrates the **platform abstraction level**: deploying a static web tool uses the same declarative API as a complete application with a database. ```yaml apiVersion: cloud.ogenki.io/v1alpha1 @@ -470,7 +470,7 @@ This is, once again, a demonstration of the **power of available open source too Furthermore the `App` and `SQLInstance` Crossplane compositions allow to enable _Performance Insights_ only by setting `performanceInsights.enabled: true` with a few tuning parameters (`sampleRate`, `minDuration`). Developers don't need to understand PostgreSQL internals or Vector—the platform masks the complexity. This same declarative API deploys both a complete database and a static web tool like pev2, demonstrating the consistency of the abstraction level. -The [cloud-native-ref](https://github.com/Smana/cloud-native-ref) project brings all these pieces together and shows how Gateway API, Tailscale, Crossplane/KCL, and the VictoriaMetrics ecosystem assemble to create a complete observability platform. +The [cloud-native-ref](https://cnref.ogenki.io) project brings all these pieces together and shows how Gateway API, Tailscale, Crossplane/KCL, and the VictoriaMetrics ecosystem assemble to create a complete observability platform — running on both AWS EKS and GCP GKE. {{% notice note "Performance Consideration" %}} Enabling Performance Insights involves an estimated overhead of **3-4% CPU** and **~200-250MB memory** with default values: @@ -511,5 +511,5 @@ The `sampleRate`, `log_timing`, and `logStatement` parameters allow fine-tuning **Configuration and Implementation** - [Vector VRL Configuration](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/README.md) - PostgreSQL log parsing pipeline -- [CloudNativePG Composition](https://github.com/Smana/cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/kcl/cloudnativepg/README.md) - SQLInstance abstraction with KCL -- [PostgreSQL Monitoring Architecture](https://github.com/Smana/cloud-native-ref/blob/main/docs/postgresql-monitoring-architecture.md) - Complete architecture documentation +- [SQLInstance Composition](https://github.com/Smana/crossplane-configuration/blob/main/apis/sqlinstance/kcl/README.md) - CloudNativePG abstraction with KCL, from the [crossplane-configuration](https://github.com/Smana/crossplane-configuration) repository +- [PostgreSQL Monitoring Architecture](https://cnref.ogenki.io/docs/platform/observability/postgresql/) - Complete architecture documentation diff --git a/content/en/post/series/observability/runlore/index.md b/content/en/post/series/observability/runlore/index.md index c97f9fc0..9b5d8243 100644 --- a/content/en/post/series/observability/runlore/index.md +++ b/content/en/post/series/observability/runlore/index.md @@ -35,7 +35,7 @@ To hold on to that knowledge, I picked **OKF** (_Open Knowledge Format_), a form * 🤖 Get to know [**RunLore**](https://github.com/Smana/runlore) and how it works * 🧠 Its **three design choices**: a single binary, the **learning loop**, and the **human who makes the call** -* 🛠️ **Deploy it** with Helm and watch it investigate a **real incident** on [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref) +* 🛠️ **Deploy it** with Helm and watch it investigate a **real incident** on [`cloud-native-ref`](https://cnref.ogenki.io) ## 🔥 Why this project: the hidden cost of investigation @@ -143,7 +143,7 @@ Keeping a human in the loop, on what gets done as much as on what gets learned, ## 👀 Here's what it looks like -Enough theory, here is RunLore **at work**. The incident below is a real one, investigated on [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref), my reference repo: a complete platform on **EKS** combining Cilium, VictoriaMetrics, Crossplane and Flux. +Enough theory, here is RunLore **at work**. The incident below is a real one, investigated on [`cloud-native-ref`](https://cnref.ogenki.io), my reference platform: a complete stack combining Cilium, VictoriaMetrics, Crossplane and Flux, running on both **AWS EKS** and **GCP GKE** — the incident below happened on the AWS cluster. {{% notice info "The model behind the demo 🧠" %}} The whole demo runs on **GLM 5.2** (Zhipu AI, through Z.ai's OpenAI-compatible API): quality **very close to frontier models** (Claude, GPT) at a **markedly lower cost per token**, which matters a lot when an agent wired to Alertmanager can kick off a lot of investigations. Since RunLore accepts any OpenAI-compatible endpoint, **switching takes a few lines**, all the way to a [self-hosted LLM stack](/post/series/agentic_ai/llm-self-hosted-stack/) (vLLM, Ollama) if you want to keep everything within your perimeter. @@ -339,5 +339,5 @@ So I'll report back after a longer run. Until then, the project is **open** (Apa * [Open Knowledge Format (OKF) — Knowledge Catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog) * [Open Knowledge Format — Google Cloud announcement](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) * [Andrej Karpathy's _LLM-wiki_ pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) -* [cloud-native-ref — reference platform](https://github.com/Smana/cloud-native-ref) +* [cloud-native-ref — documentation](https://cnref.ogenki.io) · [GitHub repo](https://github.com/Smana/cloud-native-ref) * [k8sgpt](https://github.com/k8sgpt-ai/k8sgpt) · [HolmesGPT](https://github.com/HolmesGPT/holmesgpt) · [kagent](https://github.com/kagent-dev/kagent) diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/index.md b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md index 9144b3cc..e83da002 100644 --- a/content/fr/post/series/agentic_ai/ai-coding-agent/index.md +++ b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md @@ -18,7 +18,7 @@ thumbnail = "thumbnail.png" +++ {{% notice info "Mise à jour 2026-08-18" %}} -Après plusieurs mois à utiliser [Superpowers](https://github.com/obra/superpowers), j'ai basculé [cloud-native-ref](https://github.com/Smana/cloud-native-ref) entièrement dessus : la variante SDD maison décrite plus bas est désormais retirée. Le raisonnement qui la sous-tendait — constitution de plateforme, personas de review, vérification sur cluster réel — reste valable ; c'est le mécanisme qui a changé. J'en parle dans la [partie 2 de la série](/fr/post/series/agentic_ai/ai-coding-tips/). +Après plusieurs mois à utiliser [Superpowers](https://github.com/obra/superpowers), j'ai basculé [cloud-native-ref](https://cnref.ogenki.io) entièrement dessus : la variante SDD maison décrite plus bas est désormais retirée. Le raisonnement qui la sous-tendait — constitution de plateforme, personas de review, vérification sur cluster réel — reste valable ; c'est le mécanisme qui a changé. J'en parle dans la [partie 2 de la série](/fr/post/series/agentic_ai/ai-coding-tips/). {{% /notice %}} Nous le voyons bien, nous assistons à un réel bouleversement provoqué par l'**utilisation de l'IA**. Ce domaine évolue à une telle vitesse qu'il devient presque impossible de suivre toutes les nouveautés. Quant à mesurer l'impact sur notre quotidien et notre façon de travailler, il est encore trop tôt pour le dire. Une chose est sûre cependant : dans la tech, c'est une **révolution** ! @@ -40,7 +40,7 @@ Mais surtout, je vais tenter de vous démontrer par des cas concrets que cette n -Les exemples qui suivent sont issus de mon travail sur le repository Cloud Native Ref. Il s'agit d'une plateforme complète combinant EKS, Cilium, VictoriaMetrics, Crossplane, Flux et bien d'autres outils. +Les exemples qui suivent sont issus de mon travail sur le projet Cloud Native Ref (sources sur GitHub). Il s'agit d'une plateforme complète fonctionnant à la fois sur AWS EKS et GCP GKE, combinant Cilium, VictoriaMetrics, Crossplane, Flux et bien d'autres outils. @@ -342,7 +342,7 @@ Pour ceux qui baignent dans Kubernetes, on peut faire un parallèle 😉 : la sp {{% notice tip "Ma variante SDD pour le Platform Engineering" %}} > **Mise à jour 2026-08-18** — ce workflow maison a été remplacé par [Superpowers](https://github.com/obra/superpowers). La section est conservée telle quelle : elle décrit ce qui a réellement tourné pendant plusieurs mois. -Pour [cloud-native-ref](https://github.com/Smana/cloud-native-ref), j'ai créé une variante inspirée de GitHub Spec Kit que je fais évoluer progressivement. J'avoue que c'est assez expérimental pour le moment, mais les résultats sont déjà impressionnants. +Pour [cloud-native-ref](https://cnref.ogenki.io), j'ai créé une variante inspirée de GitHub Spec Kit que je fais évoluer progressivement. J'avoue que c'est assez expérimental pour le moment, mais les résultats sont déjà impressionnants. **🛡️ Platform Constitution** — Les principes non-négociables sont codifiés dans une [constitution](https://github.com/Smana/cloud-native-ref/blob/main/docs/platform-constitution.md) : préfixe `xplane-*` pour le scoping IAM, zero-trust networking obligatoire, secrets via External Secrets uniquement. Claude vérifie chaque spec et implémentation contre ces règles. @@ -561,5 +561,5 @@ De par ma sensibilité pour l'open source, j'envisage d'explorer les alternative - [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — Anthropic Research ### Ressources -- [Cloud Native Ref](https://github.com/Smana/cloud-native-ref) — Mon repo de référence +- [Cloud Native Ref](https://cnref.ogenki.io) — Ma plateforme de référence · [dépôt GitHub](https://github.com/Smana/cloud-native-ref) - [SWE-bench Leaderboards](https://www.swebench.com/) — Benchmark de référence diff --git a/content/fr/post/series/agentic_ai/ai-coding-tips/index.md b/content/fr/post/series/agentic_ai/ai-coding-tips/index.md index 9ac55480..8bc6126c 100644 --- a/content/fr/post/series/agentic_ai/ai-coding-tips/index.md +++ b/content/fr/post/series/agentic_ai/ai-coding-tips/index.md @@ -43,7 +43,7 @@ Autant le dire : quand on est habitué à Claude Code, les attentes sont élevé * **Skills** : capacités spécialisées chargées à la demande (création de PRs, audits sécurité, écriture de specs) * **Subagents et hooks** : déclencheurs automatiques (notification desktop, validation pré-commit) et délégation à des contextes isolés -* **SDD** avec **superpowers** : j'ai testé plusieurs déclinaisons (github-specs, gsd) ; c'est celui que j'ai retenu, pour sa simplicité d'usage tout en garantissant un workflow complet qui respecte les bonnes pratiques — [cloud-native-ref](https://github.com/Smana/cloud-native-ref) a entièrement basculé dessus en août 2026 +* **SDD** avec **superpowers** : j'ai testé plusieurs déclinaisons (github-specs, gsd) ; c'est celui que j'ai retenu, pour sa simplicité d'usage tout en garantissant un workflow complet qui respecte les bonnes pratiques — [cloud-native-ref](https://cnref.ogenki.io) a entièrement basculé dessus en août 2026 * **Automode** sur les POC, avec une revue minutieuse à la première itération avant de laisser tourner Ce workflow tire parti des **forces spécifiques de Claude** : raisonnement Opus sur les passages critiques, fenêtre de contexte 1M en bêta, _function-calling_ très fiable. @@ -73,7 +73,7 @@ Les fichiers sont **cumulatifs** : Claude les charge tous du plus global au plus ### Ce que je mets dans le mien -Voici ce que contient le `CLAUDE.md` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref), concrètement : +Voici ce que contient le `CLAUDE.md` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref/blob/main/CLAUDE.md), concrètement : - **Commandes de build/test/lint** — les premières lignes, pour que Claude sache comment valider son travail - **Conventions du projet** — préfixe `xplane-*` pour l'IAM, structure des compositions Crossplane, patterns KCL @@ -82,7 +82,7 @@ Voici ce que contient le `CLAUDE.md` de [cloud-native-ref](https://github.com/Sm Ce que je n'y mets **pas** : la documentation exhaustive (c'est le rôle des [Skills](/fr/post/series/agentic_ai/ai-coding-agent/#skills--obtenir-de-nouveaux-pouvoirs)), les exemples de code longs (je référence les fichiers existants), et les instructions évidentes que Claude connaît déjà. -Voici un extrait condensé du `CLAUDE.md` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref) pour illustrer : +Voici un extrait condensé du `CLAUDE.md` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref/blob/main/CLAUDE.md) pour illustrer : ```markdown ## Common Commands diff --git a/content/fr/post/series/agentic_ai/llm-self-hosted-stack/index.md b/content/fr/post/series/agentic_ai/llm-self-hosted-stack/index.md index 9594ef03..c4bae894 100644 --- a/content/fr/post/series/agentic_ai/llm-self-hosted-stack/index.md +++ b/content/fr/post/series/agentic_ai/llm-self-hosted-stack/index.md @@ -38,7 +38,7 @@ Cet article a pour objectif de **poser les fondations** d'une alternative à fai * Évaluer honnêtement ce qui marche, ce qui ne marche pas, et ce que ça coûte vraiment {{% notice tip "Le repo de référence" %}} -Toute la stack est déployée par GitOps depuis [**cloud-native-ref**](https://github.com/Smana/cloud-native-ref) — au-delà de la couche LLM, le repo illustre **un écosystème cloud-native complet** : +Toute la stack est déployée par GitOps depuis [**cloud-native-ref**](https://cnref.ogenki.io) ([sources sur GitHub](https://github.com/Smana/cloud-native-ref)) — au-delà de la couche LLM, le projet illustre **un écosystème cloud-native complet**, fonctionnant à la fois sur AWS EKS et GCP GKE : * **GitOps** — Flux, réconciliation continue * **Platform engineering** — Crossplane (une claim YAML génère tout l'outillage Kubernetes) @@ -67,7 +67,7 @@ L'ensemble est piloté par **Flux** (réconciliation continue depuis [`cloud-nat ## :electric_plug: La pièce maîtresse : l'abstraction `InferenceService` -Si vous avez lu certains de [mes articles précédents](/fr/post/crossplane_composition_functions/), vous savez que j'apprécie particulièrement `Crossplane` pour fournir la bonne abstraction aux utilisateurs. Il fait partie de mes composants essentiels et permet d'exposer une **interface adaptée et simple** à utiliser. J'en ai déjà quelques-unes : `App`, `SQLInstance`, `EPI` — et maintenant `InferenceService`. +Si vous avez lu certains de [mes articles précédents](/fr/post/crossplane_composition_functions/), vous savez que j'apprécie particulièrement `Crossplane` pour fournir la bonne abstraction aux utilisateurs. Il fait partie de mes composants essentiels et permet d'exposer une **interface adaptée et simple** à utiliser. J'en ai déjà quelques-unes : `App`, `SQLInstance`, `EPI` — et maintenant `InferenceService`. Toutes sont packagées et versionnées dans un dépôt dédié : [crossplane-configuration](https://github.com/Smana/crossplane-configuration). ### Déclarer un nouveau modèle @@ -135,8 +135,8 @@ Quatre lignes changent. Flux réconcilie, KEDA réajuste les triggers, Karpenter {{% notice tip "KCL : versionner, tester, valider une composition" %}} La composition n'est pas écrite en YAML patches (peu lisible, intestable) mais en [**KCL**](https://kcl-lang.io/) via la [function-kcl](https://github.com/crossplane-contrib/function-kcl) — un langage de configuration **typé**, avec **assertions natives**. Trois conséquences directes : -* **Tests unitaires** — un fichier [`main_test.k`](https://github.com/Smana/cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/kcl/inference-service/main_test.k) valide chaque comportement (`kcl test` tourne en CI sur chaque PR). -* **Packaging OCI versionné** — la composition est publiée comme image OCI (`oci://ghcr.io/smana/cloud-native-ref/crossplane-inference-service:0.6.0`), référencée par tag immuable. +* **Tests unitaires** — un fichier [`main_test.k`](https://github.com/Smana/crossplane-configuration/blob/main/apis/inferenceservice/kcl/main_test.k) valide chaque comportement (`kcl test` tourne en CI sur chaque PR). +* **Packaging OCI versionné** — la composition est publiée comme package Crossplane Configuration (`ghcr.io/smana/crossplane-configuration-aws:v0.4.1`) depuis le dépôt dédié [crossplane-configuration](https://github.com/Smana/crossplane-configuration), référencée par tag immuable. * **Schéma de claim validé côté API server** — `kubectl apply` rejette les claims incohérentes (par exemple `minReplicas > maxReplicas`) **avant** que la composition ne se déclenche. Versions, tests, schéma — pas juste "du YAML qu'on copie-colle". @@ -429,7 +429,7 @@ Soyons clairs : aujourd'hui je ne troquerais pas mon écosystème Claude. Princi Cela dit, j'aurais aimé pousser plus loin l'usage d'**OpenCode** et migrer pour de bon ma configuration Claude (skills, MCPs, sous-agents) sur ce backend — ce sera peut-être le sujet d'un futur article dédié à cet agent coding open-source. -Mais je garde la stack vivante. Quand un Qwen3-Coder-30B-A3B tournera correctement sur un L4 quantifié — chemin documenté dans [`docs/llm-platform-future-paths.md`](https://github.com/Smana/cloud-native-ref/blob/main/docs/llm-platform-future-paths.md) — le swap sera une PR de quelques lignes. C'est ça l'**intérêt principal** de cette démo : se mettre en position d'**adopter rapidement** ce qui s'annonce, plutôt que d'avoir à tout (re)construire le jour où l'open-weight rattrapera le frontier. +Mais je garde la stack vivante. Quand un Qwen3-Coder-30B-A3B tournera correctement sur un L4 quantifié — chemin documenté dans la [roadmap de la plateforme IA](https://cnref.ogenki.io/docs/platform/ai-platform/roadmap/) — le swap sera une PR de quelques lignes. C'est ça l'**intérêt principal** de cette démo : se mettre en position d'**adopter rapidement** ce qui s'annonce, plutôt que d'avoir à tout (re)construire le jour où l'open-weight rattrapera le frontier. Et ce rattrapage ne vient pas que des modèles : la couche serving open-source évolue tout aussi vite et ajoute régulièrement des fonctions jusque-là réservées aux solutions propriétaires. Par exemple, [**vLLM-Omni**](https://github.com/vllm-project/vllm-omni) (premier *stable* fin 2025) étend `vLLM` à l'**omni-modalité** (texte, image, audio, vidéo, en entrée *et* en sortie) avec la même API OpenAI-compatible, donc plug directement dans la plateforme décrite ici. @@ -440,9 +440,10 @@ Et ce rattrapage ne vient pas que des modèles : la couche serving open-source ## :bookmark: Références ### Repos -- [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref) — La plateforme complète -- [`docs/decisions/`](https://github.com/Smana/cloud-native-ref/tree/main/docs/decisions) — ADRs (vLLM Production Stack, S3 Files…) -- [`docs/llm-platform-future-paths.md`](https://github.com/Smana/cloud-native-ref/blob/main/docs/llm-platform-future-paths.md) — Chemins d'évolution +- [`cloud-native-ref`](https://cnref.ogenki.io) — La documentation complète de la plateforme · [sources sur GitHub](https://github.com/Smana/cloud-native-ref) +- [`crossplane-configuration`](https://github.com/Smana/crossplane-configuration) — Les compositions Crossplane (`App`, `SQLInstance`, `InferenceService`…) +- [Décisions d'architecture](https://cnref.ogenki.io/docs/decisions/) — ADRs (vLLM Production Stack, S3 Files…) +- [Roadmap de la plateforme IA](https://cnref.ogenki.io/docs/platform/ai-platform/roadmap/) — Chemins d'évolution ### Composants techniques - [vLLM Production Stack](https://github.com/vllm-project/production-stack) — Inférence LLM en production diff --git a/content/fr/post/series/observability/logs/index.md b/content/fr/post/series/observability/logs/index.md index 159b6dcc..663d0cb3 100644 --- a/content/fr/post/series/observability/logs/index.md +++ b/content/fr/post/series/observability/logs/index.md @@ -344,7 +344,7 @@ Et commencer à utiliser l'interface Web qui est exposée en utilisant [Cilium e {{% notice tip "⚙️ Déploiement: où trouver toute la configuration" %}} -Toute la configuration utilisée pour l'écriture de cet article se trouve dans le repository Cloud Native Ref.
+Toute la configuration utilisée pour l'écriture de cet article se trouve dans le projet Cloud Native Ref (sources sur GitHub).
L'ambition de ce projet est de pouvoir démarrer rapidement une plateforme complète qui applique les bonnes pratiques en terme d'automatisation, de supervision, de sécurité etc.
diff --git a/content/fr/post/series/observability/postgresql/index.md b/content/fr/post/series/observability/postgresql/index.md index 72cc258f..c6fc21d9 100644 --- a/content/fr/post/series/observability/postgresql/index.md +++ b/content/fr/post/series/observability/postgresql/index.md @@ -42,7 +42,7 @@ Les métriques exposées incluent : -Les exemples de cet article proviennent de configurations disponibles dans le dépôt Cloud Native Ref.
+Les exemples de cet article proviennent de configurations disponibles dans le projet Cloud Native Ref (sources sur GitHub).
Il exploite plusieurs opérateurs, notamment [CloudNativePG](https://cloudnative-pg.io/) pour la gestion PostgreSQL, [VictoriaMetrics](https://victoriametrics.com/) pour la collecte de métriques et [VictoriaLogs](https://github.com/VictoriaMetrics/VictoriaLogs) pour la collecte de logs. @@ -186,7 +186,7 @@ Grâce aux "[Managed Extensions](https://cloudnative-pg.io/documentation/1.27/po L'un des principes clés du _platform engineering_ est de fournir le bon niveau d'abstraction aux développeurs/ses. Ils/Elles ne devraient pas avoir besoin de comprendre les internals de PostgreSQL ni de mémoriser plus de 15 paramètres de configuration spécifiques à PostgreSQL. -C'est ici que les **compositions Crossplane** démontrent leur intérêt. Dans le projet Cloud Native Ref, nous utilisons Crossplane avec [KCL](https://www.kcl-lang.io/) (Kubernetes Configuration Language) pour créer une abstraction de plus haut niveau appelée `SQLInstance`. +C'est ici que les **compositions Crossplane** démontrent leur intérêt. Dans le projet Cloud Native Ref, nous utilisons Crossplane avec [KCL](https://www.kcl-lang.io/) (Kubernetes Configuration Language) pour créer une abstraction de plus haut niveau appelée `SQLInstance`. Ces compositions sont packagées et versionnées dans un dépôt dédié : [crossplane-configuration](https://github.com/Smana/crossplane-configuration). **Sans Composition** (Cluster CNPG brut) : ```yaml @@ -242,7 +242,7 @@ spec: logStatement: none # Optional: none (default) / ddl / mod / all ``` -La [composition Crossplane](https://github.com/Smana/cloud-native-ref/tree/main/infrastructure/base/crossplane/configuration/kcl/cloudnativepg) **SQLInstance** gère toute la complexité. +La [composition Crossplane](https://github.com/Smana/crossplane-configuration/tree/main/apis/sqlinstance) **SQLInstance** gère toute la complexité. Cette approche par composition offre plusieurs avantages : @@ -294,7 +294,7 @@ Voici ce que Vector fait concrètement - **transformation d'un log PostgreSQL au #### Pipeline en 3 Étapes -Le pipeline Vector se compose de **3 transforms** et **2 sinks** ([configuration complète](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/helmrelease-vlsingle.yaml#L62-L338)) : +Le pipeline Vector se compose de **3 transforms** et **2 sinks** ([configuration complète](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/helmrelease-vlsingle.yaml)) : **1. Parser les logs JSON CloudNativePG** ```vrl @@ -401,7 +401,7 @@ spec: hostname: "pev2" # Results in: pev2.priv.cloud.ogenki.io ``` -Pour garantir que les données sensibles de requêtes ne quittent jamais le réseau, pev2 est auto-hébergé dans le cluster via la composition [App](https://github.com/Smana/cloud-native-ref/tree/main/infrastructure/base/crossplane/configuration/kcl/app). Cela illustre encore une fois le **niveau d'abstraction de la plateforme** : déployer un outil web statique utilise la même API déclarative qu'une application complète avec base de données. +Pour garantir que les données sensibles de requêtes ne quittent jamais le réseau, pev2 est auto-hébergé dans le cluster via la composition [App](https://github.com/Smana/crossplane-configuration/tree/main/apis/app). Cela illustre encore une fois le **niveau d'abstraction de la plateforme** : déployer un outil web statique utilise la même API déclarative qu'une application complète avec base de données. ### Analyser avec Grafana @@ -467,7 +467,7 @@ Il s'agit, encore une fois, d'une démonstration de la **puissance des outils op L'abstraction apportée par **Crossplane** amplifie encore cette facilité. Grâce aux compositions `App` et `SQLInstance`, activer Performance Insights se résume à `performanceInsights.enabled: true` avec quelques paramètres d'ajustement (`sampleRate`, `minDuration`). Les développeurs/ses n'ont pas besoin de comprendre les internals PostgreSQL ni Vector—la plateforme masque la complexité. Cette même API déclarative déploie aussi bien une base de données complète qu'un outil web statique comme pev2, démontrant la cohérence du niveau d'abstraction. -Le projet [cloud-native-ref](https://github.com/Smana/cloud-native-ref) rassemble toutes ces pièces et montre comment Gateway API, Tailscale, Crossplane/KCL, et l'écosystème VictoriaMetrics s'assemblent pour créer une plateforme d'observabilité complète. +Le projet [cloud-native-ref](https://cnref.ogenki.io) rassemble toutes ces pièces et montre comment Gateway API, Tailscale, Crossplane/KCL, et l'écosystème VictoriaMetrics s'assemblent pour créer une plateforme d'observabilité complète — fonctionnant à la fois sur AWS EKS et GCP GKE. {{% notice note "Considération de Performance" %}} L'activation de Performance Insights implique un overhead estimé de **3-4% CPU** et **~200-250MB de mémoire** avec les valeurs par défaut : @@ -508,5 +508,5 @@ Les paramètres `sampleRate`, `log_timing` et `logStatement` permettent d'affine **Configuration et Implémentation** - [Configuration Vector VRL](https://github.com/Smana/cloud-native-ref/blob/main/observability/base/victoria-logs/README.md) - Pipeline de parsing des logs PostgreSQL -- [Composition CloudNativePG](https://github.com/Smana/cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/kcl/cloudnativepg/README.md) - Abstraction SQLInstance avec KCL -- [Architecture de Monitoring PostgreSQL](https://github.com/Smana/cloud-native-ref/blob/main/docs/postgresql-monitoring-architecture.md) - Documentation complète de l'architecture +- [Composition SQLInstance](https://github.com/Smana/crossplane-configuration/blob/main/apis/sqlinstance/kcl/README.md) - Abstraction CloudNativePG avec KCL, depuis le dépôt [crossplane-configuration](https://github.com/Smana/crossplane-configuration) +- [Architecture de Monitoring PostgreSQL](https://cnref.ogenki.io/docs/platform/observability/postgresql/) - Documentation complète de l'architecture diff --git a/content/fr/post/series/observability/runlore/index.md b/content/fr/post/series/observability/runlore/index.md index e20e60d1..4d209070 100644 --- a/content/fr/post/series/observability/runlore/index.md +++ b/content/fr/post/series/observability/runlore/index.md @@ -35,7 +35,7 @@ Pour conserver la connaissance en mémoire, j'ai choisi l'**OKF** (_Open Knowled * 🤖 Découvrir [**RunLore**](https://github.com/Smana/runlore) et son fonctionnement * 🧠 Ses **trois choix de conception** : un binaire simple, la **boucle d'apprentissage**, et l'**humain à la décision** -* 🛠️ Le **déployer** simplement avec Helm et le voir investiguer un **incident réel** sur [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref) +* 🛠️ Le **déployer** simplement avec Helm et le voir investiguer un **incident réel** sur [`cloud-native-ref`](https://cnref.ogenki.io) ## 🔥 Pourquoi ce projet : le coût caché de l'investigation @@ -143,7 +143,7 @@ Garder l'humain à la décision — sur ce qui est fait comme sur ce qui est app ## 👀 Voici ce que ça donne -Assez de théorie — voici RunLore **à l'œuvre**. L'incident ci-dessous a été réellement investigué sur [`cloud-native-ref`](https://github.com/Smana/cloud-native-ref), mon dépôt de référence : une plateforme complète sur **EKS** combinant Cilium, VictoriaMetrics, Crossplane et Flux. +Assez de théorie — voici RunLore **à l'œuvre**. L'incident ci-dessous a été réellement investigué sur [`cloud-native-ref`](https://cnref.ogenki.io), ma plateforme de référence : une stack complète combinant Cilium, VictoriaMetrics, Crossplane et Flux, qui tourne à la fois sur **AWS EKS** et **GCP GKE** — l'incident ci-dessous s'est produit sur le cluster AWS. {{% notice info "Le modèle derrière la démo 🧠" %}} Toute la démo tourne sur **GLM 5.2** (Zhipu AI, via l'API OpenAI-compatible de Z.ai) — une qualité **très proche des modèles frontière** (Claude, GPT) pour un **coût par token nettement inférieur**, décisif quand un agent branché sur Alertmanager peut lancer beaucoup d'investigations. RunLore acceptant n'importe quel endpoint OpenAI-compatible, **en changer tient en quelques lignes** — jusqu'à une [stack LLM auto-hébergée](/fr/post/series/agentic_ai/llm-self-hosted-stack/) (vLLM, Ollama) si tu veux tout garder dans ton périmètre. @@ -339,5 +339,5 @@ Je reviendrai donc avec un **retour d'expérience sur la durée**. D'ici là, le * [Open Knowledge Format (OKF) — Knowledge Catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog) * [Open Knowledge Format — annonce Google Cloud](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) * [Le pattern _LLM-wiki_ d'Andrej Karpathy](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) -* [cloud-native-ref — plateforme de référence](https://github.com/Smana/cloud-native-ref) +* [cloud-native-ref — documentation](https://cnref.ogenki.io) · [dépôt GitHub](https://github.com/Smana/cloud-native-ref) * [k8sgpt](https://github.com/k8sgpt-ai/k8sgpt) · [HolmesGPT](https://github.com/HolmesGPT/holmesgpt) · [kagent](https://github.com/kagent-dev/kagent) From 586eafec29ad95bae395bbc050a1ba4609bfb318 Mon Sep 17 00:00:00 2001 From: Smana Date: Fri, 28 Aug 2026 08:47:18 +0200 Subject: [PATCH 2/2] docs(crossplane): fix dead source links in the compositions post (en/fr) The compositions this 2023 post quotes were rewritten in KCL and moved to Smana/crossplane-configuration, so the file links 404'd (and the two that still resolved had drifted away from the snippets shown in the post). - Pin every file/directory link to 3d095df, the commit at publication time, so each caption shows the exact code quoted below it - Follow the demo-cloud-native-ref -> cloud-native-ref rename; the bare "here is the repo" links stay on live main - Fix a mislabelled caption: the SecurityGroupIngressRule / CIDRBlock block comes from sql-instance-composition.yaml (L85-L105), not irsa-composition.yaml - Note in the Sources callout that links are pinned, and point readers to crossplane-configuration for the current compositions --- .../crossplane_composition_functions/index.md | 18 ++++++++++-------- .../crossplane_composition_functions/index.md | 18 ++++++++++-------- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/content/en/post/crossplane_composition_functions/index.md b/content/en/post/crossplane_composition_functions/index.md index 0a308802..8b46079f 100644 --- a/content/en/post/crossplane_composition_functions/index.md +++ b/content/en/post/crossplane_composition_functions/index.md @@ -60,12 +60,14 @@ These steps are performed in a specific order: 3. Deployment of various configurations using the previously installed providers, especially the **`Compositions`** and **`Composition Functions`**. 4. Declarations of _Claims_ to consume the Compositions. -These steps are described through [Flux](https://fluxcd.io/)'s dependencies and can be viewed [here](https://github.com/Smana/demo-cloud-native-ref/tree/main/infrastructure/base/crossplane). +These steps are described through [Flux](https://fluxcd.io/)'s dependencies and can be viewed [here](https://github.com/Smana/cloud-native-ref/tree/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane). {{% notice tip "Sources" %}} -All the actions carried out in this article come from this [**git repository**](https://github.com/Smana/demo-cloud-native-ref). +All the actions carried out in this article come from this [**git repository**](https://github.com/Smana/cloud-native-ref). There you can find numerous sources that help me construct my blog posts. 🎄 🎁 Feedback is a gift 🙏 + +The file links below are pinned to the commit from the time of writing, so they show the exact code quoted here. The compositions have since been rewritten in KCL and moved to the [crossplane-configuration](https://github.com/Smana/crossplane-configuration) repository. {{% /notice %}} ## 📦 The Compositions @@ -87,7 +89,7 @@ Based on the [configuration-rds](https://github.com/upbound/configuration-rds) c ❓ How would this _Composition_ then be used if, for example, a developer wishes to have a database? They is simply done by declaring a _**Claim**_ which represents the level of abstraction exposed to the users. Let's get a closer look 🔍 -[tooling/base/harbor/sqlinstance.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/tooling/base/harbor/sqlinstance.yaml) +[tooling/base/harbor/sqlinstance.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/tooling/base/harbor/sqlinstance.yaml) ```yaml apiVersion: cloud.ogenki.io/v1alpha1 @@ -118,7 +120,7 @@ Here we observe that it boils down to a **simple** resource with few parameters * A **PostgreSQL** instance version 15 will be created. * The **instance type** is at the discretion of the platform team (the maintainers of the composition). In the above `Claim`, we ask for a small instance, which is interpreted by the composition as `db.t3.small`. -[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L150C18-L150C18) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L150C18-L150C18) ```yaml transforms: - type: map @@ -128,7 +130,7 @@ transforms: small: db.t3.small ``` -* The `master` user's password is retrieved from a `harbor-pg-masterpassword` secret, retrieved from an [External Secret](https://github.com/Smana/demo-cloud-native-ref/blob/main/tooling/base/harbor/externalsecret-sqlinstance-password.yaml). +* The `master` user's password is retrieved from a `harbor-pg-masterpassword` secret, retrieved from an [External Secret](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/tooling/base/harbor/externalsecret-sqlinstance-password.yaml). * Once the instance is created, the connection details are stored in a **secret** `xplane-harbor-rds`. This is where we can fully appreciate the **power of Crossplane Compositions**! Indeed, **many resources** are provisionned under the hood, as illustrated by the following diagram: @@ -166,7 +168,7 @@ The [**EnvironmentConfigs**](https://docs.crossplane.io/latest/concepts/environm Since the EKS cluster is created with [Opentofu](https://opentofu.org/), we store its properties using Flux variables. (more info on Flux's variables substitution [here](https://blog.ogenki.io/post/terraform-controller/#substition-de-variables)) -[infrastructure/base/crossplane/configuration/environmentconfig.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/environmentconfig.yaml) +[infrastructure/base/crossplane/configuration/environmentconfig.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/environmentconfig.yaml) ```yaml apiVersion: apiextensions.crossplane.io/v1alpha1 @@ -187,7 +189,7 @@ data: These variables can then be used in _Compositions_ via the **`FromEnvironmentFieldPath`** directive. For instance, to allow pods to access our RDS instance, we allow the VPC's CIDR as follows: -[infrastructure/base/crossplane/configuration/irsa-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/irsa-composition.yaml) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L85-L105) ```yaml - name: SecurityGroupIngressRule @@ -218,7 +220,7 @@ These functions are executed in a **sequential** manner (in `Pipeline` mode), wi But **let's get back to our RDS composition 🔍!** It indeed uses this new way of defining `Compositions` and consists of three steps: -[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml) ```yaml apiVersion: apiextensions.crossplane.io/v1 diff --git a/content/fr/post/crossplane_composition_functions/index.md b/content/fr/post/crossplane_composition_functions/index.md index 27997352..cd813266 100644 --- a/content/fr/post/crossplane_composition_functions/index.md +++ b/content/fr/post/crossplane_composition_functions/index.md @@ -56,12 +56,14 @@ Ces étapes sont réalisées dans un ordre bien précis: 3. Déploiement de diverses configurations faisant usage des providers installés préalablement. Notamment les **`Compositions`** et les **`Composition Functions`**. 4. Déclarations de _Claims_ pour consommer les Compositions. -Ces étapes sont traduites en dépendances [Flux](https://fluxcd.io/), et peuvent être consultées [ici](https://github.com/Smana/demo-cloud-native-ref/tree/main/infrastructure/base/crossplane). +Ces étapes sont traduites en dépendances [Flux](https://fluxcd.io/), et peuvent être consultées [ici](https://github.com/Smana/cloud-native-ref/tree/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane). {{% notice tip "Les sources" %}} -Toutes les actions réalisées dans cet article proviennent de ce [**dépôt git**](https://github.com/Smana/demo-cloud-native-ref) +Toutes les actions réalisées dans cet article proviennent de ce [**dépôt git**](https://github.com/Smana/cloud-native-ref) On peut y trouver de nombreuses sources qui me permettent de construire mes articles de blog. N'hésitez pas à me faire des retours, ouvrir des issues si nécessaire ... 🙏 + +Les liens vers les fichiers ci-dessous pointent vers le commit de l'époque, afin de montrer exactement le code cité ici. Les compositions ont depuis été réécrites en KCL et déplacées dans le dépôt [crossplane-configuration](https://github.com/Smana/crossplane-configuration). {{% /notice %}} ## 📦 Les compositions @@ -83,7 +85,7 @@ En me basant sur la composition [configuration-rds](https://github.com/upbound/c ❓ Comment cette _Composition_ serait-elle alors utilisée si, par exemple, un développeur souhaite disposer d'une base de données? Il suffit de déclarer une _**Claim**_ qui représente le niveau d'abstraction exposé aux utilisateurs. -[tooling/base/harbor/sqlinstance.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/tooling/base/harbor/sqlinstance.yaml) +[tooling/base/harbor/sqlinstance.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/tooling/base/harbor/sqlinstance.yaml) ```yaml apiVersion: cloud.ogenki.io/v1alpha1 @@ -115,7 +117,7 @@ ici nous constatons que cela se limite à une **simple** ressource avec peu de p * Une instance **PostgreSQL** en version 15 sera créée * La **type d'instance** de celle-ci est laissé à l'appréciation de l'équipe plateforme (les mainteneurs de la composition). Dans la `Claim` ci-dessus nous souhaitons une "petite" instance, qui est traduit par la composition en `db.t3.small`. -[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L150C18-L150C18) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L150C18-L150C18) ```yaml transforms: @@ -126,7 +128,7 @@ transforms: small: db.t3.small ``` -* Le mot de passe de l'utilisateur `master` est extrait d'un secret `harbor-pg-masterpassword`, généré via un [External Secret](https://github.com/Smana/demo-cloud-native-ref/blob/main/tooling/base/harbor/externalsecret-sqlinstance-password.yaml). +* Le mot de passe de l'utilisateur `master` est extrait d'un secret `harbor-pg-masterpassword`, généré via un [External Secret](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/tooling/base/harbor/externalsecret-sqlinstance-password.yaml). * Une fois l'instance créée, les détails pour la connexion sont stockés dans un **secret** `xplane-harbor-rds` C'est là que nous pouvons pleinement apprécier la **puissance des Compositions** Crossplane! En effet, de **nombreuses ressources** sont générées de manière transparente, comme illustré par le schéma suivant : @@ -163,7 +165,7 @@ Les [**EnvironmentConfigs**](https://docs.crossplane.io/latest/concepts/environm Étant donné que le cluster EKS est créé avec [Opentofu](https://opentofu.org/), nous stockons ses propriétés par le biais de variables Flux. (plus d'infos sur les variables de substitution [ici](https://blog.ogenki.io/fr/post/terraform-controller/#substition-de-variables)) -[infrastructure/base/crossplane/configuration/environmentconfig.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/environmentconfig.yaml) +[infrastructure/base/crossplane/configuration/environmentconfig.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/environmentconfig.yaml) ```yaml apiVersion: apiextensions.crossplane.io/v1alpha1 @@ -184,7 +186,7 @@ data: Ces variables peuvent ensuite être utilisées dans les _Compositions_ via la directive **`FromEnvironmentFieldPath`**. Par exemple pour permettre aux pods d'accéder à notre instance RDS, nous autorisons le CIDR du VPC: -[infrastructure/base/crossplane/configuration/irsa-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/irsa-composition.yaml) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml#L85-L105) ```yaml - name: SecurityGroupIngressRule @@ -214,7 +216,7 @@ Ces fonctions sont exécutées de manière **séquentielle** (mode `Pipeline`), Mais **revenons à notre composition RDS 🔍 !** Celle-ci utilise, en effet, cette nouvelle façon de définir des `Compositions` et est composée de 3 étapes: -[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/demo-cloud-native-ref/blob/main/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml) +[infrastructure/base/crossplane/configuration/sql-instance-composition.yaml](https://github.com/Smana/cloud-native-ref/blob/3d095dfb726b941d15d8ef6768211a6880170cee/infrastructure/base/crossplane/configuration/sql-instance-composition.yaml) ```yaml apiVersion: apiextensions.crossplane.io/v1