А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?
процесс внутри контейнера форкается и плодит потомков
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает SIGTERM и мочит всех своих потомков.
Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места: kubectl logs myapp -c nginx.
Это может быть по началу непривычно, но на мой взгляд, очень удобно.
Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
Называйте как хотите — но если, допустим, вы являетесь разработчиком софта и самостоятельно настраиваете пайплайн, то есть настраиваете development operations, а соответственно от части вы являетесь DevOps-инженером)
Гипервизор — KVM
Проблем, конкретно с использованием OpenNebula, почти не возникало. Все что были — либо особенности, либо достаточно легкоразрешимые, особенно с условием того что почти вся логика в OpenNebula реализованна в виде простых bash-скриптов.
Как-то раз я делал что-то подобное но на базе OpenNebula.
Как адепту shell-скриптинга, я бы очень советовал вам взглянуть на неё.
OpenNebula очень простая и гибкая платформа, она может выступать в качестве удобного фремворка, для создания и управления VM, а поверх неё можно реализовать любую логику.
С соответствующими плагинами и подсветкой синтаксиса он нисколько не отстаёт от yaml по читаемости и удобству редактирования, но также привносит новые возможности и позволяет полностью избавится от повторяемости однотипных структур.
Не нужно, потому я и говорю что LXC и docker — это два разных инструмента
А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает
SIGTERMи мочит всех своих потомков.Кстати, это один из пунктов 12factor app.
Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места:
kubectl logs myapp -c nginx.Это может быть по началу непривычно, но на мой взгляд, очень удобно.
Я думаю предусмотрели, они просто #противсистемы
Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
На самом деле есть вполне бесплатный Katacoda — для любителей сразу потрогать ручками
да это же просто гошный бинарь, обзывайте как хотите:
и проблема решена
Докер и LXC — это всего-лишь два инструмента, которые решают две разные задачи
посмотрите на podman
Есть ещё неплохой OnlyOffice, к тому же под свободной лицензией.
Возьмите PlayOnLinux
Называйте как хотите — но если, допустим, вы являетесь разработчиком софта и самостоятельно настраиваете пайплайн, то есть настраиваете development operations, а соответственно от части вы являетесь DevOps-инженером)
Всё ведь просто, DevOps-инженер — это тот, кто выстраивает пайплайны.
Гипервизор — KVM
Проблем, конкретно с использованием OpenNebula, почти не возникало. Все что были — либо особенности, либо достаточно легкоразрешимые, особенно с условием того что почти вся логика в OpenNebula реализованна в виде простых bash-скриптов.
Хех, респект!
Как-то раз я делал что-то подобное но на базе OpenNebula.
Как адепту shell-скриптинга, я бы очень советовал вам взглянуть на неё.
OpenNebula очень простая и гибкая платформа, она может выступать в качестве удобного фремворка, для создания и управления VM, а поверх неё можно реализовать любую логику.
А ещё можно просто переключиться на jsonnet :)
С соответствующими плагинами и подсветкой синтаксиса он нисколько не отстаёт от yaml по читаемости и удобству редактирования, но также привносит новые возможности и позволяет полностью избавится от повторяемости однотипных структур.
Отличная затея! Телеграмму очень не хватает старых добрых колобков
Есть ещё не менее интересная проекция Гаусса — Крюгера:
Лучше сразу в π https://github.com/philipl/pifs