Порядок ваших действий при создании сервисов на Docker?
Добрый день. Хочется получить информацию о Вашем опыте в работе с Docker сервисами.
Пример:
Делаю Docker-compose файл, в нем описываю примитивный web-сервер (Nginx, PHP-FPM, MySQL)
Соответственно все image тяну из Dockerhub.
1) Но у меня есть желание, достать ВСЕ конфиги всех сервисов на локальную машину с помощью volume.
Как я должен получить те конфиги, которые уже находятся в image авторов? Ведь если я буду описывать volume в файле, то в контейнер сразу прокинется моя локальная директория уже с моими конф файлами.
2) Я привык строить системы на LXC, но докер имеет больше преимуществ в моей ситуации. Скажите, Docker-compose в продуктиве - это норма? Как я должен установить, например, еще один модуль для PHP?
3) Знаю про Kubernates и подобное, но для проекта, который по своей сути статичен - он избыточен.
Вижу забавную тенденцию.
Пока frontend разработчики борются за каждую долю секунды загрузки сайта (минифакация, сокращенный синтаксис, системы сборки), backend разработчики переходят на тяжеловесные фреймворки и используют Docker даже на проде, т.е. вообще не считаются со скоростью работы их детищ.
posters, ну могу и с аргументами:
1) Где такие, которые борются за каждую долю секунды?
2) Хоть примерно понимаете сложность и объем разработки без фреймворка?
3) Предлагаете использовать инсталляцию на голый сервер? А если, предположим, что-то с файловой системой произошло и он не грузится больше? Заново на соседнем будете все окружение разворачивать?
Zmtrk62, 1) если бы не боролись, файлы бы не минифицировали и системы сборки не использовали.
2) Речь была не о том, чтобы использовать или не использовать фреймворк, а про то, что их используют не следя за тем, как это сказывается на скорости работы программы.
3) Случай явно ЧП. Есть баш скрипты.
posters, Начитались про оверхеды докера и дава токсить на эту тему, я вам скажу как опытный админ кторый писал инструкции в баш скриптах до того как докер стал мейнстримом и компилировал весь софт из исходников, что оверхед компонентов докера это цена за автоматизацию процессов управления окружением, а еще докер много оверхедит у тех кто не умеет правильно его настраивать и использовать а в осталном все ок.
Денис Юрьев, как вариант.
Тут просто товарищ теплое с мягким путает. Почему то считает, что должен бороться за милисекунды работы приложения, в то время, как я борюсь за автоматизацию и удобство.
posters, есть два типа людей: первые начитались про оверхеды докера, но не могут внятно сказать, сколько они составляют, в каких условиях возникают и насколько они критичны для работы конкретного решения; вторые же знают, где, что и как в докере устроено и как его правильно готовить, чтобы возможные негативные эффекты не мешали.
У любой технологии есть свои достоинства и недостатки, но дешёвый хейт разве это оправдывает?
и используют Docker даже на проде, т.е. вообще не считаются со скоростью работы их детищ
и в чем связь? Контейнеры - не виртуализация, у них нет просадки (а с появлением поддержки виртуализации в оборудовании стало сильно лучше и тут). Они потому и стали так популярны, собственно. Собственно, если вы утверждаете, что контейнеры тормознее запуска на железе - приведите примеры, и либо я узнаю от вас что-то новое, либо вы - от меня ;)
Я обычно стягиваю конфиги софта для новых проектов из оф образов.
1) Можно как просто запулить сбилдить и запустить софт, так и через Dockerfile или даже docker-compose up -d --build, это уже личное дело как религия позволяет)
Вытягиваю обычно так:
PHP:
docker cp имя контейнера или сервиса:/usr/local/etc/php-fpm.conf /var/www/projects/mynewproject/docker/php/php-fpm.conf
docker cp имя контейнера или сервиса:/usr/local/etc/php-fpm.d/www.conf /var/www/projects/mynewproject/docker/php/www.conf
docker cp имя контейнера или сервиса:/usr/local/etc/php/php.ini-development /var/www/projects/mynewproject/docker/php/php.ini
Левые пути это размещение в контейнере конфигов, правые пути это куда копировать на хост системе.
После получения исходных конфигов прописываю их в Dockerfile сервиса PHP:
COPY /var/www/projects/mynewproject/docker/php/php.ini /usr/local/etc/php/php.ini
COPY /var/www/projects/mynewproject/docker/php/php-fpm.conf /usr/local/etc/php-fpm.conf
COPY /var/www/projects/mynewproject/docker/php/www.conf /usr/local/etc/php-fpm.d/www.conf
Правда я делаю это не через волюм конечно, но это опять же вопрос религии)
Собственно аналогично можно вытянуть конфиги и для Nginx:
docker cp имя контейнера или сервиса:/etc/nginx/nginx.conf /var/www/projects/mynewproject/docker/nginx/nginx.conf
docker cp имя контейнера или сервиса:/etc/nginx/conf.d/default.conf /var/www/projects/mynewproject/docker/nginx/default.conf
Для нового Nginx даже вроде есть файл конфига шаблона: /etc/nginx/templates/default.conf.template, который можно взять за основу для виртуалхостов nginx.
Ну а для БД и прочего софта думаю не составит труда поковырять оф образы или погуглить)
2) Если правильно понял на счет модулей ext-php:
Тут несколько вариантов модули которые входят в базовую сборку php можно установить так:
RUN docker-php-ext-install -j$(nproc) soap
Те которые нужно установить и принудительно включить:
RUN docker-php-ext-install -j$(nproc) opcache && docker-php-ext-enable opcache
Еще есть которые нужно конфигурировать вроде zip:
RUN apt-get update && apt-get install -y --no-install-recommends libzip-dev zip
RUN docker-php-ext-configure zip && docker-php-ext-install -j$(nproc) zip
А еще можно ставить из PECL расширения на примере pthreads:
RUN pecl install pthreads && docker-php-ext-enable pthreads
В общем докенезировать можно php проект главное знать основы докера и специфику софта который нужно в этом самом докере поднять.
не знаю зачем вам это нужно, но вижу только такой способ - запустить контейнер и используя docker cp скопировать себе на хост необходимые конфиги.
Композ без использования build вполне можно и на продуктив. Любые модули, как и ваш код, обновляются стандартным методом для Докера - сборкой нового контейнера с обновлёнными модулями, доставка контейнера целиком на прод
1) Что именно? Конфиги из контейнера или конфиги на хост?
2) Ну вот здесь получается сложнее. Во первых надо раздобыть Dockerfile автора. Во вторых, в LXC я просто ставлю пакет менеджером пакетов и всё. Займет это минуту.
Zmtrk62,
1). Работает в обе стороны. Я так понял вам нужно достать что-то из контейнера - только так. Volume работает только прокидыванием внутрь контейнера
2). Вы не разобрались пока - Dockerfile автора не нужен. Нужен ваш Dockerfile первыми строками которого написано FROM имя_и_тэг_образа_автора, а затем добавляете ваши правки, - модкли, пакеты, исходный код.
И при чем тут LXC? Подходы у этих контейнеров разные. LXC скорее философия виртуальной машины, перенесенная в контейнер. Не стоит оглядываться на LXC и его подходы, в противном случае вам нет выгоды от перехода в Docker.
Да, принимается, спасибо.
Скажите, где бы Вы брали конфиги для моего примера для всех сервисов? Или что сделали, если бы хотели изменить тот же nginx.conf?
Zmtrk62, зависит от случая. Если меня устраивает конфигурация, которая уже есть в контейнере и автор позаботился вынести необходимы для изменения параметры в переменные окружения - сконфигурирую через них. В данном случае я бы наверно взял mysql "как есть".
В случаях тонкой настройки, которая может потребоваться для nginx / php-fpm - взял бы набор стандартных конфигов из документации (или вытянув в качестве шаблона из контейнера), описал бы и прокинул целиком каталог конфигурации через volume в контейнер (с пометкой в volume "ro").
Zmtrk62, конкретно с nginx - наверняка есть контейнер, где в nginx.conf есть инклуд папки. Монтируем туда свой volume со своими конфигами и вуаля. А вообще контейнеры обычно конфигуряются переменными окружения
