Обновить
1
kai@kai

Пользователь

6
Подписчики
Отправить сообщение
Волшебно, конечно. Но пока только щелочку приоткрыли. До полноценного кодирования на .net под никсами еще лет пять, наверное.
Woraround приводил к тому, что Google hangouts не работал и постоянно непонятные оповещения появлялись о необходимости обновления библиотеки.

А сони никак не отреагировала, т.е. забила. Нужно было гуглить форумы на английском.
Смешно сказали, когда выпустили 4.4.2, в нем был всемирно известный баг с Google Services. Батарея в ноль разряжалась за час-два. Они этот баг не фиксили аж до следующей версии. Вот такое вот качество и поддержка пользователей.
Я об этом и говорю, как только мы выходим за рамки одного хоста — начинается серьезная доработка и подключение сторонних инструментов.

Чем в таком сценарии помогает докер, мне до сих пор не понятно. Все что я видел кажется сложнее связки API облака + Puppet + Git

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

А я говорю о другом, когда хостов несколько. Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
Но это все работает только в пределах одного хоста?
Из того что я узнал я сделал вывод, что докеру явно не хватает возможностей по конфигурации профилей «из коробки». Приходится использовать внешний инструмент для конфигураций, но тогда в облачной среде выгоды от использования докера нет. Тот же puppet позволяет накатить любую конфигурацию на шаблонный инстанс по иерархии роль_сервера/fqdn.

А вот для работы внутри отдела разработки штука стоящая и я пожалуй буду ее внедрять.
Кстати вариант, но я бы еще посмотрел в сторону Promox API + Puppet. С докером (если я правильно понимаю) начнется развесистая конфигурация сети, например, если вдруг окажется, что разные части HA находятся на разных хостах. Да и вопрос конфигурации сервисов докер не отменяет, опять же придется использовать какой-нибудь инструмент. Но тогда появится вопрос, зачем в этом всем нужен докер.
Можно назвать это разграничением ресурсов, если хотите. Но я простоты не вижу. Сейчас любой более-менее продвинутый облачный хостер позволяет через api создавать инстансы, в которые можно разворачивать образы, которые могут отлично конфигурировать себя через puppet.

И на мой взгляд такая схема проще. Хотя, пойду еще почитаю.
Мне кажется, что отдельный сервисы лучше запускать в отдельных виртуальных машинах. Чем мешать туда еще и второй слой виртуализации.
Давайте проще, образ — это read-only шаблон. Его мониторить не нужно. Нужно мониторить контейнеры, которые мы получаем из образов.

А вот упрощается ли задача мониторинга нескольких контейнеров на одном виртуальном хосте? Не думаю.
Мониторить виртуальные инстансы в облаке или виртуальные инстансы в виртуальных инстансах в облаке?

Мне кажется, первый вариант проще. Меньше прослоек, меньше глюков.
В обратную сторону опять надо перенастраивать. В общем просто докером тут не обойтись. Нужно делать большую обвязку, как мне кажется.
Они на разных хостах. У них разные настройки подключения к БД. Мне кажется, с ходу так не получится.
Допустим, у меня есть DB которая работает на отдельном хосте и есть несколько приложений, которые работают с этой DB. Как мне мигрировать все это на компьютер разработчика и обратно?

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

У кого есть опыт работы со сложными конфигурациями, пожалуйста, поделитесь им?
Для этого надо тесты проводить на своем оборудовании. Иначе профанация а не тест.
А там какая-то особенная поддержка?
Приводите конкретные баги, мешающие вам жить, а не список всего-всего.
Так пусть попробуют наказать. Видимо нет желающих привлекать к себе внимание высокими ценами.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность