Comments 42
Советую вам посмотреть на docker-machine, думаю, что потребность в ansible отпадет docs.docker.com/swarm/install-w-machine
Все же сертификатики лучше генерировать в специальных тулзах, например xca.
Ключики сварма стоит покидать в ~/.docker для удобства
Если кластер у вас один или несколько подписанных одним ЦС, а ваша клиенсткая машина хорошо защищена, то да.
У меня все рабочие файла хранятся в зашифрованном образе, который я могу открыть на другой машине, поэтому так. Более того, если я сгенерирую новые сертификаты, то мне надо будет не забыть их обновить и тут. Я для себя решил проблему просто добавив в Makefile:
У меня все рабочие файла хранятся в зашифрованном образе, который я могу открыть на другой машине, поэтому так. Более того, если я сгенерирую новые сертификаты, то мне надо будет не забыть их обновить и тут. Я для себя решил проблему просто добавив в Makefile:
swarm:
@(docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem info)
А что за зашифрованный образ? Не поделитесь в двух словах, как это выполнено архетектурно/технически? Интересная идея но как-то всё руки не доходят организовать себе что-то похожее)
Если у вас OS X, то информация есть на Хабре, например тут.
третья причина – это стоимость. У меня сейчас ~9Tb трафика и ~5Tb данных, которые я регулярно обрабатываю, обходится мне все это ~100$/месяц (можете посчитать сколько это будет стоить на AWS)
Поделитесь расчётами.
Спасибо, отличная статья, продолжайте в том же духе.
Но вот лично для меня все статьи про docker и т.п. не вдохновляют по одной простой причине: отдают незаконченностью. Вернее они рассказывают, как это круто, но я ещё не встречал статей, где есть полностью построенный какой-то проект, пусть и тестовый, сферический в вакууме. Тестовый, но реальный.
Спросите, а о чём это он? Да ну хотя бы LEMP, а ещё лучше load balancer + 2-3 node.js + MongoDB replica set. Или я чего-то совсем не понимаю, да…
Но вот лично для меня все статьи про docker и т.п. не вдохновляют по одной простой причине: отдают незаконченностью. Вернее они рассказывают, как это круто, но я ещё не встречал статей, где есть полностью построенный какой-то проект, пусть и тестовый, сферический в вакууме. Тестовый, но реальный.
Спросите, а о чём это он? Да ну хотя бы LEMP, а ещё лучше load balancer + 2-3 node.js + MongoDB replica set. Или я чего-то совсем не понимаю, да…
Докер это не панацея, строго говоря, не всем он подходит, совсем суровые пацаны вообще свои решения пишут, не хуже, я встречал таких. Это скорее показательный пример, философский взгляд, если хотите, чтобы в тему въехать, ну а дальше уже каждый хохочет как хочет.
Я ж не спорю, что каждому своё…
Просто практически все статьи заканчивают тем, что вот, мы установили докер, теперь всё круто. Всё. Ну т.е. совсем всё.
И нет статей, как это потом в реальности использовать. Вот что печалит.
Просто практически все статьи заканчивают тем, что вот, мы установили докер, теперь всё круто. Всё. Ну т.е. совсем всё.
И нет статей, как это потом в реальности использовать. Вот что печалит.
Наверное потому, что ниже уже идут совершенно рядовые рабочие вопросы, которые многократно обсасывались уже.
Непонятно, что ещё писать, есть некий пул, в нем крутятся воркеры, вдруг набежал-набежал клиент, в пуле поднялись ещё с десяток воркеров, все счастливы, ничего не тормозит, программеры получают премии, покупают яхты и спорткары (ну, пока не проснулись).
Непонятно, что ещё писать, есть некий пул, в нем крутятся воркеры, вдруг набежал-набежал клиент, в пуле поднялись ещё с десяток воркеров, все счастливы, ничего не тормозит, программеры получают премии, покупают яхты и спорткары (ну, пока не проснулись).
У рядовых рабочих вопросов есть огромное количество нюансов, которые совсем не очевидны когда ты только начинаешь использовать Docker. Появление Machine, Swarm, Compose, Network, Orca, плагинов для Docker Engine обусловлено тем, что при использовании докера на реальных проектах существует масса проблем, особенно если ты переходишь к микросервисной архитектуре и количество контейнеров начинает расти.
Это точно. В самом начале использования Docker'a и при запуске первых версий проекта вообще никаких проблем не было. Но по мере того, как проект начал разбиваться на части, которые зависят друг от друга (вышеупомянутая микросервисная архитектура) + количество машин выросло, все стало уже не так просто и весело.
Пришлось потратить время, что бы вникнуть в возможные решения проблем и только потом начать их постепенно решать.
Пришлось потратить время, что бы вникнуть в возможные решения проблем и только потом начать их постепенно решать.
Любая маленькая задумка в моей голове превращается в грандиозный план, который ограничивается только временем моей жизни.
Я хочу написать серию статей, про то, как сейчас у меня все устроено. Открывая занавесу тайны, там и балансировщики нагрузки и Service Discovery c DNS и распределенная файловая система и приватная сеть и т.д. Надо время, что бы разделить все это на части и сформулировать доступным для «не системных администраторов» языком.
То, что есть сейчас называть облачным хостингом нельзя. Но я надеюсь, что это только начало.
Я хочу написать серию статей, про то, как сейчас у меня все устроено. Открывая занавесу тайны, там и балансировщики нагрузки и Service Discovery c DNS и распределенная файловая система и приватная сеть и т.д. Надо время, что бы разделить все это на части и сформулировать доступным для «не системных администраторов» языком.
То, что есть сейчас называть облачным хостингом нельзя. Но я надеюсь, что это только начало.
Ну почему нет? У нас есть законченный пилотный проект. Конечно одним докером дело не заканчивается. Ещё как минимум нужна оркестрация (мы пока сидим целиком на ansible, но уже смотрим на kubernetes и иже с ним) и service discovery (используем consul). Сейчас докер пилит собственные решения, но судя по тому, что я видел (тот же swarm), они ещё достаточно сырые.
У меня пока нет статьи на эту тему, но есть слайды с выступления на ITGM.
У меня пока нет статьи на эту тему, но есть слайды с выступления на ITGM.
ОК, вы сделали локальный кластер с балансировкой нагрузки. Но где тут «облачность»?
Вроде как удовлетворяет определению облачности, не? Есть конфигурируемый пул ресурсов и есть on demand интерфейс.
> вы сделали локальный кластер
Что вы имеете ввиду под словом «локальный»? Частный?
> с балансировкой нагрузки
Я не писал в этой части ничего о балансировке нагрузке, так что её пока нет.
> Но где тут «облачность»?
Сейчас «облачность» заключается в том, что вы можете запустить выполнение вашего веб-приложения, сказав – «Мне надо 512Mb оперативной памяти, SSD диск и MongoDB рядом. Иди выполнись там где-нибудь». И где оно будет выполняться, вы не думаете.
Я уже писал выше, что называть это полноценным облачным хостингом пока нельзя, предстоит написать еще несколько статей и решить массу проблем.
Что вы имеете ввиду под словом «локальный»? Частный?
> с балансировкой нагрузки
Я не писал в этой части ничего о балансировке нагрузке, так что её пока нет.
> Но где тут «облачность»?
Сейчас «облачность» заключается в том, что вы можете запустить выполнение вашего веб-приложения, сказав – «Мне надо 512Mb оперативной памяти, SSD диск и MongoDB рядом. Иди выполнись там где-нибудь». И где оно будет выполняться, вы не думаете.
Я уже писал выше, что называть это полноценным облачным хостингом пока нельзя, предстоит написать еще несколько статей и решить массу проблем.
Не сочтите за троллинг, я сам занимаюсь виртуализацией и сервисной архитектурой. Но мой самый больной вопрос: а зачем это всё, если ресурсы железа ограничены? Вы всё равно не сможете запустить больше воркеров (инстансов?) приложения, чем допустимо в рамках суммарного железа этого кластера. Вы не сможете сказать приложению «иди и запустись где-нибудь, где есть 512Mb оперативной памяти», если этой свободной оперативной памяти не осталось на железных машинах.
Популярные аргументы виртуализаторов о том, что дескать «если у нас возрастёт нагрузка — мы стартуем ещё 100500 воркеров и обслужим её» разбиваются элементарным утверждением, что достаточно держать постоянно запущенными 100500 воркеров — в режиме ожидания они всё равно практически не жрут ни память, ни CPU, ни электропитание. А в случае хостинга на арендованном железе, как правило, цена за него — фиксированная независимо от нагрузки.
Что полезного конкретно вам дала описанная виртуализация?
Популярные аргументы виртуализаторов о том, что дескать «если у нас возрастёт нагрузка — мы стартуем ещё 100500 воркеров и обслужим её» разбиваются элементарным утверждением, что достаточно держать постоянно запущенными 100500 воркеров — в режиме ожидания они всё равно практически не жрут ни память, ни CPU, ни электропитание. А в случае хостинга на арендованном железе, как правило, цена за него — фиксированная независимо от нагрузки.
Что полезного конкретно вам дала описанная виртуализация?
Спасибо, хороший вопрос.
Конкретно у меня ситуация такая, что требования к размеру хранилища растут быстрее требований к CPU и оперативной памяти. Получается так, что мне надо например 4 дополнительных сервера только для того, что бы у меня было 24Tb дополнительного места, при этом 4 * 8 = 32 ядра никогда не будут загружены, большая часть из 128Gb оперативной памяти тоже будет свободна.
Решение, кажется, в том, что бы просто доставить жесткие диски в сервера, но выйдет дороже, чем арендовать еще несколько серверов. Каждый новый сервер идет со включенным бесплатным трафиком, который тоже используется по назначению и добавляет 1Gbps к общей пропускной способности.
Я уже писал выше, сколько это может стоить у AWS например. Если взять полученную стоимость, разделить на 3, накупить на эти деньги серверов, то у вас будет очень хороший запас производительности.
Конкретно у меня ситуация такая, что требования к размеру хранилища растут быстрее требований к CPU и оперативной памяти. Получается так, что мне надо например 4 дополнительных сервера только для того, что бы у меня было 24Tb дополнительного места, при этом 4 * 8 = 32 ядра никогда не будут загружены, большая часть из 128Gb оперативной памяти тоже будет свободна.
Решение, кажется, в том, что бы просто доставить жесткие диски в сервера, но выйдет дороже, чем арендовать еще несколько серверов. Каждый новый сервер идет со включенным бесплатным трафиком, который тоже используется по назначению и добавляет 1Gbps к общей пропускной способности.
Я уже писал выше, сколько это может стоить у AWS например. Если взять полученную стоимость, разделить на 3, накупить на эти деньги серверов, то у вас будет очень хороший запас производительности.
Но ведь писечка тут как раз в том, что можно развернуть понадобившиеся воркеры именно на чужом железе, пусть и дорого, зато очень быстро, много и строго на необходимый период, минута в минуту.
Есть ситуации, когда нагрузка сильно увеличивается (о вас написали в New York Times или ссылку ретвитнул супер известный блогер) и на ваш стартап, которому так необходима реклама наваливается огромная толпа долгожданных пользователей. И облачный хостинг как раз и должен решать эту проблему, тут вы правы.
Но что мы будем делать со своим стартапом, когда получим счёт от AWS на 5000$, а у вас всего столько денег на ваш проект. Возможно, было бы дешевле упасть на минут 10, пока вы оформили заказ на 4 дополнительных сервера и запустили Ansible, который их добавит в ваше облако. А оставшиеся 4900$ потратить на рекламу вашего проекта.
Но что мы будем делать со своим стартапом, когда получим счёт от AWS на 5000$, а у вас всего столько денег на ваш проект. Возможно, было бы дешевле упасть на минут 10, пока вы оформили заказ на 4 дополнительных сервера и запустили Ansible, который их добавит в ваше облако. А оставшиеся 4900$ потратить на рекламу вашего проекта.
Docker Swarm пока еще в статусе «бета» и официально не рекомендуется его авторами к использованию в продакшене (хотя многие конечно же используют). А как ваш опыт с Docker Swarm? Давно ли используете, что со стабильностью, с багами? Почему вы выбрали именно его, какие еще варианты рассматривали?
Docker Swarm пока еще в статусе «бета» и официально не рекомендуется его авторами к использованию в продакшене (хотя многие конечно же используют).
Да, я писал в начале статьи, что использую некоторые компоненты в статусе «бета». Мой проект до сих пор в разработке и когда придет время запуска, возможно Docker Swarm уже выйдет из «беты».
Почему вы выбрали именно его, какие еще варианты рассматривали?
Изначально так получилось исторически: Сначала была одна машина и все необходимые сервисы я засунул в Docker, потом появилась вторая и я сделал тоже самое. Спустя какое-то время я познакомился с Docker Swarm и понял, что могу его без проблем внедрить у себя. C Docker'ом у меня никогда проблем не возникало (и не возникает по сей день), так что необходимости в его замене на что-то другое не было.
А как ваш опыт с Docker Swarm? Давно ли используете, что со стабильностью, с багами?
Около месяца не очень активного использование, проблем пока не встречал.
Вторая причина заключается в специфике моего проекта, он связан с приватностью персональных данных. У меня нет причин кому-то просто доверять свои данные, а своих пользователей тем-более. Меня очень волнует этот вопрос, и я обеспокоен тем, что ему уделяется так мало внимания.
Если бы Вы действительно переживали за сохранность ваших данных, то для вас было бы очевидно, что для того чтобы обеспечить сохранность нужно потратить денег на свой сервер, хотябы бу, поставить его в ЦОД, нанять администратора, обеспечить конфигурацию ПО согласно нужным политикам безопастности. А так это просто баловство.
Если бы Вы действительно переживали за сохранность ваших данных, то для вас было бы очевидно, что для того чтобы обеспечить сохранность нужно потратить денег на свой сервер, хотябы бу, поставить его в ЦОД, нанять администратора, обеспечить конфигурацию ПО согласно нужным политикам безопастности. А так это просто баловство.
Зачем вы написали глупости, на которые даже ответить толком нечего?
В общем не пишите о том, о чем понятия не имеете и все у вас будет здорово, а пока «баловство» это ваш комментарий.
P.S. В проекте, о котором я вскользь упомянул, используется шифрованием на стороне клиента. Так что я немного расстроюсь тогда, когда он попадет в руки сотрудников АНБ, а не сотрудника ЦОДа.
- Где в статье хоть какая-то информация о моём проекте?
- Где в статье говориться о том, что я использую для своего проекта такие же инструменты и составляющие?
- Каким образом купленный сервер, поставленный в ЦОД, безопасней арендованного? К нему нет доступа у сотрудников ЦОДа или что, не пойму?
В общем не пишите о том, о чем понятия не имеете и все у вас будет здорово, а пока «баловство» это ваш комментарий.
P.S. В проекте, о котором я вскользь упомянул, используется шифрованием на стороне клиента. Так что я немного расстроюсь тогда, когда он попадет в руки сотрудников АНБ, а не сотрудника ЦОДа.
По моему вы назвали причину для чего нужно использовать свой хостинг, цитату я привел.
Может быть я Вам открою секрет, но в подавляющем большинстве при аренде сервера у провайдера, сотрудники этого провайдера имеют доступ к серверу на уровне операционной системы.
Мне кажется это Вы не имеете понятие о том каким последствиям может привезти на коленке собранный хостинг по вашим рекомендациям.
Может быть я Вам открою секрет, но в подавляющем большинстве при аренде сервера у провайдера, сотрудники этого провайдера имеют доступ к серверу на уровне операционной системы.
Мне кажется это Вы не имеете понятие о том каким последствиям может привезти на коленке собранный хостинг по вашим рекомендациям.
Вы не имеете понятия о том, о чем говорите.
Каким образом сотрудник может «иметь доступ к серверу на уровне операционной системы» у выделенного арендованного сервера (не виртуального), на который вы сами ставите ОС? Сотрудник ЦОДа вообще ни сном ни духом что вы творите с этим бедным сервером и какие у вас там пароли.
Единственное, что может сделать ваш «могущественный» сотрудник ЦОДа, это выдрать жесткий диск и попытаться примонтировать его у себя. И если ваш жесткий диск зашифрован или там просто хранятся зашифрованные копии пользовательских данных, то и это не даст ему ничего.
Ну расскажите мне, с техническими подробностями, к чему же это может привести?
но в подавляющем большинстве при аренде сервера у провайдера, сотрудники этого провайдера имеют доступ к серверу на уровне операционной системы.
Каким образом сотрудник может «иметь доступ к серверу на уровне операционной системы» у выделенного арендованного сервера (не виртуального), на который вы сами ставите ОС? Сотрудник ЦОДа вообще ни сном ни духом что вы творите с этим бедным сервером и какие у вас там пароли.
Единственное, что может сделать ваш «могущественный» сотрудник ЦОДа, это выдрать жесткий диск и попытаться примонтировать его у себя. И если ваш жесткий диск зашифрован или там просто хранятся зашифрованные копии пользовательских данных, то и это не даст ему ничего.
Мне кажется это Вы не имеете понятие о том каким последствиям может привезти на коленке собранный хостинг по вашим рекомендациям.
Ну расскажите мне, с техническими подробностями, к чему же это может привести?
А какой образ ОС вы будете ставить на сервер, не тот ли что уже подготовлен поставщиком услуг аренды сервера?
Ну расскажите мне, с техническими подробностями, к чему же это может привести?
Может вам еще за кофе сбегать? К Школохостерам идите они Вас всему научат, опыту наберетесь возвращайтесь поговорим.
Ну расскажите мне, с техническими подробностями, к чему же это может привести?
Может вам еще за кофе сбегать? К Школохостерам идите они Вас всему научат, опыту наберетесь возвращайтесь поговорим.
Sign up to leave a comment.
Свой облачный хостинг за 5 минут. Часть 1: Ansible, Docker, Docker Swarm