Обновить

Комментарии 13

Расскажите пожалуйста, каким образом управляете контейнерами? Приходилось ли поднимать виртуальные сети между серверами?
Что вы конкретно понимаете под управлением? Если создание нового, то это можно сделать с помощью командной строки, либо специальных сервисов, о которых я расскажу в следующих частях.

Далее если у вас услуга виртуального частного облака, вам VPN совсем не нужен. Если же сервера не в одной сети, то спсобов подъема VPN существует множество, и мануалов на эту тему достаточно много даже тут на хабре.
Про сервисы с удовольствием почитаю.
VPN это понятно, но тот же докер имеет возможность построения оверлейных SDN сетей, думал может пользовались чем-нибудь таким. Мне нравится как работает их решение в docker cloud, но мне не нравится уровень контроля и процесс управления самого docker cloud поэтому ищу альтернативы.
Сергей, а можете ответить на эти вопросы:
а стоит ли мне заморачиваться с данной технологией имея не большую виртуалку на одном из известных хостеров и что в итоге мне это даст

В статье что-то не видно никаких возможных вариантов…
Это только первая часть статьи, если найдутся люди кому продолжение будет интересно, я допишу статью быстрей.

Лично для себя могу ответить, что имею услугу виртуального частного облака с 1 машиной, 1 цпу и 1024 МБ памяти, дисковое 30. Лично мне перевод своего сервера на контейнеры дало ощутимые плюсы. О которых я хотел рассказать позже, если вкратце, то приложения использующие разные виртуальные окружения через virtualenv теперь работают в контейнере, не зависимо друг от друга не прибегая к virtualenv, все пакеты стоят глобально. К тому же набор пакетов одного приложения не мешает набору другого приложения, и все это не лежит в системе. Удаляя контейнер с приложением или обновляя его система остается чистой. Миграция и переезд теперь будет в разы быстрей и проще. Всю инфраструктуру с нуля можно поднять за пару часов с учетом переноса данных.

Различные компоненты системы изолированны друг от друга это плюс к безопасности. Управление памятью стало гораздо проще, некоторые контейнера у меня имеют строго ограниченный лимит по памяти, что актуально на ее малом количестве.

Сейчас поддерживается кластеризация из коробки, следовательно при росте проекта я добавлю новый сервер перейдя на другой ТП, и перенесу сервисы очень быстро без простоев, либо сделаю балансировку.

Еще один из бонусов, эт то что не нужно помнить все этапы настройки сервера, конфиги и прочее, сервис поднимается с нуля запуском нужного контейнера. Конечно конфиги можно подменить, что в первом что во втором случае. Тут вопрос удобства.
НЛО прилетело и опубликовало эту надпись здесь
У большинства пользователей конфигурации в пределах 512-2048 мегабайт по памяти, если необходимо то swap раздел можно создать, для этого нужно описать это в нашем файле конфигурации, об этом сказано в документации, не уверен конечно что будет работа со свопом, не проверял просто.

Вы совершенно верно подметили, самый простой пример где можно получить нехватку памяти это ДБ, и действительно до использования контейнеров я у себя наблюдал такую ошибку. Сейчас те же сервисы в том же составе у меня живут на другом хостинге с теми же ресурсами но при этом Out of Memory я еще не разу не встречал, возможно все впереди. Как вариант можно внутри контейнера использовать forever или же supervisord, но в любом случае у меня есть контейнеры которым я гарантирую работу выделяя им нужный объем памяти.
НЛО прилетело и опубликовало эту надпись здесь
Можно устанавливать последнюю версию, в стабильной ветке, не обязательно использовать альфа билды. То что CoreOS создана для кластера я упомянул это вскользь, планируя рассказать об этом в будущем. С Rancher вы правы, там все очень печально и нет даже билда 1.0.0, я тестировал 0.7 версию, насчет минимализма и docker only в стоке с дефолтной консолью возможно, но если начать менять консоли на дебиан, убунту центос, то их минималистичность становиться почти идентичной, так зачем тогда танцы с консолями.

Далее, о части конфига, это к сожалению или счастью не нужно. Сервис стартует автоматом, так уж устроена эта ОС. По поводу днс, я же говорил что конфигурация минимальна, но никто не мешает прописать больше. У меня прописано больше, я привел минимальный конфиг, только чтобы взлетело, чтобы можно было посмотреть что это такое. Ведь есть и те пользователи, которые проделают шаги только ради любопытства и не будут использовать ее возможно никогда.

Я не претендую на одобрение широкого взгляда большо специалиста, смысл данной статьи рассказать рядовому пользователю, что Docker это не страшно, а вполне понятно просто и быстро. возможно вы разработчик фрилансер, или сотрудник поддержки, а может владелец бизнеса и самостоятельно занимаетесь вопросом хостинга сайта, эта статья сделана простой для понимания не системными администраторами.

Я не собирался писать научный труд, для этого есть официальная документация, и другие статьи.

Виртуалка одна, но я упоминаю о частном приватном облаке, где виртуалки впоследствии может быть, две три пять по мере роста проекта.

Опять же не забываем про идеологию микросервисов. Для например чат бота, хватит такой виртуалки и ее действительно можно разместить в контейнере на минималистичном Alpine, но когда возникнет вопрос балансировки и отказоустойчивости, то тут изначальный завод на CoreOS выигрывает тем, что необходимо лишь будет донастроить пару служб и кластер готов.
Где собственно ответы на поставленные вами же вопросы?
и что в итоге мне это даст.


Ну и плюсы какие-то странные для выбранной ОС
К тому же CoreOS умеет работать как с контейнерами Docker так и со своими собственными Rocket (rkt), что является конечно же плюсом.

То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.

Тогда в чем плюс-то?
Где собственно ответы на поставленные вами же вопросы?
и что в итоге мне это даст.

Я собственно хотел рассказать об этом дальше, воспринимайте это как рассказ о неком пути человека, конец которому вы увидите позже.

Насчет плюсов, я описал один из возможных и вскользь упомянул о других. Разумеется далее я хотел рассказать подробней. Но не хочу писать сразу 1 большую статью, так как от прочтения таких устаешь и теряешь нить и суть повествования.

То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.

Тогда в чем плюс-то?

Если эта хрень у вас не используется, это не значит что она тупая, у других она ой как используется, и как ее использовать расскажу позднее.
Статья о том как перевести продакшен на микросервисную архитектуру. Используя в частности Docker. А о различия Docker и Rocket я расскажу несколько позже.
  • Краткое описание преимуществ требуется, раз уж вы подняли эти вопросы. Равно как и пояснение, что детали будут раскрыты в следующих статьях. В противном случае читающий остается в недоумении и читать следующие статьи просто не будет.
  • Пишем не о Docker, а о Rocket — прямо об этом упоминаем(так и так, будем работать с докер-подобным контейнером со своей спецификой. Почему выбрали именно его — пояснить)

Статья о том как перевести продакшен на микросервисную архитектуру.

Вот это должно быть или в заголовке статьи или в первом же абзаце.
А не в комментариях.
Учту ваши пожелания, но заголовок уже меня поздно, многие добавили в избранное для поиска в будущем.

Вообще я всегда за конструктивную критику, так как это моя первая публичная статья. Учиться никогда не поздно. Спасибо за замечания!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации