Administrer les paquets avec APK sur Alpine Linux

APK (Alpine Package Keeper) est le gestionnaire de paquets d'Alpine Linux. Vous le croisez surtout dans les images de conteneurs, là où chaque mégaoctet compte. Cette page vous donne les commandes du quotidien (add, del, update, upgrade, info, search), les deux idiomes qui font la différence dans un Dockerfile (--no-cache et --virtual .build-deps), la façon correcte de vérifier l'intégrité d'un système Alpine, et la construction d'un dépôt local signé. Elle s'adresse aux administrateurs et aux développeurs qui construisent des images et maintiennent des serveurs minimalistes.

Ce que vous allez apprendre

1. Installer, supprimer et mettre à jour des paquets Alpine, et vérifier le résultat après chaque action.
2. Choisir une branche Alpine supportée et configurer les dépôts en conséquence.
3. Appliquer les idiomes conteneurs --no-cache et --virtual .build-deps pour alléger vos images.
4. Auditer l'intégrité des fichiers installés et réparer un paquet altéré.
5. Construire un paquet avec abuild et publier un dépôt local signé.
6. Distinguer apk-tools 2 et apk-tools 3, dont les comportements divergent.

Prérequis et portée

Vous avez besoin d'un système Alpine, ou plus simplement d'un conteneur jetable, qui suffit pour tout ce qui suit sauf la partie dépôt local :

docker run --rm -it alpine:3.22 sh

Portée : commun Linux, hors programme LFCS et RHCSA (ces examens portent sur apt et dnf). Niveau : L2 opérationnel. Capacité visée : construire une image Alpine sans cache résiduel ni outils de compilation, et prouver que le système installé n'a pas été altéré.

Alpine et APK en deux minutes

Alpine Linux est une distribution volontairement minimaliste. Elle remplace la bibliothèque C glibc par musl libc, plus légère, et regroupe les commandes Unix courantes dans un binaire unique, BusyBox. Résultat : une image de base d'environ 8 Mo, contre plusieurs dizaines de mégaoctets pour une Debian ou une Ubuntu.

Ce choix a un prix. Les binaires compilés pour glibc ne fonctionnent pas tels quels sur musl, ce qui provoque des surprises avec certains logiciels propriétaires ou des paquets Python compilés. Alpine excelle sur les conteneurs, les systèmes embarqués et les serveurs à usage unique. Ce n'est pas une distribution de poste de travail.

APK est l'outil qui installe, supprime et met à jour les logiciels. Il travaille avec des archives .apk contenant les binaires, les métadonnées et les dépendances, et il maintient l'état du système dans un fichier texte lisible, /etc/apk/world. Sa vitesse d'exécution est sa signature : une installation qui prend plusieurs secondes avec apt se règle souvent en une fraction de seconde.

Les deux générations d'apk-tools

C'est le point le plus important à connaître aujourd'hui, et celui qui piège le plus de monde. apk-tools a changé de version majeure, et les deux générations cohabitent selon la branche Alpine que vous utilisez.

Branche Alpine	Version d'apk-tools	Sortie	Fin de support
v3.21	apk-tools 2.14	2024-12-05	2026-11-01
v3.22	apk-tools 2.14	2025-05-30	2027-05-01
v3.23	apk-tools 3.0	2025-12-03	2027-11-01
v3.24	apk-tools 3.0	2026-06-09	2028-06-01

Glissez pour voir

Vérifiez toujours à quelle génération vous avez affaire avant de copier une commande trouvée en ligne :

apk --version

Sur Alpine 3.22, la sortie affiche apk-tools 2.14.10, compiled for x86_64. ; sur Alpine 3.24, elle affiche apk-tools 3.0.6-r0, compiled for x86_64..

La bonne nouvelle : toutes les commandes courantes de cette page fonctionnent à l'identique sur les deux générations. add, del, update, upgrade, search, info, policy, audit, fix, verify et index gardent la même syntaxe. Les différences portent sur des options rares et sur le format des messages. Une divergence mérite d'être signalée : apk-tools 3 accepte les options abrégées, ce qui peut faire passer une faute de frappe pour une option valide. Écrire apk fix --check en croyant lancer une simulation exécute en réalité un vrai apk fix, parce que --check est interprété comme un raccourci de --check-certificate.

Il n'existe pas d'option de simulation nommée --check

Pour simuler une opération sans rien modifier, l'option est -s (--simulate) : apk add -s htop affiche les paquets qui seraient installés et ne touche à rien. Contrôlez ensuite avec apk info -e htop, qui ne renvoie rien si le paquet n'est pas installé.

Choisir une branche Alpine supportée

Chaque branche stable d'Alpine est supportée deux ans à partir de sa sortie. Passé cette date, elle ne reçoit plus aucun correctif de sécurité, et les dépôts finissent par disparaître du miroir principal. C'est un piège classique : une image alpine:3.18 continue de se télécharger sans erreur alors que la branche est en fin de vie depuis mai 2025.

Les branches se déclinent en trois canaux :

• main : paquets stables, maintenus par l'équipe Alpine, avec support de sécurité.
• community : paquets maintenus par la communauté, support de sécurité assuré pendant la durée de vie de la branche.
• testing : uniquement disponible sur edge, sans aucune garantie.

À côté des branches numérotées, edge est la branche de développement en rolling release. Elle est toujours à jour mais peut casser du jour au lendemain. En production, restez sur une branche stable avec main et community ; réservez edge aux environnements de test.

Pour connaître la version installée :

cat /etc/alpine-release

La sortie affiche par exemple 3.22.5. Si le premier nombre correspond à une branche dont la date de fin de support est dépassée, planifiez la montée de version.

Configurer les dépôts

APK ne connaît que les dépôts listés dans /etc/apk/repositories, un simple fichier texte, une URL par ligne. C'est le point central de la configuration, et il n'y a rien d'autre à connaître.

Sur une image Alpine 3.22, il contient exactement ceci :

https://dl-cdn.alpinelinux.org/alpine/v3.22/main
https://dl-cdn.alpinelinux.org/alpine/v3.22/community

Préfixez une ligne par # pour désactiver un dépôt sans le supprimer. Pour changer de branche, remplacez le numéro de version dans les deux URL, puis appliquez la bascule avec apk upgrade --available (détaillé plus bas). Toute modification de ce fichier exige un apk update pour être prise en compte.

Ajouter un dépôt tiers et sa clé

APK refuse par défaut tout paquet non signé par une clé qu'il connaît. Les clés publiques de confiance vivent dans /etc/apk/keys/. Ajouter un dépôt interne demande donc deux gestes : déclarer l'URL, puis installer la clé publique correspondante.

echo "https://depot.interne.example/alpine/v3.22/main" >> /etc/apk/repositories
wget -O /etc/apk/keys/depot-interne.rsa.pub https://depot.interne.example/depot-interne.rsa.pub
apk update

La sortie d'apk update doit lister votre dépôt sans avertissement. Si vous voyez UNTRUSTED signature, la clé publique est absente ou ne correspond pas à celle qui a signé l'index.

--allow-untrusted n'est pas une solution

L'option --allow-untrusted fait taire l'erreur de signature en désactivant la vérification cryptographique. Elle rend votre système vulnérable à un paquet falsifié servi par un miroir compromis. Réservez-la à un test local jetable, et installez la vraie clé publique partout ailleurs.

Les commandes du quotidien

Ces six commandes couvrent la quasi-totalité des besoins. Chacune est présentée avec sa commande de vérification, parce qu'une installation qui affiche OK ne prouve pas encore que le binaire attendu est en place.

Mettre à jour l'index des dépôts

apk update télécharge les métadonnées des paquets depuis les URL déclarées. C'est le préalable à toute installation, et le seul moyen de voir apparaître un paquet publié récemment.

apk update

La sortie se termine par une ligne du type OK: 26325 distinct packages available, qui confirme le nombre de paquets vus dans les dépôts.

Installer un paquet

apk add installe un ou plusieurs paquets et résout automatiquement les dépendances.

apk add htop curl

Vérifiez que le paquet est bien enregistré, sans parcourir toute la sortie :

apk info -e htop

La commande affiche htop s'il est installé et ne renvoie rien sinon. Son code de retour vaut 0 ou 1 selon le cas, ce qui la rend utilisable dans un script.

Supprimer un paquet

apk del retire le paquet et ses dépendances devenues orphelines. C'est un comportement plus agressif qu'apt remove, et c'est voulu.

apk del htop

La sortie détaille les suppressions en cascade :

(1/4) Purging htop (3.5.1-r1)
(2/4) Purging lsof (4.99.6-r0)
(3/4) Purging libncursesw (6.6_p20260516-r0)
(4/4) Purging ncurses-terminfo-base (6.6_p20260516-r0)

Les bibliothèques tirées uniquement par htop partent avec lui. En revanche, les fichiers de configuration que vous avez modifiés à la main sont conservés.

Mettre à jour le système

apk upgrade amène tous les paquets à la dernière version disponible dans la branche configurée. Il ne fait pas passer d'Alpine 3.22 à 3.24 : pour cela, il faut d'abord modifier /etc/apk/repositories.

apk update && apk upgrade

Pour forcer la bascule après un changement de branche dans le fichier de dépôts, ajoutez --available (abrégé -a), qui réinstalle les paquets dont la version diffère même si le numéro semble équivalent :

apk upgrade --available

apk add --upgrade --available n'existe pas

Cette combinaison, souvent recopiée d'un forum à l'autre, est rejetée par les deux générations d'apk-tools avec unrecognized option 'available'. L'option --available appartient à apk upgrade, pas à apk add.

Rechercher et inspecter

apk search interroge les dépôts. Ajoutez -v pour afficher la description en regard de chaque résultat, ce qui évite d'installer un paquet au jugé.

apk search -v htop

htop-3.5.1-r1 - Interactive process viewer
htop-doc-3.5.1-r0 - Interactive process viewer (documentation)

apk info détaille un paquet. Sans option, il n'affiche que la description ; c'est -a qui donne la vue complète (version, page web, licence, dépendances, fichiers). Deux variantes rendent service au quotidien : apk info -W répond à la question « quel paquet possède ce fichier », et apk policy montre quel dépôt fournit quelle version.

apk info -W /usr/bin/htop
apk policy htop

/usr/bin/htop is owned by htop-3.5.1-r1
htop policy:
  3.5.1-r1:
    lib/apk/db/installed
    https://dl-cdn.alpinelinux.org/alpine/v3.24/main

La ligne lib/apk/db/installed signifie que cette version est celle actuellement installée. apk policy est l'outil de diagnostic à sortir quand un paquet ne se met pas à jour comme prévu : il révèle immédiatement si un dépôt tiers fournit une version concurrente.

Épingler une version précise

Vous pouvez demander une version exacte avec la syntaxe paquet=version. C'est la base d'une image reproductible : sans épinglage, deux constructions à quelques semaines d'intervalle n'embarquent pas les mêmes binaires.

apk add "htop=3.5.1-r1"

Le suffixe -r1 est le numéro de révision Alpine du paquet : il change quand Alpine recompile le logiciel sans que sa version amont bouge. Il fait partie intégrante de l'identifiant et ne peut pas être omis.

Attention au couplage fort avec la branche. Une version présente dans Alpine 3.22 n'existe pas forcément dans 3.24, et la commande échoue alors sans ambiguïté :

ERROR: unable to select packages:
    breaks: world[htop=3.4.1-r0]

C'est le principal reproche fait à l'épinglage sur Alpine : il casse à chaque montée de branche. Le compromis que je retiens consiste à épingler l'image de base par son empreinte et à laisser les paquets suivre la branche, ce que décrit la section suivante.

Les deux idiomes conteneurs qui changent tout

Si vous ne deviez retenir que deux choses d'APK, ce sont celles-ci. Elles n'existent pas dans apt ou dnf sous cette forme, et elles expliquent pourquoi les images Alpine sont si compactes.

--no-cache : ne rien laisser derrière soi

Par défaut, apk écrit les index téléchargés dans /var/cache/apk/. Dans un conteneur, ces fichiers sont inutiles après la construction, mais ils sont figés dans la couche d'image. Le constat est net :

docker run --rm alpine:3.22 sh -c "apk add curl >/dev/null 2>&1; du -sh /var/cache/apk"

2.5M  /var/cache/apk

2,5 Mo de déchets sur une image de base qui en pèse 8. Avec --no-cache, APK télécharge l'index, l'utilise en mémoire et ne l'écrit jamais sur disque :

docker run --rm alpine:3.22 sh -c "apk add --no-cache curl >/dev/null 2>&1; du -sh /var/cache/apk"

4.0K  /var/cache/apk

Le répertoire est vide. C'est aussi la raison pour laquelle apk update devient superflu dans un Dockerfile : --no-cache rafraîchit l'index à chaque invocation. La vieille formule apk update && apk add ... && rm -rf /var/cache/apk/* que l'on trouve encore partout est obsolète et se remplace par une seule ligne.

FROM alpine@sha256:14358309a308569c32bdc37e2e0e9694be33a9d99e68afb0f5ff33cc1f695dce  # alpine:3.22

RUN apk add --no-cache curl ca-certificates

L'image de base est ici épinglée par son empreinte sha256 plutôt que par son étiquette : une étiquette comme alpine:3.22 est réattribuée à chaque correctif, l'empreinte non.

--virtual : installer pour compiler, puis tout retirer

Beaucoup de paquets Python, Node ou Ruby doivent être compilés à l'installation, ce qui exige un compilateur et des en-têtes de développement. Garder gcc dans l'image finale, c'est transporter des centaines de mégaoctets inutiles et élargir la surface d'attaque pour rien.

L'option --virtual regroupe plusieurs paquets sous un nom collectif, que vous supprimez ensuite d'un seul geste. La convention est de l'appeler .build-deps, le point initial n'ayant aucune signification particulière pour APK.

apk add --no-cache --virtual .build-deps gcc musl-dev python3-dev linux-headers

Le groupe apparaît dans /etc/apk/world sous la forme d'un paquet virtuel horodaté, ce qui prouve qu'APK le traite comme une entité à part entière :

.build-deps=20260712.082138
python3

Une fois la compilation terminée, un seul apk del fait le ménage :

apk del .build-deps

Vérifiez que le compilateur est bien parti alors que l'application reste fonctionnelle :

command -v gcc || echo "gcc absent"
python3 -c "import psutil; print(psutil.__version__)"

Le point critique est que tout doit tenir dans une seule instruction RUN. Une couche Docker est immuable : si vous installez gcc dans un RUN et le supprimez dans le suivant, la couche intermédiaire contient toujours les centaines de mégaoctets du compilateur, et l'image finale ne maigrit pas d'un octet.

FROM alpine@sha256:14358309a308569c32bdc37e2e0e9694be33a9d99e68afb0f5ff33cc1f695dce  # alpine:3.22

RUN apk add --no-cache python3 py3-pip && \
    apk add --no-cache --virtual .build-deps gcc musl-dev python3-dev linux-headers && \
    pip install --no-cache-dir --break-system-packages "psutil==7.0.0" && \
    apk del .build-deps

Le && n'est pas cosmétique : il enchaîne les commandes dans la même couche. C'est l'unique raison pour laquelle l'astuce fonctionne. Le gain est massif : cette image pèse 111 Mo, contre 420 Mo pour la même recette privée du --virtual et du apk del, soit 309 Mo de compilateur et d'en-têtes qui ne partent jamais en production.

Notez au passage linux-headers dans les dépendances de compilation. C'est le genre de paquet qu'on découvre en lisant le message d'erreur de pip : sans lui, la compilation de psutil s'arrête sur fatal error: linux/ethtool.h: No such file or directory. Les dépendances de build sont spécifiques à chaque bibliothèque, et il n'existe pas de liste universelle : partez de gcc musl-dev, ajoutez les en-têtes réclamés par le message d'erreur, et n'oubliez pas de les inclure dans le groupe .build-deps pour qu'ils repartent avec lui.

Le réflexe à garder

--no-cache sur tous les apk add d'un Dockerfile, et --virtual .build-deps dès qu'un compilateur entre en jeu, avec le apk del dans le même RUN. Ces deux réflexes suffisent à expliquer l'essentiel de l'écart de taille entre une image Alpine soignée et une image négligée.

Pour aller plus loin sur la construction d'images légères, la page Optimiser la taille des images de conteneur couvre les étapes multiples et le choix de l'image de base.

Vérifier l'intégrité et auditer le système

C'est la section où les erreurs sont les plus fréquentes, parce que deux commandes portent des noms trompeusement proches. apk verify et apk audit ne font pas le même travail.

apk verify contrôle des fichiers .apk, pas des paquets installés

apk verify prend en argument des fichiers .apk et valide leur somme de contrôle ainsi que leur signature cryptographique. Lui passer le nom d'un paquet installé produit une erreur, ce qui déroute beaucoup de monde :

apk verify openssh

openssh: -2 - No such file or directory

L'usage correct porte sur une archive, typiquement récupérée avec apk fetch avant une installation hors ligne :

apk fetch curl
apk verify curl-8.14.1-r2.apk

curl-8.14.1-r2.apk: 0 - OK

Sur une archive altérée, ne serait-ce que d'un octet, la commande échoue avec un code de retour non nul :

t.apk: -5 - IO ERROR

apk audit compare les fichiers installés à la base de paquets

Pour répondre à la vraie question, « les fichiers de mon système ont-ils été modifiés depuis leur installation », l'outil est apk audit. Sans option, il n'inspecte que les fichiers de configuration (les chemins protégés, sous /etc pour l'essentiel). L'option --system étend le contrôle à tous les autres fichiers, binaires et bibliothèques compris.

apk audit --system

Sur un système sain, la commande n'affiche rien et retourne 0. Altérons un binaire pour la voir travailler :

printf zz >> /usr/bin/curl
apk audit --system

U usr/bin/curl

Le préfixe U signale un fichier modifié ; un A signalerait un fichier ajouté hors de tout paquet. L'option --packages remonte directement au paquet fautif, ce qui est exactement ce dont vous avez besoin pour agir :

apk audit --system --packages

curl-8.14.1-r2

Réparer avec apk fix

apk fix réinstalle les paquets indiqués et rétablit les fichiers d'origine. C'est la suite logique d'un audit qui a trouvé quelque chose.

apk fix curl

Le contrôle d'après doit repartir vide, ce qui prouve que le système est revenu à son état de référence :

apk audit --system

Sans argument, apk fix s'attaque à l'ensemble des paquets et à la cohérence du fichier world. Notez qu'il ne détecte pas seul un binaire altéré : c'est apk audit qui trouve, apk fix qui répare. Enchaîner les deux constitue le duo à retenir.

/etc/apk/world, l'état déclaré du système

/etc/apk/world est la liste des paquets que vous avez explicitement demandés. Les dépendances tirées automatiquement n'y figurent pas. apk add ajoute une ligne, apk del la retire, et APK considère ce fichier comme la vérité de référence sur ce que le système doit contenir.

cat /etc/apk/world

alpine-baselayout
alpine-keys
alpine-release
apk-tools
busybox
curl
htop
musl-utils

C'est un fichier texte trivial, donc versionnable dans Git. Il en découle un usage très pratique : reconstituer un système à l'identique ailleurs.

cp /etc/apk/world packages.list

Puis sur la machine cible :

apk add $(cat packages.list)

La sortie se termine par un décompte du type OK: 14.0 MiB in 29 packages, qu'il suffit de comparer avec celui de la machine d'origine. Vous pouvez aussi éditer world à la main, mais les modifications ne prennent effet qu'après un apk fix, qui réconcilie l'état réel avec l'état déclaré.

Mode diskless : rien ne survit au redémarrage

Alpine peut tourner entièrement en RAM, sur un système sans disque. Les paquets installés et les modifications de world disparaissent alors au redémarrage tant qu'ils n'ont pas été figés avec lbu commit -d. Les sous-commandes lbu diff, lbu list et lbu revert permettent d'inspecter et d'annuler ces sauvegardes. Ce mode concerne les usages embarqués et les routeurs, pas les conteneurs.

Le cache APK sur un système installé

Contrairement à ce que l'on lit souvent, il n'existe pas d'option --cache. La tenter renvoie apk: option is ambiguous: cache. Le cache est un répertoire que l'on active en créant le lien symbolique /etc/apk/cache, ce que fait l'installateur d'Alpine sur une machine réelle et que l'image Docker ne fait pas.

Là où le cache existe, les archives .apk téléchargées y sont conservées, ce qui accélère les réinstallations et permet de travailler hors ligne. Le ménage se fait avec :

apk cache clean

Sur un système sans cache configuré, la commande ne fait rien et retourne 0, sans erreur. Vérifiez l'espace récupéré avec du -sh /var/cache/apk. Dans un conteneur, la question ne se pose pas : --no-cache a déjà tout réglé.

Créer un paquet et un dépôt local signé

Distribuer un binaire interne ou un script maison comme un vrai paquet apporte la gestion des versions, la désinstallation propre et la vérification de signature. L'outil est abuild, fourni par le méta-paquet alpine-sdk.

1. Préparer l'environnement de compilation. abuild refuse de tourner en tant que root : il faut un utilisateur membre du groupe abuild.

   apk add alpine-sdk
   adduser -D builder
   addgroup builder abuild

2. Générer la clé de signature et l'installer. L'option -a enregistre la clé privée dans la configuration d'abuild, -n évite les questions interactives. La clé publique doit être copiée dans /etc/apk/keys/ avant la construction, sinon abuild échoue en signant l'index avec UNTRUSTED signature.

   su - builder -c 'abuild-keygen -a -n'
   cp /home/builder/.abuild/*.rsa.pub /etc/apk/keys/

3. Écrire le fichier APKBUILD. Il décrit le paquet. Le champ arch est obligatoire : sans lui, la construction s'arrête. Utilisez noarch pour un script indépendant du processeur.

   pkgname=hello
   pkgver=1.0
   pkgrel=0
   pkgdesc="Un script de test"
   url="https://exemple.local"
   arch="noarch"
   license="MIT"
   source="hello.sh"
   
   package() {
     install -Dm755 "$srcdir/hello.sh" "$pkgdir/usr/bin/hello"
   }

4. Calculer les sommes de contrôle, puis construire. abuild checksum est un préalable obligatoire : abuild -r refuse de démarrer si les sources ne sont pas empreintées.

   su - builder -c 'cd ~/hello && abuild checksum && abuild -r'

   Le paquet atterrit dans ~/packages/<dépôt>/<arch>/, avec un index déjà signé :

   /home/builder/packages/builder/x86_64/APKINDEX.tar.gz
   /home/builder/packages/builder/x86_64/hello-1.0-r0.apk

5. Indexer et signer un dépôt monté à la main. apk index construit l'index, abuild-sign le signe. Cette dernière commande exige le nom du fichier d'index : lancée seule, elle se contente d'afficher son aide et sort en erreur.

   apk index --rewrite-arch x86_64 -o APKINDEX.tar.gz *.apk
   abuild-sign APKINDEX.tar.gz

   La sortie confirme la signature : >>> Signed /srv/depot/x86_64/APKINDEX.tar.gz.

6. Installer depuis le dépôt local. Le chemin passé à APK est celui du répertoire parent du dossier d'architecture, pas le dossier lui-même : APK ajoute /x86_64/ tout seul.

   apk add -X /srv/depot hello
   hello

   La sortie affiche Bonjour depuis un paquet APK maison, et apk info -e hello confirme l'enregistrement.

Deux détails expliquent la majorité des échecs sur cette procédure. D'abord l'ordre : la clé publique doit être en place avant abuild -r, parce que la construction se termine par une signature d'index qu'APK refuse s'il ne connaît pas la clé. Ensuite le chemin du dépôt : pointer -X directement sur le dossier x86_64 donne un no such package déroutant, alors que le paquet est bien là. L'option --rewrite-arch sert quant à elle à réconcilier un paquet noarch déposé dans un répertoire d'architecture concrète.

Pour rendre le dépôt permanent, ajoutez son chemin ou son URL à /etc/apk/repositories, comme n'importe quel dépôt distant.

Sécurité et points de vigilance

La sécurité d'APK repose entièrement sur la chaîne de signatures. Chaque index de dépôt est signé, chaque clé de confiance vit dans /etc/apk/keys/, et un paquet dont la signature ne correspond pas est rejeté. Ce mécanisme ne protège que si vous ne le contournez pas.

Les trois erreurs que je vois revenir le plus souvent tiennent en peu de mots. Utiliser --allow-untrusted pour « faire passer » une installation qui râle supprime la seule barrière contre un paquet falsifié. Rester sur une branche en fin de vie prive le système de correctifs de sécurité tout en donnant l'illusion que tout va bien, puisque apk upgrade continue de répondre OK. Enfin, laisser gcc et les en-têtes de développement dans une image de production offre à un attaquant de quoi compiler ses propres outils depuis l'intérieur du conteneur.

Le contrôle de routine tient en deux commandes, à intégrer dans une tâche planifiée ou dans un scan d'image :

apk update && apk upgrade
apk audit --system --packages

La première applique les correctifs, la seconde prouve que les fichiers installés correspondent toujours aux paquets d'origine. Une sortie vide sur la seconde est le résultat attendu.

Dépannage

Voici les symptômes rencontrés le plus souvent, avec leur cause réelle. La colonne « solution » donne la commande à lancer, pas une piste vague.

Symptôme	Cause probable	Solution
ERROR: unable to select packages	Index non rafraîchi, ou paquet absent de la branche	apk update, puis apk search -v <motif> pour vérifier le nom exact
UNTRUSTED signature	Clé publique du dépôt absente de /etc/apk/keys/	Installer la clé publique du dépôt, puis relancer apk update
breaks: world[paquet=version]	Version épinglée inexistante dans la branche configurée	apk policy <paquet> pour voir les versions réellement disponibles
openssh: -2 - No such file or directory sur apk verify	apk verify attend un fichier .apk, pas un nom de paquet	Utiliser apk audit --system pour les fichiers installés
no such package sur un dépôt local	Chemin -X pointé sur le dossier d'architecture	Pointer -X sur le répertoire parent de x86_64
WARNING: opening from cache ... No such file or directory	Index absent du cache après un apk add --no-cache	Sans conséquence, ou apk update si la commande a besoin de l'index
Image de conteneur anormalement grosse	apk add sans --no-cache, ou apk del dans un autre RUN	Ajouter --no-cache et regrouper installation et suppression dans un seul RUN

Glissez pour voir

• 10 questions tirées aléatoirement de la banque de questions,
• 5 minutes pour répondre,
• 80 % de bonnes réponses pour valider.

L'objectif est de vous assurer que vous maîtrisez assez APK pour construire une image Alpine propre et maintenir un serveur minimaliste. N'hésitez pas à refaire le test plusieurs fois.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• APK est un gestionnaire de paquets, pas une variante d'apt : apk del supprime aussi les dépendances devenues orphelines, et /etc/apk/world sert de référence de l'état déclaré du système.
• Deux générations cohabitent : apk-tools 2 sur Alpine 3.22 et antérieures, apk-tools 3 à partir d'Alpine 3.23. Les commandes courantes sont identiques ; vérifiez avec apk --version.
• Une branche Alpine est supportée deux ans. Une image alpine:3.18 se télécharge toujours mais ne reçoit plus de correctif de sécurité depuis mai 2025.
• --no-cache sur tous les apk add d'un Dockerfile : cela évite 2,5 Mo d'index figés dans la couche et rend apk update inutile.
• --virtual .build-deps puis apk del .build-deps dans le même RUN : 111 Mo au lieu de 420 Mo sur une image Python, et pas de compilateur laissé en production.
• apk verify porte sur des fichiers .apk, jamais sur un paquet installé. Pour contrôler les fichiers d'un système, c'est apk audit --system, et apk fix <paquet> pour réparer.
• La signature n'est pas optionnelle : installez la clé publique dans /etc/apk/keys/ plutôt que de recourir à --allow-untrusted.
• Un dépôt local se déclare par son répertoire parent : apk add -X /srv/depot, jamais -X /srv/depot/x86_64.

Articles qui pourraient vous intéresser

• Optimiser la taille des images de container
• Dockerfile : bonnes pratiques
• Administrer les paquets avec APT
• Les commandes Docker à connaître
• Build d'images en parallèle avec Ansible

×

📖 Voir la documentation →