Journaux liées à cette note :

Journal du dimanche 09 mars 2025 à 10:37 #desktop, #asCode, #linux-desktop

Je viens de publier le playground suivant : qemu-fedora-workstation-playground.

Je suis particulièrement satisfait d'avoir mis en place ce playground, car il concrétise plusieurs objectifs que je m'étais fixés depuis longtemps :

Finalement, la solution était assez simple à mettre en place et elle est très performante.

Ma VM Fedora Workstation affiche l'écran d'ouverture de session GNOME Display Manager en moins de 19s.

Voici une traduction en français de qemu-fedora-workstation-playground.

Voici les dépendances à installer :

$ sudo dnf install -y \
    qemu-system-x86 \
    qemu-system-common \
    qemu-img \
    qemu-img-extras \
    cloud-utils \
    mesa-dri-drivers \
    libguestfs-tools

Pour simplifier, la méthode que je présente est basée uniquement sur qemu.

Je télécharge la version 41 de Fedora dans sa version "cloud" :

$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-41-1.4.x86_64.qcow2 -O fedora-41-base.qcow2

À partir de cette image de base, je crée une image de type couche (layer) que j'utilise pour effectuer mes opérations sur la machine virtuelle. Cette approche me permet de revenir facilement en arrière (rollback) en cas de problème, annulant ainsi les modifications apportées à la VM.

$ qemu-img create -f qcow2 -b fedora-41-base.qcow2 -F qcow2 fedora-working-layer.qcow2
$ ls -s1h *.qcow2
469M fedora-41-base.qcow2
196K fedora-working-layer.qcow2

Je prépare un fichier cloud-init qui permet de configurer le mot de passe et ma clé SSH :

$ cat <<'EOF' > cloud-init.yaml
#cloud-config
users:
  - name: fedora
    plain_text_passwd: password
    lock_passwd: false
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEzyNFlEuHIlewK0B8B0uAc9Q3JKjzi7myUMhvtB3JmA2BqHfVHyGimuAajSkaemjvIlWZ3IFddf0UibjOfmQH57/faxcNEino+6uPRjs0pFH8sNKWAaPX1qYqOFhB3m+om0hZDeQCyZ1x1R6m+B0VJHWQ3pxFaxQvL/K+454AmIWB0b87MMHHX0UzUja5D6sHYscHo57rzJI1fc66+AFz4fcRd/z+sUsDlLSIOWfVNuzXuGpKYuG+VW9moiMTUo8gTE9Nam6V2uFwv2w3NaOs/2KL+PpbY662v+iIB2Yyl4EP1JgczShOoZkLatnw823nD1muC8tYODxVq7Xf7pM/NSCf3GPCXtxoOEqxprLapIet0uBSB4oNZhC9h7K/1MEaBGbU+E2J5/5hURYDmYXy6KZWqrK/OEf4raGqx1bsaWcONOfIVXbj3zXTUobsqSkyCkkR3hJbf39JZ8/6ONAJS/3O+wFZknFJYmaRPuaWiLZxRj5/gw01vkNVMrogOIkQtzNDB6fh2q27ghSRkAkM8EVqkW21WkpB7y16Vzva4KSZgQcFcyxUTqG414fP+/V38aCopGpqB6XjnvyRorPHXjm2ViVWbjxmBSQ9aK0+2MeKA9WmHN0QoBMVRPrN6NBa3z20z1kMQ/qlRXiDFOEkuW4C1n2KTVNd6IOGE8AufQ== contact@stephane-klein.info
ssh_pwauth: true
EOF
$ cloud-localds cloud-init.img cloud-init.yaml

Lancement de la VM avec :

  • accélération graphique
  • configuration d'une interface réseau virtuelle avec la redirection d'un port ssh
  • partage d'un dossier entre l'hôte et la VM
$ qemu-system-x86_64 \
    -m 8G \
    -smp 4 \
    -enable-kvm \
    -drive file=fedora-working-layer.qcow2,format=qcow2 \
    -device virtio-vga-gl \
    -display gtk,gl=on \
    -nic user,hostfwd=tcp::2222-:22 \
    -drive file=cloud-init.img,format=raw \
    -fsdev local,id=fsdev0,path=$(pwd)/shared/,security_model=mapped-file \
    -device virtio-9p-pci,fsdev=fsdev0,mount_tag=host_share

Cette VM est accessible via ssh, comme avec Vagrant :

$ ssh-keygen -R "[localhost]:2222"
$ ssh -o StrictHostKeyChecking=no -p 2222 fedora@localhost
Warning: Permanently added '[localhost]:2222' (ED25519) to the list of known hosts.
[fedora@localhost ~]$

Et voici comment à partir de la VM je peux monter le dossier partagé :

[fedora@localhost ~]$ sudo mkdir -p /mnt/host_share
[fedora@localhost ~]$ sudo mount -t 9p -o trans=virtio,version=9p2000.L host_share /mnt/host_share
[fedora@localhost ~]$ ls /mnt/host_share/ -lha
total 0
drwxr-xr-x. 1 fedora fedora 16 Mar  9 11:44 .
drwxr-xr-x. 1 root   root   20 Mar  9 11:45 ..
-rw-r--r--. 1 fedora fedora  0 Mar  9 11:44 .gitkeep

J'ai ensuite lancé les commandes suivantes pour installer les packages pour avoir une Fedora Workstation :

$ sudo localectl set-keymap fr-bepo # J'utilise un clavier Bépo
$ sudo dnf update -y
$ sudo dnf install -y @gnome-desktop @workstation-product gnome-session-wayland-session
$ sudo systemctl set-default graphical.target
$ sudo reboot

Et voici le résultat :

Je vais pouvoir intégrer cette méthode à https://github.com/stephane-klein/dotfiles afin de développer et tester mes scripts d'installation chezmoi dans un environnement contrôlé et reproductible, garantissant un comportement déterministe. Desktop configuration as code 🙂.

Le qemu-fedora-workstation-playground contient des scripts pour automatiser les opérations présentées :

Je pense que cette méthode pourra remplacer Vagrant dans plusieurs de mes projets.

Journal du samedi 01 mars 2025 à 18:43 #firefox, #browser, #JaiDécidé, #desktop, #JaiDécouvert

Suite aux mises à jour des conditions d'utilisation et de la politique de confidentialité de Firefox j'ai décidé :

Quelques liens à ce sujet :

Voici quelques informations au sujet des forks de Firefox.

Le projet Waterfox a débuté en 2011.
Waterfox supporte les extensions Firefox 🙂.
Pocket est désactivé par défaut 🙂.

J'ai lu l'article de Waterfox : « A Comment on Mozilla's Policy Changes ».

Waterfox est disponible sur Flathub : https://github.com/flathub/net.waterfox.waterfox.

Je découvre qu'une version Android de Waterfox est disponible : https://github.com/BrowserWorks/Waterfox-Android.

J'ai lu l'article Wikipedia de LibreWolf et les pages "Features" et "FAQ".

Le projet LibreWolf a commencé en 2020, il est bien plus jeune que Waterfox.

#JaiDécouvert IronFox (https://gitlab.com/ironfox-oss/IronFox/)

J'ai installé LibreWolf sous Fedora :

$ curl -fsSL https://repo.librewolf.net/librewolf.repo | pkexec tee /etc/yum.repos.d/librewolf.repo
$ sudo dnf install librewolf

Le site web du projet LibreWolf m'a inspiré davantage confiance que Waterfox.

Suite à cela, j'ai décidé de migrer vers LibreWolf.

Commande pour définir LibreWolf comme navigateur par défaut sous Fedora :

$ xdg-settings set default-web-browser librewolf.desktop

Je découvre Fastlane #JaiDécouvert, #iOS, #Android, #MobileDev, #InfrastructureAsCode

Je viens de découvrir le projet Fastlane (https://fastlane.tools/).

fastlane is the easiest way to automate beta deployments and releases for your iOS and Android apps. 🚀 It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.

source

Je pense que c'est l'outil qui me manquait pour suivre le paradigme configuration as code dans mon "Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor".

Il supporte Android et iOS.

Ce projet a commencé en 2014 par Felix Krause et repris par Google en 2017 : « fastlane is joining Google - Felix Krause ».

Mais, je découvre que Google semble avoir arrêter de financer le développement du projet en 2023 : Google is no longer sponsoring Fastlane | Hacker News.

Depuis, le projet semble être toujours actif avec de nombreuses release : https://github.com/fastlane/fastlane/releases.

Fonctionnalités de Fastlane qui m'intéressent tout particulièrement :

Fastlane permet aussi d'automatiser de nombreuses autres tâches que je n'ai pas encore pris le temps d'explorer : https://docs.fastlane.tools/actions/.


Installation de Fastlane avec Mise que j'ai testée sous Fedora et MacOS :

[tools]
ruby = '3.1.6' # for fastlane
fastlane = "2.226.0"

[alias]
fastlane = "https://github.com/mollyIV/asdf-fastlane.git"

(Toujours aussi pénibles ces outils développés en Ruby 😔)

À noter que sous MacOS j'ai dû lancer :

$ mise install -f fastlane

Parce que lors du premier lancement de mise install, j'ai l'impression qu'il a essayé d'installer fastlane avec l'instance ruby native de l'OS.

J'ai cherché s'il existe une option pour préciser que fastlane doit utiliser ruby installé par Mise, mais je n'ai pas trouvé.


17:05 - Solution pour contourner le problème mentionné ci-dessus :

$ mise install ruby
$ mise install

Je n'ai pas réussi à installer WSL2 sous Windows dans un Virtualbox lancé sous Fedora #WSL, #windows, #VirtualBox

Après avoir réussi à lancer Windows 11 sous ma Fedora dans VirtualBox (voir 2025-02-04_1646), j'ai essayé d'installer et de lancer WSL2, mais je n'ai pas réussi 🙁.

Je suis resté bloqué à cette étape :

vagrant@WIN11 C:\Users\vagrant>wsl --install
Ubuntu est déjà installé.
Lancement de Ubuntu...
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80370102
Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/enablevirtualization
Press any key to continue...
L’opération a réussi.

Même avec ces options :

    win11.vm.provider "virtualbox" do |vb|
      vb.customize ["modifyvm", :id, "--nested-hw-virt", "on"]
      vb.customize ["modifyvm", :id, "--paravirtprovider", "kvm"]
      vb.customize ["modifyvm", :id, "--cpu-profile", "host"]
      vb.cpus = 4
      vb.memory = 16000
    end
  end

Windows ne semble pas vouloir lancer Hyper-v dans un VirtualBox.

J'ai essayé différents paramètres pour --paravirtprovider, sans succès.

Si quelqu'un a la solution, je suis preneur ! (contact@stephane-klein.info).

Playground qui présente comment je setup un projet Python Flask en 2025 #dev-kit, #python, #mise, #docker, #WSL, #playground, #software-engineering

Je pense que cela doit faire depuis 2015 que je n'ai pas développé une application en Python Flask !

Entre 2008 et 2015, j'ai beaucoup itéré dans mes méthodes d'installation et de setup de mes environnements de développement Python.

D'après mes souvenirs, si je devais dresser la liste des différentes étapes, ça donnerai ceci :

  • 2006 : aucune méthode, j'installe Python 🙂
  • 2007 : je me bats avec setuptools et distutils (mais ça va, c'était plus mature que ce que je pouvais trouver dans le monde PHP qui n'avait pas encore imaginé composer)
  • 2008 : je trouve la paie avec virtualenv
  • 2010 : j'ai peur d'écrire des scripts en Bash alors à la place, j'écris un script bootstrap.py dans lequel j'essaie d'automatiser au maximum l'installation du projet
  • 2012 : je me bats avec buildout pour essayer d'automatiser des éléments d'installation. Avec le recul, je réalise que je n'ai jamais rien compris à buildout
  • 2012 : j'utilise Vagrant pour fixer les éléments d'installation, je suis plutôt satisfait
  • 2015 : je suis radicale, j'enferme tout l'environnement de dev Python dans un container de développement, je monte un path volume pour exposer le code source du projet dans le container. Je bricole en entrypoint avec la commande "sleep".

Des choses ont changé depuis 2015.

Mais, une chose que je n'ai pas changée, c'est que je continue à suivre le modèle The Twelve-Factors App et je continue à déployer tous mes projets packagé dans des images Docker. Généralement avec un simple docker-compose.yml sur le serveur, ou alors Kubernetes pour des projets de plus grande envergure… mais cela ne m'arrive jamais en pratique, je travaille toujours sur des petits projets.

Choses qui ont changé : depuis fin 2018, j'ai décidé de ne plus utiliser Docker dans mes environnements de développement pour les projets codés en NodeJS, Golang, Python

Au départ, cela a commencé par uniquement les projets en NodeJS pour des raisons de performance.

J'ai ensuite découvert Asdf et plus récemment Mise. À partir de cela, tout est devenu plus facilement pour moi.
Avec Asdf, je n'ai plus besoin "d'enfermer" mes projets dans des containers Docker pour fixer l'environnement de développement, les versions…

Cette introduction est un peu longue, je n'ai pas abordé le sujet principal de cette note 🙂.

Je viens de publier un playground d'un exemple de projet minimaliste Python Flask suivant mes pratiques de 2025.

Voici son repository : mise-python-flask-playground

Ce playground est "propulsé" par Docker et Mise.

J'ai documenté la méthode d'installation pour :

Je précise que je n'ai pas eu l'occasion de tester l'installation sous Windows, hier j'ai essayé, mais je n'ai pas réussi à installer WSL2 sous Windows dans un Virtualbox lancé sous Fedora. Je suis à la recherche d'une personne pour tester si mes instructions d'installation sont valides ou non.

Briques technologiques présentes dans le playground :

Voici quelques petites subtilités.

Dans le fichier alembic.ini j'ai modifié le paramètre file_template parce que j'aime que les fichiers de migration soient classés par ordre chronologique :

[alembic]
# template used to generate migration files
file_template = %%(year)d%%(month).2d%%(day).2d_%%(hour).2d%%(minute).2d%%(second).2d_%%(slug)s

Ce qui donne par exemple :

20250205_124639_users.py
20250205_125437_add_user_lastname.py

Ici le port de PostgreSQL est généré dynamiquement par docker compose :

  postgres:
    image: postgres:17
	...
	ports:
      - 5432 # <= ici

Avec cela, fini les conflits de port quand je lance plusieurs projets en même temps sur ma workstation.

L'URL vers le serveur PostgreSQL est générée dynamiquement par le script get_postgres_url.sh qui est appelé par le fichier .envrc. Tout cela se passe de manière transparente.

J'initialise ici les extensions PostgreSQL :

def init_db():
    db.drop_all()
    db.session.execute(db.text('CREATE EXTENSION IF NOT EXISTS "uuid-ossp"'))
    db.session.execute(db.text('CREATE EXTENSION IF NOT EXISTS "unaccent"'))
    db.session.commit()
    db.create_all()

et ici dans la première migration :

def upgrade():
    op.execute('CREATE EXTENSION IF NOT EXISTS "uuid-ossp";')
    op.execute('CREATE EXTENSION IF NOT EXISTS "unaccent";')
    op.create_table('users',
        sa.Column('id', sa.Integer(), autoincrement=True, nullable=False),
        sa.Column('firstname', sa.String(), nullable=False),
        sa.PrimaryKeyConstraint('id')
    )

Journal du samedi 11 janvier 2025 à 21:28 #keyboard, #panne, #thinkpad, #linux

Suite à mon problème de clavier son mon Thinkpad T14s : "Suddenly, the “v” key on my Thinkpad T14s Gen 3 returns keycode 47 instead of 55, hardware failure?", je teste l'outil keyd, qui permet de reconfigurer des touches de clavier.

Je souhaite utiliser la touche <Caps-Lock> pour afficher . et <Shift>+<Caps-Lock> par :.

Je commence par installer le package keyd pour Fedora (comme documenté ici) :

$ sudo dnf copr enable alternateved/keyd
$ sudo dnf install keyd

Je défini le fichier de configuration pour mapper <Caps-Lock> vers la touche <v> :

$ sudo tee /etc/keyd/default.conf > /dev/null <<EOF
[ids]
*

[main]
capslock = v
EOF

Je lance le service keyd :

$ sudo systemctl enable --now keyd

Et voila, ça fonctionne, il faut juste que je prenne l'habitude à taper la touche <Caps-Lock> à la place de <.>. Je me demande combien de temps cela va me prendre !

Panne clavier : soudainement, la touche "v" de mon Thinkpad affiche "m" #hardware, #bug, #laptop, #thinkpad, #keyboard

Depuis ce matin, la touche <v> du clavier de mon Thinkpad T14s ne fonctionne plus normalement. Maintenant, la touche <v> affiche <m> et la touche <m> affiche toujours <m> 🤔 (en Azerty ISO Layout).

Au départ, j'ai pensé que j'avais un problème au niveau de mon OS (Fedora), que la configuration du clavier qui avait changé par erreur…
J'ai branché mon clavier externe et je constate qu'il n'a pas de problème, la touche <v> affiche <v>.

Pourtant, tout fonctionnait bien quelques minutes avant. J'ai fait des mises à jour d'OS et de firmware il y a plus d'une semaine.

J'ai shutdown totalement le laptop, j'ai relancé et le problème était toujours présent 🤔.

J'ai ensuite redémarré et je suis entré dans l'outil de diagnostic Lenovo (touche <F10> au démarrage) et là, horreur, le problème est aussi présent dans le BIOS 😯😭.

Voici une vidéo : https://youtu.be/88335YSr6AQ

J'ai démonté la touche <v> pour la nettoyer sans grand espoir, étant donné qu'elle fonctionnait mécaniquement très bien. J'ai eu ensuite d'énormes difficultés à la remonter… et maintenant elle a un petit défaut 😭.

Désespéré, j'ai posté deux messages :

Mon thread Fediverse : https://social.coop/@stephane_klein/113811173930863045

Je croise les doigts ! 🤞

Je découvre la compression Zstandard #OnMaPartagé, #JaiDécouvert, #WebDev, #DevOps, #compression, #brotli, #zstandard, #JeMeDemande, #JaimeraisUnJour

Un ami m'a partagé Zstandard (zstd), un algorithme de compression.

Il y a 2 ans, j'ai étudié et activé Brotli dans mes containers nginx, voir la note : Mise en œuvre du module Nginx Brotli.

Je viens de trouver un module zstd pour nginx : https://github.com/tokers/zstd-nginx-module

Mon ami m'a partagé cet excellent article : Choosing Between gzip, Brotli and zStandard Compression. Très complet, il explique tout, contient des benchmarks…

Voici ce que je retiens.

Brotli a été créé par Google, Zstandard par Facebook :

Zstandard is a newer compression method developed by Facebook.

source

Je lis sur canIuse, le support Zstandard a été ajouté à Chrome en mars 2024 et à Firefox en mai 2024, c'est donc une technologie très jeune coté browser.

Benchmark sur le dépôt officiel de Zstandard :

J'ai trouvé ces threads Hacker News :

Zstandard semble être fortement adopté au niveau de l'écosystème des OS Linux :

The Linux kernel has included Zstandard since November 2017 (version 4.14) as a compression method for the btrfs and squashfs filesystems.

source

Packages Ubuntu et Debian :

In March 2018, Canonical tested the use of zstd as a deb package compression method by default for the Ubuntu Linux distribution. Compared with xz compression of deb packages, zstd at level 19 decompresses significantly faster, but at the cost of 6% larger package files. Support was added to Debian in April 2018

source

Packages Fedora :

Fedora added ZStandard support to rpm in May 2018 (Fedora release 28) and used it for packaging the release in October 2019 (Fedora 31). In Fedora 33, the filesystem is compressed by default with zstd.

source

#JeMeDemande si dans mes projets de doit utiliser Zstandard plutôt que Brotli 🤔.

Je pense avoir trouver une réponse ici :

The research I’ve shared in this article also shows that for many sites Brotli will provide better compression for static content. Zstandard could potentially provide some benefits for dynamic content due to its faster compression speeds. Additionally:

  • ...
  • For dynamic content
    • Brotli level 5 usually result in smaller payloads, at similar or slightly slower compression times.
    • zStandard level 12 often produces similar payloads to Brotli level 5, with compression times faster than gzip and Brotli.
  • For static content
    • Brotli level 11 produces the smallest payloads
    • zStandard is able to apply their highest compression levels much faster than Brotli, but the payloads are still smaller with Brotli.

source

#JaimeraisUnJour prendre le temps d'installer zstd-nginx-module à mon image Docker nginx-brotli-docker (ou alors d'en trouver une déjà existante).

Alternatives managées à ngrok Developer Preview #DevOps, #network, #comparaison

Dans la note 2024-12-31_1853, j'ai présenté sish-playground qui permet de self host sish.

Je souhaite maintenant lister des alternatives à ngrok qui proposent des services gérés.

Quand je parle d'alternative à ngrok, il est question uniquement de la fonctionnalité d'origine de ngrok en 2013 : exposer des serveurs web locaux (localhost) sur Internet via une URL publique. ngrok nomme désormais ce service "Developer Preview".

Offre managée de sish

Les développeurs de sish proposent un service managé à 2 € par mois.

Ce service permet l'utilisation de noms de domaine personnalisés : https://pico.sh/custom-domains#tunssh.

Test de la fonctionnalité "Developer Preview" de ngrok

J'ai commencé par créer un compte sur https://ngrok.com.

Ensuite, une fois connecté, la console web de ngrok m'invite à installer le client ngrok. Voici la méthode que j'ai suivie sur ma Fedora :

$ wget https://bin.equinox.io/c/bNyj1mQVY4c/ngrok-v3-stable-linux-amd64.tgz -O ~/Downloads/ngrok-v3-stable-linux-amd64.tgz
$ sudo tar -xvzf ~/Downloads/ngrok-v3-stable-linux-amd64.tgz -C /usr/local/bin
$ ngrok --help
ngrok version 3.19.0
$ ngrok config add-authtoken 2r....RN
$ ngrok http http://localhost:8080
ngrok                                                                                                                                                         (Ctrl+C to quit)

👋 Goodbye tunnels, hello Agent Endpoints: https://ngrok.com/r/aep

Session Status                online
Account                       Stéphane Klein (Plan: Free)
Version                       3.19.0
Region                        Europe (eu)
Web Interface                 http://127.0.0.1:4040
Forwarding                    https://2990-2a04-cec0-107a-ea02-74d7-2487-cc11-f4d2.ngrok-free.app -> http://localhost:8080

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

Cette fonctionnalité de ngrok est gratuite.

Toutefois, pour pouvoir utiliser un nom de domaine personnalisé, il est nécessaire de souscrire à l'offre "personal" à $8 par mois.

Test de la fonctionnalité Tunnel de Cloudflare

Pour exposer un service local sur Internet via une URL publique avec cloudflared, je pense qu'il faut suivre la documentation suivante : Create a locally-managed tunnel (CLI).

J'ai trouvé sur cette page, le package rpm pour installer cloudflared sous Fedora :

$ wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm -O /tmp/cloudflared-linux-x86_64.rpm
$ sudo rpm -i /tmp/cloudflared-linux-x86_64.rpm
$ cloudflared --version
cloudflared version 2024.12.2 (built 2024-12-19-1724 UTC)

Voici comment exposer un service local sur Internet via une URL publique avec cloudflared sans même créer un compte :

$ cloudflared tunnel --url http://localhost:8080
...
Requesting new quick Tunnel on trycloudflare.com...
Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):
https://manufacturer-addressing-surgeon-tried.trycloudflare.com

Après cela, le service est exposé sur Internet sur l'URL suivante : https://manufacturer-addressing-surgeon-tried.trycloudflare.com.

Voici maintenant la méthode pour exposer un service sur un domaine spécifique.

Pour cela, il faut que le nom de domaine soit géré pour les serveurs DNS de cloudflare.
Au moment où j'écris cette note, c'est le cas pour mon domaine stephane-klein.info :

$ dig NS stephane-klein.info +short
ali.ns.cloudflare.com.
sri.ns.cloudflare.com.

Ensuite, il faut lancer :

$ cloudflared tunnel login

Cette commande ouvre un navigateur, ensuite il faut se connecter à cloudflare et sélectionner le nom de domaine à utiliser, dans mon cas j'ai sélectionné stephane-klein.info.

Ensuite, il faut créer un tunnel :

$ cloudflared tunnel create mytunnel
Tunnel credentials written to /home/stephane/.cloudflared/61b0e52f-13e3-4d57-b8da-6c28ff4e810b.json. …

La commande suivante, connecte le tunnel mytunnel au hostname mytunnel.stephane-klein.info :

$ cloudflared tunnel route dns mytunnel mytunnel.stephane-klein.info
2025-01-06T17:52:10Z INF Added CNAME mytunnel.stephane-klein.info which will route to this tunnel tunnelID=67db5943-1f16-4b4a-a307-e8ceeb01296c

Et, voici la commande pour exposer un service sur ce tunnel :

$ cloudflared tunnel --url http://localhost:8080 run mytunnel

Après cela, le service est exposé sur Internet sur l'URL suivante : https://mytunnel.stephane-klein.info.

Pour finir, voici comment détruire ce tunnel :

$ cloudflared tunnel delete mytunnel

J'ai essayé de trouver le prix de ce service, mais je n'ai pas trouvé. Je pense que ce service est gratuit, tout du moins jusqu'à un certain volume de transfert de données.

Comment lancer une image Docker de l'architecture "arm64" sous Intel ? #docker, #DevOps, #JeMeDemande

#JeMeDemande comment lancer une image Docker pour l'architecture arm64 sur une architecture Intel sous Fedora ?

Par défaut, l'exécution de cette image Docker sous Intel avec l'option --platform linux/arm64 ne fonctionne pas :

$ docker run --rm -it --platform linux/arm64 hasura/graphql-engine:v2.43.0 bash
exec /usr/bin/bash: exec format error

J'ai consulté et suivi la documentation Docker officielle suivante : Install QEMU manually.

$ docker run --privileged --rm tonistiigi/binfmt --install all
installing: arm64 OK
installing: arm OK
installing: ppc64le OK
installing: riscv64 OK
installing: mips64le OK
installing: s390x OK
installing: mips64 OK
{
  "supported": [
    "linux/amd64",
    "linux/arm64",
    "linux/riscv64",
    "linux/ppc64le",
    "linux/s390x",
    "linux/386",
    "linux/mips64le",
    "linux/mips64",
    "linux/arm/v7",
    "linux/arm/v6"
  ],
  "emulators": [
    "qemu-aarch64",
    "qemu-arm",
    "qemu-mips64",
    "qemu-mips64el",
    "qemu-ppc64le",
    "qemu-riscv64",
    "qemu-s390x"
  ]
}

Après cela, je constate que j'arrive à lancer avec succès une image arm64 sous processeur Intel :

$ docker run --rm -it --platform linux/arm64 hasura/graphql-engine:v2.43.0 bash

root@bf74bfb8bc35:/# graphql-engine version
Hasura GraphQL Engine (Pro Edition): v2.43.0

J'ai pris un peu de temps pour explorer le repository tonistiigi/binfmt.
Je n'ai pas compris quelle est l'interaction entre les éléments installés par cette image et docker-engine.
Je constate que cette image a été créée en 2019 par deux développeurs de Docker : CrazyMax (un Français) et Tõnis Tiigi.