История изменений

Потому, что надо читать документацию, а не «гайды» сомнительного качества. Естественно в контейнерах данные сохраняются. Чтобы данные потерять, нужно удалить это контейнер и создать новый, в котором, конечно же, данных из старого контейнера не будет.

Если ты разбираешься в виртуальных машинах, контейнер это полная аналогия виртуальной машины. Образ это снапшот виртуальной машины.

Единственное, что в докере может «помочь» с потерей данных, это его философия. К примеру если ты создаёшь конейнер с флагом --rm, то он действительно удалится сразу после остановки. Если ты пишешь docker compose down, то он удаляет все контейнеры.

Про то, что контейнеры легко удаляются, это скорей некая «философия» современного применения этих самых контейнеров. Когда все изменения должны быть в Dockerfile. Также в Kubernetes контейнеры задуманы эфемерными, твой под может быть удалён с ноды, и пересоздан на другой ноде в любой момент, поэтому хранить что-то в контейнере, а не во внешнем томе - ну разве что какие-то закешированные данные, которые не жалко потерять. Хотя даже там с этим можно бороться, про «удален в любой момент» я немного лукавлю.

Но если говорить именно про докер - конечно же данные сохраняются в контейнерах и конечно же это можно использовать, хотя лучше всё же все значимые изменения документировать в Dockerfile-ах, а не делать вручную.

А почему так пишут? Не знаю. Видимо гайдописатели тупые. Такое бывает. Это как я в третьем классе понял, что моя учительница по математике тупая и я знаю математику лучше её. Видимо ты похожее осознал немного позже в своей жизни.

Потому, что надо читать документацию, а не «гайды» сомнительного качества. Естественно в контейнерах данные сохраняются. Чтобы данные потерять, нужно удалить это контейнер и создать новый, в котором, конечно же, данных из старого контейнера не будет.

Если ты разбираешься в виртуальных машинах, контейнер это полная аналогия виртуальной машины. Образ это снапшот виртуальной машины.

Единственное, что в докере может «помочь» с потерей данных, это его философия. К примеру если ты создаёшь конейнер с флагом --rm, то он действительно удалится сразу после остановки. Если ты пишешь docker compose down, то он удаляет все контейнеры.

Про то, что контейнеры легко удаляются, это скорей некая «философия» современного применения этих самых контейнеров. Когда все изменения должны быть в Dockerfile. Также в Kubernetes контейнеры задуманы эфемерными, твой под может быть удалён с ноды, и пересоздан на другой ноде в любой момент, поэтому хранить что-то в контейнере, а не во внешнем томе - ну разве что какие-то закешированные данные, которые не жалко потерять. Хотя даже там с этим можно бороться, про «удален в любой момент» я немного лукавлю.

Но если говорить именно про докер - конечно же данные сохраняются в контейнерах и конечно же это можно использовать, хотя лучше всё же все значимые изменения документировать в Dockerfile-ах, а не делать вручную.

А почему так пишут? Не знаю. Видимо гайдописатели тупые. Такое бывает.

Потому, что надо читать документацию, а не «гайды» сомнительного качества. Естественно в контейнерах данные сохраняются. Чтобы данные потерять, нужно удалить это контейнер и создать новый, в котором, конечно же, данных из старого контейнера не будет.

Если ты разбираешься в виртуальных машинах, контейнер это полная аналогия виртуальной машины. Образ это снапшот виртуальной машины.

Единственное, что в докере может «помочь» с потерей данных, это его философия. К примеру если ты создаёшь конейнер с флагом --rm, то он действительно удалится сразу после остановки. Если ты пишешь docker compose down, то он удаляет все контейнеры.

Про то, что контейнеры легко удаляются, это скорей некая «философия» современного применения этих самых контейнеров. Когда все изменения должны быть в Dockerfile. Также в Kubernetes контейнеры задуманы эфемерными, твой под может быть удалён с ноды, и пересоздан на другой ноде в любой момент, поэтому хранить что-то в контейнере, а не во внешнем томе - ну разве что какие-то закешированные данные, которые не жалко потерять. Хотя даже там с этим можно бороться, про «удален в любой момент» я немного лукавлю.

Но если говорить именно про докер - конечно же данные сохраняются в контейнерах и конечно же это можно использовать, хотя лучше всё же все значимые изменения документировать в Dockerfile-ах, а не делать вручную.

Потому, что надо читать документацию, а не «гайды» сомнительного качества. Естественно в контейнерах данные сохраняются. Чтобы данные потерять, нужно удалить это контейнер и создать новый, в котором, конечно же, данных из старого контейнера не будет.

Если ты разбираешься в виртуальных машинах, контейнер это полная аналогия виртуальной машины. Образ это снапшот виртуальной машины.

Единственное, что в докере может «помочь» с потерей данных, это его философия. К примеру если ты создаёшь конейнер с флагом --rm, то он действительно удалится сразу после остановки. Если ты пишешь docker compose down, то он удаляет все контейнеры.

Про то, что контейнеры легко удаляются, это скорей некая «философия» современного применения этих самых контейнеров. Когда все изменения должны быть в Dockerfile. Также в Kubernetes контейнеры задуманы эфемерными, твой под может быть удалён с ноды, и пересоздан на другой ноде в любой момент, поэтому хранить что-то в контейнере, а не во внешнем томе - ну разве что какие-то закешированные данные, которые не жалко потерять.

Но если говорить именно про докер - конечно же данные сохраняются в контейнерах и конечно же это можно использовать, хотя лучше всё же все значимые изменения документировать в Dockerfile-ах, а не делать вручную.