Меню
Что нового?

Вообще никак не убиваются сессии?

  • Автор темы Автор темы Dzen
  • Дата начала Дата начала
grigori написал(а):
какую еще виртуальную машину? ты о чем?
под линуксом никакой виртуалки не нужно, в контейнерах используется ядро хоста
Нажмите для раскрытия...
Эм.. Виртуализация на уровне ОС. Ок, гостевой ОС нет, но есть виртуализация на уровне ОС и есть платформы с ОС. Я как параноидальный дебианщик воздержался бы от установки его по соображениям безопасности и стабильности еще некоторое время. А вообще да, тема интересная. Правда опять же на каждую виртуальную машину нужно по IP-шнику. NAT не вариант.
 
Это не столько виртуализация, сколько разделение процессов.
 
На самом деле, если нет необходимости именно штамповать конты десятками, можно ограничиться LXC/LXD.
Та же технология, меньше автоматизации.
 
Докер любопытен не контейнерами, а "наследованием" и линковкой контейнеров между собой.
Например, локально на dev-машине можно монтировать папку с файлами базы из контейнеров с приложениями в контейнер базы, и получается, что база у каждого приложения своя собственная, а контейнер с базой при этом - один.
На production папка с диска монтируется в контейнер приложения, откуда она монтируется в контейнер базы, и рабочая база лежит уже напрямую в каталоге сервера, в контейнер не попадает.
 
Последнее редактирование:
grigori написал(а):
Докер любопытен не контейнерами, а "наследованием" и линковкой контейнеров между собой.
Например, локально на dev-машине можно монтировать папку с файлами базы из контейнеров с приложениями в контейнер базы, и получается, что база у каждого приложения своя собственная, а контейнер с базой при этом - один.
На production папка с диска монтируется в контейнер приложения, откуда она монтируется в контейнер базы, и рабочая база лежит уже напрямую в каталоге сервера, в контейнер не попадает.
Нажмите для раскрытия...
При публикации проекта лучше всего имхо, не использовать эти усложнения, поскольку усложнения ведут к удорожанию (а использовать ПО из того окружения, что было заложено при разработке). Кроме того, это еще одна прослойка ПО (а это и человеческий фактор и баги). Докер был бы полезен (если бы на сквизи запускался) мне только в одном случае, это запустить nginx от debian jessie, с поддержкой TLS 1.2 и OpenSSL 1.0.1. Если бы изначально, я бы замутил такие контейнеры. Но во-первых - ос не позвляет, второе - там есть еще одна прослойка - ISPManager, который работает в связки (через .so) со всей системой. Нужно все тестировать. На сегодня, проблему с OpenSSL и TLS 1.2 я решил путем частичной автоматизации компилирования на bash скриптах. Возможно, при спользовании докера можно было бы избежать этих проблем, но организовать это для shared хостинга проблемно. Я думаю докер все же это инструмент разработчика, что бы иметь возможность быстрого развертывания окружения для разработки, и очень бы мне помогли с nginx-ом, поскольку компилировать надоедает. Но при этом у меня LTS дистрибутив, который тьфу тьфу - выставивает на всех серверах и выдерживает все атаки. Также возникает вопрос в поддержке самих платформ докера (своевременное обновление, патчи безопасности и т.п.)

Вот допустим, выдаю я как хостер VDS, и плевать мне дальше - ресурсы ограничены, все изолировано, а как там юзер - обновляет ли . не обновляет свою ОС - мне фиолетово, а здесь же я как сис админ получаю еще один головняк. Использование таких технологий прежде всего должно быть осознано и обосновано.
 
Последнее редактирование:
@Активист, что именно OS не позволяет?
про "инструмент разработчика" - неочевидное утверждение, shared hosting с ISPManager - твой частный случай, не думаю, что много людей тут связано с хостингами.
У меня все проекты в виртуалках, а тот же Digital Ocean уже поддерживает работу с образами докера https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-docker-application

я думаю, это инструмент для автоматизации, но им надо научиться пользоваться, как любым инструментом.
вопрос конфигурирования освещен в документации много раз - монтируйте свои папки конфигов в /etc контейнера или наследуйте с копированием своих конфигов.
надо обновить - собери образ локально с нужными версиями, протестируй, выложи и подмени в production, без downtime и конфликтов.

Не использовать усложнения - не работает. Не будем использовать фреймворки, composer и github. Не будем компилировать CSS в GULP. Это необязательные прослойки. Однако, мир идет по пути усложнений и все новых прослоек.
 
Последнее редактирование:
После очередной епли с версия пхп / набор модулей / версии библиотек / локаль и прочее, склоняюсь посылать всех заказчиков с шаредом лесом и давать им на выходе докер - пусть покупают виртуалку и радуются. Осталось только ввернуть его в процесс разработки. А шаред должен помереть уже наконец....
 
статью, блин, надо писать, я уже раз 5й одно и то же рассказываю в разных местах
 
Вот, да. Именно что весь смысл докера в docker compose. Когда в один докер пакуют убунту с апачом, пхп и мысклем, включая все конфиги и файлы базы - у меня пригорает, это же бред.
 
@fixxxer, это проблема документации докера, в официальных образах примеры использования
https://hub.docker.com/_/php/
Create a Dockerfile in your PHP project
FROM php:5.6-apache
COPY src/ /var/www/html/
Where src/ is the directory containing all your php code.
Нажмите для раскрытия...

Вот и додумайся сам как на самом деле надо делать.
 
Ну если взял докер не потому что это модное слово, а с четкой целью как средство контейнеризации приложений, не найти раздел про docker compose сложно - как бы решение задачи поставленной изначально.
Документация страдает, да.

Хотя к докеру у меня тоже масса претензий - все слишком завязано на implementation details :) Coreos-овский rocket и их спека App Containers - намного более взрослый подход (от универсальной спецификации к реализациям, которых может быть сколько угодно), но пока еще в весьма зачаточном состоянии там все.
 
Compose - то ладно, а вот Data volume containers я нашел день так на 4й последовательного чтения документации.

То есть как реально надо бы делать:
смотрим предка нашего образа с php - debian:jessy, от него создаем образ с файлами приложения. Из образа приложения создаем volume container, монтируя/заменяя в нем конфиги для production, и уже этот контейнер монтируем в контейнер с php.
Папку для логов можно подмонтировать из host OS.
Когда надо обновить приложение, можно подменить образ приложения, пересоздать контейнер с приложением и перезапустить контейнер с php.
Старый контейнер с приложением можно удалять не сразу чтобы откатываться если надо.

Надо обновить php - меняем образ php, в него монтируем приложение, перезапускаем с удалением старого контейнера.
 
Последнее редактирование:
grigori написал(а):
@Активист,
У меня все проекты в виртуалках, а тот же Digital Ocean уже поддерживает работу с образами докера https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-docker-application
Нажмите для раскрытия...
У амазона тоже уже есть ec containers под докер и встроенный в привычную инфраструктуру амазона.
 
grigori написал(а):
@Активист, что именно OS не позволяет?
Нажмите для раскрытия...
На дебиан сквизи не посадить ;) Ядро старовато. А у меня все оборудование на нем крутится. Зеоны с кучей ОЗУ и Raid-1 массивами объеденными по LVM 2. Трогать не хочу. LTS еще не закрыли. Потом на Wheezy придется обновлять.
 
Войдите или зарегистрируйтесь для ответа.
Сверху