Нужно ли в Dockerfile прописывать конкретные версии пакетов?

Question

[Chheza]

Если мы откроем https://hub.docker.com/_/php, то в разделе «PHP Core Extensions» увидим:

RUN apt-get update && apt-get install -y \
		libfreetype6-dev \
		libjpeg62-turbo-dev \
		libpng-dev

Мы поставим пакеты, соберем контейнер и запустим - всё будет работать.
Через время какой-то пакет, например, libpng-dev, обновится и сломает обратную совместимость.
Мы соберем контейнер ещё раз - и он работать уже не будет, несмотря на то, что у нас старый, рабочий Dockerfile.

Нужно ли в таких случаях указывать конкретные версии пакетов, чтобы ставились именно они, и мы были уверены, что сборка всегда будет одинаковой и рабочей?

Если нет, то почему?

Comments

[сергей кузьмин]

что мешает сделать пин на версии ?
для апт это

apt list --all-versions chromium-browser

chromium-browser/bionic-updates,bionic-security,now 105.0.5195.102-0ubuntu0.18.04.1

sudo apt install chromium-browser=105.0.5195.102-0ubuntu0.18.04.1

chromium-browser is already the newest version (105.0.5195.102-0ubuntu0.18.04.1).
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.

кстати зачем переcобираете image часто ? что не так со старым ?

[Chheza]

> что мешает сделать пин на версии ?
Ничего не мешает, я именно это в вопросе и спрашиваю: нужно ли так делать или такая проблема решается по-другому.

> кстати зачем переcобираете image часто ? что не так со старым ?
Не могу ответить на этот вопрос.

Я изучаю докер и представил в голове ситуацию когда я все собрал и запустил, а через полгорда-год-миллион лет мне надо пересобрать образ (не важно, просто по приколу или мне надо перенести приложенеие на другой сервер или это делаю не я, а кто-то другой на моём месте).

Для этого я делаю docker build - < Dockerfile, но получаю не тот же самый образ, который собирался, а немного другой.

Мне кажется, что это будет проблемой, поэтому я и спрашиваю.

Answer 1

[romaro]

Вы на самом деле сами ответили на свой вопрос:

Через время какой-то пакет, например, libpng-dev, обновится и сломает обратную совместимость. Мы соберем контейнер ещё раз - и он работать уже не будет

Имхо, неуправляемое обновление плохо даже в dev-версии.

Comments

[mureevms]

Добавлю. Я бы рекомендовал использовать конкретный базовый образ. Например:
FROM php:fpm-alpine3.16
А в нем если пакеты и обновятся, то скорее это будут обновления безопасности, а не изменения функционала, оно происходит в мажорных изменениях.

[Chheza]

mureevms, я правильно понимаю, что "пакеты в образе" - это не только "уже установленные и доступные в образе", но и "те, которые я могу поставить"?

Т.е., если я сделаю

FROM php:fpm-alpine3.16
RUN apt-get update && apt-get install -y some-package

То версия этого some-package тоже будет браться из образа fpm-alpine3.16, а не текущих (на данный момент) репозиториев дистрибутива?

[romaro]

Chheza, образ, это все-таки не интернет на дискетке :) Если вы выполните команду RUN ... update, то она отработает штатно и обновит индекс пакетов из удаленного репозитория. В новом образе у вас будет дополнительный слой с изменениями пакетов (если такие изменения будут). То есть каждый раз при пересборке образа вы, фактически, будете получать новый образ с обновленными версиями пакетов.

[Chheza]

romaro, то есть, опять же, если я хочу чтобы мой образ не менялся после пересборки - мне нужно вручную проставлять версии пакетов в apt-get install?

[romaro]

Chheza, да, но я бы привязывался только к мажорным версиям пакетов, т.к. минорные должны иметь обратную совместимость. Для удобства, версии пакетов можно вынести в переменные. Посмотрите, как это сделано с PG_VERSION в этом образе.