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/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/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 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)