Права на volume между хостом и Docker-контейнером: разные UID (www-data / deploy). Как лучше организовать?

Question

[Sukesada]

Есть сервер Ubuntu 24.04, PHP на хосте нет — PHP-FMP работает только в Контейнере (Alpine). Это pet проект жены.
В репозитории Git:

.
├── dump
├── logs
│   ├── backup
│   └── make
├── prod
│   ├── duogu            # код приложения
│   ├── duogu.yml        # docker-compose для PHP/MySQL
│   ├── Dockerfile
│   ├── duogu.conf
│   ├── entrypoint.sh
│   ├── mysqld.cnf
│   └── php.ini
├── proxy
│   ├── nginx.yml        # docker-compose для nginx
│   ├── certbot.yml      # docker-compose для certbot
│   ├── certbot
│   │   ├── conf
│   │   └── www
│   ├── conf.d
│   └── nginx.conf
├── scripts
├── env.examle
└── README.md

Схема такая:
На хосте:
пользователь deploy — uid 1000 (деплоит проект, обновляет код)
www-data — uid 33
В контейнере:
www-data — uid 82 (alpine)
Весь код проекта лежит в Docker volume, примонтированном с хоста
Разделять код и storage (uploads/cache/logs) не хочется — всё лежит в одном volume
Нужно корректно организовать права, чтобы:
– deploy мог без проблем обновлять код из Git на хосте
– контейнерный www-data мог читать и писать файлы
– не использовать 777
решение должно быть адекватным.
Вопрос:
Что считается наиболее правильным и практичным для production?
На что стоит ориентироваться: безопасность, поддерживаемость, best practices Docker/Linux?

Comments

[pfg21]

впихнуть обновлятор внутрь контейнера с пыхом ??

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

преепешите Dockerfileы создаваййте всех user сами с нужным uid

[Sukesada]

сергей кузьмин, Спасибо без воды, без рефакторинга и тд:)). Сделал через make.

COMPOSE = docker compose
COMPOSE_FILE = prod/duogu.yml

UID := $(shell id -u)
GID := $(shell id -g)

.PHONY: dev prod up build

## dev / WSL
dev:
	@echo "DEV UID=$(UID) GID=$(GID)"
	WWW_UID=$(UID) WWW_GID=$(GID) \
	$(COMPOSE) -f $(COMPOSE_FILE) build
	$(COMPOSE) -f $(COMPOSE_FILE) up -d

## production (после Ansible)
prod:
	@echo "PROD UID=deploy"
	WWW_UID=$(shell id -u deploy) \
	WWW_GID=$(shell id -g deploy) \
	$(COMPOSE) -f $(COMPOSE_FILE) build
	$(COMPOSE) -f $(COMPOSE_FILE) up -d

Answer 1

[chupasaurus]

Собирать образ с нужными правами, не запускать код напрямую с диска.

Comments

[Sukesada]

Я, возможно, не до конца понял идею.
Вы предлагаете «собирать образ с нужными правами», но можете уточнить, какие именно права считаются нужными в этой схеме?
Сейчас есть конкретные UID/GID:
хост: deploy = 1000, www-data = 33
контейнер (alpine): www-data = 82
Какую комбинацию вы предлагаете считать корректной:
1000:1000
1000:33
1000:82
33:33
82:82
При этом в Linux у файла может быть только один владелец (UID) и одна группа (GID), так что выбрать всё сразу невозможно.
Если же идея в том, чтобы не запускать код с диска, а класть его в image, то это уже выглядит как смена архитектуры деплоя, а не решение вопроса прав.
В таком случае хотелось бы понять, как предполагается работать в реальном режиме разработки/поддержки, когда:
в день бывает 20–50 мелких правок,
нужен быстрый git pull и моментальный результат,
пересборка и перезапуск образа на каждую правку выглядит избыточно.
И даже при immutable image writable-часть (uploads/cache/logs) всё равно остаётся в volume, а значит проблема UID/GID там никуда не исчезает.
Поэтому интересно понять:
какую именно проблему решает сборка image в контексте прав, и какой конкретный UID/GID в итоге считается правильным?

[chupasaurus]

Ваш вопрос всё ещё:

Что считается наиболее правильным и практичным для production?

, на него я и ответил. То, что вы считаете git pull частью деплоя - это ваши проблемы.

И даже при immutable image writable-часть (uploads/cache/logs) всё равно остаётся в volume, а значит проблема UID/GID там никуда не исчезает.

При immutable image права закладываются в оный, и, исходя из названий директорий, частью процесса деплоя не являются.

нужен быстрый git pull и моментальный результат

в виде отвала из-за конфликта коммитов или выпадения в bare state, production-ready решение.

Answer 2

[say_TT_plz]

-v /etc/passwd:/etc/passwd:ro -v /etc/shadow:/etc/shadow:ro -v /etc/group:/etc/group:ro
да и все

Comments

[Sukesada]

Да я так сделал. В make что бы жене удобно было одной командой.

COMPOSE = docker compose
COMPOSE_FILE = prod/duogu.yml

UID := $(shell id -u)
GID := $(shell id -g)

.PHONY: dev prod up build

## dev / WSL
dev:
	@echo "DEV UID=$(UID) GID=$(GID)"
	WWW_UID=$(UID) WWW_GID=$(GID) \
	$(COMPOSE) -f $(COMPOSE_FILE) build
	$(COMPOSE) -f $(COMPOSE_FILE) up -d

## production (после Ansible)
prod:
	@echo "PROD UID=deploy"
	WWW_UID=$(shell id -u deploy) \
	WWW_GID=$(shell id -g deploy) \
	$(COMPOSE) -f $(COMPOSE_FILE) build
	$(COMPOSE) -f $(COMPOSE_FILE) up -d