Комментарии 59
НЛО прилетело и опубликовало эту надпись здесь
Зачем вообще ему шапка в помещении?
Может, лысину скрывает. Или проспорил кому-то перед презой.
Думаю, имелись ввиду простые правила этикета: интеллигентному мужчине находится в помещении в головном уборе не красиво и не уважительно по отношению к другим.
Всем плевать. Не нужно свой доморощенный семейный устав выдавать за правила этикета. Коль скоро он говорит по делу — пусть хоть маракасы на шею повесит.
Уважаемый, это не свой «доморощенный семейный устав», а общепринятое правило этикета, про которое вы можете прочитать в любой энциклопедии этикета.
Вот первая ссылка из гугла про это: http://www.dc-perekrestock.ru/use704.php
Вот первая ссылка из гугла про это: http://www.dc-perekrestock.ru/use704.php
Где вы все работаете, чистоплюи, которым нужна энциклопедия этикета, чтобы рассказать про контейнеры на технической конференции?
Я сам не маргинал, но у меня в команде парень с дредами, кто-то с татухами, другой любит ходить босым, а девчонка-тестер фанат тяжелой музыки и кожи. Выступают на конференциях, успешно контрибутят в open-source и вообще, ложили с прибором на тех, кого ебет их внешний вид. Все интересные личности, а с буквоедами энциклопедий я чувствую усну еще до того, как принесут меню на обеденном перерыве. Но это Берлин да, нам далеко до ваших арийских скреп и идеалов.
Я сам не маргинал, но у меня в команде парень с дредами, кто-то с татухами, другой любит ходить босым, а девчонка-тестер фанат тяжелой музыки и кожи. Выступают на конференциях, успешно контрибутят в open-source и вообще, ложили с прибором на тех, кого ебет их внешний вид. Все интересные личности, а с буквоедами энциклопедий я чувствую усну еще до того, как принесут меню на обеденном перерыве. Но это Берлин да, нам далеко до ваших арийских скреп и идеалов.
Я не поленился и открыл ссылку, и знаете, такого бреда я давно не видел, причем он очень щедро приправлен сексизмом.
Чего только стоит: «Женщине шапку с большими полями нельзя носить после 5 вечера». А мужчине можно. А женщина значит должна всегда носить запасную шапку в кармане, а то вдруг 5 вечера а она еще не вернулась домой.
Или например то что мужчине предлагается снимать на улице шапку если он слышит гимн (кстати, гимн какой страны? Обязательно ли знать гимны всех стран?) или говорит с женщиной.
Даром что сжигать никого в этой статье не предлагают.
Чего только стоит: «Женщине шапку с большими полями нельзя носить после 5 вечера». А мужчине можно. А женщина значит должна всегда носить запасную шапку в кармане, а то вдруг 5 вечера а она еще не вернулась домой.
Или например то что мужчине предлагается снимать на улице шапку если он слышит гимн (кстати, гимн какой страны? Обязательно ли знать гимны всех стран?) или говорит с женщиной.
Даром что сжигать никого в этой статье не предлагают.
Буквоедствовал-буквоедствовал, да невыбуквоедствовал.
Не всякий головной убор является шляпой. Засим предлагаю спор считать завершённым.
Не всякий головной убор является шляпой. Засим предлагаю спор считать завершённым.
Общепринятое… Странно, не помню, чтобы я или мои знакомые учавствовали в общественном обсуждении сего «достояния высших слоёв общества». Вам так хочется ограничиться в поведении длинным списком указаний, или же хочется ограничить других? Если первое — то пожалуйста, если второе — то не стоит. Пожалуйста, держите своих тараканов при себе.
Прочитал как: макросы на шею.
О, это вы наверное тот самый неадекватный HR, который требует дресс-код у программистов?
НЛО прилетело и опубликовало эту надпись здесь
Да, одному шорты — «клоунада», другому шапка, третьему крашеные волосы. А потом получаются вот такие истории, потому что вместо профессиональных качеств особо одаренные смотрят на то какая на ком футболка и шапка.
(del) комментарий почему-то прилепился в этот тред.
Не то, чтобы я не смог читать, но первое, что я подумал, когда увидел доклад — что это за хрень у него на голове, и зачем она ему нужна в помещении?! :)
Парни, завязывайте, такой стиль у человека. Какая разница, у кого какая шапка?
Двадцать первый век на дворе, конференция для гиков, а мы обсуждаем шапки.
Двадцать первый век на дворе, конференция для гиков, а мы обсуждаем шапки.
Спасибо! Каждый раз смотрю\читаю ваши доклады и успеваю не наступить на какие-то грабли)
Планируете ли открыть baDocker сообществу?
Планируете ли открыть baDocker сообществу?
Классная статья, полезный сборник потенциальных граблей при миграции в Docker
А докладчик на хабре присутствует? Хотелось бы узнать, сколько питания приходит на стойку, и сколько потом тепла можно снять, ведь даже при 10кВт хорошо нагрузить 40 машин в стойке не получится — они раза в два больше электричества сожрут.
Мне кажется самые первые грабли именно изза того что тащили часть хостовой системы в контейнер (не объяснили почему). Также непонятно зачем использовать блочное устройство в качестве ФС для хранения данных если можно просто засунуть код в докер.
И еще не увидел ни слова (в статье, видео не смотрел) про Docker volume.
Т.е по крайней мере первые грабли изза того что готовили докер не в концепции докера, а как то по своему.
И еще не увидел ни слова (в статье, видео не смотрел) про Docker volume.
Т.е по крайней мере первые грабли изза того что готовили докер не в концепции докера, а как то по своему.
«Концепция Docker» – это безусловно прекрасно. Вы не пробовали смотреть на инструмент, как на инструмент для достижения поставленных целей и решения конкретных задач? Иногда получается так, что для достижения решения нужно поскупиться концепцией и подойти к решению иначе…
Часть хостовой системы в контейнер – это вы про /dev/log или что-то еще? если будет более конкретный вопрос, то я попробую на него ответить.
Блочное устройство для docker root – это затем, что мы не хотели и не хотим получить BTRFS by default, именно поэтому был сделан отдельный том для docker root на BTRFS.
Код как таковой внутри контейнеров у нас не распространяется, т.к. большая часть сервисов, про которые я говорил — это binary.
Часть хостовой системы в контейнер – это вы про /dev/log или что-то еще? если будет более конкретный вопрос, то я попробую на него ответить.
Блочное устройство для docker root – это затем, что мы не хотели и не хотим получить BTRFS by default, именно поэтому был сделан отдельный том для docker root на BTRFS.
Код как таковой внутри контейнеров у нас не распространяется, т.к. большая часть сервисов, про которые я говорил — это binary.
Немного офтоп.
Как вообще разработчики живут со всем этим?
Нужно ставить весь стак компонентов и приложений локально?
Вы используете докер для девелопер среды тоже?
Насколько проблематично поддерживать контейнеры в актуальной версии?
спасибо
Как вообще разработчики живут со всем этим?
Нужно ставить весь стак компонентов и приложений локально?
Вы используете докер для девелопер среды тоже?
Насколько проблематично поддерживать контейнеры в актуальной версии?
спасибо
Нужно ставить весь стак компонентов и приложений локально?
Не обязательно. Разрабатывать можно как тебе удобно. Докер даёт возможность запустить приложение в конфигурации "как в продакшене". Для запуска нескольких связанных контейнеров используют Docker Compose
Насколько проблематично поддерживать контейнеры в актуальной версии?
Не проблематично, если деплой выглядит так:
- Собираем контенер.
- Тегируем его номером билда.
- На сервере загружаем контейнер нужной версии.
- Запускаем скачанную версию.
Немного офтоп.
Как вообще разработчики живут со всем этим?
Вот и я задаю этот вопрос – как с этим жить?
Нужно ставить весь стак компонентов и приложений локально?
Нет, для этого у нас есть несколько devel площадок, которые представляют собой уменьшенную копию нашего production окружения. Именно там они занимаются разработкой, тестированием и прочими прелестями, которые им нравятся.
Вы используете докер для девелопер среды тоже?
на данный момент нет, но для среды тестирования используем.
Насколько проблематично поддерживать контейнеры в актуальной версии?
что именно вы имели ввиду? актуальность пакетов ОС и их обновления? Не могли бы вы уточнить вопрос, а я попробую дать более полный ответ.
Спасибо
Интересно, как сделали удаленный web терминал? Там ведь не поднят SSH Server в контейнере?
В любом контейнере можно запустить bash и без поднятого ssh
Не, я к тому, как туда инжектнуться удаленно? Насколько мне не изменяет память, в данный момент я могу сделать только — docker exec, который запущен в данный момент там же, где я нахожусь.
Думаю, что-то типа такого, https://docs.docker.com/engine/reference/api/docker_remote_api_v1.19/#/attach-to-a-container-websocket если почитать документацию есть эквивалент для docker exec, консольная утилита по сути своей лишь клиент к REST API.
ssh внутри контейнеров у нас нет. Для web-терминала есть клиент-серверное приложение(я не помню название, но если очень нужно – могу вспомнить), которое у нас крутится на baDocker-сервере. По сути используется ssh соединение между baDocker сервером и docker хостом, где на последнем используется docker exec. Основная идея именно такая, если не лезть в дебри.
Я правильно понял что для service discovery используется что-то самописное? (Конец Видео) Интересно почему не тот же zookeeper/etcd/consul. Нет необходимости и слишком большой оверхэд по отношению к требуемым функциям?
Да, все верно поняли. На данный момент это самописное к docker ecosystem не имеет никакого отношения. Одна из основных причин – сервисы у нас не подходят под определение микросервисов и мы не можем так просто взять и поднять N-инстансов одного сервиса(верно не для всех сервисов, но для большей их части), что хорошо подходит для того service discovery, про который вы спрашиваете.
Т.е. у нас скорее это выглядит так:
— ручное принятие решение о поднятии сервиса/инстанса
— подготовка инстанса
— поднятие
— проверка, что все хорошо
— добавление информации о том, что сервис есть и им можно пользоваться
На самом деле рассмотрение etcd/zookeeper у нас также идет, но я не могу сказать, что на данный момент есть готовое внедрение и полноценное использование, так что на данный момент вот так.
Т.е. у нас скорее это выглядит так:
— ручное принятие решение о поднятии сервиса/инстанса
— подготовка инстанса
— поднятие
— проверка, что все хорошо
— добавление информации о том, что сервис есть и им можно пользоваться
На самом деле рассмотрение etcd/zookeeper у нас также идет, но я не могу сказать, что на данный момент есть готовое внедрение и полноценное использование, так что на данный момент вот так.
А зачем шапочка?
см. здесь. ;)
выше уже спрашивали.
А это дресс-код такой на конференции, судя по тому, что в соседнем треде про сравнение NoSQL-баз, докладчик вообще в шляпе.
Смотрели Kubernetes?
Да, смотрели. Более того – продолжаю смотреть на него с разных сторон. До сих пор не могу понять как и с какой стороны это нам может подойти… к сожалению.
Ну вот логи ваши, например. В kubernetes основная единица не контейнер, а pod — это набор сгруппированных контейнеров, которые имеют доступ к одним и тем же ресурсам. Скажем, вы можете создать отдельный контейнер с syslog, который будет доступен в рамках pod по заданному порту на localhost.
Потом этот контейнер с syslog можете просто подключать к своим сервисным pod'ам. Деплоймент, обнаружение сервисов, балансировка нагрузки на сервисы, поддержка заданного количества инстансов — все делает сам. Сетевая модель — на выбор тот же WeaveNet, Flannel, Calico.
Докер отдельно для серьезных проектов всё равно нуждается в системе оркестрации. Без Swarm, Mesos или Kubernetes от него мало прока в продакшне. Можно, конечно, многое допиливать и додумывать (что и пришлось вам делать), а можно взять полноценную систему оркестрации и сильно упростить себе жизнь.
Собственно Docker сейчас делает собственную оркестрацию — Swarm mode (в 1.12 появился впервые), который только пытается делать часть из того, что уже умеет Kubernetes для продакшна.
Ну и не стоит забывать, что Kubernetes — это опыт Гугла в управлении своими сервисами (те же инженеры пишут, что рулят их production-серверами)
Вы используете все эти новомодные слова или рассказываете теоретически? Просто все то что вы говорите выглядит красиво, но бьюсь об заклад что в реальности проблем 100500. Придется все свои существующие продукты переделывать так, чтобы они укладывались в видение Kubernetes как должно быть. А это примерно как «давайте перепишем все на Go».
Чудес не бывает: WeaveNet, Flannel, Calico – это мало того, что новые компоненты, так это еще и оверхед, от которого пострадает latency & throughput.
Что-то доступно по localhost в рамках pod – это также не чудо и имеет довольно простое объяснение. Данный бонус скорее относится к тем, кто приложение разрабатывает, чем к улучшению чего-то в production.
Балансировка – это прекрасно… RR, ну хорошо – есть еще healthcheck(не ох какой, но есть). То, куда приземляется трафик этого балансировщика… Вас все это устраивает?
Swarm mode не совместим с "--live-restore", как минимум. Swarm – это окончательно подсесть на Docker.
Stateful контейнеры – «не Docker way», но ничего не поделаешь – они есть и с этим как-то нужно жить. Мы приходим к тому, что желательно растянуть сторадж между хостами, на которых в случае чего pod/service может продолжить работу. Цепочку хотелок и зависимостей можно продолжать дальше долго.
К опыту Гугла я отношусь с большим уважением, также как и ко всем тем, кто занимается разработкой продуктов, которые в свою очередь оказывают неоценимую помощь остальным.
И как только я найду ответы хотябы на те сомнения и вопросы, что я написал – я непременно буду готов рассмотреть Kubernetes.
Собираемся и спасибо за Ваши добрые пожелания :)
Что-то доступно по localhost в рамках pod – это также не чудо и имеет довольно простое объяснение. Данный бонус скорее относится к тем, кто приложение разрабатывает, чем к улучшению чего-то в production.
Балансировка – это прекрасно… RR, ну хорошо – есть еще healthcheck(не ох какой, но есть). То, куда приземляется трафик этого балансировщика… Вас все это устраивает?
Swarm mode не совместим с "--live-restore", как минимум. Swarm – это окончательно подсесть на Docker.
Stateful контейнеры – «не Docker way», но ничего не поделаешь – они есть и с этим как-то нужно жить. Мы приходим к тому, что желательно растянуть сторадж между хостами, на которых в случае чего pod/service может продолжить работу. Цепочку хотелок и зависимостей можно продолжать дальше долго.
К опыту Гугла я отношусь с большим уважением, также как и ко всем тем, кто занимается разработкой продуктов, которые в свою очередь оказывают неоценимую помощь остальным.
И как только я найду ответы хотябы на те сомнения и вопросы, что я написал – я непременно буду готов рассмотреть Kubernetes.
Если собираетесь работать с docker'ом в продакшне, то рано или поздно — все эти 100500 проблем вы поимеете всё равно.
Собираемся и спасибо за Ваши добрые пожелания :)
Просто любопытно. Вы по сути делаете свой orchestration на докере. Интересно было узнать чем не устраивают существующие решения.
Если вам не сложно – вы можете посмотреть видео с моими докладами, в том числе по Docker. Очень часто в самом их начале я рассказываю о причинах того, почему нам довольно не просто взять и начать использовать что-то готовое. Это все не от того, что нам очень просто брать и делать что-то самостоятельно, а часто от того, что в готовом нет минимума, без которого мы не можем «взлететь».
Давайте я попробую привести несколько пунктов:
— у нас мало сервисов, которые мажутся горизонтально просто включением новых инстансов
— на начальном этапе внедрения нам нужно было «оркестрировать» максимально одинаково то, что в Docker и то, что нет
— сетевой аспект меня тоже довольно сильно тревожит
Т.е. основных поинтов два — сеть и изначально отличная от нашей архитектура.
Давайте я попробую привести несколько пунктов:
— у нас мало сервисов, которые мажутся горизонтально просто включением новых инстансов
— на начальном этапе внедрения нам нужно было «оркестрировать» максимально одинаково то, что в Docker и то, что нет
— сетевой аспект меня тоже довольно сильно тревожит
Т.е. основных поинтов два — сеть и изначально отличная от нашей архитектура.
Badoo лично мне интересна другой своей стороной — это единственный известный мне сайт, который на мобильной версии роняет Safari в iOS6, причем стабильно и регулярно. Все руки не дойдут поиссследовать, как ребятам это удалось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker в работе. Взгляд на его использование в Badoo (год спустя)