Пишу редко, но хотел посоветоваться с профи. На хоботе какие-то лютые NASы собирают, за proxmox топят, решил сначала с местной публикой посоветоваться.
Есть NAS:
Gigabyte E3000N (AMD E2-3000);
4 Gb DDR3;
Host SSD: 120 Gb;
Tank HDD: 500 Gb.
Задачи тривиальные: transmission, Home Assistant (аналоги), web-сервер, хранилище.
Решил попробовать и освоить Docker, поскольку считаю это удобным и достаточно безопасным. Не могу понять как правильно сделать проброс ФС хоста в контейнер.
Используя ключ -v при запуске контейнера всё ОК - проброс ФС хоста в контейнер есть. При использовании Dockerfile с параметром volume - результат иной. Это описано в документации. Несколько дней не мог понять, как лучше получить проброс хост ФС в контейнер. Не получалось через volume, прикинул, что
вероятно это не Docker-way.
И действительно, на форуме Docker попалось, что использование абсолютных путей (до хоста) в образе противоречит концепции Docker. Поскольку контейнеры должны легко перетаскиваться между хостами. Запускать контейнер c кучей ключей мне не кажется эстетичным,
хотя, кажется, в образах на DockerHub так и делают.
Решил попробовать docker-composer. С ним пока разбираюсь, но опять же он, как я понимаю, используется для контейнеров, которые взаимодействуют между собой.
Согласен. Неплохой, но в быту не очень востребованный функционал.
Цитата: От пользователя: reptile
Лучше использовать прямые точки монтирования томов в
хост через docker-compose:
Да, я нашёл этот вариант. Но docker-compose всё же предназначен для запуска контейнеров, которым требуется взаимодействие между собой. В моём случае взаимная связь контейнерам это не требуется, соответственно использование docker-compose выглядит не
совсем верным архитектурным решением. Или я не прав? Хочется сделать всё как надо согласно концепции Docker.
Цитата: От пользователя: reptile
Есть ещё контейнеры с данными (так называемые volumes) но это для отдельных извращений
Data
volumes, в моём сценарии они вроде как не нужны.
Вот и остаётся вопрос хранения persistent data. Проброс хост ФС в контейнер через ключ -v выглядит плохо имхо. Docker-compose для группы "взаимодействующих" контейнеров. Data volumes не из этой оперы. Как тогда сделать
правильно и красиво-то? :-)
В моём случае взаимная связь контейнерам это не требуется, соответственно использование docker-compose выглядит не совсем верным архитектурным решением. Или я не прав? Хочется сделать всё как надо согласно концепции Docker.
Это нормально. Используется для упрощения запуска чтобы не писать километры команд в cli. Аналогом для одного контейнера может являться
shell-скрипт, но тогда придется описывать создание и настройку сетей, если они потребуются.
Цитата: От пользователя: Awesome Man
Data volumes не из этой оперы. Как тогда сделать правильно и красиво-то?
Забей. Для отдельно взятого standalone докера это норм. Если ну очень сильно красиво хочется то:
1) Не работать с персистентными данными в
контейнерах
2) FC/iSCSI/CEPH/CEPHFS на внешнее хранилище ;-)
P.S. Ну понятно, что второй вариант очень не прост и дорог :-)
Это нормально. Используется для упрощения запуска чтобы не писать километры команд в cli. Аналогом для одного контейнера может являться
shell-скрипт, но тогда придется описывать создание и настройку сетей, если они потребуются.
В итоге остановился на docker-compose, как меньшем зле в сравнении с shell-скриптом.
Dockerfile:
Исходник:
# Используем за основу последнюю ubuntu
FROM ubuntu:18.04
# Указываем данные сборщика
LABEL maintainer="maintainer"
#ENV UBUNTU_VERSION 1.04
#ENV TRANSMISSION_VERSION 2.94
# Обновление списка пакетов, установка демона transmission, чистка кэшей и логов
RUN \
apt update && apt install transmission-daemon -y && \
rm -rf /var/lib/apt/lists/*
# Добавляем пользователя user с uid/gid как из хост-системы.
RUN \
useradd user -u 1000
# Смена пользователя с root на user. Чтобы transmission-daemon запустился от
# пользователя user.
USER user
# Точка входа. Запуск демона transmission в недемонизированном виде -
# foreground. Закомментирована, потому что используется параметр command в
# docker-compose.yml
#ENTRYPOINT ["transmission-daemon", "--foreground"]
docker-compose.yml
Исходник:
# Указываем версию docker-compose. Зависит от используемой версии Docker.
version: "3"
# Список поднимаемых сервисов. Один сервис - один процесс (контейнер).
services:
# Описываем настройки контейнера transmission
transmission:
# Указываем образ для создания контейнера
image: transmission
# Присваиваем имя контейнеру
container_name: transmission
# Команда, которую надо запустить внтури созданного контейнера.
# Это и есть процесс, ради которго создаётся контейнер.
command: transmission-daemon --foreground -g /etc/transmission-daemon
# Пробросим порты из конейнера в хост-систему. host:container.
# Для remote gui transmission используется порт 9091. Его и пробросили.
ports:
- "9091:9091"
- "51413:51413.
- "51413:51413/udp"
volumes:
- /mnt/tank/download:/home/user/download
- /mnt/tank/download/incomplete:/home/user/download/incomplete
- /mnt/tank/download/watchdir:/home/user/download/watchdir
- /home/user/docker/transmission/etc:/etc/transmission-daemon
#homeassistant:
В общем и целом всё работает. Спасибо за советы! Приступлю к следующему контейнеру =) Ну
и на HDD можно уже откладывать :-D
При необходимости можно добавить любой сервис, нет лишних прослоек, привязок к плагинам. Чистая хост-система и докер. Весь хлам в контейнерах. Пока очень нравится. Лишнего GUЯ нет.
Внимание! сейчас Вы не авторизованы и не можете подавать сообщения как зарегистрированный пользователь.
Чтобы авторизоваться, нажмите на эту ссылку (после авторизации вы вернетесь на
эту же страницу)
