Честно говоря нет, в планах пока что закончить с репликами, пройтись по шардированию и кворумам. Я помню была какая-то статья от авторов, не очень большая, но скорее теоретическая (в том смысле что тяжело будет адаптировать в формат Хабра). Посмотрю что из других материалов есть по вашей теме для статьи, и попробую написать, если будет время.
Спасибо за предложение!
Спасибо за статью, уточните пожалуйста пару моментов:
Допустим, клиент прислал координатору запрос на открытие транзакции для такой-то сущности с таким-то первичным ключом. Координатор эту сущность блокирует и помещает в таблицу блокировок в памяти.
Блокирует на запись только, т.е. остальные клиенты могут читать?
Таким образом, клиент может прочитать собственные изменения, а другие клиенты эти изменения не видят, потому что хранятся они только в памяти координатора, в нодах Cassandra их еще нет.
А если ваш клиент в это время делает синхронный запрос в другой ваш сервис, которому надо получить из хранилища данные, актуальные относительно текущей транзакции?
И последний: R + W > N? на сколько нод пишете и со скольки читаете?
Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Так это что получается, можно дома заниматься выращиванием устойчивых бактерий и мазать ими поручни в метро? Или для такого эксперимента нужны какие-то уникальные условия?
В uk, например, не то, чтобы на анализ не направят, но и к терапевту только в порядке общей очереди (ждать примерно неделю-две).
Я как-то кашлял почти месяц, так меня отказались записать на приём, единственное что удалось — терапевт позвонил по телефону и попросил покашлять в трубку.
Конечно, мне была задана куча уточняющих вопросов, чтобы понять, записывать меня на приём или нет, и в особых случаях и скорая приедет. Но в целом я как-то стал менее чувствительно относиться ко всяким лёгким недомоганиям. Может, оно и к лучшему?
1. Я стараюсь разграничивать роли и обязанности, чего и вам советую. Если у меня есть плейбуки, в которых прописана логика работы с моим докер-окружением, значит у меня билд имаджа тоже в плейбуке. (см ниже про teamcity)
2.
Docker-compose делает тоже самое, что и настроенные ansible роли для контейнеров (
Таки нет. Этот модуль — обёртка над docker api. docker-compose в общем-то, простенькая утилита для удобного развёртывания/прибивания докер-окружения, которую, кстати, можно использовать в связке со swarm. Из приятных бонусов, как я уже упомянул — dns и изолированная сеть, а ещё не надо думать про имена хостов и контейнеров.
3. Если вынести весь management в ansible (чего я советую), то teamcity, как дорогой enterprise-продукт, становится избыточным. Я, честно говоря, не имею опыта использования teamcity как scheduler, возможно это как-то оправдано, но я бы порекомендовал использовать что-то другое, в зависимости от проекта.
Раз уж используете докер — то делайте сборку проекта в докере.
Почему не подошёл docker-compose? Точно такое же изолированное окружение со своей сетью и dns.
Прописываете * в днс на сервере и делаете поддомен на каждый новый бранч. Вот это поможет не плясать с бубном и не теребить docker inspect
Если ваше использование teamcity ограничивается вышенаписанным, то в конце заворачиваете всё в ansible и, в общем-то, teamcity становится не особо нужным.
Вообще тенденция развития docker inc слегка настораживает, уж больно сильно начинает пахнуть упором на платные enterprise-подписки и тотальным vendor lock-in.
elasticsearch почему-то перенёс имаджи в свой приватный репозиторий.
К счастью, разработчики Docker прекрасно понимают необходимость поддержки не только Linux в качестве базовой ОС.
Во второй половине 2016 года были выпущены официальные релизы Docker для Mac и Windows.
Почему компании дешевле нанять кого-то со стороны, чем заниматься обслуживанием самим
Добавлю к нижеответившим:
В основном потому что аутсорсер стремится извлечь выгоду, а большой отдел внутри большой компании больше занимается политикой, чем прибылью.
1. Аутсорс обычно набирается исходя из локального рейта (т.е. усть-жопинска)
2. Не надо оплачивать офисные и транспортные (а территория покрытия о-го-го) расходы, а так же расходы на аренду отеля и пропитания.
3. Не надо оплачивать больничные и отпуска.
4. Не надо тратить огромное количество ресурсов на найм сотрудников (локаций-то куча!) и не надо потом думать куда их деть если сезон без поломок
5. В случае проблем — одна точка входа: аутсорсер. В противном случае служба логистики обвиняет снабжение, снабжение — hr, hr — бизнес, который вовремя не оплатил проживание, бизнес — руководство проекта и т.д. Добавьте к этому по 2 совещания каждый день чтобы согласовать всё это.
У нас, например, политика компании — в офисе оставить только менеджеров/лидов, вся разработка — аутсорс.
С точки зрения общения с фронтендом — это должен быть единый API, желательно построенный на одних и тех же принципах, и который можно менять более-менее целостно.
Посмотрите в сторону api gateway, например apigee
Если я, как фронтенд lead, для реализации какой-то функциональности на вебе придумываю API и иду договариваться с бэкенд разработчиками о том, чтобы его реализовать — я должен учесть не только интересы веба, не только интересы бэкенда, но и интересы мобильных команд. Только в таком случае не придётся мучительно переделывать.
А ещё можно завести позицию архитектора, чтобы он решал такие вопросы.
Был у вас на собеседовании, два раза просил рассказать про формирование «премиальной» части зарплаты. Всё, что понял из ответа — определяется факторами, такими как «общение/помощь коллегам» и «крутость выполненных задач». Какого-то более чёткого ответа получить не удалось, что удивило, так как ожидал более внятных алгоритмов определения весомой части зарплаты (причём рядом сидел тимлид и на прямой вопрос от коллеги «как ты определяешь премии?» тоже внятно не ответил).
Алексей, может вы поподробнее расскажете?
Спасибо за предложение!
Спасибо, а внутри ДЦ?
Блокирует на запись только, т.е. остальные клиенты могут читать?
А если ваш клиент в это время делает синхронный запрос в другой ваш сервис, которому надо получить из хранилища данные, актуальные относительно текущей транзакции?
И последний: R + W > N? на сколько нод пишете и со скольки читаете?
Предполагаю, потому что если вы её покупаете и принимаете решение использовать — то проблемы с экологией перекладываются на вас.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Я как-то кашлял почти месяц, так меня отказались записать на приём, единственное что удалось — терапевт позвонил по телефону и попросил покашлять в трубку.
Конечно, мне была задана куча уточняющих вопросов, чтобы понять, записывать меня на приём или нет, и в особых случаях и скорая приедет. Но в целом я как-то стал менее чувствительно относиться ко всяким лёгким недомоганиям. Может, оно и к лучшему?
2.
Таки нет. Этот модуль — обёртка над docker api. docker-compose в общем-то, простенькая утилита для удобного развёртывания/прибивания докер-окружения, которую, кстати, можно использовать в связке со swarm. Из приятных бонусов, как я уже упомянул — dns и изолированная сеть, а ещё не надо думать про имена хостов и контейнеров.
3. Если вынести весь management в ansible (чего я советую), то teamcity, как дорогой enterprise-продукт, становится избыточным. Я, честно говоря, не имею опыта использования teamcity как scheduler, возможно это как-то оправдано, но я бы порекомендовал использовать что-то другое, в зависимости от проекта.
Если ваше использование teamcity ограничивается вышенаписанным, то в конце заворачиваете всё в ansible и, в общем-то, teamcity становится не особо нужным.
Вообще тенденция развития docker inc слегка настораживает, уж больно сильно начинает пахнуть упором на платные enterprise-подписки и тотальным vendor lock-in.
elasticsearch почему-то перенёс имаджи в свой приватный репозиторий.
На маке volumes нещадно тормозят, проблема открыта с марта 2016 года (актуально для Docker for Mac)
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076
И даже подошло по смыслу :)
Добавлю к нижеответившим:
В основном потому что аутсорсер стремится извлечь выгоду, а большой отдел внутри большой компании больше занимается политикой, чем прибылью.
1. Аутсорс обычно набирается исходя из локального рейта (т.е. усть-жопинска)
2. Не надо оплачивать офисные и транспортные (а территория покрытия о-го-го) расходы, а так же расходы на аренду отеля и пропитания.
3. Не надо оплачивать больничные и отпуска.
4. Не надо тратить огромное количество ресурсов на найм сотрудников (локаций-то куча!) и не надо потом думать куда их деть если сезон без поломок
5. В случае проблем — одна точка входа: аутсорсер. В противном случае служба логистики обвиняет снабжение, снабжение — hr, hr — бизнес, который вовремя не оплатил проживание, бизнес — руководство проекта и т.д. Добавьте к этому по 2 совещания каждый день чтобы согласовать всё это.
У нас, например, политика компании — в офисе оставить только менеджеров/лидов, вся разработка — аутсорс.
Посмотрите в сторону api gateway, например apigee
А ещё можно завести позицию архитектора, чтобы он решал такие вопросы.
Алексей, может вы поподробнее расскажете?
Вы пробовали networks — aliases?