Quand et pourquoi devrais-je utiliser la mise à jour apt-get?


15

Question générale:

Certains pourraient-ils expliquer ce que fait la commande apt-get updateet quand je devrais vraiment l'utiliser?


Remarques

Veuillez donner une réponse détaillée . Pas seulement une copie de la page de manuel, à moins que votre version ne soit vraiment détaillée (je mets une définition de la page de manuel ci-dessous).

mise à jour apt-get : utilisé pour resynchroniser les fichiers d'index des packages à partir de leurs sources. Les index des packages disponibles sont récupérés à partir des emplacements spécifiés dans /etc/apt/sources.list(5). Une mise à jour doit toujours être effectuée avant une mise à niveau ou une mise à niveau distante.


Sous-questions:

  • Où est stocké l'index du package? Sur une base de données? Sur un dossier?
  • Que se passe-t-il si je fais apt-get installsans mettre à jour le cache? Y a-t-il une chance que le package distant n'existe plus et que le lien soit rompu?
  • Y a-t-il une politique politique convenue sur les dépôts Deb? Par exemple, un référentiel doit-il contenir uniquement la dernière version d'un package, ou au contraire doit-il contenir toutes les versions disponibles pour une version de distribution spécifique?

Le contexte

Je pose ma question car j'étudie le framework Docker . L'une de ses fonctionnalités est le Dockerfile , qui vous permet de créer une sorte d'image du système d'exploitation en exécutant des instructions à partir de ce fichier. Une propriété de cette image est qu'elle doit toujours être la même, quel que soit le contexte (moment de la construction, etc.).

J'ai peur que si je lance la apt-get updatecommande à un moment différent, le résultat serait différent et donc mes images seraient différentes.


Je pense que ce message pourrait servir d'article wiki pour savoir comment poser une question de haut niveau. Très utile.
Zerodf

Réponses:


12

apt-get update télécharge la liste des packages disponibles.

La liste des packages peut évoluer dans le temps. De nouveaux packages sont ajoutés et les anciens packages sont supprimés. Ainsi, si vous avez un cache vraiment ancien et que vous essayez d'en faire un apt-get install, il peut essayer de télécharger un package qui n'existe plus.
La durée de conservation d'un ancien package dans un référentiel dépend du responsable du référentiel (votre distribution). En tant que tel, si vous utilisez quelque chose comme docker, où le cache peut être très obsolète, vous devez toujours exécuter apt-get updateavant d'installer des packages.

La raison de la suppression et de l'ajout de packages est principalement la correction de bugs et les mises à jour de sécurité. Bien que si vous utilisez des référentiels tiers comme PPA, tout se passe.

Lorsque vous utilisez quelque chose comme Docker pour la conteneurisation dans un environnement d'entreprise, vous devez créer le conteneur une fois, puis déplacer ce conteneur dans vos différents environnements de version (développement, transfert, production) et ne pas reconstruire le conteneur à chaque fois. Cela garantira que vous n'obtiendrez pas un autre conteneur qui n'a pas été testé.

Pour répondre à votre question de savoir où vivent les fichiers de cache, /var/lib/apt/lists.


Très bonne réponse! Je vous remercie! Je veux réagir pour le paragraphe "(...) ne pas reconstruire le conteneur à chaque fois. Cela garantira que vous n'obtiendrez pas un conteneur différent qui n'a pas été testé." J'ai lu qu'une meilleure pratique est de ne jamais utiliser la mise à niveau apt-get. L'une des raisons serait: "Elle produit également des images incohérentes car vous n'avez plus une seule source de vérité sur la façon dont votre application doit s'exécuter et sur les versions des dépendances incluses dans l'image." N'est-ce pas le même problème avec apt-get updatealors? Et Dockerfile ne sont pas censés garantir l'image?
Pierre-Jean

2
Un peu. apt-get updaten'affectera que les packages nouvellement installés. Les packages existants ne seront mis à niveau que si les nouveaux packages en ont besoin (cela devrait être minimal). Avec apt-get upgradevous mettez à niveau tous les packages, y compris ceux existants, ce qui donne une image très différente. Bien que cela puisse entraîner un résultat différent chaque fois que vous créez à partir du dockerfile, je ne pense pas personnellement que ce soit un problème grave si vous passez par une version multi-environnement. Je pense que c'est plus un problème si vous distribuez le dockerfile à d'autres personnes et demandez-leur de le créer.
Patrick

0

Certains pourraient-ils expliquer ce que fait la commande apt-get update et quand je devrais vraiment l'utiliser?

apt-get update télécharge les index mis à jour à partir des référentiels de packages de la distribution, répertoriant tous les packages disponibles et leurs versions précises.

Les distributions communes comme Ubuntu et Debian sont généralement conservatrices et rétrocompatibles dans leurs offres de paquets, donc les versions ne changeront pas beaucoup au fil du temps; ils changeront en raison de mises à jour de sécurité ou de corrections de bogues. Par exemple, MySQL pourrait être mis à jour à partir 5.7.18de , 5.7.19mais pas 6.x.

Où est stocké l'index du package? Sur une base de données? Sur un dossier?

Il est généralement stocké dans un ou plusieurs fichiers à l'intérieur /var/lib/apt. Dans le contexte de Docker, ces fichiers sont à l'intérieur de l'image. Lors de la construction du Dockerfile, ils sont stockés dans les nouvelles couches du système de fichiers qui sont créées et conservées en tant que nouvelle image.

Que se passe-t-il si je fais l'installation d'apt-get sans mettre à jour le cache?

Vous pouvez essayer de télécharger des versions de packages qui n'existent plus. C'est assez courant sur les machines virtuelles, mais c'est également possible à l'intérieur des conteneurs si les référentiels de distribution ont publié de nouveaux packages après la construction de l'image de base. Il peut ne pas y avoir de coordination entre les responsables de la distribution et les responsables du Dockerfile, qui sont en aval de la distribution et peuvent être plus nombreux. Il n'y a qu'un seul référentiel Debian mais des milliers d' jessieimages de conteneurs et de Dockerfile.

De plus, certaines images en amont comme celle d'ubuntu suppriment l'index téléchargé pour réduire l'image et éviter les fichiers obsolètes. Il est donc attendu qu'un index mis à jour soit téléchargé lors de la construction au-dessus d'une image de base, et non pour chaque version d'une image de base à expédier avec le dernier index.

Y a-t-il une chance que le package distant n'existe plus et que le lien soit rompu?

Certainement, car les versions stockées dans l'index sont très précises comme 5.7.19(simplification; elles sont plus similaires à 5.7.19-0ubuntu1).

Y a-t-il une politique politique convenue sur les dépôts Deb? Par exemple, un référentiel doit-il contenir uniquement la dernière version d'un package, ou au contraire doit-il contenir toutes les versions disponibles pour une version de distribution spécifique?

Il est courant que les anciennes versions mineures soient supprimées rapidement une fois qu'une mise à jour est disponible; Je suppose que c'est pour économiser de l'espace sur les serveurs car les binaires peuvent peser plusieurs dizaines de mégaoctets, multipliés par toutes les versions et architectures prises en charge. Il est donc généralement impossible de préciser, par exemple, mysql-5.7.18dans la suite apt-get install; dès qu'il mysql-5.7.19est publié dans la distribution, le précédent sera supprimé.

Pour être juste envers Docker, ce non-déterminisme apt-get updateest un problème qui est signalé dans le cadre de la gestion des packages de chaque distribution. Vous auriez le même problème en essayant de construire de manière répétitive une machine virtuelle EC2 ou Vagrant.

Certains administrateurs système utilisent des services tels qu'Aptly pour mettre en miroir les référentiels d'origine et pouvoir épingler une version particulière, mais vous courez le risque de manquer des mises à jour de sécurité, sauf si vous avez un processus distinct fréquemment exécuté pour tester les mises à jour et modifier ce que vous épinglent.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.