Garambrogne 2.0

Learning Pyxel: Fleeing Danger and Game Over

2026-01-28T18:15:00+01:00

Third chapter of learning Pyxel, a retro game framework with its engine in Rust (for fluidity) and its API in Python (for simplicity

This demo progresses in difficulty, with new Python concepts and the risk of getting your character killed.

The demo goes beyond the world of sprites by drawing a line (which fortunately remains pixelated).

Demo

In this demo, a hero explores a dungeon and encounters a beholder. The monster will aim, shoot, while the hero attempts to dodge.

The player will use their keyboard to control the hero.

Assets

The sprites are organized: by rows, the characters (and their states), by columns, the direction: bottom (front), left, right, top (back).

The warrior has one additional sprite: electrocution.

The Hero Walks Around

The warrior can walk around with the keyboard arrows, turning in the right direction.

Python Concepts

List Comprehension

To create collections (including lists), Python has a condensed syntax.

The following code:

a = [i for i in range(4)]

Is equivalent to:

a = []
for i in range(4):
    a.append(i)

Technically, adding elements to a list is more expensive than the dense syntax.

Demo

A constant, TRANSPARENT , is used to designate the transparency color, without having to copy it throughout the code and to facilitate readability.

A character has a speed attribute that corresponds to its movement in pixels, each frame.

The images are ordered, the angle attribute simultaneously describes which way the character is looking, and its rank in the image row.

The move method moves the character one step (the speed attribute), in the right direction.

To avoid a slew of ifs, a multiplier is used:

0: nothing
1: forward
-1: backward

However, to prevent the character from leaving the screen, a bunch of ifs is needed.

The App class is very classic, the keyboard arrows are used to move (with move) the character in the right direction.

import pyxel

TRANSPARENT = 11


class Hero:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self):
        return self._images[self.angle]

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="The hero explores")  # width, height, title
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_DOWN):
            self.hero.move(0)
        if pyxel.btn(pyxel.KEY_LEFT):
            self.hero.move(1)
        if pyxel.btn(pyxel.KEY_RIGHT):
            self.hero.move(2)
        if pyxel.btn(pyxel.KEY_UP):
            self.hero.move(3)

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()


App()

The Hero Walks in Front of the Beholder Who Follows with Its Gaze

Python Concepts

Class Inheritance

Two characters are described by two classes, and since they have quite a bit in common (they are sprites with a direction).

A class can inherit from another class. The parent class defines attributes and methods, child classes can have their own attributes/methods or override an element of the parent class.

class Parent:
  def hello(self, txt):
    print("hello", txt)

class Child(Parent):
  def hello(self, txt):
    print("wazza", txt)

It’s possible for an overridden method to call the method of an ancestor with the super() function.

class Parent:
    def say(self, txt):
        return "I say " + txt

class Child(Parent):
    def say(self, txt):
        return super().say(txt) + ", or not"

Overriding a method can be mandatory if the parent method raise a NotImplementedError exception.

class Parent:
    def override_me:
      raise NotImplementedError

multiple assignment

Multiple assignement get a condensed syntax too.

a, b = 1, 2

Is equivalent to:

a = 1
b = 2

Typing

Python has typing for its values, but not strong typing: a variable can be reassigned with a value of a different type.

Python uses hints to make the type of a variable explicit. Python maintains backward compatibility: the hints are not taken into account by the interpreter. Typing is intended (among other things) for static analysis (a bot reads and gives its opinion on your code).

Modern editors take typing into account for their suggestions, and to complain (underline in red) about parts of your code that don’t respect the typing.

a :int # a is an integer

Ternary operators

Python get a condensed syntax for value assignement with a condition.

if dx > 0:
    angle = 1
else:
    angle = 2

become:

angle = 1 if dx > 0 else 2

Value 1, if, clause, else, value 2.

Be careful not to overuse dense syntax which can destroy readability.

Demo

The basic behaviors of Hero are now in the Sprite class which will be the parent class of Hero and Beholder.

The Beholder class has a state attribute, and uses 2 rows of images. state allows knowing which row to use, the direction remains the column as in the previous demo (used in the image method).

The beholder can glare at a target with the watch method.

A bit of math: we calculate the delta between the two characters on the horizontal and vertical axis, dx and dy. If the horizontal distance is greater than the vertical distance, the beholder looks horizontally. If dx is positive, it looks left, otherwise right. Same thing for the vertical axis.

In the App class, the update method specifies that the space key activates the LOADING state of the beholder (it looks up), and that it watches the nero.

import pyxel

TRANSPARENT = 11
# Beholder states
LOADING = 0
WAITING = 3


class Sprite:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed: int
        self.angle: int  # bottom, left, right, top
        self.state: int

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self) -> tuple[int, int, int, int, int]:
        # What is the current image
        raise NotImplementedError

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class Beholder(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.angle = 1
        self.speed = 2
        self.state = WAITING
        # The beholder can be normal : waiting, aiming, moving…
        self._main_images = [(i * 16, 0, 16, 16, TRANSPARENT) for i in range(4)]
        # The beholder loads its death ray
        self._loading_images = [(i * 16, 16, 16, 16, TRANSPARENT) for i in range(4)]

    def watch(self, target: Sprite):
        dx, dy = self.x - target.x, self.y - target.y
        if abs(dx) > abs(dy):
            self.angle = 1 if dx > 0 else 2
        else:
            self.angle = 3 if dy > 0 else 0

    def image(self):
        if self.state == LOADING:
            return self._loading_images[self.angle]
        else:
            return self._main_images[self.angle]


class Hero(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]

    def image(self):
        return self._images[self.angle]


class App:
    def __init__(self):
        # width, height, title
        pyxel.init(160, 120, title="The beholder watch the hero")
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        self.beholder = Beholder(128, 32)
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_DOWN):
            self.hero.move(0)
        if pyxel.btn(pyxel.KEY_LEFT):
            self.hero.move(1)
        if pyxel.btn(pyxel.KEY_RIGHT):
            self.hero.move(2)
        if pyxel.btn(pyxel.KEY_UP):
            self.hero.move(3)

        if pyxel.btn(pyxel.KEY_SPACE):
            self.beholder.state = LOADING
        else:
            self.beholder.state = WAITING
        self.beholder.watch(self.hero)

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()
        self.beholder.draw()


App()

The Beholder Tries to Strike the Hero with Lightning

Python Concepts

No new python concepts in this chapter, math calculus are boring enough.

Demo

The hero and the monster now have the state attribute which designates (obviously) the state.

The beholder sprites are arranged on two rows:

The second when it prepares its shot (it looks up)
The first for the other states (waiting and shooting)

The hero has one more column, the electrocuted state, which has no direction.

All this is handled by the image method.

To give the hero a chance, the beholder aims at the current position of the hero, in the aim method, waits a bit, the time to charge its death ray, then shoots where the hero WAS, the shoot method.

The ray is instantaneous, but it shoots late. If the hero hasn’t moved enough, it dies.

The start and end of the ray are from the center of the sprites, not from the top left corner.

To know if the hero is hit, we don’t just consider its center (hit right in the heart?), but we determine the face of its sprite that faces the beholder. If the ray touches even one of its toes, the character is fried.

The ray is interrupted by the hero, if it touches it, otherwise, it stops at the edge of the screen.

To avoid getting lost in unreadable if statements, a 3x3 grid is used:

the middle row corresponds to a vertical shot
the middle column has a horizontal shot
the center has a shot into its own foot
the other cells correspond to combinations of left/right, up/down

This is where the heap of math lines begins. We start by calculating the slope of the shot, then we handle the case where the slope is zero, then we check if the hero is hit laterally, or vertically. If it’s hit, the ray stops at the point of impact, the hero switches to the ZAPPED state and the ray changes color.

The shot is drawn with Pyxel’s line function.

In the App, no math. The arrows no longer move the hero when it’s dying. After 30 frames of pain, the game quits.

The beholder cycles every 40 frames, it aims at frame 10, shoots at frame 30.

import pyxel

TRANSPARENT = 11

# Beholder states
LOADING = 0
FIRING = 1
MOVING = 2
WAITING = 3

# Hero states
HEALTHY = 0
ZAPPED = 1


class Sprite:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed: int
        self.angle: int  # bottom, left, right, top
        self.state: int

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self) -> tuple[int, int, int, int, int]:
        # What is the current image
        raise NotImplementedError

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class Beholder(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.angle = 1
        self.speed = 2
        self.state = WAITING
        # The beholder can be normal : waiting, aiming, moving…
        self._main_images = [(i * 16, 0, 16, 16, TRANSPARENT) for i in range(4)]
        # The beholder loads its death ray
        self._loading_images = [(i * 16, 16, 16, 16, TRANSPARENT) for i in range(4)]
        # Where the beholder aims
        self._aim_dx: int
        self._aim_dy: int

    def image(self):
        if self.state == LOADING:
            return self._loading_images[self.angle]
        else:
            return self._main_images[self.angle]

    def watch(self, target: Sprite):
        dx, dy = self.x - target.x, self.y - target.y
        if abs(dx) > abs(dy):
            self.angle = 1 if dx > 0 else 2
        else:
            self.angle = 3 if dy > 0 else 0

    def aim(self, target: Sprite):
        self.state = LOADING
        self._aim_dx, self._aim_dy = self.x - target.x, self.y - target.y

    def shoot(self, target: Sprite):
        self.state = FIRING
        # The ray starts avec self.x, self.y
        x_end: float  # horizontal end of the ray
        y_end: float  # vertical end of the ray

        # Center of the shooter
        shooter_x, shooter_y = self.x + 8, self.y + 8
        # Center of the target
        target_x, target_y = target.x + 8, target.y + 8
        # Side hit by the shot
        target_side_x = target_x + pyxel.sgn(self._aim_dx) * 8
        target_side_y = target_y + pyxel.sgn(self._aim_dy) * 8

        # Where the ray ends when it misses ?

        cross = [  # x, y
            [(pyxel.width, pyxel.height), (pyxel.width, shooter_y), (pyxel.width, 0)],
            [(shooter_x, pyxel.height), (None, None), (shooter_x, 0)],
            [(0, pyxel.height), (0, shooter_y), (0, 0)],
        ]
        x_end, y_end = cross[pyxel.sgn(self._aim_dx) + 1][pyxel.sgn(self._aim_dy) + 1]

        if x_end is None:  # It shoots its own foot
            return

        x_hit, y_hit = shooter_x, shooter_y
        if self._aim_dx != 0:
            slope = self._aim_dy / self._aim_dx
            y_end = (x_end - shooter_x) * slope + shooter_y
            y_hit = (target_side_x - shooter_x) * slope + shooter_y
            if slope != 0:
                x_end = (y_end - shooter_y) / slope + shooter_x
                x_hit = (target_side_y - shooter_y) / slope + shooter_x
        if abs(target_x - x_hit) <= 8:
            x_end, y_end = x_hit, target_side_y
            target.state = ZAPPED
        if abs(target_y - y_hit) <= 8:
            x_end, y_end = target_side_x, y_hit
            target.state = ZAPPED
        bolt_color = 10 if target.state == ZAPPED else 6
        pyxel.line(shooter_x, shooter_y, x_end, y_end, bolt_color)


class Hero(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]
        self._zapped_images = [
            (64, 32, 16, 16, TRANSPARENT),
            (64, 32, -16, 16, TRANSPARENT),
        ]
        self.state = HEALTHY

    def image(self):
        if self.state == HEALTHY:
            return self._images[self.angle]
        elif self.state == ZAPPED:
            return self._zapped_images[pyxel.frame_count % 2]


class App:
    def __init__(self):
        # width, height, title
        pyxel.init(160, 120, title="The beholder and its beam of death")
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        self.beholder = Beholder(128, 32)
        self.game_over = 0
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if self.hero.state == ZAPPED:  # Everything is frozen when the hero is zapped
            if self.game_over == 0:
                self.game_over = pyxel.frame_count
            else:
                if pyxel.frame_count - self.game_over == 30:
                    pyxel.quit()
        else:
            if pyxel.btn(pyxel.KEY_DOWN):
                self.hero.move(0)
            if pyxel.btn(pyxel.KEY_LEFT):
                self.hero.move(1)
            if pyxel.btn(pyxel.KEY_RIGHT):
                self.hero.move(2)
            if pyxel.btn(pyxel.KEY_UP):
                self.hero.move(3)

            self.beholder.watch(self.hero)
            if pyxel.frame_count % 40 == 10:  # Every 50 frames, the beholder aims
                self.beholder.aim(self.hero)
            if pyxel.frame_count % 40 == 30:  # 25 later, it shoots
                self.beholder.state = FIRING

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()
        if self.beholder.state == FIRING:
            self.beholder.shoot(self.hero)
        self.beholder.draw()
        if self.hero.state == ZAPPED:
            pyxel.text(60, 10, "GAME OVER", 7, None)


App()

The sources of Beholder are available on Github.

You can test the online version of Beholder Demo Online

What’s Next

The shot kills the hero in one hit, we could use a health bar system that decreases with each shot, as well as a loading bar for the beholder’s shot preparation.

The hero cannot retaliate, what injustice. There would need to be sprites with a sword that strikes (a forward lunge?), with a (short) waiting time during an attack that prevents it from moving.

A HUUUUUUM sound during charging, then ZAAAAP during shooting, a GZZZZZ during electrocution seems essential to me.

Uncloud, self hosted Cloud, seen by a developer for developers

2026-01-05T09:17:00+01:00

Uncloud

Uncloud defines itself as a non-cloud, similar to Heroku or Render, open-source and targeting self-hosting.

Comparing a self-hosted cloud service to these vintage pre-Docker SAAS is weird. OK, with all these services, you can push your container without any sysadmin involvement, without configuring (almost) anything.

Uncloud is built during the Docker era, embracing Compose, without any bloat or patronizing developers.

One more point, the elephant in the room, Kubernetes, the hegemonic solution for hosting containers (spoiler: the main developer has a great experience with K8s for small projects). Uncloud sees itself as a Citroën 2CV compared to K8s, as a semi-trailer.

Adminless

With Uncloud, you can manage your production environment like your development laptop. This sentence is terrifying.

But, with a bit of rigor, this approach is credible; Uncloud handles a large part of the work with minimal voodoo magic.

Beware, if you bypass sysadmin, you have to fix online incidents (and updates and backup and fine tunings and a lot of surprises).

Scaleless

Uncloud is hosting agnostic, you can even mix different hostings. VPS, bare metal, self-hosting, mixing processor families (yikes!).

It creates a large virtual encrypted network (with Wireguard), and every container can communicate with each other on all servers.

Let’s recall that the product is Australian, which has neither a large number of local users nor an ultimate network connection with the rest of the world. Having distributed nodes close to clients is more important for them than for a French person who struggles to think beyond their metropolitan area (and Europe for the most ambitious).

Self-hosting is perfectly acceptable, as long as you have enough bandwidth to serve your users. Remember, cheap hosting is, well, cheap, and doesn’t blow 24/7 in your living room (or in a closet).

Mixing local and remote hosting is weird, perhaps to benchmark your fancy Nvidia card for a vital AI feature ? Sure, give it a try, tokens aren’t cheap, and local datas can’t be used/sold somewhere in the Silicon Valley.

Brainless

Uncloud is just one command, uc, which mimics the docker command. You can even use docker-compose.yml files (with some additional information).

Containers registries are boring to manage. Uncloud push images directly to the remote server, throught SSH (layers by layers, not an ugly full image wrapped in tgz archive).

The neologism is pussh, classy.

By default, the container is pushed somewhere in your cluster, randomly (without packing complexity). If your containers are heterogeneous (CPU, RAM, bandwidth, storage), good luck. OK, you can target one or more specific servers (basic load balancing is provided). Using Docker Compose, you can set lots of options, like the number of replicas. It’s a cleaner deployment strategy.

Deployment is guaranteed to be uninterrupted, following the well-known blue/green or rollup strategies.

You can name your servers with the free *.cluster.uncloud.run domain. Just add a DNS alias with your own domain. The documentation is not ready yet; you have to wait.

Let’s Encrypt (via Caddy) provides free TLS certificates.

Firewall blocks everything, you can’t oops a container, exposing a naked service to the Internet. Not everything, HTTP/HTTPS/SSH/Wireguard services are public. Uncloudd (the server side) is used throught SSH.

The deployment procedure is something like that:

Works for me
Push to production (the fresh container is started, the old one is stopped)
If something goes wrong, we immediately have the logs to understand the cause of the oops
Quick fix
Re-deployment
Break for a game of foosball.

Dissection

It sounds great, but what is the secret sauce, the technical choices?

The first rule of Uncloud is decentralization. All nodes provide the same uncloudd service, without specialization or an orchestrator.

Uncloud doesn’t use configurations and promises to consume only 150MB of RAM per node.

Remote API

All services use grpc, with the official REST grpc-gateway.

Grpc services accept different transport layers (and wrappers) :

SSH tunnel (native or ssh command)
Wireguard tunnel
TCP
UNIX socket

SSH is the default option (remember the admin motto: “in ssh we trust”).

Containerization

Uncloud is built on Docker : system services are containers, user services are containers too. The API use containerd for low level features (and it uses GRPC).

Images are not centralized; everything is pushed directly to the target via the unregistry subproject.

Bypassing the registry is cheating. Github and Gitlab provide a free registry, one of the steps to continuous deployment. This is not the way. Uncloud is an autonomist; no external services can be mandatory. The temptation of streamlining the technical stack, removing moving parts, is the path to robustness.

Container configuration uses configuration files accessed from volumes.

Environment variables are not available yet, which is a crime according to 12Factors.

Private Network

Private network management on a Cloud is a punishment.

Uncloud picks Wireguard (https://www.wireguard.com/) for linking all servers, and iptable for routing, just like Tailscale (https://tailscale.com/). The obvious answer for kniting networks between scattered Linux servers.

IP are neatly arranged, with subnetworks.

The (eventualy) consistency is assumed by Corrosion (https://github.com/superfly/corrosion), a competitor to Consul, created by Fly.io for large clusters.

An internal DNS allows access to everything, following naming conventions.

Ingress

Caddy is the HTTP/HTTPS gateway. It provides load balancing, dead node eviction, TLS certificates with Let’s Encrypt, and HTTP/3.

Caddy is deployed on each node, leaving the public DNS to choose an entry point.

High Availability

Qorums (sufficient electors within the cluster) terrorize Uncloud. User must be able to use Uncloud, even if the cluster is broken.

In the CAP theorem, Uncloud sacrifices consistency (for availability and performance), hoping that data will reconcile once all cluster members are reunited.

This is an opinionated choice. But, Uncloud clusters are very small, with explicit service placement, local IP are locally managed, and dead nodes are handled by an internal load balancer.

Without self-healing (spawning services instances on healthy nodes), handling node crash can be minimalistic.

Critics

Uncloud assumes not to be production-ready, yet.

Beta software can’t be torn apart with criticism, it’s not fair.

Uncloud is a (almost) one-man project, even if the developer is talented and maintains exemplary documentation. For the perenity of his project, he’ll have to look at both sides before crossing the road.

Uncloud is not concerned by Infrastructure as Code or CI/CD, by design. You are a big boy; you can do IAC/CI/CD, by yourself, Uncloud doesn’t care. Remember, it’s a project targeting developers. IAC/CI/CD are great, but are seen as wasted time for a freelancer on solo projects. This strategy is called “one-man deployment.”

Cluster management is not dry yet. Mixing Corrosion (a rust project), with IPFS CRDT storage, is weird. Consul is the obvious answer for cluster management, but IBM is slowly strangling Hashicorp’s products, what a pity. Sharing states and groups with gossip is the first step, but what is the purpose of a cluster without self-healing ? a federation?

Fault tolerance relies on a (free) DNS service, which is a single point of failure (SPOF) that will cause problems for everyone due to time-to-live (TTL) issues.

Like all distributed hosting offerings that promise fault tolerance, the persistence aspect is conveniently avoided.

Is persistence in the scope of a cluster application? Maybe not, but it’s mandatory for the user.

The documentation should give some leads:

Redis Cluster for sessions
Minio for file storage

These two services have the advantage of being largely self-sufficient. For databases, it’s a different story. You either have to compromise with exotic databases like Litefs, Scylladb, or Foundationdb… or handle primary/secondary replication of traditional relational databases (without any magic).

The user-centric approach to data persistence immediately shatters the “elegant simplicity” of Uncloud.

Before complaining, start by having a proper backup procedure, WITH RESTORE TESTING; that would be a good start.

Otherwise, claiming that Uncloud is virtuously sustainable simply because it’s less resource-intensive than Kubernetes is rather petty.

The Aftermath

Uncloud already has the wow effect (and visibility), which is a major achievement for a solo developer. Have a look at the Hacker News thread.

Given its current strategy, Uncloud will likely generate limited revenue, essentially selling its technical expertise.

The choice of targeting “solo developers, small projects, discount hosting” also won’t help monetization. Communication agencies will love it, without giving a dime.

Please, Uncloud, give a more ambitious example than the infamous WordPress+Mariadb combo.

Therefore, it’s essential to hope for some form of sponsorship.

In any case, anything that shakes things up and challenges admins, DevOps engineers, and other cloud worshippers is refreshing, even if the proposal ultimately falls flat (I hope not).

A project to watch and encourage!

Uncloud, le cloud dégraissé par les devs

2025-12-09T09:17:00+01:00

Uncloud

Uncloud se présente comme un non-cloud un service ressemblant à Heroku ou Render, mais aux sources ouvertes. Le seul point commun que je vois dans ces références est la possibilité de bazarder des conteneurs en prod sans passer par la case adminsys, mais avec la promesse de la montée à l’échelle, le Graal de toute bonne startup. La comparaison avec des services vieillissants est étrange, et même peu flatteuse en vue de l’ambition technique de Uncloud.

L’autre comparaison, l’éléphant dans le couloir, est Kubernetes. Uncloud se présente comme une deux chevaux face à K8s le semi remorque de 38 tonnes.

Adminless

Uncloud permet de gérer sa prod comme son poste de dev. Cette phrase est terrifiante. Mais, avec un peu de rigueur, cette approche est crédible, Uncloud assume une grosse partie du travail, avec le minimum de magie vaudou.

Si on vire les adminsys de l’équation, il faut assumer la correction des incidents en ligne (et les mises à jour, et les sauvegardes, et la configuration fine bas niveau et plein d’autres surprises).

Scaleless

Uncloud est conçu pour ne pas se soucier de l’hébergement, et même d’avoir plusieurs hébergeurs, ou même de l’auto-hébergement. Il crée un grand un réseau virtuel chiffré (avec Wireguard), et tout le monde peut causer avec tout le monde, sur tous les serveurs.

Rappelons que le produit est australien, qui n’ont ni des tonnes d’utilisateurs locaux, ni une connexion réseau ultime avec le reste du monde. Avoir des noeuds distribués proches des clients est plus important pour eux que pour un français qui a du mal à se projeter au dela de la métropole (et de l’Europe pour les plus ambitieux).

L’auto-hébergement est honorable, tant qu’on a la bande passante suffisante pour servir ses utilisateurs, mais l’hébergement à pas cher est, euh, pas cher, et ne souffle pas h24 dans votre salon (ou un placard). Mixer hébergement local et distant est difficilement justifiable, peut-être pour bencher votre jolie carte NVidia en proposant une indispensable fonctionnalité cloud sans vous ruiner en token (ou sans offrir vos données à la Silicon Valley).

Brainless

Uncloud expose une commande, uc qui permet d’agir comme on le ferait avec docker, et même d’utiliser des docker-compose.yml (avec quelques informations complémentaires).

Pour ne pas avoir à gérer un registre de conteneur (ça sonne mieux en anglais : container registry), ce qui peut effectivement être pénible, les images sont directement poussées sur la cible, en SSH, créant ainsi le néologisme pussh.

Uncloud fournit gracieusement un DNS en *.cluster.uncloud.run qui avec un simple alias depuis votre nom de domaine vous permettra d’avoir une résolution de nom en tourniquet (Round Robin DNS).

Lets-encrypt (via Caddy) fournit le certificat TLS.

Toutes les interactions avec les serveurs passent par SSH, même le débug.

Les conteneurs sont déployés sur une machine explicite, et s’il y a plusieurs instances d’un service, une répartition de charge (load balancing) se met en place spontanément.

Le déploiement est promis sans interruption, la fameuse stratégie bleu/vert.

Le réseau privé évite qu’un service soit exposé par accident sur Internet (seuls les ports SSH, HTTP et HTTPS sont accessibles).

La procédure de déploiement est donc :

Chez moi ça marche
Pousse en prod
Si ça pète, on a tout de suite les logs pour comprendre la cause du oups
Correction à l’arrache
Repousse
Pause au babyfoot

Dissection

Les promesses de la plaquette sont bien belles, mais qu’en est-il techniquement ?

Un des concepts de bases, si ce n’est l’unique, est la décentralisation, tous les noeuds fournissent le même service uncloudd, sans spécialisation, sans chef.

Uncloud n’utilise pas de configurations, et promet de ne consommer que 150MB de RAM par noeud.

API réseau

Tous les services sont en grpc, avec la passerelle REST officielle : grpc-gateway.

Le client utilise une connexion ssh pour causer en grpc, ce qui simplifie la gestion des droits.

Conteneurisation

Docker est évidement la brique de base de ce non-cloud, avec en interne des appels directement à Containerd.

Les images ne sont pas centralisées, tout est poussé directement sur la cible, via le sous projet unregistry.

Ce petit sacrilège est bien tentant pour simplifier une pile technique, même si Github/Gitlab fournit des registry privées.

La configuration des conteneurs se fait par des fichiers de conf accédés depuis des volumes. Pour l’instant la configuration via les variables d’environnement n’est pas disponible, ce qui est un crime selon 12 factors.

Réseau privé

La gestion du réseau privé est l’élément le plus complexe de la pile technique.

Wireguard permet de relier les différents noeuds, avec des sous réseaux bien rangés, et du routage. Même choix technique que Tailscale, gage de sérieux.

La coordination des différents noeuds du réseau passe par Corrosion, un concurrent de Consul, crée par Fly.io. Écrit en Rust (what else ?) il expose une base de données sqlite avec la possibilité de s’abonner à une requête SQL.

Un DNS interne permet d’accéder à tout, en suivant des conventions de nommage.

La persistance de la config réseau utilise le datastore CRDT d’IPFS, même si Corrosion propose la même chose et que d’autres pistes sont explorées.

Ingress

Caddy a été choisi comme passerelle HTTP/HTTPS, même si Traefik est aussi évoqué dans le wiki. Il prend en charge le load balancing, l’éviction des noeuds morts, les certificats TLS avec Letsencrypt et HTTP/3.

Caddy est déployé sur chacun des noeuds, laissant au DNS (public) le choix d’un point d’entrée.

Haute disponibilité

Uncloud est terrorisé par les quorums (suffisamment d’électeurs au sein du cluster) qui pourraient empêcher la modification de l’état du cluster.

Dans le théorème CAP, il sacrifie le C, la cohérence des données, et prie pour que les données vont se réconcilier une fois que tous les membres du cluster sont de nouveaux réunis.

Sur le papier, ça ressemble à un choix de lapin apeuré. Concrètement, les clusters Uncloud seront de taille ridicule, avec des services déployés explicitement sur des noeuds n’utilisant que très peu les instances multiples avec répartition de charge.

Tant que le projet Uncloud n’a pas fait le ménage dans la partie gossip et état distribué, il n’a aucune légitimité à faire de pareilles affirmations.

La notion de haute disponibilité de Uncloud est un peu une blague : il ne sait pas re-ventiler les services d’un noeud qui a crashé ou en lancer de nouveau pour accompagner une montée en charge.

Critiques

Uncloud n’est officiellement pas prêt pour de la prod, ce qui limite la possibilté de le défoncer à coups de critiques.

Uncloud est le projet d’un seul homme (one man project), même s’il est talentueux et maintient une documentation exemplaire. Il va falloir qu’il regarde bien des deux cotés avant de travers la route.

Les sources contiennent des paramètres spécifiques à la machine du développeur, même si ce n’est qu’un détail. Le déploiement des services est sauvage (il pousse d’office un binaire docker sur les noeuds).

La notion d’Infra As Code ou de CI/CD ne semble pas l’intéresser, mais c’est un raccourci tentant pour un freelance qui ne fait que des missions en solo. On peut parler de “one man deployment”.

La notion de multitenant ou même d’isolation de différents projets ne paraissent pas effleurer le développeur. C’est un challenge intéressant pour la couche réseau.

La tolérance de panne passe par un service DNS (gratis) est un SPOF qui va embêter tout le monde avec les temps de diffusion (TTL).

Comme toutes les offres d’hébergement distribué avec promesse de tolérance de panne, la partie persistance est planquée sous le tapis. Il faudrait au moins évoqué dans la documentation l’intérêt de Redis-cluster pour les sessions, Minio pour le stockage de fichiers. Ces deux services ont le bon gout de se débrouiller à peu près tout seul. Pour les bases de données, ce n’est pas la même histoire, il faut soit faire des compromis avec des bases exotiques : litefs, scylladb, foundatoindb … ou assumer la réplication primaire/secondaire des classiques base de données relationnelles.

La gestion crédible (à la charge de l’utilisateur) de la persistance casse tout de suite l’ambiance “élégance de la simplicité” d’Uncloud.

Avant de râler, commencez par avoir une procédure de sauvegarde d’équerre, AVEC TEST DE RESTAURATION, ce sera déjà pas mal.

Sinon, affirmer qu’Uncloud est vertueusement soutenable par ce que moins orgiaque que Kubernetes est un peu mesquin.

L’après

Uncloud bénéficie déjà d’une belle visibilité et réputation, ce qui est une grande victoire pour un développeur seul.

Par ses choix, Uncloud ne pourra générer que peu de revenus, juste vendre de l’expertise technique. Le choix de la cible “développeur solo, petits projets, hébergement discount” ne va pas non plus aider à ramener des sous, même si Uncloud risque de plaire aux agences de communication.

Il faut donc lui souhaiter du sponsoring, sous une forme ou une autre, et cibler des projets un poil plus ambitieux que l’infâme Wordpress+Mariadb proposé dans les exemples.

Il y a pour l’instant des parties mal définies qui rend le projet un peu brouillon. Ces zones floues seront rapidement corrigées avec une dose de RTFM et d’aide extérieure.

De toute façon, tout ce qui secoue et remet en cause les admins, devops et autre idolâtre du cloud est rafraichissant, même si la proposition se vautre.

À suivre et à encourager !

Packages proxies

2025-07-15T09:04:00+02:00

Packages store

All package repositories are technically similar and unfancy. Technical boredom is a guarantee of stability.

On a website, packages are indexed per release, per version, per architecture (and sometimes per group, like “security” or “backport”).

Lots of technical details are explained in the previous blog post (sorry for my French).

Faster, closer, and more efficient

If you manage a large float of servers or a busy continuous integration service, you have to cache package repositories (to avoid banishment, throttling, or bad karma).

Package integrity is handled behind the distribution channel with signatures. At least, it should be so.

Distribution channel (HTTP most of the time) is not a security problem.

Old-school providers sign (with a trusted public key) the index of the packages (including their hashes).

The (almost) universal signing tool for open-source code is Sigstore.

With signatures, package integrity is guaranteed, so caching or mirroring is safe.

Repositories can be mirrored, but beware of the synchronization periodicity.

Some package providers handle their own mirrors, with explicit and implicit GeoDNS and cache proxy. They can broadcast updates to minimize mirror lags.

Bring your own cache

Cache can be fancy, with a lot of features and complexity, or crude, just a plain old HTTP cache proxy.

Fancy caches

Here is a short selection of specialized proxies:

Proxpi for Python
Goproxy or Athens for Golang
Gemirro for Ruby
Panamax for Rustlang

Some specialized proxies handle different kinds of packages, like Pulp.

apt-proxy (which also handles yum and apk) is designed to handle flappy Internet connections and find the best mirror (behind it).

Old school caches

Squid is boring; lets use Nginx cache.

A proxy cache for your repositories

Dinosaurs remember the time when a simple HTTP_PROXY environment variable plugged a proxy in front of the target site.

Proxy only works with HTTP servers. HTTPS encrypts the connection, which can’t be cached.

Now, all repositories use HTTPS by default now (kudos to SSL Everywhere). The proxy must be a “man in the middle”, and intercept the queries.

Each kind of package must be configured specificallyy.

Setting a proxy for all package families can be done with a config file. It’s explicit, but not universal.

Developers and CI can use different private caches.

Some package manager can be configured with few ENV; for the others, a mix of file configuration and ENV can do the trick.

Demo time

One cache to rule them all.

Setting a private DNS and TLS is boring; life is short. The easiest and laziest way is to mix local and containerized development with bare IP and containerized cache server.

Please don’t do that ia real production environment.

Caching for few package families are explained later in this blog post.

This examples use Docker to build images.

The adaptation for local development is trivial.

Docker has the ONBUILD command in its Dockerfilen very useful for setting variable in the build process.

The easiest way to build image which can use cache is to build an image atop the main language image.

The layers of the cake are:

base image
cachable image
project image

Nginx cache

The official Nginx image doesn’t have the subs-filter module.

Lets build a new image with it.

docker build \
  --build-arg ENABLED_MODULES="subs-filter" \
  -t nginx-subs \
  https://raw.githubusercontent.com/nginx/docker-nginx/refs/heads/master/mainline/alpine/Dockerfile

Each cache packages families use path route, and when it’s impossible, it uses hostname route (the client is configured to use the cache as a proxy).

Nginx configuration is minimalistic, tune it if you wish.

Pick your favorite resolver, I use 193.110.81.0 (dns0.eu), 8.8.8.8 (google) is “déjà vue”.

Cache size needs your attention, set a correct value, nor to small, nor to huge.

One server, one port, no hostname.

worker_rlimit_nofile 8192;

events {
    worker_connections 4096;
}

http {
    log_format proxy '$remote_addr '
                        '"$request" $status $bytes_sent bytes'
                        ' -> "$upstream_addr" "$http_location" '
                        ' "$http_user_agent" ';

    error_log /dev/stdout info;
    access_log /dev/stdout proxy;

    include /etc/nginx/mime.types;

    index index.html;
    resolver 193.110.81.0; # dns0.eu
    default_type application/octet-stream;

    tcp_nopush on;
    server_names_hash_bucket_size 128;

    proxy_cache_path /data/cache keys_zone=fat_cache:10m max_size=1g inactive=60m use_temp_path=off;

    server {
        listen 80;
    }
}

The server section is empty, some location will be added later.

Pick a private interface face, and its IP for publishing the cache service. The cache server needs to be available from containers and your workstation.

The ip is stored as SERVER_IP :

ip -f inet addr show docker0 | grep "inet " | sed -E "s#.*inet (.*)/.*#\1#g"

Or something more dirty with MacOS, docker0 is inside the VM, so, the IP of the laptop is used (check your firewall settings, first).

ifconfig -v en0 | grep "inet " | cut -w -f 3

You can now run the cache server (with its SERVER_IP).

mkdir -p data/cache
docker run --rm \
    -v `pwd`/data/cache:/data/cache \
    -v `pwd`/nginx.conf:/etc/nginx/nginx.conf:ro \
    -p $(SERVER_IP):8082:80 \
    nginx-subs

On Linux, you should use an user with your id, cache owned by root is unorthodox.

Debian (and Ubuntu)

Debian uses URLs starting with /debian.

server {
    location ~^/debian(.*)$ {
        proxy_cache fat_cache;
        proxy_cache_background_update on;
        proxy_cache_lock on;
        proxy_pass http://deb.debian.org/debian$1;
    }
}

Cache image.

FROM debian:bookworm-slim

ONBUILD ARG APT_MIRROR=""
ONBUILD RUN if [ -z '$APT_MIRROR' ] ; \
    then \
    echo 'No mirror'; \
    else echo "Acquire::http::Proxy \"$APT_MIRROR\";" \
    > /etc/apt/apt.conf.d/cache.conf; \
fi

docker build -f Dockerfile.debian-mirror -t deb-mirror .

Debian demo imagee :

FROM deb-mirror

RUN apt-get update \
    && apt-get install -y --no-install-suggests --no-install-recommends \
        cowsay \
    && rm -rf /var/lib/apt/lists/*

CMD ["cowsay", "Through the Looking-Glass"]

Build it , with a specific cache server.

docker build \
    -f Dockerfile.debian \
    -t debian-demo \
    --build-arg APT_MIRROR=http://192.168.1.35:8082/ \
    .

You should see a flow of package URLs in the terminal with Nginix Cache.

Run it :

docker run --rm debian-demo

The Ubuntu variant needs only few modifications.

Ubuntu doesn’t use prefixed URLs;the hostnameme must be used.

server {
    server_name ~^(.*)\.ubuntu.com$;
    listen 80;

    location / {
        proxy_cache fat_cache;
        proxy_cache_background_update on;
        proxy_cache_lock on;
        proxy_pass https://$1.ubuntu.com;
    }
}

Alpine

Nginx conf:

location /alpine/ {
    proxy_cache fat_cache;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    proxy_pass https://dl-cdn.alpinelinux.org/alpine/;
}

Cache image:

FROM alpine:latest

ONBUILD ARG HTTP_PROXY=""
ONBUILD RUN if [ -z '$HTTP_PROXY' ] ; \
    then \
        echo 'No mirror'; \
    else \
        sed -i 's/https/http/g' \
        /etc/apk/repositories; \
    fi

There is trick, $HTTP_PROXY will be used by apk.

Build cache image:

docker build \
    -f Dockerfile.alpine-with-cache \
    -t alpine-with-cache \
    .

Demo image:

FROM alpine-with-cache

RUN apk add --no-cache figlet

CMD ["figlet", "Carpe diem"]

Build demo image:

docker build \
    -f Dockerfile.alpine \
    -t alpine-demo \
    --build-arg HTTP_PROXY=$(SERVER_IP):8082 \
    .

Run demo:

docker run --rm alpine-demo

Pypi

Nginx conf for pypi:

location ~ ^/pypi/(.*)$ {
    proxy_cache fat_cache;
    proxy_pass https://pypi.org/simple/$1;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    proxy_ssl_protocols TLSv1.2;
    proxy_ssl_session_reuse off;
    proxy_ssl_server_name on;
    proxy_ssl_name pypi.org;
}

pip can use an index without https, but the host needs to be trusted.

Cache image:

FROM python:3.13-slim

ONBUILD ARG PYPI_CACHE=""
ONBUILD RUN if [ -z '$PYPI_CACHE' ] ; \
    then \
        echo 'No mirror'; \
    else \
        echo "[global]\n\
        index-url = http://${PYPI_CACHE}/pypi\n\
        trusted-host = $(echo ${PYPI_CACHE} | cut -d : -f 1)" \
        > /etc/pip.conf ;\
    fi

Build cache image:

docker build \
    -f Dockerfile.python-with-cache \
    -t python-with-cache \
    .

Demo image:

FROM python-with-cache

RUN python3 -m venv /demo \
    && /demo/bin/pip install cowsay

CMD ["/demo/bin/cowsay", \
    "-c", "tux", \
    "-t", "\"Welcome to the thunder dome\"" ]

Build example:

docker build \
    -f Dockerfile.python \
    -t python-demo \
    --build-arg PYPI_CACHE=$(SERVER_IP):8082 \
    .

Run example:

docker run --rm python-demo

npm

Nginx conf:

server {
    server_name registry.npmjs.org;
    listen 80;

    location / {
        proxy_cache fat_cache;
        proxy_cache_background_update on;
        proxy_cache_lock on;
        proxy_pass https://registry.npmjs.org/;
        proxy_ssl_protocols TLSv1.2;
        proxy_ssl_session_reuse off;
        proxy_ssl_server_name on;
        proxy_ssl_name registry.npmjs.org;
    }
}

Cache image:

FROM node:24-alpine

ONBUILD ARG NPM_CACHE=""
ONBUILD RUN if [ -z '$NPM_CACHE' ] ; \
    then \
        echo 'No mirror'; \
    else \
        npm set proxy "http://${NPM_CACHE}/" --location global && \
        npm set https-proxy "http://${NPM_CACHE}/" --location global &&\
        npm set registry http://registry.npmjs.org/; \
    fi

Build cache image:

docker build \
    -f Dockerfile.npm-with-cache \
    -t node-with-cache \
    .

Demo image:

FROM node-with-cache

# npm should be somewhere, not /
RUN mkdir -p /opt/demo \
    && cd /opt/demo \
    && npm --verbose install cowsay

CMD ["/opt/demo/node_modules/.bin/cowsay", \
    "-e", "xx", \
    "\"With a little help from my friends\"" ]

Build demo image:

docker build \
    -f Dockerfile.node \
    -t node-demo \
    --build-arg NPM_CACHE=$(SERVER_IP):8082 \
    .

Run demo:

docker run --rm node-demo

Docker

Docker daemon can use a mirror.

Docker Hub, now, has quota; if you don’t want to be banned, use a mirror.

A private registry is mandatory to deploy your images.

All registries can be used as a proxy cache for another public or private registry.

Harbor, graduated by CNCF, like all registries, can be a proxy cache

Using nginx for caching Docker Hub should not be done in production, but it’s fun to cache everyting with one server.

Docker daemon configuration.

Add this line in the daemon.json config file:

"registry-mirrors": ["http://_server_ip_:8082/docker/"]

On Linux the path is /etc/docker/daemon.json, but, before breaking something, RTFM the Docker configuration file.

With Docker Desktop (OSX or Windows), the configuration is in the tab “Docker Engine.”

Docker can use a containerized mirror, but pull and build the image BEFORE using it.

Nginx conf:

location /docker/ {
    rewrite ^/docker/(.*)$ /$1 break;

    proxy_cache fat_cache;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    proxy_pass https://registry.hub.docker.com/;
}

Github Demo Project

Copy pasting is boring;, the package-cache contains all the files cited in this post, with an useful Makefile.

Split your terminal (with tmux maybe), and build and run the cache server.

make cache

Run all demos:

make demo

For the Docker cache demo, you have to tweak your Docker daemon configuration and pull a fresh image, not one already cached in your local registry.

Cache all the things

CI can share a private local cache between steps.

Useful, but this cache is not shared (cache poisoning is very dangerous).

The cache proxy is safe, the user can’t write data (and poison it), and the cache is shared between all project builds.

Have fun with Nginx demo, but sooner or later, you will use specifics caches.

Infomaniak et le chiffrage des mails

2025-06-18T15:15:00+02:00

Infomaniak, vous savez, les charmants Suisses qui ont (a priori) repris le karma du vendeur de DNS à Gandi (époque Chemla), ils ont aussi une offre mail construite, pas juste un Roundcube de politesse.

Ils viennent d’annoncer une évolution de leur offre pour plus de sécurité : il y a maintenant un petit bouton cadenas dans l’interface du webmail.

Toutes les démarches pour améliorer la sécurité et la confidentialité sont les bienvenues.

Ma légitimité sur l’analyse

Disclaimer, j’ai l’expertise en sécurité d’un lecteur de Wikipedia, de RFC et de la presse people qui rapportent les plus beaux CVE. Jamais je n’assurerai que quoi que ce soit est à l’épreuve des balles. C’est un métier et clairement pas le mien. Par contre, si je vois un trou dans la coque, je peux affirmer qu’il y est.

GPG

Donc, Infomaniak utilise GPG, standard de fait (et une des plus belles déceptions d’Internet).

Techniquement, GPG utilise les mêmes algorithmes de clefs asymétriques que TLS ou SSH. Ça part sur de bonnes bases.

Les distributions Linux l’utilisent pour signer leurs paquets, git permet aussi de la faire, bref, c’est dans l’écosystème libre depuis longtemps.

SAUF QUE.

Le chiffrage asymétrique ne sait comment exposer la clef publique des utilisateurs en garantissant qu’il n’est pas un usurpateur.

SSH utilise par défaut le naïf Trust on first use, mais peut utiliser des clefs signées par une autorité de certification.

GPG a fait le choix utopiste (niais ?) de ne rien centraliser (bon choix), mais d’utiliser une chaine de confiance. Un utilisateur peut signer la clef d’autres utilisateurs qui pourront faire de même et ainsi former une toile d’araignée de confiance. Comment savoir que la clef que l’on signe n’est pas une fourberie ? Comment savoir qu’une personne qui a déjà signé est digne de confiance ?

Bref, le “web of trust” est une fausse bonne idée (comme CRAM-MD5 par exemple)

Pour que GPG fonctionne, il faut pouvoir prouver que la clef appartient bien à la bonne personne.

Pour les paquets, c’est tout simple : le trousseau des clefs légitimes est disponibles quelque part en TLS. La confiance est déléguée au DNS et à l’autorité qui a signé le certificat (comme Let’s Encrypt).

Pour des utilisateurs lambdas, c’est un poil plus compliqué, Keybase propose de légitimer une clef en prouvant que l’on est bien possesseur de différents services (de bonnes réputations) sur Internet (un site web, Github, Twitter, Hackernews, Reddit…). Petit souci, c’est un freeware racheté par Zoom (pour rafistoler sa réputation de passoire) et seulement 400k utilisateurs l’utilisent.

Il existe Web Key Directory une solution à base de .well-known sur un serveur web. Il n’a pas sa page Wikipedia, ce qui est une faute de gout. Il faut que je l’essaye avant de le dauber.

De toute façon, le crime originel de GPG pour les mails est qu’il ne chiffre que le corps du mail. Le reste est en clair, comme l’expéditeur, le destinataire, par où il est passé. Sans ça, pas moyen d’acheminer le mail. Pour une utilisation crédible, il faut utiliser des comptes mails avec des pseudos, des SMTP les plus banaux possibles et des titres cryptiques, et échanger correctement les clefs publiques. Bon courage aux lanceurs d’alerte non techniques.

S/MIME

Il existe une autre norme, S/MIME qui mise tout sur TLS. Peut-être qu’un jour Let’s Encrypt proposera de signer des clefs pour S/MIME qui est souvent implémenté dans les clients mails.

S/MIME ne va pas pouvoir faire mieux que GPG, et ne chiffrera que le corps du mail.

Webmail

Nouveau drame.

Les mails sont souvent utilisés en webmail. Comment fournir et stocker sa clef privée ? Techniquement, javascript sait lire un fichier local, gérer du chiffrage et il existe Openpgpjs (soutenu par l’Union Européenne).

Mais, le site, qui héberge ce code Javascript peut être un fourbe (ou compromis), et on va lui confier sa clef privée.

Clef que l’on transporte comment ? Sur une clef USB, dans ce cas, autant utiliser Tails (si la machine peut booter sur une clef).

Infomaniak

Implémentation par Infomaniak :

La clef est chez l’hébergeur (stocké de manière sécurisée) mais accessible par eux.
Si on écrit un mail à un client Infomaniak, la clef publique est directement utilisée (avec confiance).
Pour écrire à un utilisateur externe, il faut se démerder pour lui faire passer un mot de passe.
La recherche ne fonctionne plus que sur les titres (comme vu plus haut).

J’ai de gros doutes sur la crédibilité de ce petit cadenas bleu en bas de la page.

Et au-delà

Le mail est à la fois indispensable (car universel), et maudit. La confidentialité intégrale est techniquement impossible. Plus de sécurité, comme la signature des mails (par le serveur avec DKIM, par l’utilisateur avec GPG ou S/MIME), ou le TLS sur tout le chemin sont possibles.

La confiance dans l’hébergeur est incontournable.

Il y a deux points bloquants pour atteindre le meilleur : les applications mails (dont les webmails) qui ne gère pas forcément toutes les fonctionnalités possibles et l’ergonomie pour les utilisateurs.

Le plus simple est d’utiliser Signal, même si l’authentification de son interlocuteur n’est pas magique :

Il faut fournir un code, via un QRcode par exemple, ou en faisant une vision pour vérifier qu’il a la bonne tête.

Prenez soin de vous, amis paranos.

Kloset sur la table de dissection

2025-06-11T09:04:00+02:00

Un Plakar pour ranger ses archives

Plakar est un outil de sauvegarde multi-plateforme et open source. Basé sur les technologies et les usages contemporains : il utilise la déduplication, la compression et met la priorité sur le chiffrement et la signature (intégrité de l’archive et authenticité).

Le code de Plakar, en golang, est découpé entre plusieurs bibliothèques que l’on peut utiliser de manière granulaire. Plakar est l’application qui va tirer toutes ses bibliothèques pour proposer une UI élégante.

Kloset

Kloset (qui m’évoque la martyre de Thénardier) s’occupe des archives, c’est cette partie que je souhaite disséquer.

Théorie

Découper en tranches

Le document est découpé en tranches (chunks en VO), avec l’espoir d’avoir des tranches en commun avec d’autres fichiers.

Si le format de fichier ne secoue pas tout chaque fois qu’il enregistre, il est fort probable d’avoir des duplicas. C’est le pari de git qui travaille à partir de patch. Cette approche fonctionne très bien avec des fichiers plats (tant qu’il n’y a pas de guerre vaine de formatage).

Limiter les transferts

Même avec une connexion moderne, il est toujours appréciable de limiter la bande passante utilisée lors d’un transfert de données. À l’ère du NVMe, la sauvegarde sur un disque à plateau (plus pérenne à long terme) va vous paraitre mollassonne.

L’outil de référence (et historique) de synchronisation incrémentale est rsync, enfin, librsync. L’explication de l’algorithme (simple et élégant) est décrit dans l’article originel The rsync algorithm de 1996.

Il est agréablement lisible.

Le fichier cible est découpé en blocs de taille fixe (des chunks), dont on calcule deux hashs. Le premier hash, dit “faible”, peu couteux à calculer, aide à trouver des similarités, le second, dit “fort”, garanti que deux chunks sont identiques.

La cible fournit cette liste à la source.

Le premier hachage est techniquement une “somme de contrôle” (checksum en VO), précis, rapide à calculer mais avec des risques de faux-positifs (des collisions).

L’idée est d’utiliser un rolling hash peu couteux à calculer, car il réutilise le calcul précédant (en “faisant rouler” la fenêtre de hash d’un octet). Le rolling hash peut décaler les chunks et créer des “trous” dans la liste décrivant le fichier local.

Si un rolling checksum est dans la liste des hashs distants, bingo, il ne sera pas nécessaire de l’envoyer. Le second hachage est dit fort (le risque de collision est considéré comme improbable) et va garantir que les chunks sont identiques.

Il suffit d’envoyer la liste des chunks qui ont changé de place, les octets à ajouter ou effacer, et un hash pour vérifier la cohérence du fichier modifié.

Un patch peut être créé avec cet algorithme, en local, pour fournir des mises à jour de logiciel.

Cette approche est élégante, mais le fichier cible doit être non chiffré pour pouvoir appliquer les modifications sur la cible. Techniquement, il est possible d’avoir le fichier cible chiffré tant qu’il fournit la liste de ses hashs, par contre, ils seront stockés en l’état sur la cible. Le moment où l’on souhaitera effacer les anciennes versions pour faire de la place va être compliqué.

Le temps de calcul va dépendre (de manière non linéaire) de la taille du fichier, bon courage pour les vidéos et les images disques.

Déduplication par le chunk

Les chunks peuvent être utilisés de manières différentes.

En décrivant les fichiers avec des listes des chunks, sans “fenêtre roulante”, la création de patch minimaliste n’est plus possible. Par contre, en travaillant sur un volume conséquent de fichiers (en To), il y aura statistiquement de doublons, des chunks communs à plusieurs fichiers : le Graal du dédoublonnage.

La déduplication est fort pratique pour la sauvegarde, mais elle est aussi déployée pour le stockage distant, qualifié de “synchronisation”, comme le propose Dropbox, Google Drive et tant d’autre. Seafile est un équivalent open source, même s’il a un coup de mou depuis 2016.

Historiquement, les morceaux découpés avaient une taille fixe, plus simple, moins couteux en CPU, mais limitant les chances d’avoir des doublons.

Le Content-Defined Chunking décrits dans ce papier (“Découpage basé sur le contenu” dans la langue de Pivot) propose d’utiliser des morceaux de tailles variables (dans une fourchette imposée) pour augmenter le taux de duplicas.

Hugginface est enthousiaste sur le dédoublonnage permettant un gain en place et bande passante pour ses modèles monstrueux.

Optimiser le débit

Le meilleur moyen d’optimiser le débit d’un transfert et de ne pas transférer. Pour ça, il faut maximiser la chance que le chunk soit déjà sur place, un duplica. Les petits chunks ont plus de chance d’avoir des duplicas, mais trop de chunks sont plus lourds à indexer : les chunks sont regroupés dans un fichier de taille raisonnable, il faut donc maintenir un index pour savoir dans quel fichier se trouve un chunk.

Hugginface explique ses optimisations pour partager ses données. Il possède, à l’époque de la rédaction de leur billet, 45Po de données découpées en chunks de 64ko, soit 690 milliards de chunks. Pour un fichier de 200Go, taille normale chez eux, il faut 3.125 millions de chunks.

Pour téléverser un fichier, il faut le découper en chunks, et pour chacun vérifier qu’il n’est pas déjà sur le serveur via un filtre de Bloom : on prend le hash du chunk, modulo 1000, et hop, on connait le nom de l’index à télécharger qui peut contenir le nom du chunk. Les chunks sont regroupés en bloc de 64Mo, et envoyés dans un ordre quelconque.

L’archivage se fait sur un disque dur, les SSD/NVMe restent hors de prix pour les gros volumes. Le HDD, lui continue sa course à la densité, même si le débit ne suit pas.

En dispersant les chunks sur un disque dur, les performances en lecture ne sont pas optimales, les lectures séquentielles sont bien plus performantes.

Les écritures sont regroupées en plus gros blocs, plus simple à optimiser pour le système de fichier.

Les fabricants de disques durs font de gros efforts pour conjuguer densité et débit.

Le cache distant (celui du disque, ou d’un SSD en renfort), et local (les duplicas) amélioreront grandement les performances en téléchargement. La restauration complète d’une sauvegarde, sans cache local, avec peu de chance que les chunks soient dans le cache distant, est le cas le plus défavorable.

Tout ça n’est que théorie, il faut des tests de charge pour valider/invalider ces hypothèses.

Le bus interne (SATA/SAS), le processeur, la bande passante de l’hébergeur, et fort probablement la bande passante de l’utilisateur peuvent être des goulots d’étranglement.

Hugginface, est dans un cas bien plus favorable, ses modèles en best-seller profitent pleinement d’un cache en SSD/NVMe.

Entropie d’un binaire

L’entropie mesure le côté aléatoire d’un binaire, l’absence de motifs répétés (comme des séries de 1 ou de 0). Les binaires pleins de trous ont même un nom, les sparse files et les systèmes de fichiers savent bien les gérer. Une faible entropie va perturber le processus de découpage basé sur le contenu qui créera des chunks rares, qui n’auront que peu de duplicas. Les images disques de machine virtuelle sont un bon exemple de sparse file en représentant l’espace disponible de longues suites de 0.

L’article The Impact of Low-Entropy on Chunking Techniques for Data Deduplication explique ça avec précision.

Traiter les données depuis la cible

Traditionnellement, les chunks ne sont pas chiffrés, ce qui permet d’agir depuis la cible.

Redécouper les chunks pour chaque client, en fonction de la qualité de leur connexion (latence et pertes de paquets) permettra une utilisation fluide sur un réseau de qualité médiocre (ce qui arrive régulièrement sur les réseaux de téléphonie mobile).

Indexer le contenu permettra aux utilisateurs de chercher dans leur fatras de documents en ligne. Dropbox vous propose de chercher vos images (OCR et description par une IA) mais aussi de bannir le contenu protégé par le droit d’auteur (initialement à base de hachages sur liste noire) et finalement de faire la chasse aux pédonazis.

chiffrement

“Oui, mais moi, je n’ai rien à cacher”, comme l’affirme le projet ECHELON. Depuis la révélation de ce projet, le chiffrement s’est généralisé sur Internet. Il n’y a aucune raison de ne pas chiffrer son stockage en ligne (dans le Nuage ?).

Cryptomator se positionne comme intermédiaire local entre vous et un stockage distant. C’est gentil de leur part, mais l’un des objectifs du chiffrement est de transformer vos données en ce qui semble être un amas d’octets complétement aléatoire. Cette bouillie d’octets est le pire cas pour le chunking et le dédoublonnage.

Le chiffrement doit se faire après le découpage des chunks, à la source et la cible ne doit avoir aucun moyen de lire le contenu.

Implémentation de Kloset

Comme le laisse supposer les précédentes explications théoriques, Kloset va chunker, vérifier, authentifier, dédoublonner, compresser et chiffrer.

Son objectif est la sobriété (stockage et bande passante), la résilience et la sécurité.

Ces explications, bien que denses, se contentent de vulgariser les choix techniques de Kloset, pour avoir une connaissance exhaustive, il faut lire le code.

Chungking Express

Le jeu de mot avec le film était trop tentant, même si c’est loin d’être le meilleur de ce réalisateur.

Kloset utilise du CDC (des chunk de taille variables) et comme il n’y a aucun hash à rouler, un seul, fort, est utilisé. Un chunk, et bien d’autres objets sont désignés par leur hachage.

Clef maîtresse

Toute la sécurité de Kloset part du mot de passe de l’utilisateur (qui est validé par diverses contraintes de sécurité lors de sa création).

À la création du dépôt, un bloc de 32 octets aléatoire est créé, il sera le sel.

Le mot de passe et le sel vont générer une master key (de 32 octets) avec une fonction de dérivation de clef.

Ce hachage est volontairement compliqué et lent (même pour un GPU) pour ralentir les attaques en force brute. Argon2 a été choisi (gagnant du concours de hash de 2015 quand même).

MAC

Il n’est pas tout à fait vrai de dire que Kloset utilise des hash pour vérifier l’intégrité de ses contenus. Pour être précis, il faut parler de HMAC, sur-ensemble d’un hash, qui permet de vérifier en plus l’authenticité avec un secret. N’importe qui peut modifier le document et fournir un hash valide, mais seul les personnes connaissant le secret peuvent signer et authentifier. Le terme MAC est utilisé dans le code pour désigner les HMAC.

La clef maitresse est utilisée comme secret pour les différents HMAC.

Pour de meilleures performances le hachage n’est pas forcément confié au standard SHA-256, mais utilise par défaut BLAKE3, très rapide et facilement parallélisable (SIMD et multi-threads).

Ce MAC sert de clef pour désigner les différents objets du projet.

Chunk et PackFile

Kloset considère que tout est un blob binaire, référencé par un Chunk. Les blobs et leur Chunk sont entassés dans un Packfile qui, lui, sera enregistré sur un disque dur, un S3, quelque part.

Un PackFile se compose de trois parties. D’abord une écriture en flot (sans tout charger en mémoire) d’une suite de blobs. Ensuite viennent les métadonnées (de taille fixe) pour chacun des blobs, consolidées en RAM (28o de méta par bloc, c’est plus que raisonnable). Le PackFile se termine par un footer, de taille fixe (28o aussi) qui contient, entre autre, l’offset de l’index.

Les Packfile ont une taille maximale. Si l’on a besoin de plus de place, il suffit d’en créer un nouveau.

Pour lire un Packfile, il suffit d’aller 32 octets avant la fin à la fin du fichier, lire le Footer (en bleu), qui décrit l’emplacement de l’Index (en jaune). Entre le début du fichier et l’Index se trouve la zone de Blobs contenant de manière indistinct (mais séquentiel) des blocs de contenu (en rose). Dans l’Index, tous les 28 octets, un Blob est décrit. Chaque Blob décrit l’emplacement d’un bloc de contenu. Il est possible de lire partiellement l’index si les méta-datas contenu dans le Blob correspond à sa recherche. Une fois le Blob sélectionné, il suffit d’aller le lire.

En théorie un Packfile peut contenir n’importe quels binaires typés (jusqu’à 2^32 types différents). Kloset s’en contente d’une vingtaine.

Comme tous les différents objets sont désignés par des hash, les Chunk vont se retrouver ventilés dans de multiples Packfiles.

Il est techniquement possible d’itérer dans tous vos Packfile pour trouver un MAC (une clef) précis, mais un confortable index permet de connaitre, rapidement, pour chaque objet son Packfile, son offset, sa taille et son type.

Entry

Kloset sauvegarde des fichiers, pas uniquement des données binaires abstraites.

Le fichier est modélisé par un Entry (participant ?), sérialisable, qui va contenir toutes les méta-informations spécifiques à l’OS (UNIX, Windows), et les fichiers spéciaux (dossiers, liens symboliques, liens durs) en plus des méta-données liées à l’archivage.

Une Entry contient moult méta-données, et une référence à son Object listant des références Chunk (qui eux font référence au contenu binaire).

MessagePack est utilisé pour la sérialisation. C’est un format similaire à JSON (auto-descriptif), mais rapide et compact.

Repository

Le “dépôt” est le point de départ pour sauvegarder ses données. Différents paramètres permettent de l’adapter à ses besoins, et il maintient un index pour manipuler efficacement ses archives.

Un dépôt peut utiliser un disque local, distant, un serveur de stockage (façon S3) ou un serveur distant (sftp et même ftp).

Un dépôt peut se synchroniser avec un autre dépôt.

Snapshot

Les fichiers sont archivés par lots, dans des Snapshot.

Un Importer va effectuer un scan, un parcours (walk en VO) de l’arborescence de fichiers filtrés par des règles.

Kloset décrit l’interface Importer qui n’a qu’une implémentation de test. Plakar, lui, fournit des implémentations concrètes.

L’Importer fournit un flot de ScanRecord représentant les fichiers à sauvegarder.

PackageManager

Un Repository possède un PackageManager (qui parallélise ses taches) que l’on va nourrir de Blob (type, MAC, contenu) pour créer des PackFile, le Repository se chargeant de les compresser et chiffrer (si la configuration le réclame).

Pour l’instant, aucune excentricité dans les choix des outils de compression : le vénérable GZIP (bonne compression, mais débit mou) ou LZ4 (débit fantastique au détriment de la compression).

Le chiffrement propose des configurations normées d’AES-256.

Store et index

Les PackFile sont enregistrés dans un Store, une interface avec juste une implémentation de test dans Kloset, mais des implémentations concrètes dans Plakar.

Il n’y a pas d’index pour retrouver ses petits, mais un cache, que l’on peut reconstruire. Plus précisément, c’est une interface StateCache qui a pour une fois des implémentations dans Kloset basés sur PebbleCache. Pebble est un clone de RocksDB en Golang.

Sécurité

La sécurité, c’est comme les interfaces utilisateurs, il ne faut jamais laisser un développeur s’en approcher.

Lire la page Wikipédia pour comprendre les concepts est un bon début. Ne pas tripoter les curseurs, surtout sans savoir ce qu’ils font est simplement du bon sens. Faire valider/auditer par un spécialiste la partie liée à la sécurité est sage (ça éloigne le mauvais œil et les zero days).

Les salles secrètes du donjon

Après une rapide visite du donjon de Kloset, on peut apercevoir des indices sur des fonctionnalités futures.

Des notions de “classification” et de “Score” apparaissent.

Il est aussi possible que j’aie raté des éléments dans ma lecture du code.

Ma lettre au père Noël

Trousseaux

Laisser trainer sa clef avec le risque de la perdre et de transformer ses archives en brique est inutilement stressant.

[ ] Intégration à Vault ou un équivalent, pour gérer le “grand secret”
[ ] Intégration à différents trousseaux (gnome keyring, keepass, freedesktop keyring, apple keyring…)

Résilience

Les disques durs qui meurent, ou plus fourbe, les octets pourris (bit rot en VO), ça arrive, c’est même pour ça que l’on fait des sauvegardes (même si le cas d’usage classique et de pouvoir revenir sur une action hasardeuse).

[ ] Correction d’erreurs de Reed-Solomon pour palier ou compléter la flemme de la réplication
[ ] Gestion de la parité en XOR sur 3 disques pour contourner Minio ou le RAID

UX

La sauvegarde doit être systématique, machinale, la moindre friction ressentie par l’utilisateur va espacer les backups. L’assurance de pouvoir restaurer sereinement est tout autant indispensable.

[ ] Sauvegarde qui se déclenche (ou demande gentiment) dès que l’on branche un disque USB dédié (et si la machine est branché à son chargeur)
[ ] Décompression à la volée des archives, comme les dumps SQL ou les fichiers OpenDocument, pour avoir de jolis chunk (et de recompresser dans le PackFile)
[ ] Sauvegarder un snapshot, si le système de fichier en est capable (ZFS, Btrfs, bcachefs, APFS…)
[ ] Connexion aux sauvegardes intégrées d’applications, comme le archive_command de Postgresql

Plus vite, plus haut, plus fort

[ ] Gestion des disques SMR avec des PackFile qui remplissent efficacement les tracks.
[ ] Échange des PackFile en QUIC, tant pis pour les paquets perdus, on les redemandera plus tard. Ça revient presque à du chunk de chunk.

Indexation et recherche

Là, on s’éloigne du backup pour se rapprocher de l’archivage.

[ ] Création de vignette pour les images, et la possibilité d’afficher, comme pour le teste, le delta (avec un PixelMatch moins laid) pour choisir la version à restaurer
[ ] Embeding avec le Fast Tokenizer d’Hugginface pour de la recherche par mot (enfin, par token) ou même de la similarité.
[ ] Indexation des images (création de mots clefs) avec YOLO ou d’autres modèles (avec une licence compatible).

SAAS

Chacun ses chunk

Backblaze a un prix d’archive au kilo (enfin, au téra) fort difficile à concurrencer, même s’ils fournissent la recette pour construire leurs serveurs.

L’offre de Backblaze est, à la louche, le prix d’un dédié (OVH, SCW, Hetzner), avec une redondance de stockage de deux. Il faut compter en plus les salaires et leur marge.

Mutualiser les chunk de différents utilisateurs

Juste pour l’exercice d’une offre SAAS qui partage des chunk entre utilisateurs (chunk qui reste rangés dans des Packfile), pour dédoublonner encore plus fort. Pour ça, il faut que chaque chunk ait une clef de chiffrement différente, et un hash (pas un hmac) pour les désigner.

Il faut un archiviste-notaire qui certifie une clef TLS pour chaque utilisateur.

Un utilisateur souhaite envoyer un chunk avec une taille et un hash, le serveur dit “OK, je pense l’avoir déjà, voici un sel aléatoire, calcul moi le hmac du chunk“, si la preuve est correcte, pas besoin d’envoyer le fichier. Le notaire va ajouter l’utilisateur à la liste des propriétaires du chunk.

La partie chiffrement est la plus casse-gueule.

Pour déchiffrer un chunk que l’on n’a pas créé, il faut demander au notaire la liste des propriétaires, et contacter l’un d’eux en point à point, en s’authentifiant en mTLS. Le propriétaire s’assure auprès du notaire que la demande est légitime, puis il fournira la clef (qu’il a chiffrée en local avec sa clef maitresse).

Pour ça, il faut qu’une des personnes soit connecté et réponde à un moment ou à un autre (comme l’utopique IPFS).

Sinon, le serveur conserve et fournit les clefs, ce qui est contraire au concept même de Kloset.

Je vois là une belle usine à gaz instable, et je n’ai même pas prononcé le mot DHT.

Un concept de crypto qui m’échappe peut, peut-être, résoudre ce micmac.

La limite du raisonnable

Oui, une partie des souhaits ne sont pas raisonnables.

Essayer de contourner des services existants est risqué.

Optimiser quelque qui chose qui fonctionne déjà correctement, ou pour des conditions extrêmes n’est jamais une bonne idée.

Par contre, d’autres gadgets, comme la synchronisation QUIC peut être développé (pour le sport) à côté sans rien secouer. Si le gain est décevant, poubelle, et retour aux approches sages.

Old

Le billet de blog officiel décrivant Kloset existe, mais promis, je suis parti des sources et des publications universitaires pour écrire ma version.

Packageless, la distribution sans paquets

2025-05-26T09:04:00+02:00

Paquets

Les paquets permettent d’installer des logiciels et des bibliothèques sur un ordinateur. Sur un système d’exploitation si on veut être précis.

Les paquets ont la bonne granularité déployer des applications et mutualiser les bibliothèques (en limitant la redondance sur le disque dur) et permettent de mettre à jour simplement la machine.

L’article se concentre sur Linux (pour les serveurs), mais ils existent des outils similaires à installer sur des OS propriétaires comme Chocolatey pour Windows ou Homebrew pour MacOS.

Formats

Archives brutes

Sur les distributions de dinosaures, comme Slackware (en 1993), de simples archives (du tar compressé par exemple) sont utilisés. Slackware oublie de gérer les dépendances, ce qui est un peu peu.

Paquets sources

Pourquoi se contenter de paquets tout prêts qui font des choix à notre place alors qu’il est possible de tout compiler avec vos options choisies avec amour ?

Gentoo propose ça.

Concrètement, l’intérêt est uniquement pédagogique, pour comprendre le fonctionnement d’un Linux.

La plupart du temps, une béquille est proposée sous forme de paquet binaire, pour gérer des monstres comme Libreoffice ou Firefox.

Paquets binaires

Les paquets binaires sont déjà compilés et s’installent beaucoup plus rapidement. Des systèmes spécifiques de paquet apparaissent, comme les .deb (techniquement dpkg, en 1994) et .rpm (en 1997). D’autres formats apparaitront plus tard.

Les paquets civilisés apportent les fonctionnalités suivantes :

Gestion des paquets dépendants ou recommandés
Gestion des conflits de paquets
Suppression du paquet et des paquets dépendants orphelins
Signature cryptographique pour ne plus craindre la falsification
Proposition d’une configuration par défaut
Redémarrage des services liés
Possibilité de reconstruire le paquet à partir d’un paquet source

Bibliothèques

Pour mutualiser la place (et historiquement la mémoire), les systèmes d’exploitation utilisent des bibliothèques partagées, un bout de code qui pourra être utilisé par plusieurs applications (et même d’autres bibliothèques).

La plupart des UNIX (dont Linux) utilise le standard ELF qui utilise le format shared objects, aka .so, pour ses bibliothèques dynamiques.

La commande ldd permet de lister qui est lié à quoi.

Découverte d’une faille de sécurité OpenSSL ? Hop, il suffit de mettre à jour libssl et de redémarrer toutes les applications qui l’utilisent avec un intuitif lsof +c 0 | grep libssl | awk '{print $1}' | sort | uniq ou en faisant confiance à votre gestionnaire de paquets.

Le comportement des bibliothèques est similaire pour la plupart des langages, mais les langages interprétés, mais pas ceux qui compilent en statique.

Spaghettis de liens

Avec des cascades de bibliothèques, il est possible de créer des drames grandioses, comme un CVE niveau 10 avec la tant redoutée CVE-2024-3094 qui infect liblzma utilisé par libsystemd utilisé par openssh. Les détails gores sont là.

Micro-bibliothèques

Les langages modernes fournissent un ensemble de bibliothèques classiques, pour avoir un socle commun et surtout une qualité constante (indispensable pour les bibliothèques liées à la sécurité). On parle de “bibliothèque standard” ou “piles incluses”.

Pour ne pas assumer ce travail, certains langages ont fait le choix des micro-bibliothèques qui ne font pas grand-chose et devrait pouvoir être remplacé facilement en cas d’abandon.

Concrètement, chaque micro-bibliothèque dépend de beaucoup de bibliothèques. Chaque projet se retrouve alors avec une ribambelle de dépendances. La quantité est telle qu’il y aura forcément une partie des dépendances mal maintenue ou devenant incompatible.

On ne nommera pas le langage le plus enfoncé dans ce choix, mais un simple npm audit vous donnera l’état d’un de ses projets.

Paquets de bibliothèques

Emballer les bibliothèques partagées est un choix évident, et il est même possible de proposer diverses variantes, mais une seule version (ce qui est de moins en moins vrai).

Les langages interprétés utilisent, eux aussi, des bibliothèques, mais dans leur propre format.

La compilation statique (les bibliothèques sont intégrées au binaire) permet de résoudre (violemment) le souci des versions épinglées. Go et Rust compilent systématiquement leurs bibliothèques en statique, tant pis pour la taille du binaire, mais au moins, on évite les pinaillages de compatibilité de versions.

Des distributions comme Debian mettent un point d’honneur à pouvoir recompiler n’importe quel paquet sans dépendre de sites tiers. Démarche honorable, mais hors C/C++, la plupart des applications utilisent des pelletées de bibliothèques (pas forcément dans la même version), et ne corrigent les failles de sécurité que dans la version courante.

Donc, même s’il est possible d’empaqueter des applications sans dépendances, l’obligation de fournir des paquets sources des bibliothèques utilisées pour les compiler vire rapidement au drame.

Techniquement, le vendoring (copie des sources des bibliothèques dans le projet) peut résoudre la possibilité de recompiler sans dépendre de sites tiers, mais en remplissant le disque dur de multiples copies.

Paquets tiers

Certaines applications ne rentrent pas dans les clous d’une distribution, comme on l’a vu précédemment.

Les outils pour créer des paquets sont fournis avec la distribution, et pour les formats de paquet contemporains, la tache est triviale.

Le premier intérêt de fournir des paquets éditeurs et la liberté de faire des montées en versions fonctionnelles à son rythme, pas une fois par an.

La gestion des bibliothèques dans les paquets tiers est compliquée (versions, options différentes…).

Différents paquets pour différentes distributions dans différentes versions (et différentes architectures) va rapidement devenir pénible (même si une CI/CD facilitera beaucoup le travail). La création, même laborieuse, est faisable, par contre, la gestion de bugs spécifiques ou de bibliothèques dont les versions sont incompatibles, va rapidement devenir infernal. La distribution en paquets systèmes d’application avec le support technique d’un éditeur ne se fera que pour quelques distributions.

Les entrepôts de paquets tiers, fort pratique, n’ont pas forcément les mêmes performances et disponibilité qu’un entrepôt de distribution.

Les mises à jour de sécurité devraient être équivalente, mais la non garantie de figer les fonctionnalités peut amener des surprises lors des mises à jour. Chose que devrait attraper les tests (intégrations et fonctionnels) dans la CI.

Déployer une application métier dans des paquets systèmes

Il ne faut plus compiler du code métier sur le serveur de production. Rails avec sa compilation des assets l’a démontré dans la douleur.

Un artefact est créé à partir des sources de l’application, puis déployé en production. Ne vous faites pas de mal, ne déployez jamais d’application métier dans un .deb, jamais.

Cohérence des versions et mises à jour

Les distributions garantissent plus ou moins la cohérence entre les paquets. Plus pour Debian, moins pour Archlinux (et Slackware).

Debian a fait le choix de l’hyper-cohérence entre les paquets et refuse de changer la version d’un paquet dans une distribution.

Des aplications utilisent des bibliothèques dans des versions très récentes, modifiées ou compilées avec des options spécifiques.

L’exemple classique est v8, le moteur Javascript de Google connu pour ses montées en versions frénétiques. Chromium, Nodejs et Mongodb (quand il était encore libre) utilisent des v8 différents, ce qui les excluent de fait des entrepôts Debian.

Debian fait bien sûr rigoureusement les mises à jour de sécurité, mais en rapiéçant (patch) le code, pour ne RIEN changer au niveau fonctionnel, et donc de n’amener aucunes surprises aux applications qui utilisent ces paquets.

Globalement, l’engagement de stabilité fonctionnelle est tenu.

Monorepo, solution ultime pour la cohérence et la fraicheur

Le monorepo (une seule source de code versionné), principalement aux échelles titanesques de Google ou Meta, permet d’avoir une cohérence rigoriste entre les bibliothèques partagées par les différents services.

Dès que l’on pousse une modification de code, non seulement ses tests sont lancés, mais surtout, déclenche les tests toutes les applications avec la nouvelle version de la bibliothèque. La modification n’est pas validée tant que tous les tests concernés ne passent pas. Une fois validé, le déploiement continu se déclenche (progressivement, avec comparaison des métriques avant et après la mise à jour). S’il y a une régression dans une application utilisant la bibliothèque, c’est à elle de corriger (et de blinder ses tests pour la prochaine fois).

Le déploiement passera par un artefact dans tous les cas, et à une époque, Facebook le faisait en pair à pair (son artefact avait une taille déraisonnable).

Fraicheur d’une distribution

La durée de vie d’une distribution se compte en années, et bien plus pour les versions LTS (support à long terme). La fréquence de sortie de nouvelles versions d’application n’est clairement pas le même.

Il y a eut des drames avec Clamav, par exemple, qui a stoppé le support de l’ancien format de description de virus, obligeant Debian à créer un nouvel entrepôt de paquets.

Le problème se pose pour les applications, mais aussi les bibliothèques, les interpréteurs (hors Perl qui est stable, lui), les outils de développement.

Développer avec des outils vieillissants est une punition.

Les navigateurs web sont les plus agressifs sur les montées en version, contraint par les soucis de sécurité, mais aussi par les fonctionnalités. De toute façon, la course à la version se fait sur les smartphones, Windows et MacOS, ce serait dommage que Linux se fasse distancer. Les applications web sont LE système universel pour distribuer des applications, surtout avec l’arrivée de webassembly, et pour ça il faut un socle sain, homogène et performant.

Ubuntu, pragmatique, ne fournit plus de paquets .deb pour Firefox/Chromium. Enfin si, le paquet .deb se contente d’installer le navigateur avec un autre système de paquet, sacrilège pour les puritains.

Mise à jour roulante

Plutôt que de fournir des versions gravées dans le marbre tous les ans (voir plus), des distributions choisissent de ne jamais figer les versions, d’avancer continuellement.

Archlinux, une sorte de Gentoo civilisé, ne sort jamais de version, enfin, pas jamais, tout le temps, suivant le principe de mise à jour roulante (rolling update). La possibilité de faire une mise à jour n’est pas garanti, il faut les faire régulièrement pour limiter les drames.

Amateur de Debian Sid, voici un nouveau challenge.

Distribution immuable

Les distributions immuables (comme feu CoreOS) garantissent une cohérence ultime. Pas de gestion de paquets, donc ni ajout ni suppression ni mises à jour possibles. Tout est gravé dans le marbre. Pour protéger le marbre, la partition racine est montée en lecture seule.

L’image est construite à partir de paquets (pour ne pas en utiliser ensuite). CoreOS utilisait les paquets de Gentoo, et des rpm dans sa reprise par Redhat, Fedora-CoreOS.

Le choix est extrême, mais l’idée est de servir de socle pour une abstraction de plus haut niveau. Imaginé pour les conteneurs, ils peuvent aussi gérer des machines virtuelles.

Pour mettre à jour, il suffit de redémarrer sur une nouvelle version. Techniquement, il y a deux partitions bootables, la courante, en lecture seule, la version suivante sur laquelle on a appliqué des patchs, soit n et n+1. Si le redémarrage de mise à jour se passe mal, rembobinage sur la dernière version connue comme stable.

Ce type de distribution n’est pas réservée aux serveurs, il en existe des dédiées aux bureaux.

Méta-paquets

Entre le tout paquet des distributions classiques et le sans paquets des distributions immuables, il y a une place pour des solutions plus souple.

Une application métier va s’appuyer sur un ensemble d’outils systèmes, soit un tout petit bout d’un serveur Linux.

Oui, certaines technologies isolationnistes permettent de s’en passer.

Une application dans une image ne va pas dépendre du système hôte (distribution et version), mais juste des capacités du noyau.

Environnements virtuels spécifiques aux langages

Tous les langages de script savent utiliser un environnement spécifique à l’application (et pas global). Les bibliothèques utilisées seront spécifiques à cet environnement, dans des versions précises. Tout sauf utiliser les bibliothèques empaquetées par la Distribution.

Python a venv
Ruby a Bundler
PHP a Composer
Golang, Rust, Nodejs le font par défaut

Partir d’une liste de bibliothèques dans des versions précises est l’approche recommandée par les outils qui chassent les versions trouées (comme le Dependabot de Github mais surtout l’OSV, comme évoqué dans mon billet Sécuriser Internet).

La plupart des langages utilisent une description des dépendances avec des contraintes sur les versions, puis un autre fichier qui contient les versions gelées, celles choisies lors de la dernière montée en version.

L’utilisation de bibliothèques partagées (des .so) va un peu casser l’universalité de cette solution.

Pour avoir un environnement d’exécution déterministe et donc normalisé, du poste du développeur à la production en passant par la CI, il va falloir utiliser quelque chose de plus costaud.

Images immuables pour la virtualisation

Netflix a communiqué sur sa tactique de création d’images immuables démarrées dans EC2. Celui qui n’a pas souffert avec Packer ne peut imaginer à quel point cette approche est laborieuse et pénible. Même avec Cloud-init.

Cloud-init permet de configurer une machine virtuelle au démarrage qu’elle que soit l’hébergeur.

Le kernel-less profite aussi de la (para)virtualisaiotn et réduit à l’os la taille de l’image disque, mais avec des contraintes radicales. On en a déjà parlé sur ce blog.

Images OCI (aka Docker et k8s)

L’image disque n’est pas la bonne échelle pour déployer une application (ça va mieux en le redisant).

Les conteneurs utilisent des images avec un bout d’arborescence Linux, indépendamment du choix de Distribution. L’arborescence est construite en couche d’oignons, mutualisés entre les conteneurs, avec tout en bas une image minimaliste basée sur une distribution Linux.

L’application dans un conteneur est lancé dans un contexte isolé par diverses fonctionnalités du noyau Linux.

Docker en a prouvé la faisabilité, OCI l’a normalisé, et Kubernetes l’a déployé en cluster. Redhat l’a remis en cause avec Podman, qui ne comprend pas l’intérêt d’avoir un service pour gérer les conteneurs alors qu’il y a déjà Systemd.

L’image est construite avec des paquets (Alpine, Debian…) si l’application n’est pas un gros binaire statique.

Les courageux démarrent le conteneur en lecture seule, ce qui rend le conteneur encore plus prévisible. C’est bien au niveau sécurité (pas moyen de corrompre l’application), et aussi pour les écritures intempestives (log, debug ?) qui tenteront de remplir le disque dur.

Paquets agnostique pour le bureau

Proposer des paquets systèmes pour la pléthore de distribution Linux existante est tout simplement impossible.

Par contre, reprendre l’idée des .app de MacOS (de Next en fait), en ajoutant une couche de sécurité (et une sous-couche mutualisée) permet de distribuer une application sans les contraintes de l’hôte.

Les outils de bas niveaux et les fonctionnalités du noyau sont essentiellement celles utilisées par les conteneurs.

Flatpack

Flatpak permet de distribuer des applications, même propriétaire sous Linux sans se soucier de la distribution et de sa version. L’application est dans un “bac à sable”, et demandera des droits pour agir avec l’hôte, comme le font les applications sur téléphones.

Flatpack utilise les mêmes outils d’isolation de Linux que les conteneurs. Plutôt que du Layering, Flatpack dédoublonne les fichiers avec OStree.

Il fournit un ensemble de Runtime, sur lesquels on va pouvoir compiler ses applications. Niveau paquet, on est très hardcore, ce sera le classique ./configure && make && make install.

Les runtimes sont fournis par Freedesktop, le grand réconciliateur du monde Linux. Freedesktop-sdk est construit à partie de rien, sans paquets.

Des runtimes spécifiques sont fournis, comme Gnome ou KDE, et il est possible de faire cohabiter différentes versions.

Fedora, choqué à l’idée de ne pas utiliser ses rpm a négocié l’utilisation des images OCI en plus du OSTree originel.

Snap

Plutôt que de se fatiguer à faire du lobbying comme Redhat pour Flatpack, Unbuntu a créé son Snap.

Le fonctionnement de Snao est très, très classique.

Un bout d’arborescence sur un Squashfs (système de fichier compressé en lecture seule) posé sur une Base (une Ubuntu LTS) et des droits fins pour accéder à l’hôte.

La construction de paquet est isolée par LXD (un outil de conteneur pour les ringards) et utilise des .deb.

On voit bien l’intérêt d’Ubuntu de pouvoir proposer un Firefox frais sans casser la cohérence de sa distribution, tout en s’appuyant sur son propre écosystème, mais c’est navrant de voir une dispersion entre Flatpack et Snap qui font, à quelques pinaillages près, la même chose.

Entrepôt d’artefacts

Il faut pouvoir mettre à disposition les paquets (quelque soit leur forme) que l’on souhaite utiliser. Du poste de dev à la prod en passant par la CI.

Chaque technologie expose son entrepôt en ligne (et doit avoir une facture sympa en CDN).

Il est possible de cacher ces entrepôts, au fur et à mesure, ou de créer des miroirs (s’il est centralisé). La cache des entrepôts, fort important pour l’intégration continue sera le sujet d’un autre billet.

Signatures

Pour éviter la falsification des paquets (suite à une compromission du serveur ou via un miroir menteur), il faut signer les paquets.

Techniquement, on calcule le hachage du paquet, qui est signé avec une clef asymétrique.

Chaque langage a son propre système de signature à base de clefs asymétriques et de chaines de confiance.

GPG est souvent utilisé même si le principe de la chaine de confiance est une utopie ratée. Pour pallier ça, un trousseau de clefs de confiance (qui permettent de signer les clefs des mainteneurs) est fournie avec la distribution ou avec les entrepôts tiers.

Pour généraliser tout ça et surtout pouvoir signer n’importe quel artefact sans passer par une poignée d’autorités de certification (comme le fait TLS), une nouvelle approche universelle est proposée : Sigstore (comme évoqué dans le billet Distroless).

Qu’une personne signe un paquet n’a pas beaucoup de sens. Un mainteneur peut le faire, car il est le seul responsable de ce paquet. Pour un développeur, signer un commit est logique, mais comme le code libre est en théorie réalisé à plusieurs, qui est légitime pour signer le paquet ? Un éventuel “dictateur bénévole à vie” qui valide toutes les modifications ? Une entité regroupant les développeurs (et ceux qui valident les contributions externes) est légitime. Une fondation ou une entreprise par exemple, et par extension un entrepôt centralisé.

Les CI peuvent maintenant signer les artefacts en leur nom (Github par exemple).

Cette confiance peut être chainée, des entrepôts font confiance à la signature de Github.

C’est le principe du Sigstore de Sigstore.

Microsoft, propriétaire de Github, se retrouve quand même avec un beau “All your base are belong to us”.

La gestion de la chaine de confiance dans les entrepôts de paquets (hors paquets des distributions) a longtemps était inexistante ou catastrophique comme l’a démontré la CVE-2022-29176 avec un excellent score de 9.9.

Git

Git n’est pas tout à fait un entrepôt de paquets, mais comme il est possible de désigner une bibliothèque avec une URL Git, on peut le qualifier de paquet source.

Un commit git peut être signé avec GPG, et, depuis peu, avec Sigstore via gitsign.

Python

Python signe les artefatcs de CPython, avec Sigstore et déprécie GPG dans sa PEP-761.

Python galère depuis une dizaine d’années malgré de gros financements (voir la PEP-480 et les discussions attenantes).

Il est possible de signer les paquets avec GPG mais sans trousseau de confiance, ça reste aléatoire.

Plutot de que de mal réinventer la roue, Python choisit l’approche de Sigstore où l’entrepôt, Pypi, signe son index de paquets en s’engageant sur l’identification des publieurs avec l’authentification à deux facteurs (forte) obligatoire depuis fin 2023.

Nodejs

Npm signe les index de son entrepôt avec ECDSA (et abandonne GPG).

Les publieurs peuvent utiliser l’authentification à deux facteurs

Npm ne permet pas de signer un paquet.

Golang

Golang utilise un système non orthodoxe pour la publication de ses modules. Le binaire d’un module n’est pas publié, mais uniquement ses sources, accessible par un tas de gestionnaire de source (VCS) : bzr (le machin d’Ubuntu), fossil, git, hg et svn (le CVS des dinos à la page).

Golang propose un proxy, pour ne pas saturer les urls source, un index, pour connaitre les mises à jour disponible et une base de données de checksum (dont les modifications sont auditables) qui contient les hachages des versions des modules, signés par Golang (la clef publique étant connu par la commande go).

Golang fait confiance au service qui héberge le code utilisant des urls de modules non ambigües et universelles.

Docker/OCI

L’entrepôt OCI peu fournir la signature d’une image. L’incontournable Sigstore est utilisé avec l’outil cosign.

Il est possible de téléverser et signer des images OCI sur l’entrepôt open sourcre et éphémère ttls.sh.

PHP

Composer signe ses paquets avec une clef publique (deux en fait).

Un paquet Phar peut être signé avec un hash (une belle confusion technique comme le rappelle la CNIL) ou avec OPENSSL.

Phar.io dit le contraire et vante la signature GPG.

Pour dire vrai, l’écosystème PHP ne m’intéresse plus depuis bien longtemps.

Rust

Rust tergiverse sur l’implémentation de signature de paquet et lorgne vers TUF dans la RFC dédiée et regarde du côté de Sigstore.

Au delà des paquets

Il n’y a pas une technologie universelle de paquets.

L’approche raisonnable est d’empiler les couches :

Une distribution Linux utilisant des paquets systèmes (au moins pour sa création).
Un conteneur minimaliste (variante slim) qui montera en version plus régulièrement que son hôte.
Une application développée avec un nombre raisonnable de paquets spécifiques au langage, périodiquement audités (par un robot comme OSV-scanner) avec des tests pour vérifier la montée en version des dépendances, puis déployée par la CI.

Les langages qui créent de gros blobs (golang, rust, java…) n’ont pas forcément besoin de conteneurs, juste d’isolation (cgroup, namespace…).

Si vous détestez vraiment les paquets, il vous faut de l’unikerl (évoqué dans le billet kernel-less).

Comme dit l’adage :

Les paquets, c’est cadeau

Apprendre Pyxel : carte de tuiles et collision

2025-01-12T14:48:00+01:00

Quatrième chapitre de l’apprentissage de Pyxel, framework de retro game avec son moteur en Rust (pour la fluidité) et son API en Python (pour la simplicité).

Cette démo explore le jeu de plateforme avec une carte de tuiles créée dans un logiciel spécifique.

Démo

Le héros, nommé Jones, explore les dangereuses ruines d’un temple oublié.

Assets

Jusqu’à présent, les démos n’utilisaient que peu de graphismes, mais là, pour expliquer l’utilisation des cartes et des collisions, il va falloir plus de pixels, beaucoup plus.

Pour le défi, et pour avoir un aspect encore plus vintage, les sprites seront cette fois-ci de 8 pixels de côté.

Carte de tuiles

Historiquement, pour gérer l’affichage avec très peu de RAM et une carte graphique antique, tout était tuiles. L’écran est alors rempli de gros carrés qui peuvent être répétés.

La Game Boy, par exemple, utilise un Picture Processing Unit capable de gérer jusqu’à 40 sprites de 8 x 8 ou 8 x 16 sur un écran de 160 x 144 pixels, sur 3 calques, et seul le dernier permet de positionner le sprite au pixel près.

Pyxel se contente de rendre hommage aux vieilles consoles, la plupart des contraintes sont des conventions, comme la palette réduite ou le tout petit écran.

Les cartes permettent de composer une grande image (et même plus grande que l’écran, permettant ainsi de déplacer la caméra pour un effet de scroll) à partir de tuiles. Certaines tuiles , par convention, peuvent être considérées comme solides, pour que le personnage puisse marcher dessus et ne pas tomber.

Pyxel (arbitrairement) ne peut gérer que 3 cartes.

Concrètement, les cartes permettent de travailler à 3 sans se marcher sur les pieds:

Le graphiste crée le jeu de tuiles et le peaufine ensuite.
Le game designer compose la carte à partir du jeu de tuiles pour avoir quelque chose de jouable et d’intéressant.
Le développeur utilise la carte pour vérifier les actions (courir, sauter…) et les comportements (tomber, se cogner dans un mur…) du personnage.

Pyxel fournit un éditeur de carte, mais il est un peu rugueux (comme tout ce que propose son éditeur d’assets).

Tiled est un éditeur de cartes un poil plus civilisé, et il est utilisable par quantité de moteurs de jeux. Attention, Pyxel ne sait pas utiliser toutes les options de Tiled, ni tous les formats de sortie.

Tiled

Pyxel gère les cartes TMX avec les calques (pas plus de 3).

Les TSX (jeu de tuiles) doivent être embarqués dans la carte TMX.

Les tuiles non définies dans la carte seront remplacées par le premier bloc du jeu de tuiles.

Pour que la carte gère la transparence (pour avoir un fond uni, par exemple), il faut utiliser une tuile uniforme, dont la couleur sera utilisée comme transparence.

La palette de couleurs utilisée par Pyxel sera issue de la carte.

Nouvelle carte

Nouveau fichier : ctrl-N

Orientation: orthogonale
Format de calque des tuiles: CSV
Ordre d’affichage des tuiles: En bas à droite
Taille de la carte: 20 tuiles x 15 tuiles, soit 160 x 120 pixels
Taille des tuiles: 8 x 8 pixels

Le jeu de tuiles doit être disponible pour créer une carte, mais ne vous inquiétez pas, il est possible de modifier le PNG, Tiled le rechargera tout seul (sinon, un ctrl-r fera l’affaire).

Tout en bas à droite, le bouton Nouveau jeu de tuiles…

Nom: mettez ce que vous voulez, sinon, le nom par défaut est basé sur le nom du fichier.
Type: Basé sur l’image du jeu de tuiles
Embarquer la carte: ✔︎
Source: le chemin du PNG, sélectionnable via [ Parcourir… ]
Largeur/Hauteur: 8 pix
Marge/espacement: 0 pix
Utiliser la couleur transparente: ✔︎ puis le second carré, qui fait apparaitre une mini-carte avec le PNG pour sélectionner la couleur.

La carte apparait dans le coin bas-droite, microscopique, il faut zoomer avec le menu déroulant, pour atteindre au moins les 400%.

Créer sa carte

La grille dans la zone principale, trop petite et mal centrée. ctrl-+ et ctrl-- pour zoomer, sinon, on peut tricher avec ctrl-:. Pour les adeptes du menu, ces réglages sont rangés dans Vue.

Sélectionnez une tuile dans le jeu de tuiles en cliquant dessus, elle devient grisée. Avec l’outil Tampon (raccourci : B), vous pouvez tamponner de la tuile à volonté sur la carte. Pour l’esthétique, pour les plateformes, faites attention à commencer par une tuile début, terminer par une tuile fin, et au milieu des tuiles milieu.

Il ne faut pas utiliser le personnage (qui sera utilisé comme sprite), la carte ne doit contenir que des éléments statiques.

Enregistrer le fichier, ctrl-s, au format TMX.

Tuiles

La carte a besoin d’éléments regroupés dans un fichier PNG. Sélectionnez un éditeur spécialisé dans le pixel-art et non un gros éditeur qui sera frustrant (Krita, Gimp, PowerPoint…).

Comme outil libre et multi-plateformes, je vous propose :

Piskel est un éditeur web. OK, il est abandonné depuis 6 ans, mais il fonctionne bien, et il est possible de sauvegarder les fichiers source en local.
Pikopixel est un éditeur conçu pour GNUStep, mais qui fonctionne sur la plupart des plateformes.

Il doit surement en exister d’autres, dont certains propriétaires, comme Pixen.

Utilisez une palette de couleur réduite, ça aidera à rendre l’ensemble cohérent, et ça rend hommage aux anciens. Il y a des sites pour ça, comme Colorkit.

Décors

Le plus important dans ce type de jeu sont les plateformes. Il faut donc un début, un milieu, une fin de plateforme. Pour simplifier la gestion des collisions, il faut que ces blocs utilisent au maximum les 8 pixels des sprites.

Il est aussi possible d’utiliser des tuiles pour décorer, qui ne gênent pas la progression du personnage.

Le jeu de tuiles (32 x 32 pixels) de la démo est organisé par ligne :

La plateforme : début, milieu, fin
Des décors : herbes, torche, vase
Le héros : marche 1, marche 2, tombe, saute

Les tuiles sont transparentes, mais pour la lisibilité, le héros a un contour noir (la couleur du fond dans le jeu), pour se détacher du fond.

Les ruines vides

On va commencer tranquillement, en se contentant d’afficher le décor.

Le PNG est chargé dans l’emplacement 1 de la banque d’images.

Le calque 0 du TMX est chargé dans l’emplacement 1 de la banque de cartes.

L’image 1 est connectée à la carte 1.

Dans draw, la carte est affichée. Le troisième élément désigne la carte 1. Le dernier élément désigne la couleur de transparence.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="The temple")  # width, height, title
        pyxel.images[1] = pyxel.Image.from_image("temple.png", incl_colors=True)
        pyxel.tilemaps[1] = pyxel.Tilemap.from_tmx("temple.tmx", 0)
        pyxel.tilemaps[1].imgsrc = 1  # The map uses this image for its sprites

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

    def draw(self):
        pyxel.cls(9)  # Clear screen
        # x, y, tm, u, v, w, h
        pyxel.bltm(0, 0, 1, 0, 0, pyxel.width, pyxel.height, 0)


App()

Il y a une astuce pour obtenir la palette et connaitre le rang des couleurs : Pyxel fournit un raccourci pour sauvegarder la palette de couleurs sous forme de PNG : Ctrl-Shift-Alt-0.

Tomber dans le vide

Pour bien isoler les parties du code, une class abstraite Sprite est utilisée, ainsi qu’un moteur (primitif) de physiques.

Collisions connait la liste des tuiles solides (leurs coordonnées dans le jeu de tuiles), qui ne peuvent pas être traversées. Dans ce jeu, point de mur, juste du sol pour atterrir avec grâce. Pour éviter les références croisées, Collisions est un attribut de App confié à la méthode update du Sprite.

Le personnage (un Sprite) va pouvoir s’avancer dans le vide au bord d’une plateforme, jusqu’à ce que son dernier pixel soit au-delà du dernier pixel de la plateforme.

import pyxel


class Sprite:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.direction = 1  # 1: -> -1: <-


class Physics:
    def __init__(self, solids: list[tuple[int, int]]):
        "List of solid tiles"
        self.solids = solids
        self.map = 1

    def floor(self, sprite: Sprite) -> bool:
        "Does the sprite have floor under its feet?"
        if sprite.direction == -1:  # the tile before
            x = pyxel.ceil(sprite.x / 8)
        else:  # the tile after
            x = pyxel.floor(sprite.x / 8)
        # the tile under the feet of Jones
        tile = pyxel.tilemaps[self.map].pget(x, sprite.y // 8 + 1)
        return tile in self.solids

    def too_low(self, sprite: Sprite) -> bool:
        "Does the sprite fall under the bottom of the screen?"
        return sprite.y >= (pyxel.height - 8)

Jones hérite de Sprite. De manière similaire aux chapitres précédents, Jones va gérer un state qui va permettre de choisir la bonne image, et de gérer la physique, essentiellement les sauts et les chutes.

C’est le héros qui va gérer l’affichage clignotant du tant redouté GAME OVER.

TRANSPARENT = 0

WAITING = 0
WALKING = 1
FALLING = 2
JUMPING = 3
DEAD = 4


class Jones(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.images_right = [(i * 8, 16, 8, 8, TRANSPARENT) for i in range(4)]
        self.images_left = [(i * 8, 16, -8, 8, TRANSPARENT) for i in range(4)]
        self.state = WAITING
        self.how_high = 0
        self.death_time = 0

    def image(self) -> tuple[int, int, int, int, int]:
        if self.direction == 1:
            images = self.images_right
        else:
            images = self.images_left

        if self.state == FALLING:
            return images[2]
        if self.state == WALKING:
            return images[(pyxel.frame_count // 5) % 2]  # move legs every 5 frames
        if self.state == JUMPING:
            return images[3]
        # WAITING
        return images[0]

    def physic(self, world: Collisions):
        if self.state == DEAD:  # there is no physics when you are a soul
            return
        if self.state == JUMPING:
            if self.y > self.how_high:
                self.y -= 2
                self.x += self.direction
            else:  # start falling soon
                self.state = WAITING
            return
        if world.too_low(self):
            self.death_time = pyxel.frame_count + 30
            self.state = DEAD
            return
        if world.floor(self):
            if self.state == FALLING:
                self.state = WAITING  # soft landing
            return
        else:
            self.state = FALLING
            self.y += 2

    def move(self, direction):
        if direction == 0:
            self.state = WAITING
        else:
            self.state = WALKING
            self.direction = direction
            self.x += self.direction * 2

    def jump(self, direction):
        self.state = JUMPING
        self.how_high = self.y - 16
        self.direction = direction

    def update(self, world: Collisions):
        if self.state in (WAITING, WALKING):
            if pyxel.btn(pyxel.KEY_RIGHT):
                dx = 1
            elif pyxel.btn(pyxel.KEY_LEFT):
                dx = -1
            else:
                dx = 0

            if pyxel.btnp(pyxel.KEY_UP):
                self.jump(dx)
            else:
                self.move(dx)
        if self.state == DEAD and pyxel.frame_count > self.death_time:
            pyxel.quit()
        self.physic(world)

    def draw(self):
        if self.state == DEAD:
            if pyxel.frame_count % 10 < 5:
                pyxel.text(70, 10, "GAME OVER", 8, None)
        else:
            pyxel.blt(self.x, self.y, 1, *(self.image()))

L’application, App, est super classique. Elle va charger les assets, instancier le moteur de physique avec les trois premières tuiles comme étant solides, puis instancier le héros, qui commence la partie sur une chute.

class App:
    def __init__(self):
        pyxel.init(160, 120, title="The temple")  # width, height, title
        pyxel.images[1] = pyxel.Image.from_image("temple.png", incl_colors=True)
        pyxel.tilemaps[1] = pyxel.Tilemap.from_tmx("temple.tmx", 0)
        pyxel.tilemaps[1].imgsrc = 1  # The map uses this image for its sprites

        self.world = Physics([(0, 0), (1, 0), (2, 0)])

        self.jones = Jones(8, 0)

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()
        self.jones.update(self.world)

    def draw(self):
        pyxel.cls(9)  # Clear screen
        # x, y, tm, u, v, w, h
        pyxel.bltm(0, 0, 1, 0, 0, pyxel.width, pyxel.height, 0)
        self.jones.draw()


App()

Les sources de Jones sont disponible sur Github.

La suite

Le personnage pourrait courir (en plus de marcher) pour pouvoir faire des sauts plus longs.

Il pourrait aussi s’accrocher quand il finit son saut sur un mur, puis remonter sur la plateforme (comme dans Prince of Persia).

Il pourrait s’arrêter en dérapant juste au bord du vide (comme dans Flashback).

Pour l’ambiance, ce serait bien d’avoir la flamme des torches animées (en recouvrant l’image de fond par un autre sprite).

Les herbes pourraient onduler au passage du héros (et continuer quelques secondes après).

Learning Pyxel: Moving Sprites with the Mouse

2025-01-07T16:48:00+01:00

Here is a new chapter in the “Learn Pyxel the Soft Way” book. Pyxel is a retrogaming framework built with Rust for the smoothness of the games, exposing a Python API for simplicity and expressivity.

This demo is a bit more complex than the previous one : keyboard and flying saucer. Don’t worry; the learning curve is still flat.

Books for learning Python

No Starch Press’ Python for Kids, second edition
O’Reilly’s Learning Python, sixth edition

You already found a great book for learning Python, didn’t you?

And you already start to read it ?

Please, RTFB (Read The Python Book): you can’t learn development from Youtube videos or copy-pasting tutorials.

Demo

This time, with the mouse, the player will tell a cute bat where to fly in its dark cave.

Assets

The assets are two sprites of the bat, two square images of 16x16px. The first one has wings up, the second one has wings down.

You can also download the bat.pyxres file.

Code

For clarity, the bat has its own class : Bat.

The purpose of a class is to wrap all its needs.

A bat flapping its wings

The frame attibute points to the current sprite : 0 for wings up, 1 for wings down.

The swap_wings methode switches from one state to the other : up, down, up …

In the draw method, the wings are swapped every 10 frames, then drawn on the screen. One flap every 10 seconds is slow, but it’s a bat, not a hummingbird.

The App class is bare-bones: setting the game, starting the main loop. The only difference with the flying saucer App is instantiating the Bat class and asking it to draw itself.

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [ # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        self.frame = 0 # 0 : bat wings are up, 1 : down

    def swap_wings(self):
        "The wings switch from up to down."
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite"
        if pyxel.frame_count % 10 == 0: # Every 10 frames, the wings flip
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres") # Load the assets.

        self.bat = Bat(72, 72) # Spawn a new bat 🦇

        pyxel.run(self.update, self.draw) # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q): # Hit Q to quit
            pyxel.quit()

    def draw(self):
        pyxel.cls(0) # Clear screen
        self.bat.draw() # Draw the bat at its current position


App()

The game just drew a flapping bat in the middle of the screen. You can do nothing, just quit when hitting the Q key. Yes, it’s frustrating.

A bat following the mouse when you click

Show the cursor with pyxel.mouse(True). A left click (pyxel.MOUSE_BUTTON_LEFT) moves the bat to the cursor position.

If the left click is maintained, the bat follows the movements of the mouse. You can shake the bat (but it’s not nice to do that).

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [  # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        self.frame = 0  # 0 : bat wings are up, 1 : down

    def swap_wings(self):
        "The wings switch from up to down."
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite."
        if pyxel.frame_count % 10 == 0:  # Every 10 frames, the wings flip
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres")  # Load the assets.

        self.bat = Bat(72, 72)  # Spawn a new bat 🦇

        pyxel.mouse(True)  # Show the mouse

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.MOUSE_BUTTON_LEFT):
            self.bat.x = pyxel.mouse_x
            self.bat.y = pyxel.mouse_y
            pyxel.mouse(False)
        else:
            pyxel.mouse(True)

    def draw(self):
        pyxel.cls(0)  # Clear screen
        self.bat.draw()  # Draw the bat at its current position


App()

Yes! In this step you can do something. Not so much, but something.

A bat flying to the click position

Let’s remove the code that links the bat to the mouse.

In this ambitious step, some math (8th grade) will be used to compute the path:

The distance function computes the distance between two points with a little help from our friend Euclid.
The angle function computes the angle from one point to the other (it’s trigonometry).

Technically, we switch from Cartesian to Polar coordinates.

The vector between the actual position and the clicked target is computed.

Every frame, the bat moves one step (its speed) following the vector. If the distance between the bat and the target is lower than the step, the bat stops. Here, vectors and steps use real numbers (ℝ aka float), and the screen uses natural numbers (ℕ aka integer), and there are rounding troubles between them.

Pyxel uses the top left corner of a sprite as its zero. Without correction, the top left corner of the bat will stop on the clicked target. It’s counterintuitive and ugly.

The vector must use the center of the sprite: x + width / 2 and y + height / 2.

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [  # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        # self.x is the top left corner of the image,
        # computing the position of the center of the bat is more intuitive
        self.center_x = self.images[0][2] / 2
        self.center_y = self.images[0][3] / 2
        self.frame = 0  # 0 : bat wings are up, 1 : down
        self.angle = 0  # Where does the bat look ?
        self.target_x: int  # The bat goes to this target.
        self.target_y: int
        self.speed = 0

    def move_to(self, x, y, speed):
        "The bat rotates and will move to the target."
        self.target_x = x
        self.target_y = y
        self.speed = speed
        self.rotate_to(x, y)

    def rotate_to(self, x, y):
        self.angle = angle(x, y, self.x + self.center_x, self.y + self.center_y)

    def one_step(self):
        "The bat moves to its target."
        if self.speed != 0:
            delta = distance(
                self.target_x,
                self.target_y,
                self.x + self.center_x,
                self.y + self.center_y,
            )
            if delta <= self.speed:
                self.speed = 0
            else:
                self.x += pyxel.sin(self.angle) * self.speed
                self.y += pyxel.cos(self.angle) * self.speed

    def swap_wings(self):
        "The wings switch from up to down."
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite."
        if pyxel.frame_count % 10 == 0:  # Every 10 frames, the wings swap
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


def distance(x1, y1, x2, y2: float) -> float:
    "Euclidean distance"
    dx = x1 - x2
    dy = y1 - y2
    return pyxel.sqrt(dx**2 + dy**2)


def angle(x1, y1, x2, y2: int) -> float:
    "Get the angle between two points with trigonometry."
    dx = x1 - x2
    dy = y1 - y2
    return pyxel.atan2(dx, dy)


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres")  # Load the assets.

        self.bat = Bat(72, 72)  # Spawn a new bat 🦇

        pyxel.mouse(True)  # Show the mouse

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.MOUSE_BUTTON_LEFT):  # Mouse click set the target
            self.bat.move_to(pyxel.mouse_x, pyxel.mouse_y, 2)  # x, y, speed

        self.bat.one_step()  # The bat flies, one step at a time

    def draw(self):
        pyxel.cls(0)  # Clear screen
        self.bat.draw()  # Draw the bat at its current position


App()

The path is computed for each click; you can force the bat to swing chaotically if you click frenetically on the screen.

In genuine 8-bit games, sprites are squares. If you need to compute collisions, or if one sprite overlaps the other, don’t bother with Euclid. Just check if the pointer is lower than the top of the bat, higher than the bottom, further left than the right side, and further right than the left side.

You can modify the code for replacing the Euclid + Trigonometry part with the two squares dance as a tribute to the Game Boy with its tiny Sharp Z80 processor, clocked at 4.194304 MHz, and its 8ko of RAM.

With the current computers, even a Raspberry Pi, nobody will notice the performance difference.

The sources of Bat are hosted on Github.

Beyond

Own the code, change it, break it. Add missing behaviors.

A little bit of randomness in its flight to make it more shaky?

One more sprite for the standby position, upside down, wings folded ?

Some “flap flap” sounds when the bat flies?

Apprendre Pyxel : fuir le danger et game over

2025-01-05T18:15:00+01:00

Troisième chapitre de l’apprentissage de Pyxel, framework de retro game avec son moteur en Rust (pour la fluidité) et son API en Python (pour la simplicité).

Cette démo progresse en difficulté, avec de nouveaux concepts Python, et le risque de se faire tuer son personnage.

La démo va au-delà du monde des sprites, en traçant une ligne (qui reste heureusement pixelisée).

Démo

Dans cette démo, un héros explore un donjon, et rencontre un beholder. Le monstre va viser, tirer, tandis que le héros va tenter de l’esquiver.

Le joueur va utiliser son clavier pour contrôler le héros.

Assets

Les sprites sont rangés : par lignes, les personnages (et leurs états), par colonnes, la direction : bas (face), gauche, droite, haut (dos).

Le guerrier a un sprite de plus : l’électrocution.

Le héros se balade

Le guerrier peut se balader avec les flèches du clavier, il se tourne dans la bonne direction.

Pythoneries

Compréhension de liste

Pour créer des collections (dont les listes), Python dispose d’une syntaxe condensée.

Le code suivant :

a = [i for i in range(4)]

Est équivalent à :

a = []
for i in range(4):
    a.append(i)

Techniquement, ajouter des éléments à une liste est plus couteux que la syntaxe dense.

Démo

Une constante, TRANSPARENT, est utilisée pour désigner la couleur de transparence, sans avoir à la recopier dans tout le code et pour faciliter la lecture.

Un personnage a un attribut speed qui correspond à son déplacement en pixels, à chaque frame.

Les images sont ordonnées, l’attribut angle décrit simultanément vers où regarde le personnage, et son rang dans la ligne d’images.

La méthode move déplace le personnage d’un pas (l’attribut speed), dans la bonne direction.

Pour éviter une ribambelle de if, un multiplicateur est utilisé :

0 : rien
1 : en avant
-1 : en arrière

Par contre, pour éviter au personnage de sortir de l’écran, il faut une tartine de if.

La class App est très classique, les flèches du clavier sont utilisées pour déplacer (avec move) le personnage dans la bonne direction.

import pyxel

TRANSPARENT = 11


class Hero:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self):
        return self._images[self.angle]

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="The hero explores")  # width, height, title
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_DOWN):
            self.hero.move(0)
        if pyxel.btn(pyxel.KEY_LEFT):
            self.hero.move(1)
        if pyxel.btn(pyxel.KEY_RIGHT):
            self.hero.move(2)
        if pyxel.btn(pyxel.KEY_UP):
            self.hero.move(3)

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()


App()

Le héros de ballade devant le beholder qui le suit du regard

Pythoneries

Héritage de class

Deux personnages sont décrits par deux class, et comme elles ont pas mal de choses en commun (ce sont des sprites avec une direction).

Une class peut hériter d’une autre class. La class parente définit des attributs et des méthodes, les class enfants peuvent avoir leurs propres attributs/méthodes ou surcharger un élément de la class parente.

class Parent:
  def hello(self, txt):
    print("hello", txt)

class Child(Parent):
  def hello(self, txt):
    print("wazza", txt)

Il est possible pour une méthode surchargée d’appeler la méthode d’un ancêtre avec la fonction super().

class Parent:
    def say(self, txt):
        return "I say " + txt

class Child(Parent):
    def say(self, txt):
        return super().say(txt) + ", or not"

Pour obliger à surcharger une méthode, la méthode de la class parente doit lever une erreur NotImplementedError.

class Parent:
    def override_me:
      raise NotImplementedError

Assignation multiple

La syntaxe d’assignation d’une variable dispose aussi d’une syntaxe dense, avec des raccourcis.

Ici, seul l’assignation multiple est utilisé, dans sa forme la plus simple :

a, b = 1, 2

Ce qui équivaut à :

a = 1
b = 2

Typage

Python a du typage pour ses valeurs, mais pas de typage fort : une variable peut être réassignée avec une valeur de type différent.

Python utilise des indices (hints en VO) pour expliciter le type d’une variable. Python tient à garder le comportement historique : les indices ne sont pas pris en compte par l’interpréteur. Le typage est destiné (entre autres) à l’analyse statique (un robot lit et donne son avis sur votre code).

Les éditeurs modernes prennent en compte le typage pour ses suggestions, et pour raler (souligner en rouge) sur les parties de votre code qui ne respectent pas le typage.

a :int # a is an integer

Opérateur ternaire

Python dispose d’une syntaxe dense pour assigner une valeur avec une condition.

if dx > 0:
    angle = 1
else:
    angle = 2

Devient:

angle = 1 if dx > 0 else 2

Valeur 1, if, clause, else, valeur 2.

Attention à ne pas abuser des syntaxes denses qui peuvent anéantir la lisibilité.

Démo

Les comportements de base de Hero sont maintenant dans la class Sprite qui sera la class parente de Hero et Beholder.

La class Beholder a un attribut state, et utilise 2 lignes d’images. state permet de savoir quelle ligne utiliser, la direction reste la colonne comme dans la démo précédente (utilisée dans la méthode image).

Le beholder peut faire les gros yeux à une cible avec la méthode watch.

Un peu de maths : on calcule le delta entre les deux personnages sur l’axe horizontal et vertical, dx et dy. Si la distance horizontale est supérieure à la distance verticale, le beholder regarde à l’horizontal. Si dx est positif, il regarde à gauche, sinon à droite. Même sport pour l’axe vertical.

Dans la class App, la méthode update spécifie que la touche espace active l’état LOADING du beholder (il regarde en l’air), et qu’il surveille le héros.

import pyxel

TRANSPARENT = 11
# Beholder states
LOADING = 0
WAITING = 3


class Sprite:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed: int
        self.angle: int  # bottom, left, right, top
        self.state: int

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self) -> tuple[int, int, int, int, int]:
        # What is the current image
        raise NotImplementedError

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class Beholder(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.angle = 1
        self.speed = 2
        self.state = WAITING
        # The beholder can be normal : waiting, aiming, moving…
        self._main_images = [(i * 16, 0, 16, 16, TRANSPARENT) for i in range(4)]
        # The beholder loads its death ray
        self._loading_images = [(i * 16, 16, 16, 16, TRANSPARENT) for i in range(4)]

    def watch(self, target: Sprite):
        dx, dy = self.x - target.x, self.y - target.y
        if abs(dx) > abs(dy):
            self.angle = 1 if dx > 0 else 2
        else:
            self.angle = 3 if dy > 0 else 0

    def image(self):
        if self.state == LOADING:
            return self._loading_images[self.angle]
        else:
            return self._main_images[self.angle]


class Hero(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]

    def image(self):
        return self._images[self.angle]


class App:
    def __init__(self):
        # width, height, title
        pyxel.init(160, 120, title="The beholder watch the hero")
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        self.beholder = Beholder(128, 32)
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_DOWN):
            self.hero.move(0)
        if pyxel.btn(pyxel.KEY_LEFT):
            self.hero.move(1)
        if pyxel.btn(pyxel.KEY_RIGHT):
            self.hero.move(2)
        if pyxel.btn(pyxel.KEY_UP):
            self.hero.move(3)

        if pyxel.btn(pyxel.KEY_SPACE):
            self.beholder.state = LOADING
        else:
            self.beholder.state = WAITING
        self.beholder.watch(self.hero)

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()
        self.beholder.draw()


App()

Le beholder essaye de foudroyer le héros

Pythoneries

Pas de nouveautés Python dans cette dernière démo, il y a suffisamment de maths pour remplir les lignes de code supplémentaires.

Démo

Le héros et le monstre ont maintenant l’attribut state qui désigne (évidemment) l’état.

Les sprites du beholder sont rangés sur deux lignes:

La seconde quand il prépare son tir (il regarde en l’air)
La première pour les autres états (attente et tir).

Le héros a une colonne de plus, l’état électrocuté, qui n’a pas de direction.

Tout ça est traité par la méthode image.

Pour laisser une chance au héros, le beholder vise la position actuelle du héros, dans la méthode aim, attend un peu, le temps de charger son rayon de la mort, puis tire là où ETAIT le héros, méthode shoot.

Le rayon est instantané, mais il tire en retard. Si le héros ne s’est pas assez déplacé, il meurt.

Le départ et l’arrivée du rayon se font depuis le centre des sprites, et non depuis le coin haut gauche.

Pour savoir si le héros est touché, on ne se contente pas de son centre (touché en plein cœur ?), mais on détermine la face de son sprite qui est face au beholder. Si le rayon ne touche ne serait-ce qu’un de ses orteils, le personnage est frit.

Le rayon est interrompu par le héros, s’il le touche, sinon, il s’arrête au bord de l’écran.

Pour ne pas se perdre dans des if illisibles, un tableau de 3x3 cases est utilisé : - la ligne du milieu correspond à un tir vertical - la colonne du milieu a un tir horizontal - le centre a un tir dans son propre pied - les autres cases correspondent aux combinaisons de gauche/droite, haut/bas

C’est maintenant que débute la platrée de lignes de maths. On commence par calculer la pente du tir, puis on gère le cas où la pente est nulle, puis on vérifie si le héros est touché latéralement, ou verticalement. S’il est touché, le rayon s’arrête au point d’impact, le héros passe à l’état ZAPPED et le rayon change de couleur.

Le tir est dessiné avec la fonction line de Pyxel.

Dans le App, point de maths. Les flèches ne font plus bouger le héros quand il agonise. Au bout de 30 frames de douleur, le jeu quitte.

Le beholder cycle toutes les 40 frames, il vise à la frame 10, tire à la frame 30.

import pyxel

TRANSPARENT = 11

# Beholder states
LOADING = 0
FIRING = 1
MOVING = 2
WAITING = 3

# Hero states
HEALTHY = 0
ZAPPED = 1


class Sprite:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.speed: int
        self.angle: int  # bottom, left, right, top
        self.state: int

    def move(self, angle: int):
        # 0: don't move
        # 1: move forward
        # -1: move forward
        # angle : ↓←→↑
        self.angle = angle
        self.x += [0, -1, 1, 0][angle] * self.speed
        self.y += [1, 0, 0, -1][angle] * self.speed
        # Can't escape the screen
        if self.x < 0:
            self.x = 0
        elif self.x > pyxel.width - 16:
            self.x = pyxel.width - 16
        if self.y < 0:
            self.y = 0
        elif self.y > pyxel.height - 16:
            self.y = pyxel.height - 16

    def image(self) -> tuple[int, int, int, int, int]:
        # What is the current image
        raise NotImplementedError

    def draw(self):
        pyxel.blt(self.x, self.y, 0, *(self.image()))


class Beholder(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.angle = 1
        self.speed = 2
        self.state = WAITING
        # The beholder can be normal : waiting, aiming, moving…
        self._main_images = [(i * 16, 0, 16, 16, TRANSPARENT) for i in range(4)]
        # The beholder loads its death ray
        self._loading_images = [(i * 16, 16, 16, 16, TRANSPARENT) for i in range(4)]
        # Where the beholder aims
        self._aim_dx: int
        self._aim_dy: int

    def image(self):
        if self.state == LOADING:
            return self._loading_images[self.angle]
        else:
            return self._main_images[self.angle]

    def watch(self, target: Sprite):
        dx, dy = self.x - target.x, self.y - target.y
        if abs(dx) > abs(dy):
            self.angle = 1 if dx > 0 else 2
        else:
            self.angle = 3 if dy > 0 else 0

    def aim(self, target: Sprite):
        self.state = LOADING
        self._aim_dx, self._aim_dy = self.x - target.x, self.y - target.y

    def shoot(self, target: Sprite):
        self.state = FIRING
        # The ray starts avec self.x, self.y
        x_end: float  # horizontal end of the ray
        y_end: float  # vertical end of the ray

        # Center of the shooter
        shooter_x, shooter_y = self.x + 8, self.y + 8
        # Center of the target
        target_x, target_y = target.x + 8, target.y + 8
        # Side hit by the shot
        target_side_x = target_x + pyxel.sgn(self._aim_dx) * 8
        target_side_y = target_y + pyxel.sgn(self._aim_dy) * 8

        # Where the ray ends when it misses ?

        cross = [  # x, y
            [(pyxel.width, pyxel.height), (pyxel.width, shooter_y), (pyxel.width, 0)],
            [(shooter_x, pyxel.height), (None, None), (shooter_x, 0)],
            [(0, pyxel.height), (0, shooter_y), (0, 0)],
        ]
        x_end, y_end = cross[pyxel.sgn(self._aim_dx) + 1][pyxel.sgn(self._aim_dy) + 1]

        if x_end is None:  # It shoots its own foot
            return

        x_hit, y_hit = shooter_x, shooter_y
        if self._aim_dx != 0:
            slope = self._aim_dy / self._aim_dx
            y_end = (x_end - shooter_x) * slope + shooter_y
            y_hit = (target_side_x - shooter_x) * slope + shooter_y
            if slope != 0:
                x_end = (y_end - shooter_y) / slope + shooter_x
                x_hit = (target_side_y - shooter_y) / slope + shooter_x
        if abs(target_x - x_hit) <= 8:
            x_end, y_end = x_hit, target_side_y
            target.state = ZAPPED
        if abs(target_y - y_hit) <= 8:
            x_end, y_end = target_side_x, y_hit
            target.state = ZAPPED
        bolt_color = 10 if target.state == ZAPPED else 6
        pyxel.line(shooter_x, shooter_y, x_end, y_end, bolt_color)


class Hero(Sprite):
    def __init__(self, x, y):
        super().__init__(x, y)
        self.speed = 4
        self.angle = 2
        self._images = [(i * 16, 32, 16, 16, TRANSPARENT) for i in range(4)]
        self._zapped_images = [
            (64, 32, 16, 16, TRANSPARENT),
            (64, 32, -16, 16, TRANSPARENT),
        ]
        self.state = HEALTHY

    def image(self):
        if self.state == HEALTHY:
            return self._images[self.angle]
        elif self.state == ZAPPED:
            return self._zapped_images[pyxel.frame_count % 2]


class App:
    def __init__(self):
        # width, height, title
        pyxel.init(160, 120, title="The beholder and its beam of death")
        pyxel.load("beholder.pyxres")  # Load the assets
        self.hero = Hero(32, 104)
        self.beholder = Beholder(128, 32)
        self.game_over = 0
        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if self.hero.state == ZAPPED:  # Everything is frozen when the hero is zapped
            if self.game_over == 0:
                self.game_over = pyxel.frame_count
            else:
                if pyxel.frame_count - self.game_over == 30:
                    pyxel.quit()
        else:
            if pyxel.btn(pyxel.KEY_DOWN):
                self.hero.move(0)
            if pyxel.btn(pyxel.KEY_LEFT):
                self.hero.move(1)
            if pyxel.btn(pyxel.KEY_RIGHT):
                self.hero.move(2)
            if pyxel.btn(pyxel.KEY_UP):
                self.hero.move(3)

            self.beholder.watch(self.hero)
            if pyxel.frame_count % 40 == 10:  # Every 50 frames, the beholder aims
                self.beholder.aim(self.hero)
            if pyxel.frame_count % 40 == 30:  # 25 later, it shoots
                self.beholder.state = FIRING

    def draw(self):
        pyxel.cls(13)  # Clear screen
        self.hero.draw()
        if self.beholder.state == FIRING:
            self.beholder.shoot(self.hero)
        self.beholder.draw()
        if self.hero.state == ZAPPED:
            pyxel.text(60, 10, "GAME OVER", 7, None)


App()

Les sources de Beholder sont disponible sur Github.

Vous pouvez tester la version en ligne de Démo Beholder en ligne

La suite

Le tir tue d’un coup le héros, on pourrait utiliser un système de barre de vie qui décroit à chaque tir, ainsi qu’une barre de chargement pour la préparation du tir du beholder.

Le héros ne peut pas riposter, quelle injustice. Il faudrait des sprites avec avec une épée qui frappe (une fente avant ?), avec un temps (court) d’attente lors d’une attaque qui l’empêche de se déplacer.

Un son de HUUUUUUM lors du chargement, puis de ZAAAAP lors du tir, un GZZZZZ lors de l’électrocution me semble indispensable.

Apprendre Pyxel : gérer la souris dans son jeu

2024-12-09T18:48:00+01:00

Voici un nouveau chapitre pour apprendre le framework de création de jeux Pyxel. Oui, on dit cadriciel en français, mais cette traduction est tellement laide.

Cette nouvelle démo va être un poil plus compliqué que la soucoupe volante gérée au clavier. Pas d’inquiétudes, la marche entre les deux projets n’est pas très haute.

Bouquins pour apprendre Python

De toute façon, vous avez trouvé un bon bouquin pour apprendre Python et vous avez commencé à le lire, n’est-ce pas ?

Pour les grands, en anglais, il y a le Oreilly : Learning Python.

Il existe une traduction faite par une IA que je n’aurai absoluement envie de rire.

Pour les jeunes, il y a le No Starch, traduit à la main par Eyrolles : Python pour les kids.

Démo

Cette fois-ci, avec sa souris, le joueur va faire voler une charmante chauve-souris dans l’obscurité de sa grotte.

Pour ne pas s’embrouiller entre chauve-souris (le sprite) et souris (le pointeur), on va déclarer que c’est une pipistrelle.

Assets

Les assets contiennent deux sprites de la chauve-souris, deux images de 16 pixels posées côte à côte. La première avec les ailes en haut, la seconde avec les ailes en bas.

Si vous avez la flemme de dessiner, le plus simple est de télécharger le fichier bat.pyxres.

Code

Le code étant un poil plus compliqué que l’initiation, la chauve-souris a sa propre class : Bat.

Comme tout bon code orienté objet, Bat va gérer tout ce qui le concerne.

Une chauve-souris qui bat des ailes

L’attribut frame indique l’image courante, 0 pour les ailes en haut, 1 pour en bas.

La méthode swap_wings va inverser la position des ailes.

Dans la méthode draw on va commencer par inverser la position des ailes toutes les 10 frames, avant de dessiner son sprite. Une fois sur 10 permet d’avoir un battement lent, pas celui d’un colibri.

App est minimaliste, il prépare le jeu puis démarre la boucle, seule nouveauté, il instancie une Bat et lui envoie les évènements.

Dans la première itération du code, il n’y a pas d’interactions, App se contente de demander à l’instance de Bat de draw.

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [ # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        self.frame = 0 # 0 : bat wings are up, 1 : down

    def swap_wings(self):
        "The wings switch from up to dwon"
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite"
        if pyxel.frame_count % 10 == 0: # Every 10 frames, to wings flip
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres") # Load the assets

        self.bat = Bat(72, 72) # Spawn a new bat 🦇

        pyxel.run(self.update, self.draw) # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q): # Hit Q to quit
            pyxel.quit()

    def draw(self):
        pyxel.cls(0) # Clear screen
        self.bat.draw() # Draw the bat at its current position


App()

Le jeu se contente d’afficher une chauve-souris qui bat des ailes. La seule interaction possible est de quitter le jeu, en taper sur la touche Q, oui, c’est frustrant.

Une chauve-souris qui suit la souris quand on clique

On commence par afficher le curseur de la souris avec pyxel.mouse(True). Un clique sur le bouton de gauche (pyxel.MOUSE_BUTTON_LEFT) déplace la pipistrelle à la position du curseur.

En maintenant le bouton, il est possible de lier la position de la pipistrelle au curseur de la souris, et de la faire gigoter en secouant la souris.

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [  # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        self.frame = 0  # 0 : bat wings are up, 1 : down

    def swap_wings(self):
        "The wings switch from up to dwon"
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite"
        if pyxel.frame_count % 10 == 0:  # Every 10 frames, to wings flip
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres")  # Load the assets

        self.bat = Bat(72, 72)  # Spawn a new bat 🦇

        pyxel.mouse(True)  # Show the mouse

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.MOUSE_BUTTON_LEFT):
            self.bat.x = pyxel.mouse_x
            self.bat.y = pyxel.mouse_y
            pyxel.mouse(False)
        else:
            pyxel.mouse(True)

    def draw(self):
        pyxel.cls(0)  # Clear screen
        self.bat.draw()  # Draw the bat at its current position


App()

Le peu d’interaction est gratifiant, mais accrocher une bestiole aux mouvements de la souris reste simpliste.

Une chauve-souris qui volète vers un point désigné par un clic

Commencez par effacer le bout de code qui lie la souris à la pipistrelle.

Dans cette ambitieuse version, des maths (niveau 3°) vont être utilisées pour calculer le chemin :

distance calcule la distance entre deux points avec l’aide de notre ami Euclide.
angle calcule l’angle entre deux points, avec de la trigonométrie.

Techniquement, on passe de coordonnés cartésiens à coordonnées polaires.

Quand on clique, un chemin (un vecteur) est calculé entre la position courante de la chauve-souris et la position cible désignée par le clic.

À chaque frame, la chauve-souris avance d’un pas (sa vitesse), sur ce vecteur. Si la distance entre la chauve-souris et sa cible est inférieure au pas, elle s’arrête, ce qui permet de gérer simplement les problèmes de comptes qui ne tombent pas rond.

Pyxel utilise le coin haut gauche du sprite pour désigner sa position. Donc, sans correction, la chauve-souris stopperait quand son coin haut gauche atteint la position du clic, ce qui serait peu intuitif et même laid.

Pour les calculs de chemin et de distance, il faut utiliser la position du centre du sprite soit : x + width / 2 et y + height / 2.

import pyxel


class Bat:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.images = [  # The bat uses two images : wings up, wings down
            (0, 0, 16, 16, 0),  # x, y, width, height, transparent color
            (16, 0, 16, 16, 0),
        ]
        # self.x is the top left corner of the image,
        # computing the position of the center of the bat is more intuitive
        self.center_x = self.images[0][2] / 2
        self.center_y = self.images[0][3] / 2
        self.frame = 0  # 0 : bat wings are up, 1 : down
        self.angle = 0  # Where does the bat look ?
        self.target_x: int  # The bat goes to this target
        self.target_y: int
        self.speed = 0

    def move_to(self, x, y, speed):
        "The bat rotate and will move to the target"
        self.target_x = x
        self.target_y = y
        self.speed = speed
        self.rotate_to(x, y)

    def rotate_to(self, x, y):
        self.angle = angle(x, y, self.x + self.center_x, self.y + self.center_y)

    def one_step(self):
        "The bat moves to its target"
        if self.speed != 0:
            delta = distance(
                self.target_x,
                self.target_y,
                self.x + self.center_x,
                self.y + self.center_y,
            )
            if delta <= self.speed:
                self.speed = 0
            else:
                self.x += pyxel.sin(self.angle) * self.speed
                self.y += pyxel.cos(self.angle) * self.speed

    def swap_wings(self):
        "The wings switch from up to down"
        if self.frame == 0:
            self.frame = 1
        else:
            self.frame = 0

    def draw(self):
        "Draw the sprite"
        if pyxel.frame_count % 10 == 0:  # Every 10 frames, to wings swap
            self.swap_wings()
        pyxel.blt(self.x, self.y, 0, *(self.images[self.frame]))


def distance(x1, y1, x2, y2: float) -> float:
    "Euclidian distance"
    dx = x1 - x2
    dy = y1 - y2
    return pyxel.sqrt(dx**2 + dy**2)


def angle(x1, y1, x2, y2: int) -> float:
    "Get the angle between two points with trigonometry"
    dx = x1 - x2
    dy = y1 - y2
    return pyxel.atan2(dx, dy)


class App:
    def __init__(self):
        pyxel.init(160, 120, title="Flying bat")  # width, height, title
        pyxel.load("bat.pyxres")  # Load the assets

        self.bat = Bat(72, 72)  # Spawn a new bat 🦇

        pyxel.mouse(True)  # Show the mouse

        pyxel.run(self.update, self.draw)  # Starts Pyxel loop

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):  # Hit Q to quit
            pyxel.quit()

        if pyxel.btn(pyxel.MOUSE_BUTTON_LEFT):  # Mouse click set the target
            self.bat.move_to(pyxel.mouse_x, pyxel.mouse_y, 2)  # x, y, speed

        self.bat.one_step()  # The bat fly, one step at time

    def draw(self):
        pyxel.cls(0)  # Clear screen
        self.bat.draw()  # Draw the bat at its current position


App()

Comme le calcul du chemin et relancé à chaque clic, il est possible de faire voleter la chauve souris d’un bout à l’autre de l’écran, sans qu’elle ait le temps de s’arrêter.

Dans les vrais jeux 8 bits, avec des sprites carrés, pour savoir si deux blocs sont au même endroit, on n’utilise pas Euclide, mais on vérifie simplement si le pointeur est plus bas que le haut de la pipistrelle, et plus bas que le haut, plus à gauche de sa droite, plus à droite que sa gauche.

Vous pouvez modifier le code pour rendre hommage à la Game Boy et son processeur Sharp z80 cadencé à 4,194304 MHz, et ses 8ko de RAM. Sur une machine récente, même un Raspberry Pi, personne ne verra la différence.

Les sources de Bat sont disponible sur Github.

La suite

Prenez en main le code, pour rajouter des comportements qui vous semblent indispensables.

Un peu de random sur sa position pour rendre le vol un peu plus erratique ?

Un sprite de plus pour avoir une position statique, la tête en bas, pour qu’elle puisse se reposer ?

Un son de “flap flap” joué quand la bête vole ?

Initiation à la création de jeu rétro avec Pyxel

2024-11-24T18:04:00+01:00

Pyxel permet de créer en Python des jeux rendant hommage aux vieilles consoles, comme la Game Boy Color : de gros pixels, une palette de couleur réduite, un son minimaliste (mais sur 4 canaux).

Ce minimalisme permet de créer rapidement des jeux qui fonctionneront de manière fluide, grâce à sa bibliothèque en Rust, sur n’importe quelle brouette, et même sur une page web (avec Wasm).

Préparation

Pyxel fonctionne sur Linux, Mac et Windows.

Le développement se passe depuis le terminal, en tapant des commandes.

Éditeur de texte

Il vous faut un éditeur de texte : VSCode, Sublime Text, ou un autre qui vous plait. Ils sont disponibles en téléchargement depuis leur page web, ou via les appstores des différents OS.

Sur Mac, ce sera Homebrew avec brew install vscode.

Sur Ubuntu, ce sera avec Snap disponible depuis la barre d’outils.

Python

Vérifiez que vous avez Python dans une version décente (>= 3.10) : python3 -V

Sinon, il faut l’installer. Pour Mac, ce sera brew install python, pour Linux, ce sera sudo apt install python3-dev python3-venv python3-pip, pour Windows, ce sera via python.org.

Installation

Pyxel n’est pas une application, mais un framework Python, avec un éditeur de médias.

Donc, pour l’utiliser, il suffit d’avoir Python sur sa machine, et de créer des projets, avec leur environnement, (un venv), puis d’ajouter la bibliothèque pyxel avec l’outil pip.

Pour ne pas mettre le bazar, on va ranger le code dans un dossier.

mkdir pyxel-demo
cd pyxel-demo

Puis créer un environnement pour Python, pour pouvoir installer des bibliothèques uniquement pour ce projet et ne pas tout cochonner.

python3 -m venv .pyxel-env

Les utilisateurs de zsh et bash (les shells par défaut de Linux et OS X) vont utiliser source :

source .pyxel-env/bin/activate

Pour les transgressifs de fish, venv sait aussi gérer ce shell :

. .pyxel-env/bin/activate.fish

Sur Windows, l’activation utilise une commande différente.

Installation des bibliothèques. On commence par mettre à jour pip pour ne pas qu’il râle, puis on installe pyxel.

pip install -U pip
pip install pyxel

Exemples de projets Pyxel

pyxel copy_examples

Pyxel va télécharger son dossier d’exemple et créer le dossier pyxel_examples.

La commande pyxel run permet de lancer les démos.

pyxel run pyxel_examples/02_jump_game.py

Jump Game utilise les flèches droite/gauche pour accélérer/ralentir le personnage.

L’éditeur de médias pour Pyxel

Pyxel fournit un éditeur de médias (sprites, tilemap, sound, music).

Pyxel utilise des formats traditionnels (et même antiques).

Les images sont en PNG (la transparence est gérée). Les jeux vidéo ont l’habitude d’avoir le zéro dans le coin haut gauche. Il est possible de glisser/déposer des images PNG/GIF/JPG dans la fenêtre de l’éditeur.

Les polices de caractères (les fonts, quoi) sont en pixel et au format BDF, éditables avec FontForge.

Les maps sont au format TMX, éditables avec Tiled (plus de formats sont disponibles sur Github)

L’éditeur Pyxel crée des archives pyxres qui sont des fichiers ZIP avec un gros TOML à l’intérieur, avec les binaires gérés comme des listes d’entiers.

Le son est dans un format spécifique.

pyxel edit

Démo

Demo party !

Une fois ce premier test réussi, et quelques bidouillages pour se l’approprier, il faudra lire la doc, une longue page.

Le code est typé, mais non commenté, ce qui permet d’avoir quelques indices depuis son éditeur.

Éditeur de médias

pyxel edit initiation.pyxres &

Dessinez deux vaisseaux spatiaux, de 16 pixels de côté.

C’est votre vaisseau, vous dessinez bien ce que vous voulez, tant que vous respectez les consignes.

Le premier regarde à droite, le second, à gauche.

Par convention, la transparence est la première couleur (noir), et correspond à la valeur 0 dans le code.

Si vous galérez, vous pouvez simplement télécharger le fichier initiation.pyxres.

Code

Éditez un fichier initiation.py, puis adaptez le code d’exemple (plus bas) à vos besoins.

# Uniquement sur UNIX
touch initiation.py

Un vaisseau immobile

L’application est rangée dans une class.

Lors de la création de la class, on choisit la taille de l’écran et son titre. Les assets sont chargés.

La méthode update gère les entrées (le clavier dans ce cas).

La méthode draw va entièrement redessiner l’écran.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO static")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.ship = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

Demandez à Pyxel de surveiller votre jeu.

pyxel watch . initiation.py

Le vaisseau s’affiche au milieu du vide de l’espace, et on peut juste quitter l’application avec la touche Q.

Le vaisseau est secoué

Un peu de math, un simple cosinus, pour que le vaisseau rebondisse mollement.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO shaken")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.ship = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

        # 🛸 bumps slowly 1/16 per tick starting with y = 72
        self.player_y = pyxel.cos(pyxel.frame_count * 360 / 16) + 72

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

Le vaisseau peut avancer dans un sens ou dans l’autre

Le vaisseau peut pointer d’un côté ou de l’autre, grâce à deux sprites.

Avec les flèches, on peut avancer ou reculer de 2 pixels (sans sortir du cadre).

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO exploration")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.spaceship_r = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color
        self.spaceship_l = (16, 0, 16, 16, 0)
        self.ship = self.spaceship_r  # 🛸 looks ->

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_LEFT) or pyxel.btn(pyxel.GAMEPAD1_BUTTON_DPAD_LEFT):
            self.player_x = max(self.player_x - 2, 0)  # go ->
            self.ship = self.spaceship_l  # 🛸 looks <-
        if pyxel.btn(pyxel.KEY_RIGHT) or pyxel.btn(pyxel.GAMEPAD1_BUTTON_DPAD_RIGHT):
            self.player_x = min(self.player_x + 2, pyxel.width - 16)  # go ->
            self.ship = self.spaceship_r  # 🛸 looks ->

        # 🛸 bumps slowly 1/16 per tick starting with y = 72
        self.player_y = pyxel.cos(pyxel.frame_count * 360 / 16) + 72

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

Voilà, vous avez un sprite qui gigote et réagit aux frappes sur un clavier.

Vous pouvez tester la version web de la démo Spaceship.

Les sources de Spaceship sont sur Github.

La suite

Quelle sera la suite ? Du bruit, un décor avec des étoiles, des tirs de laser, des antagonistes ?

Introduction to retrogame programming with Pyxel

2024-11-24T18:04:00+01:00

Lobsters : mm1bss/introduction_retrogame_programming Summary: The Rust framework Pyxel has a simple Python API for building retrogames. Code your first demo! Bluesky: 3lbymgiaofs2t Thumbnail: /images/pyxel-spaceship.png Thumbnail_small: images/thumbnail/pyxel-spaceship.png Thumbnail_width: 158 Thumbnail_height: 158

Pyxel is a tribute to game consoles of the golden age, like the SNES or the Game Boy Color: large pixels, few colors, and minimalistic sounds (on 4 channels).

With such a minimalistic way, you can build games quickly, and they will run smoothly on a dog-slow computer (thanks, Rust), on every OS, even on a web page (with WASM).

Setup

Pyxel is tested on Linux, Mac, and Windows.

You have to use the terminal and type commands the geeky way.

Text editor

You have to pick a text editor, like VSCode, Sublime Text, or whatever works. You can download them from their webpage or through an app store.

On Mac, you will use Homebrew

brew install vscode

On Ubuntu, you will use Snap.

Python

Check you have a decent Python installed (>= 3.10).

python3 -V

If you don’t have Python, or an old version, you have to install a fresh version.

On Mac, you will type

brew install python

On Linux, you will type

sudo apt install python3-dev python3-venv python3-pip

On Windows, you will click-click on python.org.

Installation

Pyxel is not an application but a framework. A media editor is provided.

So, to use it, you must have Python installed, create a project with its own virtual environment (a venv), install the pyxel library with the pip tool.

Don’t be messy; put all your code in a dedicated folder.

mkdir pyxel-demo
cd pyxel-demo

Create a virtual environment in order to install libraries locally, only for this project.

python3 -m venv .pyxel-env

Main shells used by Linux and OS X are bash and zsh and use source to activate the venv:

source .pyxel-env/bin/activate

Fancy users use fish shell. The command to activate the env is handled :

. .pyxel-env/bin/activate.fish

On Windows, the activation command will be different (but similar).

Install the library. First, update pip, or it will yell, and then install pyxel.

pip install -U pip
pip install pyxel

Pyxel examples

pyxel copy_examples

Pyxel will download its own examples in the pyxel_examples folder.

Use pyxel run to start demos.

pyxel run pyxel_examples/02_jump_game.py

The Jump Game uses the right/left arrows to accelerate or decelerate the hero.

Pyxel Media Editor

Pyxel provides a media editor for sprites, tilemap, sound and music.

Pyxel handles traditional data formats.

Pictures are PNG (with transparency). Be careful, video games used to put the zero in the top left corner. You can upload a PNG/GIF/JPG file with a drag and drop in the editor window.

Fonts are pixel only and use the BDF format (you can edit them with FontForge).

Maps use the TMX format, editable with Tiled.

Pxyel editor creates a pyxres archive (a ZIP file with a fat TOML file inside).

Pyxel sounds use elderly synthetizer instructions using a specific format.

pyxel edit

Demo

Demo party !

OK, it works; you can launch and tweak the examples. Now you should read the doc.

The code uses type (yeah) without comments (woooh), so the text editor can provide a few hints.

Media editor

pyxel edit initiation.pyxres &

Draw two spaceships, 16px tall and wide.

It’s your own spaceship; draw wahtever you like, with the correct sizes.

The first spaceship looks to the right side and the second spaceship looks left.

The first color of the palette is transparent; it’s the 0 value in the code.

If you are struggling, you can cheat and download the file initiation.pyxres.

Code

Create and edit a file initiation.py, then write the example code and tweak it as you will.

# only for UNIX
touch initiation.py

A static spaceship

The application is put in a class.

In the __init__ method, you pick a screen size and its name. The assets are loaded.

The update method handles inputs (the keyboard, here).

The draw method draws the full screen.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO static")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.ship = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

Ask Pyxel to watch the source of your game.

pyxel watch . initiation.py

The spaceship is in the middle of the void of space. You can only quit the application with the Q key.

The spaceship is shaken

A little bit of match, just a cosine is used to bounce the spaceship smoothly.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO shaken")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.ship = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

        # 🛸 bumps slowly 1/16 per tick starting with y = 72
        self.player_y = pyxel.cos(pyxel.frame_count * 360 / 16) + 72

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

The spaceship can move forward or downward

The spaceship can looks frony or back, using the two sprites.

Using the arrows, you can move forward or backward, with a step of two pixels. You can’t go outside the screen.

import pyxel


class App:
    def __init__(self):
        pyxel.init(160, 120, title="UFO exploration")  # width, height, title
        pyxel.load("initiation.pyxres")
        self.player_x = 72  # 🛸 X position
        self.player_y = 72  # 🛸 Y position
        self.spaceship_r = (0, 0, 16, 16, 0)  # x, y, width, height, transparent color
        self.spaceship_l = (16, 0, 16, 16, 0)
        self.ship = self.spaceship_r  # 🛸 looks ->

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_LEFT) or pyxel.btn(pyxel.GAMEPAD1_BUTTON_DPAD_LEFT):
            self.player_x = max(self.player_x - 2, 0)  # go ->
            self.ship = self.spaceship_l  # 🛸 looks <-
        if pyxel.btn(pyxel.KEY_RIGHT) or pyxel.btn(pyxel.GAMEPAD1_BUTTON_DPAD_RIGHT):
            self.player_x = min(self.player_x + 2, pyxel.width - 16)  # go ->
            self.ship = self.spaceship_r  # 🛸 looks ->

        # 🛸 bumps slowly 1/16 per tick starting with y = 72
        self.player_y = pyxel.cos(pyxel.frame_count * 360 / 16) + 72

    def draw(self):
        pyxel.cls(0)  # clear screen with color 0

        # Draw 🛸
        pyxel.blt(self.player_x, self.player_y, 0, *self.ship)


App()

Here it is; you have a wiggling spaceship, and you can drive it with your keyboard.

Sources of Spaceship are hosted on Github.

To infinity and beyond

What’s next? Some noise, a background with stars, some laser beams, some villains?

Kernel-less : allégez drastiquement vos VMs en supprimant le kernel

2024-08-05T09:04:00+02:00

Les machines virtuelles sont fort pratiques pour utiliser efficacement les serveurs en les découpant en tranche de la bonne taille. Un partage sans trop de soucis de sécurité (la surface d’attaque est restreinte), permettant d’avoir du multitenant (différents clients, potentiellement agressifs, partagent une machine).

À cause de Moore (enfin, de la fin de sa loi), les processeurs (génériques, aka CPU) prennent du retard face aux progrès du réseau, du stockage, et l’arrivée d’unités de calculs spécialisés (GPU, NPU, TPU…).

Le noyau a la charge de gérer le matériel et d’arbitrer leur accès.

Quand le CPU pédalait plus vite que le réseau et le stockage, les latences du noyau était de différent ordre de grandeurs inférieures à celle du matériel, et donc anecdotiques. Mais avec le réseau en 100G, le NVMe, et tous plein de nouveaux jouets qui essayent de saturer le PCIe, les latences du noyau deviennent hors de prix. L’article fondateur, Attack of the Killer Microseconds, explique très bien tout ça, et j’en ai déjà parlé dans le billet tcpless.

Avec une machine virtuelle, on empile les noyaux : celui de l’hôte (qui gère effectivement le matériel), et celui de l’invité (qui fait un peu de la figuration).

Avec deux noyaux en cascade, il y a le risque de faire deux fois le travail (ou de prendre deux fois une décision sur un même point).

Grâce à virtio, le noyau invité se fait le plus discret possible, avec un accès le plus simple et le plus direct avec le matériel, parfois même sans passer par le noyau de l’hôte (en utilisant les fameux rings et du zero copy).

Le noyau invité a la charge de gérer les utilisateurs et les process dans la machine virtuelle. Avec des micromachines virtuelles, comme dans un conteneur, il n’y aura qu’un seul utilisateur, une seule application (peut être même asynchrone, sans threads).

La tentation est donc grande de continuer d’élaguer et de réduire la place du noyau dans les machines virtuelles.

On peut réduire un kernel générique au maximum, comme le propose smolbsd (avec NetBSD) ou comme le suggère Firecracker (avec Linux), mais on peut aussi faire le grand pas vers l’unikernel.

unikernel

Le concept, audacieux, d’un unikernel, est d’embarquer l’application dans un kernel minimaliste, taillé sur mesure. Une application classique a son code, ses bibliothèques, ses appels système. Dans un unikernel, tout est bibliothèque, l’application (compilé en statique) comme les appels système nécessaires, et forme un seul binaire, bootable.

Isolation

Comme l’hôte assure l’isolation de la machine virtuelle, celle-ci peut se permettre de ne rien isoler (pas d’espace mémoire, pas de process, pas d’utilisateur…), comme il n’y a qu’une seule application, elle n’a rien à craindre de quiconque.

Minimalisme

Les unikernel ciblent la virtualisation (bien que des foufous fassent booter des Raspberry Pi avec des unikernels), ce qui simplifie tout.

Pour la gestion des drivers, il suffit de mettre du virtio à tous les étages (ou du Xen).

Cette simplicité permet un temps de boot réduit (qui pousse à préférer Firecracker à Qemu, trop long à démarrer), des images légères, une consommation de mémoire moindre, et de très bonnes performances.

Quand on parle de simplicité, on est au niveau “Linux embarqué”, ces gens considèrent que musl est une grosse libc.

Toutefois, les unikernels commencent par promettre un minimalisme absolu, des APIs uniques et parfaites, puis exposent une couche de compatibilité POSIX, pour finalement lancer des applications au format elf (Le format Linux).

Multicœur

Le SMP (la gestion des multiples processeurs et cœurs) est un sujet complexe, surtout la partie coordination pour les accès exclusifs. La virtualisation peut aisément aggraver le problème : si vCPU pose un verrou sur un CPU physique et que l’hyperviseur le gèle pour le confier à une autre machine virtuelle (en cas de sur allocation), il va bloquer le verrou pour un temps imprévisible (et pourrir la gigue, jitter en VO).

Le papier How to Deal with Lock Holder Preemption explique le problème et propose une solution.

Pour un OS spécifiquement conçu pour la virtualisation (comme l’est un unikernel), il est possible de se passer de ce genre de verrou.

Système de fichiers

Autre sujet chaud, les systèmes de fichier, les unikernels détestent ça, il faut implémenter VFS, gérer les descripteurs de fichiers, puis les spécificités du système de fichiers, et paraphraser LVM si on est ambitieux.

Pour avoir un ordre de grandeur, e2fsprogs, qui permet de gérer ext[2-4] en espace utilisateur, son dossier lib contient 197 fichiers en C pour 65 426 lignes de code seul (du sloc en jargon), sans tirer de dépendance tierce (d’après le paquet Debian libext2fs2). En comparaison pour Nanos, il y a 1457 lignes pour TFS, leur FS maison et 814 lignes pour 9pfs (utilisé pour accéder à un disque de l’hôte).

Sinon, un ramfs suffit pour avoir un /tmp est le minimum pour assurer une compatibilité.

La réponse fantasmatique ultime serait que l’application parle directement le NVMe, en écrivant ses blocs, sans l’abstraction d’un système de fichier. Voici les spécifications, bon courage.

Utiliser un stockage clef/valeur peut être une abstraction plus légère qu’un système de fichier (le stockage, lui, causera aux blocs). DPDK a le blobstore et Ceph a confg-key (bien moins ambitieux que le précédant, mais ils ont aussi exploré base clef/valeur comme LevelDB) par exemple, mais l’intégration à unikernel reste théorique.

La solution raisonnable serait plutôt d’utiliser virtio-fs, qui expose un dossier de l’hôte (qui, lui, va gèrer un système de fichiers) via le protocole zero copy de virtio. Basé sur FUSE, mais avec le daemon en espace utilisateur sur l’hôte, utilisé depuis l’invité, avec les commandes FUSE qui utilisent le protocole de virtio, à base de ring et de mmap. L’unikernel Hermit, par exemple, peut utiliser du virtio-fs.

Virtio-fs est plébiscité par Kata, parfait pour du Serverless (et utilisé par AWSLambda), mais nécessite de la collaboration depuis l’hôte, chose impossible si l’on souhaite s’appuyer sur l’API VM de son Cloud préféré qui va se contenter de connecter un disque de blocs à une machine virtuelle.

Techniquement, du CephFS pourrait faire le job, mais je n’ai aucune idée du surcout pour une image (code, mémoire, processeur), et du temps de connexion. Une recherche rapide ne donne pas grand-chose : soit c’est trop novateur, soit c’est une mauvaise idée.

En attendant OSv embarque ZFS (qu’on aurait du mal à qualifier de minimaliste), Nanos a son système de fichier maison (nommé TFS) et Unikraft a la flemme.

La tradition reste la mauvaise foi en affirmant “les VMs sans état, c’est la pureté”. Cette approche radicale est tout à fait légitime, c’est un des piliers du dogme Serverless.

Temps de démarrage

Démarrer une machine virtuelle classique prends du temps : Il faut rapatrier l’image de référence sur le serveur qui va instancier la machine avec différentes stratégies : téléchargement sur le disque local, puis éventuelle création d’une instance en COW (copy on write), ou utilisation en flot depuis un disque distant depuis un SAN, avec là aussi un potentiel COW.

La taille compte, plus l’image sera de taille raisonnable, plus vite on pourra commencer à l’utiliser.

Ensuite vient la partie matérielle, que la virtualisation simplifie grandement, le BIOS/UEFI a déjà fait le travail.

Le démarrage du kernel, là aussi, la partie drivers est normalisée par la virtualisation, et enfin l’init, avec systemd, un bon gros cloud-init qui va mettre à jour des paquets, et enfin la ribambelle de services qui vont accompagner l’application métier.

Allez jeter un œil au billet de depot.dev qui bataille pour booter en 5s, sans utiliser de pool d’images qui explique comme passer d’un correct 40s pour démarrer à un excellent 5s.

Pour un temps de démarrage qui se mesure en dizaines de secondes, les VMM (gestionnaires de machines virtuelles) sont tous suffisamment rapides.

Sauf qu’en travaillant le temps de démarrage, pour du serverless par exemple, on passe à un temps en dixième de secondes avec Firecracker, comme le rappel Julia Evans qui souhaite instancier des VMs à la demande pour ses joueurs. Il y a ensuite d’autres stratégies comme le stream d’image de AWS Lambda, comme j’en avais parlé dans mon billet Flot d’images disque.

Un unikernel a tous les atouts pour démarrer super rapidement : une taille ascétique, une couche système minimaliste, et un seul service.

Tous les efforts des unikernels pour démarrer rapidement peuvent être ruinés par les autres services requis pour instancier une machine virtuelle.

Sécurité

Les unikernels vantent la sécurité de leur minimalisme et l’isolation forte de la virtualisation.

Ils ne s’arrêtent pas en si bon chemin et implémentent au mieux les fonctions de sécurité disponible sur les processeurs. Pour ensuite pinailler sur le cout en performance, et le bienfondé de cette protection dans le cadre précis d’une machine virtuelle avec un process, un utilisateur, un espace mémoire.

Certains unikernels peuvent même cibler des architectures exotiques dédiées à la sécurité, comme les enclaves Intel SGX.

Débug

Le service devient une fonction dans le noyau. Tout le rangement d’un UNIX classique avec des process et des espaces mémoire réservé, des appels systèmes saute. Quand un bug apparait, il va falloir pouvoir déterminer qui accuser, le code système, ou le code métier.

Le problème de la virtualisation, c’est que ça isole fort. Pour que l’invité puisse raconter ses soucis, il va falloir passer par un port série (aka la console) ou du réseau.

Par le réseau, on peut faire passer le débugueur gdb, et profiter de l’interactivité (ça marche même depuis un IDE).

Normalement, on commence par vérifier que son application fonctionne en local (ou dans un conteneur), hors contexte unikernel, puis on teste dans l’unikernel.

Le debug unikernel ne devrait être utilisé uniquement quand on tripote des paramètres de l’unikernel, pas pour du code métier. Ou alors, c’est qu’il y a un bug dans l’unikernel ou une de ses bibliothèques système, et qu’il faut comprendre l’incident pour faire un ticket circonstancié.

Tous les outils permettant d’envoyer la stack trace d’une erreur, comme Sentry, fonctionneront dans un unikernel.

Certains unikernels ont des options lors de la compilation pour que la fonction contenant le code métier soit emballée dans un try/catch et déclenche une action en cas de crash (comme afficher un dernier log dans la console série).

Les cas justifiant un debug en prod doivent être rare, et si ça arrive, bah ce sera pénible, comme un bug de qemu. Il reste toujours la possibilité de router une partie du trafic sur une instance qui sera outillée pour un debug dans les conditions de la prod, soit un gdb depuis l’hôte, soit, euh, l’application hors du contexte unikernel ?

Les offres serverless ne proposent pas de debug live (pas de serveur : pas de debug), ça doit juste marcher. Avec Firecracker, AWS a dû assumer tous les bugs de virtualisation, mais la machine virtuelle est utilisé sans privilège (sans root) par le client, avec une distribution Linux maison. Là, avec les unikernels, l’utilisateur va devoir assumer la partie système de la virtualisation, avec la CI pour recetter.

Observabilité

L’unikernel, par principe, méprise la notion de process et son /proc qui va avec, tout comme les syscall (et son strace).

L’analyse de traces dynamiques avec, DTrace, uprobe et ebpf ne sont évidement pas disponible, mais les unikernels peuvent proposer la notion de traces et de hooks avec des API spécifiques.

Les échantillonneurs, et leur fameux flamegraph, ne vont pas fonctionner du premier coup, car ils sont souvent un outil tiers qui va analyser un process, comme py-spy. Les profileurs sous forme de bibliothèque, eux, vont fonctionner normalement, comme pprof, dans sa version Golang ou Rust.

Globalement, tous les outils embarqués dans le code vont fonctionner dans un unikernel : les journaux, traces, métriques, tout ce que propose opentelemetry.

Pour avoir des informations en boite noire, il faudra forcément passer par l’hôte, et l’on pourra voir ce que consomme la machine virtuelle, mais guère plus. Techniquement, tout ce qui cible qemu devrait fonctionner, comme Cannoli

Unikernels monolangage

Pour pousser un cran plus loin la sécurité, certains unikernels sont dédiés à un langage rigoriste :

Erlang avec LING
OCaml avec Mirage
Haskell avec Galois ✞
Wasm avec k23
Rust Hermit

D’autres ciblent des langages plus fantaisistes

FreePascal avec Toro
Javascript avec runtime.js ✞

Cette hyperspécialisation est étrange, car un unikernel basé sur du C pourra lier n’importe quel langage compilé, ou embarquer l’interpréteur de n’importe quel langage de script. Utiliser un langage avec une forte abstraction par rapport à l’OS permet de masquer à l’utilisateur les efforts (fort couteux) de portage.

Dans l’autre sens, des unikernels spécialisés peuvent s’ouvrir à d’autres langages : Hermit, dédié au calcul haute performance (HPC), peut gérer du C/C++, Fortran, Go et discuter en OpenMP.

Pour les fans de méta, les “one ring to rule them all”, il y a Solo5, commencé comme un portage de Mirage pour KVM (depuis Xen), puis devient une abstraction imaginée comme pérenne pour utiliser différents unikernels. IRL, Solo5 fonctionne avec Mirage et IncludeOS (fan de C++). Les benchmarks ne sont pas flatteurs pour Solo5.

Unikernels généralistes

Dans les unikernels généralistes, beaucoup sont cités (et comparer), mais peu sont encore bien vivants. La short list semble être Osv, Nanos et Unikraft, mais d’autres conservent leur aura, comme Lumpin, Rump ou Solo5. Hermit est encore très jeune, mais prometteur.

Prêt pour la prod

Les unikernels étaient une fantaisie pour chercheurs qui bootent, mais ils commencent à intéresser les entreprises.

Les unikernels ne sont pas apparus ex nihilo, ils sont la suite logique des µ conteneurs, qui sont la suite des conteneurs (qui sont la suite des WAR de Java, l’hypothèse d’une parenté avec les chroots est trop banale).

Les unikernels s’insèrent facilement dans les workflows actuels, ils ne sont pas si disruptifs que ça.

Une CI/CD avec moult tests, puis de la métrologie (journaux, métriques, traces, rapports d’erreurs) sont indispensables, mais bon, comme n’importe quel service depuis au moins une décennie.

Pour l’instant, 3 usages types émergent :

Serverless
HPC (pour profiter du gain en performance)
Hébergement dense avec scale to zero (du mutu moderne, quoi)

OSv

OSv a envoyé du rêve, en proposant un unikernel vantant sa compatibilité avec les binaires Linux.

OSv documente ses choix (et citent des white papers), et a fait le choix hétérodoxe d’un système de fichier luxueux : ZFS.

Petit souci, l’entreprise derrière, Cloudius, a lâché l’hébergement cloud pour tout miser sur ScyllaDB (une base de données orientée colonnes, libre, clone de Cassandra, concurrente de DynamoDB).

Le projet est dorénavant maintenu par sa communauté, avec un rythme bien plus mou.

Unikraft remercie OSv pour les bouts de code qu’ils ont repris.

Nanos

NanoVMs affirme avec aplomb que les unikernels vont buter les conteneurs d’ici 5 ans, mais aussi qu’ils permettent de se passer de devops.

De manière très classique, leur offre SAAS, propriétaire, s’appuie sur du code plus bas niveau, libre : un kernel et un cli permettant le build et le déploiement.

Nanos est l’unikernel (sous licence Apache-2), avec sa chaine de build, ops (sous licence MIT).

En local

De gros efforts ont été fournis pour faciliter la prise en main de Nanos : la documentation est conséquente, et ops rends bien des services à toutes les étapes du projet, que ce soit le build, le run (en local) et le déploiement.

Les langages compilés sont utilisés comme avant, il suffit de produire un binaire pour Linux. La doc s’amuse à fournir des exemples exotiques (forth, haskell, pascal, crystal, ada, nim, odin…).

Pour les langages interprétés, il suffit d’utiliser un paquet disponible (une image dans un registre, quoi), pour construire son image. La doc, de nouveau, s’amuse avec des exemples exotiques, comme PHP ou Perl.

L’objectif est clairement de déployer efficacement son code métier, et non de batailler/pinailler avec les problématiques des unikernels.

Les images Nanos ciblent KVM (qemu et firecracker), mais aussi Bhyve (sur FreeBSD), Xen, Hyper-V (sur Windows), VSphere, VMware ou même Virtualbox.

Un beau travail d’intégration a été fait pour débuguer avec gdb, soit en cli (depuis la VM vers l’hôte, donc), soit intégré dans son éditeur préféré (comme VSCode).

Génération Cloud

Nanos cible les différentes offres Cloud du marché pour déployer ses images. Il cible les gros du Cloud (AWS, GCE, Azure), mais aussi les hébergeurs pour budgets serrés : Vultr, Linode, DigitalOcean, OpenStack (et donc OVH)…

Le cli, ops est capable de lister, pousser, instancier les images.

Il est possible de spécialiser ses images pour un hébergeur spécifique, pour utiliser correctement le service de machines virtuelles, avec les klibs, permettant ainsi d’émettre des métriques ou du log, ou même profiter de cloud-init pour avoir de la config au boot du service.

Ops sait manipuler les volumes distants (en utilisant les APIs de l’hébergeur), et les brancher/débrancher, même à chaud sur une instance de nanoVM.

Pour pouvoir utiliser des disques en mode bloc, Nanos a fait l’effort de créer son propre système de fichier, TFS. Un utilitaire permettant de monter les images avec FUSE est fourni, permettant de trifouiller le contenu.

TFS est un système de fichier nébuleux, en lisant les sources, on comprend qu’il est journalisé (src/fs/tlog.c), et ne possède pas les fonctionnalités ambitieuses d’un système de fichier moderne, comme le RAID, ou la création d’instantanés.

Étonnement, Nanos n’est pas super à l’aise avec Kubernetes; oui, il va fonctionner avec KubeVirt, mais il estime que ça va dégrader son niveau de sécurité.

Nanos a une approche granboutienne, il considère qu’un unikernel est une petite VM, et non un super conteneur, et qu’il doit s’intégrer dans l’écosystème des machines virtuelles, et surtout pas se compromettre avec K8s (qui lui est dans la team conteneur).

Avec cette approche, Nanos s’interdit les joies du serverless, ou alors il devra proposer un service avec un pool de serveurs bare-metal pour y arriver.

Avec son système de fichiers maison, TFS, Nanos fait un choix pragmatique pour gérer la persistance maintenant, partout, sur les offres Cloud majeures.

Sauf qu’un système de fichier est par définition terrifiant, en dessous de 10 ans d’âge, on ne le considère même pas, et ensuite, il faut assumer des pinaillages incessants sur les performances dont vont se plaindre les développeurs de bases de données, les ext4 vs XFS, les BtrFS vs ZFS.

virtio-fs en confiant la persistance à l’hôte contourne le problème, mais est-ce bien raisonnable d’exiger qu’un service HTTP gère les blocs de son disque dur alors que le reste de la gestion matérielle est abstraite par la virtualisation?

Unikraft

Unikraft a une approche plus universitaire que Nanos, ce qui permet d’avoir de chouette white papers à lire, comme Unikraft: Fast, Specialized Unikernels the Easy Way.

Le projet rassemble plusieurs universités, et bénéficie de l’aide du Google Summer Of Code. Unikraft a été adoubé par la prestigieuse fondation Linux (c’est comme le CNCF, mais en plus grand).

Dans la tradition BSD, une startup complète la partie recherche, en proposant une offre SAAS: Unikraft.io basé en Allemagne (en zone RGPD, donc, même si peu de détails apparaissent sur la matérialité de l’hébergement).

Unikraft cible pour l’instant Xen et KVM (qemu et Firecracker), pour les architectures x86_64, arm64 et arm.

Il est possible de créer des images pour des Clouds existants, fort pratiques pour faire des benchmarks, mais la documentation ne dit pas comment le faire. Rien n’est prévu pour avoir de la persistance hors virtio (pas de iscsi ni de NVMe-OF, pas de systèmes de fichiers en stock), impossible donc d’utiliser les volumes distants.

Unikraft ne croit pas à l’intégration aux offres Cloud actuelles, il souhaite repartir sur un socle simple et pour ça cible le bare metal, sans se soucier des offres existantes.

Unikraft a une relation avec les Clouds du marché opposée à celle de Nanos.

Construire une image

Unikraft a bien sûr son cli à tout faire, kraft, un gros binaire autonome, qui, en plus d’une ressemblance assumée à docker pour lancer des instances, permet de construire une image.

Pour l’instant, la seule cible est KVM (via QEMU ou Firecracker), d’autres cibles sont prévus : Xen, VMWare et Hyper-V.

La présentation d’Unikraft insiste bien sur les bienfaits de la compilation spécifique (et minimaliste), mais la documentation commence par expliquer comment créer un unikernel à partir d’un binaire Linux, en utilisant un loader comme app-elfloader.

Le plus simple est de cannibaliser une image Docker, basée sur Debian ou Alpine selon l’inspiration (ou la compatibilité avec musl plutôt que glibc). Avec du multi-FROM, on recopie le strict nécessaire d’une image officielle (pour déléguer la maintenance du binaire à un tiers de confiance), puis le build va recopier l’arborescence minimaliste. Oui, tout le travail se fait dans le Dockerfile, ce qui simplifie grandement la CI.

Le build va embarquer ce petit bout d’arborescence dans le noyau, avec un “embeded initrd” en VO, einitrds pour les intimes, qui sera exposé comme ramfs (en lecture seule) lors du démarrage de l’image.

Pour des langages compilés traditionnels, c’est un peu plus sport, il faut entrer dans le conteneur, strace le service pour découvrir ce qu’il openat, puis ldd pour connaitre les bibliothèques liées, et avec ces indices créer une image ascétique.

Le fichier Kraftfile, qui malgré son nom hommage à (Make|Docker)file ne décrit aucune actions et ne contient que de la configuration, la magie se passant soit dans des options de compilation mystique pour du natif, ou un lien vers un Dockerfile qui aura tout préparé.

Allez voir le catalogue officiel, il est rempli d’exemple, et vous pourrez juger de la lisibilité du combo Dockerfile + Kraftfile. Vous verrez aussi que la gestion des images arm n’est pas encore systématique, bien que la compilation croisée soit documentée.

Pour du C, C++, rust, vous pouvez aussi construire un vrai unikernel de puriste, dit natif : votre application devient une bibliothèque de votre noyau. Allez voir le dossier native dans le catalogue.

Bien sûr, il est possible d’activer le mode verbeux, puis, en désespoir, d’utiliser l’indispensable debug avec gdb pour comprendre pourquoi ça résiste.

Pour gérer des images dans des formats spécifiques, Unikraft fournit un module pour Packer.

Écrire des fichiers

Unikraft reconnait que les systèmes de fichiers peuvent être utiles, pour une base de données par exemple. Pour l’instant, unikraft ne gère que ramfs (pour avoir un / ou /tmp) et 9pfs, qui est un service réseau issu du mythique projet plan 9 du laboratoire Bell, dont on retrouve des petits bouts un peu partout.

Un ticket github évoque la gestion de systèmes de fichiers classique comme ext4 : ouvert en 2019, à part du rangement, il ne s’est rien passé. Cette indécision sur l’intégration d’un système de fichier dans un unikernel est légitime. Déléguer ce point à l’hôte est tellement plus simple, surtout que 9pfs (déjà disponible dans unikernel) le fait déjà, passer à virtio-fs semble logique, avec un gain en performance à la clé.

En attendant, si vous voulez profiter d’un volume distant, ce sera via l’hôte, qui devra le monter, puis le partager.

KraftCloud expose des volumes, précise qu’ils ont un système de fichier à leur création, en se gardant bien de préciser lequel. Comme tout est compilé hors de Kraftcloud, point d’arme secrète, ce devrait être du 9pfs.

Exploitation

Les fans des 12 facteurs seront rassurés

Le build est prédictif, avec le combo Dockerfile + Kraftfile, et adapté à une CI/CD
Le contrat avec l’hôte est clair : KVM ou Xen
Déploiement sans admin : presque, ça reste une image de VM, par contre, la compatibilité cloud n’est pas une priorité. L’intégration avec Packer permet au moins de gérer les différents formats d’images.
Pour le scale, on reste dans les clous : service sans états que l’on peut multiplier pour gérer la charge.
Configuration via les ENVs avec le module posix-environ.
Pour les logs, tout écrire dans STDOUT/STDERR ne va pas suffire. Cette recommandation est ringardisée par l’arrivée d’opentelemtry, votre application va devoir communiquer à un service tiers ses journaux, traces, rapports d’erreurs et diverses métriques. Le bon moment pour essayer Quickwit ?

kraft Fournis les commandes équivalents à ce que propose Docker pour le cycle de vie des machines virtuelles, et il gère même les fichiers docker-compose.yml.

Pour des architectures multi serveurs, il faudra passer par leur offre KraftCloud, ou Kubernetes.

Écosystème containerd et K8s

Unikraft fournit son propre runtime compatible OCI (Containerd ou cri-o) : runu.

En créant des images d’unikernel au format OCI, il est possible de déployer des unikernels Unikraft dans un cluster Kubernetes, et même de panacher avec des conteneurs classiques.

Il est techniquement possible d’envisager du serverless via k8s (Knative et ses amis), mais pour l’instant, c’est qemu qui est utilisable, pas Fireworks, il faut donc bien surveiller les temps de démarrage.

As A Service

Unikraft.io est une offre SAAS, Unikraft ayant fait le choix opposé de Nanos, en daubant la compatibilité historique, préférant cibler le bare metal, en gardant la main sur l’hôte et la coordination. D’après ce que laisse transparaitre la doc, Unikraft.io est basé sur Firecracker, k8s, crossplane et Prometheus.

API REST, utilisable depuis le cli en local ou une CI
Loadbalancer
Autoscale
Scale to zero
Déploiement continu (les outils sont conçus pour fonctionner depuis unne CI)
Mise à jour progressive (déploiement bleu/vert…)
Sondes Prometheus
Terraform
Déploiement de certificats, ou création à la demande avec Lets Encrypt
Volumes
Registre d’images
Gestion de docker-compose.yml

Certains services paraissent pour l’instant frustes (comme le load balancer).

Il manque des bouts :

Stockage sans fond de type S3
Load balancing interne

Par contre, Unikraft.io reprend la promesse d’élasticité du Cloud : tu payes ce que les utilisateurs utilisent, de 0 à beaucoup. Ce qui signifierait que les load balancers attendent gratuitement. C’est gentil, mais les crawlers assurent un trafic minimum constant.

Les Unikernels sont-ils universels ?

L’assonance est belle, mais la technologie commence à peine à émerger des laboratoires après une petite décennie de gestation.

On va dire que les étoiles s’alignent, ce qui permet l’émergence de cette technologie.

KVM normalise l’accès à l’hôte avec virtio, avec des services en zero copy, baissant encore le surcout de la virtualisation. Rust s’engouffre dans ce domaine, permettant l’arrivée de Firecracker, fasciné par le démarrage rapide de machines virtuelles.

Moore se fait distancer par le stockage, le réseau et les *PU : le CPU devient le boulet des architectures contemporaines, ce qui remet en avant les langages compilés, domaine qui a aussi fait des efforts pour proposer des langages mieux bordés, avec un cycle de développement plus raisonnable.

La télémétrie a fait un bon en avant (merci Grafana), tout comme la notion de CI/CD : il est maintenant normal de ne plus pouvoir corriger une prod avec un vim en ssh après une analyse rapide avec tail.

Webassembly, conçu pour pouvoir recompiler Doom et lancer dans un navigateur web, s’avère être finalement un redoutable concurrent aux unikernels, avec son bac à sable rigoureux et ses bonnes performances.

Le cloud a promis l’élasticité il y a fort longtemps, et il est possible que ce soit les unikernels qui pourront tenir cette vieille promesse.

Les machines virtuelles en cascades fonctionnent mal, pour profiter des unikernels, il faut du bare metal, et les serveurs contemporains, pour rentabiliser la place dans les datacenters, sont très souvent énormes. OVH sait rester raisonnable avec des processeurs spécifiques aux dédiés (AMD a une gamme pour ça), avec juste 12 cœurs délicats, alors qu’AWS tabasse directement avec des machines à 128 cœurs. La moindre maquette va manger 3 serveurs, pour avoir de la redondance et des élections non ambigües.

La virtualisation, que ce soit KVM ou Xen a réussi l’exploit de devenir transparent, on sait que ça existe, mais on ne l’accuse jamais de bug ou de brimer la performance. Pour les bugs, on accuse le kernel et on est confiant qu’une mise à jour corrigera, pour les performances, bah, on a la surallocation et le CPU steal comme bouc émissaire. Les unikernels n’ont pas encore ce totem d’immunité, la virtualisation, OK, c’est la même qu’une bonne VM à l’ancienne, mais le peu de code système de l’unikernel, qui va-t-on blâmer? Pas les devs Linux, ils n’y sont pour rien. Comment gérer un éventuel incident en prod?

La suite

Dans un monde parfait, la recherche de l’efficience, et donc de la densification serait un objectif, mais bon, le dédié a encore beaucoup de succès, tout comme les technologies avec un cout CPU/utilisateur désastreux.

Ce n’est pas une raison pour lâcher l’affaire, la densification avance, ne serait-ce que pour des histoires de foncier ou de puissance disponible, le minimalisme est une des pistes.

La notion d’Unikernel date des années 90, mais il a fallu la déferlante des conteneurs (et son incapacitant à faire du multitenant), puis le renouveau de la paravirtualisation (avec Firecracker) poussé le Serverless pour que des produits matures émergent enfin.

Il manque l’épreuve du feu aux Unikernel pour gagner la confiance des utilisateurs, et pour ça, il faut que des utilisateurs utilisent pour trouver les bugs les plus vicieux, et surtout polissent les workflows de compilation. Unikernel est presque prêt pour le grand public, et peut déjà servir d’arme secrète pour les aventureux.

Ma prédiction est que les unikernels vont être utilisés pour des services en interne, très denses, et sans états : comme des load balancers, des services liés à la télémétrie, du memcache.

Première interaction avec les utilisateurs : du serverless, sans stockage, sans débug, avec pour commencer des runtimes prêt-à l’emploi (python, ruby, node…), puis de l’image unikernel issu d’une CI/CD.

On peut imaginer que de gros utilisateurs veuillent faire baisser leur facture d’hébergement en profitant des gains en performance et en densité des unikernels. Comme ce qu’a permis, sans trop d’effort, les processeurs ARMs, plus efficients et aux performances stables (sans variations de fréquence pour gérer la chaleur).

Le stockage est pour l’instant un caillou dans la chaussure d’unikernel. Soit l’unikernel gère le disque distant (NVMeOF ?) et un système de fichier, soit l’hôte mount un volume distant dans un namespace partagé avec la VM et l’expose avec virtio (choix que fait Lambda avec Firecracker), soit un portage de CephFS pour déporter le souci sur Ceph.

Les API clouds pour les machines virtuelles ne sont pas entièrement adaptés aux unikernel, il manque une optimisation hyper agressive sur le temps de démarrage et une stratégie plus interventionniste sur l’hôte s’il doit gérer les systèmes de fichiers pour l’invité.

Les unikernels vont dans le sens de la simplification des architectures système, ce qui est toujours une bonne idée. Il est temps que le droit d’inventaire de la (para)virtualisation soit enfin effectué. Je trouve personnellement réjouissant de pouvoir se passer du tentaculaire systemd sans revenir à l’infâme initd, même si supprimer la notion même de kernel semble un peu excessif pour y arriver.

Small is beautiful.

Tcpless ou comment passer le cap des cartes 100Gb

2024-06-12T09:04:00+02:00

Ça plait bien, le thème du “less” en informatique.

Donc, suite au best seller diskless, le bouc émissaire du jour est TCP, et donc ça va causer tcpless.

Comme entrée en matière, je recommande le brulot It’s Time to Replace TCP in the Datacenter (publié en 2022, amendé en 2023).

L’article est plaisant, sans plus, mais il fournit des sources (ce que promet la lecture de documents touffus écrits en LaTeX, avec au moins une page de citation à la fin, sans URL).

L’auteur propose un nouveau protocole remplaçant TCP : HOMA, dont on reparlera plus tard.

Dans les arguments, il y a deux chouettes buzzwords de Google :

La taxe datacenter
L’attaque de la microseconde tueuse

L’article Profiling a warehouse-scale computer “profiler un ordinateur de la taille d’un hangar”,publié en 2015, analyse 3 ans de mesures sur les services Google, qui suit le précepte “le datacenter est l’ordinateur” (on parle de milliers de serveurs), pour découvrir qu’entre 22 et 27% du temps des CPU est utilisé par autre chose que le service métier : bloat rpc, serialisation/deserialisation, compression/décompression, chiffrage/déchiffrage, hashage, allocation mémoire, copies…

Ce surcout est nommé “la taxe datacenter”, et la réponse est de tout miser sur l’accélération matérielle (l’offloading).

L’article Attack of the Killer Microseconds se lamente de la fin de la loi de Moore, les CPU contemporains devraient être 20 fois plus performant alors que le réseau ou le stockage lui a follement progressé. Les ordinateurs ont été conçus pour gérer des millisecondes (réseau, disque dur…) avec un noyau qui a des latences en microsecondes (changement de contexte, interruptions, discussions entre threads …).

Tout allait bien jusqu’à ce que le matériel passe à la microseconde (réseau en 10G et plus, disques SSD puis NVMe…), rendant les latences du noyau agaçantes. La moindre action (pour le code de Google) étant massivement parallélisée (on parle de millier de rpcs pour une recherche), la latence du pire élément du groupe devient la latence du groupe.

Autre point évoqué dans l’article : gérer la parallélisation dans le code est une tannée. Gérer l’asynchrone avec des callbacks cochonne le code, et une simple abstraction comme des threads légers rendent le code plus concis et compréhensible. Un développeur javascript qui a vu l’arrivée de async/await pourra confirmer quel enfer sont les callbacks.

Ce point explique les choix originels de golang, et tourne le couteau dans la plaie async de Rust.

Matériel

Cartes Ethernet

On est maintenant dans l’ère du terabit Ethernet, Intel propose du 100G, NVidia du 400G (qui fait bien fructifier son rachat de Mellanox). Le 800G est spécifié, le 1.6T est en travaux. À partir de 400G, ce sera de l’agrégation (16 brins de 25G pour la première génération de 400G, 2 brins de 200G dans la dernière)

Oui, les plus gros débits consomment plus d’énergie, et il existe une norme qui s’en inquiète : EEE, Energy Efficient Ethernet. L’idée n’étant pas la sobriété, mais de densifier le datacenter qui est cappé par l’énergie disponible, plus que par le foncier.

Meta cause régulièrement de son matos, logique, car il est fondateur de Opencompute qui fournit des specs libres et travaille en collaboration avec des constructeurs.

Chez Meta, le 100G est généralisé, avec 16 planes en uplink pour un rack, toutes les machines dans un bâtiment sont accessibles en 6 sauts . Le 400G est vu (enfin, en 2021) comme spécifique à l’AI et à l’apprentissage machine.

SR-IOV

Une carte PCIe peut avoir l’option (capability) SR-IOV lui permettant de présenter à l’hôte des périphériques virtuels, avec chacun son bus et son espace mémoire, qui pourront être confié à des machines virtuelles. Azure propose ce genre de chose avec des VMs disposant d’un réseau de 25G, et l’accès au FPGA de la carte via DPDK.

Alibaba utilise ce découpage matériel pour qu’une carte réseau puisse être utilisée en espace utilisateur (avec DPDK) et par le noyau Linux, de manière classique.

Cadriciels réseaux

Netmap

netmap est un projet de l’université de Pise pour une gestion du réseau en espace utilisateur. Des outils sont fournis pour la gestion des switchs et machines virtuelles, ainsi que des papiers de recherche.

FreeBSD a intégré netmap les autres OS (Linux et Windows) sont moins enthousiastes, même si le code est fourni.

L’activité projet est très calme depuis 2019, mais il est souvent comparé à DPDK.

DPDK

DPDK, pour Data Plane Development Kit est un projet fourretout centré sur l’accélération matérielle.

Il permet de gérer des choses farfelues comme l’accélération matérielle d’expressions régulières (pour épauler un WAF ?), mais surtout les cartes réseau.

DPDK cible le SDN (Software Defined Network) et les switchs virtuels qui accompagnent si bien les machines tout aussi virtuelles. Il est pour ça une des cibles de P4, le DSL qui parle réseau.

En plus des possibles accélérations à tous les niveaux, on notera le brutal AF_PACKET qui permet d’envoyer et recevoir des paquets bruts en espace utilisateur, ainsi que AF_XDP qui fait partie de l’écosystème EBPF et XDP. EBPF et XDP permettent de router/bloquer des volumes énormes de paquets avant le noyau, mais la taille du code qui prend les décisions est limité, le routage pourra être fait vers un AF_INET (le classique réseau du noyau) ou un AF_XDP (des paquets bruts en espace utilisateur). AF pour Address Family (comme il existe un AF_UNIX).

DPDK permet la bifurcation de flot, pour répartir le flot réseau entre le noyau et l’espace utilisateur. SR-IOV permet de découper la carte en cartes virtuelles (SR-IOV présente différente adresse Mac sur ses ports Ethernet, et route en L2 le flot vers les cartes virtuelles présentées au bus PCIe), mais certaines cartes sont aussi capables de comprendre les couches suivantes du modèle OSI , et de router en fonction du VLAN, VXLAN, IP, port… que ce soit en IPv4 ou IPv6.

Une expertise “coin de nappe” permet d’affirmer que l’on parle de cartes à partir de 500$ (Metronome Chelsio par exemple).

DPDK fournit une liste des cartes réseau supportées, que vous pourrez explorer avec vos admin sys et vos acheteurs.

mTCP

mTCP a été la référence de TCP en espace utilisateur, et détail mignon, il propose d’utiliser différents projets pour gérer les cartes réseaux, et pas uniquement le maintenant incontournable DPDK.

De manière similaire, ils ont implémenté des alternatives pour la gestion de congestion.

Le projet est intouché depuis 2019.

IX

IX s’appuie sur dune pour régler les problèmes réseau de Linux.

Dune permet d’être plus que root en utilisant les fonctionnalités de virtualisation du processeur pour tripoter des trucs en ring 0, comme la gestion des interruptions.

IX se vante de faire mieux que mTCP, mais date d’avant ROCEv2 et les cartes 100G.

Le papier qui explique tout ça : IX: A Protected Dataplane Operating System for High Throughput and Low Latency.

Le choix de truander le ring 0 est d’une audace folle (dune semble être abandonnée depuis 2016).

f-stack

F-stack a été crée pour que le serveur DNS d’un hébergeur puisse survivre a un DDOS (en UDP donc).

Leur réponse est simple : transplantation de la stack IP de FreeBSD 11 en espace utilisateur.

L’accès au réseau passe par une lib asynchrone utilisant des coroutines ou un truandage pour exposer l’API POSIX avec epoll/kqeue.

C’est du réseau en espace utilisateur (basé sur DPDK), mais ça reste de l’IP traditionnelle, et donc pas du tcpless.

VPP

Vector Packet Processor se focalise sur l’optimisation de la gestion des paquets en vectorisant leur traitement. Plutôt que de travailler à la pièce, on passe à la palette. Les différents paquets sont traités par lot, pour bénéficier au maximum du cache du processeur dont le D-Cache (potentiellement au détriment du I-Cache).

VPP propose de pimper tout le modèle OSI, avec des applications extrêmement diverses (DHCP, Wiregard, V-Host pour virtio, switch virtuel, VRRP, VXLAN, QUIC) et bien sur d’utiliser les accélérations matérielles fournies par DPDK.

VPP a sa fan base, des ⭐️ et des contributeurs, mais ses sous-projets génèrent nettement moins d’enthousiasme.

TLDK propose d’implémenter la couche L4, (UDP et TCP), avec l’inévitable fork de Nginx. Pas de commit depuis 2021.
Contiv, officiellement déprécié, proposait un vSwitch par nodes K8s et le tricotage réseau des conteneurs qui allait avec.

K8s n’a pas abandonné VPP, c’est Calico qui a repris le flambeau des mains de Contiv, avec Calico-VPP.

VPP se voit comme un hub ultime du réseau en espace utilisateur, avec un système de plugin et de fallback pour atteindre l’universalisme.

Même s’il existe TLDK, VPP cible clairement l’infra réseau.

Protocoles

SRD

AWS a créé SRD, pour le calcul scientifique, j’en ai parlé dans l’article sur le diskless.

Pour résumer : nouvelle couche de transport sur IP non connecté, mais livraison garantie bien que non ordonnée, et surtout mise en avant du multipath. Leur implémentation utilise les buzzwords du moment : accélération matérielle, DMA, gestion de congestion, contournement du noyau. SRD est utilisé via libfabric pour le calcul scientifique, mais aussi pour tunneler le réseau des machines virtuelles (comme le ferait GRE, VXLAN…), en réordonnant les paquets (classique, UDP, indispensable aux VPN, a aussi besoin de réordonnement).

Snap et pony express

Google a rapidement exploité le réseau en espace utilisateur, déjà évoqué dans l’article précédant sur le diskless.

Pour résumer : snap est le service en espace utilisateur qui gère la carte réseau et du DMA, divers moteurs sont utilisés, les logiciels choisissent le moteur qu’ils veulent, selon les besoins de latence, de débit et de cout. “Pony Express” est le moteur détaillé dans l’article, qui propose un mix de messages courts et de simili RDMA, avec une gestion de congestion aux petits ognons.

HOMA

L’implémentation en espace utilisateur, utilisant DPDK est abandonnée, pour une implémentation en espace noyau, HOMA module. Le protocole est obnubilé par la notion de RPC, des petits messages avec une faible latence (10 fois moindre qu’en TCP). C’est utilisable en C++, en golang (avec go-homa), du Java est promis, et la cible est grpc (avec une promesse de thrift qui arrivera plus tard). Les switchs doivent gérer la qualité de service avec DCSP.

Le protocole est un ping pong, le client envoie un paquet DATA (avec la taille totale du message en meta donnée), le serveur valide et annonce la taille du prochain paquet avec un GRANT. Donc, le protocole fait l’impasse sur les paquets non ordonnés et à priori le multipath.

Aucune référence à RDMA, ou à de l’offloading.

Alibaba

Alibaba a fait évoluer la partie réseau de son stockage en mode bloc en plusieurs étapes.

What’s the Story in EBS Glory: Evolutions and Lessons in Building Cloud Block Store (2024)

RDMA

Pour suivre les performances des disques NVMe, Alibaba s’est orienté vers le RDMA (du RoCE, de l’Ethernet donc), qui permet du zero copy via PCIe entre le disque et la carte réseau. La copie entre le disque et la carte réseau les empêchait de saturer une carte 100G.

Après avoir bien lu les publications de Microsoft qui avait déjà déployé du RDMA à grande échelle, ils sont partis sur du DPDK+SPDK.

Le RDMA a été déployé de manière prudente, juste sur un niveau de switch au dessus des Top Of Rack pour limiter les tempêtes PFC, des racks de stockages, des racks de calcul (c’était pour leur site de vente en ligne, le ratio stockage par CPU est censé être prévisible). Le RDMA n’est activé qu’entre un serveur de calcul et un serveur de stockage, chaque famille de serveurs parle entre eux en TCP (en espace utilisateur).

Ils ont commencé avec des RNIC (du Mellanox) où la carte gère le RDMA, ce qui brime la possibilité de corriger des problèmes (comme ceux liés à PFC). Le RNIC s’est avéré pénible à l’usage, chaque constructeur implémente de manière subtilement différente les uns des autres, et un même constructeur ne fera pas les mêmes choix entre ses différentes gammes de cartes.

Le TCP a été utilisé comme fallback pour le RDMA, et l’isolation entre les deux protocoles n’a pas été sans heurts.

Pour profiter du zero-copy, un filesystem spécifique permet d’écrire directement des blocs, et de faire entre 4 et 10 fois plus d’IOPS que de l’ext4. L’article cite sur ce point Reflex (et son code d’exemple) et i10 (et son code d’exemple) qui anticipent NVMe-of en tcp (il n’était qu’en RDMA à ce moment).

Tous les détails sont dans le papier de 2021 : When Cloud Storage Meets RDMA.

Avoir un pool de stockage par routeur ressemble à l’expérience de Facebook qui était plafonné par la taille maximale d’un cluster HDFS. Facebook s’était retrouvé avec une constellation de milliers de pool de stockage par datacenter, mal balancé, avec des rééquilibrages très pénibles. Voir le papier Facebook’s Tectonic Filesystem: Efficiency from Exascale.

Je suppose que l’expérience a dû être similaire chez Alibaba.

Luna + RDMA

Le papier Deploying User-space TCP at Cloud Scale with Luna (2023)

Luna promet 3.5 fois le débit, réduction de 50% des latences par rapport au TCP du noyau Linux.

Le RDMA n’est pas utilisable pour du multi AZ, et conserver une compatibilité avec TCP est quand même bien pratique.

Les offres existantes de TCP en user space sont prometteuses (IX, mTCP, VPP) mais ont des soucis de conception : * utilisation d’un thread pour le réseau, un autre pour l’application qui engendre un surcout de communication * absence de zero-copy * accès exclusif à la carte réseau

Partant de ce constat, Luna utilise une boucle évènementielle par thread pour entrelacer la gestion du réseau et l’application, et du zero copy.

La carte réseau est partagée avec le noyau via SR-IOV, et, plus raffinée, de la bifurcation de flot (de DPDK) pour choisir pour une IP et un port qui va répondre. LUNA laisse le kernel gérait la couche Ethernet et les adresses ARP, se contentant d’aller les lire via netlink.

Gérer une pile réseau en espace utilisateur nécessite (indirectement) des processeurs gérant les hugepages (de plus de 2Mo je présume) et une partie de leur flotte ne le gérait pas (en 2017), donc utiliser du classique TCP permettait une compatibilité et un déploiement progressif.

Solar

From Luna to Solar: The Evolutions of the Compute-to-Storage Networks in Alibaba Cloud

Dont on peut trouver le PDF ici

Après 5 ans de Luna, Alibaba s’est remis sur la planche à dessin pour concevoir l’itération suivante. Ils ont aussi très vraisemblablement étudié le papier de AWS sur SRD.

En corrigeant les problèmes de réseaux avec Luna, Alibaba a pu découvrir les limites de leurs abstractions de stockage réseau, ainsi que l’importance de la rapidité pour reprendre un incident réseau (quelques millisecondes).

Solar est un protocole UDP conçu pour les besoins de stockage. Il est utilisé conjointement avec Luna, qui a un usage plus large.

L’idée de base est simple et élégante : un bloc disque est contenu dans un bloc réseau. Bloc de 4ko, comme ce qu’utilise le SSD, et donc du jumbo frame pour le réseau. Aucune conversion ou assemblage, on a tout ce qu’il faut pour du zero copy. L’arrivée des paquets n’est pas tenue d’être ordonnée (et donc de maintenir une connexion), ce qui facilite l’utilisation du multipath tant vanté par SRD.

L’utilisateur voit un disque NVMe, qui est géré par l’agent de stockage, qui sait sur quels serveurs écrire, effectuer la réplication, puis prévenir le client que le quorum est atteint.

L’agent est dans la carte d’offloading (l’équivalent du Nitro d’AWS), et il va récupérer quelques informations depuis l’hôte (QOS, chemin), pour le reste il se débrouille, il se comporte comme un disque NVMe, en PCIe, avec donc du DMA. Les cartes ALI-DPU sont des FPGA (avec l’idée de passer a de l’ASIC à un moment), mais ces cartes sont très sensibles au bit-flip (le phénomène que corrige ECC pour la RAM), et donc les calculs de CRC sont validés par le CPU (avec une astuce mathématique pour valider des lots, pas un par un).

Une partie du FPGA étant squatté par l’offloading du vswitch (le routage réseau des VMs), Solar a fait le choix du minimalisme. Choix payant, parce qu’il est possible d’envisager d’implémenter l’agent avec P4, un DSL pour le réseau, et donc d’utiliser un DPU du marché.

Histoire de pinailler, techniquement, Solar ne fait plus de RDMA, même s’il fait du DMA de chaque côté du tuyau (et du zerocopy).

QUIC

QUIC, la couche basse de HTTP/3, est un protocole équivalent à TCP, mais plus adapté à Internet et spécifiquement les réseaux mobiles. Basé sur UDP, il est supporté par les routeurs de plus ou moins mauvaise foi qui forment l’Internet.

W3tech, Mozilla et Cloudflare sont d’accord pour estimer que près de 30% du Web se fait en HTTP/3 (plus qu’en HTTP/1), et Facebook annonçaient 75% en 2020, pour ses services.

Tous les gros acteurs proposent leur implémentation :

mvfst pour Facebook
MsQuic pour Microsoft
XQUIC pour Alibaba (avec tengine son fork de Nginx pour HTTP/3)
QUICHE (celui en C++) de Google, utilisé par Envoy
QUICHE (celui en Rust) de Cloudflare. (un patch pour Nginx existe)
s2n-quic de AWS

HAproxy a sa propre implémentation (cherchez les quic_*.c dans les sources). OpenSSL n’implémente pas encore les routines requises par QUIC, mais il y a un fork pour ça : quictls. Golang a bien sûr son implémentation native, quic-go dont bénéficient Traefik et Caddy.

Tout ça est super, QUIC est le chalengeur officiel de TCP, mais, comme le rappel cUrl, QUIC et HTTP/3, est conçu pour Internet, et pas pour les datacenter. L’établissement rapide des connexions n’a pas un grand intérêt sur des réseaux à faible latence, et les algos de gestion de congestion sont maintenant disponibles pour TCP. cURL a aussi constaté que HTTP/3 était limité par le CPU, chose que l’on ne voit pas quand on est limité par le réseau.

1RMA

Google a constaté que le RDMA avait des performances fort sympathiques (latence, débit, contournement du CPU…), mais qu’il n’a jamais été conçu pour le multitenant. Ajoutons à ça les reproches favoris de Google : gestions des congestions naïves, flasher un firmware (pour corriger ou tuner) c’est relou.

Google décrit donc 1RMA, pour “one way RMA”. Leur idée est de ne pas avoir de discussions (une connexion, quoi), mais des messages initiés d’un bout ou l’autre du tuyau.

Leur concept est de virer toute la magie de la carte, qu’elle se contente de délester uniquement des éléments bien spécifiés (et qui n’évolueront pas) : DMA, réseau, chiffrage et signature.

Ce qui donne leur liste en 5 points :

1 - Pas de connexion. C’est à l’applicatif de séquencer s’il en a besoin, pas au protocole. La plupart des messages seront indépendants. Avec un engagement de latence faible, il est possible d’enchainer des questions/réponses, plutôt que d’utiliser des trains de paquets comme le fait TCP.

2 - Petits paquets. 4ko, comme pour un disque dur. L’idée est donc d’envoyer 3,125 millions de paquets par seconde, sur une carte 100G. Avec un découpage fin, on peut garantir des latences, gérer de la qualité de service, pour obtenir un bon débit, il suffira d’user de violence.

3 - Contrôle de congestion logiciel. Ce n’est pas au switch de bricoler. La carte va fournir des mesures fines pour connaitre le temps de trajet sur le réseau, hors des fils d’attente, ce qui permet d’estimer la saturation. Ce système permet de partager le trafic avec des échanges non 1RMA, et de gérer des ralentissements en 25µs.

4 - Allocation des ressources définies par le logiciel. Avec des petits paquets et en imposant des délais (timeout) très courts, il est possible de gérer le débit au maximum, de garantir des latences faibles et une gestion contenue des incidents. En maitrisant le flot de paquets, il est possible d’appliquer des priorités métiers, sans bouchons.

5 - Sécurité par défaut. Tous les échanges sont chiffrés et signés par la carte, les petits paquets permettent de gérer la rotation de clés sans passer par le classique “erreur, la clé a changé, recommences”.

Dans leurs tests, le 1RMA consomme 1/2 cœur et utilise à plein une carte 100G.

Tous les détails et graphiques sont dans leur papier de 2020 : 1RMA: Re-envisioning Remote Memory Access for Multi-tenant Datacenters

Swift

Google dans son article de 2020 Swift: Delay is Simple and Effective for Congestion Control in the Datacenter décret son algo de gestion de congestion Swift, successeur de Timely (le papier de 2015 TIMELY: RTT-based Congestion Control for the Datacenter).

En préambule, il rappelle que pour désagréger le stockage, il faut des latences de 100µs pour du disque Flash, et 10µs pour du NVMe (et 10ms pour un seek sur un disque à plateaux).

L’article met un peu de temps à l’avouer, Swift est utilisé pour du 1RMA sur du Pony express, dans Snap. Ce n’est qu’un détail, l’algorithme reprend ce qui se fait avec TCP.

Comme DCTCP leur a fait des grumeaux en millisecondes, ils en disent pis que pendre.

Le concept, simple, est d’adapter le débit aux délais de la connexion. “Pas plus haut que le bord” comme on dit.

L’algo est basé sur AIMD “ajout additif, retrait multiplicatif” en traduction charabia, “croissance linéaire, décroissance exponentielle” en meilleur français. L’un des attraits de cet algo est que si chacun des flots calcule son débit avec, on aboutit à une stabilité de l’ensemble.

Swift ne veut pas dépendre du switch, ni pour les informations (rejet de paquets ou message ECN), ni pour des obligations de paramétrages (seuil ECN), en se gardant la possibilité d’un déploiement progressif (remplacement progressif de switch 10G par des 100G).

Swift considère que les délais de commutations des switch sur une route sont fixes, et dépendent du nombre de sauts. Swift, en connaissant la cible, connait la route, le nombre de switch à parcourir, et donc le délai.

Pour connaitre le délai de carte à carte, Swift va utiliser l’horodatage de la carte (après la queue Tx depuis la source, avant la queue Rx sur la cible), puis le temps de traitement. Les informations nécessaires seront transmises dans un entête du ACK (qui part sans attente, lui). Pour rappel, l’article parle de 1RMA comme protocole, qui est un protocole avec des messages à “sens unique” : un message envoyé, un ACK en retour (ou un timeout).

Swift prévoit des connexions sans états, mais conserve une notion de flot, le débit entre la source et la cible, pour calculer une “fenêtre de congestion”, et utiliser la plus petite des deux (entre la source et la cible).

Swift va collaborer avec le QOS d’autres protocoles classiques, et n’a pas besoin d’exclusivité sur la connexion (ou la carte réseau).

Les usages de Swift sont divers, ils peuvent être limités par :

le débit (disques distants)
la latence (base clé/valeur)
les IOPS (système de fichiers distants)

Conclusion

Les gains en performance du réseau (et du stockage) sont en complet décalage avec les gains en performance des CPUs, obligés par la fin de Moore à multiplier ses cœurs.

Brancher des cartes 100G au cul de vos serveurs ne va pas suffire. Pour profiter des performances monstrueuses du matériel moderne, il faut délester le CPU, et mettre le doigt dans l’explosion cambrienne des offres d’offloading en choisissant une abstraction pérenne (DPDK, P4, SPDK…) pour ne pas se verrouiller avec un constructeur.

Le DMA et le zero-copy ont le vent en poupe.

Le noyau Linux (et ses interruptions) n’est pas à l’aise pour gérer efficacement ce nouveau palier de performance matérielle, mais il avance vers la communication non bloquante (avec les ring), et propose des points d’entrée pour mixer espace noyau et espace utilisateur de manière efficace. La virtualisation va dans le même sens, et permet d’exposer des API classiques (dans les machines virtuelles) alors que l’hôte utilise des API modernistes.

L’article prétend traiter du tcpless, parce que le nom est porteur.

Mais avant de s’attaquer aux protocoles alternatifs, la première étape est d’utiliser l’offloading fourni par la carte réseau, puis les outils réseaux en espace utilisateur. DPDK for the win.

Il n’y a pas de nouveaux protocoles réseau libres pour les datacenters (RoCE peut-être?) mais sortir de TCP parait être l’étape indispensable pour la désagrégation.

Passer d’une pile IP en espace noyau, avec les API POSIX a une pile IP en espace utilisateur avec une API éxotique doit être justifié par un vrai gain. Passer par virtio a au moins le mérite d’être transparent pour l’application.

Tester les gestionnaires de congestions modernes (dctcp, bbr v3) et voir ce que ça change au niveau des latences et des pertes de paquets a le bon gout d’être bien moins intrusif.

Écrire son petit protocole réseau à soi est une tache dantesque, sans compter qu’ensuite il faut le maintenir et gérer les potentiels (inévitables ?) incidents. Puis patcher Ceph.

J’aurais peut-être dû nommer l’article “l’ère du post-CPU”.

Diskless, le stockage sans disque

2024-05-29T09:04:00+02:00

Diskless

“Less is more” comme disent les inventeurs de buzzwords.

Diskless, sans disques, est une optimisation (radicale) pour gérer un ensemble de serveurs (réels, virtualisés, ou même des conteneurs).

Désagrégation

Un serveur, c’est un ensemble processeur (CPU/GPU) / mémoire / stockage avec du réseau. Les utilisateurs, rien que pour embêter l’hébergeur, ne vont pas vouloir un ratio fixe entre ces ressources matérielles, et même vouloir changer d’avis.

La désagrégation propose d’exploser ses ressources, et de composer un serveur, en piochant dans son pool de ressources.

Spoiler alert, même avec les performances monstrueuses que peuvent atteindre les cartes réseau modernes, on ne peut pas encore généraliser la mémoire désagrégée, même si la norme CXL existe, et des gens s’amusent avec. Mais si c’est techniquement faisable, il n’y a pas d’abstractions magiques et universelles. Les machines multiprocesseurs ont encore des histoires de NUMA, et il est toujours pertinent de profiter de la localité des données et des différents caches. Des abstractions de plus haut niveau ont déjà prouvé leur pertinence, comme Open-MPI, qui évite de lier du code métier à du matériel exotique.

Externaliser le stockage des ordinateurs existe depuis très longtemps, ajouter des boites reliées par des câbles faisant partit des plaisirs simples de l’informaticien.

Débit de disques

Les branchements ont d’abord était cul à cul, puis chainés, switchés, pour enfin utiliser du réseau comme tout le monde.

Les grosses cartes réseaux proposent maintenant de faire plus que du réseau, et mettent à disposition des processeurs ARMs ou du FPGA. On parle de SmartNIC, ou de NPU. Classiquement, la carte propose d’effectuer le chiffrage, les checksums, ou de filer un coup de main pour la virtualisation réseau (comme vSwitch), de prendre en charge le XDP. DPDK propose d’unifier toute cette magie gravée dans le silicium.

Un réseau “normal” est en 10G, sachant que le 100G existe, et que l’on peut agréger les liens pour additionner les bandes passantes.

Vous pouvez mettre ce genre de monstre, 128 * 100Gb, soit 12,8Tb en 4RU comme top of rack, mais bon courage pour connecter les racks avec une bande passante suffisante.

Il est compliqué de comparer les technologies, le débit n’est qu’une des métriques (il peut être symétrique ou asymétrique), les IOPS changent complètement entre les disques à plateaux et SSD, les latences changent d’ordres de grandeur selon les technologies.

Le SATA est encore utilisé pour du stockage massif (comme le propose Backblaze).

L’USB4 intègre Thunderbolt, mais il n’est pas conçu pour les datacenter, il est possible de relier des baies de disques en SAS (en cuivre ou en fibre optique), pour former un gros SAN.

le CXL se base sur PCIe 5.0 et 6.0, mais cible la RAM, pas le stockage.

Samsung arrive à saturer (de peu) les 63G du PCIe 4.0 en x4 avec son SSD PM1735 et donc utilise du x8.

La Pmem (mémoire persistante), est connectée comme une barrette de RAM, en RDIMM. Les performances sont comparables à du PCIe 6.0 en x16. Le chiffre est pour comparer avec les autres technologies, l’intérêt de la Pmem est sa latence, et la proximité avec le cache du processeur.

Technologie	Débit
SATA 3	4.8Gbit/s
HDD 16To lecture séquentielle	2 Gbit/s
SAS-5	45Gbit/s
USB4 Gen 3x2	40Gbit/s
USB4 gen 4	80Gbit/s
fibre channel gen 7	64Gbit/s
fibre channel gen 8	128Gbit/s
Infiniband NDR	106Gbit/s
PCIe 4.0 x4	63Gbit/s
PCIe 4.0 x8	126Gbit/s
PCIe 6.0 x16	968Gbit/s
Pmem	1000Gbit/s

C’est rare que le matériel soit utilisé en 1 seul exemplaire, les benchs SPDK sont faits sur un serveur avec 2 processeurs de 28 cœurs, 14 disques SSD, 4 cartes réseau de 100Gbits, pour un résultat maximal de 330Gbit/s (sur 400 théoriques). Un serveur de stockage à haute densité, c’est 70 disques.

Disque réseau

Un tas de disques utilisé via du réseau par un tas de serveurs s’appelle un SAN, Storage Area Network, et à pendant longtemps nécessité du matériel spécifique (et cher).

Protocoles

iSCSI

L’un des vénérables protocoles de disque dur, SCSI (première version en 1986 quand même), avec ses gros câbles qui changeaient du tout au tout à chaque nouvelle version majeure, a eu droit à son passage au réseau, avec iSCSI, au début des années 2000.

Fibre Channel (fibre et non fiber, pour faire chic) permet (entre autres) de faire passer des commandes SCSI sur un réseau switché (plusieurs ordinateurs peuvent se connecter à plusieurs disques). Fibre channel est luxueux, il nécessite du matériel et des compétences spécifiques.

L’idée du iSCSI est simple, faire passer les messages SCSI en TCP/IP, et permettre ainsi de contrôler des lecteurs de bandes, de changer des cassettes, des CD-ROMs, et aussi des disques durs, sur un réseau classique.

40 ans de SCSI, 20 ans de iSCSI, sa réputation n’est plus à faire, même si les disques SCSI n’ont pas passé l’an 2000 (remplacés par le SAS) avant la déferlante SSD.

NBD

NBD est un protocole vintage, 1997, mais simple, qui permet d’exposer des blocs en TCP/IP. Datant de l’époque des disques à plateaux, il ne propose pas de parallélisation, chose que font très bien les SSDs.

NBD a gagné le statut de format “presque standard” pour exposer des blocs.

go-nbd est fort pratique pour bricoler du bloc avec golang, et je vous recommande ma démo stream-my-root.

QEMU l’utilise pour exposer ses images QCOW2 avec qemu-nbd.

Autre fan de QCOW2, libguestfs propose un projet enthousiaste, nbdkit pour gérer un protocole placide.

Ceph RBD

Ceph se positionne comme la solution ultime et universelle du stockage réseau : il gère les 3 modèles : blocs, fichiers, blobs. Il est rétrocompatible avec l’existant: système de fichiers UNIX, iSCSI, NFS, S3, et avec ses propres protocoles.

Ceph est le service bloc standard des gens qui n’ont pas de SAN iSCSI (Digital Ocean, OVH, Scaleway … Hetzner ?).

NVMeOF

Les premiers SSD avaient une interface SATA, pour faire la transition avec les disques à plateaux, et ont rapidement saturé les performances de ce bus. Le NVMe est un SSD qui utilise directement du PCIe, de manière non bloquante, tous les cœurs d’un CPU peuvent discuter avec le disque. Le NVMe est apparu sous forme de grosses cartes PCIe, puis finalement dans des formats plus pratiques, comme du M.2 pour le grand publique, et du U.2 ou U.3 pour les serveurs (en conservant les racks utilisés par SATA et SAS, et la connexion à chaud).

NVMeOF, comme NVMe Over Fabric, reprend l’astuce du iSCSI et fait passer les messages NVMe prévus pour du PCIe sur du réseau qui lui aussi utilise du PCIe. Le PCIe utilisé par NVMe et le réseau permettent des optimisations redoutables, comme le RDMA, Remote Direct Memory Access, la carte réseau peut exposer un disque NVMe distant, sans passer par le processeur. La communication de carte à carte pouvant être faite en Fibre Channel, Infiniband, ou tout simplement en Ethernet (avec ROCE RDMA Over Converged Ethernet).

NVMeOF peut aussi être géré de manière logicielle (pouvant profiter de l’accélération matérielle de la carte réseau), côté client ou serveur, sous l’égide du projet SPDK, qui centralise tous les efforts NVMe pour Linux.

Du MVMeOF logiciel ne dépend pas de NVMe et peut donc partager un gros disque SATA ou même un disque dynamique.

SPDK a fait de chouettes benchmarks, qui mettent bien en valeur le gain en latence de RDMA face à TCP : 6 fois mieux.

Les blocs du noyau Linux

Le noyau Linux fournit les briques de base pour gérer des disques, que ce soit en espace noyau ou utilisateur, avec sa fascination pour le rangement et le dédoublonnage.

bdev

bdev est la couche de base pour écrire un pilote pour exposer des blocs.

io_uring

Le noyau Linux a galéré pour proposer une API asynchrone pour la gestion du stockage.

Libuv, grand unificateur des API asynchrones, se contente d’un pool de threads pour gérer les accès disques

Il y a eu la tentative AIO, mais sans API équivalente pour les sockets, ça rend les interactions compliquées.

io_uring permet une communication non bloquante avec le stockage avec d’excellente performance.

En juin 2023, Google a constaté que pour l’année 2022, 60% des failles Linux soumises à son bug bounty étaient liées à io_uring, du coup bannissement massif dans l’écosystème Google, suivi par Docker qui en a entrainé d’autres comme Bun.

On attend le retour en grâce du très prometteur io_uring.

ublk

ublk permet aux kernels d’exposer des blocks, en espace utilisateur. Ublk utilise io_uring pour un échange sans interruption entre les espaces noyau et utilisateur. C’est une bonne nouvelle pour les performances, mais il y a eu de grosses failles de sécurité avec io_uring, ce qui lui a valu un bannissement (temporaire) de Google et Docker. Il faut donc attendre la bénédiction d’un acteur majeur avant de pouvoir profiter de cette prometteuse technologie.

ublksrv est le cadriciel en espace utilisateur (le framework en usersapce) pour ublk.

Ublksrv permet par exemple de monter des images QCOW2, et il sera possible de faire du NBD (avec du zero-copy entre le block et le réseau).

Ublk est aux blocs ce que FUSE est aux fichiers.

TCMU

TCM permet de créer une cible SCSI (un serveur) dans le noyau Linux. TCMU est un TCM Utilisateur, et permet donc à une application de se comporter comme un disque SCSI.

FUSE expose des fichiers, ublk des blocs, TCMU une cible SCSI.

TCMU a été utilisé avant l’arrivée de ublk ou vhost-user.

Device mapper

Device Mapper permet de composer sa gestion de blocs en empilant des fonctionnalités plus ou moins exotiques (compression, chiffrage, cache, raid, instantanés, COW …) et même du débug (mesure de performances, ajout de latences…). Device Mapper sert de base à LVM, Logical Volume Manager.

vfio

vfio permet d’exposer en espace utilisateur le DMA d’un périphérique, emballé dans un IOMMU. Le périphérique exposé par VFIO peut être confié à une application, ou même un conteneur.

vDPA

vDPA/VDUSE comme “virtio data path acceleration” et “VDPA Device in USEr space” est une norme pour avoir des drivers en espace utilisateurs qui bénéficient des spécificités d’un drivers (accélérations et délestent proposés par une carte réseau futée (smart NIC/DPU), ou du DMA bordé par un IOMMU). L’idée de conserver l’isolation fournie par une machine virtuelle ou un conteneur, mais de bénéficier des spécificités d’un matériel, sans émulation ou paraphrases. VDUSE permet d’utiliser un périphérique virtio dans le kernel hôte, et de le confier à un conteneur. vDPA permet a QEMU d’utiliser un matériel spécifique, on parle alors de “fast path”, et si l’on souhaite migrer la machine virtuelle sur un hôte sans l’accélération matérielle, il basculera en émulation, on parle de “slow path” (et ça va commencer à ramer sévèrement).

les Virtios de KVM

Virtio normalise (à la hache) des drivers minimalistes pour que les OS invités utilisent des pilotes simple et minimaliste, et quand c’est possible du “passage direct” entre l’invité et l’hôte (du pass through, quoi).

Virtio est utilisé par les différentes solutions de virtualisation basées sur KVM, mais aussi par Xen.

virtio-scsi et virtio-blk

virtio-scsi permet d’exposer du bloc comme un disque SCSI, c’est standard pour l’invité, mais ça tire la longue histoire de SCSI.

virtio-blk se contente d’exposer du bloc.

Par défaut, côté hôte, les services sont statiques et exposent des images disques.

Pour fournir dynamiquement une image disque, il est possible de faire des bricolages honteux, en servant l’image disque via un montage FUSE, comme dans l’article AWS sur le streaming de disque pour firecracker.

vhost-user

vhost-user est le protocole officiel pour exposer un service en espace utilisateur, à un virtio, coté invité. vhost-user utilise un anneau pour discuter sans interruption entre l’hôte et l’invité, de manière comparable à ce qu’utilise io_uring.

vhost-user peut être utilisé pour discuter avec tous les virtio (comme le vhost-device de rust-vmm), mais aussi virtio-blk, et il existe diverses implémentations de backends (comme le documente Firecracker)

Qemu backend : qemu-storage-daemon
Cloud Hypervisor backend
crosvm backend (la VM de ChromeOS, l’un des fondateurs de rust-vmm)
SPDK backend

Libblkio

libblkio est une bibliothèque rust qui se focalise sur son API C, et propose de brancher tout vers tout : io_uring, NVMe, virtio-blk (vhost-user ou même vhost-vdpa et vfio-pci).

Les blocs du Cloud

Toutes les offres Cloud proposent des disques réseau tellement pratiques à l’usage.

Les gros du cloud ont des outils maison, la plupart des autres utilisent Ceph, sans forcément le préciser, alors que Digital Ocean en profite pour faire de la pub sur le bouquin de leur Mr Ceph

Cinder

Openstack souhaite normaliser le Cloud, ce qui est une idée sympathique, il propose une API normalisée et tous les fabricants de matériel fournisse un pilote.

Cinder est le service de blocs d’Openstack.

Il propose une quantité invraisemblable de pilotes, avec pas mal de SANs, et les grands classiques open sources.

Amazon EBS

AWS aime bien rester nébuleux dans ses pages produits, mais il donne des indices sur son stockage bloc io2, et d’autres infos techniques dans cette présentation re:Invent de 2012 (il faut zapper les présentations produits pour se concentrer sur le techos).

NVMeOF
Le réseau (IP) de stockage est isolé du réseau classique
Pas de TCP, mais du SRD, qui utilise du multipath
4Gbps par volume
Accélération matérielle avec la carte Nitro

Google Cloud Hyperdisk

De manière prévisible, Google donne peu d’informations techniques sur son Hyperdisks, l’OS invité lui cause en SCSI (le virtio-scsi ?) ou en NVMe (du NVMeOF exposé par leur carte SmartNIC gvNIC ?)

Le débit maximum de 24 Gbit/s (avec 5 disques) est assez énorme.

Hyperdisk est fier de découpler les IOPS et bande passante du nombre de CPU, le ratio fixe par CPU est classique pour la RAM ou le disque local, mais là, hyperdisk désagrège le stockage, et l’on peut réserver (IOPS, bande passante) selon un planning, pour ne pas avoir à surdimensionner pour uniquement encaisser les pics d’utilisations.

Azure Elastic SAN

Azure se contente de vendre des tranches de SAN, avec une bande passante par To de stockage. Le partage se fait en iSCSI sur un réseau privé.

Les blocs de l’open source

Les SANs sont hors de prix, les formats sont normalisés, ça fait deux raisons d’avoir des implémentations libres de serveurs de disques en mode blocs.

Open-ISCSI

La RFC3720 est un poil aride, ça utilise de vieux protocoles (comme SLP ou RADIUS), il faut du matériel exotique pour tester la partie RDMA, il n’y a donc pas un enthousiasme fou pour implémenter iSCSI, c’est donc open-isci qui s’y colle, accompagné de tgt pour la partie en espace utilisateur et son daemon.

SPDK

Storage Performance Development Kit est, entre autres, le roi du NVMeOF. Il cause aussi le iSCSI, le vhost (pour virtio), le ublk (pour Linux en espace utilisateur), le CSI de k8s et d’autres trucs exotiques, mais surtout, il a un daemon, spdk_tgt pour configurer tout vers tout, qui discute en JSON-RPC 2.

SPDK met à dispositions des fonctions de plus niveau, comme la gestion des volumes et la création d’instantanés.

SPDK utilisé des modules qui permettent d’ajouter des fonctionnalités comme le “copy on read and write” du bdev_ubi d’Ubicloud, qui permet de cloner une image de base et de l’utiliser tout de suite (attention à la licence non libre)

SPDK est souvent le backend caché derrière des applications de plus haut niveau.

Ceph

Ceph a comme couche basse RADOS (Reliable Autnonomous Distributed Object Store), au-dessus duquel vont être construits des services (utilisant librados pour la plupart) comme RBD ou le NVMeOF de SPDK, et en dessous, il y a des “stores”.

Filestore, des fichiers sur du XFS, maintenant déprécié.
BlueStore), du bloc cru (raw block), capable d’utiliser du HDD et de profiter du SSD (et pmem) pour les métadonnées et les journaux.
Seastore, prochainement, du full NVMe avec SPDK pour avoir une gestion fine du TRIM et proposer du zero copy (avec l’aide de DPDK, pour peu que l’on ait une carte réseau avec du DMA)
Des travaux sont effectués pour gérer les disques zonés (comme les HDD SMR).

Ceph propose des fonctions avancées comme la création d’instantanés et le COW.

Ceph sait parler le Kubernetes avec ceph-sci.

Débuté lors d’une thèse, le projet a intéressé des scientifiques générant beaucoup de données (Los Almos, le CERN…) avant d’être rachetés par Red Hat, qui a créé une fondation avec d’autres participants de prestige. Suse a d’abord collaboré avant de bouder et mettre en avant son Longhorn.

Sheepdog

Feu Sheepdog était une solution de stockage de blocs distribués, qui s’appuyait sur corosync et Zookeeper. La passerelle iSCSI était assurée par le même tgt utilisé par Open-iSCSI.

Le projet est SUPER STABLE depuis 7 ans. Son fork, sheepdog-ng, est dans le même état.

DRBD / Linstor

Distributed Replicated Block Device est un module de bloc répliqué distant pour le noyau Linux. On écrit sur un bloc local, le noyau réplique (en TCP ou RDMA) l’écriture sur un bloc distant, en synchrone dans le scénario recommandé.

DRDB est une des briques de bases de HA Linux, et permet d’avoir un serveur de secours disponible en cas de défaillance du serveur principal.

Le répliqua n’est pas accessible en lecture, ce qui empêche la répartition de charge en lecture.

Les gens audacieux peuvent utiliser DRBD en multiprimaire, pour peu qu’ils utilisent un système de fichier adapté (comme les exotiques GFS et OCFS2).

Linstor expose un volume DRBD dans différents protocoles (iSCSI via tgt et NVMeOF via SPDK), en assumant la haute disponibilité. Linstor fournit les drivers de haut niveau comme Cinder pour OpenStack ou CIS pour k8s.

OpenEBS

OpenEBS a un logo moche, mais il a plus d’étoiles Github que Longhorn.

OpenEBS est issu de la libération de Mayastor.

Mayastor est maintenant le service utilisé par un agent CIS pour que k8s puisse utiliser des volumes persistants. Mayastor est stateless et cause à différentes sources de blocs, dont l’agent SPDK ou LVM. Mayastor est utilisable par des microconteneurs (Firecracker, Kata), via vhost-user (et donc virtio), et même hors de l’écosystème k8s (pour faciliter le débogage et les migrations).

Longhorn

Longhorn est le service CIS de Rancher.

Rancher se positionne comme le vulgarisateur de Kubernetes et fournit des projets réputés, comme k3s la plus petite des distributions k8s, ou Elemental qui crée des images Linux immutables à partir de fichier Dockerfile.

Rancher est maintenant racheté par Suse.

Dissection de longues cornes

Longhorn, dans sa version actuelle, expose les blocs en iSCSI, via un fork de tgt qui ajoute son propre backstore bs_longhorn, qui se contente de faire le passe-plat, en confiant toutes les commandes lire/écrire/effacer à un service en go, qui lui détient tout le code métier : la réplication, la création d’instantanées, la détection d’incidents et les réparations, comme le détail la documentation secrète.

Le hack de tgtd (repris de Sheepdog), est audacieux, tout comme utiliser un service en golang (avec son ramasse-miette) pour gérer de faibles latences. Autre temps, autres mœurs, en 2016, il n’y avait pas ublk ou même SPDK. Il y a eu une version utilisant TCMU, l’ancêtre de ublk.

Les images disques sont de simples fichiers troués (sparse file), et Longhorn utilise ses sparse-tools, pour ne pas s’embêter avec les trous lors de la création d’instantané, recopie et consolidation. Pour ça, ils s’appuient sur les file extent mapping du noyau Linux (fiemap étant le successeur de fbmap qui lui ne voir que des blocs). Pour bénéficier de fiemap, il faut utiliser un système de fichiers gérant les extents, et pour créer des instantanés, fsfreeze sera utilisé, ce qui ne laisse que XFS et ext4 comme système de fichier utilisable.

La version 2 du moteur de données de Longhorn s’appuie sur SPDK et NVMeOF. Une grosse partie des fonctionnalités sont maintenant assumées par SPDK (accès distant, réplication, instantanés…).

Les gains en performance sont clairs, pas énormément sur la bande passante, mais clairement sur les IOPS et les latences, et la différence est plus flagrante avec un meilleur débit réseau.

La documentation insiste sur ce point : il faut dédier un cœur à spdk_tgt pour ne pas avoir de fluctuations de performance (jitter).

Au-delà de Longhorn : Harvester

Harverster s’appuie sur LongHorn (et Rancher) pour proposer un service d’infrastructure hyperconvergente (un Proxmox like, quoi).

C’est intéressant de voir une architecture du nouveau monde Kubernetes proposer de la gestion de machines virtuelles (l’ancien monde, donc), auquel on pourra ajouter des conteneurs.

Au-delà des blocs réseau

Un volume réseau est une réponse universelle qui permettra de faire comme avant, sans rien changer, et vous proposera des choses bien pratiques, comme les instantanés, l’agrandissement déraisonnable, ou la déconnexion depuis une machine virtuelle pour se reconnecter vers une autre machine.

Un volume bloc ne sera accessible que depuis un seul client, ou alors il faut mettre les doigts dans gfs2 ou ocfs2. Globalement, un système de fichier distribué aura un comportement différent (et décevant), que ce soit en mode bloc ou fichier.

Réseau

TCP

Le drame de TCP est son ossification, son incapacité à évoluer.

TCP doit faire un compromis sur la taille des paquets, soit des gros pour le débit, soit des petits pour la latence, et il y a encore des drames avec le TCP_NODELAY pour éviter d’attendre 200ms pour tenter de remplir une trame et limiter le surcout des entêtes.

le reproche principal de TCP est son contrôle de congestion qui attend la perte de paquets pour prévenir la source que le tuyau est saturé.

ECN

La RFC3168 propose d’anticiper l’arrivée d’une congestion, et de ne pas arriver à l’étape fatidique de la destruction de paquet. Pour ça, un champ de l’entête IP, ECN (2 bits), pour Explicit Congestion Notification, est utilisé pour indiquer que la file d’attente a atteint un seuil, et que si ça continue comme ça, il va couper.

Les deux bits ECN sont dans l’octet TOS, qui a eu d’autres usages, et quand on envoie une trame TCP, on ne sait pas si le switch gère l’ECN. S’il le gère, le switch va flipper un des bits, l’autre servant d’annonce de congestion.

Donc, pour bénéficier d’ECN, il faut que les switchs sur le trajet le gèrent, et par exemple, chez AWS, c’est niet.

DCTCP

Le noyau Linux utilise des modules pour le contrôle de congestion, et dctcp (comme DataCenter TCP) utilisé ECN pour anticiper les congestions.

Il y a une RFC, donc Bortzmeyer en parle : 8257

MPTCP

MPTCP propose d’ajouter le multi path à TCP, sans casser Internet, sans modifier les applications.

Même Bortzmeyer dit du bien de la RFC 6182, et explique divers points.

Fort pratique pour les connexions mobiles (4G + Wifi), il peut avoir sa place dans un datacenter, pour profiter de la redondance du réseau. Déjà déployé dans les téléphones, Linux commence à avoir l’outillage nécessaire pour faire correctement du mptcp avec un démon en userspace, mptcpd pour configurer finement le comportement. Les outils se concentrent sur les usages mobiles, ciblant HTTP et SSH, et je n’ai pas vu grand-chose ressemblant aux stratégies ECMP de SRD.

C’est sage de partir sur une technologie compatible avec l’existant, mais je suis curieux de voir comment ça va évoluer dans des réseaux policés comme ceux des datacenters.

Je miserai sur les proxys HTTP, comme premiers déploiements en prod, si votre HAproxy gère mptcp, c’est gagné (il y a d’ailleurs une PR pour mptcp). Golang le gère depuis la 1.21 ça devrait débarquer dans Traefik rapidement (aucune occurrence dans le code, pour l’instant).

En interne, en garantissant l’ordre des paquets, on va subir la latence du pire chemin, même si on peut profiter d’un meilleur débit.

J’ai du mal à voir le bénéfice par rapport à un client qui se connecte directement à une des instances d’une application distribuée, sans passer par un proxy. Pour de l’HTTP, c’est rigolo à coder, je l’ai fait avec le projet Medusa.

BBR v3

Google dit que pendre sur TCP, qui est “ossifié”, et si son QUIC est une alternative efficace, il n’est pertinent que pour l’Internet public, plein de bruit et de fureur.

Plus universel, Google revient à la charge et propose sa troisième itération de BBR, son algorithme de contrôle de congestion. Comme tout le monde, il méprise la perte de paquet comme indicateur de congestion et se concentre sur le classique algorithme AIMD et les informations de délais et ECN. Comme DCTCP, quoi. Google bosse sur le sujet depuis des années, et l’a utilisé chez Youtube, mais surtout pour ses connexions entre datacenter.

Il fournit un module pour le noyau, mais aussi un patch pour ip et ss.

Le statut est “test élargi”, du bêta, quoi.

Hystart++

Microsoft bosse aussi sur le contrôle de congestion, et il a spécifié son Hystart++. Cloudflare a fait une implémentation de Hystart++ pour QUIC dans Quiche.

Pour Linux, le hystart sans ++, la version précédente, est intégré comme paramétrage pour le contrôleur CUBIC.

RoCE

La norme ROCE souhaite normaliser le RDMA en mettant de l’Infiniband dans de l’Ethernet, et donc se passer des couteux câbles et switch Infiniband, pour du classique Ethernet (classique, on parle quand même de carte 10G et la plupart du temps de fibre optique).

La version 1, assez naïve, ne fonctionne que dans un même sous réseau, non routable.

RoCE v2 est un véritable protocole Internet, utilisant UDP, routable, mais utilise ECN pour notifier les congestions. Voilà, de l’UDP avec ECN,conçu pour TCP, mais utilisé dans IP, la couche en dessous, du bon gros recyclage. Visiblement, pas tous les switchs le gèrent.

RoCE va envoyer des messages sur le réseau, dans son monde, on parle de “verbe”, mais surtout va envoyer de gros blocs de mémoire de RAM à RAM, sans passer par le CPU, comme le permet le PCIe, du RDMA (Remote Direct Memory Access) et pour ça, il faut une carte réseau qui sache le faire.

SRD

AWS a voulu proposer du réseau en 100G pour son offre de calcul scientifique (HPC). Le monde du HPC est habitué au matériel exotique, et utilise des abstractions aux dessus des couches réseaux, comme Open-MPI comme couche haute, et libfabric comme couche basse.

AWS dit qu’ECN n’est pas adapté à un réseau aussi étendu qu’un datacenter AWS, et donc qu’il est impossible d’utiliser du RoCE v2. Les menaces sont terribles : “Risque de verrou de la mort, épanchement de congestion et blocage en tête de ligne”.

De toute façon, AWS croit très fort au multipath, plutôt que de se contenter d’une route pour se connecter à un serveur, autant utiliser toutes les routes possibles.

Donc, AWS crée SRD, Scalable Reliable Datagram, proche de ce que propose Infiniband (suffisamment pour créer un module libfabric), qui en plus du multipath, ne s’engage pas à livrer les paquets de manières ordonnées.

Le tri des paquets est confié à la couche applicative, qui a à sa disposition bien plus de mémoire qu’une carte réseau, et qui saura prendre des décisions métiers. Le multipath risque d’utiliser des routes plus rapides que d’autres, augmentant les chances de mélanger l’ordre d’arrivée des paquets. Attendre l’arrivée d’un paquet lent va stopper le flot, et péter le débit.

Le classique ECMP est utilisé sur les switchs, mais en lui donnant des indices, et un contrôle de congestion maison est utilisé.

Le réseau est partagé avec les autres, qui se contentent d’une seule route, eux, et pour éviter les tant redoutés de congestions, SRD utilise les RTT pour estimer l’encombrement des routes et s’y adapte. SRD utilise les SmartNICs maison d’AWS, les cartes Nitro, et profite de l’abstraction du pilote EFA pour diverses optimisations comme les accès sans interruption (un ring je présume), du zero copy avec DMA.

L’article est agréable à lire, et les chiffres du monde HPC réveillent en nous le plaisir des gros V8 qui ronronne alors qu’on fait ses trajets en bus diésel.

Mais ça, c’était avant, la dernière itération d’EBS, utilise io2 qui utilise du SRD, et donc les blocs disques utilisent du multipath. La carte Nitro est cité, je présume qu’il y a du NVMe en RDMA (et un gros buffer pour ordonner les paquets).

Snap et Pony express

Google a constaté que développer (et déployer) du code en espace noyau était 4 fois lent qu’en espace utilisateur. Une interruption de 100ms plutôt que de redémarrer la machine, on comprend bien la différence de confort.

Google a choisi une approche maximaliste et utilise snap, un service en espace utilisateur, qui a l’exclusivité sur la carte réseau (une smart NIC qui gère du DMA, Intel est cité), avec un utilisateur non privilégié, mono threadé. Techniquement, c’est un microkernel. Le flot est multipléxé (comme HTTP/2 et QUIC), avec une seule connexion entre deux machines, il gère la congestion à sa sauce. Le document précise juste que ce n’est pas du TCP, ni de l’UDP, on peut supposer que la couche IP est conservée pour avoir du routage. La doc parle de négocier le protocole de transport d’un service, via une connexion TCP, vu que Snap a des mises à jour hebdomadaires, tout le monde ne parle pas la même version. Diverses stratégies sont possibles, mais il est possible de lui dédié un cœur (les processeurs modernes en ont plein), le service consommera donc 100% du CPU, et sera entièrement responsable de la latence, personne (et surtout pas le kernel) n’étant là pour le gêner.

snap utilise plusieurs modules, avec différentes stratégies fournissant diverses performances (latences, débits) et cout. Le débit par cœur est triplé par rapport à TCP/IP, et les latences en dessous des 10µs.

snap est utilisé pour le réseau des VMs, le peering Internet, et pour le trafic à faible latence au sein d’un datacenter, il y a pony express, qui a divers usages dont la recherche internet et le stockage.

Colossus

Colossus est la technologie de stockage interne de Google, mais aussi la couche basse utilisée par le stockage pour les machines virtuelles, et divers services de stockage (comme Bigtable ou Spanner).

Snap se vante de gérer le stockage, et donc Colossus.

Un énorme pool de stockage utilisant un mix de disque à plateaux et SSD, une gestion pointilleuse du cache (avec CacheSack) et la notion de données chaude (trop de répliqua) puis froide. Chaque client exige des performances, de la redondance, qui peuvent être très variées. Pour maitriser les latences, il n’y a pas de proxy, les échanges se font de point à point, par le chemin le plus court, même le cache est tiré depuis le stockage de référence (le dataplane indiquera alors d’utiliser le cache, plutôt qu’un disque précis).

Bases de données distribuées

Un service complexe de stockage comme une base de données va solliciter fortement le stockage : le log binaire pour pas perdre de données, les données elle-même, avec des réécritures pour bien ranger, la mise à jour des index, ce genre de choses.

Si la réplication a lieu au niveau des blocs, l’amplification d’écriture va être entièrement répliquée, et de manière bloquante. Les bases de données savent (toutes ?) maintenant gérer la réplication au niveau applicatif, en utilisant le flot d’évènements (souvent un WAL), et des quorums pour les réplications, ce qui permet de ne pas attendre les retardataires (outliers), la consolidation se faisant plus tard, en asynchrone.

Aurora a uniformisé ce principe avec Aurora, sur lequel ils utilisent plusieurs bases de données open source (Mysql, Postgresql). Leur article “Conception et considérations pour une base de données relationnelle à haut débit née dans le Nuage et bien plus intéressante que leur infâme page produit. Il ne faut pas oublier que la persistance n’est qu’un des soucis que va gérer une base de données relationnelles, la gestion des transactions en est un autre, et pour ce sujet l’article dédié est “Sur l’évitement du consensus distribué sur les changements dans les entrées/sorties, les transactions et les adhésions”.

Google publie lui aussi des informations sur F1 et Spanner qui s’appuie sur Colossus.

En open source, Neon propose un moteur de persistance pour Postgres, et donc une base de données serverless (?! du dbless ?!).

Plus rigolo, Ceph propose libcephsqlite, un sqlite avec uniquement le stockage distribué, pour un client solitaire.

Dans le même genre, il y a litefs, et litevfs, du sqlite répliqué, avec un bon gros verrou pour arriver à y écrire.

Il existe des bases de données simplissimes qui se concentre surtout sur du clef/valeur (à la rocksdb) et se concentre surtout sur la distribution et la réplication :

tikv, du CNCF, propose un système de transactions et sert de socle à TiDB
foundationDB, d’Apple, avec des transactions ACID, des clés ordonnées, des notifications de modification, des opérations atomiques.
Hive, de Scaleway, crée pour coordonner leur stockage S3 et peut être un jour remplacer etcd.
Scylladb, un clone de Cassandra, une base orientée colonnes, avec des données typées, un langage de requêtes avec des fonctions utilisateurs. C’est le plus haut niveau de la liste.

On notera que, perfidement, les offres de disques réseaux hautes performances des offres Cloud ciblent les bases de données propriétaires (SQL Server, SAP…), pour contourner les couts de licences (par CPU) ou les surcouts pour le clustering.

Stockage orienté blob

S3 a démontré qu’il savait gérer brutalement une partie des besoins de stockage.

S3 est souvent utilisé en complément à du bloc, pour les sauvegardes par exemple, ou plus récemment comme stockage de flot, pour conserver les flots de réplication.

Ses débits ne sont pas forcément suffisants, on retrouve alors des solutions en pair à pair, soit du bittorrent pour le vaste monde, soit des variations avec des participants de confiance. Déployer des applications et des images de conteneurs font partie des usages violents, mais aussi des données comme des LLM (Large Language Model) pour l’IA ou des données scientifiques, comme des génomes.

DAOS

DAOS reprends les travaux d’openfabrics qui veut désagréger les machines de calcul avec du matériel de rêve (Cray, CXL, RDMA, SCM …).

DAOS propose d’entasser des disques NVMe dans un cluster (on parle de centaines ou de milliers de nœuds), puis d’utiliser tous les moyens possibles pour les saturer : zero copy, RDMA, pmem, accelerations matérielles…

Les modèles de données classiques du calcul scientifique sont exposés (HDF5, Hadoop, MPI-IO, fichiers POSIX…) pour une utilisation simple avec du code existant.

Des primitives sont fournies pour gérer les accès concurrents, avec différents modèles d’organisation des données. L’idée est d’avoir du code métier simple, avec “des applications avec un bon comportement” permettant d’utiliser un “mode relâché”. DAOS est prêt à tout, comme contourner les appels trop lents de FUSE avec LD_PRELOAD.

Pour le mode bloc, l’incontournable NVMeOF (de SPDK) est utilisé, avec une procédure pour qu’un nœud le monte en RW, écrit, démonte, puis le volume est monté en RO par plusieurs nœuds.

DAOS est un monstre, mais c’est toujours intéressant de voir quels sont les choix pris pour des volumes et des performances extrêmes, et surtout comment fournir des APIs simples et intuitives pour des utilisateurs spécifiques.

La fin de Moore

La taille des disques durs, et les cartes réseau n’ont pas atteint leur plafond, et continue de progresser, alors que la fréquence des CPU est plafonnée.

Le DMA doit permettre de décharger une partie du travail des CPU, mais peut poser des problèmes de sécurité dans des environnements multitenants (comme les environnements virtualisés).

Évolution des abstractions

Le noyau et ses interruptions sont souvent blâmés pour ajouter des latences et empêcher d’utiliser à plein le matériel.

L’espace noyau n’est plus une chasse gardée, le noyau a besoin de déléguer une partie de ses tâches en espace utilisateurs.

Beaucoup de travail est fait dans ce sens pour le kernel Linux, mais il faut du temps pour stabiliser et surtout avoir une sécurité décente (coucou io_uring), puis attendre que ça apparaisse upstream, dans les distributions.

La virtualisation est généralisée, et le domaine est bouillonnant : rust dépoussière kvm, les conteneurs rendent tentant les µconteneurs, et même les unikernels reviennent avec Unikraft. Virtio permet de concentrer les efforts pour que kvm puissent profiter au mieux, de manière la plus transparente, des nouveautés du noyau.

Le bloc de stockage est une abstraction naïve, les stockages ont leur spécificité :

les seeks des HDD (de pis en pis avec l’augmentation des tailles)
l’asymétrie des modifications des SSD et son trim
le stockage zoné pour prolonger la densification des stockages.
Le RAID a un palier, bon courage pour restaurer votre HDD de 16To.

dm-zoned, ZoneFS F2FS propose des réponses pour le zonage et le trim. Pour le seek, la réponse sera applicative (on écrit pour avoir des réponses séquentielles), et les caches SSD devant un stockage plus lent, dm-cache, bcache, sont imparfaits, le LRU n’aime pas les SSD, et sans indices il est possible de remplacer l’intégralité d’un cache pour des données qui ne seront finalement pas utilisées.

Stateless is the new diskless

Le confort de déployer des services sans états est immense. Ils peuvent facilement être multipliés, déplacés, mis à jour sans crainte de perdre des données.

Pour profiter de cette pureté (pureté promise par le développement fonctionnel), il faut arriver à ranger proprement la gestion de la persistance, en utilisant l’abstraction adéquate.

Flot d’images disque

2024-04-23T09:04:00+02:00

AWS aime beaucoup les armes secrètes (et son monopole) : c’est bon pour son image, et ça la différencie des autres offres Cloud. Mais de temps en temps, AWS libère du code (pour mutualiser les efforts, pas pour faire plaisir à Stallman) et explique des points précis de son architecture.

L’article On-demand Container Loading in AWS Lambda, détail comment ils ont optimisé le temps de téléchargement des images disques utilisées dans leur offre serverless.

Contexte : le monde du Function As A Service

Le FAAS est proche du serverless, et je suis un fan de jargon technicocommercial préfixé en less, le flou et la polémique vont forcément accompagner ce nouveau barbarisme.

Le FAAS permet d’exposer une fonction comme service dans un cloud. Aucun détail d’implémentation ou même d’exécution ne doit perturber l’utilisateur de FAAS.

Le serverless est un poil au-dessous du FAAS, il abstrait totalement la partie exécution du service, en gérant le nombre d’instances, de zéros à suffisamment, avec une facturation à l’usage.

AWS Lambda

La page Wikipédia d’AWS Lambda donne une explication synthétique (avec l’historique des évolutions), qui évite de lire la page officielle et sa tempête d’acronymes en 3 lettres.

Techniquement, une fonction serverless est un bout de code qui sera démarré, puis qui ira dépiler une file d’attente en HTTP en causant JSON. Le protocole est masqué par les bibliothèques fournies, mais pour les curieux (et les langages compilés), il y a de la documentation et un exemple en shell. On est plus proche de Celery que de Django.

La plupart des utilisateurs se contenteront d’écrire leur bout de code métier : une fonction qui prend un JSON et un contexte en entrée, et qui en sortie produira une réponse serialisable en JSON. On range le nécessaire dans une archive zip, et hop, on téléverse.

Les lambdas ont été imaginés comme le liant entre différents services d’une offre Cloud, pour réagir à des évènements. Permettant ainsi à l’utilisateur de brancher son code DANS la machine, pas juste de consommer du service, avec le très classique protocole client-serveur.

Exposer des fonctions lambdas comme API HTTP n’est qu’un des différents usages des lambdas.

Les lambdas sont volatils et démarrés en quantité fluctuante, la persistance devra être assurée par un autre service, capable d’encaisser les pics d’utilisation (comme un pool de connexion pour une base de données relationnelles, ou des services conçus pour la violence comme S3, DynamoDB ou Scylladb).

Les lambdas sont facturés à la milliseconde, alors que les machines virtuelles sont facturées à la seconde). Oui, c’est un coup de comm, cette granularité est bien trop fine, mais ça insiste sur l’importance de la latence pour un lambda.

De l’autre côté du miroir

Vu du côté hébergement, en intégrant la notion de file d’attente, AWS se laisse la possibilité de lancer plein d’instances si le cluster n’est pas chargé (et se vanter de la faible latence), ou laisser s’allonger les files d’attente en attendant que ça se calme. Si le temps de démarrage du lambda est raisonnable, le cout devrait être comparable.

Lambda masque la notion d’image conteneur (par ce qu’au début, il n’en utilisait pas), mais expose quand même la notion de couches des images conteneurs, en permettant de composer une fonction avec une liste ordonnée d’archives Zip.

L’environnement d’exécution des lambdas est massivement multitenant, l’isolation des conteneurs (namespace, cgroup, seccomp, apparmor/SELinux) n’est pas suffisante pour un milieu aussi agressif, il faut donc des micromachines virtuelles. AWS s’est tourné vers les travaux de ChromeOS pour utiliser kvm (le module kernel), mais sans QEMU. Ils se sont mis d’accord pour partager rust-vmm, qui sert de base pour Firecracker, et pour les VMs spécifiques de ChromeOS.

Firecracker peut mettre en pause une VM (comparable au cgroup freezer), ce qui libère le processeur, mais pas la mémoire, permettant d’entasser des fonctions prédémarrées (Provisioned Concurrency en jargon AWS), fort pratique pour gérer des évènements synchrones peu fréquents, mais réactifs.

Firecracker pourra congeler (developer preview pour l’instant) une VM (en pause) et écrire son état (l’état de la VM et le contenu de la RAM).

Il est possible de rebrancher le réseau et l’entropie d’une fonction congelés, avant de la relancer (unpause en VO). Il est donc possible de décongeler une fonction autre part, plusieurs fois, et ainsi obtenir des clones. Criu promet la même chose depuis longtemps pour les conteneurs (ou les simples process). Le pool de fonctions “pret-à-porter” ne consommera pas de RAM, et pourra être centralisé. Curieux de connaitre la différence entre le temps de démarrage à froid et un téléchargement de l’état suivi d’une décongélation, j’imagine qu’un python qui tire de grosses bibliothèques sera plus apte à la décongélation qu’un langage compilé.

Serverless libre

Il n’y a pas encore de réponse évidente, mais tout tourne autour de Kurbernetes avec des évènements spécifiés par le CNCF, avec cloudevents. Tous considèrent que les fonctions sont exposées en HTTP, et qu’une passerelle gèrera les évènements issus d’une file d’attente, le contraire de Lambda.

Tous ces FAAS sont déployables sur un K8s maison ou infogéré, garantissant ainsi une portabilité (multi-cloud en jargon).

Knative se positionne comme standard de fait, poussé par Google, IBM et Redhat.

OpenFunction propose une approche de plus haut niveau, proposant d’utiliser Knative ou des alternatives (toujours basé sur k8s) comme Keda (l’autoscaler poussé par Azure), Dapr (comme Distributed Application Runtime, un sidecar comparable à Istio en plus ambitieux).

Fission propose une approche simple et de bon gout, avec juste Istio comme fantaisie. Leurs efforts se portent sur le démarrage à froid, avec un pool de conteneurs déjà prêt. À vérifier si le pod est en pause pour libérer du CPU. Le principal contributeur de Fission est InfraCloud, une grosse boite indienne, avec des bureaux en Allemagne, Pays-Bas et États-Unis, et un gros fan du CNCF.

OpenFAAS a exploré les alternatives à K8s, pour finalement ne faire plus que du k8s, le tout sous une licence bancale. Il est compliqué pour une simple société de financer ce genre de projet libre, Knative est financé par des gens qui ont d’autres (énormes) sources de revenus, et leur but est de péter (chatouiller) le monopole d’AWS (et de vendre de la VM ou du consulting).

K8s va tirer les runtimes alternatifs, dont les micro VMs comme Kata qui lui va pouvoir tirer les fils de KVM : QEMU, Cloud-Hypervisor et Firecracker (qui lui sait directement causer le containerd).

De l’autre côté du miroir

Les alternatives libres n’ont pas la volonté (ou même la possibilité) d’imposer un framework qui va emballer la définition de la fonction, d’où le choix standard de n’exposer que des services HTTP. Depuis l’époque de la création de Lambda, l’utilisation des CI/CD s’est généralisé, le build des images est moins bourrins, BuildX et ses amis dispensent le développeur d’une partie du tuning de build. Le distroless et les builds en composant les couches des images reprennent les empilements de Zip de Lambda. Une partie de la simplicité de déploiement de Lambda fait maintenant partie des workflows standards de conteneurs.

L’approche tout HTTP permet d’exposer une API simple, qui sera utilisée de manière synchrone (directement appelé par l’utilisateur en HTTP) ou asynchrone (toujours en HTTP, mais via un dépileur interne connecté à un fil d’attente).

En asynchrone, le scaler (contrôle de débit?) se contente d’effectuer des requêtes HTTP et de regarder ce que raconte Prometheus ou le cgroup du conteneur (la consommation de la fonction) pour estimer le bon débit d’évènement pour qu’une instance soit utilisée entièrement, avant de créer de nouvelles instances.

Les offres libres évoquent différentes files d’attente, comme Redis STREAM, Kafa ou NATS.

Décorticage de l’article sur le démarrage au fil de l’eau

L’article est écrit par des gens de chez AWS, lié au projet Lambda. Il faut donc s’attendre à de l’enthousiasme, et à une validation par leur équipe communication/secret industriel. Venant d’AWS, il faut aussi s’attendre à des échelles titanesques (démarrage en pic de 15k conteneurs par seconde, par exemple), que peu d’entreprises approcheront.

Je suis bien content pour eux de leurs chouettes gains en performance, mais c’est plutôt leur choix technique (et les choix écartés), ainsi que leurs erreurs qui m’intéressent.

Images

L’OCI a normalisé le format des images de conteneur : une collection d’archives tar que l’on désarchive les unes sur les autres, avec une convention de nom pour effacer (et non pas écraser) un fichier.

Même si les images OCI ont été imaginées pour des conteneurs classiques (namespace et ses amis), elles sont utilisables par des machines virtuelles, pour peu que l’on ajoute divers fichiers (comme un kernel et un init).

Le conteneur (classique ou micro VM) n’a pas besoin de lire l’intégralité de son disque pour démarrer le service. D’après les mesures de Lambda, en moyenne, seuls 6% sont nécessaire pour démarrer.

Les conteneurs travaillent au niveau des fichiers, avec un assemblage virtuel, via overlayfs, même si la piste des blocs a été explorée (avec devicemapper).

Des essais ont été faits avec un chargement paresseux (lazy loading en VO), fichier par fichier, par les projets Slacker et Startlight.

Lambda, pour des raisons de sécurité, souhaite utiliser une VM minimaliste, sans drivers autre que virtio, sans actions complexes en kernel space, ou même en root.

Le tricotage du disque doit donc se faire coté hôte, qui sera exposé à l’invité (la machine virtuelle) via un virtio.

Le débit de création de fonctions est raisonnable, même poussé, testé systématiquement depuis une CI (à chaque git push, donc), l’utilisateur s’attend à un temps raisonnable de cuisson (baking en VO).

Il est donc pertinent de préparer les fonctions (et leur image) lors de leur création, pour optimiser au maximum leur temps de démarrage à froid.

Exposer une image dans un conteneur en µVM

Dans l’article, les indices sont tenus : une image en ext4 découpé en tranche, du FUSE, et enfin virtio-blk pour communiquer avec la machine virtuelle.

À la fin de l’article, les auteurs s’excusent du bricolage qui fait deux sauts périlleux dans le kernel, pour finalement (après l’article) se passer de FUSE.

Pour leur version 1, vraisemblablement, leur agent expose avec FUSE un volume avec un seul fichier RAW, qui est confié à la VM via virtio-blk, et depuis la VM, on voit un bloc, qui est montée en ext4.

nbdfuse fait ce genre de chose, en utilisant FUSE pour exposer une image disque dynamique (connecté à un serveur NBD dans ce cas), tout en disant que c’est une mauvaise idée de monter cette image.

It is tempting (and possible) to loop mount the file. However this will be very slow and may sometimes deadlock.

Nbdfuse fait partie de libguestfs, et dit qu’il est possible de lancer un QEMU avec l’image dans FUSE, même si c’est mieux d’utiliser QEMU avec nbd:// . Bref, nbdfuse a un petit souci de confiance en lui.

Lambda est plus enthousiaste sur les performances d’un passage par FUSE, même si ils ont abandonné cette approche.

Les buzzwords utilisés dans l’article indiquent que la version 2 utilise vhost-user, la nouvelle approche de virtio pour communiquer, sans interruption systèmes, sans copie (et si tout se passe bien, sans passer par le processeur si le matériel le permet).

La communication est établie avec une Vsock, ensuite les messages sont partagés dans un mmap synchronisé par un ring. Attention de ne pas confondre avec io_uring qui fait ce genre de chose entre user-space et kernel-space, avec de bonnes performances, mais pour l’instant des soucis de sécurité.

La communication zero copy sera utilisée dans plusieurs virtio, et il y a du code rust bas niveau pour vhost user backend (le frontend étant dans l’invité) et une partie des virtio à la sauce vhost-user est disponible.

vhost-user est conçu pour repousser très loin les performances des IO, en se branchant sur les ambitieux projets SPDK (Storage Performance Development Kit) et DPDK) (Data Plane Development Kit), conçues pour profiter des accélérations matérielles et l’univers RDMA : SmartNIC, NVMeOF…

vhost-user permet d’avoir une API universelle, rappelons que le but de virtio est de limiter drastiquement le nombre de drivers dans l’OS invité, même si la quête de performances, avec des blocs rangés dans un S3, sera bien loin des latences d’un disque NVMe.

POC

Pour mettre les mains dans le moteur, et comprendre l’article, j’ai décidé d’écrire un POC en golang, oui, l’article vante Rust, et tous les outils modernes liés à kvm et virtio ne jurent que par Rust et le zero-copy.

Mais c’est un POC, réalisé par une équipe de 1, pour comprendre comment s’architecture cette abstraction de disque avec dans la boucle des téléchargements depuis un S3 et du cache distant.

Mon interrogation porte surtout sur l’utilisation d’images disques dédoublonnées, en mode bloc, alors que Containerd (Docker et K8s) ne jure que par les tar et overlayfs. Il est même possible d’indexer des tar pour faire des seek dans l’archive, pour y lire un fichier précis (comme le propose le vénérable tarindexer).

Golang permet d’avoir rapidement du code lisible, des performances décentes, et de l’asynchrone qui fonctionne, ce que ne permet pas (plus?) du python ou du nodejs.

NBD

Pour pouvoir exposer ces blocs dynamiques dans un Linux, l’abstraction sera donc NBD, comme le fait qemu-nbd pour exposer une image qcow2.

go-nbd utilise une interface simplissime : on lit et écrit des listes de bytes à une position précise, le ReadAt/WriteAt de la bibliothèque io de Golang. Le code métier va donc se contenter d’implémenter une interface sans dépendre de la bibliothèque, il est ainsi théoriquement possible de brancher un autre protocole pour exposer des blocs.

Le code de la maquette est dans le projet stream-my-root.

git clone https://github.com/athoune/stream-my-root.git
cd stream-my-root
make submodule

Blocs

Peu convaincu par les tactiques de chargement paresseux de fichiers, Lambda décide de partir sur du bloc.

Pour chaque image OCI, on crée une image disque, en ext4, et on y désarchive les tar réclamés dans le manifest.

L’image est découpée en blocs de 512Ko appelés chunks. Les chunks vides ne sont pas conservés.

Chaque chunk est nommé à partir de son hachage, un SHA256.

Un nouveau manifest est créé, listant les chunks et leur position.

Pour avoir de la mutualisation de chunks équivalent à la mutualisation de layers des images OCI, il faut que la création d’images disque et les écritures soient déterministes, ce que ne font pas les outils ext4 classiques. L’écosystème ext4 n’est pas énorme (et sa homepage est restée dans son jus : e2fsprog), mais il existe quelques pépites.

Android, il y a longtemps, utilisait des images disques en ext4, avant de passer à F2FS, le code était disponible dans le SDK d’Android 7, puis a disparu dans les versions suivantes. Il y a eu un paquet debian, qui tentait de bien ranger un SDK bien invasif.

Heureusement, il y a eu des forks, dont le fork make_ext4fs d’OpenWRT qui l’a nettoyé de toutes dépendances exotiques, et qui fonctionne même avec autre chose que la glibc. Du beau travail de dev embarqué.

Lambda évoque l’utilisation d’un code spécifique qui linéarise les écritures, sans trop préciser le logiciel en question. fuse2fs (qui fait partie de e2fsprog) semble faire le job.

Pour rapatrier les images OCI et ses couches, j’ai déjà écrit un billet sur le distroless qui explique comment le faire avec curl et jq, cette fois-ci, crane fera très bien le job : manifest2layers.sh

Pour créer une image disque, empiler le contenu des archives tar dans l’image, ce sera avec make_ext4fs et fuse2fs : tar2img.sh.

Ces deux scripts utilisent des logiciels exotiques ou dans des versions trop récentes, et sont donc emballés dans un conteneur Docker, accessibles via une commande make.

make docker-tool
make img NAME=gcr.io/distroless/base-debian12

Les outils pour créer une image ext4 et la découper ne requièrent pas de privilèges root, juste un accès à /dev/fuse.

L’image a une taille fixe, et sera pleine de vide, mais bon, les systèmes de fichiers modernes le gèrent bien (tout comme GNU tar avec -S).

$ ls -slh out/*.img
42M -rw-r--r-- 1 root root 1.0G Apr 18 16:31 out/gcr.io_distroless_base-debian12.img
55M -rw-r--r-- 1 root root 1.0G Apr 21 11:50 out/gcr.io_distroless_java-base-debian12.img
57M -rw-r--r-- 1 root root 1.0G Apr 19 10:42 out/gcr.io_distroless_python3-debian12.img
24M -rw-r--r-- 1 root root 1.0G Apr 18 16:22 out/gcr.io_distroless_static-debian12.img

Les outils suivants seront en golang:

make build

Pour trimmer les zéros, puis découper en chunks, ce sera le cli en go chunk qui utilise la bibliothèque chunk.

Pour grappiller de la place, les chunks étant de taille connue (car fixe), ils sont tronqués, et n’ont pas leurs zéros en fin de fichier.

L’article dit bien que la compression avant chiffrage n’est pas recommandée, mais les chunks sont pleins de trous (des longues suites de zéro), et la compression m’évite de coder un sparse bytes dans un premier temps.

Une “recette”, préfixé en .recipe est écrite pour chaque image OCI, en format texte pour l’instant.

Les chunks sont entassés dans un même dossier, une partie d’entre eux seront communs entre différentes images.

./bin/chunk out/*.img
# les recettes sont dans le même dossier que l'image
ls -lh out/*.recipe
# les chunks sont dans le dossier smr
ls -lh smr

L’outil diff permet de comparer deux recettes, de compter le nombre de chunks de chacun, et surtout le nombre de chunks partagés. Les scores sont crédibles, une image dérivant d’une autre aura à peu près le bon nombre de chunks en commun. Il y a vraisemblablement des informations uniques dans le premier chunk, je n’ai pas été assez agressif sur les options de make_ext4fs.

$ ./bin/diff out/gcr.io_distroless_python3-debian12.img.recipe out/gcr.io_distroless_base-debian12.img.recipe
A: 123 chunks, 121 unique chunks
B: 58 chunks, 56 unique chunks
B has 51 chunks in common with A, 7.9 MB

Le serveur NBD va utiliser le backend en lecture seule, seule partie du code lié à go-nbd, qui va utiliser le module blocks, la seule partie de code un peu complexe, pour gérer les zéros implicites.

Le debug de serveur NBD est ingérable, les outils Linux ne sont simplement pas faits pour ça, même s’il logue gentiment dans /var/log/kernel.log, sur une lecture incohérente il se bloquera. Avec un Linux Alpine, ce sera encore pire, le client nbd est géré par busybox.

La nouvelle bibliothèque standard slog permet d’avoir des informations en mode debug, pour avoir le contexte et la partie de code qui crash. Il est étonnement simple de lancer le debugger delve depuis VSCode avec le client NBD dans un Linux virtualisé.

Mais ce n’est pas la bonne approche, les tests fonctionnels ne doivent être faits qu’à la toute fin, une fois que l’on a un serveur dans un état présentable.

Il est étonnement facile de s’autopipoter avec des tests unitaires qui affichent un excellent ratio de couverture. Les tests unitaires doivent être complétés par du fuzzing avec des fixtures crédibles, en l’occurrence de vraies images. Une fois que le fuzzing trouve une erreur, on l’ajoute aux tests unitaires (pour la lisibilité du prochain qui lira le code), on corrige, puis, “rinse and repeat” comme on dit en Amérique.

Le fuzzing de golang est agréable à utiliser, mais il utilise beaucoup de magie, avec des arguments non nommés, de l’introspection, et cette magie apparait dans les très confuses stacks trace de vautrage.

make fuzz

Pour compléter le fuzzing, le cli debug utilise le backend, la plus haute couche du code métier, juste avant go-nbd, et va faire des itérations seek+read aléatoires sur l’image brute, et la même chose sur le backend, pour comparer les deux.

./bin/debug out/gcr.io_distroless_python3-debian12.img

Le serveur utilise une recette

./bin/server out/gcr.io_distroless_python3-debian12.img.recipe

Qemu fournit un outil de debug pour décrire un serveur nbd

$ qemu-img info nbd://localhost:10809/smr
image: nbd://localhost:10809/smr
file format: raw
virtual size: 1 GiB (1073741824 bytes)
disk size: unavailable
Child node '/file':
    filename: nbd://localhost:10809/smr
    protocol type: nbd
    file length: 1 GiB (1073741824 bytes)
    disk size: unavailable

On peut maintenant monter l’image depuis un Linux (physique ou virtuel).

# nbd ne se plaindra que dans kernel.log, découper votre tmux avec un ctrl-%
tail -f /var/log/kern.log
# le module nbd doit être chargé
sudo modprobe nbd
# nbd-client va connecter le serveur avec un /dev/nbdx
sudo nbd-client -N smr localhost 10809 /dev/nbd1
sudo mkdir /mnt/smr
# le serveur est en lecture seule
sudo mount -o ro -t ext4 /dev/nbd1 /mnt/smr
# l'image est disponible, ou peut l'utiliser
ls /mnt/smr

Conclusion

Grâce à la persévérance d’OpenWRT, il est possible de créer des images disques déterministes, avec des chunks partagés entre différentes images. NBD permet de prototyper un serveur de bloc simplement, et un Linux vanilla saura l’utiliser.

Le prototype ne dépendant pas de go-nbd, il ne devrait pas être compliqué de tester avec l’audacieuse stratégie de blocks over FUSE, car rust-vmm n’en a que faire de nbd, pas plus que Firecracker.

Le cache en LRU/K, un serveur de cache à la Memcache/Redis, les chunks dans S3, ainsi que le chiffrage ne devrait pas poser de problèmes.

Le copy on write pour avoir un disque en lecture/écriture, le sparse bytes pour se passer de compression, le taint read pour connaitre les chunks utilisés lors du démarrage nécessiteront un peu plus d’attention.

Exposer les blocks via un vhost user backend devrait être un poil plus sportif, mais bon, il y a des specs et une implémentation de référence.

Je ne m’attendais pas à ce que l’article permette de faire une maquette, et qu’il utiliserait des outils secrets insuffisamment définis pour être reproduit. Mais non, avec pas mal de RTFM et d’assiduité dans la chasse aux bugs, ça passe.

Campagne internationale pour la sécurité informatique : audit automatique des projets

2024-04-08T09:04:00+02:00

Campagne internationale pour la sécurité informatique, partie 2

La partie 1 traitait des dépendances logicielles et des failles officielles.

Plutôt que d’attendre la découverte d’une faille (et sa divulgation), il est quand même plus sage d’auditer le code que l’on utilise. Pouvoir lire le code est quand même une des bases de l’open source.

Un humain aura du mal à lire tout le code qu’il utilise (puis les modifications), et il aura donc besoin de l’aide de robots.

Imaginer une lecture exhaustive est utopique, mais ça ne veut pas dire qu’il ne faut pas essayer.

Quantifier la qualité du code

Il est difficile d’auditer en continu le code que l’on écrit, le moindre mal étant la revue de code dans les demandes de fusion, mais il n’est pas humainement possible d’auditer tout le code open source utilisé, et encore moins de recommencer à chaque mise à jour.

L’idée est de confier cette tâche à des robots, comme assistant, et de manière autonome.

Typage

Le typage fort (tellement pratique pour la complétion dans les IDEs) s’avère être aussi très utile pour faire de l’analyse statique (ou même dynamique) de code. Le typage fort, longtemps méprisé par les langages de scripting, est maintenant partout : Javascript était tellement mou qu’il a fallu crée TypeScript (mais il y a maintenant la proposition d’intégrer le typage dans Ecmascript), Python a son typing et même Ruby, pourtant fan de monkey patching, a son sorbet pour gérer le typage.

Le typage permet d’avoir des informations sur l’intention du développeur, indépendamment de l’implémentation qu’il propose. Ce serait dommage de s’en passer.

Analyse statique

L’analyse statique de code existe depuis longtemps, et ça a même été une des fiertés de Java : les vraies professionnelles ont plein de tableaux de bord avec des graphiques qui vont en s’améliorant (sauf la consommation de mémoire, mais ce n’est qu’un détail).

Quand l’analyse touche la sécurité, on parle de SAST, Static Application Security Testing.

SonarQube regroupe divers outils d’analyse de codes pour créer de chouettes tableaux de bord dont est friand le management moderne.

Règles

La recherche d’erreur récurrente fait maintenant partie des outils de développement des différents langages. Ces outils mélangent souvent les règles de formatage, les remarques blessantes sur l’absence de commentaires, de vraies obligations de bonnes pratiques dans le code. Les outils sont souvent dispersés, et utilisés via un métaoutil “pour les gouverner tous” :

Golangci-lint pour Golang
Ruff pour Python
Rubocop pour Ruby
Clippy pour Rust, oui, le nom est un hommage à l’infâme trombone de MS-Office
Nodejsscan pour Nodejs
Ansible-lint pour Ansible
Hadolint pour les Dockerfile
Terrasscan pour l’infra as code
Shellcheck pour les scripts shell

Pour aller plus loin que cette sélection, allez jeter un œil sur analysis-tools.dev que l’on pourrait renommer “awesome static analysis”.

Ces outils sont souvent utilisés via les IDE, mais ils peuvent se brancher dans l’intégration continue pour avoir un résultat systématique et homogène. L’intégration la plus brutale est de refuser le commit, puis de vautrer la CI, le plus diplomate étant de commenter la demande de fusion (et de bloquer cette demande).

Github intègre les résultats d’analyse de code via le format SARIF, crée par Microsoft. Le format, basé sur JSON, est normalisé par OASIS, et utilisé pas différents outils.

Gitlab a réfléchi pendant 4 ans à son intégration, pour finalement proposer une moulinette qui transforme un rapport SARIF vers leur format maison, implémenté dans leur projet report sous licence MIT (dans sarif.go pour être précis).

Les outils de lint fournissent des listes de règles qui se pensent universelles et on peut les désactiver une à une (attention, c’est une lourde responsabilité).

Les règles génériques constituent une base, elles sont écrites et recommandées par des entités de renoms, ce qui permet d’éviter de longs ergotages sur la pertinence de tel ou tel point.

La découverte d’une nouvelle faille ou soucis de performance peut être généralisé sous la forme d’un motif, que l’on doit pouvoir rechercher autre part.

Chaque application/groupe/entreprise est unique, et il y aura des motifs récurrents en son sein : des bonnes pratiques, et des erreurs. Ici aussi, des outils doivent permettre de travailler avec des motifs maison.

Idéalement, il faudrait pouvoir corriger les problèmes remontés par les outils d’analyses, à défaut, il est possible de se contenter d’une note, et attendre les effets de la pression sociale pour que ça s’améliore (d’ailleurs, ce blog a fièrement un A+ pour son SSL).

Recherche

La recherche “full text” classique, naïve en fait, est “courte des pattes” pour faire des recherches dans de grandes quantités de codes. La normalisation des mots (comme la lemmatisation) n’est pas pertinente pour du code, et c’est surtout le débit de modification sature les index inversés.

Github a utilisé Solr puis Elasticsearch, qui n’a pas pu suivre la croissance du nombre de projets et de modifications. Au sommet, Github a utilisé un cluster Elasticsearch de 162 nœuds, 5184 vCPUs, 40To de RAM, 1.25Po de disques, une moyenne de 200 requêtes par seconde, sur 53 milliards de fichiers. Des dimensions mythologiques.

Expression régulière

grep est l’ami du développeur, enfin, ripgrep de nos jours. Ils lisent quantité de fichiers pour y rechercher des motifs, ce qui ne va pas bien fonctionner sur de grandes quantités de textes et beaucoup d’utilisateurs.

Google explique comment combiner indexation et expressions régulières : c’est ainsi que fonctionnait (fonctionne encore?) leur CodeSearch interne. C’est à priori ce même CodeSearch qui est mis à disposition pour rechercher dans ses projets open source.

La recette secrète de CodeSearch est de pouvoir appliquer des expressions régulières (enfin, un sous-ensemble qui garantit un temps de réponse raisonnable, Re2) sur des quantités gargantuesques de code, indexé par trigrammes. On commence par extraire les trigrammes de l’expression de recherche (tout ce qui n’est pas signe cabalistique), ce qui permet de faire une première sélection de documents contenant ces trigrammes, et de ne lancer la couteuse expression régulière que dans ce sous-ensemble.

Russ Cox (cofondateur de Go et “ingénieur distingué” chez Google) explique précisément le principe de la recherche par expression régulière sur des index avec du vieux code archivé comme démonstration.

Sourcegraph maintient Zoekt, projet initié par Google, qui implémente (et cite) l’article regexp/trigram, pour des quantités raisonnables de code (2Go), en utilisant un simple btree pour le stockage. Attention à la taille des index, qui peut atteindre 3 fois la taille du code.

Ling Zang, doctorante au sein du Gray Systems Lab propose une implémentation contemporaine en C++ : Blare (BLAzing fast REgex) avec le white paper qui va bien.

La recherche de Github est basée sur l’article de Cox, mais avec un pinaillage sur la taille des ngrams (les sparse-ngrams), car le code contient trop de mots trop courts (for, if, not…). Oui, leur explication technique sur les ngrams clairsemés est nébuleuse.

Arbre symbolique abstrait

Le code n’est pas de la prose.

Quand on cherche un élément, on ne veut pas mélanger les commentaires, fonction, argument ou autres informations typées. De manière similaire, les commentaires (annotations, types…) sont attachés à un élément.

Pour indexer du code, il est pertinent de commencer par le parser, pour créer un AST (Abstract Symbolic Tree), qui lui, sera indexé.

Chaque langage civilisé a dans sa bibliothèque standard ce qu’il faut pour lire sa propre syntaxe. Ils existent de multiples approches pour parser des formats structurés, et le domaine évolue au fil du temps, et de nouveaux outils apparaissent régulièrement, l’hégémonie de lex/yacc n’est plus.

Tree-sitter

L’ambitieux Tree-Sitter se positionne comme le générateur universelle de parsers :

gestion d’un nombre farfelu de formats avec ses parsers (137 cités dans la doc)
des bindings dans 19 langages
tree-sitter sait créer une bibliothèque partagée (un .so, quoi) à partir d’une grammaire, et la plupart des bindings utiliseront ce format, il y aura donc du C dans votre langage préféré. Le parser est suffisamment rapide pour reparser le buffer d’un éditeur de texte à chaque clic d’une touche.
les s-expressions (les listes imbriquées de Lisp) sont utilisées à différents endroits : comme format de sortie, comme prédicat pour filtrer le parcours d’un arbre.

La navigation de code de Github utilise tree-sitter, ainsi que son moteur de recherche.

Sourcegraph aussi aime bien tree-sitter:

doctree crée un site web de documentation de code, mais le code n’a pas été touché depuis 2 ans, et le nom de domaine est mort.
cody est une IA qui connait votre code.
sourcegraph permet de naviguer et de chercher dans votre code (et une intégration avec Cody)

Bien d’autres applications utilisent tree-sitter, dont certaines seront évoquées plus bas dans l’article.

Datalog

Ni les moteurs de recherche full text, ni les bases de données relationnelles ne sont adaptés pour indexer des projets avec leur code.

Il faut donc étendre la recherche dans les modèles exotiques de bases de données. Avant l’invention de la base de données relationnelle, il y a eu les bases de données déductives, inspirées par Prolog.

Le concept de ces bases est proche de celui des bases orientées graphes, les données sont modélisées par des triplets : 2 nœuds liés par une relation.

Le modèle déductif a Datalog comme langage de requête tout comme le modèle relationnel a SQL.

Embeded code

Rien à voir avec les ordinateurs trop petits de l’embarqué, embeded désigne la technique de représenter les mots (enfin, des tokens) sous forme de vecteurs, ainsi que les documents, permettant ainsi de faire des recherches de proximité (en calculant la distance entre deux vecteurs). C’est la base des LLM, les Larges Languages Model.

Vous reprendrez bien un louche d’IA?

Github a documenté ses travaux pour proposer de la recherche sémantique de code (avec les liens vers les papiers de recherche), pour proposer l’année suivante (2019) un concours sur le même thème avec encore des citations de publications sympathiques comme embarquement de texte et de code par préentrainement contrasté.

Tout ça a fini par devenir Copilot, leur magicien de l’autocomplétion de code.

Les LLM peuvent rendre de grands services, mais pas (encore?) de chasser le bogue.

Sourcegraph

Sourcegraph essaye de se positionner comme le leader de la recherche de code, bien que seule une petite portion de son code soit libre. On peut installer le service sur son poste, pour avoir la première dose gratuite.

Gitlab peut utiliser Sourcegraph pour naviguer dans le code, depuis l’interface web, et effectuer des recherches, ça en fait presque un standard de fait.

La recherche de Sourcegraph s’appuie sur un salmigondis de bases de données (du trigramme/regexp avec Zoepkt, du vecteur avec Qdrant, du relationnel avec Postgres et Sqlite). On peut ajouter à ça un peu de full text (j’ai vu passer des bibliothèques de lemmatisation), et de l’IA avec son Cody.

Sourcegraph a essayé d’étendre Langserver (le LSP des IDE) avec LSIF pour normaliser l’indexation de code, pour finalement abandonner et déprécier ses contributions, pour se rediriger vers son SCIP, qui crée des index que son serveur peut manger. Un outil permet de dumper les index en JSON, pour l’utiliser en dehors de Sourcegraph.

Sourcegraph propose des outils pour rechercher puis patcher du code, mais l’implémentation actuelle est brutale : il faut écrire un bout de bash qui sera lancé dans un conteneur sur toutes les occurrences de la recherche.

L’écosystème Sourcegraph fournit des briques intéressantes, mais rien de bouleversant pour aller à la chasse au mauvais code.

CodeQL

Microsoft, en rachetant Github s’est retrouvé, de fait, comme responsable d’une bonne partie des sources du logiciel libre. C’est assez cocasse quand on connait la position de Steve Ballmer quelques décennies plus tôt.

Gardien des sources, des bugs mais aussi de la flemme de tous les jours.

Microsoft est bien au courant de la valeur d’une CVE, il a donc ajouté des outils pour boucher le code troué.

Dependabot (dont certaines briques sont libres) est un robot qui crée des demandes de fusion quand la correction est triviale (mettre à jour une dépendance officiellement trouée) ou envoie des alertes s’il faut prendre une décision pour corriger.

Personnellement, je pense que Dependabot est aussi un complot pour faire regretter d’avoir choisi Nodejs, qui avec sa palanquée de microbibliothèques, va statistiquement trouver au moins une faille par semaine, quelque part au fond d’une branche du graphe de vos dépendances.

La vraie puissance de Dependabot n’est pas juste de lire et patcher les listes de dépendances figées, mais la recherche de motif de code avec CodeQL en fournissant un lot de règles CodeQL, qui ont la gentillesse d’être sous licence MIT.

CodeQL a fait le pari de Datalog pour écrire des requêtes. Choisir un langage ésotérique, inventé avant le Minitel, est audacieux. Charge à Github d’utiliser correctement ses index, le cache et la parallélisation pour exécuter efficacement ces recherches déclenchées par la CI.

Règles métiers

Il existe divers outils pour décrire des patchs génériques à appliquer sur quantités de projets (ou dans un bon gros monorepo).

Ils sont souvent conçus pour créer des patchs jetables, et se contentent pour la plupart d’une utilisation en ligne de commande, quelques-uns proposent une intégration plus fine, avec des consoles interactives ou de l’intégration continue.

Agnostique

Semgrep, écrit en OCaml qui aime tant le parsing, propose d’appliquer des règles décrites en YAML. Il y a une version libre en LGPL, et pour avoir le parsing multifichier et d’autres bonus, il faut passer à la caisse. On notera la possibilité d’obtenir une réponse en SARIF, gage d’intégration avec d’autres produits.

Comby, encore en OCaml, et sous licence Apache 2, se positionne comme roi du one liner, pour remplacer le traditionnel grep+sed. Il positionne comme outil de patch universel, plutôt que comme linter.

Infer, de chez Facebook, et toujours en OCaml, se contente de chasser le bogue en C/C++/Objective-C et Java, mais il est utilisé par de grands noms.

ast-grep, écrit en Rust avec du tree-sitter, se positionne comme grep du code, alors qu’il permet aussi de remplacer, en plus de rechercher des motifs.

Python

pyparsing a longtemps été la brique de base pour lire du code (pour ensuite râler ou proposer une correction). Yelp a utilisé Undebt pour faire de la chasse au code déprécié. La chasse a été bonne, mais le projet a été archivé.

Plus classique, issu de l’équipe sécurité d’OpenStack, puis maintenu par la Python Code Quality Authority, bandit parcours l’AST d’un fichier Python pour y trouver des mauvaises pratiques. Bandit propose une liste de règles, mais il est aisé d’en créer de nouvelles. Une règle s’abonne à un évènement (souvent un appel de fonction), qui déclenchera une vérification, pouvant renvoyer un Incident. Les règles fournies sont simples (voir naïves), bandit ne permet pas une grande expressivité.

RedBaron propose de naviguer dans l’arbre abstrait de code python, de manière interactive, avec la possibilité de modifier des éléments, et de revenir à un code source avec juste ce qu’il faut de modifications. RedBaron a tout ce qu’il faut pour créer des patchs génériques, mais pour l’instant, il n’a pas exploré la recherche de “mauvais motif” avec une correction; il est plus conçu pour créer du patch du sur mesure, pas du prêt-à-porter.

Facebook a sa productive équipe OCaml et propose Pyre, parfois appelé Pysa (pour PYre Security Audit). Pyre file la métaphore des hydrologues, avec des source qui sont tainted (des inputs confiés à un utilisateur) et des sink (des zones à surveiller, comme l’exécution d’une commande) qui seront teintés ou non. Pyre s’appuie sur le typage de Python.

Golang

Gopatch reprend l’astuce de Coccinelle, et utilise l’antique syntaxe de patch de diff pour décrire des correctifs.

Java

Java propose des outils étranges et grandiloquents, comme OpenRewrite et Rascal. Les patchs, c’est pour les petits bras, Java mérite de la méta programmation.

Fuzzing

L’analyse statique, c’est bien, mais l’analyse dynamique peut apporter des informations complémentaires.

Le fuzzing est une des stratégies possibles d’analyse dynamique, il en existe d’autres.

L’idée du fuzzing est de jeter du pâté dans le ventilateur (“spam hits the fan” en VO).

le code est instrumenté, depuis l’intérieur en le recompilant (ou une technique équivalente pour du script), ou depuis l’extérieur via le kernel (souvent via QEMU). Des désinfecteurs (sanitizer en VO) vont surveiller des comportements anormaux, tant sur le plan logiciel que matériel.
On désigne un point d’entrée (une fonction)
Il est possible de modifier les appels système (avec preeny par exemple) pour que le code ait un fonctionnement plus déterministe, voire même de remplacer un échange réseau par une discussion sur STDIN/STDOUT, les fuzzer préfèrent appeler une fonction, plutôt que de démarrer un serveur complet.
À partir d’exemples, ou de rien, un corpus va être créé, en essayant de maximiser la couverture de code. Ce corpus devient un artéfact et sera réutilisé.
Le point d’entrée est testé avec des données issues du corpus, auquel on applique des mutations. En cas d’erreurs (ce que l’on cherche), le test sera réduit (shrinking en VO) pour n’avoir qu’un changement mineur entre une valeur qui passe, et celle qui ne passe pas.
Historiquement, les données en entrée sont un gros binaire, ce qui correspond aux cas classiques de la lecture d’un fichier ou d’un échange réseau. Il est aussi possible de définir des générateurs (ou des grammaires), pour fournir du contenu typé.

Générer du contenu complètement aléatoire sera peu efficace, il existe différentes stratégies faisant référence à la génétique, avec des notions de mutations, qui ne sont pas retenues si elles ne génèrent pas d’erreur ou n’améliorent pas la couverture de code.

Bien sûr, il est possible d’utiliser de l’IA pour fuzzer encore plus fort.

Les fuzzers subissent une forte sélection darwinienne, les bonnes idées sont conservées pour la génération suivante, les autres idées finissent en fossile.

AFL, considéré comme standard de fait, mute en AFL++ pour finalement donner HonggFuzz, et je vous fais grâce de l’explosion cambrienne listée dans Awesome-AFL.

Gitlab propose de s’interfacer avec du fuzzing, mais dans sa version ultimate (la plus chère), en vous laissant l’approche DIY dans votre très classique CI, avec des exemples dans différents langages

Oss-fuzz

Google a testé ses outils de fuzzing créés pour Chrome sur des logiciels opens sources, et a trouvé beaucoup d’erreurs, certaines avec des implications au niveau sécurité. Comme les erreurs découvertes se chiffrent en milliers, Google s’est associé à l’OSSF pour créer oss-fuzz, un service de fuzzing continue dédié à l’open source.

Attention, on entre dans le monde merveilleux du code Google libéré : il faut s’attendre à des acronymes aléatoires de 4 lettres, des projets remplaçant le précédent (parfois 3 ou 4 remplacements) et des README partiellement à jour.

L’outil, ClusterFuzz (avec sa variante allégée, ClusterFuzzLite), est libre (licence Apache 2). Il est conseillé pour fuzzer du code non libre (sur une instance interne).

ClusterFuzz gère différent fuzzers historiques, et globalement, les fuzzers spécifiques se rapprochent de LibFuzzer dans leurs comportements.

On notera que l’attaque sur OpenSSH via xz a commencé par désactiver le fuzzing d’Oss-fuzz sur la partie qu’il a ensuite contaminée : témoignage de crainte face à Oss-fuzz. OK, Oss-fuzz n’a pas découvert cette faille, car le cambrioleur a coupé l’alarme de la salle du coffre, mais il a pris la peine de le faire.

Sanitizers

Les désinfecteurs vont surveiller ce qu’il se passe au niveau de l’allocation de la mémoire et des threads.

Les désinfecteurs peuvent être utilisés en instrumentant le code compilé (avec LLVM et même gcc), puis le code est exécuté avec un malloc spécifique.

Le kernel Linux est maintenant outillé pour surveiller ce qu’il se passe au niveau de la mémoire et des threads (qui font quand même partie de sa responsabilité). Ces modules ont été intégrés au fur et à mesure dans le kernel : ce sont les K*SAN. Ils ne gèreront pas forcément toutes les architectures, et pour certains, il faudra utiliser un noyau compilé avec LLVM plutôt que gcc (ne le dites pas à Stallman). Les kernels instrumentés ne visent pas la production, mais une VM temporaire pour secouer du code dans une cuve pleine de capteurs.

Fuzzers

D’autres langages disposent d’une instrumentation compatible avec oss-fuzz : C/C++, Rust, Go, Python, Java/JVM, Swift et JavaScript (dont typescript), pour les autres, ce sera uniquement via LLVM.

Comme grand absent, on notera Ruby, tellement fière de la liberté de sa syntaxe et assument le monkey patching ne doit pas aider les fuzzers à se concentrer. Mais trêve de mauvaise langue, le projet Ruzzy reprend pour Ruby l’approche d’Atheris (le binding de libFuzzer pour Python).

Mutation de test

Le principe de mutation de données peut être utilisé sur de très classiques tests unitaires pour répondre à la question “Qui test les test?” (ou Quis custodiet ipsos custodes? pour les fans de péplums en VO).

La mutation de test est une idée de Richard Lipton, alors étudiant, en 1971, ce qui ne nous rajeunit pas (c’est plus vieux que vi). Il a attendu 1980 pour donner le sujet à un thésard en philosophie, Thimoty Alan Budd : Mutation Analysys of Program Test Data.

L’idée est de cochonner votre base de code avec des erreurs, et de voir si les tests passent encore. Les mutations correspondent à des fautes que ferait un développeur distrait (remplacer un > par une >=, un && par un ||, mettre un not devant un booléen, ce genre d’étourderies).

Le logiciel va créer un rapport et coller une note : le ratio entre le nombre de mutants attrapés et le nombre de mutants crée.

Si votre outil est un poil finaud, il va commencer par lancer les tests un à un, et noter la couverture de code à chaque fois. Ainsi, il ne va muter que le code couvert par les tests, et ne lancera que les tests concernés.

Les mutations de tests ne déclenchent pas un enthousiasme fou sur Github, mais il y a largement de quoi farfouiller.

Le leader de ce domaine est Java, avec Pitest, mais il existe aussi mutmut pour Python, Mutant.rs ou go-Gremlins.

Quantifier la qualité d’un projet

Nous venons de voir qu’il était possible de lancer des hordes de robots pour auditer le code de logiciels open source que vous souhaiteriez utiliser. Mais la qualité du code n’est qu’une partie de la qualité globale du projet.

L’exemple de l’attaque sur xz est frappant, sur un des miroirs (le projet officiel est banni), on voit que la qualité du code n’est qu’un détail :le payload de l’attaque, présenté comme une fixture, est chiffré, et le déclencheur n’est pas versionné dans le git, mais juste dans la tarball de la release. La vraie information, ce sont les contributions de xz, il y a UN mainteneur, Larzhu, une poignée de gens faisant quelques propositions de modifications, et un sauveur, l’infâme JiaT75, qui vient filer un coup de main.

ScoreCard.dev

L’OpenSource Security Foundation, a créé une moulinette, [ScoreCard] (https://scorecard.dev/) qui donne une note aux projets open source, dans une approche très scolaire, pour pousser les projets à suivre de bonnes pratiques.

Les différentes vérifications sont plus que légitimes, mais aussi des pousse-au-crime pour utiliser l’écosystème Github de bout en bout.

J’espère que ça va piailler, et qu’il va y avoir du lobbying pour que des services alternatifs (des gros services en ligne, ou des petits autohébergés) soient pris en compte pour le calcul du ScoreCard.

Deps.dev

Google, avec deps.dev pousse l’idée de ScoreCard.dev un cran plus loin en recyclant leur PageRank. la note finale d’un paquet est calculée en fonction du graphe de dépendance tirée par ce paquet. Un paquet avec une mauvaise note va faire baisser la note de ceux qui l’importent, directement ou indirectement.

Autre avantage de deps.dev est qu’il propose un chouette site web avec un moteur de recherche alors que scorecard.dev vous propose de télécharger des CSV de dimensions cyclopéennes.

Criticité d’un projet

L’OSSF a une autre moulinette (en bêta) pour donner une note à l’importance d’un paquet au sein de l’écosystème open source : le Criticality Score.

Il utilise le ScoreCard, l’âge, le nombre de projets l’utilisant, le nombre de contributeurs (individuels et organisations), le débit de contributions et de tickets, ce genre de choses.

Ce genre de classement devrait permettre de trouver les maillons faibles de la chaine d’approvisionnement, et justifier des financements pour des développeurs quelconques du Nebraska, comme le recommande XKCD.

Distroless, les images sans distributions

2024-03-24T09:04:00+01:00

Less is more

Le journalisme a un suffixe magique, “gate”, qui permet de créer des buzzwords qui claquent, depuis le watergate. En informatique, le suffixe magique est “less”, comme dans

diskless, un ordinateur qui démarre via le réseau (sans utiliser son disque).
headless, un système de gestion de contenu, qui permettra de générer un site statique et/ou une API distante depuis le javascript de la page web.
cpu-less, blagounette d’ordinateur rudimentaire à base de portes logiques.
db-less, architecture sans base de données relationnelles.
serverless, du cloud sans le cloud, juste votre code poussé dans le nuage.
code-less, le terme no-code est plus courant. Une interface permet de décrire une logique métier, sans écrire de code.
browserless, des test fonctionnels (ou du scraping de fourbe), depuis un navigateur web sur un ordinateur sans écran.
less, comme more mais mieux (humour UNIX).
distroless, une image conteneur construite sans distribution Linux

Conteneur

Nouvelles abstractions

Quand la virtualisation est apparue, la promesse était “ne touchez à rien, c’est comme avant”, on prend le contenu d’un serveur physique, on le met dans un serveur virtuel, et hop. Sauf que la virtualisation (fort pratique pour simuler une autre architecture) est rapidement devenue de la para-virtualisation, bien plus performante, l’OS invité collabore avec l’OS hôte. Cette collaboration est allé plus loin avec la création de matériel virtuel VirtIO, pour finalement aboutir aux machines virtuelles légères qui n’utilisent quasi que du Virtio ( DragonBall, FireCracker …).

Les conteneurs ont été conçus pour isoler une poignée de process (idéalement un). À l’arrivée des conteneurs, la même promesse a été faite : LXC, c’est presque comme une machine virtuelle, avec un init qui lance une grappe de services. Docker a fait le ménage pédagogique en expliquant bien qu’un conteneur va héberger un seul service. Mais, pour pallier aux cas de process zombie, Docker a intégré tini, avec l’option (--init).

Cette option est très peu utilisée, les applications métiers, même celles qui forkent des workers, savent gérer leur sous-process. De plus, le dogme demande de laisser à Kubernetes le soin de gérer la mise à l’échelle en multipliant les instances.

Image de base

Docker a fait le choix d’utiliser comme dossier racine un assemblage de pelures de systèmes de fichiers. Seule la pelure du haut est modifiable. Pour créer une image, on part d’une image, et on ajoute des pelures. Par convention, la première couche, vide, s’appelle SCRATCH.

Le meilleur moyen d’appréhender une nouvelle abstraction est de commencer par faire comme avant, et donc d’utiliser une distribution Linux, en partant d’un bootstrap (par ce que l’installation complète depuis un CD, à la Packer, ça va 5 minutes), puis d’installer des paquets.

Une image Docker est allégée, elle n’est pas bootable et n’a ni kernel, ni la ribambelle de services systèmes.

Docker a porté son choix d’image de référence sur Debian (libre à vous d’en faire d’autres à partir de votre distribution favorite). Ubuntu a deux fois plus de fan, propose de nouvelles versions à date fixe, mais fait régulièrement des choix polémiques. Ubuntu étant basé sur Debian, et ses ajouts ne s’aventurant que rarement dans les couches basses et les runtimes, ça ne change pas grand-chose. Donc, Debian.

L’image Debian officielle (maintenue par Debian) est construite à partir de son système de paquets, via l’outil debootstrap, utilisé aussi pour créer des images disques pour des machines virtuelles. Pour avoir des images reproductibles, deboostrap est emballé par debuerreotype, qui en plus de la gestion de snapshot va aussi appliquer différents paramétrages pour minimiser la taille de l’image.

Avec une optimisation agressive (en virant la doc essentiellement), on gagne 30% de place, et on a une image dite slim.

Les images de langages (python, ruby, golang, node, rust…) sont basées sur les images Debian officielles. Comme les images partagent leurs ancêtres, avec tout basé sur Debian, on mutualise pas mal de place en disque et réseau (lors du déploiement).

Les utilisateurs Docker se sont rendu compte qu’en partant sur une distribution Alpine, distribution minimaliste prévue pour l’embarqué, on obtient une image 10 fois plus petite, mais avec un système de paquet moins cohérent que Debian, une libc rikiki (musl) et busybox plutôt que les outils gnu. Les images de langages proposent souvent une variante basée sur Alpine, en plus de Debian.

Pour construire l’image de son application, on utilise souvent deux images : une image de construction, éphémère, avec les outils de développement, et une image d’exécution qui finira en production.

Images minimalistes

Pour limiter la surface d’attaque, les faux positifs dans les analyses de versions de paquets, et la taille des images, la nouvelle tendance est d’utiliser des images minimalistes. Minimaliste pour ne pas dire “à l’os”, ces images n’ont pas de shell, et aucun utilitaire.

Debugs et tests ne se feront pas depuis l’image, mais autour de l’image.

L’application aura des tests unitaires, l’image des tests fonctionnels et des tests de charges. Les erreurs remonteront via les journaux et Sentry. Les soucis de performances seront analysé par les traces, les sondes déployées en production.

Dans le pire du pire, un debug en preprod sera fait avec un conteneur sidecar, par ce que le conteneur de l’application sans shell, ne permet pas de s’y connecter avec un docker exec. Kubernetes permet de se connecter à une instance (un pod) mais je ne suis pas sûr que ce soit une bonne idée de le faire en production.

Distroless

Google a exploré une piste minimaliste pour construire des images dites “runtime” avec différents critères :

basé sur une distribution connue, pour la confiance et la correction des CVEs.
les applications apprécient d’utiliser les dernières mises à jour (stables) de leur langage, ce que ne peut fournir une distribution qui a besoin de la valider avec une brouette de paquets.
en se basant sur Debian, on peut construire l’application avec l’image de langage officielle, elle aussi basée sur Debian, pour ensuite déposer le tout dans une image “runtime”.
Les images doivent pouvoir être construites rapidement, avec du cache efficace, sans réclamer un utilisateur privilégié.
Différentes architectures de processeurs doivent pouvoir être gérées, sans émulation ni CI sur différentes architectures de serveurs.

Explorer une image sans shell

Voici une petite recette, qui sent le vestiaire, pour aller visiter une image sans shell. Commencez par voler un busybox, un bon petit binaire statique qui sert à bricoler dans des Linux trop petits.

Comme distroless est basé sur Debian, le vol de busybox se fera à partir d’une Debian de la même version.

# Préparez un volume pour accueillir le larcin
mkdir /tmp/tools
# Et branchez le dans votre bonne vieille Debian
docker run -ti --rm -v /tmp/tools:/tools debian:12-slim

# Vous êtes dans le conteneur.
# Un conteneur n'a pas d'index apt, ça prend de la place et c'est tout le temps périmé
apt update
# On va éventrer le paquet, autant faire ça dans un endroit tranquille
cd /tmp
# En suivant la voie de Debian, téléchargez le paquet dans sa version courante
apt download busybox-static
# dpkg va ouvrir le paquet, pas moyen de le faire à la main, une debian-slim n'a pas l'application ar
dpkg-deb -R busybox-static_*.deb .
# Recopiez le binaire dans le volume monté
mv bin/busybox /tools/
# Au revoir
exit

Vous pouvez maintenant lancer une image ascétique en montant busybox dans le PATH, comme le dossier /usr/local/bin prévu pour accueillir du bazar, n’existe pas dans l’image, ce sera donc usr/bin.

$ docker run -ti --rm -v /tmp/tools/busybox:/usr/bin/busybox gcr.io/distroless/static-debian12 busybox sh


BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Bazel

Distroless utilise Bazel, un outil de build très agressif sur la parallélisation et le cache (en utilisant un graphe de dépendance). Bazel est la version open source de Blaze, outil interne de Google, libéré en 2015.

Bazel utilise un dialecte spécifique, Starlack (basé sur la syntaxe de Python), mais n’hésite pas à utiliser des outils maison (évidemment compilé par Bazel).

Gestion des paquets Debian

Distroless fait le choix de faire les images sans utiliser de conteneur, ni les outils de gestion de paquets Debian. En travaillant directement avec les paquets (on pourrait ricaner en parlant de containerless), plus de soucis de multi architecture, ni même d’OS hôte, le build sera le même depuis un Mac ou un Windows (oui, le build sera fait depuis une CI, dans un conteneur, comme tout le monde).

Distroless utilise son propre module golang pour gérer des paquets Debian.

Il y a un sous-module (peu palpitant), build qui va permettre à gazelle d’écrire des fichiers bzl avec les détails sur les paquets à utiliser.

L’autre sous-module, deb, est le plus intéressant, il gère les debianeries pour récupérer, entre autres, la liste de paquets.

Instantanés Debian

Debian fournit un système d’instantanés pour retrouver les versions des paquets à une date donnée. Le site snapshot.debian.org explique son fonctionnement (on notera l’architecture moderniste : 2 sponsors fournissent un serveur apache+varnish avec une application Flask en python 3 derrière un load balancing DNS, et du certificat LE. Par contre, c’est 135 To de stockage, pour un historique depuis 2005).

Chercher un instantané pas trop vieux avec la liste des paquets

deb/snapshot.go

Il suffit d’aller sur https://snapshot.debian.org/archive/debian/?year=%d&month=%d puis de fouiller dans le HTML l’expression régulière [0-9]+T[0-9]+Z. On notera qu’il peut y avoir des jours sans snapshots, et plusieurs snapshots sur une journée, avec des horaires aléatoires.

Le commentaire dans le code précise que parfois, le dernier instantané est incomplet, et qu’il suffit de prendre le précédent. De toutes façon, le code cherche un snapshot qui a plus de deux jours (ce délai est codé en dur).

On peut ensuite aller sur https://snapshot.debian.org/archive/debian/%s/dists/%s/main/binary-%s/Packages.xz avec le snapshot, la version (bookworm pour la version courante) puis l’architecture, pour connaitre l’URL de la liste des paquets.

Ça, c’est pour main, Debian utilise plusieurs canaux, il faut recommencer pour updates et security.

On n’est pas tout à fait à l’état de l’art comme API REST, mais bon, avoir accès à tous les instantanés des différentes Debian garanti une reproductibilité et un retour en arrière possible.

Lister les paquets d’un instantané

deb/parser.go

Le format de liste de paquets Debian est plutôt carré, sauf que le parser prévoit un buffer de 1Mo pour lire des lignes trop longues.

Nomenclature des versions de paquet Debian

deb/versions.go

Debian utilise une nomenclature personnelle pour les versions de paquets, prenant en compte la version du paquet source et un versionnage des correctifs appliqués par le mainteneur. Comme on travaille avec 3 listes de paquets, il faut être capable de trier les versions pour trouver la plus récente.

Format de paquet

Les paquets Debian utilisent un format antédiluvien, ar. La commande ar fait parti de GNU binutils, mais la Linux Standard Base l’a déprécié et il sera bientôt retiré.

Chose intéressante, le tar de BSD (celui disponible sur MacOS) sait lire des archives ar, et c’est avec cet outil que Bazel dépiaute les paquets Debian dans la règle étrangement nommée locale.

Pour installer (comme une brute) un paquet Debian dans une image de conteneur, il suffit d’ouvrir le paquet (au format ar), de récupérer les données (l’archive tar, data.tar.xz), de créer le fichier status qui se retrouvera dans /var/lib/dpkg/status.d et d’en faire un tar, qui sera ajouté à votre image de base. On notera qu’à la différence des images debian-slim, la documentation que l’on trouve dans usr/share/doc est conservé.

En maintenant la base dpkg/status, les outils listant les versions, comme Syft fonctionnent sans surprises.

Ce genre d’installation ne prendra pas en compte les déclencheurs du paquet (preinst et postinst), mais bon, l’image Debian Docker officielle brime aussi le paquet en les empêchant de lancer/relancer des services.

Distroless fournit des images de base spécialisées (node, java, python…) pour faire tourner du code métier, il ne se charge même pas de la compilation du code, et donc à part quelques bibliothèques, vous n’allez pas installer grand-chose (car tout est dans votre dossier de vendoring).

Les couches d’une image conteneur

Bazel a décidé de bouder Docker en archivant rules_docker, pour mettre en avant le format d’image OCI avec rules_oci, et en disant quelques méchancetés sur son défunt concurrent. Docker utilise les images OCI de manière transparente, ce n’est donc pas très grave, et Distroless fournit des exemples de Dockerfile utilisant ses images.

Distroless assemble ses images OCI à partir d’une liste de tar, certains crée à partir de paquets Debian, d’autre sont générés (et tous sont cachés).

Des tests sont effectués avec container-structure-test, un simple outil en ligne de commande, qui va savoir travailler avec une liste de tar pour vérifier la présence/absence d’un fichier, ou avec docker, pour lancer des commandes. Les paranoïaques ont la possibilité d’utiliser gVisor pour lancer des commandes douteuses dans des conteneurs.

Les images sont créées pour chacune des architectures, puis rassemblées par rules_oci pour en faire une image multiarchitectures.

Inventaire

L’administration américaine demande d’utiliser des SBOM (Software Bill Of Material), et il existe différents formats dont SPDX (Software Package Data Exchange).

Debian s’intéresse à SPDX, surtout pour gérer les histoires de licence (tout comme le projet reuse).

Distroless a un outil pour créer une entrée SPDX à partir d’un paquet Debian : debian_spdx. À partir de la liste de paquets demandés pour créer une image, il est facile de créer un SBOM spdx : oci_image_spdx.

Dans une première itération, il était possible de pousser les SBOM specifications dans un registre OCI, mais rien ne garantit la cohérence entre cette spécification et l’image. Il est maintenant recommandé d’utiliser une Attestation spec qui utilise le format d’attestation spécifié par in-toto, et une signature.

Par convention, Docker puis OCI, stockent la description de l’image à un endroit, le manifest, qui va désigner des blobs. Les blobs sont immuables et nommés à partir de leur hachage, ce qui permet d’avoir un cache efficace, et de ne télécharger que les blobs manquants. Un blob est souvent la couche d’une image, mais le système reste ouvert sur le contenu d’un blob.

Demo time

Prenons comme exemple gcr.io/distroless/static-debian12:latest, la fameuse image de moins de 2Mo.

La convention de nommage permet de construire l’url de son manifest.

Si dans le nom d’une image il y a un ou deux éléments séparés par des slash, elle sera sur le hub Docker, si il y a 3 éléments, le premier désigne le hub, ici gcr.io (pour Google Container Registry je présume).

v2 est la version de l’API.

distroless est le groupe.

static-debian12 est l’image.

manifests par ce que je souhaite connaître la description de l’image.

latest est le tag par défaut.

$ curl -L --silent gcr.io/v2/distroless/static-debian12/manifests/latest

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1951,
      "digest": "sha256:285af5683714393b2702463eb92bf1290bb12401a265c2a8942ebd79ac1ac673",
      "platform": {
        "os": "linux",
        "architecture": "amd64"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1951,
      "digest": "sha256:7866c847208413c5f8c6c9fa1c78dca9421f6deb1c553c8384d6cf877b592b1c",
      "platform": {
        "os": "linux",
        "architecture": "arm64",
        "variant": "v8"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1951,
      "digest": "sha256:60f84cc8a1e4afa08c901b307b2aba8ae34ee088b92659114038660840eeac4a",
      "platform": {
        "os": "linux",
        "architecture": "arm",
        "variant": "v7"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1951,
      "digest": "sha256:3791cb6581d68b72be439062377c67e16a21110cf68d9114e5384a510cacc159",
      "platform": {
        "os": "linux",
        "architecture": "s390x"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1951,
      "digest": "sha256:8edfd8cf3c82045c05763cb2d25c0f421ccce218b69440190870a5d821fb8f95",
      "platform": {
        "os": "linux",
        "architecture": "ppc64le"
      }
    }
  ]
}

application/vnd.oci.image.index.v1+json précise que le format OCI pour décrire les index d’image est utilisé (et non le format Docker).

Il y a plusieurs manifests car l’image est multi architectures.

Prenons l’image arm64, par ce que le arm64, c’est chic, et allons chercher son manifest. Pour ne pas risquer une confusion avec un tag, on préfixe avec le type de hachage. On notera que cette fois ci, le json n’est pas indenté, tache dont s’acquitte très bien jq.

curl -L --silent gcr.io/v2/distroless/static-debian12/manifests/sha256:7866c847208413c5f8c6c9fa1c78dca9421f6deb1c553c8384d6cf877b592b1c | jq .

{
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 1870,
    "digest": "sha256:1dcec56bafe5a886201f3011e859f9e95086aee5e19faf08fcbbd3ae46de18f4"
  },
  "layers": [
    {
      "digest": "sha256:8398841c83114be91a2fb43e384042528a6d82580f0ff857997dfa7090bda899",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 104183
    },
    {
      "digest": "sha256:2b776ada03417eaa87102a617f964324df1de8967698fc4209dc1a1fbdfae8cd",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 13384
    },
    {
      "digest": "sha256:2a977872b36c1a2309fac8bd22b0fa0b3ee6efd1a25af5016ee9409beca1b3cf",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 537713
    },
    {
      "digest": "sha256:b6824ed73363f94b3b2b44084c51c31bc32af77a96861d49e16f91e3ab6bed71",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 67
    },
    {
      "digest": "sha256:7c12895b777bcaa8ccae0605b4de635b68fc32d60fa08f421dc3818bf55ee212",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 188
    },
    {
      "digest": "sha256:33e068de264953dfdc9f9ada207e76b61159721fd64a4820b320d05133a55fb8",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 122
    },
    {
      "digest": "sha256:5664b15f108bf9436ce3312090a767300800edbbfd4511aa1a6d64357024d5dd",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 168
    },
    {
      "digest": "sha256:27be814a09ebd97fac6fb7b82d19f117185e90601009df3fbab6f442f85cd6b3",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 93
    },
    {
      "digest": "sha256:4aa0ea1413d37a58615488592a0b827ea4b2e48fa5a77cf707d0e35f025e613f",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 385
    },
    {
      "digest": "sha256:da7816fa955ea24533c388143c78804c28682eef99b4ee3723b548c70148bba6",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 321
    },
    {
      "digest": "sha256:9aee425378d2c16cd44177dc54a274b312897f5860a8e78fdfda555a0d79dd71",
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 130495
    }
  ],
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "schemaVersion": 2
}

Cette fois ci, on a des couches d’image OCI sous forme de tar compressé avec gzip : application/vnd.oci.image.layer.v1.tar+gzip.

La description des couches se trouve dans base/base.bzl

tars = [
   deb.package(arch, distro, "base-files"),
   deb.package(arch, distro, "netbase"),
   deb.package(arch, distro, "tzdata"),
   "//common:rootfs",
   "//common:passwd",
   "//common:home",
   "//common:group",
   # Create /tmp, too many things assume it exists.
   # tmp.tar has a /tmp with the correct permissions 01777
   "//common:tmp",
   ":nsswitch.tar",
   "//common:os_release_" + distro,
   "//common:cacerts_" + distro + "_" + arch,
]

On notera que les couches toutes petites contiennent de la conf, et sont les mêmes, indépendamment de l’architecture. Bricolez la commande curl pour le vérifier, c’est instructif.

Une convention de nommage, un peu crado, permet de créer l’url de l’attestation d’une image : il faut ajouter .att à la fin, et surtout remplacer le : qui sépare le type de hachage de sa valeur, par un -. Une convention similaire permet de trouver la signature, avec le suffixe .sig.

curl -L --silent gcr.io/v2/distroless/static-debian12/manifests/sha256-7866c847208413c5f8c6c9fa1c78dca9421f6deb1c553c8384d6cf877b592b1c.att | jq .

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 243,
    "digest": "sha256:1f3ca242c4197b2abe2db3f9d162b4719fccd6261e2b45819c9d51361f340b8a"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dsse.envelope.v1+json",
      "size": 12944,
      "digest": "sha256:c42ef2b6fa9e3d15aad198c23a147bc2fbc474af3c607ffe05ef5e934cb7d977",
      "annotations": {
        "dev.cosignproject.cosign/signature": "",
        "dev.sigstore.cosign/bundle": "{\"SignedEntryTimestamp\":\"MEUCIAz/DSGCZlu0Zm/sN4BJf4MmEzLnZFANmlHy50k8I/bhAiEAj8keEKbxX/VYZAfjZIsgbMkGDRlo+yO+j/3Skmgh/qY=\",\"Payload\":{\"body\":\"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaW50b3RvIiwic3BlYyI6eyJjb250ZW50Ijp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiJjNDJlZjJiNmZhOWUzZDE1YWFkMTk4YzIzYTE0N2JjMmZiYzQ3NGFmM2M2MDdmZmUwNWVmNWU5MzRjYjdkOTc3In0sInBheWxvYWRIYXNoIjp7ImFsZ29yaXRobSI6InNoYTI1NiIsInZhbHVlIjoiNDU1OTc4MDgyNDU0OGRlNDM5NzdlZDJhN2Q2NGE2YWQ1MDA4OTgwZTcxY2Q5ZDBmN2Y2NzBmMTU2YWM3MjIyYyJ9fSwicHVibGljS2V5IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVTTBla05EUVcxcFowRjNTVUpCWjBsVlUyNWxaVFYyWTBSUVIzSnpTa2h4SzIxcmFVUTBjbTVRWkdjd2QwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcFJkMDE2UlhoTlZHTXhUMVJGTUZkb1kwNU5hbEYzVFhwRmVFMVVaM2RQVkVVd1YycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVU0ZFM5SmVrMHZkVlp5YjB4cGFGTmpiVzQzV1dKaGJuRkZVVWxyVWpKeU9HNDRXbFVLY1ZsbVJrTmFaaTlaV1ZoT1RtdDBMMDh6VEVvcmJURmpTRlpJWjBoR2IwVlNZamxVZVdrd1pUaGpXRGRTZGxGblZqWlBRMEZaWTNkblowZEVUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZPU3k4d0NrcE9SR1V4TUc5SU5VUjZhMGRPVW5sT1oyMU1abUpOZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDA5QldVUldVakJTUVZGSUwwSkROSGRNU1VWeFlUSldOV0pIVm5wak1FSnJZVmhPTUdOdE9YTmFXRTU2VEcxc2FHSlROVzVqTWxaNVpHMXNhZ3BhVjBacVdUSTVNV0p1VVhWWk1qbDBUVU5yUjBOcGMwZEJVVkZDWnpjNGQwRlJSVVZITW1nd1pFaENlazlwT0haWlYwNXFZak5XZFdSSVRYVmFNamwyQ2xveWVHeE1iVTUyWWxSQmNrSm5iM0pDWjBWRlFWbFBMMDFCUlVsQ1FqQk5SekpvTUdSSVFucFBhVGgyV1ZkT2FtSXpWblZrU0UxMVdqSTVkbG95ZUd3S1RHMU9kbUpVUTBKcFVWbExTM2RaUWtKQlNGZGxVVWxGUVdkU04wSklhMEZrZDBJeFFVNHdPVTFIY2tkNGVFVjVXWGhyWlVoS2JHNU9kMHRwVTJ3Mk5Bb3phbmwwTHpSbFMyTnZRWFpMWlRaUFFVRkJRbXBwTm5KTlExRkJRVUZSUkVGRldYZFNRVWxuU1ZSWFkwOU5VbWhJVUdScmJtcEdZV2wwWVZaUlJ5OTVDbFZuVFVSR05XRTNlVWxWT1hSaEsya3pRbEZEU1VoMUwxcHRZemRLY0hSSmJ6bDFNRGxKWjBKd2VEUXdhMFYyT1ZjMk9XOU1NRU5sU2xKcmNucEhkSGdLVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZEVDJob2NUZGhMM1F2TXpKS05EWnZMMmx0WmtjcmVIWkhlbEp0UWxWQllubFFjbVJFYXdwT1dVRnVVa3gwYVZoWWRHaFRhRkJHTTAxc1NtdGtaRmR4YjJ0RFRWRkRUR05uUVRNdlIycFRTakJvUkVSeE9GQkNNMnBvWkcwM1pFbHBhMlF6TUdGMUNrSTVNMVpFUzJGSWJXNWpjSEIwTW05a2NucElWRkU1U21sNE4zUnBUMmM5Q2kwdExTMHRSVTVFSUVORlVsUkpSa2xEUVZSRkxTMHRMUzBLIn19\",\"integratedTime\":1710179954,\"logIndex\":77294834,\"logID\":\"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d\"}}",
        "dev.sigstore.cosign/certificate": "-----BEGIN CERTIFICATE-----\nMIIC4zCCAmigAwIBAgIUSnee5vcDPGrsJHq+mkiD4rnPdg0wCgYIKoZIzj0EAwMw\nNzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl\ncm1lZGlhdGUwHhcNMjQwMzExMTc1OTE0WhcNMjQwMzExMTgwOTE0WjAAMFkwEwYH\nKoZIzj0CAQYIKoZIzj0DAQcDQgAE8u/IzM/uVroLihScmn7YbanqEQIkR2r8n8ZU\nqYfFCZf/YYXNNkt/O3LJ+m1cHVHgHFoERb9Tyi0e8cX7RvQgV6OCAYcwggGDMA4G\nA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUNK/0\nJNDe10oH5DzkGNRyNgmLfbMwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y\nZD8wOAYDVR0RAQH/BC4wLIEqa2V5bGVzc0BkaXN0cm9sZXNzLmlhbS5nc2Vydmlj\nZWFjY291bnQuY29tMCkGCisGAQQBg78wAQEEG2h0dHBzOi8vYWNjb3VudHMuZ29v\nZ2xlLmNvbTArBgorBgEEAYO/MAEIBB0MG2h0dHBzOi8vYWNjb3VudHMuZ29vZ2xl\nLmNvbTCBiQYKKwYBBAHWeQIEAgR7BHkAdwB1AN09MGrGxxEyYxkeHJlnNwKiSl64\n3jyt/4eKcoAvKe6OAAABji6rMCQAAAQDAEYwRAIgITWcOMRhHPdknjFaitaVQG/y\nUgMDF5a7yIU9ta+i3BQCIHu/Zmc7JptIo9u09IgBpx40kEv9W69oL0CeJRkrzGtx\nMAoGCCqGSM49BAMDA2kAMGYCMQCOhhq7a/t/32J46o/imfG+xvGzRmBUAbyPrdDk\nNYAnRLtiXXthShPF3MlJkddWqokCMQCLcgA3/GjSJ0hDDq8PB3jhdm7dIikd30au\nB93VDKaHmncppt2odrzHTQ9Jix7tiOg=\n-----END CERTIFICATE-----\n",
        "dev.sigstore.cosign/chain": "-----BEGIN CERTIFICATE-----\nMIICGjCCAaGgAwIBAgIUALnViVfnU0brJasmRkHrn/UnfaQwCgYIKoZIzj0EAwMw\nKjEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MREwDwYDVQQDEwhzaWdzdG9yZTAeFw0y\nMjA0MTMyMDA2MTVaFw0zMTEwMDUxMzU2NThaMDcxFTATBgNVBAoTDHNpZ3N0b3Jl\nLmRldjEeMBwGA1UEAxMVc2lnc3RvcmUtaW50ZXJtZWRpYXRlMHYwEAYHKoZIzj0C\nAQYFK4EEACIDYgAE8RVS/ysH+NOvuDZyPIZtilgUF9NlarYpAd9HP1vBBH1U5CV7\n7LSS7s0ZiH4nE7Hv7ptS6LvvR/STk798LVgMzLlJ4HeIfF3tHSaexLcYpSASr1kS\n0N/RgBJz/9jWCiXno3sweTAOBgNVHQ8BAf8EBAMCAQYwEwYDVR0lBAwwCgYIKwYB\nBQUHAwMwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU39Ppz1YkEZb5qNjp\nKFWixi4YZD8wHwYDVR0jBBgwFoAUWMAeX5FFpWapesyQoZMi0CrFxfowCgYIKoZI\nzj0EAwMDZwAwZAIwPCsQK4DYiZYDPIaDi5HFKnfxXx6ASSVmERfsynYBiX2X6SJR\nnZU84/9DZdnFvvxmAjBOt6QpBlc4J/0DxvkTCqpclvziL6BCCPnjdlIB3Pu3BxsP\nmygUY7Ii2zbdCdliiow=\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIB9zCCAXygAwIBAgIUALZNAPFdxHPwjeDloDwyYChAO/4wCgYIKoZIzj0EAwMw\nKjEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MREwDwYDVQQDEwhzaWdzdG9yZTAeFw0y\nMTEwMDcxMzU2NTlaFw0zMTEwMDUxMzU2NThaMCoxFTATBgNVBAoTDHNpZ3N0b3Jl\nLmRldjERMA8GA1UEAxMIc2lnc3RvcmUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAT7\nXeFT4rb3PQGwS4IajtLk3/OlnpgangaBclYpsYBr5i+4ynB07ceb3LP0OIOZdxex\nX69c5iVuyJRQ+Hz05yi+UF3uBWAlHpiS5sh0+H2GHE7SXrk1EC5m1Tr19L9gg92j\nYzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRY\nwB5fkUWlZql6zJChkyLQKsXF+jAfBgNVHSMEGDAWgBRYwB5fkUWlZql6zJChkyLQ\nKsXF+jAKBggqhkjOPQQDAwNpADBmAjEAj1nHeXZp+13NWBNa+EDsDP8G1WWg1tCM\nWP/WHPqpaVo0jhsweNFZgSs0eE7wYI4qAjEA2WB9ot98sIkoF3vZYdd3/VtWB5b9\nTNMea7Ix/stJ5TfcLLeABLE4BNJOsQ4vnBHJ\n-----END CERTIFICATE-----",
        "predicateType": "https://spdx.dev/Document"
      }
    }
  ]
}

L’attestation contient des layers, comme une image, il ne faut pas se laisser distraire par la quantité d’annotations utilisée par la signature de cosign. Si il y a des layers, c’est qu’il y a des blobs (un layer et un blob, en l’occurrence).

curl -L --silent gcr.io/v2/distroless/static-debian12/blobs/sha256:c42ef2b6fa9e3d15aad198c23a147bc2fbc474af3c607ffe05ef5e934cb7d977 | jq .

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjAuMSIsInByZWRpY2F0ZVR5c
  […]
  uc2hpcFR5cGVcIjpcIkRFUEVORFNfT05cIn1dfSJ9",
  "signatures": [
    {
      "keyid": "",
      "sig": "MEUCIEdF83LnL01ToM4pkDvgnMkqvzRHwT3viDb/bOhqYA1JAiEAlgZR0Lei6lng9itoHr/Iw1xMllI67DngGtyg0o+hP4A="
    }
  ]
}

On a un document in-toto avec un gros paté en base64 (que je n’affiche que partiellement), que jq va traiter pour nous.

$ curl -L --silent gcr.io/v2/distroless/static-debian12/blobs/sha256:c42ef2b6fa9e3d15aad198c23a147bc2fbc474af3c607ffe05ef5e934cb7d977 | jq '.payload|@base64d|fromjson'

On obtient un prédicat de type https://spdx.dev/Document, le sujet qui désigne l’image, avec un hash pour préciser la version. Le corps du prédicat, qui contient le SPDX attendu est sous forme de json dans du json (sans base64 cette fois ci).

$ curl -L --silent gcr.io/v2/distroless/static-debian12/blobs/sha256:c42ef2b6fa9e3d15aad198c23a147bc2fbc474af3c607ffe05ef5e934cb7d977 | jq '.payload|@base64d|fromjson|.predicate|fromjson'

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "//base:static_root_arm64_debian12",
  "documentNamespace": "http://spdx.org/spdxdocs/distroless/-slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
  "creationInfo": {
    "licenseListVersion": "NOASSERTION",
    "creators": ["Organization: distroless"],
    "created": "1970-01-01T00:00:00Z"
  },
  "packages": [
    {
      "name": "//base:static_root_arm64_debian12",
      "SPDXID": "SPDXRef--slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
      "downloadLocation": "NOASSERTION",
      "copyrightText": "NOASSERTION"
    },
    {
      "name": "base-files",
      "SPDXID": "SPDXRef-arm64-underscore-debian12-underscore-base-files",
      "versionInfo": "12.4+deb12u5",
      "supplier": "Person: Santiago Vila \\u003csanvila@debian.org\\u003e",
      "downloadLocation": "https://snapshot-cloudflare.debian.org/archive/debian/20240210T223313Z/pool/main/b/base-files/base-files_12.4+deb12u5_arm64.deb",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "ca5e69b38214de267d7d59bf4d0c1abd10987abacb5c9bfaf72b178bee883d1b"
        }
      ],
      "copyrightText": "This is the Debian prepackaged version of the Debian Base System\nMiscellaneous files. These files were written by Ian Murdock\n<imurdock@debian.org> and Bruce Perens <bruce@pixar.com>.\n\nThis package was first put together by Bruce Perens <Bruce@Pixar.com>,\nfrom his own sources.\n\nThe GNU Public Licenses in /usr/share/common-licenses were taken from\nftp.gnu.org and are copyrighted by the Free Software Foundation, Inc.\n\nThe Artistic License in /usr/share/common-licenses is the one coming\nfrom Perl and its SPDX name is \"Artistic License 1.0 (Perl)\".\n\n\nCopyright (C) 1995-2011 Software in the Public Interest.\n\nThis program is free software; you can redistribute it and/or modify\nit under the terms of the GNU General Public License as published by\nthe Free Software Foundation; either version 2 of the License, or\n(at your option) any later version.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nOn Debian systems, the complete text of the GNU General\nPublic License can be found in `/usr/share/common-licenses/GPL'.\n",
      "summary": "Debian base system miscellaneous files",
      "description": "Debian base system miscellaneous files\nThis package contains the basic filesystem hierarchy of a Debian system, and\nseveral important miscellaneous files, such as /etc/debian_version,\n/etc/host.conf, /etc/issue, /etc/motd, /etc/profile, and others,\nand the text of several common licenses in use on Debian systems.",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:deb/debian/base-files@12.4+deb12u5?arch=arm64"
        }
      ]
    },
    {
      "name": "@arm64_debian12_base-files//:spdx",
      "SPDXID": "SPDXRef--at-arm64-underscore-debian12-underscore-base-files-slash--slash--colon-spdx",
      "downloadLocation": "NOASSERTION",
      "copyrightText": "NOASSERTION",
      "description": "Generated from base-files@12.4+deb12u5"
    },
    {
      "name": "netbase",
      "SPDXID": "SPDXRef-arm64-underscore-debian12-underscore-netbase",
      "versionInfo": "6.4",
      "supplier": "Person: Marco d'Itri \\u003cmd@linux.it\\u003e",
      "downloadLocation": "https://snapshot-cloudflare.debian.org/archive/debian/20240210T223313Z/pool/main/n/netbase/netbase_6.4_all.deb",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "29b23c48c0fe6f878e56c5ddc9f65d1c05d729360f3690a593a8c795031cd867"
        }
      ],
      "copyrightText": "Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/\nComment:\n This package was created by Peter Tobias tobias@et-inf.fho-emden.de on\n Wed, 24 Aug 1994 21:33:28 +0200 and maintained by Anthony Towns\n <ajt@debian.org> until 2001.\n It is currently maintained by Marco d'Itri <md@linux.it>.\n\nFiles: *\nCopyright:\n Copyright (c) 1994-1998 Peter Tobias\n Copyright (c) 1998-2001 Anthony Towns\n Copyright (c) 2002-2022 Marco d'Itri\nLicense: GPL-2\n This program is free software; you can redistribute it and/or modify\n it under the terms of the GNU General Public License, version 2, as\n published by the Free Software Foundation.\n .\n This program is distributed in the hope that it will be useful,\n but WITHOUT ANY WARRANTY; without even the implied warranty of\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n GNU General Public License for more details.\n .\n You should have received a copy of the GNU General Public License along\n with this program; if not, write to the Free Software Foundation,\n Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.\n .\n On Debian systems, the complete text of the GNU General Public License\n version 2 can be found in '/usr/share/common-licenses/GPL-2'.\n",
      "summary": "Basic TCP/IP networking system",
      "description": "Basic TCP/IP networking system\nThis package provides the necessary infrastructure for basic TCP/IP based\nnetworking.\n.\nIn particular, it supplies common name-to-number mappings in /etc/services,\n/etc/rpc, /etc/protocols and /etc/ethertypes.",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:deb/debian/netbase@6.4?arch=all"
        }
      ]
    },
    {
      "name": "@arm64_debian12_netbase//:spdx",
      "SPDXID": "SPDXRef--at-arm64-underscore-debian12-underscore-netbase-slash--slash--colon-spdx",
      "downloadLocation": "NOASSERTION",
      "copyrightText": "NOASSERTION",
      "description": "Generated from netbase@6.4"
    },
    {
      "name": "tzdata",
      "SPDXID": "SPDXRef-arm64-underscore-debian12-underscore-tzdata",
      "versionInfo": "2024a-0+deb12u1",
      "supplier": "Person: GNU Libc Maintainers \\u003cdebian-glibc@lists.debian.org\\u003e",
      "downloadLocation": "https://snapshot-cloudflare.debian.org/archive/debian/20240210T223313Z/pool/main/t/tzdata/tzdata_2024a-0+deb12u1_all.deb",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "0ca0baec1fca55df56039047a631fc1541c5a44c1c4879d553aaa3a70844eb12"
        }
      ],
      "homepage": "https://www.iana.org/time-zones",
      "copyrightText": "Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/\nSource: https://www.iana.org/time-zones\nUpstream-Contact: The Internet Assigned Numbers Authority (IANA)\n                  Commentary should be addressed to tz@iana.org\n\nFiles: *\nCopyright: The Internet Assigned Numbers Authority (IANA)\nLicense: public-domain\n This database is in the public domain.\n",
      "summary": "time zone and daylight-saving time data",
      "description": "time zone and daylight-saving time data\nThis package contains data required for the implementation of\nstandard local time for many representative locations around the\nglobe. It is updated periodically to reflect changes made by\npolitical bodies to time zone boundaries, UTC offsets, and\ndaylight-saving rules.",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:deb/debian/tzdata@2024a-0+deb12u1?arch=all"
        }
      ]
    },
    {
      "name": "@arm64_debian12_tzdata//:spdx",
      "SPDXID": "SPDXRef--at-arm64-underscore-debian12-underscore-tzdata-slash--slash--colon-spdx",
      "downloadLocation": "NOASSERTION",
      "copyrightText": "NOASSERTION",
      "description": "Generated from tzdata@2024a-0+deb12u1"
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relatedSpdxElement": "SPDXRef--slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
      "relationshipType": "DESCRIBES"
    },
    {
      "spdxElementId": "SPDXRef--at-arm64-underscore-debian12-underscore-base-files-slash--slash--colon-spdx",
      "relatedSpdxElement": "SPDXRef-arm64-underscore-debian12-underscore-base-files",
      "relationshipType": "GENERATED_FROM"
    },
    {
      "spdxElementId": "SPDXRef--slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
      "relatedSpdxElement": "SPDXRef--at-arm64-underscore-debian12-underscore-base-files-slash--slash--colon-spdx",
      "relationshipType": "DEPENDS_ON"
    },
    {
      "spdxElementId": "SPDXRef--at-arm64-underscore-debian12-underscore-netbase-slash--slash--colon-spdx",
      "relatedSpdxElement": "SPDXRef-arm64-underscore-debian12-underscore-netbase",
      "relationshipType": "GENERATED_FROM"
    },
    {
      "spdxElementId": "SPDXRef--slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
      "relatedSpdxElement": "SPDXRef--at-arm64-underscore-debian12-underscore-netbase-slash--slash--colon-spdx",
      "relationshipType": "DEPENDS_ON"
    },
    {
      "spdxElementId": "SPDXRef--at-arm64-underscore-debian12-underscore-tzdata-slash--slash--colon-spdx",
      "relatedSpdxElement": "SPDXRef-arm64-underscore-debian12-underscore-tzdata",
      "relationshipType": "GENERATED_FROM"
    },
    {
      "spdxElementId": "SPDXRef--slash--slash-base-colon-static-underscore-root-underscore-arm64-underscore-debian12",
      "relatedSpdxElement": "SPDXRef--at-arm64-underscore-debian12-underscore-tzdata-slash--slash--colon-spdx",
      "relationshipType": "DEPENDS_ON"
    }
  ]
}

On notera que SPDX reprend le principe des triplets de RDF qui, promis juré, devait servir de base au web 3.0. Ces relationships décrivent un graphe avec des liaisons nommées (et des noms de nodes rigolos, un genre d’échappement littéral).

On notera aussi que le moulinage des informations issus des paquets Debian ont des soucis bizzaries d’UTF8 avec des \\u003c et des \\u003e.

Le SPDX permet de désigner tous les paquets utilisés, avec leur version, leur URL figée dans le temps, et le nom du responsable. Tout ce qu’il faut pour lancer une moulinette de chasse au CVE, pour mettre à jour la couche impactée sans devoir refaire les couches supérieures.

Outils pour gérer les images de conteneur

C’est instructif de manipuler les images avec curl et jq, mais il existe aussi des outils civilisés pour manipuler des registres d’images de conteneur : crane ou skopeo.

Pour vérifier les signatures des images, l’outil de référence est cosign.

Autres projets d’images minimalistes

Wolfi

Chainguard, les gens qui participent au développement de sigstore, propose Wolfi, une distribution Linux basée sur apk (comme Alpine), mais avec glibc, ciblant uniquement les conteneurs, et donc sans kernel, sans init.

Les images de base Wolfi peuvent s’utiliser “comme avant”, avec un Dockerfile et apk, comme on le ferait avec une image Alpine.

Les avant-gardistes, eux, construiront leurs images Wolfi avec apko

Apko

Apko est un outil minimaliste écrit en go, utilisable depuis un conteneur ou depuis un OS (Linux ou non), qui va créer l’archive (multi architecture) d’une image de conteneur et plein de SBOMs, à partir d’un YAML et d’un dépôt apk. Apko peut même pousser l’image dans un registre.

Comme Apko est un rebelle, il peut créer des fat containers avec s6 comme init.

Apko se fiche de Wolfi, de Alpine, de Bazel, de Docker, de Podman, de Containerd, de Kubernetes et de plein d’autres choses. Mais comme il est poli, il sait aussi bosser avec eux.

Apko fait des builds déterministes, multi architecture, et donc ne lance pas de commandes pendant le build. En bon monomaniaque, Apko mise tout sur apk, et donc pousse a utiliser son projet melange pour créer les apk qui seront utilisés par Apko. Ou vous pouvez truander avec un Dockerfile, à l’ancienne.

Melange

Melange est un autre projet de Chainguard pour créer des paquets apk multi architectures à partir d’un incontournable YAML. Pour être utilisé hors des Linux basés sur apk, Chainguard a réimplementé apk en go.

Le projet est tout frais (en version 0.6), peu documenté, mais prometeur,actif depuis 2 ans, avec une belle liste de pull requests.

La création pour les architectures non-natives passe par binfmt_misc qui s’appuie sur qemu.

Les builds classiques sont gérés (cargo, rust, npm, make install …), et il est même possible de créer un build Melange à partir d’un projet ruby, python ou apk.

Le code parle de conteneurs Docker/k8s/dagger/bubblewrap mais pas la documentation. Pour les développeurs Mac, il y a une intégration à Lima.

Les builds simples tombent en marche, de manière assez magique, mais j’attends une bonne bagarre avec le débug d’un build qui ne passe pas pour avoir un avis plus affirmé.

Chainguard croit très fort à apk comme artéfact universel, brique de base pour composer un conteneur.

Ko

Golang est le “fruit bas” des langages à déployer dans un conteneur. Golang crée un gros binaire statique, et peut cross-compiler très simplement.

Google a crée ko, avant de lui dédier son propre groupe dans Github et de postuler comme projet CNCF (il est niveau “bac à sable” pour l’instant).

On retrouve les arguments du moment : build natif, SBOM, YAML, publication dans un registre.

Dans les pinaillages, Ko recommande de ne pas pas utiliser cgo, et demande à ce que les éventuelles dépendances soient fournies dans l’image de base. Par contre, Ko sait déployer des assets.

Jib

Jib, du même Google, permet de créer des images de conteneurs à partir de projets Java.

Jib a la tâche encore plus facile que Ko, Java est par principe multi architectures. L’image de base est OpenJDK, mais il est possible de paramétrer ce choix.

Jib est une extension pour Maven ou Gradle, ou s’utilise comme outil indépendant et il n’utilise pas de conteneur.

Tout le travail de Jib est de déposer les différents jar sur différentes couches d’images de conteneurs, et lors d’un nouveau build de l’application, seuls les jar modifiés seront redéployés sur leur couche respective.

La suite

L’OCI continue de taper sur Docker pour lui expliquer la différence entre implémentation et spécification.

Des fois, c’est de mauvaise foi (à chaque fois que Redhat vante son écosystème concurrent), souvent c’est justifié. L’absence de marché clair pour Docker inc est triste, et la constance de Docker Desktop a demandé des sous (l’achat d’une licence) sur presque toutes les nouvelles commandes n’améliore pas leur karma.

Le Dockerfile reste le format standard et universel pour créer des conteneurs, mais la norme est le format de l’image. Il est normal de pouvoir créer une image de conteneur comme on le souhaite (comme umoci le propose), et d’explorer d’autres pistes. Il est par exemple intéressant de pouvoir travailler couche par couche pour composer une image, en ne changeant que ce qu’il y a de nouveau. La gestion des architectures multiples est une vraie question auquel Docker ne répond que partiellement.

Pouvoir débuguer en local/staging est normal, mais l’outillage doit être différent en production. Vous n’avez pas forcément la main sur le nombre d’instances de votre conteneur, il y a peu de chance que vous y ayez un accès privilégié, et vous n’allez pas attendre que l’incident revienne.

La généralisation des traces et des journaux structurés sont là depuis longtemps et maintenant indispensable. La vague ebpf prolonge ce mouvement et va offrir plus de visibilité sur le comportement des applications en production.

Les offres d’hébergement de conteneur de haut niveau, comme Fly.io propose une interface simple et va masquer les détails d’implémentation, pour plutôt proposer une intégration fine avec un ensemble de services pour le client ou le développeur.

Le postulat d’Heroku est toujours valide : “tu git push, ça finit en prod”, sauf que maintenant c’est explicite, normalisé, et sécurisé.

Campagne internationale pour la sécurité informatique : sécuriser la chaine d’approvisionement

2024-03-18T09:04:00+01:00

Campagne internationale pour la sécurité informatique

Il y a quelques jours, la Maison-Blanche demande un audit sur la sécurité de ses logiciels, tout en reconnaissant l’utilisation massive (et indispensable) de l’écosystème open source pour les services de l’État.

Le sujet de l’audit est large (et très technique), et a pour objectif d’améliorer drastiquement la sécurité des logiciels. Les pistes sont bien connues, mais là, c’est écrit noir sur blanc par la Maison-Blanche.

Sécurisation des fournisseurs de paquets (logiciels et bibliothèques)
Mis en place d’outils pour quantifier la qualité et la sécurité du code
Remplacement des logiciels codé avec des langages sans gestion stricte de la mémoire (memory safe).

Github fournit des outils sur ce thème depuis quelque temps, aucune surprises, mais entendre le président des États-Unis dauber sur le C/C++, c’est une première. Oui, le document de la Maison-Blanche cite le nom de Biden à tour de bras, j’imagine que c’est l’usage dans ce pays, mais hors US, on a l’impression que c’est une attaque personnelle.

Le document est plein d’intentions, on attend le résultat de l’audit pour avoir des éléments concrets, mais il contient quand même plein de liens bien plus concrets comme une roadmap sur la sécurité open source

Comme le sujet est touffu, et plein d’acronymes, le billet sera coupé en trois, en suivant le découpage de la Maison-Blanche :

Sécuriser la chaine d’approvisionnement (ce billet)
Quantifier la qualité du code
Protéger l’accès à la mémoire

Dépendances logicielles

Une application est composée de code pris sur l’étagère, sous forme de source ou de paquets (gros binaire, paquet système, image Docker…) ou de code développé maison qui va utiliser des bibliothèques existantes.

Pour ne pas réinventer la roue (et la maintenir), une application va dépendre de paquets (au sens large) gérés par des tiers.

C’est un des aspects principaux de l’open source.

Le sujet est pris en main par la Linux Foundation, via l’Opensource Security Foundation, via Alpha-Omega fondé par les gros du cloud (Amazon, Google et Microsoft) pour supporter les outils essentiels de l’open source, du début à la fin (la ref ⍺ - Ω, vous l’avez?).

Les cascades de fondations et de comités, avec pour l’instant des zones floues ou redondantes, laissent présager moult réunions et visioconférences. Mais trêve de mauvaise langue, ils ont déjà produit des choses concrètes : code, données et financement de projets existants. L’adoubement de la fondation Linux devrait calmer la fascination de la dispersion et des projets qui n’aboutissent jamais.

Chaine d’approvisionnement

Gérer la dépendance à des produits tiers se joue sur la durée, il peut se passer plein de choses durant ce voyage.

Failles officielles

Découvrir une chouette faille de sécurité est un titre de gloire, surtout si ça permet de faire des choses créatives et imprévues.

Pour éviter les doublons et pour que tout le monde parle de la même chose, l’usage est d’enregistrer sa vulnérabilité auprès de CVE, Common Vulnerabilities and Exposures géré par l’organisme Mitre, soutenu par le département de la sécurité intérieure des Etats-Unis. CVE est le standard de fait, mais sa gestion est problématique, cf Curl conteste certains de ses CVEs. L’API de CVE est peu pratique, et ses données, très peu formatées, sont dures à exploiter.

L’OpenSSF propose un nouveau format, développé conjointement avec la communauté open source : l’OSV (pour Open Source Vulnerability).

Les paquets sont identifiés par un écosystème (le dépôt officiel), un nom et une version, ou directement par un commit hash.

OSV agrège de multiples sources.

OSV fournit une API REST et un cli (en go) qui sait lire la liste de dépendances gelées de différents formats ainsi que les listes de paquets installés de Alpine ou Debian, les images Docker basées sur Debian.

Tout l’outillage d’OSV est lié à GCE, avec des services pénibles comme AppEngine, ou l’utilisation de GCS (du S3, quoi) comme source. La documentation ressemble à un publireportage GCE, ce qui est dommage. D’un autre côté, proposer un schéma de table, agréger les failles, lire des listes de paquets n’est pas un challenge technique, mais surtout un travail politique pour convaincre et devenir la référence.

Paquets malhonnêtes

Au-delà des failles (involontaires), il existe aussi des paquets volontairement dangereux qui peuvent faire par exemple ce genre de choses.

Le projet package-analysis effectue l’analyse dynamique de paquet, en le lançant dans un environnement isolé ( gVisor, un conteneur paranoïaque, pour observer les fichiers qu’il tripote, les adresses où il se connecte.

Les paquets scélérats, compromis, ou avec des noms trompeurs (aka typosquatting) sont répertoriés par le projet malicious-packages pour créer des OSV.

Paquets de confiance

Il arrive qu’un paquet légitime soit corrompu durant son cycle de vie.

L’attaque peut être effectuée à différents niveaux.

Des patchs malicieux peuvent être proposés, prétendant améliorer un point alors qu’il en fragilise un autre. Un étudiant a réussi à faire passer un patch malicieux dans le kernel Linux avant de s’en vanter. Sa fac, l’université du Minnesota, s’est fait bannir avec lui.
En truandant l’authentification d’un mainteneur, il est possible de publier une version scélérate d’un paquet sur un dépôt.
Via l’intégration continue, il est possible de modifier ou de publier des bêtises.
Il est tentant de modifier le cache d’un dépôt, bien que les signatures soit censées empêcher ce genre d’attaque.

Dépôts pour bibliothèques de langage

Les langages disposent de bibliothèques de code disponibles via des dépôts spécifiques.

La sensibilisation à la sécurité pour la publication de bibliothèque a été bien trop tardive. Même si la possibilité de signer un paquet est arrivé tôt, sans prosélytisme, ça a eut du mal à prendre, et il faut une chaine de confiance, de bout en bout, pour que ce soit utilisable.

Python Pypi

Dans leur liste de diffusion, les paqueteurs Python évoquent le drame du faible taux de signature en 2016, de toute façons, seul le format binaire, les whl, gèrent les signatures.

Python a des spécifications pour l’empaquetage, Pypa, un hangar qui progresse bien, Warehouse, mais côté client, c’est très confus.

Il y a plusieurs formats pour définir les dépendances, rien de bien précis pour le verrouillage, que n’utilise pas l’outil par défaut, pip. Les challengers, poetry et unearth manquent d’ambitions, alors que uv rêve de la perfection de rust.

Plutôt que de batailler avec des clés de développeurs, Python se dirige vers la notion de diffuseur de confiance. On indique à Pypi qu’un build précis d’une CI (projet, branche…) est de confiance. La CI va publier vers Pypi l’artéfact, avec le token OIDC contenant les détails du build, si le token est valide, et si les détails correspondent à ce qui a été paramétré, Pypi accepte l’artéfact.

Même si cette approche semble simple, fonctionne pour une personne ou une CI, elle ne survit pas à la compromission du serveur Pypi, personne ne pourra savoir quels paquets ont été bidouillés.

Il faut que les paquets aient une signature auditable, qui soit faite en dehors du serveur Pypi.

Golang

Golang ne prévoit rien pour signer, il délègue toute la confiance au dépôt de source distant (Github, quoi). Par contre, Golang maintient une base de hash pour les différentes versions d’un paquet, avec un journal transparent, ce qui permet d’utiliser un miroir pour télécharger un paquet.

Les applications Golang sont livrées sous forme binaire, que vous pouvez signer de manière classique.

Ruby Gem

Ruby documente l’utilisation de certificat asymétrique avec ses gems mais avoue ne pas savoir comment gérer une chaine de confiance, et qu’ils en discutent.

Par contre, une gem peut faire confiance à une source OIDC avec l’exemple d’une action de la CI Github (et ils citent la documentation pypi pour comprendre le fonctionnement).

Même fragilité que Pypi en cas de compromission du serveur.

Node npm

Longtemps mauvais élève, Npm vante maintenant la notion de provenance avec Sigstore et propose de vérifier la signature du dépôt utilisé : npm audit signatures.

En signant les paquets en dehors du dépôt et en utilisant un journal public, ce que permet l’utilisation de Sigstore, le dépôt npm est moins fragile que pypi et rubygem.

Les concurrents de Nodejs ne sont pas très ambitieux sur la sécurité:

Rust crates

Pour l’instant, les paquets publiés sur crate.io ne sont pas signés, mais il y a en préparation une RFC pour intégrer Sigstore. La documentation parle d’intégration continue, mais pas de déploiement continu. Pour l’instant, crate.io authentifie les utilisateurs en OAuth2 avec Github, et permet la création de token pour publier, on a donc un lien entre un crate publié et un compte Github, mais c’est un peu peu.

Paquets Linux

La gestion de paquets des distributions Linux est mature depuis bien longtemps, et toutes gèrent les signatures (sauf Slackware).

La plupart des distributions utilisent gpg pour signer les paquets (sauf Alpine qui se distinguent avec de la clé openssl nue).

ArchLinux prend la peine d’établir un vraie rituel de signature :

5 clés maitres ont le pouvoir signer les clés des mainteneurs.
5 personnes détiennent une clé maitre ainsi que la clé de résiliation d’une autre clé maitre.
Une clé de mainteneur est légitime pour signer un paquet si elle est signée par au moins 3 clés maitres.

Les autres distributions se contentent de fournir un trousseau avec des personnes de confiance.

Même si les distributions Linux disposent d’une PKI pour signer leurs paquets, et empaquetent une partie des bibliothèques de langage, les paquets Linux ne sont pas utilisable pour développer des applications métiers.

Le cycle de vie d’un paquet Linux est lié à une version de la distribution, seuls les mises à jour de sécurité seront rétro-appliquées (backportées, quoi), les bugs fonctionnels resteront en l’état, et certaines distributions se permettent des patchs qui ne seront pas supportés par le mainteneur de la bibliothèque.
Une bibliothèque emballée dans un paquet Linux sera disponible dans une unique version majeure, utilisé par tous les paquets qui en ont besoin.
Même si les langages compilés modernes créent des binaires statiques, les paquets Linux doivent être reproductibles, et donc les bibliothèques des sources doivent être empaquetées. Cette règle empêche d’avoir des paquets officiels pour des applications agressives sur les versions de bibliothèques, comme Mongodb, Clickhouse ou même Nodejs.
Le vendoring, largement utilisé dans le développement contemporain, en gérant de manière isolée (et redondante) les dépendances logicielles est un tabou des distributions Linux. Il empêche la rationalisation et le travail de correction des mainteneurs.
Les formats de paquets historiques sont vieillissants, confus et la somme d’un empilement d’outils. Leur cout est négligeable par rapport à la valeur de la cohérence d’une distribution, mais hors de prix pour des applications métiers.
Les distributions Linux récentes sont tentées par la livraison continue, rolling release, sans jamais figer de version. Cette approche favorise la fraicheur des paquets, mais ne garanti plus la constance du comportement des applications ni même la possibilité d’avoir des mises à jour espacées dans le temps. Conçu pour les postes de travail, ce genre de distribution impose des stratégies de mises à jour rigoureuses sur un serveur, comme l’immutabilité

Paquets Linux universels

Fournir des paquets Linux pour un éditeur est une tannée.

En ciblant des serveurs, il est imaginable d’imposer des distributions majeures comme Redhat, Debian ou Ubuntu, mais pour des applications grand public, il y aura trop de variations possibles. S’ajoutent à ça les soucis de dépendances à des versions précises de bibliothèques.

Pour l’utilisateur, installer une application non disponible dans sa distribution, sans forcément avoir accès aux sources n’est pas une très bonne idée d’un point de vue sécurité. Un paquet Linux classique s’installe avec les droits de super utilisateur et fait bien ce qu’il veut.

Depuis l’avènement des conteneurs, Linux sait correctement isoler des applications, même si l’intégration à un bureau ne fait pas partie des objectifs d’un Docker (même si Jessfraz a relevé le challenge).

Freedesktop a effectué un travail de titan pour normaliser les points d’entrées d’un bureau Linux, permettant une intégration élégante d’applications disparates. Il faut donc que les applications, bien que bordées, puissent profiter de Freedesktop.

Flatpack

Flatpak se positionne comme solution universelle de déploiement d’application sur Linux.

Il s’appuie sur Bubble Wrap pour l’isolation (namespace et seccomp), cgroup étant géré par systemd.

Plutôt que de bricoler un chroot obèse comme image de base, FlatPack propose des runtimes qui seront mutualisés entre les différents paquets (et mis à jour indépendamment de l’application, en s’engageant à garder stable l’API).

Le dédoublonnage, et le versionnage des fichiers sont gérés par ostree.

Une liste compréhensible de droits permet de choisir ce que peut faire une application.

Pour les mises à jour, un outil permet de le faire en ligne de commande, ou un plugin permet à Flatpack de s’incruster dans le gestionnaire de paquets de Gnome.

Snap

Snap voit plus loin que le bureau Linux (il a été conçu pour l’IOT), mais son choix d’utiliser Apparmor brime la famille de distributions Linux qui activent SELinux automatiquement : Redhat (qui pousse Flatpack, le concurrent). SELinux et Apparmor se branchent au même endroit dans le noyau Linux : ils sont exclusifs.

Les images de bases, appelées core sont basées sur Ubuntu.

Quand Ubuntu a décidé d’utiliser snap quand on installe un navigateur web avec un paquet deb, ça a un peu fait grincer des dents. Ce choix permet d’avoir les navigateurs dans leur version courante, dans différentes versions d’Ubuntu, même les très stables LTS (support à long terme). Je ne souhaite à personne de backporter les patchs de sécurités dans les bases de code tentaculaires des navigateurs webs.

Un Snap utilise SquashFS (un système de fichier compressé) comme format de paquet.

Snap se met à jour automatiquement, avec tout le confort moderne : livraison par delta, modification atomique, retour arrière possible.

Les interfaces permettent de réclamer des droits avec le système, et même d’en créer de nouveaux pour que les snaps discutent entre eux.

La documentation ne l’évoque que partiellement, mais Snap utilise des signatures à tous les étages, avec des chaines de confiances entre le publieur, le dépôt, le paquet.

Distributions Linux immuables

Les distributions Linux peuvent être considérées comme un unique paquet, immuable, avec des stratégies de mises à jour atomiques, et la possibilité de rétro-déploiement (rollback), on parle alors de distributions immuables.

Ne laissant aucun choix d’installation de paquets, il n’y a pas de multiples combinaisons à tester pour valider une nouvelle version.

Il est possible de composer une distribution immuable à partir de paquets Linux (et de profiter des patchs, des mises à jour et de la cohérence entre eux).

Ces distributions peuvent avoir des stratégies de mises à jour agressive, ayant la garantie de pouvoir revenir à un état stable en cas d’incident de mises à jour ou de régression. Le déploiement des mises à jour est différentiel (pour limiter le temps de téléchargement), et surtout signé, pour avoir un confort et une sécurité comparable à un OS classique. Démarrer sur une partition en lecture seule améliore grandement la sécurité de l’OS, il sera impossible de corrompre cette couche (les couches supérieures devront elles, faire attention).

Les OS immuables utilisent souvent un système de paquet d’applications neutre, comme FlatPack ou des conteneurs, ne fournissant que des services de bases.

Le pionnier du Linux immuable, CoreOS a été racheté par RedHat qui propose maintenant des variantes de RedHat/Fedora immuables (et forcément spécialisé) et fournit OStree comme outil de base pour créer des arborescences de fichiers immuables. Au moment du rachat, Coreos a été forké en FlatCar.

Images conteneurs

Les conteneurs, popularisés par Docker, permettent le déploiement d’applications indépendamment de l’OS hôte qui va principalement fournir un noyau Linux (et donc des ressources matérielles), et contrôler son utilisation.

Les conteneurs sont isolés les uns des autres (namespace, cgroup, seccomp…), et si un conteneur est compromis ce sera compliqué pour atteindre les autres conteneurs.

Les conteneurs permettent d’avoir le même environnement sur le poste du développeur, dans l’intégration continue et en pré-production puis production.

Les conteneurs adorent les signatures, et savent les utiliser de bout en bout.

Une image conteneur va embarquer tous les fichiers nécessaires pour lancer une application. Les arborescences de fichiers sont composés de couches, seule la plus haute permet l’écriture, permettant ainsi la mutualisation des couches (en lecture seule, donc) permettant un gain de place certain.

La plupart des images sont construites avec des paquets système, avant d’attaquer la couche applicative qui utilisera des paquets logiciels. Un conteneur ne doit faire qu’une seule chose, et donc ne devrait pas nécessiter trop de paquets.

Chaque conteneur pourra contenir ses propres versions de paquets, et un serveur pourra contenir moult conteneurs, multipliant ainsi les failles possibles et les besoins de mises à jour. Il existe de multiples outils pour découvrir les systèmes de paquets utilisés, puis de confronter leurs versions à des bases de failles, comme osv-scanner ou d’autres services payants.

Dans une vision naïve, l’image de base contiendra le contenu complet d’une installation Linux; une copie de tous les fichiers, on sait jamais. 120Mo pour une Debian 12.

Ensuite, en activant quelques options (comme ne jamais déployer la documentation) et en dégraissant la liste des paquets d’une installation de base, on arrive aux distributions dites slim. 75Mo pour une Debian 12 Slim.

Google propose de faire mieux avec Distroless, toujours avec une Debian. 2 Mo pour une version static qui n’utilise que 3 paquets, même pas de libc, juste de quoi lancer une application statique. La version base pèse 20Mo, avec une libc et openssl, 15Mo sans openssl. Des variantes spécifiques à des runtimes sont aussi fourni : python, node et java.

Au-delà de l’exploit, ce minimalisme drastique améliore la sécurité de l’image en limitant la surface d’attaque, mais surtout va limiter les faux positifs dans les analyses de paquets.

Les conteneurs sont issus des travaux de Google pour son Borg, qui a fourni au noyau Linux les fonctions de base pour isoler les processus, ce qui a permis la création de Docker qui a assumé l’évangélisation, puis de lancer Kubernetes (le Borg pour le reste du monde). Kubernetes a sorti de la boucle Docker en créant l’Open Container Initiative et en normalisant la couche juste en dessous de Docker : Containerd.

RedHat en a profité du coup de mou de Docker pour venger cet affront innovation en créant Podman qui utilise poliment les normes existantes et recrée tout l’écosystème de Docker :

Podman est basé sur cri-o l’outil de bas niveau utilisé par Containerd
Podman utilise les images OCI
Podman n’utilise pas de démon lui préférant systemd
Podman croit très fort aux conteneurs démarré sans droit d’admin (axa rootless), même si tout ne fonctionne de manière optimal pour l’instant

Notaire

Pour signer des commits de code ou des paquets, il faut utiliser un système de clé privée/public, avec une chaine de confiance permettant de diffuser les clés publiques signées.

GPG

GnuPG tente depuis longtemps de démocratiser la cryptographie asymétrique. Le concept de chaine de confiance signé entre pairs n’a jamais fonctionné comme il faut. L’écosystème est bancal, mal maintenu :

le serveur de clé est un bricolage
la révocation d’une clé est une tannée
le format de clé est confus, personne ne sait quel type de clé il utilise et si la taille de la clé est suffisante.
le vaillant mainteneur est seul, avec des micro-contributions d’autres personnes

Keybase a fait un gros travail de pédagogie en fournissant des outils agréables à utiliser. Keybase se fiche de la chaine de confiance pour crédibiliser une clé, mais propose de la lier à différente présence sur Internet, avec un système de challenge (compte de réseaux sociaux, site web personnel, porte monnaie de crypto…). Keybase a été racheté par Zoom qui avait besoin de se payer une réputation suite à différents incidents, puis laissé en l’état, en stagnation.

Debian utilise gpg et met à disposition son trousseau, pour avoir un moyen simple de vérifier une signature, avec une politique de cooptation pour les nouveaux arrivants.

Git permet de signer avec gpg un commit ou un tag, et le kernel Linux, l’utilisateur initial de git, publie aussi son trousseau.

Je pense que l’on peut en 2024 affirmer que GPG n’a pas tenu ses promesses, surtout son idée de chaine de confiance.

The Update Framework

Le CNCF (Cloud Native Computing Foundation) a proposé une norme pour la mise à jour de logiciels : TUF (The Update Framework). Les travaux initiaux sont basés sur le système de mises à jour de TOR, et ont commencé en 2009.

TUF propose un framework pour sécuriser le procédure de mise à jour de paquets, en se focalisant sur les métadatas, sans empiéter sur la gestion de paquets.

TUF utilise une autorité de certification, avec la clé privée qui est hors ligne, la clé publique est fourni avec le client. Tous les efforts sont focalisés sur diminuer les dégâts en cas de compromissions de clés, pour ça TUF utilise une délégation de confiance avec des rôles précis, et des certificats de courtes durées.

TUF a beaucoup plus à l’industrie automobile qui l’utilise via le projet uptane.

Docker a implémenté TUF avec Notary, avant de le sortir de la marque Docker. Notary utilise une très classique PKI pour signer/vérifier, mais surtout lie aux images une police de confiance, un ensemble de règles disant qui peut signer où, avec quelle autorité de certification.

Python proscranise depuis 10 ans avec sa PEP-0480 pour savoir si ils vont faire du TUF. Pourtant, l’implémentation de référence est en Python.

Sigstore

En s’appuyant sur les concepts de TUF, Sigstore propose un système de signature sans clé (keyless signing, mais le terme enthousiaste cache une clé à courte vie), pour tout l’écosystème open source, en espérant une adoption massive et une sécurité accrue, comme l’a fait Let’s Encrypt pour le TLS.

Sigstore est directement sous l’égide la Linux Foundation, sans passer par le CNCF (qui dépend de la Linux Foundation aussi).

Pour afficher son côté neutre, les clés d’autorités sont des clés matérielles, détenues par 5 experts, venus de l’industrie et de l’université, pour une durée d’à peu près 18 mois, avec renouvèlement des signatures tous les 4 mois.

Le principe de fonctionnement de Sigstore est décrit dans une publication scientifique Sigstore: Logiciel signé pour tout le monde, signé par deux devs de chez Chainguard et un chercheur de l’université de Purdue. L’un des développeurs publie des trucs sur TOR, assez à cheval sur la sécurité, les chaines de confiance et les mises à jours nickels.

Chainguard, startup de la supply chain, a été fondé par des gens qui ont bossé chez Microsoft, Google, dans l’écosystème Kubernetes, avec KNative par exemple. Il est donc logique que l’on retrouve du Github (qui appartient à Microsoft) et du Google à tous les étages de Sigstore.

Deux services isolés

Sigstore s’appuie sur deux services :

Fulcio, la PKI qui va signer la clé temporaire utilisée pour signer le paquet, après que l’utilisateur se soit authentifié avec OpenID Connect (chez Github ou Google par exemple), en promettant d’utiliser de l’authentification à deux facteurs (OIDC ne précise pas l’utilisation de 2FA dans son token).
Rekor, va enregistrer les étapes de la signature d’un paquet dans un journal public qui n’efface rien (reprenant la logique de publicité des autorités de certification de Certificate Transparency.

OIDC

sigstore.dev utilise Dex pour l’authentification OIDC, avec Github, Google et Azur comme cibles, ce qui permet de choisir depuis une page web sans avoir à préciser un OIDC tiers lors de la signature.

Clients

La discussion avec Sigstore se fait en REST, avec les outils de SSL. Vous pouvez reproduire la danse de Sigstore en bricolant sur un coin de table avec curl, openssl, jq et base64.

Sigstore fournit un client de référence, cosign écrit en go. Sa bibliothèque Python, sigstore-python, propose aussi un cli (capable de deviner le token OIDC dans une CI).

Github (même s’il ne fait que de l’Oauth2 et pas de l’OIDC) et Gitlab fournissent les outils pour utiliser Sigstore (vérification et signature) dans l’intégration continue, dans le but d’atteindre le niveau 3 de la certification SLSA.

La doc de Sigstore évoque même Jenkins, il n’y a donc pas d’inquiétudes sur la possibilité d’intégrer Sigstore à n’importe quelle CI.

Validation

La procédure de validation d’un paquet est tout à fait classique, avec du json, du base64 et des certificats x509.

Validation de la clé publique :
signature par l’autorité de certification
émetteur crédible
source OIDC crédible
auteur crédible (un mail ou un build depuis une CI)
l’horodatage signé est dans la période de validité du certificat
Vérification que la création de la clé apparait comme il faut dans le journal Rekor
Calcul du hash de l’artéfact et validation de sa signature avec cette clé publique éphémère

Signature

Création d’une paire de clé publique/privée
Création d’un certificat X509 avec des attributs confirmables par le token OIDC
Le certificat contient un challenge (aléatoire) et la signature effectuée avec la clé privée.
Récupération d’un token OIDC, via sa CI, ou via Fulcio qui est une application OAuth2
Envoie du certificat éphémère public et du token OIDC à Fulsio, qui vérifie la signature du token, puis la cohérence des champs entre le certificat et le token. Fulcio raconte tout ça à Rekor, renvoie le certificat signé pour 10 minutes
Calcul du hash de l’artéfact et signature avec la clé privée
Création d’un horodatage signée selon le RFC3161 avec un service tiers comme freeTSA ou Sigstore Timestamp Authority
Envoi de la signature, du hash et du certificat sur Rekor
Envoi de l’horodatage signé sur Rekor
Création d’un bundle, un json avec des blobs en base64 à fournir avec l’artéfact

Le certificat pourra être utilisé plusieurs fois pendant sa durée de vie. La clé privée sera détruite, sans jamais avoir touché le disque dur.

Fulcio préconise l’utilisation de gestionnaire de clés (matériel, services KMS des clouds, Vault d’Hashicorp) et en dernier recours, d’une clé privée sur un fichier.

Pour héberger un service TSA, il faut prévoir du hardware pour avoir une horloge rigoureuse, comme un GPS.

Paquets

Sigstore fournit des outils spécifiques aux gestionnaires de paquets suivant :

cosign sait publier la signature d’une image de conteneur sur un dépôt OCI (comme Docker)
Golang
Python
Rust (instable, en version 0.8 pour l’instant)
Java
Javascript

Il est possible de signer un commit git via Sigstore, avec gitsign, qui utilise pour ça GPG avec des documents au format x509. Oui, git sait utiliser une PKI comme tout le monde.

Pour les paquets, plus que le nom de la personne qui a signé, ou le numéro de série du build, c’est la notion de provenance qui importe.

Dans ce fouillis de cascade de normes, il ne faut non plus oublier in-toto (sour l’égide de la Linux Foundation), pour spécifier les méta-datas d’un paquet.

OpenPubKey

Un autre consortium, composé de BastionZero et de Docker, propose leur propre norme pour signer des clés publiques après une authentification OIDC : OpenPubKey.

OpenPubKey est aussi un projet de la Linux Foundation, et il est utilisé par le registre public de Docker.

Ils ont publié leur white paper expliquant leur démarche.

L’idée d’OpenPubkey est de créer une paire de clés publique/privée et un défi (un nombre aléatoire), de le signer avec la clé privé. La clé publique, le défi, la signature soit utilisé comme nonce pour demander un jeton OIDC. Normalement, un nonce est un nombre aléatoire utilisé lors de l’échange OAuth2, en utilisant le triplet défi-clé-signature, avec un défi de taille suffisante, ça ne remettra pas en cause l’entropie lors de l’échange.

Pour un jeton OIDC émis lors d’une CI, il n’y a pas de nonce, et ce sera donc aud qui sera détourné pour faire signer sa clé par OIDC.

Le jeton ne permettra pas de faire grand chose (son scope est “openid profile email”) et sera rapidement périmé. Lors de la vérification de la clé publique, le champs exp du token ne sera pas pris en compte (il est périmé comme jeton OIDC, mais pas comme preuve), et il sera possible d’utiliser la date d’émission (iat) comme date fiable d’émission de la preuve.

Le jeton peut être vérifié à partir de la clé publique du service OIDC, mais il y aura une rotation (entre 15 jours et 3 mois pour les gros services OIDC), et le papier évoque l’utilisation d’un journal de signature, pour avoir une conservation sur un temps long.

Sigstore cause de OpenPubKey dans son blog, reconnait la simplicité de leur approche, mais doute fort de la possibilité de vérifier une clé sur un temps long, et hurle sur l’idée de laisser trainer un token JWT n’importe où (oui, ce n’est clairement pas orthodoxe).

Mises à jour des dépendances

Il est important d’avoir une politique fluide de mises à jour de paquets, et de faire des déploiements d’un service sans nouvelles fonctionnalités/corrections, juste pour des mises à jour.

Pour la chasse aux paquets troués, tâche ô combien rébarbatives, il faut un robot et une bonne couverture de tests. Tous les gestionnaires de paquets ont une API distante et un cli pour faire ça, mais des outils comme le dependabot de Github, bien que non libre, a le bon gout de fluidifier les mises à jour, en créant une demande de fusion (pull request), qui va déclencher l’intégration continue, et donc les tests.

Il ne faut pas que cette tâche dépende de la disponibilité ou de l’humeur d’un développeur, c’est un travail de robot.

Sécuriser la chaine d’approvisionnement

Pour ce point, il faut des gestionnaires de paquets en bon état, de l’authentification forte pour les contributeurs, une PKI pour signer un peu partout, la possibilité d’auditer les signatures et de l’automatisation pour les montées en version.

Tout ça existe.

Comment vendre une base de données open source

2023-10-02T09:20:00+02:00

Comment vendre une base de données open source

Influxdata vient de sortir la version 3 d’Influxdb sa base de données “temporelles”, avec une petite astuce sur le modèle de licence, pour continuer à faire de l’open-source sans se faire piller, comme certain de ses prédécesseurs.

Mais commençons par le commencement.

L’histoire ancienne

Postgresql

1996 MIT

Ingres, est né en 1982 comme projet universitaire à Berkley, pour travailler sur la notion de base de données relationnelle. Le leader de l’équipe Ingres va créer une entreprise, Ingres, puis finalement revenir à la fac et créer un deuxième produit, Post-Ingres, aka Postgres. Bascule vers le SQL en 1994, changement de noms en PostgreSQL en 96, début de la présence sur Internet avec la version 6, peu de temps après Mysql finalement. A part le faux départ Ingres, Postgresql a toujours été open source (MIT, donc team BSD) et maintenu par sa communauté.

Postgres a un écosystème complet, awesome comme on dit, qui va de la haute disponibilité avec Patroni de Zalando (en MIT), à de la sauvegarde continue avec Barman de 2ndquadrant (en GPL-3).

Personne n’est arrivé à accaparer Postgresql, fidèle à sa licence MIT, il permet l’apparition d’entreprise proposant des services complexes (et open source), en parallèle avec des outils communautaires.

Mysql

1995 GPL

Mysql a été crée comme un clone libre du maintenant oublié msql, par Mysql AB, comme le récite Wikipedia et toutes les pages qui le cite. Pas de trace d’une version antérieur à la version 3, il est donc facile d’imaginer qu’il y a eut deux versions privées, avant de créer l’entreprise éponyme, puis de commencer la conquête d’Internet en 1995, qui est une bonne date pour commencer un truc sur Internet : c’est l’arrivée du grand public sur le grand réseau mondial.

Mysql, est suffisamment souple pour propulser tout le web, du simple LAMP (Linux/Apache/Mysql/PHP) aux premiers GAFAs (Facebook, Flickr, Twitter, Wikipedia, Youtube, plus tard Github …).

Le bizness model ne suit pas, rachat par Sun, qui frustre le vendeur qui fork en MariaDB, et patatra, Oracle rachète un Sun moribond, et met la main sur ce qui reste moralement son concurrent.

Les gros utilisateurs bricolent de la réplication à échelle titanesque :

Github parle de son gh-ost qui deviendra un produit (très confidentiel) sous le nom d’openark
Twitter parle de son Gizzard qui a commencé par répliqué du Mysql avant de passer à autre chose. Mysql qui est toujours utilisé d’après leur billet récapitulatif de 2017 Scale
Facebook parle régulièrement de Mysql et fournit myrocks, un fork de Mysql 5.6, sous licence GPL-2, qui utilise son moteur de stockage, rocksdb (successeur du leveldb de Google). Percona propose une version qui tourne comme module pour Mysql 8.0
Vitess est le proxy utilisé par Youtube pour scaler du Mysql. Ce proxy a mis beaucoup de temps pour causer mysql avec les clients (et enfin devenir un vrai proxy).

L’entreprise Percona est la référence de fait pour Mysql, hors Oracle, et proposent des outils, de l’infogérence et surtout du consulting.

Il ne faut pas se mentir, le rachat de Mysql par Oracle en 2010 (via Sun en 2008), a cassé l’ambiance. Mariadb permet de rester droit dans ses bottes face au grand méchant Oracle, mais c’est tout, le fork d’arrière garde n’a pas les épaules pour proposer des innovations, ou même toucher quoi que ce soit.

Mysql a une chouette histoire, mais cette histoire est figé dans le marbre, et cette stabilité depuis toujours, pour toujours est ce que recherche ses utilisateurs. À part pour créer un Wordpress de plus, qui donc choisi Mysql pour un nouveau projet après 2020?

Sqlite

2000 Public Domain

Sqlite est une base de données relationnelles, avec tout ce qu’il faut de SQL, mais sans réseau, sans accès concurrents. Longtemps cantonné au rôle de base de données pour crétin qui ne savent pas installer une vraie base de données, Sqlite est maintenant la référence pour stocker des données complexes de manière pérenne, largement utilisé dans les téléphones portables.

L’ère du 2.0

Le Web a démarré en s’appuyant sur des outils existants, avant de commencer à créer des choses originales. Github devient rapidement incontournable et les utilisateurs distribuent des ⭐️ comme un gastronome de chez Michelin.

Mongodb

2007 24k⭐️ SSPL

Mongodb arrive en fanfare, pour sauver le web du méchant SQL et du modèle relationnel.

Bruyant et malhonnête (écriture sans sync pour aller plus vite, surconsommation de disques durs avant l’arrivé de Tiger…), il s’est ensuite calmé, et à forcé les autres bases de données à évoluer pour avoir du typage plus complexe (listes, tableaux…) ou plus simple (hstore, json…), plus proche des ORMs, par ce que ne nous mentons pas, de la base de données sans modèle, ça n’existe pas, le modèle est soit explicite, soit tacites. Mongo

Mongodb sera la première victime de la cloudification, et de manière prévisible, ça fera beaucoup de bruits.

Rethinkdb

2009 26k⭐️ Apache 2

En 2009, Rethinkdb trouve que Mongodb est un petit bras, et qu’il est possible d’exposer un AST dans le client pour devenir une requête dans la db. Création d’une boite avec le core dev, licence Apache 2.

Ça ne prends pas, mais 26k étoiles sur Github.

Pivot sur l’aspect temps réel (des événements pour les clients restent synchronisés), ça ne prends pas non plus.

Gros coup de frein en 2015.

Le core-dev tente un reboot base sur FondationDB, Refound, qui cartonne avec 11 étoiles sur Github.

Arangodb, ex Advocadodb

2012 13k⭐️ Apache 2

En 2012, encore dans la hype de Mongodb qui est un petit bras, Arangodb propose en plus du modèle orienté document, un modèle orienté graphe, et même du clef/valeur. En plus des requêtes en javascript comme Mongo, il y a un Query Language.

Gros coup de frein en 2017, mais un score honorable avec 13 milles étoiles Github.

Redis

2009 62k⭐️

Redis débute sa vie comme moteur de cache, du clef/valeur non relationnel avec des types complexes et les opérations adéquates pour les manipuler. Redis méprise les disques durs, tout doit tenir en RAM, mais bon, les tailles des barrettes ont grandis avec lui, et il y a quand même de la persistance (instantanés et journalisation) pour repartir directement cas de reboot. Il gère la réplication et la haute dispo.

Il n’échappera pas à la cloudification.

Elasticsearch

2010 65k⭐️

Elasticsearch commence par rendre accessible le trop théorique Lucene, outil de recherche full text, pour finalement devenir une base de données orientées colonnes, agréable à utiliser en cluster.

Elasticsearch a ensuite su pivoter, pour devenir un stockeur de logs, puis de time series, et de se diversifier avec tout un écosystème un peu confus avec des morceaux de libre mélangé avec des morceaux propriétaires, mais open-source.

Ça ne l’empêchera pas de se faire cloudifier aussi.

Clickhouse

2009 31k⭐️ Apache

Profitant de la hype des bases orientés colonnes, fort pratique pour analyser le comportement de ses clients, Yandex, le Yahoo des russes, libère son Clickhouse sous licence Apache. Yandex permet d’entasser trop de données, de jeter du SQL dessus, et d’obtenir des résultats rapidement sans passer par la case map-reduce du monde Hadoop.

ClickHouse est maintenant une boîte à San Francisco et Amsterdam, lève des fonds, et de chouettes projets commencent à l’utiliser (comme PostHog). C’est la phase “lune de miel”, tout est merveilleux, il faut devenir un standard de fait, puis on parlera bizness à ce moment là.

De manière très classique, Clickhouse se gère facilement sur une seul instance, bare metal ou conteneur, par contre, pour le cluster, il y a LE chois technique de l’équipe, avec un gros zookeeper, et comme ça piaille, ils ont fourni une API pour utiliser autre chose, mais comme ils n’utiliseront pas les alternatives en prod, bah, ce sera en l’état, à la communauté de bosser. Des outils tiers commencent à apparaitre, comme HouseWatch

Leveldb

2011 34k⭐️ New BSD

Google explique sa stratégie d’écriture sans modification (mais en consolidant périodiquement), et l’importance d’avoir des clefs ordonnées dans une base clef/valeur. Héritière de BigTable, leveldb est une réécriture complète, par ce que BigTable s’appuie sur des bibliothèques qui n’ont pas vocation à être libérées.

C’est du simple clef/valeur ordonnées, avec des itérations efficaces sur les clefs (d’où l’intérêt de les garder ordonnées), et des écritures par lot.

Pas de produit, pas de service.

Rocksdb

2012 26k⭐️ Apache 2

Facebook aime bien le concept de Leveldb et fork en Rocksdb pour d’aller plus loin sur le tuning spécifique au SSD (qui était nouveau à cette époque), d’exposer les journaux d’écritures pour avoir de la réplication, et de l’utiliser comme couche basse de persistance, un peu partout, comme Mysql par exemple avec Myrocks, ou simplement du cache.

Foundationdb

2017 13k⭐️ Apache 2

Apple reprend le concept d’une base clefs/valeurs ordonnées avec des écritures par lots, mais se focalise sur la notion de réplication cohérente au sein d’un cluster et sort discrètement Foundationdb. Comme “fondation”, elle se positionne comme outil de base niveau, sans protocole réseau spécifié, mais en fournissant le client adéquat dans différents langages (C, Ruby, Python, Java, Golang). Orienté performance, gros volume et fiabilité, Foundationdb demande à l’utilisateur de faire des efforts, en dénormalisant son modèle, en utilisant une serialisation qui ne casse pas l’ordre des clefs, et en recommandant de ne pas dépasser le ko pour les données, au pire 10k si on sait que l’on ne pas écrire/itérer trop souvent dans cette table, et la limite dure est 100ko.

Foundationdb se positionne clairement comme outil sur lequel construire des services (et potentiellement facturer), ce qu’Apple fait en interne.

Deno KV utilise Fundationdb, mais reste une arme secrète pour l’offre d’hébergement de Deno, les offres plus ou moins serverless basées sur javascript sont en pleine ébullition.

Les héritiers de Postgresql

Postgresql avec sa communauté maintient un logiciel vivant, et sa licence incite la création d’entreprise, qui en retour financeront (ou dédieront des développeurs) le projet.

Citusdb

2016 9k⭐️ AGPL

Citusdb fournit une extension, pour distribuer les données et les calculs dans un cluster, du stockage orienté colonnes (compressé).

La licence Affero brime les offres d’hébergement, et Citus réserve l’offre en Cloud à Azure dans son offre Cosmos-db

Timescaledb

2018 16k⭐️ Apache 2

TimescaleDB propose une extension, pour gérer les timeseries, avec du sharding basé sur la date de l’événement, du stockage orienté colonne (compressé). La version autohébergement est sous licence Apache, et ils gardent pour eux la version Cloud.

Neon

2021 10k⭐️ Apache 2

Neon se positionne comme un Aurora open source, en séparant le calcul du stockage. Le stockage s’appuie sur le WAL (Write Ahead Log) répliqué, pour créer des blocs immuables régulièrement consolidé (du LSM), qui seront à chaud sur un SSD, à froid sur un S3. Le sharding est une possibilité, mais pas la priorité immédiate.

L’idée étant d’avoir du serverless (du SQL over HTTP/Websocket), avec la possibilité d’éteindre les noeuds de calcul, sans remettre en cause la persistance, et de pouvoir dimensionner le calcul et le stockage indépendement. le site envoie du rêve en parlant de stockage sans fond, mais aussi de cold start qui se chronomètre en seconde, ce service n’est pas universel, ni magique.

Pour l’instant, il faut patcher les sources de Postgres (les modifications ont vocations à remonter) compiler et déployer. Neon n’a pas trop à craindre de la concurrence de son offre SAAS.

Alloydb

2022 propriétaire

Google fork Postgresql pour créer Alloydb, avec une architecture avec des nodes calcul/stockage, ressemblant à Neon, mais avec plus de violence : le stockage est orienté colonnes, la cible est donc de gros volumes de données sans modification, avec des reqêtes complexes.

Hors documentation utilisateur, Google communique peu sur les rouages de ce produit, qui doit recycler des outils existants, des éléments de Spanner, crée en 2012, avec un moteur SQL en 2017, l’année de l’offre SAAS public.

Alloydb semble être la réponse définitive à tous les utilisateurs de Spanner qui ralent sur la compatibilité Postgresql, Spanner ne gérant que le protocole.

Les héritiers de Sqlite

Rqlite

2014 14k⭐️ MIT

[Rqlite] se présente comme une base de donnée relationnelle distribuée, utilisant sqlite comme moteur de stockage. Il permet d’avoir des transactions, de la cohérence écriture puis lecture (la bagarre avec la réplication asynchrone), tout en restant simple et léger.

Projet communautaire sans offre d’une entreprise.

Litestream

2020 9k⭐️ Apache 2

En 2020, Litestream prouve qu’il est efficace de répliquer les modifications d’un sqlite vers quelque chose de pérenne, comme un S3, et de proposer des services simples.

Pas d’entreprise ni d’hébergement, c’est un projet “because we can”.

Litefs

2022 3k⭐️ Apache 2

Superfly utilise LiteFS la même réplication des journaux que Litestream, pour répliquer massivement et de manière asynchrone les écritures, suivant un motif primaire/secondaire avec un consensus Raft (du Consul). LiteFS est une couche de persistance pour l’offre serverless de Superfly, adapté pour des cas avec peu d’écriture concurrentes, et beaucoup de lecture qui bénéficieront de faible latence. Il se positionne comme plus performant que Rqlite, et plus qu’un simple backup comme Litestream.

Litefs est la vitrine technologique (en bêta) d’une offre Cloud volontairement sobre, pour se différencier des gros du Cloud.

Parquet

2012 2k⭐️ Apache 2

La fondation Apache adore rationaliser les écosystèmes éparpillés, et fournir des fondations saines sur lesquelles construire de s choses plus grande.

Inspiré par le Dremel white paper de Google, conçu pour Hadoop (et HDFS), Parquet est un format de stockage orienté colonne : les écritures se font par lot, on réécrit pour modifier, on peut lire que les colonnes de son choix. Le format est compact, compressé, optimisé pour la lecture et les performances. Imaginé pour remplir du HDFS et être lu par du java, il s’avère tout à fait apte à remplir du S3 et à être écrit/lu par tout les langages gérés par Arrow. Toutes les audaces sont permises, on peut écrire avec un logiciel, et lire avec un autre, utilisant une technologie différente, comme vous le faisiez avec du CSV ou du JSON.

Arrow

2016 12k⭐️ Apache 2 Arrow est la bibliothèque officielle pour lire et écrire du parquet, pour exposer des colonnes en RAM avec les primitives pour faire de l’IPC (discussion entre process) et du RPC (pareil, entre deux machines), avec tout ce qu’il faut de zéro copie et de binding dans moult langages (dont Numpy).

Datafusion

2016 4k⭐️ Apache 2 Datafusion est un moteur SQL utilisant Arrow, qui peut utiliser du Parquet, mais aussi du JSON, du CSV et d’autres formats. Les réponses sont du Arrow, et donc lisible en natif dans de multiples langages.

Ballista

2016 1k⭐️ Apache 2 Ballista permet de faire des requêtes avec Datafusion, mais en distribué.

Flight

2019 Apache2

Flight, basé sur grpc, implémente le début d’un protocole réseau :

poignées de mains (handshake en VO)
discussion direct entre noeuds avec un ticket pour amorcer une discussion authentifiée
découverte de méta data
authentification
chiffrage
middleware
tracing (avec OpenTracing)
du RDMA est prévu pour plus tard (les machines discutent de RAM à RAM, sans passer par le CPU)

FlightSQL

FlightSQL normalise le protocole réseau comme le faisait ODBC et JDBC, en s’appuyant sur Flight.

Il existe une extension pour causer à Postgresql en FlightSQL

Les autres bases de données

J’oublie volontairement les bases de données dédiées au big data (coucou Scylladb ou Cockroachdb), tout ce qui est orienté graphe, et les bases trop exotiques (ou qui sont passé sous mon radar).

Le projet database of databases tente l’exhaustivité, ce qui est assez fascinant.

La rationalisation par le nuage

L’innovation suit un chemin très classique : un démarrage plein de créativité, une rationalisation, et finalement une banalisation.

Les hébergeurs ont commencé par proposer la triplette machine virtuelle/stockage/réseau.

En y collant une API, c’est devenu le Cloud.

En étant suffisamment gros, vous avez du stock de machines, et donc la promesse de pouvoir ajouter rapidement de la ressource pour suivre un pic d’usage.

Ensuite, sont arrivés les offres de services, parfois des services open source existant, comme Mysql ou Postgresql, parfois des services maisons que la concurrence n’a pas.

GNU sent l’embrouille et crée en 2007 l’AGPL, comme du GPL, mais avec l’obligation de fournir les sources (sous la même licence) des patchs utilisés par un hébergeur.

S3, services spécifiques à AWS est devenu un standard de fait, cloné par tous les autres clouds.

Héberger des services open-source reste fairplay, c’est même le but de la famille BSD. Il y a juste une distorsion de concurrence avec la force de frappe commercial, les économies d’échelles. On peut ajouter à ça l’effet winner take all, le premier rafle tout, et l’assurance vie que propose ces demi dieux de l’informatique : ok, le projet n’a pas tenu la charge, mais qui aurait pu faire mieux que le glorieux Amazon/Google/Microsoft?! Fatalitas!! Ce n’est pas de ma faute.

Deuxième étape, une fois l’entreprise construite à partir de briques open-source (qui est aussi fait pour ça, pas de soucis), on peut passer à l’étape “moissonner le blé de l’open-source” : on prends un produit open-source, avec sa base utilisateur, sa réputation, ses threads de questions/réponses sur StackOverflow, et on l’intègre proprement à son offre Cloud : on peut commencer à vidanger l’offre “as a service” de l’éditeur, vers son offre Cloud.

Si on a un peu de temps, on peut créer un élément spécifique à un logiciel open-source, un élément taillé sur mesure pour son architecture logiciel, sur un thème un peu casse-gueule, comme la persistance, redondance ou performance.

Le plus connu est Aurora, un moteur de stockage distribué, sur lequel on peut poser un tout à fait classique Mysql ou un Postgresql.

Là, la cible est facile, il n’y a pas d’entreprises à piller (Oracle ne compte pas trop sur la vente de licence Mysql).

Quand AWS a proposé une offre intégré avec Mongodb, ça a un peu plus dérangé l’éditeur qui a riposté en changeant de licence pour SSPL, propriétaire. AWS a simplement crée un clone de Mongodb, Documentdb, propriétaire, avec une compatibilité sur le protocole.

AWS lance une offre intégré pour Elasticsearch, qui bascule en SSPL et une partie de son code passe en “open source lecture seule”. AWS fork pour créer OpenSearch qui reste sous Licence Apache 2.

Redis anticipe et bascule en free-core, le Redis “comme d’habitude” garde sa licence permissive, mais toutes les nouveautés, sous forme de modules, n’ont pas le droit d’être vendu par un hébergeur.

Le cas Influxdb

En 2013 le monde est prêt pour avoir une base de données temporelles open source : le Cloud permet d’avoir des services distribués, d’adapter les ressources à la charge, bref, on passe de la question binaire “le site est il disponible?” à la finesse de “quelles sont les performances pour quelle consommation”.

Tellement prêt que Soundcloud crée en 2012, Prometheus basé sur le Borgmon de Google. Ciblant le cloud, Prometheus est découpé en plusieurs services et suit le choix de Google : c’est la base de données qui va chercher les valeurs sur les services (un préfixe en HTTP) en attendant que tout le monde cause le prom, il faut déployer des sidekicks, comme blackbox, qui font les entremetteurs pour aller chercher les métriques.

Influxdb 1

Financé par Y-Combinator, Influxdb apparait en 2013, avec une approche minimaliste : un seul binaire à déployer, des agents poussent des données, avec une large compatibilité avec les agents déjà déployés.

Un faux SQL permet de faire des requêtes et des agrégations. Premier péché : personne ne doit créer un presque SQL, c’est extrêmement frustrant, autant créer un vrai DSL sans comparaison possibles, ou avoir du vrai SQL.

2015, changement de nom pour pour Influxdata, et créer une suite logicielle, avec Telegraf, un agent permettant d’envoyer des données depuis de multiples sources.

Coté interface utilisateur, Kibana, apparu en 2012 et dédié à Elasticsearch, fork en Grafana pour devenir multi bases, en 2013.

La citation d’Influxdb apparait dans un commit pour la première fois en février 2014. Prometheus est cité dans un commit pour la première fois en septembre 2015

Influxdata a donc une stack complète pour lire et écrire des métriques.

Influxdata se concentre rapidement sur son bizness model, propose un relais permettant de faire la réplication master/master (avec des données horodatées, immuables, on doit être dans le cas de réplication le plus simple), puis oups, l’interromps, ça brime son offre as a service. Des forks seront maintenus un temps.

Influxdb utilise une astuce pour avoir une base de code unique qui permet de fournir un monolithe open source, et de générer une version en microservices, spécifiques à l’offre commerciale, avec du protobuf et du raft.

La foule a choisi Prometheus qui a une communauté (bientôt cannibalisé par Grafana). Influxdb se repositionne comme timeseries pour le Edge, avec une offre on premise (les données restent chez vous), en plus du cloud, qui supporte un accès intermittent à Internet.

Influxdb 2

Il faut un second souffle.

Personne n’utilise directement l’influxql, il est tellement plus simple de cliquer partout depuis l’UI de Grafana.

Pour sa version 2, Influxdb sort un vrai DSL : Flux, et tord le bras de utilisateur pour qu’ils lâchent influxql, qui n’est plus géré dans la version libre, il faut une licence pour ça. Flux a une syntaxe élégante, basé sur la notion de pipe, les |> que l’on voit apparaitre dans les langages récents pour chainer les fonctions, sans avoir des tempêtes de parenthèses.

Le machine learning, qui deviendra l’intelligence artificiel, commence à se généraliser, Numpy a envie de manger de la métrique, pour faire de la prévision, ou même la très casse gueule recherche d’incohérences.

Le protocole réseau des requêtes réponds en JSON, comme tout bon REST, mais c’est loin d’être optimal pour envoyer des myriades de float.

Flux ne remplacera jamais Numpy ou même R, faire des requêtes dans deux langages en même temps est une punition, avec le risque de filtrer les données coté client (et non du coté de la base de données, ajoutant la latence de la connexion) et d’autre sous optimisation.

Influxdb 3

Nouveau pivot, Influxdb conserve Golang pour les couches hautes, mais bascule sur Rust pour la couche de persistance/requêtes, et crée IOx, prononcez eye-ox, oeil de boeuf. IOx s’appuie sur Parquet, qui fait sauter les contraintes de cardinalité qui peuvent mordre très fort et Datafusion qui permet d’avoir du vrai SQL avec des possibilité de jointures sur des bases de données relationnel externes.

influxql et Flux sont dépréciés, on peut parler de faux départ pour cette technologie pourtant élégante.

Avec le stockage en Parquet, techniquement, si vous avez envie de lire les données avec Clickhouse ou n’importe quel OLAP sympathique qui cause le Parquet, faites vous plaisir.

IOx est déployé dans Influxdb 3.0 annoncé la semaine dernière.

En normalisant(sous traitant?) les couches basses, Influxdb supprime deux drames, et se concentre sur son coeur de métier.

Nouvelle version, nouvelles licences.

Edge, un Open-core, monolithique, libre, sans compactage.

Community, gratuit, comme Edge, mais permet des requêtes sur des temps long, et du compactage.

Influxdata se réserve la partie cluster :

Serverless, proche du mutualisé d’antan, où l’on paye à l’usage.
Dédié pour envoyer du gros débit de manière prévisible.

Si vous avez des besoins de edge, vous n’avez qu’à synchroniser vos fichiers Parquet sur un S3 (ou un de ses clones), qui assurera la redondance. Les fichiers sont horodaté, ce sera facile d’effacer les vieilles données, ou de faire de la consolidation, pour perdre en granularité en échange de place.

Conclusion

Construire une base de données à partir de rien, tout seul est utopiste. Il faut mutualiser l’effort de développement et la construction de la base utilisateur, et sans se faire piller tout de suite. La couche de persistance, et donc le risque de perdre des données, est terrifiante. Pas mal de base de données innovantes (Mongodb, Influxdb, Prometheus…) ont débuté sur un moteur de stockage bricolé sur un coin de table avant de pivoter (ou racheter) sur quelques choses de plus crédibles.

Les efforts pour mutualiser les couches basses (stockage, requête, réplication…) du Big Data sont resté dans l’écosystème Java, avec un ticket d’entrée trop haut, golang s’est coincé tout seul avec un cout trop élevé pour faire des aller-retours avec du C qui le force à paraphraser en pure Go. Cockroach l’explique dans son billet expliquant la bascule de Rocksb vers Pebble.

Les tentatives de recycler le Innodb de Mysql n’ont pas abouti, mais on a vu apparaître des simples base de données clef/valeur (local comme Rocksdb, distribué comme Fundationdb) qui sont des bases saines pour construire une application.

Rust est la bonne réponse à Java pour fournir des outils juste au dessus de la couche de persistance, sans tirer tout un écosystème (et ses guerres de communauté).

Postgres, avec sa licence permissive et sa modularité reste incontournable pour ajouter des approches différentes (colonnes, géographie, graphes, vecteurs…) mais en gardant tout le reste (SQL, protocole réseau, client, réplication…). Pas mal de base de données récentes causent le dialecte Postgres pour profiter des clients (et UI) existants.

Distribuer une base de données sur plusieurs machines est compliqué, mais profiter d’une reprise sur l’incident qui arrive au milieu de la nuit est quand même chouette.

Les white papers sont disponibles, les briques logicielles libres existent, mais le travail pour fournir un service distribué est difficilement mutualisable et monétisable, surtout quand on se fait piller.

Utiliser des chouettes jouets sans pouvoir ouvrir le capot est frustrant, en plus d’être moins efficace et moins pérenne. Les gros du Cloud, comme tout le monde, ont besoin d’utiliser et produire de l’open source : Nanos gigantum umeris insidentes

Ubus roi

2023-08-31T16:23:00+02:00

ubus est le microbus système développé par OpenWRT. u étant la version ASCII de µ.

Pourquoi yet another bus?

OpenWRT

OpenWRT est une distribution Linux ciblant l’embarqué : des appareils avec peu de mémoire, un stockage lent et maigrichon, et un processeur minimaliste. L’appareil fera peu de chose, mais bien, sans bouffer des gigawatts.

OpenWRT est conçu sur la notion de contrainte, faisant passer Alpine pour une distrib de débauché.

OpenWRT est surtout connu pour son utilisation dans les routeurs wifi, il est même possible d’en acheter avec directement un openWRT dessus, sans avoir besoin de le flasher.

Composabilité

OpenWRT s’appuie sur la philosophie UNIX : un ensemble de services qui ne font qu’une seul chose, mais correctement. Cette approche théorique est élégante dans un shell, où, avec quelques commandes et autant de pipes, on obtient à peu prés ce que l’on veut. Cette composabilité favorise l’émergence de logiciels largement utilisé pour mériter des audits et des CVEs, et suffisamment de contributions pour avoir des corrections et des évolutions (en théorie).

Les services en ligne perdent les atouts du shell et de sa composabilité. Le shell ne prévoit rien pour la notion d’événement de plus, dans ce glorieux passé, à part des cliques sur un clavier, un reboot de la machine, il ne se passait pas grand chose. Non, le cron n’est pas une réponse acceptable, et encore moins l’immonde polling.

Pour que des services puissent discuter entre eux, il faut passer par un bus. UNIX fournit gentiment des sockets UNIX et même des files d’attentes (le très peu connu /dev/mqueue), mais ces outils ont été conçu à l’ère des processeurs mono-coeurs, et fournissent que des IPC (communications inter processus) pas de la gestion d’événements.

UI centralisé

OpenWRT est entièrement configurable en ligne de commande via un accés SSH, mais sa vraie force est de proposer une interface web, maintenant écrite en lua : LuCI. LuCI a permis de tirer une (petite) dépendance dans cet univers de minimalisme : Lua, la pépite du “code as config”.

D-bus

Le besoin de coordination et d’évenement a très vite était ressenti pour les desktops (le fameux “est-ce que Linux est raidi pour le dekstop?”). Mais KDE, le premier bureau pas tout moche, avait un soucis de licence (avec la licence de Qt, soyons précis), ce qui a conduit l’apparition de Gnome (basé sur gtk, concurrent de Qt, crée pour Gimp), les deux se sont tirés la bourre, et ont fait le maximum de choix différents, pour, euh pourquoi? pour se différencier. Chacun a bien sur choisi un bus différent.

Freedesktop a été crée pour arrêter le massacre, et établir consensus puis des normes. Freedesktop a fournit D-bus, débuté en 2002, avec une API stable en 2006. Fortement inspiré de DCOP, d-bus a rapidement été intégré dans KDE, Gnome a un peu plus trainé la patte. Mais c’esst de l’histoire ancienne, d-bus va maintenant au delà du desktop et gère maintenant le réseau avec NetworkManager le bluetooth avec bluez, mais surtout le boot avec systemd.

Systemd qui tire d-bus a fait hurler sur le coup, mais la concurrence était tellement inférieur et une norme contestable (mais utilisé) pour une couche basse a tellement plus de valeur que de vaines divergences.

D-bus a gagné la guerre du bus desktop, mais n’a jamais trop pris sur les serveurs, même si il reste un prérequis système.

Les applications métiers se concentrent sur les couches au dessus, avec des services maintenant distribués, utilisant soit de la découverte/configuration (zookeeper, etcd, consul) soit du gros bus avec maintenant de la persistance/reprises d’événement (Kafka, nats, Redis STREAM…).

Trop gros, trop complexe, D-bus n’a aucun intérêt pour des applications cotés serveurs.

Les bus prévus pour les applications distribués sont tout aussi sur-dimensionnés pour de l’embarqué.

Ubus

OpenWRT fonctionne sur des petits Linux, bien incapable de gérer D-bus.

Ubus (µbus ?) est un logiciel embarqué, cousu main en C, premier commit en 2010, avec une chaine de dépendance minimaliste, utilisant les libs maison pour mutualiser des fonctions pour grapiller de la place. On parle de libs qui se pèsent en kilo.

Pas de README (la doc, c’est pour les faibles), une arborescence plate, cmake et un compilateur C sont les seul prérequis pour compiler.

Ubus s’appuie sur ubox, la bibliothèque fourre-tout de openwrt, et json-c via un wrapper maison.

Pour ne pas se laisser distraire par des fonctionnalités exotiques, qui mettrait en péril le minimalisme du projet, mais sans pour autant bloquer les évolutions, lua est bindé à l’application.

Une architecture classique et de bon gout : core en C minimaliste, modules en lua.

Le principal usage de lua est un module http, qui expose ubus en REST avec l’incontournable JSON, qui permet de lui causer avec curl et même d’exposer ubus au reste du monde (dans le LAN, hein, foufou, mais pas trop), avec de l’authentification et des ACLs.

Le module http pour ubus est bien sur prévu pour s’intégrer à LuCI, l’UI web d’OpenWRT.

Pour parler le ubus (à ubusd, donc), il n’y a que 3 possibilités :

l’outil en ligne de commande : ubus
la lib officielle, le protocole n’est pas spécifié, il existe juste une implémentation
l’API REST, avec le classique curl ou whatever qui cause HTTP/1.1 et JSON

Ubus est très lié à l’écosystème d’OpenWRT, les sources ne compilent pas sur une simple Debian (et encore moins sur un Mac). OpenWRT cible une multitude d’architectures exotiques, et pour ça utilise une chaine de compilation (cross compilation, en l’occurence), disponible via Docker, par ce qu’on est quand même en 2023 : openwrt/docker.

Une image “bac à sable” est fourni, pour avoir un shell dans un environnement OpenWRT, mais sans les services lancés (pas de ubusd, donc), l’idée est de pouvoir simplement tester un paquet.

Le plus simple pour jeter un oeil reste de passer par un Vagrant avec vagran-openwrt-box.

Le bus roi

Pour pouvoir composer une application à base de services, le plus simple est de passer par un bus métier.

Un peu fatigué par les zélotes de Kafka (ou pire, des services spécifiques des gros du Cloud), ubus apporte une touche de fraicheur, avec une approche petit boutiste, bien loin des orgies grand boutiennes.

OpenWRT, Linux comme avant

Utiliser OpenWRT donne l’impression de voyager dans le passé, d’effleurer l’age d’or d’UNIX, avec son C omniprésent et des contraintes matériels énormes.

OpenWRT est minimaliste et traditionaliste, sans pour autant être complaisant et réactionnaire (chose assez facile à trouver dans le monde des firewalls) : il utilise un kernel récent (un 5.10), ne démarre pas les services depuis un dossier rempli de shell (il utilise son procd), utilise les possibilités d’isolations qui font la joie de Docker (namespace, capabilities, cgroup2, seccomp, bpf…).

Minimaliste, mais contemporain.

Aller plus loin

Il existe des boitiers avec OpenWRT installé dessus, coutant quelques dizaines d’euros, pour pouvoir jouer et profiter tout de suite de l’écosystème d’OpenWRT.

Si vous aimez l’absurde et les jeux de mots bancals sur père Ubu allez jeter un oeil l’étonnante adaptation filmé par Jean Christophe Averty.

Libre, as a service

2020-04-05T15:20:00+02:00

Il faut degoogliser Internet, ok. Avec du logiciel libre, ok. Libre comme le discours, pas la bière, ok.

Brassage domestique

Je dois pouvoir micro héberger, sur un gros mutu PHP, sans compétences particulières, euh non, en fait.

Il est indispensable de garder le contrôle de ses données, et de décentraliser Internet. C’est une démarche politique et technique. Les deux ensembles. Une bouse technique, mais correcte politiquement, c’est un échec.

Parlons pognon

Vous voulez déposer une application sur Internet, et que des gens puissent l’utiliser. Ça va avoir un cout : en temps, en matos, en sous.

Le cout du développement, si c’est un logiciel libre, installé tel quel, sans modification, bah il est gratos, comme dans bière gratos.

Ensuite, il faut un serveur, et un branchement vers Internet. Avec les ordis de la taille d’une paume, et une ADSL à prix agressif, le cout d’un hébergement à la maison va être faible. Les offres entrées de gammes de nos hébergeurs nationaux (ou plus loin) sont elles aussi accessibles.

Concrètement, pour un service simple et peu sollicité, un hébergement peu cher aura des performances correctes.

Jusqu’ici tout va bien, le cout du développement et de l’hébergement matériel sont raisonnables.

Mais c’est que maintenant que l’histoire commence.

Notre temps

Vient maintenant la notion de maintenance.

Le développement, c’est ton temps, l’hébergement, c’est le temps des autres.

Le service va avoir des incidents, qu’ils soient matériels ou logiciels. De simples bugs, sur lesquels on peut s’assoir, ou des failles de sécurité, qu’il faut patcher rapidement avant que ça dégénère. Pour certains services, comme du SMTP, un incident, ça veut dire un bannissement, et donc un arrêt partiel du service. Un service compromis qui va miner du bitcoin en mettant à genoux le serveur, ça veut dire aussi un arrêt du service.

Un disque dur qui boude, un serveur qui se coince, ça veut dire restaurer un backup, et donc avoir fait un backup.

À un moment, vos utilisateurs vont utiliser votre service, sinon, il ne sert pas à grand-chose, et donc le secouer un peu, puis beaucoup. Ce n’est pas grave, vous centralisez les erreurs, enregistrez les métriques et faites un joli tableau de bord. Une première passe pour trouver des usages abusifs, puis finalement, ils vont atteindre de vraies limites, et ça va ramer sévère.

Là, l’hébergement de ce service va commencer à être pénible. Le cout du dev est gratos, le cout du matériel est symbolique, le cout de la maintenance explose. Que faire? Passer en force et surdimensionner les serveurs, mais ça veut dire tout réinstaller (bah oui, sans provisionning, sans conteneur, ça a un cout sympathique), et ça transfert un cout en temps vers un cout en sous. Avec plus de matos, ou du matos plus gros, ça va pouvoir secouer plus fort, avec plus d’utilisateurs à mécontenter, et de nouveaux drames rendus possibles par le franchissement de la première vague de drames.

Cramage

À cette étape, il est possible de cramer l’admin, qui va se trouver bien seul, avec plein de gens pour râler. Si c’est pour du support utilisateur, un forum et des grunts peuvent décharger une partie de la charge. Pour les serveurs qui pètent, bah, c’est compliqué.

Pour ne pas cramer un humain, une seule solution en avoir plusieurs, une équipe en fait. Pour rentabiliser, il leur faut donc plus d’utilisateurs et donc une instance plus grosse. Il sera humainement possible de gérer plus de matos et donc céder à la facilité de continuer de passer en force

Ce n’est pas sale de payer des gens. Que ce soit en micropaiement ou salarié par une structure associative. Ils mangent, payent un loyer et s’habillent de teeshirt trop cher à cause des dessins qu’il ya dessus.

Automatisation ou l’anti-luddisme

À cette étape-là, infra as code n’est plus une option.

Par contre, empiler du matos, juste pour gérer des pics d’utilisation, ça va devenir hors de prix, et c’est même probable que le code ne va pas gérer la répartition sur plusieurs machines. L’impasse va vite arriver.

En parallèle, un autre problème va arriver : la complexité des services. On est passé de l’ère des sites webs à celui des applications, et tout ne rentre pas dans l’http de l’an 2000, pour avoir du tchat, de la visioconférence, oui, ça va passer par les navigateurs webs, mais via websocket, webrtc et autres streamings. Cette complexité va faire exploser les couts de développement, et la complexité côté serveur. Cette fois-ci, Varnish ne pourra plus sauver votre développement de bourrin.

Les utilisateurs ont rapidement pris gout aux interfaces léchées des applications web des GAFAs. Essayez de faire passer un utilisateur non militant de Gmail à Squirrel mail, juste pour voir. Pour développer un service de qualité, il faut des compétences complémentaires (UX, graphisme, support, traduction, développement…) et tous ces métiers ne se payent pas tous de gloire, leur métier ne leur laisse pas forcément autant de temps et de thunes en rab, pour le consacrer au logiciel libre.

Le matos a changé d’échelle avec le remplacement des disques à plateaux qui se trainaient lamentablement par le SSD, et même avant qu’on se rende compte du changement par du NVMe. En face, de la fibre ou de la grosse 4G. Le matos est prêt à tout engloutir, ce ne sera ni le stockage, ni la bande passante qui vont ralentir la soif de pixels.

Donc, voilà, des hordes d’utilisateurs exigeants, avec des gros appétits, sont là pour apprécier vos services. Serez-vous à la hauteur?

Un nouvel espoir

Pour avoir une chance de réussir à proposer des services sympathiques en ligne, alternatifs ou pas, il faut d’abord mettre de l’ordre dans tout ce fatras.

Protocoles

L’idée de base est de ne pas avoir de monopole, il faut donc avoir des systèmes décentralisés, des machins qui causent entre eux pour profiter de l’effet d’échelle. Un réseau social fonctionne par ce qu’il y a déjà plein de gens dessus. Pour ça, il faut des protocoles, une locomotive pour tirer plein de monde, et des implémentations adaptés à des cas moins courants.

Bittorrent a parfaitement réussi ça, et Mastodon peut réussir si Pleroma arrive à se démocratiser. Peertube est fonctionnel, en déclinant le concept du pair à pair à la vidéo. Il faut voir ce que donnera IPFS.

Le mail est LE premier service distribué largement utilisé, mais le spam et la stagnation des outils libres qui ont permis l’apparition de gmail ont eu un effet dramatique. DKIM et SPIF sont maintenant un prérequis, mais l’arbitraire des gros serveurs est maintenant une menace permanente. L’incapacité du courriel à garantir la confidentialité des échanges, confirmée par l’échec de GPG, ont reléguer le mail au rôle de renouveleur de mots de passe.

Il faut des protocoles bien spécifiés pour être interopérables, et des implémentations qui scalent petit, et grand.

Étonnement, Gitlab et Gittea via git comme protocole permettent ça. Reste à normaliser la notion de fork et pull request.

De la distribution de service sans syndication efficace, bah, c’est juste de la dispersion.

De bons outils

Avant, on avait des disques qui ramaient, une pénurie de développeurs web, et des navigateurs pourrites. Donc pas de dev front. Il y eut ensuite l’épisode Flash + IE6, pour enfin aboutir à la modernité : HTML5 et les spécifications EcmaScript, la déferlante des smartphones, les disques qui vont trop vite et les gros tuyaux.

Pour les devs, on a maintenant des langages matures, des bouquins avec des gravures d’animaux dessus, des frameworks, des workflows pour gérer le code, et de plus en plus d’analyses statiques.

Il faut un écosystème logiciel suffisamment responsable pour avoir des bibliothèques maintenues et pas systématiquement trouées.

Qualité

Donc, pour proposer des services de qualité en ligne, il faut des technologies suffisamment répandues pour avoir un stock de développeurs, et une chance de reprise si le mainteneur a un pépin. J’ai fait des patchs Erlang, par vice, mais je suis moyen chaud pour RTFM suffisamment pour proposer des patchs Haskell, Pony ou autre Crystal.

Qui garde les gardiens

Un serveur vautré a une qualité de zéro, niveau expérience utilisateur. Il faut avoir un système pour prévenir quand ça se vautre, avec tout ce qu’il faut de contexte pour pouvoir comprendre rapidement l’incident, puis le corriger (dites bonjour à Sentry), et que ce surveillant soit lui même plus fiable que le système qu’il surveille. Pour ça, il n’y a pas 36 solutions, il faut de la redondance, et là, ça commence à gripper pour l’auto hébergement. Pour l’instant il n’y a rien comme outils simples pour avoir une coopérative de monitoring, regroupant quelques auto-hébergeur. Une fois que vous vous serez mangé un incident au moment où vous avez le plus envie de faire toute autre chose, bah, vous commencerez à vous renseigner sur la redondance et la tolérance de panne. Je ne parle pas de l’inévitable RAID de disques, mais des outils comme Consul pour coordonner une petite grappe de machines et relancer des services sur les machines survivantes, vous laissant le temps d’organiser la réparation ou le changement d’une pièce. Je parle juste de coordination de services, l’omniprésent Kubernetes est largement au-delà du scope du petit hébergement.

Efficience

Concrètement, ce qui coince, maintenant, c’est la facture énergétique, et l’utilisation du CPU. La prévisibilité de son utilisation, pour être précis.

C’est difficile de dimensionner un serveur. Techniquement le premier palier va être gros, la machine sera surdimensionnée, tout comme l’est votre poste de développement. Avec peu d’utilisateurs, si marche sur votre laptop, ça marchera sur le serveur. Par contre, avec plein d’utilisateurs, le matériel va commencer à être utilisé comme il faut. On va avoir un budget CPU/RAM/Disque par utilisateur. La notion de hit, avec les gens qui prennent le temps de lire, ça saute avec les applications et les flots HTTP. Pour avoir de la visibilité, il faut que ce budget ressource soit prévisible : si vous avez quelques workers avec 512Mo de RAM et un timeout de 30 secondes, ça va gérer les actions violentes sur le serveur, mais au détriment du nombre d’actions en parallèle. En permettant que quelques-uns puissent tout prendre, bah ça va brimer l’ensemble du groupe. Pour offrir une qualité correcte à l’ensemble, il faut des quotas raisonnables pour tous, et mettre dans des files d’attente toutes les actions gourmandes : elles seront effectuées, mais sans se marcher dessus, et en prenant le temps qu’il faut. Rigoler en voyant le load d’un serveur, ça se faisait avant l’an 2000, plus en 2020. L’asynchrone devient la règle, pour lisser les accès parallèles et assumer les différentes latences.

Simple ou simpliste, complet ou complexe ?

La tolérance du langage pour faciliter son apprentissage se paye cash au niveau maintenance et sécurité. L’analyse statique, que ce soit dans son éditeur ou la CI devient un prérequis. Typescript est venu ajouter la rigueur du typage fort à l’historiquement bordélique Javascript. Même Python a maintenant des annotations de type.

La facilité de déploiement est un argument ambigu. Pouvoir poser un machin en PHP dans un bout d’arborescence apache n’est pas un déploiement facile. Les gros mutus sont d’une autre époque, en fait. Proposer un déploiement simple sans drames de dépendances est l’objectif. La réponse ultime est bien sur le conteneur (le concept, hein, je ne parle pas d’implémentation). Les paquets systèmes ont failli pour déployer des services, mais ils gardent toute leur pertinence comme briques de base pour composer un service. La norme existe : CNAB, reste à peaufiner les implémentations.

La facilité de mises à jour avec un rollback facile est un prérequis. Si on déploie, on met à jour. Sinon, ce sera du site statique.

Visibilité

La visibilité, que ce soit les incidents ou les mesures (ce que ça fournit niveau métier, ce que ça mange), doit être systématique. htop et grep /var/log ne sont plus suffisants, hein. Sentry, même avec sa nouvelle licence est votre ami.

Arrêtez de tanner les gens avec des comptes et des mots de passe qui seront soit tout le temps le même, ou oubliées. Mozilla a lâché l’affaire avec son SSO, ce qui est frustrant, mais JWT ou OAuth sont maintenant bien diffusé. Par contre, il faut un retour en grâce d’OpenID, pour ne pas tout appuyer sur l’OAuth d’un des GAFAMs, ce qui serait un drame.

L’usine nouvelle

Arrêtez la comparaison industrie/artisanat pour l’informatique. Un service installé à la main, sur un serveur installé avec un CD, ce n’est pas comparable avec du pain ou un meuble d’artisan. La valeur de l’installation est dans la rigueur, les choix techniques, la connaissance de l’ensemble pour prendre des choix éclairés, pas dans la sueur et la vélocité des commandes tapée sur un clavier typematrix. Faites votre levain, et provisionnez vos serveurs. L’installation c’est le prélude, l’histoire, c’est la maintenance et les mises à jour de nouvelles fonctions.

Gmail n’a pas gagné par ce qu’il était meilleur, mais par ce que les offres du logiciel libre ont échoué.

Déployer des microservices avec des dépendances

2018-12-01T14:09:00+01:00

Microservices

Le principe de bases des microservices est simple : une application est composée d’un ensemble de services, qui peuvent discuter entre eux.

La règle de base étant que ces microservices puissent avoir un cycle de vie (et de déploiement) autonome.

Si vous devez déployer plusieurs microservices d’un coup, bravo, vous avez un monolithe distribué.

La confusion entre microservice et conteneur

Attention, il n’y a absolument pas de ratio un pour un entre microservice et conteneur. Un service peut être rendu par plusieurs conteneurs, regroupé ou non en pod. L’exemple typique étant le site web et son traitement asynchrone (rails+sidekiq, flask+celery …). Les serveurs de bases de données peuvent être mutualisés, tant qu’on ne touche pas à la sacrosainte isolation des bases.

Versionning

Un service peut consommer un autre service. Les différents microservices sont versionnés, que ce soit avec un hash git tout moche, ou un joli semver.

Même s’il est possible d’appeler un service par son nom, il est quand même sage d’avoir un graphe des différents services : qui consomme qui. C’est l’approche des links de Docker-compose, Kubernetes préférant l’anonymat des Services.

Les services sont des boites, la version du service doit rester privée, ce qui est public (et concerne les autres services), c’est la version de son API.

Du coup, chaque service peut réclamer un autre service avec une version d’API.

Un peu comme de la gestion de bibliothèque, quoi, on retombe sur le pattern bien maitrisé de gem/yarn/dep/pip et compagnie.

Pour chaque service, on peut déterminer sa version d’API, et la liste des services avec les versions minimum attendues. Ces informations peuvent être rangées dans des étiquettes des images (des labels docker, quoi), ce qui permet de retrouver simplement l’information sur un environnement live.

La procédure de déploiement peut débuter par un preflight : on vérifie que le service que l’on souhaite déployer va trouver les services consommés dans les versions attendues.

Intégrer le preflight, à titre informatif, dans son cycle d’intégration continue, est une bonne idée : “attention, là maintenant, votre service n’a pas les prérequis pour être déployé en prod, il va peut être falloir discuter avec l’autre équipe”.

D’un autre côté, présenter une API, mais sans la déployer, ce n’est pas super fairplay non plus, ça sent le refactoring qui a du mal à aboutir.

Déployer à blanc

Pour limiter les embrouilles de chronologie de déploiement pour des histoires de dépendances, chose que l’approche micro services promettait d’éviter, il ne faut pas hésiter à déployer des services à blanc, en déployant des bouts d’API qui ne seront consommés que par des tests fonctionnels. On déploie d’abord un serveur sans clients, puis dans un second temps les clients.

Le service est déployé, testé, un éventuel test de charge pour évaluer son comportement en charge, ou même déployé en fantôme, avec des clients qui l’utilisent, mais sans le dire, soit en doublon d’un service qu’il souhaite remplacer, soit headless, sans que les utilisateurs le voie. Facebook avait fait ce genre de chose pour son tchat.

Lorsque l’on déploie un service, on se réserve la possibilité de faire un rollback en cas de drame. Par contre, attention, quand on déploie une nouvelle API, qu’on la valide incorrectement, puis en déployant le client qui va la consommer, on se rend compte d’un problème : c’est le drame, le seul rollback possible est une cascade de rollback, ce que l’on souhaiter éviter à tout prix.

Pour les services très fortement sollicités, le déploiement se fera de manière progressive, en gardant les yeux rivés sur les performances et les taux d’erreurs. Le déploiement progressif rend physiquement impossible, ou presque le déploiement par lot. Ça tombe bien, c’est ce que l’on souhaite éviter.

Étendre le concept

Cette notion de version d’API peut être étendue aux modèles de données. La modification devra se faire en deux étapes, la première va ajouter des colonnes, sans casser le code actuellement déployé. Ensuite, on pourra déployer le code utilisant le nouveau modèle, et enfin, déploiement des modifications qui vont enlever des colonnes.

Modifier des colonnes va être un peu plus compliqué. Soit le modèle logiciel (l’ORM, à priori) va assurer la transition en calculant les modifications à la volée, puis en tache de fond, de gros batchs assurent une transition complète, sans subir un phénomène de longue traine. Mongodb se prête bien à ce genre d’astuce.

La migration de modèle est un sujet complet, complémentaire du déploiement. Allez jeter un oeil à gh-ost pour avoir une étendu du sujet.

Déprécier

Effacer des trucs, ça veut dire prendre le risque de le regretter plus tard. À grande échelle, on passe du regret à l’angoisse. Du coup, il est tellement plus confortable d’entasser à l’infini, de se proposer des API avec une compatibilité ascendante depuis le premier jour. Dans le même esprit, on ne rajoute pas de contrainte sur des données stockées (dans l’approche de stockage massif à la HDFS). C’est ce que propose Protobuff et Thrift.

Il est quand même possible de connaitre les versions de clients déployés (en interne), et d’avoir des stats sur les clients externes. Avec ces infos, on peut déprécier l’API, forcer la main pour mettre à jour les clients, puis retirer l’ancienne API. Bazarder du code mort, ça fait toujours plaisir, et ça évitera d’avoir des surprises plus tard. Mettre à disposition un proxy qui fera le passe plat entre différentes versions de l’API peut être un palliatif, mais une coupe franche est nettement plus simple.

Automatiser

Il existe des grammaires pour les différentes API distantes. OpenAPI (ex-swagger), grpc et tant d’autres sont basé sur cette approche. Ce contrat doit être le seul lien entre les différents services, le sujet de discussion entre les différentes équipes. Ce contrat va permettre de générer du code, ou le valider, selon les cultures logicielles.

Avec du code bien rangé, il est possible de lancer automatiquement des tests sur les différents clients quand on modifie le serveur. Trivial pour des tests fonctionnels avec des services conteneurisés, envisageable pour des bibliothèques. C’est là que débute le troll sur le monorepo, mais un sujet orthogonal au déploiement de microservices.

Kubernetes est la réponse, c’est quoi déjà la question ?

2018-06-20T19:23:00+02:00

Drôle d’ambiance autour de Kubernetes, en ce moment. Le Docker bashing à toujours la cote : des gens avec des avis tranchés, qui ont réussi avec arrogance, là où LXC pataugeait depuis toujours, pour finalement aboutir à une norme et des spécifications. Mais, en même temps, Kubernetes, qui est prêt pour la prod, lui, est encensé, attendu comme le messie. Ça donne des tweets de ce genre.

Services

Commençons par le commencement, votre application est orientée service : c’est l’assemblage de différents services. Un truc comme django/celery/postgresql/redis ou même php-fpm/mariadb/memcache/varnish/nginx ou que sais-je dans ce gout-là.

Si votre application est un gros binaire qui contient tout, un peu comme la boite contenant le mouton du Petit Prince, félicitation, vous faites du Zope, vous n’avez pas à vous enquiquiner avec ces histoires de Kubernetes.

Microservices

La question n’est pas là, utiliser des services est déjà suffisant, et ce sera encore plus fun avec des microservices.

Conteneur

Docker quoi, on peut tourner autour du pot, mais même avec la normalisation de l’OCI, Docker est pour l’instant le standard de fait. Le travail d’intégration sur les postes de travail, sur Windows/Mac/Linux, est trop énorme (et trop pénible) pour être paraphrasé par un concurrent.

Un conteneur, c’est juste un format de livraison d’un service standardisé, immuable, et la possibilité de le lancer avec des paramètres, de l’isolation et des contraintes matérielles (RAM, CPU, IO).

Son immuabilité renforce et facilite la mise en place de tests fonctionnels et autres étapes de qualification.

La construction déterministe, et le résultat déterminé facilitent le déploiement, sur un ou plusieurs serveurs, et le retour en arrière en cas de drame.

Les conteneurs donnent aux développeurs la responsabilité de la création du conteneur, il choisit les paquets et applications nécessaires. Ces choix sont décrits de manière simple et lisible, qui seront versionnés, deux points qui facilitent l’analyse statique et les audits.

L’étape de créations des images et les tests/analyses qui suivent doivent être construits depuis un service d’intégration continue.

La recette de build automatique, les versions d’outils explicites, et les différentes astuces pour faciliter le développement diminuent drastiquement le ticket d’entrée pour un nouveau développeur sur un projet. Avec une VM, on comptait un jour, avec des conteneurs, une heure.

Composition

Docker-compose est le standard de fait pour décrire la composition de services, hey wouais, l’OCI n’a encore rien dit là-dessus.

Tout comme le Dockerfile décrit de manière non ambigüe la création d’une image, docker-compose.yml va décrire l’assemblage de différents services, avec les paramètres et les liens entre eux.

L’outil docker-compose va gérer tranquillement tout plein de détails pénibles, comme la création d’un réseau isolé, les dépendances entres services, les logs, et même un peu de scale. Il est bon pour mettre à jour le service que l’on vient de mettre à jour et de relancer les services qui l’utilisent, sans forcément tout relancer.

Techniquement, le fichier docker-compose.yml expose à peu près tous les choix que peut faire un développeur pour décrire son application. Bon, Swarm a un peu cochonné le format, mais ça reste anecdotique. Pour ce qui manque, les labels permettent de décrire les intentions sans trop de difficultés ou de circonvolutions.

Le format du fichier docker-compose.yml permet de générer des configurations vers d’autres outils : - Kompose pour Kubernetes - dce-go pour Mesos - Bon, Nomad est tellement peu opiniated qu’il faudra faire vos choix et votre moulinette.

Supervision

Le service dockerd (containerd dans les faits) est aussi un superviseur, il va suivre et commander le cycle de vie des différents conteneurs.

dockerd empiète un peu sur systemd, et les deux projets aiment ce jeter des cailloux dessus.

Le monde se divise en deux catégories, enfin, le monde, les services : systèmes et applicatif. Les applications s’appuyant sur les services systèmes (en dessous), pour être exposées à des utilisateurs (au-dessus).

Systemd, ça gère la couche système, et seul l’utilisateur root peut le manipuler.

La première cible de Docker est la couche applicative, et n’importe qui avec le bon certificat SSL ou le bon groupe peut l’utiliser. Ça ne veut pas pour autant dire que c’est une super idée d’avoir des utilisateurs qui tripote des dockers en prod depuis la console.

Il est tout à fait légitime d’avoir un service lancé par systemd qui gère des conteneurs systèmes .C’est comme ça qu’est implémenté Kubernetes, d’ailleurs, avec son kubelet, et les namespaces de containerd vont pouvoir encore mieux isoler ces groupes distincts de conteneurs.

Par contre, vouloir orchestrer un ensemble de services formant une application avec un ensemble de fichiers `.service systemd est une drôle d’idée. Les conteneurs sont des fils des docker-containerd-shim qui vont cafter au démon containerd l’état du conteneur, excluant complètement systemd de la boucle, qui serait bien incapable de superviser quoi que ce soit.

Instrumentation

Docker va gérer des services, bien rangés dans des cgroups qui maintiennent des métriques, et branche STDOUT vers une sortie quelconque, un fichier ou un service de logging. 12 factors prétends que ça suffit, mais c’est juste le strict minimum au niveau observabilité.

Il faut passer rapidement à des trucs plus sérieux, comme des rapports d’erreurs avec Sentry, des logs structurés (au format fluentd), des mesures métiers avec les exports prometheus pour les technos asynchrones, et statsd pour les autres.

Routage

C’est bien, d’avoir plein de conteneurs, mais vous allez exposer tout ça, dans la plupart des cas avec une seule IP et un seul port, 443 à priori (pour bien faire, cette IP sera flottante, et vous la collerez à une machine virtuelle en vie).

Il va donc falloir un peu de coordination entre les conteneurs et des règles de routages (et de la répartition de charge).

Persistance

C’est bien d’avoir des conteneurs “quelque part”, qui bougent en fonction des vagues. Mais cette mobilité n’est possible qu’avec des conteneurs sans état, état qui va bien devoir être quelque part. Pour ça, il faut une solution de stockage distribué, en mode blob, à la S3 (ou Minio), ou en mode block, à la iSCSI. Donc, du Ceph ou une offre SAAS spécifique et propriétaire que votre fournisseur de nuage vous proposera gentiment.

Orchestration

Pour gérer un ensemble de conteneurs sur plusieurs machines, il faut de l’orchestration. L’orchestrateur a la charge de décider comment les conteneurs vont être répartis sur les différentes machines, que faire quand un noeud disparait ou quand un nouveau apparait.

L’orchestrateur va s’appuyer sur service clef/valeur distribué (comme etcd) pour mettre à disposition de tout le monde tout ce qui est paramétrage et maintenir une carte de l’existant.

L’orchestrateur va réagir à un ensemble d’évènements, et en réponse à des commandes, déclencher des évènements (et des actions) comme les stratégies de mises à jour des conteneurs, ou la mythique promesse du Cloud : lancer des VM pour empiler encore plus de conteneurs pour accompagner un pic de charge, puis les éteindre tranquillement une fois la vague passée.

Voilà, là, vous êtes à l’étape Kubernetes, et pour ça, vous avez pieusement suivi toutes les étapes précédentes, car vous avez besoin de plusieurs serveurs pour héberger votre application.

La vieille promesse de l’élastique du nuage n’est possible qu’avec de l’orchestration, et donc des conteneurs, de l’intégration continue, de l’observabilité, une séparation nette entre l’expression de l’intention (sous la responsabilité des devs) et les choix de son implémentation (sous la responsabilité des ops).

Google a très envie de manger tout l’hébergement Internet

2018-05-08T17:30:00+02:00

Le marché de l’hébergement Cloud arrive à maturité. OpenStack a réussi à éradiquer tous les pouilleux, la place est libérée pour les trois gros, Amazon, Google et Azure, qui vont pouvoir s’étriper tranquilement.

Le marché du cloud a été découvert par Amazon pour répondre à ses propres besoins. Amazon s’est contentée d’ouvrir son outillage interne, très rapidement organisé en unités autonomes, chacune étant cliente les unes les autres. L’offre d’AWS est un mélange d’outils standards (machines virtuelles, disques distants…) et de services spécifiques dont certains sont maintenant des standards de fait (S3) d’autres non (dynamodb), pour ensuite proposer des services de plus haut niveau, comme les bases infogérées ou les CDN.

Cette offre a parfaitement accompagné la première vague du Web et corresponds tout à fait aux besoins des gros sites américains, qui ont besoin de grosses croissances pour arriver rapidement en position abusivement dominante à l’échelle de l’Occident, pour commencer à être bénéficiaire. Ces sites croissent comme des crabes, chaque changement de carapace correspondant à un tour de table, et il faut devenir bien plus gros. Le fameux “ça scale” tant vanté par le Cloud.

Google a bien vu grandir Amazon, et à toujours eut une technologie plus performante, plus intégrée, plus tout, en fait. Une partie des technos d’Amazon sont issus des white papers de Google. Sauf que Google, à la différence d’Amazon a une approche très cathédrale, très intégrée, très peu ouverte, en fait. Google a zappé l’étape des machines virtuelles en passant directement aux conteneurs (les CPUs n’étaient pas près quand la question s’est posée) bien plus efficaces pour densifier, et tout à fait compatible avec un partage non agressif, coordonné des ressources.

Google, une fois ses services bien installés, a su faire des efforts pour avoir des clients qui consomment ses services (Android, Chrome), mais a été longtemps une grosse quiche pour ses offres d’hébergement. Google semble tout simplement inadapté pour reprendre une idée qui n’est pas la sienne. Un peu comme les humiliations de Google+ ou pire, Google Wave.

Par contre, leurs services sont bons : gmail, calendar, docs. Ils sont surtout encore meilleurs pour bosser en groupe, et remplacent des outils forts pénibles et corporate, comme la suite Microsoft, ou pire encore, IBM Lotus. Outre leur ergonomie agréable, ces outils éradiquent les BOFH, craints par tous, direction comme utilisateurs. Avec ces offres orientés pro, Google à mis un pied dans l’entreprise.

Donc, les services sont bons, les clients sont bons, que reste-t-il à récupérer dans la chaine de valeur? Les serveurs, pas les siens qui sont optimums depuis une grosse décennie, mais ceux des autres.

Première vague, Google App Engine. Google reprends son approche interne, les applications sont contraintes, mais bénéficient d’un ensemble de services de très bonne qualité (comme la BigTable). Sauf que non. Les utilisateurs n’ont que faire de contraintes les obligeants à réinventer la roue alors qu’ils existent tant de trucs open source permettant de sortir trop tôt un gros tas de boue mal fagoté. Les services proposés sont effectivement mythiques et permette de scaler plus haut que sa carte bleue, mais le ticket d’entrées (technique) est rédhibitoire, tout ça pour un truc captif aux performances fluctuantes.

Entre temps apparait Docker, qui réassemble de manière cohérente les bouts de kernel que Google à écrit pour sa propre solution de conteneur, LMCTFY. La première appropriation du logiciel libre des conteneurs, LXC, n’était guère plus qu’un gros POC myope. Docker apporte la notion de services composables, immuables et paramétrable, et, arme secrète, Docker fonctionne très bien sur les ordinateurs des développeurs (Linux, Mac et Windows à égalité), et c’est en fait le premier critère pour l’adoption d’une nouvelle technologie.

Google manque terriblement d’empathie, ils sont capables d’inventer des tas de concepts, mais sont incapables de se mettre au niveau des gros ploucs de développeurs. Ou des gros ploucs de pipelettes des réseaux sociaux, d’ailleurs.

Ils ont du coup mise en place une nouvelle approche, un peu comme leurs withes papers qui deviennent des outils utilisables par le reste du monde. Ils prennent une de leur technologie interne, qui à eut le temps de bien maturer, et ne conservent que les concepts ou les parties bas niveau (comme les patchs kernels) pour les confier à des gens extérieurs, des gens bizarres avec des sentiments. De fait, ils exfiltrent eux même leurs technologies, en petits bouts autonomes. Ils ont réussi ça avec golang, qui a une vraie communauté, et qui a d’ailleurs servi de base à Docker, et à toute une génération des services de bas niveau. Cela dit en passant, un des gros échec d’OpenStack est python, tout à fait inadapté à ce genre de tache, mais bon à l’époque, les autres langages disponibles (java, C++) auraient aussi été un drame.

Donc, pour attaquer l’hébergement, il faut d’abord un socle, et faire des concessions aux ploucs. C’est l’offre Google Cloud, qui expose une couche super standard : de la machine virtuelle avec KVM (avec comme effet de bord de faire chier AMZ qui a choisi l’autre virtualisation, Xen, qui n’est pas dans le kernel vanilla). Réel effort de la part de Google qui n’utilise pas de virtualisation en interne. Ensuite les trucs de base, comme le réseau, les disques distants, du stockage objet compatible S3, du routage, du SQL infogéré, quelques services qui envoient du rêve (à base de big data et de machine learning).

Voilà, ça, c’est le ticket d’entrée pour commencer à discuter. Pour avoir des utilisateurs et donc du débug, Google utilise la technique super classique, une offre massive de crédits à des startoups ambitieuses, des incitations à la création de sociétés de services qui ne font que du Google Cloud, des espèces de franchises, en fait. Pour montrer leur humanité, Google met en place un système astucieux de conseil sur le dimensionnement des services pour que l’on crame moins de sous. Un peu comme une cafétéria qui conseillerait de ne pas remplir son plateau pour pas que ça finisse à la poubelle, en fait. Payer ce que l’on utilise, ça semble bête, mais ça le différencie de AWS, qui eux ont pour motto “la carte bleu comme seul limite”.

Voilà, Google a aussi son offre Cloud crédible, mais comment aller plus loin? la guerre des prix avec AWS est un peu vaine, et ce genre de blague finit souvent en victoire à la Pyrrhus. Non, la cible n’est pas d’aller tout de suite vers le coût marginal et la notion de commodité (pas les WC, le barbarisme traduisant “commodity”). La cible est d’aller là où il y a des sous, d’aller s’occuper des DSI et de l’hébergement de leurs serveurs.

Pour ça, Google est en train de déployer la tactique finaude du tapis de bombe, le carpet bombing des années 1940.

Première vagues, les services, gmail et Google Docs, les utilisateurs veulent du Google et trouvent ringard les services existants.

Deuxième vague, l’hébergement classique. Techniquement, la notion de VM n’est qu’une transition, c’est compliqué, dur à dimensionner, dur à maintenir au fil du temps. Comme solution plus adéquate, il y a bien sûr les conteneurs, standard maintenant officialisé par l’OCI et installé sur tous les postes de développeurs. Docker est mature coté dévelopement, mais pas encore coté hébergement, pour ça, il faut de l’orchestration, et il y a maintenant Kubernetes, offre exfiltrée à partir d’une techno maison de Google, Borg, qui devient tout aussi standard et officiel que les conteneurs de l’OCI, mais dans un autre consortium, le CNCF, avec ses amis Envoy (pour le routage) et Prometheus (pour les mesures).

Kubernetes est open source, bien spécifié, bien maintenu, plein de vie. Pourquoi se méfier de son coté captif? Tout simplement par ce qu’il est tout aussi complexe à héberger qu’un Ceph dont tout le monde vante l’open source sans pour autant le déployer. Kubernetes va éradiquer l’offre Docker Swarm qui n’a jamais convaincu grand monde, et débarquer par défaut sur tout les postes de dev avec le très confortable minikube. Kubernetes a besoin de s’appuyer sur des services de persistances (mode bloques et objets), bien pénible à héberger. En partant de bare metal, il faut donc assumer un Ceph en plus de Kubernetes comme ticket d’entrée.

C’est de plus en plus visible : la notion d’open source fusionne avec la notion de standard et de portabilité. L’hébergement de Kubernetes, même si on garde le choix entre 3 mammouths est de fait propriétaire, tout en gardant le développement open source. L’open source se fait commodifier la gueule, en fait, mais avec le sourire. L’open source est utilisé pour faire chier les autres, Microsoft peut en témoigner.

Une bonne vague d’hardware inaccessible, pour continuer à distancer la concurrence (gpu haut de gamme , tpu) toujours basée sur des frameworks bien libres comme Tensorflow.

La prochaine vague, déjà bien amorcée, est le serverless, un buzzword pour imposer un framework n’exposant que du code métier, facilitant de fait l’hébergement (et basé sur des conteneurs encore plus densifiés).

Une vague de métrologie, avec OpenCensus qui va permettre d’unifier les mesures privées (les services fournit par Google), avec les mesures publics, dans le code déployé.

La vague suivante va être la sécurité avec gVisor pour les conteneurs, et Asylo pour les enclaves.

La tactique est des plus classiques. On abuse de l’exclusivité tant qu’on peut, tout en démolissant la marge de la génération précédente de technologie, tout en maintenant un cout d’entrée énorme, pour exclure les nouveaux entrants. Ça permet à la fois de réduire ses propres coûts tout en asséchant la concurrence. On a ainsi vu récemment passer la libération des frameworks de machine learning, en mode terre brulée (Google, Nokia, Microsoft…), pour finalement se concentrer sur la vente d’hébergement avec du matériel spécifique (les fameux TPU), ou “as a service” pour les utilisateurs aux compétences limités : AutoML.

À l’époque de la ruée vers l’or, le meilleur moyen de devenir riche était de vendre des pelles (avec l’exclusivité), pas de creuser. L’offre Cloud de Google nous vends des pelles.

La tokenisation et les index inversés au service de la lecture des logs

2018-03-07T19:23:00+01:00

Les logs servent à remplir les disques (souvent) et à déboguer (parfois), mais pas que. Logstash a démontré que l’on pouvait entasser des logs dans un moteur de recherche pour faciliter les analyses postmortem d’incidents. On peut aussi compter des trucs et des machins pour faire de jolis graphes, voir même, en lâchant des sous, avoir des alertes avec alerting. Elasticsearch propose aussi la notion de percolate avec ses recherches à l’envers. Les notions existent et sont même déjà implémentées (en Java).

Voici une présentation pédagogique, avec une implémentation toute légère en golang, pour chercher des motifs dans des flots de logs : Yangtze 长江.

Concept

L’idée de base est d’enregistrer des requêtes, et de leur soumettre des lignes de log. C’est la percolation d’Elasticsearch.

Pour ne pas tout bouffer la RAM et le CPU, les expressions régulières ne seront surtout pas utilisées de manière systématique.

Même si Grok permet d’écrire des regex concises et compréhensibles, même si RE2 limite le bazar des très classiques PCRE, les regexps restent un marteau qui scalent mal. C’est vrai, Piwik (enfin, Matomo) l’a prouvé avec son parser de user-agent.

Indexer une expression régulière oblige à la déplier, et c’est rapidement pénible à faire (du code ruby existe et fonctionne plutôt bien), pour un résultat peu concluant.

L’idée est de découper le motif en jetons (en tokens, en mots, quoi), et de les utiliser pour indexer les requêtes. En découpant les lignes de logs en jeton, on peut retrouver les requêtes correspondantes, et ne tester le motif que sur les lignes qui ont les jetons nécessaires.

Implémentation

Motifs

Plutôt que d’aller se coincer dans du vrai regex, je pars sur un sous-ensemble minimaliste :

. un jeton
? zéro ou un jeton
... plusieurs jetons

Tokenisation

La tokenization est tout aussi brutale, les jetons sont constitués de lettres, de chiffres, de _ et de -. Tout le reste, ponctuation, parenthèses, espaces… est considéré comme des séparateurs.

Je [mange] des carottes.

Va donner :

Je
mange
des
carottes

Les tokens qui sont indexés (ceux des requêtes, pas ceux des lignes) sont rangés dans un tableau, et un identifiant (un simple compteur) leur est attribué. Par convention, les identifiants commencent à 1, 0 est réservé pour gérer le rien, un token qui n’est pas indexé.

Avec la tokenisation et les identifiants, on peut transformer une ligne en une suite de nombres.

"a ... c" => [1, 0, 2] // un motif
"a a b c" => [1, 1, 0, 2] // une ligne

Bitset

Les bitsets sont de longues suites de booléens, leur rang correspond à leur valeur. Par convention, le 0 est toujours false. Avec un bitset, on ne peut savoir que si un jeton est présent ou non, on perd sa position et son nombre d’occurrences. Par contre, il est facile d’effectuer des opérations booléennes, des opérations sur des ensembles, ou compter le nombre de bits allumés (on parle alors de cardinalité).

"a ... c" => ◻︎◼︎◼︎
"c . a" => ◻︎◼︎◼︎
"a a" => ◻︎◼︎◻︎
"a a b c" => ◻︎◼︎◼︎

Une ligne avec une cardinalité nulle ne matchera jamais, première simplification.

Si le bitset d’une requête n’est pas inclus dans le bitstet de la ligne, on sait que ça ne matchera pas.

set("a ... c") ⊂ set("a a b c")
set("c . a") ⊂ set("a a b c")

Si ces deux premières conditions sont passées, on peut tester le motif (en travaillant sur les suites de nombres).

pattern("a ... c").match("a a b c") == True
pattern("c . a").match("a a b c") == False

Pour limiter le travail, les requêtes sont indexées par jetons. Pour l’instant, le jeton de la ligne utilisé pour tirer les requêtes potentielles est le premier. Pour bien faire, il faudrait trier les jetons par occurrence, et choisir le moins courant (et donc le plus discriminant).

Performance

Les performances de regexp de golang, basé sur RE2, sont très bonnes. Tokenizer une ligne, vérifier si le motif correspond est plus que de tester une expression régulière. Mais ça tombe bien, ce n’est pas le cas d’usage, on tokenize une fois, exclue puis test le motif plein de fois. Obtenir l’identifiant d’un jeton est super rapide, travailler avec les bitsets et vérifier les motifs sont aussi super rapide, bien plus qu’une regexp. Le cout de la tokenization (qui gère de manière orthodoxe l’UTF8) est très rapidement amorti quand il s’agit de tester une brouette de motifs.

Préparer une ligne est 4 fois plus long que de lancer une regexp, mais tester un motif est presque 10 fois plus rapide.

Bon, un benchmark est toujours un peu raide et rien ne remplace un vrai usage.

Usage

Avoir de jolis tests unitaires et des benchmarks, c’est bien, avoir du code utilisable, c’est mieux. Le premier usage sera de surveiller des flots de logs (tail, journald, fluentd…) pour soit lever des erreurs qualifiées (sentry, alertmanager, alerta), soit compter des trucs qui finiront dans du timeseries. Des actions à la fail2ban sont potentielement envisageable.

RPC

2018-01-22T22:16:00+01:00

RPC

Les RPC existent depuis longtemps, ils ont leurs heures de gloire (CORBA, SOAP), et de déchéance (CORBA, SOAP). Ils reviennent sur le devant de la scène avec l’invasion de Javascript au dépens des templates cotés serveurs, et surtout des micro services.

Techniquement, un RPC, c’est : une sérialisation, un protocole, une couche transport. Certains RPC proposant différentes sérialisations (une binaire, une texte), et même différents transports.

Sérialisation

La réponse magique est JSON, ce qui est un progrès par rapport à la réponse magique XML, d’il y a 20 ans. Mais le JSON est ambigu, chaque langage et même chaque bibliothèque va gérer de manière différente chaque point mal spécifié. Il ne gère ni différencie pas les entiers des flottants, ni les nombres en 64 bits, le binaire doit passer par du base64 et donc prendre plein de place.

BSON corrige le JSON en ajoutant de nouveaux types et un format binaire, mais il reste très lié à Mongodb.

MessagePack fait peu ou prou la même chose, mais de manière neutre, sans être lié à un produit.

On reste dans la famille des sérialisations auto descriptive, qui permet techniquement de faire un peu n’importe quoi de chaque coté d’un RPC.

Cette approche prend beaucoup de place, avec Mongodb, il n’est pas rare que les clefs prennent plus de place que les contenus.

Avro propose une approche intermédiaire. On envoie la grammaire, en JSON, puis le contenu en binaire, bien compacte.

La mode est maintenant à la sérialisation avec grammaire. Cette grammaire étant neutre, elle peut être utilisée par différents langages pour effectuer les sérialisations/deserialisation. Ces grammaires sont incrémentales, il est possible d’ajouter des informations, sans casser la compatibilité avec l’existant.

Petite collision de date, Google avait déjà son protobuff (qu’il utilisait bien au-delà des RPC) quand Facebook a publié spécification et implémentation de référence pour son Thrift, fort similaire. Protobuff a été libéré après Thrift.

Pour aller un cran plus loin dans la recherche de performance, il existe des sérialisations qui ne sérialisent pas, et permettent le zéro-copie, ce qui est fort pratique pour les RPC locaux, directement en mémoire, sans réseau. Apache Arraow et Cap’n Proto font ce genre de chose.

Protocole

La première étape est la notion de question du client au serveur, et la réponse correspondante, dans l’autre sens.

REST

REST n’est tout simplement pas un protocole RPC. C’est un standard largement diffusé, le meilleur ami de curl, mais ce n’est pas un RPC.

REST permet d’exposer rapidement des données hiérarchisées, pas plus, et GraphQL (quand il sera sec) est bien parti pour lui ravir cette niche.

Des formalisations comme Swagger (maintenant OpenAPI) sont clairement les bienvenus, et même indispensable, mais ne suffisent pas à définir de bout en bout les échanges. Du code spécifique côté client et serveur reste indispensable, et fragilise l’ensemble.

ElasticSearch reste le parfait exemple des limites de REST : le protocole/sérialisation ne brime pas les performances, par contre, les fonctions spécifiques comme les batchs, la pagination, la gestion du cluster, rendent indispensable l’utilisation des drivers officiels.

Docker a le même souci, avec son truandage pour gérer les flots TTY, et ils sont en train de tout re-ranger en grpc avec Containerd, pour faciliter les échanges de serveur à serveur.

Multiplexage

Les connexions ne sont pas illimitées, que ce soit des clients web vers un serveur, ou même en interne, avec le nombre de connexions simultanées que peuvent ouvrir les technologies asynchrones. Le multiplexage s’impose assez vite. Les requêtes ont des identifiants, et les réponses arrivent dans l’ordre de leur résolution.

XMPP a formalisé cette approche avec ses stanzas, tout comme JSON-RPC.

Flot

Les RPC sont confrontés aux mêmes problèmes que les Big Data, où il faut choisir entre le gros débit des traitements par lots (Hadoop), et les faibles latences des flots (Spark, Storm).

La gestion de flot facilite le multiplexage, limite la taille des buffers, et permet de commencer tôt le traitement du message.

HTTP/1 propose une gestion de flot descendant, avec EventSource, mais rien en flot montant, il faut alors dégainer Websocket. Hum, est-ce bien raisonnable d’utiliser WebSocket pour de la communication de serveur à serveur?

HTTP/2 gère le multiplexage, et permet la gestion de flot montant et descendant.

Finagle, de Twitter, propose un RPC complet basé sur Thrift, mais surtout explique bien la notion de multiplexage, de streaming et de méta information. Finagle a publié beaucoup de lecture pédagogique indispensable, mais il est fortement lié à Scala, et même à Twitter, en fait.

Méta information

Les RPCs ont besoin d’informations complètement différentes de ce qui sera utilisé par les fonctions exposées. La notion de format, de trace, d’authentification, de chiffrage et de compression par exemple. Toutes les belles choses que l’on est habitué à utiliser avec HTTP, en fait.

Parralélisation

On est habitué aux contraintes d’HTTP qui a l’habitude d’imposer des temps de réponse courts, et de se faire couper en cas de “timeout”. Les RPC n’ont pas les mêmes contraintes sur les temps de réponse. Les langages synchrones sont alors brimés par la difficulté de paralléliser des taches de durée très variables. L’implémentation de GRPC en python, par exemple, travaille avec un pool de 10 connexions, ce qui n’est pas farfelu si on garde la règle magique de 2 workers par coeur de processeurs. En augmentant le pool, on prend le risque d’avoir des traitements avec peu d’attentes IO et de faire exploser le load.

De toute façon, la notion de file d’attente devra être géré, soit par le langage qui va accepter plein de connections, soit via un service spécifique, comme Redis, RabbitMQ, nsq, kafka…. Les services de file d’attente permettent de faire de jolies choses, souvent pénibles à reproduire dans son code, comme la répartition de charge ou la reprise de traitement en cas de vautrage. Google a une sainte horreur des serveurs de file d’attentes, déjà qu’il n’aiment pas les proxy, car il se focalise sur la course à la latence. Twitter semble les suivre dans cette approche.

Débogabilité

Déboguer un RPC bancal peut rapidement devenir un enfer.

Traces

Il est indispensable d’utiliser une gestion d’erreur centralisée (à la Sentry), des métriques (statsd ou des compteurs Prometheus), et rapidement des logs unifiés, des traces en fait, comme le proposent OpenTracing (Zipkin, Jaeger, Appdash…).

Ligne de commande

Il est difficile de se passer du confort de curl + JSON, tous les RPC de la galaxie proposent un équivalent, avec plus ou moins de complétion et de retour d’erreurs.

Sniffer

Encore plus culte que curl, il existe tcpdump, pour filtrer et voir passer un flot sur le réseau. PacketBeat propose de jolies bases pour construire un sniffeur.

La généralisation de TLS, même sur les réseaux privés rends ça rapidement pénible.

L’approche sniffing est du débogage en boite noir, il est tellement plus simple d’être dans la place, et de profiter de l’approche boite blanche, comme Google le préconise : ticket grpc et tecpdump.

Finagle confirme cette approche avec Twitter-Server, mais comme Finagle n’impose pas TLS, il est possible de tricher : thrift-tools.

Rapidement, les RPC vont être distribués (sur plusieurs serveurs), il est assez illusoire de penser pouvoir attraper l’ensemble des flots pour ensuite isoler celui qui nous intéresse. Bricoler son Mysql/Postgres/Mongodb ou autres services tiers pour avoir du log spécifique n’est pas la meilleur des idées, dans ce cas, le pcap est légitime, mais pour du code qui nous appartiens, avec la possibilité d’utiliser des middlewares ou pires des proxys, ce serait dommage de ne pas en profiter.

Transport

Les rpc ne sont pas forcément fascinés par la couche transport, mais la plupart s’épanouissent dans HTTP, la garantie de pouvoir circuler sur internet sans drame, et sans faire crier les firewalls corporates. Il existe des transports plus spécialisés, comme zeromq, nats ou même plus exotique comme STOMP.

Hum, peut-on considérer un broker comme une couche transport? Dans ce cas, Kafka et AMQP en font partis.

HTTP/2 permet de profiter de l’héritage HTTP/1 (Internet, proxy…) mais le protocole est bien récent, et les bibliothèques pour le gérer ne sont pas bien répandues. C’est mature pour des serveurs webs (nginx, traefik…), pour des clients (Chrome, Firefox…), mais pour du code, golang écrase un peu tout.

Ceinture et bretelle

Rien n’interdit d’exposer une fonction avec différentes approches.

Les usages sont trop divers pour qu’une seule réponse universelle puisse être envisagée. Les interfaces utilisateurs sont maintenant en HTML5 avec beaucoup de Javascript, et proposent des interfaces utilisateurs réactives. Il est donc indispensable d’utiliser HTTP pour les UI web. L’outillage HTTP2 en javascript est pour l’instant introuvable, il faut donc basculer sur les plus classiques HTTP/1.1 et ses extensions, comme SSE et surtout Websocket.

Pour les appels internes, HTTP/1 est un peu court des pattes et va poser des problèmes avec les parallélisations massives que permettent les technologies asynchrones.

L’approche la plus saine me parait de surtout se concentrer sur l’utilisation de grammaire neutre, qui permettent de générer (ou d’introspecter pour les langages qui n’aiment pas le code écrit par des robots), les clients et serveurs, et même de générer plusieurs protocoles pour une seule fonction exposée.

Twirp propose cette approche après s’être cassé les dents sur du grpc, qui reste pourtant la référence de ce genre d’approche.

Grpc fait des choix plutôt autoritaires pour présenter ce que Google estime être l’état de l’art. Personnellement, aucun de ces choix ne me frustre, c’est plutôt le manque de maturité des bibliothèques qui m’inquiètent. Les fonctions avancées de la bibliothèque golang n’a pas de numéro de release, avec une documentation légère. La bibliothèque Python embarque un gros machin en C pour gérer toute la partie HTTP/2, avec un pool de workers. Je suppose que les autres langages sont dans le même état. Par contre, je n’ai aucune inquiétude sur la pérennité de cette technologie et sur le fait que les bibliothèques vont évolués, et surtout que tous les langages vont avoir l’outillage requis pour gérer comme il faut HTTP/2/

Il existe une passerelle Grpc/REST, Grpc-gateway qui permet d’exposer une fonction, en utilisant la grammaire grpc, sous deux formes, du REST avec la documentation Swagger, et du Grpc.

La couche HTTP/2 n’est pas forcément la réponse universelle, pour certains projets discrets, utilisant un grand nombre de connexions, le surcout en RAM peut être pénalisant. Le projet a fait le choix d’utiliser un protocole différent (du TCP sans stream), et de générer le code avec les grammaires GRPC.

Bref

L’informatique est maintenant distribué, que ce soit sur des coeurs de processeurs, ou des serveurs. Les RPC sont maintenant indispensable (ne serait-ce que par la traction des UI complexes en Javascript), mais le domaine n’est pas encore stabilisé.

En l’état, la seul recommendation sans risque est d’utiliser des grammaires pour déclarer ses APIs, et d’instrumenter son code (log, erreurs, métriques).

Persister les conteneurs

2016-11-28T09:34:00+01:00

Isoler

Les conteneurs permettent d’isoler les ressources utilisées par des services, et avec un peu de discipline, offrent la promesse d’utiliser au mieux un groupe de machines.

Distribuer

Distribuer des services est maintenant un classique, pour ne pas dire un prérequis. Par contre, il faut ensuite assumer; surdimensionner pour assurer quelques pics devient rapidement un problème de place, mais surtout de puissance électrique.

La distribution permet d’avoir plus de ressources à disposition, mais aussi d’assurer plus de résilience, en proposant plusieurs instances de chaque service, capable de prendre le relai en cas d’incident, ou tout simplement de démarrer un nouveau service sans états, pour remplacer un autre défaillant.

L’élastique dans le nuage

Le cloud nous promet cette élasticité, mais la taille efficace d’une machine virtuelle est bien trop grosse pour un découpage propre, alors que le conteneur a lui, la taille et la mobilité requise.

Les ressources nécessaires fournies par la machine aux services sont le classique triplet : processeur, mémoire, stockage. Triplet que sait bien border un conteneur. En faisant attention à avoir du code immuable et versionné, il est possible d’avoir plusieurs instances d’un même conteneur, sur une ou plusieurs machines. Mobilité et ubiquité que sait bien gérer un conteneur.

Orchestrer l’utilisation des ressources

Il est possible de gérer un ensemble de conteneurs, avec un nombre d’instances fluctuant.

Pouvoir optimiser cette fluctuation permet de dépasser le taux ridicule d’utilisation de la plupart des datacenters : 15%. Une gestion efficace des ressources est l’arme secrète de Google, Borg. Enfin, l’une des armes secrètes.

Le principe est simple : on met à disposition un ensemble de ressources, on commande ensuite des ressources, et un planning est établi. Des outils sont mis à disposition permettant la coordination ou la découverte de services, qui, couplés à des proxyies, permet la mise à disposition publique des services.

Google a publié, sur le tard (une dizaine d’année après sa mise en place), leur approche avec de la gestion de cluster avec Borg. Ils insistent beaucoup sur la différence entre les tâches longues (qui ne doivent pas s’arrêter), et les taches éphémères (sensibles aux latences).

Mesos a été une des premières implémentations libres de planification de ressources, mais il vise gros, et propose de généraliser ce que proposait le YARN de Hadoop. Si vous ne comptez pas vos ressources en rack ou en datacenter, il faut chercher autre chose.

Des choses comme Nomad (le sage), Swarm (le tonitruant), ou Kubernetes (le conquérant).

Ces outils sont utilisables sur une poignée de serveur, et en se basant sur des serveurs dédiés, ou des clouds frustres, il est possible d’être bien moins cher que des clouds toutes options.

Persister

La partie pénible dans l’usage des clusters est la persistance, distribuer le travail n’est finalement pas si complexe : le loadbalancing naïf est la première étape, avant de passer à de la parallélisation et au fameux map-reduce.

Le stockage dans un environnement distribué est un problème de cohérence, latence, et de débit.

Il n’existe pas de réponse absolue, mais un ensemble de choix et de tuning. Le théorème du CAP résume cet ensemble de contraintes, et l’obligation d’en choisir deux parmi les trois lettres Consistency, Availabiliy et Partition tolerance.

Le cas du conteneur

Docker (et rkt) proposent gentiment d’emballer une application, pour pouvoir la versionner, et la déployer simplement. Une généralisation du WAR de Java, quoi. Le prérequis est d’avoir une application en lecture seule. Il est ensuite possible de monter des volumes au sein des conteneurs, pour proposer des dossiers en lecture/écriture. Sauf que ces volumes montés n’apportent ni l’ubiquité, ni la distribution, et seront liés à un serveur. Un conteneur permet d’abstraire et de généraliser plein de choses, mais pas la persistance. Pour un système distribué, c’est ballot.

Qui est le responsable du stockage?

Première décision, la persistance est-elle de la responsabilité du système d’exploitation l’application ?

Disques distants

Le moyen le plus simple pour déporter le stockage est d’utiliser un disque distant. Ce disque pourra être démonté puis remonté sur un autre serveur, il est mobile, mais n’existera qu’en un seul exemplaire. Pour peu que le serveur propose des instantanés, il sera possible d’avoir du COW, et de monter des réplicats du disque sur d’autres noeuds.

Tous les clouds proposent un service de ce genre, avec de l’iSCSI par exemple. Openstack fournit une liste indigeste des disques qu’il peut utiliser en mode bloc. Il est possible de redonder ce genre de disque, côté client, avec un simple RAID, ou côté serveur, avec de la magie, si c’est un SAN.

Il n’existe pas grand-chose en libre comme serveur iSCSI. Il existe le vénérable NBD, et le plus récent xNBD, prévu initialement pour du netboot. Coreos bosse sur Torus, un serveur NBD distribué, utilisable dans quelques années?.

Le Graal étant le rdb de Ceph (qui a rejoint le giron de RedHat), montable en NBD ou en Fuse. OVH propose maintenant du Ceph as a service.

Pour les aventuriers, il existe des systèmes de fichiers distribués(OCFS2 d’Oracle, GFS2 de Red Hat… ), permettant l’ubiquité d’un même disque monté sur plusieurs serveurs. En dehors du calcul scientifique, on trouve peu d’exemples d’usage de cette approche. Pour garantir la cohérence des données, un serveur de verrou est utilisé, garantissant des problèmes de performance pour les écritures concourantes.

Il existe des abstractions exposant une API unique vers diverses implémentations, comme Flocker ou Cinder.

Fichiers distants

Le partage en mode fichier permet un accès à distance, mais aussi multiple, à un ensemble de fichiers. NFS et Samba, que seul Azure préconise en sont les exemples les plus classiques.

Le partage de fichier est fort pratique, mais, pour assurer des performances correctes, certains raccourcis sont pris : une partie des engagements requis pour un système de fichier UNIX ne sont plus assumés.

Toutes les bases de données dédient une page de la documentation pour promettre d’atroces souffrances à qui osera mélanger NFS et base de donnée : Postgres et NFS, Cassandra et NFS

L’architecture de NFS commence à dater, et ce n’est pas un, mais un ensemble de services qui sont utilisés, pas forcément prévu pour un environnement hostile comme l’est le cloud. NFS ne prévoit rien pour la distribution du stockage.

Les serveurs NAS haute dispo, comme celui proposé par OVH, sont souvent des baies de disques connectés en optique avec deux serveurs, l’un ou l’autre serveur pourra utiliser la baie, du RAID assurera la redondance des disques, une double alimentation, la redondance d’énergie, mais en cas d’incident sur la baie, bah, pas de bol, vous avez perdu.

Des implémentations propriétaires, comme l’EFS d’Amazon permettent d’avoir de la redondance et de la distribution.

Pour les acharnés du partage en mode fichier, il existe le tant redouté GlusterFS, récemment racheté par RedHat. La prochaine version majeur, GlusterFS 4 sera d’ailleurs en Go et utilisera Etcd. On voit son nom apparaitre de temps en temps, comme l’offre un poil daté d’Acquia.

L’incontournable Ceph propose aussi un partage en mode fichier, mais cette option semble un peu boudé, c’est pour le mode bloc qu’il est réputé. Gitlab l’utilise pour son offre SAAS mais ils ont souffert de la non-homogénéité des IO des clouds publiques, et sont passé à du bare metal.

Objets distants

Assurer un stockage distribué, aussi à l’aise en lecture qu’en écriture, sans corrompre les données, fut une des premières questions que Google dut résoudre, et surtout la première révélation des secrets de Google. Le white paper sur le Google File System fut publié en 2003. Il servit de base à la création du HDFS du projet Hadoop.

Le principe est simple, les fichiers sont immuables, mais versionnés. Il n’est pas possible de modifier un fichier existant, on va en créer une nouvelle version, et par défaut, on lira la dernière version disponible.

Le premier service d’AWS, au-delà de la simple VM, fut un service de persistance distribué, S3. Le Dynamo paper expliquant la notion d’anneau virtuelle pour une architecture sans maître avec de la redondance, fut publié en 2007.

Pour S3, les fichiers sont immuables, versionnés, redondés, accessibles directement en HTTP.

Aucun cloud digne de ce nom n’ose sortir sans proposer un clone plus ou moins compatible de S3.

Tous les frameworks webs décents sont maintenant capables de gérer les uploads sur des stockage objets, avec des bibliothèques comme CarrierWave ou paperclip.

Toutes les bases de données savent (ou devraient savoir) maintenant faire des snapshots dans des stockages à la S3.

Swift

Le clone de référence est Swift d’OpenStack. Son architecture est extrêmement simple, à la limite du naïf, en python très classique. Ils ont une excellente réputation sur la qualité de leur API, et la fidélité avec l’API du S3 d’AWS.

Riak-S2

Il existe aussi le moins connu Riak-S2, une surcouche au Riak de Basho, libéré il y a quelque temps. C’est une architecture Erlang contemporaine, au code particulièrement pédagogique et étonnamment lisible, compte tenu de la complexité du bestiau.

LeoFS

Pour les fans d’Erlang, il y a aussi LeoFS. Par contre, je ne sais pas trop qui l’utilise en dehors de Rakuten, leur sponsor.

Minio

En ce moment est en train d’émerger Minio, il propose une belle UI Web, mais surtout un serveur, en Go, ce qui change du Java et de l’Erlang.

Son accueil enthousiaste vient du fait qu’il scale bien à un. Ce serveur est utilisable sur un seul serveur, et son image Docker juste marche.

Il gère tellement bien un seul serveur que la version distribuée n’est pas encore finie.

Par contre, il est capable de gérer une grappe de disque, et d’assurer de la redondance avec le code de Reed-Solomon, utilisé par le système RAID pour les disques, et vulgarisé dans un article par Backblaze, le plus grandiose des entasseurs de disques durs. En gérant eux même la parité, plutôt que la délégué à du RAID comme tout le monde, ils peuvent réparer objet par objet, et pas par volume.

RADOS Gateway, de Ceph

Le dernier, et pas des moindres, est RADOS Gateway de Ceph. Ceph met à disposition sa solution de stockage RADOS, sous les trois approches : blocs/fichiers/objets.

Base de données

Le stockage objet met un pied dans le plat. Il casse la compatibilité du système de fichier UNIX, pour proposer quelque chose de plus adapté aux environnements distribués. Du coup, l’application continue d’écrire sur un disque local (les essais de stockage sans FS d’Oracle ou Mysql ont fait un flop), mais vont se charger de la distribution avec réplication, répartition, cohérence, réparation…

Avoir une application distribuée, correctement implémentée est difficile. Le projet Jepsen propose un framework d’analyse et publie ses analyses de différentes versions d’applications. Le résultat des analyses est souvent “call me maybe”, et il y a ensuite des corrections de l’application autopsiée.

Base de données relationnelle

Les bases de données relationnelles sont toutes capables de gérer de la réplication, en utilisant le très classique modèle maître-esclave. Postgresql a quand même attendu la version 9 pour proposer ça en natif, sans passer par un produit tiers.

Pour répartir les données sur plusieurs machines, il faut passer par du sharding, ce qui va poser des problèmes pour faire des jointures sur des données dispersées. Le sharding est traditionnellement applicatif, et fonctionne mieux sur des données bien isolées, comme des utilisateurs, par exemple.

Citusdata propose d’améliorer Postgresql en lui mettant à disposition :

un stockage orienté colonne
du sharding avec Citus
un moteur de requêtes distribuées
des approximations statistiques pour des calculs massifs

Les conteneurs adorent les applications sans états, indifférenciées. Ce qui est l’opposé des bases de données relationnelles.

Multi-maître

Pour ne pas avoir à gérer la différence maitre/esclave, et la complexité de la promotion de maître à esclave, puis de créer un nouvel esclave, il est possible d’utiliser de la réplication multi maître.

Postgres sait maintenant faire ça avec BDR.

Mysql propose des outils similaires, comme Galera et proxysql, ou des trucs plus emballé comme XtraDB Cluster de Percona.

Ces outils sont sympathiques, mais rien de prévu pour pour pouvoir redimensionner simplement.

Pourtant, des solutions propriétaires existent, comme Aurora d’Amazon, basé sur Mysql, avec de gros efforts pour conserver la compatibilité et disponible dans leur offre RDS, ou le mystérieux F1 de Google, reservé à AdWords.

Le modèle relationnel n’est juste pas prévu pour fonctionner de manière distribuée, mais de gros efforts sont faits pour, par contre, les applications vont devoir faire des compromis pour s’adapter. En posant un Wordpress sur un Cloud, on ne pourra pas s’attendre à de miracle.

Je fait bien la différence entre le modèle relationnel et le SQL, le langage, qui lui peut parfaitement être distribué. Des outils comme Drill de la fondation Apache, Presto de Facebook ou même Spark SQL.

Base de données NoSQL

Les bases NoSQL ont été inventées pour remettre en cause le dogme relationnel.

Bon, elles ont ensuite fournis baucoup d’efforts pour s’en rapprocher, le SQL restant une lingua franca pour explorer des données, et pouvoir se brancher dessus en JDBC/ODBC est toujours appréciable.

Le NoSQL a aussi été conçu pour pouvoir profiter d’un hébergement distribué.

Le monde du NoSQL est tout récent, Darwin n’a pas eu le temps de faire le tri pour trouver ses champions. Voici une sélection arbitraire de bases de données, qui fonctionnent à des tailles raisonnables. La partie élection, pour avoir une archi sans maître, peut être plus ou moins laborieuse.

La première chose que va sacrifier une base NoSQL est la notion de transaction.

Mongodb est la plus visible des bases NoSQL, et avant la version 3 et le stockage Tiger, est plutôt pénible à administrer. Le pattern de distribution est classique, un système d’élection pour avoir un master, et un proxy qui va assurer le routage vers le bon serveur. La distribution du travail se fait avec du classique map-reduce.

Cassandra est une base de données orientée colonnes, avec un presque SQL, le CQL, sans jointures ni sous-requêtes, mais avec du map-reduce. Créé par Facebook pour manger du log, il fut ensuite confié à la fondation Apache, pour passer à autre chose : Presto et Hbase, et une autre stack pour avaler leurs logs. Cassandra, même s’il est civilisé, reste une base conçue et dimensionnée pour du big data.

Scylladb est un clone C++, agressif et ambitieux de Cassandra, mettant un point d’honneur à saturer des réseaux 10Go, le kernel, les CPUs et des disques NVMe tout en conservant la compatibilité avec Cassandra.

Elasticsearch est une base orientée documents, distribués, avec des beaux index et une interface REST. Initialement conçu pour la recherche full text, il a évolué vers les calculs d’agrégations, et poursuit vers le machage de logs. Elasticsearch est parfaitement à l’aise avec les principes de distribution et de réplication, tout en restant crédible à partir de 2 noeuds.

Le stockage se distribue bien, se réplique bien, mais se bouge mal

Les containers sont tout à fait capables d’assurer la persistance, locale ou sur du partage en mode blocs. Par contre, les orchestrateurs ont bien envie de rééquilibrer le cluster en déplaçant les containers dans tous les sens. C’est tout à fait légitime pour des containers sans états, un contre sens pour du stockage.

Il faut alors revenir aux vieux principes décrits par Borg et Hadoop : les données sont fixes, les process peuvent bouger.

Les orchestrateurs sont maintenant capables de faire attention à ne pas déplacer les données, pour pouvoir profiter pleinement des performances locales.

Le stockage local est le plus performant, le mode bloc offre une simplification et un confort appréciable, le mode objet permet une pérennité incomparable et un scaling sans trop de limites, le mode fichier n’a plus sa place dans un environnement web.

Le phénomène Docker expliqué aux adorateurs de la Terre plate

2016-10-17T09:20:00+02:00

Si vous aimez jouer au buzzword bingo, vous avez bien remarqué que Docker est un mot compte triple. Vous allez l’adorer, le détester, ou adorer le détester. Comment un machin si récent peu déclencher autant d’engouement ? Pourquoi les gros du cloud (abrégé en GDC) se prosternent devant lui, ou monte une équipe pour lui casser les genoux et lui rappeler sa place?

TL;DR

Une architecture web est composée d’un ensemble de services, ensemble que l’on doit pouvoir utiliser à différents endroits, du poste de dev, à l’intégration continue, et finalement les serveurs de prod, en un ou plusieurs exemplaires.

S’abstraire du matériel

Avant de râler que s’était mieux avant, mieux vaut le définir, ce avant, histoire de parler de la même chose.

Les machines virtuelles

Les machines virtuelles n’ont jamais été qu’un mensonge. Qemu propose vraiment de la virtualisation, lui. Il isole complètement l’OS invité de la machine, et ce, à la vitesse d’une tortue qui a trop mangé de poutine.

Tous les outils utilisables de virtualisation (KVM, Xen, Virtualbox, hypervisor… ) sont en fait de la paravirtualisation, le kernel invité est adapté à ce que fournit son hôte, et s’appuie sur des fonctions spécifiques du processeur. Il est d’ailleurs impossible de virtualiser de la virtualisation en mélangeant des technos.

Le vrai mensonge n’est pas là, mais dans le “Rien n’a changé, tout est comme avant, un serveur virtuel s’utilise comme un serveur physique, c’est kifkif”.

Même si l’accès à la RAM sera dédié, le processeur sera partagé ou alors gâché avec de l’épinglage (du pinning, quoi). Dans tous les cas, les cartes réseau et disques durs seront partagées. La tragique conséquence est le classique phénomène du voisin bruyant.

De faux drivers permettent d’accéder de manière isolée à des fonctions du matériel, comme l’horloge ou le générateur d’aléatoire. Mais les vrais paranoïaques n’ont pas de voisins (allez lire la doc de SecureDrop).

Autre partage pénible, les IPs, que l’on doit soit router (niveau 4 ou 7) caché derrière un LAN, soit gaspiller de l’IPv4, bientôt plus rare qu’un panda en liberté.

Mais au fait, pourquoi virtualiser ?

La réponse est simple, on virtualise pour isoler.

Isolation qui permet de

limiter la portée des bêtises (erreurs ou agressions)
mélanger des versions d’OS et d’avoir des cycles de mises à jour indépendants, voir même utiliser différents OS, pour les plus créatifs
installer des logiciels ou des bibliothèques dans des versions non compatibles
ne pas mélanger les pommes et les oranges, aka co-tenant
garantir une répartition plutôt équitable des ressources

Tout ça permet donc d’entasser plein de choses sur un même serveur, on parle alors de densification.

Ces entités isolées, abstraites de la couche matérielle peuvent être manipulées :

redimensionnement (RAM, CPU, Disques)
déplacement d’une machine à l’autre, pour rééquilibrer, ou mettre à jour le matériel
snapshot et restauration
Jouer à jour/nuit avec des cycles de vie courts, pour faire des tests, des benchmarks, des essais
Ajouter de la puissance pour tenir la charge d’un évènement, comme un passage à la télévision
Lancer des lots violents de calculs, de manière ponctuelle

Les limites de la virtualisation des machines

Les machines des développeurs

Il est complexe d’amener les machines virtuelles sur les postes des développeurs, et super pénible de gérer une grappe de serveur. Ça reste lent, ça bouffe des tonnes de RAM, le partage de fichier pour une édition local est mou des genoux, le watch de fichier ne marchera pas forcément. C’est ballot, tous les OS proposent maintenant de la virtualisation de série, bhyve dépote sur Mac, mais, étonnement je n’ai jamais vu de dév Linux utiliser KVM.

Rebelote pour faire des tests fonctionnels ou même unitaires utilisant un service (comme une base de données), avec en prime des surprises comme ah tiens, Xen ne veut pas de Virtualbox.

Vagrant est un excellent outil pour systématiser la mise en place de machines virtuelles. De toute façon, il est ridicule de travailler directement avec Virtualbox (ou l’un de ses concurrents), et même criminel si l’on travaille à plusieurs sur un même projet. Entendons-nous bien, je suis un grand fan de Vagrant, mais il est au top, il n’y aura rien après, Otto, son successeur a été sabordé.

Vouloir simplifier la stack du développeur en ne travaillant qu’avec des services directement installés en local a rapidement montré ses limites. Le temps de setup est énorme, la bascule d’un projet à l’autre est souvent la garantie d’écraser des données, et la flemme du commun va empêcher d’utiliser des outils qui sauvent le monde comme Redis ou Elasticsearch. De toute façon, qui utilise le même OS que le serveur cible sur sa machine locale? Une Debian stable en poste client?

La taille des tranches de virtualisation

La virtualisation fonctionne bien, et est très largement utilisée, mais elle a un ticket d’entrée, avec moins de 2 coeurs et 2 Go de RAM, ce n’est plus une VM, mais un jouet (AWS appelle ça T2, pour flatter). Dédier une machine pour des services peu gourmands, reviens vite hors de prix, sans compter la place disque occupé par l’OS (et l’application) sur la machine physique si l’on n’a pas de système de COW, qui reste complexe à mettre en place.

Du coup, on se rabat sur le classique entassage sur une même machine, mais avec quelle garantie d’isolation (sécurité et ressource)?

Même si la haute dispo est heureusement réservée à des applications très spécifiques (brrrr, des gros mots comme HAlinux, drdb, heartbeat, pacemaker…), il est maintenant classique d’avoir des applications distribuées. Une base de données répliquée en master/slave est courante, un Elasticsearch est malheureux tout seul. Pour pouvoir espérer tenir un pic de charge, il faut tout simplement que l’application métier puisse être déployée sur plusieurs serveurs.

La notion de services

Les architectures actuelles sont de plus en plus riches. L’indétrônable LAMP, qui a permis à Wordpress de conquérir le monde est maintenant détrôné.

On garde le classique service de persistance (la base de données, quoi), le service applicatif, puis un service pour stocker des fichiers (FS local, ~~GlusterFS~~, un S3 like), mais aussi un service de mémoire partagé (Memcache, Redis…) pour gérer le cache, les sessions, les évènements. Pour travailler avec des timeout décents, on va utiliser un service de taches asynchrones (~~cron avec wget~~, Sidekiq/Celery/Beanstalk…). De la recherche full text avec ~~Solr~~ Elasticsearch. Un machin pour gérer les websockets par ce que son langage chéri est bien incapable de gérer de l’asynchrone, Un petit Logstash pour manger les logs, un Sentry pour les erreurs, un Statsd pour les compteurs de performances, un Cuttlefish pour les mails transactionnels, un Pootle pour les traductions… Et là, je ne parle que de services Open Source que l’on peut déployer, et pas des services en ligne, les fameux SAAS.

La décrépitude du système

Server rots

— Ori

L’entropie mange le monde, c’est comme ça, et c’est prouvé par Pr Ian Malcom dans Jurassic Park : ce n’est qu’une question de temps, mais ça va partir en sucette.

Au fil du temps, son petit serveur d’amour, nommé en suivant un champ lexical spécifique, installé avec amour et inspiration, va commencer à sortir du champ de rationalité, il va continuer de fonctionner, bien sûr, mais il y aura des changements subtils, des innovations, des corrections sauvages, mais, promis, temporaires. Et au bout de suffisamment de temps, il va devenir un snow flake, unique et inreproductible comme un flocon de neige. Plus on entasse de choses, plus on bataille pour prolonger une version d’OS dépassé, plus le décollage sera rapide.

La seule solution est d’avoir un système immuable, construit de manière reproductible avec une recette, en précisant les quelques dossiers capables d’écrire, pour assurer la persistance.

Et Docker dans tout ça ?

L’isolation par la virtualisation est couteuse, et il n’y a aucun intérêt à avoir un système complet pour accueillir un service.

Il faut revenir à quelque chose de simple, de très UNIX en fait : demander au kernel d’isoler des process.

Chroot existe depuis toujours, et cgroups a été initialement conçu par Google il y a maintenant 10 ans.

Rajoutez à ça un système de fichiers en oignon, comme AUFS, pour mutualiser la place occupé sur le disque dur et avoir des mises à jour tranche par tranche.

Pour répondre à la ribambelle de questions que je viens d’énumérer, la conteneurisation apporte une réponse différente (et potentiellement complémentaire) à la virtualisation.

LXC

Petit incident de parcours, ces éléments ont été utilisés pour construire LXC (wouaaais) le chantre du Fat Container (Oooooohhhh). Plutôt que de travailler avec des process, comme tout le monde, LXC a trouvé très malin de singer un système complet, avec un init et une grappe de process, vous savez, “comme avant”. Pour parfaire le tout, LXC est livré avec une stack réseau en DIY (démerde-toi, en VF). Ubuntu a bien essayé de sauver les meubles avec son LXD, mais non. La simulation d’OS que propose LXC est très différente d’un OS même virtualisé. Faire des tests fonctionnels dans LXC en espérant que ça ressemblera à la cible, non LXC, est la garantie d’un drame. De toute façon, LXC, avant LXD est trop pénible à mettre en place pour du dev/test. Et LXD, ça veut dire Ubuntu, et du coup, grosse flemme de lui laisser une seconde chance. Surtout que LXD ne remet pas en cause le fat container, et la concurrence, elle, fonctionne.

Docker, qui avant d’être un projet libre, a utilisé TOUTES les technos de contenurisaton disponible sous Linux, une à une. Au moment de sa libération, Docker était une surcouche à LXC. En utilisant dans un vrai cadre ces outils (avec des tonnes de clients et des brouettes de devs dédiés), Docker a vraiment utilisé LXC, qui n’était qu’un gadget un peu reloud. Ca a permis de trouver plein d’horreurs dans le code du kernel, et les corrections qui ont suivis ont abouti au mythique 3.11, la première version offrant de la conteneurisation décente. LXC a été jeté au profit de bibliothèques maisons, en Go, qui utilise des fonctions avancées du kernel.

Docker

Donc, première révélation aux haters : Docker n’existe pas. Docker se contente d’utiliser des fonctions du kernel, sans le patcher, et d’autres outils bas niveau pour proposer une solution cohérente de conteneur. D’autres outils proposent leurs propres solutions de conteneurisation en utilisant les mêmes briques de bases.

De toute façon, Docker n’existe pas, ce n’est qu’une API basée sur runc, l’implémentation officielle de l’Open Container Initiative (crée grâce à la saine polémique lancée par Rkt).

Donc, pour ceux qui ne suivent pas, Docker, c’est un process lancé dans un chroot avec le kernel isole ou partage un maximum de choses.

La conquête

Docker a choisi une stratégie bottom top. Sa première cible a été les développeurs, les postes clients. Je ne sais pas si c’était leur stratégie, mais clairement, leurs premières victimes ont été des développeurs.

Docker propose une api CLI élégante, une API REST logique, et surtout une très bonne documentation, des évangélistes de prestiges, comme Petazzoni ou Jess Frazelle (qui bosse maintenant chez Mesos).

Immuable

Une image n’a pas vocation à conserver ses données modifiées. Pour ça, il y a les volumes, des dossiers en RW qui existe hors du container.

Les images sont définies par couches, et si l’on suit la tendance actuelle, la première couche sera une debian stable, commune à toutes les images.

Il est possible d’avoir plusieurs instances d’une même image dans sa grappe de machine.

Les réglages spécifiques à une instance doivent passer par des variables d’environnements, et non les classiques fichiers de conf.

Tous ces points (une image immuable, configurée depuis l’extérieur, avec quelques dossiers explicites qui assureront un stockage non volatile), permettent de conserver une même image pour les tests d’intégration, préprod, et enfin la production, limitant au maximum le drame des tests qui passent dans un environnement, mais pas dans un autre.

La recette Dockerfile

Docker permet un système simple de recette, Dockerfile, pour construire ses propres images, et le Hub pour aller piocher dans un catalogue. Bon, on y trouve tout et n’importe quoi dans ce hub et il est sage de se contenter des repos officiels. Ces images publiques sont fort pratiques pour du dev, plus polémique pour de la prod.

On ne met pas à jour une image, on la reconstruit. Voilà, contre l’entropie, la reconstruction.

L’approche en pelures d’oignons du filesystem permet de profiter d’un cache tacite. Pratique, mais pas suffisant, il y a actuellement du travail qui est fait pour améliorer le cache, sans affaiblir la sécurité.

Dockerfile est la solution par défaut pour construire une image, mais il est possible de se débrouiller autrement.

Le multi OS

Pour achever les dernières poches de résistance, Docker, qui fonctionnait déjà très bien sur Mac dans un Virtualbox (merci l’archi client/serveur) a développé la première appli connue utilisant la toute fraiche API de virtualisation de MacOS (basé sur un produit FreeBSD). Même effort coté Windows, mais c’est un monde que je ne fréquente pas.

La composition de Docker-Compose

Docker a clairement dit que le fat container était une mauvaise idée (voir le troll de Phusion), et vante l’approche “service par conteneur”. Pour une application complète, il faut donc plusieurs conteneurs, configurés, décrits simplement dans une recette. C’est ce que propose Docker-Compose.

Docker à distance

Docker est basé sur une architecture client/serveur, qui utilise une socket UNIX, ou une authentification par certificats. Il est donc possible de laisser son docker client causait avec un docker daemon, distant.

C’est ce que propose Docker-machine, qui permet d’utiliser de la virtualisation ou du Cloud.

Tous les gros du Cloud proposent une offre spécifique à Docker, qui, en proposant une abstraction pour distribuer des services, met à mal le côté captif des différents Cloud.

Docker en cluster

Une fois son application bien rangée en petit conteneur, il est tentant de la distribué sur plusieurs serveurs, voir même d’avoir quelque chose de mouvant, que ce soit pour accompagner une montée en charge, ou pour survivre à une panne d’un des serveurs.

C’est ici que ce positionne Docker-Swarm, mais aussi Kubernetes, Nomad, Mesos.

Docker-swarm propose d’utiliser la même API pour gérer un ou plusieurs serveurs, et de laisser un algo se débrouiller pour répartir les services et élire des masters des services, si besoin.

Avec sa dernière release, Docker a mis le bazar en allant s’attaquer aux offres d’hébergements distribués. Par ce que bon, humilier LXC ou Vagrant, tout le monde s’en fout un peu, par contre, s’attaquer à de vrais produits qui génèrent de vrais sous, comme Kubernetes, c’est une autre histoire. Surtout que cette version 1.11 semble avoir été sorti un peu vite, sans trop se soucier de réutiliser des choses existantes.

Ce qui marche avec Docker

Docker, sur un poste de dev, c’est un nouveau dans une équipe qui peut commencer à bosser dans 1h, avec Vagrant, il fallait compter 1 jour.

Pour l’intégration continue, Docker est pour l’instant sans concurrence, surtout que l’on n’a pas à simuler ce que va utiliser le dev, mais on va prendre la même configuration.

Docker est un fan de 12 Factor, il permet de déclarer simplement comment lancer un service, et se chargera des logs et de son cycle de vie.

Pour compiler, et encore plus avec des outils trop récents (Golang, je pense à toi), ou des trucs qui veulent installer des tonnes de paquets en *-dev, Docker est magique, on monte le dossier courant comme volume de travail, et paf, ce qui se fait là bas, atterrit ici.

Pour les instances à la demande, comme ce que permettent les notebook de Jupyter, il est tentant d’utiliser des images contenant tout le bazar (les scientifiques n’ont pas la même notion de packaging que les développeurs).

Pour installer une application composée de plusieurs services (tout ce qui est à peine plus complexe que phpmyadmin, quoi), la mettre à jour, puis la bazarder, Docker a peu de concurrents.

Ce qui n’est pas sec

Docker a décidé de se friter avec Systemd, c’est une querelle de personnes, mais aussi une concurrence. Mais bon, j’en cause dans un autre billet: Quis custodiet ipsos custodes?.

Par grosse flemme, Docker a décidé de ne pas gérer de compatibilité ascendante entre son client et son serveur. Quand on est sur la machine où se trouve le daemon, ce n’est pas grave, c’est le même paquet, à distance, ou pour les APIs tiers, c’est une autre histoire.

Pour la gestion de plusieurs machines, c’est actuellement la bataille, avec Google qui a envie de mettre en valeur son propre Cloud qui permet d’avoir le Kubernetes le plus beau du monde. Nomad et Mesos visent les très gros trucs, et Docker ne veut rien lâcher de sa conquête de l’Univers, et pour cela, il est prêt à aller trop vite.

Les APIs peuvent changer brutalement et potentiellement tout défoncer les produits tiers.

Ce qui est de la mauvaise foi

Docker c’est pourri par ce qu’on ne peut pas mettre à jour openssl

Une image est immuable, et ne dois pas être mise à jour sur place. Il faut donc une nouvelle image de l’application. Avec le système de couches, il suffit de repartir d’une image système à jour, et de redéployer.

Le souci est le même pour tout ce qui est compilation (hors bibliothèque partagé), et donc Java, Scala, Golang… Même drame pour les frameworks.

La réponse à ça est le baking.

De manière générale, il est assez criminel de demander à un dev de pousser une image depuis son poste de travail. Il est nettement plus sage d’utiliser de l’intégration continue, et donc d’avoir un combo build+test automatisé, pour redéclencher la création d’une nouvelle image.

De toute façon, un apt-get upgrade ne marche qu’un temps (sur deux versions d’OS, grosso modo), et même les langages (PHP, je te vois!) ne sont pas maintenus jusqu’à la fin des temps.

Avec les architectures distribuées, vous allez vous retrouver avec un service frontal qui va assurer le proxy/routage des services. Le classique Nginx/HAproxy/Traefik/Caddy/… qui va bien, et qui va affronter Internet, faisant rempart de son corps devant l’application. Ce proxy HTTP pourra être mis à jour, indépendamment du cycle de vie de l’application.

La mise à jour d’openSSL sera nécessaire pour dans la grande majorité des cas à une utilisation client, pas serveur. Mais en parlant de ça, savez-vous si l’application va accepter des réglages débiles (comme le fit Ruby), ne pas vérifier la concordance entre le nom du serveur, et le nom du certificat (comme le fit Python), si le pinning et la révocation sont gérés?

Je ne veux pas sur mon infra une image qui sort du cul d’Internet

Clairement, c’est une bête idée de lancer un binaire sans un minimum de crédibilité. Coup de bol, une image polie doit être fournie avec son Dockerfile, et donc, de fait, ses sources permettant de la construire.

Ce problème est de plus en plus générique. Qui a envie de recompiler Elasticsearch après avoir relu le code, ou même MongoDB?

De toute façon, c’est celui qui construit qui répare. Un dev peut très bien bosser avec une image “postgres:9.4” sur son poste de travail, mais rien ne vous oblige à la déployer. Son service a besoin d’un service Postgres dans la version 9.4, bah, coïncidence, c’est la version packagé Debian, et vous avez tuné avec amour sa conf et sa réplication. Si vous êtes de bonne humeur, vous pouvez même construire votre image Pg, basée sur “debian:stable”, avec les réglages que verront l’utilisateur. Image qui servira en dev, et pour le CI.

Docker, ce n’est pas secure

Oui, clairement, la surface d’attaque entre la virtualisation et la conteneurisation n’est pas comparable, ni leur maturité.

Par contre, il y a un souci pour la virtualisation qui va protéger l’hôte, et les autres VM, laissant libre ce qui se passe au sein de la VM. Visualisez un alien qui se faufile dans le véhicule blindé, ok, il aura du mal à sortir, mais pour les passagers, ce sera une autre affaire.

La taille minimale des VMs oblige à y déployer plusieurs services, la contamination de l’un d’entre eux pourra mettre en danger les autres.

Il y a deux réponses à ça.

En plus de l’isolation permise par Cgroups et les Namespaces, Docker permet d’utiliser simplement l’arsenal classique de Linux : Apparmor/SELinux, les capabilities et seccomp.

Apparmor est déployé par défaut sur Ubuntu (et est plaisant à utiliser), mais Seccomp est peu utilisé en dehors de Chromium. Docker est un évangéliste de ces technos soit ignorés, soit méprisés.

Seconde approche, mise en évidence par Rancher et CoreOS, utiliser la tactique de ceinture et bretelles, en mettant des containers dans des machines virtuelles (grâce à la délégation de droit que permet KVM). L’idée n’est pas d’avoir du un pour un, mais d’isoler les services critiques ou au moins de les séparer.

De toute façon, vous n’êtes pas tenu de faire du co-tenant sur vos serveurs.

Docker, ça tourne en root

Oui, c’est un poil reloud. Par contre, le root dans les images, c’est juste une histoire de flemme, et d’ailleurs Kubernetes refuse maintenant les images sans utilisateur dédié.

Pour l’hôte, c’est une limitation de Linux, qui bosse sur ce sujet, et une partie des outils sont déjà possibles sans privilège. Docker piaffe d’impatience d’avoir son outil qui puisse fonctionner sans root.

Juste pour le plaisir de dire du mal : ping a besoin du compte root, lui aussi.

Docker c’est pourri, je ne peux pas me connecter en SSH pour déboguer mon service

Ni pour y faire un apt-get upgrade, on a compris.

Un conteneur utilise les namespaces pour isoler son process hôte, mais il est tout à fait possible, lors de la création d’un conteneur d’utiliser les mêmes namespaces qu’un conteneur existant. On parle de side kick container (Robin qui vient déboguer Batman, quoi). Un conteneur peut ainsi stracer un autre.

Je vous invite à RTFM nsenter.

Je parle bien de conteneur en général, rien de tout ça est spécifique à Docker.

Docker, c’est pourri, ça veut scaler mes services en les clonants, faisant fi des threads

Non, ça, c’est une connerie des 12 factor. Heroku a la flemme de gérer les possibilités de scaling des différents serveurs webs, du coup, hop, la vérité c’est eux, ne vous occupez de rien, on n’a qu’à prendre le plus petit commun. Donc, dans la vraie vie, Docker sait passer les messages UNIX au process, et il se fiche de savoir si votre application fait du fork en COW (comme peut le faire Gunicorn), ou des threads. Rien de vous empeche d’avoir une grappe de process/thread web dans votre container, et quand vous aurez besoin de scaler, d’instancier une (ou plusieurs) grappe, un peu plus loin.

12 factor, qui ont le bon gout d’être pratique et lisible, reste quand même de la propagande post mortem d’Heroku.

Docker, c’est pourri, je ne peux pas sécuriser l’accés à mes services en utilisant des sockets UNIX

Bah, déjà, quand je mets mon Mysql d’un côté, et mon Wordpress de l’autre, je ne peux plus utiliser de sockets UNIX, pour gérer les droits. Pour ceux qui ne sont pas attentifs, mais les solutions de types Heroku sont encore pire, il n’y a pas de notion de VLAN privé, et du coup, tous les services non moisis proposent de l’authentification, même Memcached sait le faire, c’est dire.

Dans les gros boulets ouverts aux quatre vents, personnellement, je vois Statsd (avec son protocole UDP) et Elasticsearch, pour son gossip de cluster. Mais Docker ne vous a pas oublié, il propose un système de réseau extensible, pour créer des sous réseaux permettant de regrouper vos différents services. Pour le reste du monde, ça s’appelle Software Defined Network, et il existe plein d’implémentation libre. Le réseau virtuel est d’ailleurs actuellement ce qui fait la qualité d’un service Cloud (OVH, je te regarde).

Docker, c’est pourri, ça utilise Alpine qui utilise musl que c’est compatible avec rien

Une application à besoin d’un contexte : une arborescence Linux, et un kernel pour accéder au matériel.

Une Debian nue doit faire dans les 125Mo, pourquoi ne pas utiliser quelque chose de plus minimaliste, surtout avec les technos qui ont des traditions d’autarcisme (JVM, Erlang, Golang…)? Alpine Linux est une distribution qui a une approche “embarqué”, basée sur busybox et musl comme libC. 5Mo tout mouillé.

C’est rigolo à utiliser, jusqu’à ce qu’on essaye de compiler un truc non packagé, et que l’on tombe sur du code spécifique glibc. Une image Debian embarque clairement beaucoup trop de bazars pour lancer un seul service bien bordé. Mais bon, ça à le bon gout de marcher, on a la garantie qualité Debian™, et avec le système de couches, l’image de base sera commune à la plupart des images.

Pour l’instant, les images de base sont basées sur Debian, et c’est un choix excellent, ça limite au maximum les surprises de la couche basse, et permet de se concentrer sur le côté trop à jour de l’application.

Docker aime explorer des voies, mais bon, si Alpine vous chagrine, vous pouvez toujours tester Slackware, comme avant.

Dans tous les cas, rien ne vous oblige à utiliser une image que ne vous sentez pas, les Dockerfile sont tellement simples à hacker, ne vous privez pas.

Docker, c’est pourri pour de la prod

Il y a beaucoup de concurrents pour le concours de “pourri pour la prod”, hein. Docker avance couche par couche. L’étape prod distribué, par ce que prod sur un serveur, ce n’est pas non plus super complexe, est son chantier actuel. Docker Swarm est arrivé avec La release 1.12, et a fait hurler pas mal de personnes. Mais bon, on change d’échelle niveau complexité, et Raft, c’est quand même un gros morceaux. Allez demander aux devs de Etcd ou Consul.

Swarm a quand même l’audace de s’attaquer à Kubernetes, la version libre de l’outil interne de Saint Google, quand même.

Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

Voici l’argumentaire “take that, Batman” de Google pour ses conccurents.

Enfin bon, avoir un avis définitif sur un tel outil, sorti fin juillet, c’est un poil hatif. Il est possible d’utiliser Docker sans Swarm, promis!

Docker, c’est pourri

Imprimez des teeshirts et des stickers, c’est efficace avec les slogans.

Docker est opiniated, avance vite, et il fait beaucoup de bruit.

On peut lui reprocher plein de choses (avec des arguments), mais s’il n’y a qu’un seul argument à retenir pour le défendre : Docker est un produit opensource qui explore, code, explique et corrige. Et ça, que vous soyez utilisateur ou non de leur produit, c’est déjà super important.

La conteneurisation fait déjà partie de l’informatique moderne, il va falloir s’y faire.

GraphQL, repenser le modèle de données

2016-09-14T19:07:00+02:00

L’écosystème de React

Caché derrière son blockbuster React (accompagné de Relay), GraphQL est une rafraichissante invention de Facebook permettant de manipuler un modèle de donnée en passant par un petit tuyau. Ciblant clairement les applications smartphones (webs ou natives), GraphQL remet à plat tout un tas d’habitudes et de cargo cult. D’abord utilisé comme arme secrète, il est maintenant libéré, spécifié avec une implémentation de référence (en nodejs) et d’autres implémentations (se basant sur des frameworks largement utilisés).

React fait le choix de franchement basculer un maximum d’intelligence du serveur vers le client, donnant sciemment le pouvoir à JavaScript, le vrai, celui dans le navigateur web.

Les échanges clients/serveurs

Malgré ses velléités d’autonomies, le HTML5 reste massivement utilisé comme une plaisante interface utilisateur connectée en HTTP à un serveur, qui va garder la main sur les données, et coordonner les interactions des multiples clients.

REST

Exposer une API REST est l’approche la plus neutre et la plus ouverte pour mettre à disposition des données et des fonctions via le protocole HTTP.

Par contre, implémenter avec ses petites mains un client à partir d’une API REST est chronophage, fragile, pénible à faire évoluer, douloureux à tester.

Modèle

Les données, côté client sont manipulées sous forme d’objets, mais il faut voir comment faire correspondre le modèle local avec le modèle distant.

Le choix d’utiliser le même langage, entre le client et le serveur, permet de partager le modèle. Il est possible de choisir JavaScript, comme le fait Meteor, ou pire, de choisir un langage tiers, qui sera compilé en JavaScript, client et serveur, comme OPA.

Une variante de cette approche est de garder son langage de prédilection pour le serveur et de ne générer que la partie cliente, comme le presque oublié GWT.

Plutôt que de partir d’un langage spécifique pour définir son modèle, il est plus sage de passer par une grammaire agnostique pour définir modèles et fonctions qui sera moulinée dans différents langages. C’est que propose Swagger (renommé il y a peu OpenAPI, surcouche à REST. Il existe aussi RAML, qui semble avoir moins de soutiens.

Il existe aussi des grammaires neutres, non REST mais pouvant utiliser HTTP comme couche transport, comme Thrift et Protobuff avec son grpc qui vient de sortir en version 1.0, mais lié à la toute nouvelle version 2 d’HTTP.

Toutes ces technologies permettent d’accéder à des données en clef/valeur, ou à des fonctions. Il faut donc implémenter une fonction côté serveur, qui sera utilisé côté client, avec du coup un aller-retour demandant des compétences distinctes.

Réseau et latences

Le premier ennemi des réseaux mobiles est la latence, bien avant le débit. Pour limiter les temps de latence, il faut limiter le nombre de requêtes. Pour pallier aux problèmes de débit, il ne faut rapatrier que le nécessaire pour afficher la réponse. Google, avec HTTP/2 (version normalisée de son SPDY), propose de multiplexer la connexion, sur un canal bidirectionnel qui reste ouvert, permettant ainsi d’envoyer les données sous une forme permettant de les utiliser au fur et à mesure.

GraphQL

Pour optimiser la communication réseau, Facebook se contente de reprendre la tactique du SQL : utiliser un langage concis permettant de sélectionner ce que l’on souhaite, et de préciser les objets et attributs attendus en réponse.

Ce langage de requête est le GraphQL.

La requête est en GraphQL, un nouveau format texte, mais la réponse est classiquement en JSON.

La ressemblance de GraphQL avec SQL est faible, et c’est une bonne nouvelle : il est clairement impensable de confier la rédaction de SQL au client web, de plus, le modèle relationnel, intimement lié à SQL est loin d’être un modèle universel, déjà mis à mal par les ORM et le cache.

Le GraphQL permet de rapatrier une grappe d’objets, avec un peu de dynamisme, surtout pas d’effectuer des calculs sur des regroupements ou tout autres action complexes.

Modèle abstrait

Le GraphQL ne sera pas traité directement par une base de données. Il travaille sur un modèle abstrait et orienté graphe. Facebook est fasciné par les graphes, presque autant que Linkedin, et ça tombe bien, c’est un modèle que notre cerveau arrive bien à appréhender, mais qu’il est difficile d’implémenter autrement que tout en RAM.

L’abstraction du modèle laisse toute liberté aux choix d’implémentations. Des outils sont fournis pour exposer les objets d’un ORM s’appuyant sur le classique modèle relationnel, mais rien n’empêche d’utiliser d’autres modèles, fichier par exemple (MongoDB, Couchbase, Elasticsearch…), voir même les modèles hybrides que nous propose l’intégration de JSON dans Postgresql et plus récemment Mysql. Des outils tiers permettent de faire des serveurs GraphQL dans autre chose que du Javascript, et il faut reconnaitre que l’implémentation pour Python, Graphene, a une bonne tête.

Typage

GraphQL utilise du typage, qui permet de systématiser la validation, mais aussi de l’introspection.

Le typage permet de garantir la réponse attendue, mais il est suffisement souple pour permettre une évolution du serveur sans imposer la mise à jour du client. Fort pratique pour faire évoluer un service pour une nouvelle application sans pour autant casser une ancienne application utilisant le même service.

Il existe un éditeur en ligne, avec une interface sympathique, GraphiQL (notez le i, comme interactif).

Paramètres

Une simple astuce permet de révolutionner ce classique usage de graphes : les attributs acceptent des arguments nommés, il est donc possible d’ajouter du dynamisme (comme une recherche) ou plus simplement du paramétrage (comme une taille d’image).

GraphQL ne va pas utiliser le principe de REST, mais se contenter d’un seul point d’entrée HTTP, /graphql, mais va profiter de la session, avec donc une connaissance de l’utilisateur.

Mutations

Initialement conçu pour un accès lecture seul, GraphQL permet maintenant des mutations.

Requêter simplement

Avec GraphQL, le serveur se contente de gérer le modèle (avec la garantie de cohérence, les droits, la persistance), avec du code métier, des middlewares, tout ce genre de bonnes choses.

Le client pourra librement composer à partir de ces données.

Par dessus, vous pouvez ajouter Relay et React, pour profiter de l’écosystème officiel. Mais vous pouvez utiliser d’autres choses, sans même vous limiter à JavaScript (il suffit de savoir lire du JSON sur de l’HTTP).

Quis custodiet ipsos custodes?

2016-09-01T20:00:00+02:00

Mais qui gardera ces gardiens ?

Où il sera question de Linux, de processus, de conteneurs et de choses gravitant autour.

Processus et daemon

Un serveur regroupe des process, et le premier d’entre eux, celui avec le pid 1 a la responsabilité de lancer tous les autres lors du démarrage.

Certains sont des daemons, des programmes qui tournent en tache de fond, sans interaction directe. Un daemon a la responsabilité d’abandonner ses privilèges, de changer d’utilisateur et de racine (chroot), de causer dans un journal, de noter son PID, et de se détacher, de que décrit si bien Zed Shaw dans Lust.

Init

Historiquement, le rôle d’init est dévolu à init.d, qui accuse méchamment le poids de son âge.

Son principe, finalement simpliste alors qu’il se prétendait simple, est que chaque service est lancé par un script shell, en répondant à quelques commandes : start, stop, status, restart, reload.

Dans les faits, les efforts de l’application sont laborieux, et la qualité de ces scripts est variable pour des applications packagés par le système. Pour des applications métiers, la qualité est tout simplement atroce. Le shell n’a tout simplement pas les commandes nécessaires, et le nébuleux start-stop-daemon est une punition à débuguer.

Il y a eut un peu de tuning, comme le passage de bash à dash pour grappiller du temps, et des efforts de parallélisation. Rien qui n’a pu sauver un init.d finalement en phase terminale.

Superviseur

Des tentatives laborieuses ont été explorées, côté utilisateur, comme daemontools ou supervisor. Ces bricolages permettent de se passer de la danse du daemon, et de se contenter de lancer directement l’application, l’emballage se chargeant du reste. Deux drames UNIX ont perturbé cette volonté de simplification :

Pour utiliser des ports réseaux < 1024, il faut être root, par ce que.
Un utilisateur ne peut pas changer d’utilisateur, ça, c’est du plus facile à justifier. Mais si vous pouvez utiliser un superviseur, qui tourne avec l’utilisateur root, paf, vous pouvez lancer des commandes en son nom.

L’idée du superviseur n’a jamais été traitée complètement, et ces outils inaboutis finiront par vous mordre, tôt ou tard. Supervisor, le meilleur des produits disponibles, dépend de bibliothèques mortes depuis des années, impose des rechargements par grappe, et utilise des actions bien séquentielles.

Pourtant, le Procfile, un simple format déclaratif, est devenus un standard de fait, et est maintenant sanctifié par les 12 facteurs , par le chapitre VI précisément.

Au-delà de chroot

Pour limiter la possibilité de faire des bêtises, un serveur doit avoir un utilisateur, un chroot si on est poli, et … c’est à peu près tout, une limitation sur le nombre de fichiers ouvert? Depuis peu, d’autres possibilités de restrictions sont apparues, comme Apparmor/SELinux, les cgroups, les namespaces, seccomp, les capabilities … Plein de très belles choses permettant de cloisonner proprement les applications. Techniquement, c’est à l’application de gérer tout ça, ou presque, seules les cgroups sont faciles à manipuler depuis l’extérieur.

Plutôt que d’espérer vainement que les applications gèrent proprement toutes ces fonctionnalités, il est nettement plus efficace de reprendre l’idée simpliste des superviseurs, et d’emballer chaque process.

Cette approche, qui sépare l’application de l’isolation de son contexte, permet d’auditer simplement la sécurité, et d’avoir des politiques systématiques. LMCTFY, “Laisse-moi contenariser ça pour toi”, comme on disait chez Google, pionnier de cette approche.

Il suffit de rajouter un système de fichier par couche pour avoir un chroot propre qui prends peu de place, et voilà, vous avez un système de conteneur.

La collision avec Systemd

Parallèlement avec l’apparition des outils systèmes permettant la création des containers est arrivé Systemd, le nouvel init standard pour Linux.

Après quelques concurrents timides à init.d, Systemd a débarqué avec son gros bulldozeur, en choisissant de remettre à plat la fonction d’init, en incluant la supervision et moult fonctions liées. Avec une diplomatie brutale, peu de respect pour les dogmes, et une grande ambition, Systemd est arrivé à se faire haïr comme peu de logiciels avant. En plus, il est promu (et développé) par Red Hat.

Mais bon, les réécritures timides d’init.d n’avait aucune chance, Upstart s’étant vautré, il ne restait plus beaucoup d’alternatives. L’apparition du Cloud a forcé le destin, par ce qu’il consomme énormément d’init, et annihile le culte incompréhensible du dieu uptime. Il est indispensable d’avoir des cycles de start/stop avec les dépendances qui vont bien, rapides et prévisibles.

Debian a sifflé la fin de la récré en incluant systemd malgré le peu d’enthousiasme de ses mainteneurs, suivi par Ubuntu qui a ainsi acté la mort du pénible Upstart.

Le choc avec Docker

Systemd a débloqué plein de choses, mais il a renâclé sur la notion de conteneur, son nspawn étant officiellement un jouet “for debugging, testing and building”. C’est ballot.

Docker a démontré que les outils systèmes étaient valide pour créer des conteneurs, sans suivre la fausse bonne idée qu’est LXC.

Docker, grisé par son succès pense qu’il va être le prochain init, et qu’il faut une guerre ouverte avec Systemd. “Je dis non à tout patch spécifique à systemd” voilà la signature de Jess Frazelle, core dev charismatique et influente, sur son étiquette pour une conférence Dockercon. D’ailleurs, elle qualifie Systemd de 🍑

Forcé à faire des concessions par les applications s’utilisant (ou son concurrent, Rkt), Docker a été contraint d’écrire des specs, Open Containers,plutôt que de tout défoncer à chaque release majeur. Fair-play, ils ont créé une implémentation de référence, runc, qu’ils utilisent maintenant comme couche basse pour leur outil (depuis la 1.11).

Systemd, surtout dans sa version Debian stable (Jessie, donc) n’implémente pas toutes les possibilités d’isolation du kernel Linux, mais collabore très bien avec runc, qui est par concept peu intrusif et plus facile à mettre à jour.

Le déplacement du conflit

Systemd et Docker sont en fait très proche : ils permettent de manipuler des process sur un serveur.

La notion d’application, qui n’a jamais vraiment été autonome est maintenant remplacé par une composition de services. Il est primordial que cette composition soit la même en dev, en test, en préprod et en production.

Autre grande évolution conceptuelle, la notion de serveurs, qu’ils soient virtuels ou “bare metal”, est en train de fondre. Pour pouvoir prolonger la densification, utiliser toujours plus de ressources, et profiter de la fluidité du Cloud, il ne faut plus lier les process à un serveur. Une application est composée d’une arborescence de services. Il y a maintenant un pool de ressources qui seront alloués par un orchestrateur, responsable de palier au crash des serveurs, et de recâbler les services entre eux, de manière dynamique.

Docker est le standard de fait pour la conteneurisation. Docker-Compose est bien placé pour la description de compositions, et Docker, dans sa version 1.12 a décidé de s’attaquer à la couche suivante, avec Docker-Swarm, ce qui a fait hurler tous les produits positionnés sur cette couche-là, la seule permettant de proposer des produits financièrement viables. Docker s’est attaqué ainsi à Kubernetes, du dieu Google, avec un produit mal fini.

Entre cet affront, le clash avec Systemd, le refus de se brimer en suivant des specs, de stabiliser son cycle de vie, des drames de harcèlement moral en interne et surtout l’importance que représente cette nouvelle étape dans le développement informatique, il va y avoir un drame.

Comme un fork.

Golang le bouleverseur

2016-01-25T22:25:00+01:00

Évolution et disruption

C’est dur de traduire le mot anglais “disruption”. Boulversement semble être le terme le plus approprié.

Le progrès, l’évolution, n’est absolument pas linéaire, de temps en temps, plutôt que la douce pente des améliorations, on monte une marche, d’un coup.

Golang fait partie des éléments “bouleverseurs” de l’informatique.

Les trois couches

En informatique, sur la table basse du hardware, on pose un gros gâteau multicouche : le logiciel. Tout en bas, la couche du noyau, tout en haut, la couche applicative. Au milieu, quelque chose de plus indistinct, la couche de middleware (intergiciel selon l’Office québécois de la langue française), les bases de données et les services non-métier.

Dans cette couche, on peut par exemple ranger les proxy, les brokers, les compteurs de métriques, les serveurs de cache/noms/temps… Tout ce qu’il faut pour relier les différentes parties applicatives qui, ensemble, forment une application.

On trouve dans cette catégorie des applications vénérables, éprouvées, indispensables, mais aussi très rigides. Déjà, corriger un bug, puis le maintenir en attendant qu’il passe upstream, peu de personnes peuvent se le permettre, alors écrire un plugin pour mettre du code métier en C …

Au-delà du C

Le C est sacré. Il a été créé pour inventer UNIX, et c’est la plus fine couche possible au-dessus de l’assembleur. Les seules limites sont donc le matériel (via le kernel), et des détails, comme la responsabilité de gérer la mémoire qui est à la charge du développeur.

On se retrouve donc avec les pleins pouvoirs, mais les temps de développement explosent. La vélocité (le ratio fonctionnalité/temps de développement) est un des gros problèmes du C.

Avec des gros processeurs (qui ne coute pas cher) et des petits temps de dev (qui coute cher), le C est hors de prix.

Il faut donc aller voir ailleurs : les surcouches, les langages spécialisés (mais compilés), ou les langages de scripts (mais génériques).

Le scripting

Les langages de scripting ont une vélocité inégalable, mais le surcout en RAM et CPU est loin d’être négligeable, tout comme sa tradition pénible de ne pas savoir utiliser correctement les threads. La réponse officielle pour les soucis de performances est un mensonge : si c’est mou, tu n’as qu’à recodé la partie qui grippe en C. Double mensonge.

La plupart des blocages sont dus à des problèmes d’IO que seul l’asynchrone peut sauver. OK, le SSD peut aider. Viennent ensuite les problèmes de CPU : le surcout de l’interprétation (qui peut être compensé par de la compilation Just In Time) et la parallélisation (faire bosser plusieurs coeurs de son processeur).

Optimiser en C

Le C permet d’utiliser très efficacement son processeur, mais la parallélisation et l’asynchrone ne seront pas offertes en cadeau. Pour appeler simplement du C depuis un autre langage, il existe depuis longtemps des outils génériques : SWIG ou FFI, une API C, et de la transcompilation, mais le mélange reste douloureux et ne facilitera pas la maintenance.

Dans tous les cas, imaginer qu’un bon scripteur fera du bon C est complètement farfelu.

Intégrer du scripting dans du code C (le contraire, donc), est faisable, mais obtenir de bonnes performances peut être complexe, il n’y a qu’à voir les performances de Postgresql avec ses procédures stockées exotiques.

Il existe des solutions hybrides, basées sur Numpy par exemple, qui émergent pour gérer efficacement des aller-retour entre le scripting et le C : Ibis et MonetDB. Mais ce sont des réponses super spécialisées.

Lua

Lua a été le premier a chambouler la frontière entre C est le reste du monde. Conçu pour gérer des configurations complexes d’une application en C en utilisant un modèle de mémoire similaire pour pouvoir partager des variables, il est aussi un langage de scripting plus décent que bien d’autres. Interprèté, simple et minimaliste, avec un JIT efficace, Lua est le chouchou des dév C pour embarquer du code métier.

Il y a en ce moment une vague de logiciels intégrant Lua pour définir le comportement métier :

Torch l’utilise pour faire du calcul scientifique (avec la possibilité d’utiliser le GPU)
Un patch Nginx (packagé Debian, c’est dire sa popularité) existe
Haproxy l’aura dans sa prochaine version stable
Haka sniff son réseau, Nmap le réseau des autres
Sysdig surveille le système d’exploitation avec ses chisels
Redis et ses procédures stockées. Notons la présence d’un dévermineur spécifique
…

Bref ça fonctionne, et bien.

Mais, il y a un mais. Débuguer et tester du lua embarqué peut rapidement devenir apocalyptique. Comprendre le workflow du code en C pour y intercaler ses bouts de scripts n’est pas évident, et il ne sera pas possible d’aller au-delà de ce qu’expose l’application hôte.

Javascript

Javascript a un indéniable côté universel et il propose maintenant de bonnes performances grâce au JIT et ses Arrays spécialisés. Nodejs l’a définitivement rendu crédible hors du browser, mais il est dur de trouver des applications embarquant du Javascript.

Electron est un framework javascript pour créer des applications pour le “desktop”, Javascript y est l’hôte, et non l’invité.
Nginx a du créer son propre interpréteur Javascript : nginScript car les usages prévus par V8 ou Gecko sont trop spécialisés.

Comme langage autonome, Node a surpris tout le monde en démontrant l’efficacité de l’approche asynchrone et la maturité des interpréteurs Javascripts modernes. Par contre, il n’a rien réglé sur la confusion du code et la fiabilité en production. Node a effectué un débroussaillage salutaire, mais sans arriver à atteindre un niveau de sérieux suffisant. Il faut voir ce que va apporter ES6, mais il reste encore beaucoup de travail.

Golang

Conçu pour remplacer le C++ moche, Golang a, contre toutes attentes, été massivement adopté par les scripteurs (python, ruby…) lassés du code linéaire, mou et imprévisible que permet leurs langages pourtant si véloces.

Golang a des partis pris un peu abrupts :

Golang n’invente rien, n’amène aucun nouveau concept. Pas de modèle objet complexe ni même d’exceptions. Quelqu’un sachant déjà coder ne sera pas perdu en découvrant Golang.
Golang est compilé. Le typage est fort, et même le style de syntaxe est imposé.
Golang ressemble à du scripting, la syntaxe est expressive, la compilation rapide, il n’y a pas de gestion de mémoire grâce au ramasse-miette, les bibliothèques systèmes sont généreuses.
La parallélisation et l’asynchrone sont prévus dés le départ.
Golang utilise les types et les structs du C, appeler du code C est triviale avec cgo.

Avec ces choix et ces contraintes, Golang permet de développer efficacement des applications à tous les niveaux du gateau logiciel : des couches basses (comme le fameux Docker), des applications distribuées, des bases de données, du middleware, des applications métiers.

Golang fait sauter la distinction entre le code système et le code métier.

Malgré l’absence de modules dynamiques et de generics, Golang fournit des bibliothèques de grande qualitées : beaucoup d’applications Golang ne sont en fait que des gros frameworks permettant de composer une application, et pas simplement la configurer.

Ces deux derniers points sont tout simplement une révolution.

Avant, les gens se contentaient de tricoter avec des outils existants, où s’arrêtait en route, faute d’outils.

La fin de la loi de Moore, la maturité du cloud et de la virtualisation, les exigences de résiliance, tout pousse les applications à travailler en environement distribué. Ce type d’environnement amène avec lui son lot de complexité, qui nécessite des bibliothèques robustes, et plus seulement des services fiables.

Java a bien prouvé qu’il était possible de cloner les outils révélés par Google (MapReduce, BigTable, Chubby, Borg, Dremel…), mais voilà, Java, quoi. Le ticket d’entrée est élevé, que ce soit en compétence technique et en nombre de serveurs. C’est rentable pour du big data, qui nécessite déjà des machines par palettes entières, mais c’est rapidement impressionnant pour des applications distribuées plus classiques. Les gros fournisseurs de clouds fournissent certains des ses outils, mais comme service, en mode boite noire, la vengeance du logiciel propriétaire contre l’hégémonie de Linux.

Golang a montré que l’on pouvait créer ces outils de coordinations, simplement, et de manière composable, pour ensuite créer des applications distribuées. Cette zone floue entre bibliothèque et service semble impossible en C/C++, un problème de packaging, de divergence d’approche. C’est dommage, des applications distribuées existent, comme les bases de données ScyllaDB, RethinkDB, Aerospike …

Ces applications sont prometteuses, mais sont développés en autarcie, pas moyen d’en recomposer simplement de nouvelles à partir du travail existant.

De son côté Golang propose des briques de base permettant d’agir sur l’ensemble de la stack.

Les bibliothèques de Golang permettent un accès complet aux couches basses, mais le réseau est sa grande force, il gère différents protocoles réseau, au-delà de l’inévitable HTTP : http2, ssh, tls, dns… ce qui permet d’agir à chacune des étapes du protocole. Des outils complémentaires permettent de simplifier l’utilisation de protocoles classiques, comme oxy pour créer des proxy http, yamux pour multiplexer des connexions TCP.

D’autres bibliothèques réseaux, elles, fournissent des outils de haut niveau, comme la coordination sans maitre : raft (Paxos étant jugé trop complexe) ou la communication par potin (gossip) : serf, ou le déverrouillage par double clef : red october.

Par dessus sont construit des outils réseaux de haut niveau : Vulcand, etcd, Consul…

Il faut être honnête et reconnaitre que l’écosystème Java fournit des outils similaires avec Zoo keeper, Akka, Netty, Hystrix, Zuul…, mais on est clairement à une autre échelle, et Java est une famille envahissante.

Golang profite d’une bienveillante neutralité, faisant fi des guerres des langages historiques.

Jusqu’à présent, il y avait une séparation claire entre langages système et langage métier. Cette frontière est fortement remise en cause avec Golang, et je suis curieux de voir ce que va pouvoir apporter Rust dans cette zone intermédiaire.

Fighting with EventMachine

2015-06-16T21:41:00+02:00

Here is one of my old post (late 2011) from dev.af83.com about EventMachine, when I worked with ruby. TL;DR without futures/promises or fibers async languages are doomed.

If it’s your first night with EventMachine, you have to fight.

EventMachine in a nutshell

EventMachine is an implementation of the reactor pattern. It’s not Twisted, nor Node, nor Erlang. It follows the Ruby way, hence you have to follow the EventMachine way.

The event-loop pattern is now mainstream

The event-loop pattern is quite simple. The actions are no more systematically sequential. It’s not thread-based: there is only one thread for the event-loop, therefore execution is still sequential. This enforce a unique context, accessing variables is still atomic (no concurrency).

Classical asynchronous actions are waiting actions, such as IOs (network or disk access). This makes long-lived actions (CPU intensive) to jam the flow. Async actions are detached from the flow, and a callback is called when it finished. If you don’t take care, you will have stairs of block (one for each callback) and troubles for handling errors, the now infamous callback spaghetti.

The EventMachine way

EventMachine.run do
  http = EventMachine::HttpRequest.new("http://google.com").get
  http.callback do
    puts "got a response"
    puts http.response
    EventMachine.stop
  end
  puts "too early"
end

The first block handles the reactor, the second one is the callback.

What if I want to fetch more than one url?

EventMachine.run do
  google = EventMachine::HttpRequest.new("http://google.com").get
  google.callback do
    puts google.response
    yahoo  = EventMachine::HttpRequest.new("http://yahoo.com").get
    yahoo.callback do
      puts yahoo.response
      EventMachine.stop
    end
  end
end

As the event-loop pattern forces you to nest callbacks, you’re building an infinite staircase. It also makes actions sequential, but you may don’t want google to answer before yahoo. You also had to add one level of indentation per url.

A workaround is to handle it by hand:

EventMachine.run do
  urls = %w{ google.com yahoo.com}
  finished = urls.length
  responses = urls.map do |url|
    response = EventMachine::HttpRequest.new("http://#{url}").get
    response.callback do
      finished -= 1
      if finished == 0
        puts responses.map{|response| response.response }
        EventMachine.stop
      end
    end
    response
  end
end

Don’t you love flashbacks in movies? This way, url fetches are parallel, and you’ve even get a callback when all actions are finished.

EventMachine provides a helper for such common patterns:

EventMachine.run do
  urls = %w{ google.com yahoo.com}
  EventMachine::Iterator.new(urls, urls.length).map(
    proc do |url, iter|
      http = EventMachine::HttpRequest.new("http://#{url}").get
      http.callback { iter.return http.response }
    end,
    proc do |responses|
      puts responses
      EventMachine.stop
    end
  )
end

It is the official way, but IMO it turned out not as elegant as it could have been. The first Proc handles the iterations and return the response, the second Proc is the finished callback.

Em-http-request provides a specific object for doing batch jobs in a simpler form:

EventMachine.run do
  multi = EventMachine::MultiRequest.new
  multi.add(:google, EventMachine::HttpRequest.new("http://google.com").get)
  multi.add(:yahoo, EventMachine::HttpRequest.new("http://yahoo.com").get)
  multi.callback do
    puts multi.responses[:callback]
    puts multi.responses[:errback]
    EventMachine.stop
  end
end

Short, elegant, and specific, isn’t it? As nobody cares about the specific requests’ callbacks, they are out. The response is deferrable and MultiRequest collects the spreaded responses. You don’t have to handle parallel or sequential multi-actions in your own API. It’s really a job for EventMachine (or Synchrony)!

The mysterious Deferrable behavior

As seen above, an async action returns a deferrable response, which is a mysterious object bound a callback. Why not a classical Proc? Why not a quick and dirty DefaultDeferrable as you may have seen in EM’s doc?

The callback is just a trigger, it is not responsible for giving the answer back: the deferrable object is the answer.

But Deferrable is a complex answer, providing a state, two (actual) triggers, a success callback and a error callback; and an optional timeout.

In this pattern, an async function returns a response immediately (a Deferrable one), but the actual value of the response will be available later. Think of it as a closed box that will open itself, later on.

Using API functions with a block is just a syntactic sugar, but don’t forget to provide both a callback and an errorback, and more importantly, you must return a Deferrable.

Example of an API based on EventMachine

Let’s take a simple example: airports are required to freely give weather information (no authentication layer to handle). So here is the first weather webservice I found in Google. It’s PHP-based on the server side, response serialization is done the oldschool way, but it’s free indeed and it just works.

class Weather
  include EventMachine::Deferrable
  attr_reader :code, :date, :temp, :humidity, :wind_speed

  def _feed(code, raw)
    rough = raw.split('#')
    @code = code
    @date, @temp, @humidity, @wind_speed = rough[0..3]
  end

  def to_s
    "<Weather: code=#{@code} temp=#{@temp} humidity=#{@humidity} wind_speed=#{@wind_speed}>"
  end
end

def meteo(icao, &block)
  response = Weather.new
  response.callback(&block) if block_given?
  http = EventMachine::HttpRequest.new("http://stationmeteo.meteorologic.net/metar/your-metar.php?type=mes&icao=#{icao}").get
  http.errback do |error|
    response.fail :system, error
  end
  http.callback do
    response._feed icao, http.response
    response.succeed response #giving itself as first argument give the choice to how handle answer
  end
  response
end

And now an example with EventMachine’s iterator:

EventMachine.run do
  # Airport of Lyon, Paris and Marseille; US airports don't seems to work.
  EventMachine::Iterator.new(%w{LFRS LFLL LFML}, 3).map(
    proc do |airport, iter|
      meteo airport do |score|
        iter.return score
      end
    end,
    proc do |scores|
      puts scores
      EM.stop
    end
  )
end

Fiber, or the hidden-threaded way

It can be funny to fight with callback in daemon project, at least for some time. But it may come a time when you just yearn for sequential programming. Still you want to use this cool framework wich uses EventMachine to handle lots of parallels connections. How would you do then?

You could strive to parrallelize a few requests, but most of the time, you just want to be able to describe your needs in a sequential fashion, everywhere.

Fiber, shipped with Ruby 1.9, is the answer. A Fiber waits for the response, for you, pausing the execution in the middle of a flat code chunk using #yield and resuming execution at any time with #resume. We are using Synchrony here:

alias :ameteo :meteo

def meteo(icao)
  f = Fiber.current
  conn = ameteo icao
  conn.callback { |resp| f.resume(resp) }
  conn.errback { |*errors| f.resume(*errors) }
  Fiber.yield
end

Usage is straightforward:

EventMachine.synchrony do
  puts meteo "LFRS"
  puts meteo "LFML"
  EventMachine.stop
end

Sequential actions are now, well, sequential. Revolutionary.

In order to transform you previously async methods into a Fiber-aware one, you may prefix the method with a (as in async), then wraps it within a fiber which will be resumed in the callbacks. It can be made systematic, have a look of how Synchrony monkey patches common libraries.

You could also explicitly ask for parallel actions, using an async variant of your code.

EventMachine.synchrony do
  responses = EventMachine::Synchrony::Iterator.new(%w{LFRS LFLL LFML}, 3).map do |airport, iter|
    ameteo airport do |response|
      iter.return response
    end
  end
  puts responses
  EventMachine.stop
end

EventMachine.synchrony do
  multi = EventMachine::Synchrony::Multi.new
  multi.add :satolas, ameteo("LFRS")
  multi.add :paris, ameteo("LFLL")
  responses = multi.perform.responses[:callback].values
  puts responses
  EventMachine.stop
end

Microservices : orchestrer, chorégraphier, visualiser et isoler

2015-05-27T00:15:00+02:00

Microservices

Le principe du microservce est simple : une application est composé de différents petits services, fortement découplés, et orientés métier. Ces services communiquent entre eux pour composer une application. L’application, naturellement distribuée, gagne en souplesse et en robustesse, l’utilisation des ressources est optimisée, les évolutions (changements et croissance) sont simplifiées.

Les microservices sont une nouvelle étape dans les architectures serveurs. Créées en opposition aux applications monolithiques, les microservices utilisent pleinement les possibilités du Cloud computing et des conteneurs. Théorisés et mis en place par de très gros sites (Netflix, Twitter, Google …), les nouvelles abstractions, et les outils adéquats, qu’apportent les microservices sont maintenant utilisables par tout le monde.

Tout cela a bien sûr un coût : l’application est plus complexe, plus dure à tester et la gestion des latences devient une priorité. La robustesse n’existe que si les clients font l’effort d’implémenter une stratégie de tolérance aux pannes (refaire un appel échoué sur un nouveau noeud, gèrer les timeouts…).

Routage

Le point central de ce type d’application reste le routage, comme pour les classiques sites web.

Par contre, cette notion de routage est généralisée. Le traitement peut-être synchrone ou asynchrone, séquentiel ou parallèle, unitaire ou par lot, avec un ou plusieurs essais, ou un mix de tout ça.

Ces différentes approches existent actuellement de manière dispersée, avec le routage des applications webs, les services web, et les workers asynchrones avec ses files d’attente.

Une notion formelle de RPC peut être utilisé (thrift, finagle…) mais une simple sérialisation (JSON, msgpack, protobuff…) avec du classique REST, ou un serveur de message (AMQP, NSQ, Redis…) fonctionne tout aussi bien.

L’abstraction de message, bien connu dans le protocole HTTP, permet d’enrichir, de restreindre, de sécuriser, d’organiser, de compresser, de surveiller les échanges de messages indépendamment de leur contenu et de manière transparente pour l’application. Des outils classiques et éprouvés comme HAproxy ou Nginx ont tout à fait leur place dans le nouveau monde des microservices.

Dynamisme

Le découplage et la communication par message permettent de distribuer simplement les services (en faisant varier le nombre d’instances d’un même service). De manière similaire un service crashé peut être remplacé sans heurt. Les mises à jour peuvent être roulantes, ou même atomiques en refusant les nouvelles requêtes, attendant la fin de requêtes en cours, avant de basculer le routage sur la nouvelle version du service. Des choses plus complexes, comme du A/B testing sont réalisable simplement.

Le routage peut facilement devenir dynamique et même réactif, utilisant le concept de découvertes de service.

Pour garantir un tant soit peu de cohérence, il est possible d’utiliser un coordinateur comme le tant redouté ZooKeeper, ou une de ses alternatives comme Etcd ou Serf.

Des outils de plus haut niveau se basent sur ces outils, comme consul, fleet, vulcan ou Eureka.

Crée à l’origine comme base clef/valeur distribuée pour mettre à disposition une configuration pour un cluster, les produits ont évolué pour proposer du pub/sub (les clients intéressés sont prévenus d’un changement de clef et déclenche une action), puis du DNS (en exposant les valeurs de la base) et même du monitoring (la disparition d’un service devient un évènement, qui sera traité).

Un nouvel antagonisme apparait avec le routage dynamique : le choix entre l’orchestration et la chorégraphie. L’orchestration déclare les différentes routes de manière explicite, la chorégraphie donne des instructions pour ensuite laisser les différents éléments se débrouiller.

Pour valider la résilience de l’approche “chorégraphie”, il existe le mythique Chaos Monkey, que seuls les plus braves osent l’utiliser en production.

Inspecter

Un service peut être composé d’un ou plusieurs services, eux-mêmes composés de services. Le client discutant avec une façade, il ne connait (ni se soucis) de l’implémentation du service. Cette approche aide au découplage des différents services, mais rend plus complexes le débug et l’optimisation des différentes latences.

Comme à chaque fois, la réponse à été donnée par Google il y a quelque temps (en 2010), sous la forme d’un white paper : Dapper. Comme souvent, une implémentation en Java en est faite, par Twitter, cette fois-ci : Zipkin. Zipkin vise gros et il prévoit de travailler avec le reste de l’écosystème Twitter. Il existe heureusement un clone plus léger, Appdash, avec un protocole simple et bien spécifié.

Prévu initialement pour mesurer les latences sans perturber le service (avec de l’échantillonnage léger, 1 sur 1024), ces outils de tracing permettent aussi de voir simplement ce qu’il se passe, de repérer ce qu’il est pertinent de paralléliser, d’aider à optimiser et dimensionner.

Google insiste sur la notion d’ubiquité dans Dapper et instrumente tout son code à partir de quelques bibliothèques clefs (gestion de thread, du réseau…).

Avec du monkeypatch ou des hooks, il n’est pas compliqué d’instrumenter des frameworks RPC comme Nameko : j’avais fait un prototype en monkeypatch, j’ai eu droit à un commentaire proposant une meilleure approche avec un hook élégant.

Il est aussi possible de faire de l’instrumentation en boite noire avec des outils comme Packet beat.

Visualiser

L’ensemble des services forme des réseaux analysables et visualisables par des outils classiques comme Networkx. Ces réseaux peuvent être décrits de manière explicite, par introspection, ou en surveillant (en échantillonant) la communication engendrée par l’application ou des tests.

Plus sportif, il est possible de simuler et de tester le coté dynamique des routes avec Spigo, prometteur, mais pour l’instant très lié à l’écosystème de Netflix.

Isoler

Le découpage permet aussi d’isoler les services, pour simplifier la prise en main par différentes équipes, pour déployer chacun à son rythme.

Mais le découpage permet aussi de compartimenter l’accés aux ressources, pour éviter qu’un incident sur un service entraine l’ensemble et finisse par faire tomber l’application.

Le terme technique est disjoncteur. En cas d’abus, on coupe tout de suite, avant que ça casse tout.

Concrètement, une utilisation fine des timeouts permet d’écourter pas mal de drames. Une allocation fixe des ressources permet de garantir que chaque service n’ira pas perturber son voisin. Les cgroups de Linux ont été conçues pour ça, et sont un des piliers de la conteneurisation. Contraindre les accès aux disques durs et au réseau sera plus un poil plus complexe que le CPU et la RAM. Pour limiter la portée des bêtises (volontaire ou non), apparmor est simple à mettre en place.

Il est possible d’automatiser entièrement la mise à disposition de ressources matérielles avec Mesos, mais le ticket d’entrée est conséquent, Swarm semble plus économe, mais reste encore très jeune.

Les outils de containerisation sont conçus pour restreindre l’utilisation des services, mais aussi pour mesurer leurs usages. Les outils de mesures sont en pleine effervescence, dispersés, mais cAdvisor propose un produit complet, se connectant sur Influxdb ou le très prometteur Prometheus.

La suite

Les microservices sont bien entendu un buzzword de plus, mais ils existent bel et bien. Pour l’instant peu formalisés, les microservices sont un ensemble de principe à suivre, pour généraliser et étendre l’architecture orientée service qui est actuellement la norme. Les ennemis des microservices sont clairement identifiés (le couplage fort, les applications monolithiques, les latences, les problèmes de montée en puissance…), les drames possibles le sont un peu moins.

Toutes innovations amènent avec elles une catastrophe potentielle. Les gens qui ont fabriqué le Titanic ont aussi inventé le naufrage à grande échelle. Il est donc important d’anticiper les drames potentiels pour ne pas se laisser surprendre, et de surveiller les erreurs que font les autres, pour éviter de les reproduire.

Un bac à sable pour Ruby

2015-04-13T20:00:00+02:00

Un bac à sable pour Ruby

Je ne sais plus trop comment cette histoire a commencé. Hum… une discussion engagée par un développeur de codepen.io sur la possibilité d’utiliser des Dockers jetables pour “rendre” des fichiers HAML.

HAML est un format de template pour Ruby très peu verbeux, basé sur l’indentation. Il permet, entre autres, de faire des choses dangereuses, comme insérer du ruby dans le gabarit. Cette option est débrayable, heureusement, mais cet outil n’a jamais été conçu dans une optique de sécurité, mais de rendre le développeur heureux. Comme tous les produits Ruby, en fait.

Proposer de rendre des fichiers HAML comme service web est donc dangereux, il ne doit pas être bien difficile de mettre le bazar en soumettant un HAML mal intentionné.

Dans l’absolu, je ne me sens pas super concerné par HAML, ni par les entrailles de Ruby. Mais le challenge est intéressant : proposer un bac à sable avec les outils modernes servant de base à la conteneurisation.

Depuis l’intérieur de ruby

Ruby est un langage interprété capable d’aller très loin dans les abstractions, les bidouilles et les astuces. Tout est permis, il n’y a aucune limite pour atteindre l’objectif sacré : “à la fin, le code est beau”, le but ultime du développeur Ruby.

Vouloir border l’exécution de code ruby est donc complètement utopiste, voire même insultant.

Il existe des outils liés à la sécurité dans Ruby, comme la variable $SAFE, mais ça semble être peu pratique, et remis en cause dans les prochaines versions de Ruby.

Il existe la gem shikashi qui permet de faire des eval avec des listes blanches, mais pour l’utiliser, il faudrait patcher le code de la gem `haml.

Il y a visiblement des choses à faire dans Ruby même, mais bon, je n’ai pas super envie d’aller farfouiller dans ses entrailles, ni même beaucoup d’espoir de pouvoir y trouver quelque chose de déterministe ou systématique.

Depuis l’extérieur de Ruby

Docker a réussi à démocratiser la conteneurisation sur Linux, et à amener de la visibilité sur le sujet, beaucoup de visibilité.

Seul bémol, les conteneurs de Docker ne sont pas pour l’instant prévus pour isoler du code potentiellement agressif. Une équipe a été montée pour travailler sur ce sujet, et RedHat s’y intéresse aussi.

L’isolation des process est confiée aux namespaces, une innovation apparue dans le kernel 3.8, il y a maintenant 2 ans, mais qui surtout est officiellement troués jusqu’à la version 3.14 du kernel. Pour rappel, Trusty, la version courante d’Ubuntu utilise un kernel 3.13.

Bien conscient du problème, Docker propose d’utiliser l’une des deux implémentations vedettes des LSM : Apparmor ou SELinux. Je n’ai pas eu l’occasion de me documenter sur SELinux, et Apparmor a le bon gout d’être installé par défaut sur Ubuntu depuis des années (et Debian le gère sans soucis). Pour l’instant, la documentation de Docker sur la sécurité est spartiate (les sources de libcontainer sont lisibles), et rien ne semble prévu pour demander à restreindre des accés à l’intérieur même du conteneur.

Github a réalisé un prototype pour emballer du Ruby générique dans un Docker : Hoosegow. Ils donnent tous les liens vers les informations disponibles, mais font le pari de confier la sécurité à Docker.

Découper en tranches

Docker, c’est beaucoup de Kernel, un peu d’API, et pas mal de choix d’organisation (type de réseaux, système de fichiers en oignons, chemin des Cgroups …). Pour la partie isolation/coercition, le rôle est confié aux Namespaces et aux Cgroups, le tout emballé par Apparmor. Les Namespaces sont officiellement troués. Deuxième soucis, Apparmor travaille avec des chemins complets, et Docker utilise un UUID au dernier moment, pour nommer le dossier racine du containers. Il y a donc un souci pour préparer le apparmor avant de pouvoir l’utiliser.

Docker fourni nsinit, un outil en ligne de commande pour coudre à la main des namespaces pour tailler sur mesure son propre conteneur. On ne peut pas tout à fait qualifier cet outil de grand public. Il m’a résisté. Je suis donc parti sur une solution simple, basée sur Apparmor et Cgroup, pour les Namespaces, on verra plus tard.

Isoler un service

La tactique est simple : isoler le code gérant le haml dans un serveur, et le mettre dans une boite qui interdit un maximum d’actions possibles :

La boite est en lecture seule, sans réseau IP, sans capabilites.
Seuls les fichiers nécessaires pour lancer le code ruby sont lisibles.
Le serveur va communiquer via une socket UNIX, seul élément accessible en écriture.
Le protocole n’utilise aucune sérialisation, juste des Pascal strings : une taille sur 4 octets, suivi du message.
Le client gère un timeout pour ne pas attendre un serveur bloqué.
Cgroup permet de limiter la mémoire, et la ration de CPU disponibles.

Bundler

Bundler est utilisé pour installer les bibliothèques nécessaires de manière propre et déterministe. Le serveur sera lancé avec un -I pour ne pas devoir embarquer tout bundler dans Apparmor : pas de bundle exec. L’application a un shebang et un chemin en dur : /opt/box/box pour permettre l’interception par le démon de Apparmor.

Apparmor

La règle Apparmor est créée en ajoutant les fichiers nécessaires un par un, jusqu’à ce que le serveur se lance, puis que le client puisse lui parler. C’est un peu laborieux, mais je suis moyennement convaincu par l’outillage actuel, avec l’activation d’un audit et surveillance automatique des logs. On parle de 50 lignes de serveurs utilisant 1 bibliothèque et de 40 lignes de clients, rien de comparable avec la moindre application Rails.

Eye

L’application bénéficie d’un superviseur, Eye,qui se charge de lancer et relancer le service en cas d’incident. Pour l’instant, seul le service est isolé par Apparmor.

Eye.config do
  logger '/var/log/sandbox/eye.log'
end

Eye.application 'sandbox' do
  working_dir '/var/run/box'
  trigger :flapping, times: 10, within: 1.minute, retry_in: 10.minutes
  stdall 'trash.log' # stdout,err logs for processes by default

  # eye daemonized process
  process :box do
    pid_file 'box.pid' # pid_path will be expanded with the working_dir
    start_command '/usr/bin/ruby -I /opt/box/vendor/bundle/ruby/1.9.1/gems/ /opt/box/box'
    daemonize true
  end
end

Cgroups

Un utilisateur est créé, pour profiter des droits UNIX classiques, et surtout pour pouvoir y accrocher des Cgroups. Il n’est pas nécessaire de dégainer des outils de haut niveau pour ça, Cgroups se configure avec de simples fichiers montés dans un point de montage de type cgroup.

Init.d

Le script init.d est laid comme tous les scripts init.d mais comme il est tombé en marche au bout de 10 minutes alors que la version upstart m’a résisté pendant tout le weekend, je ne critiquerai pas. L’abandon d’Upstart dans la prochaine version LTS d’Ubuntu est par contre une très bonne nouvelle. J’ai rarement vu un produit aussi pénible et incapable de dire où il a mal, puis qui se bloque au bout d’un moment, avec le reboot comme seule issue. La doc est pleine de promesses d’améliorations pour la prochaine release que personne ne verra jamais.

Le superviseur et le service tournent avec un utilisateur non privilégié lancé par un start-stop-daemon, init.d se charge de préparer le terrain puis d’attacher le service dans un cgroup.

do_pre_start()
{
    mkdir -p /run/box
    chown box /run/box

    mkdir -p /var/log/sandbox
    chown box /var/log/sandbox

    cgcreate -a box -t box -g memory,cpu:box
    # 25%
    echo 256 > /sys/fs/cgroup/cpu/box/cpu.shares
    # 32Mo
    echo 32000000 > /sys/fs/cgroup/memory/box/memory.limit_in_bytes

    mkdir -p /opt/box/.eye
    chown box /opt/box/.eye
}

do_post_start()
{
    sleep 3 # Yes, this is ugly, it should be a loop
    cgclassify -g memory,cpu:box `cat /run/box/box.pid`
}

On retrouve la logique de poupées gigognes (les matriochkas), avec une séparation claire des responsabilités. L’init crée le contexte puis lance un superviseur, qui lance un service dans un contexte rigoriste. Ruby n’est jamais lancé avec l’utilisateur root.

Je n’ai aucune idée du niveau de sécurité qu’amène cette suite de bonne pratique, mais on est clairement au-dessus de pas mal de sites web.

Améliorer

Par principe, il faudrait mettre la boite dans une boite de virtualisation, utiliser un kernel patché avec GRSec, ajouté du log (auditd et tcpspy ) vers une machine distante, et attendre un drame pour ensuite corriger.

Le code

Le code est disponible sur github, avec une jolie licence LGPL : Sandbox

L’échec de l’élastique comme un service

2015-04-05T19:35:00+02:00

L’échec de l’élastique comme un service (et son renouveau)

Le Cloud est élastique

Le Cloud n’a qu’une seule fonction intéressante : l’élasticité. Tout le reste n’est que blabla commercial ou confusion sémantique. Attention, je ne suis pas nostalgique du serveur cousu main, à l’ancienne. Les offres d’hébergement sont en constante évolution et mettent à disposition plein de belles choses, mais ce ne sera que rarement du Cloud.

La définition du Cloud est pourtant simple : Mise à disposition DYNAMIQUE de ressources via une API distante. Même Wikipedia le dit, enfin presque. Je peux commander des ressources, et les utiliser dans les minutes qui suivent, en demander plus, puis les diminuer un peu plus tard.

Ces ressources peuvent être matérielles (bien que virtualisées) comme de la puissance de calcul ou du stockage, mais aussi de plus haut niveau, des services.

Le Cloud sait mettre à disposition des ressources de bas niveaux : CPU, RAM, réseau, disque… depuis maintenant presque 10 ans, grâce à la virtualisation.

Mais la virtualisation est beaucoup plus à l’aise pour dimensionner une machine à froid. L’élasticité, ce serait pouvoir redimensionner certaines ressources à chaud, sans redémarrer. Techniquement, des choses sont faisables, mais il est très difficile de mettre à disposition un pool de ressources et de piocher dedans, l’unité de base reste la machine physique.

Il est beaucoup plus simple de travailler avec plusieurs machines (réelles ou non), et d’en ajouter ou d’en enlever, puis de demander à la partie applicative de gérer cette fluctuation en débranchant et rebranchant les différents éléments.

Le web est élastique

Le web se prête bien aux architectures distribuées dynamiques, avec son protocole sans état (en théorie).

La méthode immuable pour traiter les requêtes web est celle de l’aiguillage qui va demander le traitement de la demande a des workers. Les workers peuvent être des process ou des threads sur une même machine, eux-mêmes répartis sur plusieurs serveurs. HAproxy ou Nginx (plus faiblard), sont capable de répartir la charge entre plusieurs machines.

Le load-balancer devient une pièce maitresse des applications distribuées. Nginx évolue rapidement (principalement sur sa branche privatrice) pour reprendre sa place de proxy universelle, HAproxy va intégrer Lua, et des proxy applicatifs apparaissent, comme le maintenant historique Hipache ou le prometteur Vulcan.

Dire que le protocole HTTP est sans état est un mensonge, enfin, un raccourci. La notion de cookie puis celle de session sont apparues très vite, pour conserver l’état d’un client sur une période plus ou moins longue. Dans un environnement distribué, il faut pouvoir partager un état entre les workers, rôle traditionnel de Memcache, challengé par Redis.

De la même manière, il faut pouvoir gérer les uploads de fichiers de manière centralisée avec S3 et ses clones, ou le classique NFS.

Pour la persistance, les inébranlables bases de données relationnelles ont encore largement leur place, challengée par la vague du NoSQL, plus ou moins fiable, mais tellement plus adapté au redimensionnement.

Pour ceux qui ont encore faim, il est possible de gérer tout ça de manière dynamique.

Tout ça pour atteindre le Graal de l’élasticité.

Élastique comme un service

La complexité est quand même impressionnante pour un besoin que beaucoup de gens n’auront jamais.

Il y a eu une première vague de réponses pour simplifier l’accès à l’élastique : Google App Engine, puis Elastic Beanstalk.

Deux produits contraignants, qui, bien qu’utilisant des langages libres, enferment l’utilisateur dans une solution propriétaire.

Ces deux produits ont causé beaucoup de drames : des langages arbitrairement périmés, un environnement de dev ne ressemblant que très peu à la prod, des performances aléatoires, et surtout l’impossibilité d’utiliser des frameworks et des applications largement utilisées dans des environnements classiques. Une vraie catastrophe.

Et tout ça pour se faire siphonner sa carte bleue, si le site a la mauvaise idée de faire une belle audience. Le plafond de cout étant apparu sur le tard : “Attention, nous, on scale, mais pas ta carte bleue”.

Le conteneur est élastique

Donc l’approche bas-niveau ne suffit pas, et les approches de trop haut niveau sont encore pires. Il faut donc voir ce qui est faisable avec une approche plus modérée.

Les conteneurs, qui ne sont ni de la virtualisation, ni de l’applicatif, permettent d’embarquer une application avec tout ce dont elle a besoin, et de la lancer avec quelques paramètres dans un environnement maitrisé (accès aux ressources physiques, isolation). Le Cloud devient un simple pool de ressources dans lequel on va piocher en déployant ou déplaçant un conteneur là où il y a de la place.

Le conteneur peut être considéré comme immutable (en lecture seule), et il confiera ses besoins d’IO à des services réseau, ou à un point de montage avec un système de fichier. Le réseau est clairement plus souple, mais des systèmes de fichiers modernes permettent de faire de belles choses (comme ZFS avec le double push de Flocker).

On a donc une application tout ce qu’il y a de plus classique, en PHP, Python ou je ne sais quoi, qui va se retrouver sur un Linux en lecture seul (ou presque), et dont on va pouvoir multiplier les instances. Se passer du stockage local est intégré dans beaucoup de framework maintenant :

Pour le reste, il suffit de brancher une poignée de services (session, caches, base de données…) et avoir une première étape de scaling sans douleur.

La seconde étape arrive quand la base de données commence à crier, et il va falloir négocier pour aller au-delà du combo index/cache/tuning pour avancer. Mais bon, cette étape arrive lorsque l’on a un joli trafic, et il est toujours possible de négocier en force en ajoutant un esclave plus gros (plus de coeurs, plus de RAM, plus de SSD…), et de le promouvoir, pour faire du scaling vertical.

Scaler la couche applicative en utilisant des conteneurs est la voie dans laquelle s’engagent (à fond) les gros du Cloud, avec des solutions ouvertes ou non :

Kubernetes (Google)
ECS (Amazon)
Triton (Joyent)
Mesos (UC Berkeley et Twitter)
…

Kubernetes, qui a le bon gout d’être libre, déchaine l’enthousiasme. Red Hat se raccroche aux branches et profites de Kubernetes pour faire basculer vers les conteneurs son Open Shift pour la version3 en préparation.

Les conteneurs posent encore beaucoup de questions, et des startups proposent des réponses, comme Flocker de ClusterHQ pour avoir de la persistance qui peut migrer. CoreOS continue de taper tous azimuts. HashiCorp se contentait d’une gestion opportuniste des conteneurs, mais c’est en train de bouger. Terraform dans sa version 0.4 gère Docker, et j’ai hâte de voir comment Consul et les autres outils vont s’adapter.

La fusion du Cloud et des conteneurs est en train de se faire, là, maintenant. Il y aura des nouveautés, et des morts. Cette fusion amène de nouvelles réponses, et tout autant de questions. Rendre possible l’élasticité de la partie applicative fait partie des réponses apportées par la combinaison du Cloud et des conteneurs.

La cuisson avec Docker

2015-03-19T22:40:00+01:00

Préparer une application

Même si l’on code massivement avec des langages de script pour ne pas passer par la case compilation, il y a forcément une étape de préparation avant de pouvoir livrer une application à partir de ses sources : télécharger les modules et compiler les potentiels binding en C, mais surtout gérer tout le bazar lié aux assets : JavaScript et CSS.

Cette étape de préparation avant déploiement porte en anglais le nom poétique de baking : on cuit le pain avant de le livrer.

Il n’y a aucun intérêt à réaliser cette étape sur le serveur de production qui a surement mieux à faire : c’est long, ça requière des outils plus ou moins louches, et si l’application est distribuée, il faut recommencer sur chaque instance.

Préparer Isso

Voici un exemple commenté de préparation et déploiement de Isso, un clone libre et local de Disqus, qui permet d’embarquer des commentaires depuis du JavaScript, sur un site qui peut même être statique. Le serveur est en Python, et il fournit du JavaScript à embarquer dans ses pages HTML.

Pour ne pas pourrir ma machine en installant des outils bizarres, j’utilise des containers Docker à usage unique. Pour avoir un build sans trop de répétitions, j’utilise un simple Makefile. Oui, Makefile est vieux et moche, mais pas plus que bash, et il est un standard de fait. Pour des taches de tailles raisonnables, il reste tout à fait pertinent.

En montant un dossier local dans le container, le résultat du traitement se retrouvera dans ce dossier. La source et le résultat sont locaux, le traitement distant.

Cerise sur le gâteau, grâce à boot2docker,l’action lancée depuis un Mac, va faire travailler un Linux, et surtout, produire du contenu pour Linux.

Pour éviter toutes surprises, je n’utilise que des images officielles de Docker, forcément basé sur Debian (et Wheezy, si possible).

Cuire le Python

Isso est packagé sur Pypi : il s’installe simplement avec pip. Je sais installer python, mais comme la vie est courte, autant utiliser python:2-wheezy.

Makefile pense à l’envers, en pensant prérequis et dépendances. Pour avoir l’application Isso, j’ai besoin d’un python dans un virtualenv, qui a besoin d’un dossier app. Ce qui donne :

app/bin/isso: app/bin/python
    docker run --volume=`pwd`/app:/app --rm --workdir=/app python:2-wheezy /app/bin/pip install isso

app/bin/python: app
    docker run --volume=`pwd`/app:/app --rm --workdir=/app python:2-wheezy virtualenv .

app:
    mkdir app

Comme je suis radin, j’efface (—rm) le container dès qu’il a exécuté son action.

Cuire le JavaScript

Le JavaScript, de nos jours, utilise plus de bazars que du C++ pour être utilisable. Isso est sobre, il se contente de Bower pour aller chercher les bibliothèques et leurs dépendances, Uglify pour compacter, et on échappe à Grunt, un Makefile est utilisé à la place.

js: src/isso/js/embed.js
    docker run --volume=`pwd`/src:/src --rm --workdir=/src node:wheezy sh -c 'npm install -g bower requirejs jade && make init && make js'
    echo "Your minified javascript files are here:"
    find src/isso/js -name *.min.js

src/isso/js/embed.js: src
    git clone https://github.com/posativ/isso.git src/

src:
    mkdir src

Même tactique, une image jetable avec nodejs : node:wheezy est utilisée. Petite astuce, “docker run” n’accepte qu’une seule commande en argument, du coup, il faut passer par un sh -c 'pim && pam && poum'

Livrer le gâteau

La cuisson s’est faite dans des containers, mais le résultat est à chaque fois un simple dossier, tout ce qu’il y a de plus traditionnel.

Il est possible de déployer l’application ainsi, avec un rsync et un supervisor.

J’ai fait le choix de la déployer avec Docker. Le Dockerfile utilisé est minimaliste.

FROM python:2-wheezy

COPY app /app

VOLUME /conf
WORKDIR /app
EXPOSE 1234
CMD ["/app/bin/isso", "-c", "/conf/isso.conf", "run"]

Le dossier contenant le fichier de configuration est réclamé, par contre, l’application est embarquée.

Pour configurer tout ça, un docker-compose.yml qui va utiliser le Dockerfile.

---
isso:
    build: . # Dans le même dossier
    # Aucun privilège
    cap_drop:
        - ALL
    ports:
        - "1234:1234"
    volumes:
        - "conf:/conf" # Pour la configuration
        - "data:/data" # Pour la base de données

La configuration isso est tout aussi simple

[general]
dbpath = /data/comments.db
host = https://example.tld/
[server]
listen = http://0.0.0.0:1234/

Le dossier data monté dans compose est utilisé pour accueillir la base sqlite, et le serveur écoute bien le port 1234.

Il faut ensuite tricoter les urls pour avoir le site web et Isso.

Le site en production n’aura aucune séquelle de son installation, pas de nodejs, pas de choses qui trainent, juste une Wheezy spartiate et une application.

Tout le code est disponible sur github, sous Licence BSD.

Plus de machines, des services

2015-03-19T22:40:00+01:00

La virtualisation n’était qu’une étape.

Le besoin de virtualisation

La virtualisation est apparue pour en finir avec l’ajout sans cesse de machines dans les salles serveur. Pour pouvoir garantir de la qualité, limiter la portée des incidents, permettre des cycles de vies différents, il est important de pouvoir isoler les services. La virtualisation permet de découper des serveurs physiques. En regroupant des services sur un serveur plus gros, on gagne en efficacité, en consommation d’énergie, et en souplesse pour réorganiser l’ensemble (il est possible de migrer une machine virtuelle sur une autre machine physique).

Abstraction matérielle

Cette nouvelle couche d’abstraction n’a pas été indolore, mais des optimisations sont arrivées rapidement. Les processeurs se sont adaptés en rajoutant des jeux d’instructions spécifiques (Intel VT et AMD-V). L’augmentation du nombre de coeurs au sein d’une même puce, et l’augmentation constante de la quantité de RAM disponible permet de passer en force. La virtualisation pure et dure est rapidement passée à la paravitualisation, l’OS invité devant faire quelques efforts d’adaptation en échange d’un gain en performance important.

Techniquement, il est possible de mélanger les OS (Linux, Windows, FreeBSD…), mais rester sur du tout Linux, en se contentant de mélanger les versions ou les distributions, simplifie beaucoup de choses.

Il est possible de redimensionner ou de déplacer une VM, mais concrètement peu d’hébergeurs le proposent, à part Gandi Cloud, peut-être. Le redimensionnement à froid est plus simple, et souvent, la migration vers une VM plus grosse est préconisée.

Augmenter la densité

Un serveur physique met à disposition un certain nombre de ressources (Processeur, RAM, réseau, stockage…). La virtualisation permet d’en mutualiser certaines (Openstack parle d’un ratio, pour la RAM, on peut monter péniblement à 1.5:1, en mettant en commun des plages de mémoire. Dans les cas les plus courant, la mémoire est partagée à 1:1, et ce sont les accès disques qui sont bloquants. Un ordonnanceur essaye de répartir équitablement les ressources, mais le phénomène du voisin bruyant est bien connu des utilisateurs d’AWS.

La plus petite tranche possible

Pour pouvoir profiter d’un minimum de parallélisme, il faut au moins avoir 2 CPUs dans une VM. Le ratio RAM/CPU et de 1:1 pour les offres basses (VPS OVH, Digital Ocean par exemple) pour monter à 3.75:1 pour de l’Amazon Web Service et Google Cloud, et grimper autour de 7:1 pour des VMs spécialisées. Ce qui fait quand même presque 8Go de RAM comme unité de base. Quand on est plus petit que Netflix ou Twitter, ça fait quand même une grosse tranche, surtout si l’on veut doubler le nombre de machine pour avoir de la redondance.

Découper différemment

Les machines virtuelles sont une bonne réponse, mais quelle est la question, déjà?

Pouvoir isoler des services.

Les besoins d’isolations sont finalement divers et négociables :

Répartir au plus juste la consommation des ressources (CPU, RAM, stockage, réseau).
Isoler les différents utilisateurs qui vont utiliser des ressources physiques communes (CPU, RAM, stockage, réseau)
Réstreindre les capacités des utilisateurs, pour limiter les possibilités de faire des bêtises, et donc les surfaces d’attaques.

Ces différentes possibilités ont été explorées, en patchant directement le noyau Linux. Vserver et OpenVZ pour le confinement, GRSec pour la sécurité.

Ces pistes, prometteuses, mais intrusives, ont permis la création de nouveaux modules dans le noyau Linux, permettant ensuite la création de produits, sans avoir besoin d’un noyau patché.

Les capabilities définissent les actions privilégiées que peut faire un process. Pour isoler des processus, il y a maintenant les namespaces, pour répartir les ressources, Google à offert les CGroups, pour la sécurité, les Linux Security Modules permettent avec quelques polémiques de brancher Apparmor, SELinux (cadeau de la NSA) ou des choses plus exotiques comme Tomyo ou Smack. Seccomp (issu de Google Chrome) permet de créer des règles de sandboxing (par thread) en BPF. BPF est la toute nouvelle machine virtuelle universelle pour Linux qui permet de définir des règles en user space, qui seront utilisées en kernel space, sans avoir à faire d’aller-retour. Libseccomp propose une interface de plus haut niveau pour définir ces règles de sécurité.

Les solutions de conteneurs officiels sont des assemblages de ces différents outils :

Les conteneurs sont une approche grandboutiennes, il est toujours possible d’avoir une approche petiboutiste, plus spécifique et du coup plus adapté, comme le propose uwsgi, un serveur d’application.

De toute façon ces outils se démocratisent rapidement, l’invasion Systemd amène avec lui les Cgroups (et donc les namespaces), et Apparmor est installé par défaut sur Ubuntu depuis la 7.10.

Découper le découpage

Il est possible de découper à grandes tranches avec de la paravirtualisation, qui pour l’instant est la seule à garantir une isolation forte, puis de confier ensuite la finition à un kernel Linux récent.

Simplifier le découpage

Une fois la démarche de conteneurisastion amorcée, il est tentant d’optimiser la pile en enlevant la couche de paravirtualisation. C’est la démarche qu’à fait Google, ils ont basculé vers le tout container. Google ne fait pas tourner de code dont ils n’ont pas confiance, ce qui facilite largement le passage au tout container. Au pire, ils peuvent avoir du code bête, mais pas du code méchant. LMCTFY, leur solution maison, utilise quand même Apparmor. Par contre, pour leur offre d’hébergement, Google Cloud, utilise toujours KVM.

Découper quoi?

Une machine virtuelle a une taille minimale plutôt conséquente. Il n’est pas possible d’empiler trop de machines virtuelles sur une machine physique. Tout pousse à utiliser les machines virtuelles comme des machines physiques, en y faisant cohabiter différents services. Certains services étant des prérequis (syslog, ntpd, dnsd, cron, atd…) d’autres étant un regroupement de services pour ne pas gâcher la place.

Découper des services

Un service peut être rendu par une ou plusieurs machines. Les services distribués peuvent utiliser le classique pattern master/slave ou des choses plus égalitaires, à base de Paxos ou de Raft.

Il est possible de redimensionner (confier plus ou moins de ressource) un service, ou d’en ajouter des instances, s’il supporte la distribution.

Utiliser des services

Un service est ce que va utiliser un développeur, il se fiche un peu des détails d’implémentation ou de paramétrages. Son application, qui n’est finalement qu’un service, va utiliser d’autres services pour fonctionner, et en bout de chaine, consommer des ressources.

Un développeur va utiliser des services, qui seront dimensionnés en fonction de la demande et du budget disponible.

Ces services pourront être classique, comme du stockage, du backup, une base de données relationnelle, mais aussi plus abstrait comme de l’antispam (Akismet…), le stockage distribué de S3, la proximité d’un CDN, la surveillance d’un pingdom, la consolidation des erreurs d’un Sentry (un projet libre), l’analyse de performance d’un Newrelic… la liste évolue de jour en jour.

L’informatique est maintenant de plain-pied dans l’ère des services.