Когда пересобирать образ в докере?
Я только начинаю работать с докером и немного запутался с томами. Предположим, я создал контейнер с томом, папкой с моего компьютера и папкой из контейнера. Позже в папке моего компьютера я создаю новую базу данных sqlite (так что она также создается в контейнере, верно?). Когда контейнер умрет и вы создадите новый контейнер ИЗ ТОГО ЖЕ ОБРАЗА, база данных все равно будет там. Я пока в порядке? Но образ был обновлен с этой новой базой данных или что случилось? Если нет, то лучше ли в этих случаях пересобрать образ и собрать контейнер? (или когда я должен перестроить образ? когда я изменяю переменные среды?) Большое спасибо, я надеюсь, что вы можете мне помочь!
Но если я создам новый контейнер, останутся ли в силе изменения, сделанные в предыдущем контейнере? В этом случае, что на самом деле происходит, так это то, что он берет изменения из файлов на моем ПК? докер обходится мне...
Мы не можем «изменить» образы; они неизменны. Мы можем изменять данные в томах. И если мы запустим другой контейнер с тем же томом, что и первый контейнер, они увидят те же данные в этом томе. Если том разрешает доступ для чтения-записи-записи, контейнеры увидят изменения, сделанные друг другом. Если мы внесем изменения в работающий контейнер (например, вызовем диспетчер пакетов), эти изменения исчезнут, когда контейнер будет удален и воссоздан.
Мне начинает становиться яснее. Последний вопрос (обещаю, ха-ха). Например, когда в docker compose я пишу так: Volumes: - ./project:/usr/src/app (первая часть — это путь к моему компьютеру, а следующая часть — это путь к контейнер) Что я делаю, так это создаю том, в котором хранятся изменения как на моем компьютере, так и в контейнере? (Имя тома создается автоматически?) Таким образом, каждый раз, когда вы создаете контейнер этой службы с помощью docker compose, будет ли этот том монтироваться? Большое спасибо за такое сотрудничество!
Он не дублируется. Это один и тот же каталог, вмонтированный в контейнер. Если контейнер записывает или изменяет файл в томе, он будет немедленно виден на хосте докера и наоборот.
Все понял! Бесконечное спасибо!
Ответы 1
Возможно, более простой случай, если база данных находится в отдельном контейнере. Рассмотрим этот docker-compose.yml файл:
version: '3.8'
services:
app:
build: .
ports: ['8000:80']
environment: { PGHOST: db, ... }
db:
image: 'postgres:15.1'
environment: { ... }
volumes:
- 'dbdata:/var/lib/postgresql/data'
volumes:
dbdata:
Во-первых, обратите внимание, что на контейнере app вообще ничего не установлено. Если код изменится, вы должны перестроить образ, а если образ изменится, вы должны заново создать контейнер. (Сравните с скомпилированными языками, такими как C++, Go, Rust, Java или Elixir: если вы изменяете свой код, вы обычно должны перекомпилировать исполняемый файл, а затем запустить новый процесс.)
Надеюсь, базовый жизненный цикл контейнера db и именованного тома dbdata ясен.
Теперь предположим, что выпущена версия PostgreSQL 15.2, и вы соответствующим образом измените image:. Официальная сборка образа не может знать о ваших конкретных данных и не может быть включена в образ. Вместо этого существующий том будет смонтирован в новый контейнер с новым образом.
[Я бы порекомендовал подобную настройку, если это возможно, с данными, хранящимися в базе данных отдельно от контейнера вашего приложения. Это полезно, если вы когда-нибудь захотите запустить несколько реплик своего приложения или если вы рассматриваете возможность запуска базы данных на выделенном оборудовании или в общедоступном облаке.]
Вы должны быть в состоянии обобщить это на настройку, которую вы описываете в вопросе. Если вам больше нравится:
version: '3.8'
services:
app:
build: .
ports: ['8000:80']
volumes:
- ./data:/app/data # containing the SQLite file
Смонтированный привязкой каталог /app/data фактически имеет свое хранилище вне контейнера. Если контейнер удаляется и создается заново, данные остаются. Вам нужно перестроить образ, если код изменится, но данные вообще не сохраняются в образе (и хотя они доступны из контейнера, они не хранятся в файловой системе контейнера как таковая).
Большое спасибо за ваш ответ. Возникает вопрос: прямо в моем текущем приложении у меня есть конфигурация, о которой вы говорите: тома: - ./data:/app/data # содержащие файл SQLite Так что у меня не том, а бинд-монтированный? Согласно тому, что я понял при таком способе написания, был создан том, в котором докер хранит как изменения, возникающие в контейнере, так и на моем компьютере, когда контейнер умирал и запускался новый, тот же том автоматически монтировался .
Продолжить... Но теперь я запутался, что я на самом деле делаю, так это имею смонтированную папку с моей локальной папкой, и каждый раз, когда я запускаю новый контейнер, я получаю доступ к этой папке? Я думаю, что в обоих случаях это более или менее одинаково, но я понял, что разница между бинд-маундами и томами была в том, что последние хранились в докере (поправьте меня, если я ошибаюсь :) )
Правильно, основное различие между именованными томами и монтированием привязки заключается только в том, контролирует ли Docker хранилище или вы используете определенный каталог хоста. В обоих случаях содержимое подключенного хранилища сохраняется в контейнерах. Изменения в файловой системе контейнера теряются при удалении контейнера.
Тома монтируются во время выполнения контейнера, а не во время сборки образа. Вкратце: образ не знает объемов. Изменения в томах видны во время выполнения для контейнера, когда том смонтирован. Нет необходимости перестраивать образ, если изменяется содержимое тома или монтируется новый том.