Comments 13
Расскажите пожалуйста, каким образом управляете контейнерами? Приходилось ли поднимать виртуальные сети между серверами?
Что вы конкретно понимаете под управлением? Если создание нового, то это можно сделать с помощью командной строки, либо специальных сервисов, о которых я расскажу в следующих частях.
Далее если у вас услуга виртуального частного облака, вам VPN совсем не нужен. Если же сервера не в одной сети, то спсобов подъема VPN существует множество, и мануалов на эту тему достаточно много даже тут на хабре.
Далее если у вас услуга виртуального частного облака, вам VPN совсем не нужен. Если же сервера не в одной сети, то спсобов подъема VPN существует множество, и мануалов на эту тему достаточно много даже тут на хабре.
Про сервисы с удовольствием почитаю.
VPN это понятно, но тот же докер имеет возможность построения оверлейных SDN сетей, думал может пользовались чем-нибудь таким. Мне нравится как работает их решение в docker cloud, но мне не нравится уровень контроля и процесс управления самого docker cloud поэтому ищу альтернативы.
VPN это понятно, но тот же докер имеет возможность построения оверлейных SDN сетей, думал может пользовались чем-нибудь таким. Мне нравится как работает их решение в docker cloud, но мне не нравится уровень контроля и процесс управления самого docker cloud поэтому ищу альтернативы.
Сергей, а можете ответить на эти вопросы:
В статье что-то не видно никаких возможных вариантов…
а стоит ли мне заморачиваться с данной технологией имея не большую виртуалку на одном из известных хостеров и что в итоге мне это даст
В статье что-то не видно никаких возможных вариантов…
Это только первая часть статьи, если найдутся люди кому продолжение будет интересно, я допишу статью быстрей.
Лично для себя могу ответить, что имею услугу виртуального частного облака с 1 машиной, 1 цпу и 1024 МБ памяти, дисковое 30. Лично мне перевод своего сервера на контейнеры дало ощутимые плюсы. О которых я хотел рассказать позже, если вкратце, то приложения использующие разные виртуальные окружения через virtualenv теперь работают в контейнере, не зависимо друг от друга не прибегая к virtualenv, все пакеты стоят глобально. К тому же набор пакетов одного приложения не мешает набору другого приложения, и все это не лежит в системе. Удаляя контейнер с приложением или обновляя его система остается чистой. Миграция и переезд теперь будет в разы быстрей и проще. Всю инфраструктуру с нуля можно поднять за пару часов с учетом переноса данных.
Различные компоненты системы изолированны друг от друга это плюс к безопасности. Управление памятью стало гораздо проще, некоторые контейнера у меня имеют строго ограниченный лимит по памяти, что актуально на ее малом количестве.
Сейчас поддерживается кластеризация из коробки, следовательно при росте проекта я добавлю новый сервер перейдя на другой ТП, и перенесу сервисы очень быстро без простоев, либо сделаю балансировку.
Еще один из бонусов, эт то что не нужно помнить все этапы настройки сервера, конфиги и прочее, сервис поднимается с нуля запуском нужного контейнера. Конечно конфиги можно подменить, что в первом что во втором случае. Тут вопрос удобства.
Лично для себя могу ответить, что имею услугу виртуального частного облака с 1 машиной, 1 цпу и 1024 МБ памяти, дисковое 30. Лично мне перевод своего сервера на контейнеры дало ощутимые плюсы. О которых я хотел рассказать позже, если вкратце, то приложения использующие разные виртуальные окружения через virtualenv теперь работают в контейнере, не зависимо друг от друга не прибегая к virtualenv, все пакеты стоят глобально. К тому же набор пакетов одного приложения не мешает набору другого приложения, и все это не лежит в системе. Удаляя контейнер с приложением или обновляя его система остается чистой. Миграция и переезд теперь будет в разы быстрей и проще. Всю инфраструктуру с нуля можно поднять за пару часов с учетом переноса данных.
Различные компоненты системы изолированны друг от друга это плюс к безопасности. Управление памятью стало гораздо проще, некоторые контейнера у меня имеют строго ограниченный лимит по памяти, что актуально на ее малом количестве.
Сейчас поддерживается кластеризация из коробки, следовательно при росте проекта я добавлю новый сервер перейдя на другой ТП, и перенесу сервисы очень быстро без простоев, либо сделаю балансировку.
Еще один из бонусов, эт то что не нужно помнить все этапы настройки сервера, конфиги и прочее, сервис поднимается с нуля запуском нужного контейнера. Конечно конфиги можно подменить, что в первом что во втором случае. Тут вопрос удобства.
1024 МБ
По умолчанию в CoreOS нет swap, не было ли проблем с недостатком памяти?
некоторые контейнера у меня имеют строго ограниченный лимит по памяти
Если контейнер, а точнее процесс в контейнере начет выходить за эти лимиты, с ростом нагрузки или у вас ограниченны не влиящие на работу сервиса контейнеры? Скажем ограничили вы контейнер с бд по памяти, а ему надо стало больше, что в итоге? хотя это уже должно быть во второй статье рассказано.
У большинства пользователей конфигурации в пределах 512-2048 мегабайт по памяти, если необходимо то swap раздел можно создать, для этого нужно описать это в нашем файле конфигурации, об этом сказано в документации, не уверен конечно что будет работа со свопом, не проверял просто.
Вы совершенно верно подметили, самый простой пример где можно получить нехватку памяти это ДБ, и действительно до использования контейнеров я у себя наблюдал такую ошибку. Сейчас те же сервисы в том же составе у меня живут на другом хостинге с теми же ресурсами но при этом Out of Memory я еще не разу не встречал, возможно все впереди. Как вариант можно внутри контейнера использовать forever или же supervisord, но в любом случае у меня есть контейнеры которым я гарантирую работу выделяя им нужный объем памяти.
Вы совершенно верно подметили, самый простой пример где можно получить нехватку памяти это ДБ, и действительно до использования контейнеров я у себя наблюдал такую ошибку. Сейчас те же сервисы в том же составе у меня живут на другом хостинге с теми же ресурсами но при этом Out of Memory я еще не разу не встречал, возможно все впереди. Как вариант можно внутри контейнера использовать forever или же supervisord, но в любом случае у меня есть контейнеры которым я гарантирую работу выделяя им нужный объем памяти.
Приветсвую,
Последняя версия docker всегда идет в alpha версии https://coreos.com/releases/
Она скорее создана для создания кластера, ибо etcd, flannel и тд из коробки, т.е продвижение своих наработок в ОС, щас вот tectonic кстати.
RancherOS вроде даже 1.х.х версии не достигла, но вот она скорее более чиста в плане only docker. Но очень сыра.
Чем тот же debian не угодил? или если уж совсем «чистую» ос, то alpine? или чем для вас «чистота» ОС определяется?
Вы кстати забыли в конфиге:
А то не будет автоматом стартовать, хотя systemctl enable docker.service должно работать, но данный параметр не сохраняется(вроде), могу ошибаться.
UTC там для класстера, это вполне нормально.
Кроме гугловских, добавили бы еще пару каких, или бы оставили те, что от хостера + гугл.
Виртуалка одна, как я понимаю, зачем тогда CoreOS? да и странный какой-то продакшен на одной вм… В общем статья во многом противоречет сама себе, на мой субъективный взгляд.
Вариант развития событий, чисто установленная ОС, без лишних компонентов, последняя версия Docker, о том как ее установить подробно описано в документации.
Последняя версия docker всегда идет в alpha версии https://coreos.com/releases/
Еще один прекрасный способ это использовать ОС созданную специально для контейнеров, например CoreOS
Она скорее создана для создания кластера, ибо etcd, flannel и тд из коробки, т.е продвижение своих наработок в ОС, щас вот tectonic кстати.
RancherOS вроде даже 1.х.х версии не достигла, но вот она скорее более чиста в плане only docker. Но очень сыра.
Чем тот же debian не угодил? или если уж совсем «чистую» ос, то alpine? или чем для вас «чистота» ОС определяется?
Вы кстати забыли в конфиге:
- name: docker.service
command: start
А то не будет автоматом стартовать, хотя systemctl enable docker.service должно работать, но данный параметр не сохраняется(вроде), могу ошибаться.
UTC там для класстера, это вполне нормально.
Кроме гугловских, добавили бы еще пару каких, или бы оставили те, что от хостера + гугл.
DNS=8.8.8.8
DNS=8.8.4.4
стоит ли мне заморачиваться с данной технологией имея не большую виртуалку
Виртуалка одна, как я понимаю, зачем тогда CoreOS? да и странный какой-то продакшен на одной вм… В общем статья во многом противоречет сама себе, на мой субъективный взгляд.
Можно устанавливать последнюю версию, в стабильной ветке, не обязательно использовать альфа билды. То что CoreOS создана для кластера я упомянул это вскользь, планируя рассказать об этом в будущем. С Rancher вы правы, там все очень печально и нет даже билда 1.0.0, я тестировал 0.7 версию, насчет минимализма и docker only в стоке с дефолтной консолью возможно, но если начать менять консоли на дебиан, убунту центос, то их минималистичность становиться почти идентичной, так зачем тогда танцы с консолями.
Далее, о части конфига, это к сожалению или счастью не нужно. Сервис стартует автоматом, так уж устроена эта ОС. По поводу днс, я же говорил что конфигурация минимальна, но никто не мешает прописать больше. У меня прописано больше, я привел минимальный конфиг, только чтобы взлетело, чтобы можно было посмотреть что это такое. Ведь есть и те пользователи, которые проделают шаги только ради любопытства и не будут использовать ее возможно никогда.
Я не претендую на одобрение широкого взгляда большо специалиста, смысл данной статьи рассказать рядовому пользователю, что Docker это не страшно, а вполне понятно просто и быстро. возможно вы разработчик фрилансер, или сотрудник поддержки, а может владелец бизнеса и самостоятельно занимаетесь вопросом хостинга сайта, эта статья сделана простой для понимания не системными администраторами.
Я не собирался писать научный труд, для этого есть официальная документация, и другие статьи.
Виртуалка одна, но я упоминаю о частном приватном облаке, где виртуалки впоследствии может быть, две три пять по мере роста проекта.
Опять же не забываем про идеологию микросервисов. Для например чат бота, хватит такой виртуалки и ее действительно можно разместить в контейнере на минималистичном Alpine, но когда возникнет вопрос балансировки и отказоустойчивости, то тут изначальный завод на CoreOS выигрывает тем, что необходимо лишь будет донастроить пару служб и кластер готов.
Далее, о части конфига, это к сожалению или счастью не нужно. Сервис стартует автоматом, так уж устроена эта ОС. По поводу днс, я же говорил что конфигурация минимальна, но никто не мешает прописать больше. У меня прописано больше, я привел минимальный конфиг, только чтобы взлетело, чтобы можно было посмотреть что это такое. Ведь есть и те пользователи, которые проделают шаги только ради любопытства и не будут использовать ее возможно никогда.
Я не претендую на одобрение широкого взгляда большо специалиста, смысл данной статьи рассказать рядовому пользователю, что Docker это не страшно, а вполне понятно просто и быстро. возможно вы разработчик фрилансер, или сотрудник поддержки, а может владелец бизнеса и самостоятельно занимаетесь вопросом хостинга сайта, эта статья сделана простой для понимания не системными администраторами.
Я не собирался писать научный труд, для этого есть официальная документация, и другие статьи.
Виртуалка одна, но я упоминаю о частном приватном облаке, где виртуалки впоследствии может быть, две три пять по мере роста проекта.
Опять же не забываем про идеологию микросервисов. Для например чат бота, хватит такой виртуалки и ее действительно можно разместить в контейнере на минималистичном Alpine, но когда возникнет вопрос балансировки и отказоустойчивости, то тут изначальный завод на CoreOS выигрывает тем, что необходимо лишь будет донастроить пару служб и кластер готов.
Где собственно ответы на поставленные вами же вопросы?
Ну и плюсы какие-то странные для выбранной ОС
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?
и что в итоге мне это даст.
Ну и плюсы какие-то странные для выбранной ОС
К тому же CoreOS умеет работать как с контейнерами Docker так и со своими собственными Rocket (rkt), что является конечно же плюсом.
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?
Где собственно ответы на поставленные вами же вопросы?
и что в итоге мне это даст.
Я собственно хотел рассказать об этом дальше, воспринимайте это как рассказ о неком пути человека, конец которому вы увидите позже.
Насчет плюсов, я описал один из возможных и вскользь упомянул о других. Разумеется далее я хотел рассказать подробней. Но не хочу писать сразу 1 большую статью, так как от прочтения таких устаешь и теряешь нить и суть повествования.
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?
Если эта хрень у вас не используется, это не значит что она тупая, у других она ой как используется, и как ее использовать расскажу позднее.
Статья о том как перевести продакшен на микросервисную архитектуру. Используя в частности Docker. А о различия Docker и Rocket я расскажу несколько позже.
и что в итоге мне это даст.
Я собственно хотел рассказать об этом дальше, воспринимайте это как рассказ о неком пути человека, конец которому вы увидите позже.
Насчет плюсов, я описал один из возможных и вскользь упомянул о других. Разумеется далее я хотел рассказать подробней. Но не хочу писать сразу 1 большую статью, так как от прочтения таких устаешь и теряешь нить и суть повествования.
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?
Если эта хрень у вас не используется, это не значит что она тупая, у других она ой как используется, и как ее использовать расскажу позднее.
Статья о том как перевести продакшен на микросервисную архитектуру. Используя в частности Docker. А о различия Docker и Rocket я расскажу несколько позже.
- Краткое описание преимуществ требуется, раз уж вы подняли эти вопросы. Равно как и пояснение, что детали будут раскрыты в следующих статьях. В противном случае читающий остается в недоумении и читать следующие статьи просто не будет.
- Пишем не о Docker, а о Rocket — прямо об этом упоминаем(так и так, будем работать с докер-подобным контейнером со своей спецификой. Почему выбрали именно его — пояснить)
Статья о том как перевести продакшен на микросервисную архитектуру.
Вот это должно быть или в заголовке статьи или в первом же абзаце.
А не в комментариях.
Sign up to leave a comment.
Внедрение Docker для небольшого проекта в Production