Согласен. Текущее состояние большинства приложений не позволяет назвать их «cloud native» именно из-за таких вот жёстких зависимостей.
Ну ничего. Засохнет и отомрёт. Не до конца, конечно. Ведь и сейчас mainframe'ы есть. Но mainstream течь другом русле.
Спасибо за ответы.
Мне кажется, что мы из разных миров. А чувствую, что ваши слова подкреплены вашей реальность, примерами из вашей жизни. Но для меня они звучат странно.
Для меня процесс — это запущенный в кластере контейнер. И обычно, одно приложение — это не один контейнер, а множество.
В моем мире ситуация запуска в контейнере одного процесса другим возможна. Например, когда python скрипт запускает JVM, но это исключение. Обычно, запускается одиночный процесс.
Для меня, сron — внешняя система, которая просит надзирателя над кластером запустить контейнеры.
Процесс помогающий работать с логами основного контейнера — это ещё один контейнер, запущенный в паре с основным. По типу sidecar описанному тут http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
После прочтения фразы, что у вас нет Docker на production, почувствовал себе виноватым, за все заданный мной вам вопросы…
Хотелось бы только добавить, что не стоит процессу внутри контейнера менять своё состояние. Контейнер умер и был поднят на другой машине… вот вам и привет всем настройкам и плагинам, которые вы ему наставили.
Подписчики/обработчики сообщений нормальное явление по многих мирах. Но в мирах известных мне, обычно они живут внутри некого системного процесса. И будучи сущностями неизменными просто переиспользуются. Старт нового системного процесса, обычно, значительно затратен, чем создание нового экземпляра такого обработчика.
Не берите в голову. Это я так, чисто для расширения своих горизонтов спросил.
А если у вас больше одного контейнера с таким «воркерами» и один из них «встал колом», но остальные работают. Как глядя на движущуюся очередь вы понимаете, что один контейнер «отлынивает»? В вашем случае «отряд не заметит потери бойца».
Не буду больше ковырять. Как я вижу, для вас это все в самом начале и у вас у самого больше вопросов, чем ответов. Спасибо.
1. Мне казалось, что концепция «один контейнер — один процесс» уже устоялась и принята как генеральное направление. Зачем мне контролировать сервис внутри контейнера? Пусть сгинет вместе с контейнером и тот кто отвечает за контейнеры, поднимет новую копию. Этот надзиратель все равное есть, дак зачем мне усложнять runtime нутро контейнера?
2. Правильно ли я понял, что «PID 1 zombie reaping» результат особенностей Docker ранних версий и на данный момент она не актуальна?
Правильно ли я понял, что это некая особенность php мира, так реализовывать идею publish/subscribe? Ничего против не имею, просто не знаком с таким подходом. Как я понимаю, это некое подобие амазоновских λ — https://aws.amazon.com/lambda/
А как вы или другая система снаружи узнает, что у такого контейнера все нормально? Как вы его мониторите?
1. Зачем генерировать сертификат? Можно ли его передать контейнеру снаружи?
2. А где находятся файлы данных базы? В контейнере?
3. Зачем создавать базу при старте контейнера? Почему нельзя подключиться к уже существующей и управляемой отдельно?
Товарищи, а позвольте уточнить, как вы используете упомянутые supervisor'ы?
1. «Я подключаюсь к контейнеру по ssh или через Docker CLI и запускаю клиент супервизора для выяснения ситуации с сервером.»
2. «Супервизор сам открывает порт и выставляет свою web-морду, на которой я вижу что происходит с сервером.»
3. «Супервизор экспортирует показатели сторонней системе (через файл или сетевое соединение), а я использую эту систему для автоматического мониторинга.»
Не уверен, что понял ваши опасения на счёт вордпресс и .htaccess.
На сколько я понимаю, последующий слой может делать с предыдущим что угодно: изменять файлы и даже удалять их.
1. Правильно ли я понял, что вы таки используете Docker образы в своём проекте?
2. Являются ли созданные вами образы независимыми от окружения, в котором они будут запускаться? Может ли один и тот же образ быть запущен локально (или в тестовом окружении) и на production?
3. Включаете ли вы секреты в образ или же они запрашиваются в момент старта контейнера?
4. Я не знаком с Ruby. Правильно ли я понял, что eye оборачивает ruby-процесс и для вас выглядит как некий launcher — вы запускаете его, а он запускает ваш ruby код?
Эти вопросы я задаю, так как у меня сложилось впечатление, что вашем случае есть некое смешение того, является частью образа (image build time) и что должно быть частью развернутого контейнера (deployment time).
Следуя аналогии дедушки Мартина (Fowler), такой сложный образ начинает отдавать душком (smells). Возможно вам стоит разбить один образ на несколько и запускать их как совокупность?
Вот тут про то, как образы могут быть декомпозированы в kubernetes — http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html Но мне кажется, всё то же самое может сделать Docker Compose.
Прочитал фразу.
Если сценарий сборки нетривиален и содержит множество инструкций, нужно как-то выкручиваться. Помимо того, что Dockerfile не может содержать более 120 слоев ( насколько я правильно понял из документации по Docker ), иметь дело с развесистым Dockerfile не очень приятно.
Подумал. Прочитал ещё раз… Малость испугался.
А вы точно уверены, что вам необходимы такие развесистые «скрипты развертывания»? Может что-то не так с самой идеей такой сложной настройки образа?
P.S. А можно ли какой-то пример из вашей практики, чтоб ощутить необходимость такого сложного контейнерного образа?
Ну ничего. Засохнет и отомрёт. Не до конца, конечно. Ведь и сейчас mainframe'ы есть. Но mainstream течь другом русле.
Мне кажется, что мы из разных миров. А чувствую, что ваши слова подкреплены вашей реальность, примерами из вашей жизни. Но для меня они звучат странно.
Для меня процесс — это запущенный в кластере контейнер. И обычно, одно приложение — это не один контейнер, а множество.
В моем мире ситуация запуска в контейнере одного процесса другим возможна. Например, когда python скрипт запускает JVM, но это исключение. Обычно, запускается одиночный процесс.
Для меня, сron — внешняя система, которая просит надзирателя над кластером запустить контейнеры.
Процесс помогающий работать с логами основного контейнера — это ещё один контейнер, запущенный в паре с основным. По типу sidecar описанному тут http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
Если гора не идет к Магомету, то гора идет лесом.
Хотелось бы только добавить, что не стоит процессу внутри контейнера менять своё состояние. Контейнер умер и был поднят на другой машине… вот вам и привет всем настройкам и плагинам, которые вы ему наставили.
Не берите в голову. Это я так, чисто для расширения своих горизонтов спросил.
А если у вас больше одного контейнера с таким «воркерами» и один из них «встал колом», но остальные работают. Как глядя на движущуюся очередь вы понимаете, что один контейнер «отлынивает»? В вашем случае «отряд не заметит потери бойца».
Не буду больше ковырять. Как я вижу, для вас это все в самом начале и у вас у самого больше вопросов, чем ответов. Спасибо.
2. Правильно ли я понял, что «PID 1 zombie reaping» результат особенностей Docker ранних версий и на данный момент она не актуальна?
А как вы или другая система снаружи узнает, что у такого контейнера все нормально? Как вы его мониторите?
1. Зачем генерировать сертификат? Можно ли его передать контейнеру снаружи?
2. А где находятся файлы данных базы? В контейнере?
3. Зачем создавать базу при старте контейнера? Почему нельзя подключиться к уже существующей и управляемой отдельно?
1. «Я подключаюсь к контейнеру по ssh или через Docker CLI и запускаю клиент супервизора для выяснения ситуации с сервером.»
2. «Супервизор сам открывает порт и выставляет свою web-морду, на которой я вижу что происходит с сервером.»
3. «Супервизор экспортирует показатели сторонней системе (через файл или сетевое соединение), а я использую эту систему для автоматического мониторинга.»
Опишите свой случай, пожалуйста, если я промазал.
На сколько я понимаю, последующий слой может делать с предыдущим что угодно: изменять файлы и даже удалять их.
1. Правильно ли я понял, что вы таки используете Docker образы в своём проекте?
2. Являются ли созданные вами образы независимыми от окружения, в котором они будут запускаться? Может ли один и тот же образ быть запущен локально (или в тестовом окружении) и на production?
3. Включаете ли вы секреты в образ или же они запрашиваются в момент старта контейнера?
4. Я не знаком с Ruby. Правильно ли я понял, что eye оборачивает ruby-процесс и для вас выглядит как некий launcher — вы запускаете его, а он запускает ваш ruby код?
Эти вопросы я задаю, так как у меня сложилось впечатление, что вашем случае есть некое смешение того, является частью образа (image build time) и что должно быть частью развернутого контейнера (deployment time).
Следуя аналогии дедушки Мартина (Fowler), такой сложный образ начинает отдавать душком (smells). Возможно вам стоит разбить один образ на несколько и запускать их как совокупность?
Вот тут про то, как образы могут быть декомпозированы в kubernetes — http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html Но мне кажется, всё то же самое может сделать Docker Compose.
Если сценарий сборки нетривиален и содержит множество инструкций, нужно как-то выкручиваться. Помимо того, что Dockerfile не может содержать более 120 слоев ( насколько я правильно понял из документации по Docker ), иметь дело с развесистым Dockerfile не очень приятно.
Подумал. Прочитал ещё раз… Малость испугался.
А вы точно уверены, что вам необходимы такие развесистые «скрипты развертывания»? Может что-то не так с самой идеей такой сложной настройки образа?
P.S. А можно ли какой-то пример из вашей практики, чтоб ощутить необходимость такого сложного контейнерного образа?