Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один "домашний" для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).
За прошедшее время накопился довольно большой опыт работы с Nomad окружением, в статье опишу встреченные проблемы Nomad и как с ними можно справиться.
Немного текста про поддержку IPv6 в докере и ещё кой-какие нюансы docker networking.
IPv4
Для разминки рассмотрим обычную IPv4-only систему. На хост-машине есть интерфейс eth0. К этому интерфейсу привязан внешний IP-адрес. Ещё есть loopback интерфейс. Когда на такую машину мы устанавливаем docker, он создаёт себе дефолтную сеть с названием bridge. Для этой сети на хост-машине создается еще один интерфейс docker0. У него тоже появляется ip адрес, например, 172.17.0.1. Когда мы запускаем контейнер, докер выделяет контейнеру адрес из выбранной сети (bridge по умолчанию). Например, 172.17.0.5. Внутри контейнера появляется интерфейс eth0 и на нём адрес 172.17.0.5. Итак, с адресами базово разобрались. Теперь попробуем понять, как процесс внутри контейнера может обращаться к внешним ресурсам и как сделать так, чтобы можно было снаружи сходить в контейнер.
Однажды наша команда решилась на эксперимент по расстрелу боевой платежной системы реальными деньгами. Это позволило бы понять, сколько сможем выдержать мы вместе с нашими партнерами. Об этом неоднозначном опыте и хочу рассказать.
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Британская компания NotSoSecure, специализирующаяся на penetration testing и ИТ-безопасности в целом, представила головоломку для специалистов по Docker под названием Vulnerable Docker VM.
В Москве конференция Гейзенбаг уже проходила в декабре 2016-го, а теперь впервые добралась до Петербурга. Суть у Гейзенбаг 2017 Piter осталась прежней: «конференция о тестировании, но не только для тестировщиков». А изменились ли детали? Какие доклады были в этот раз? Правда ли, что Илари Хенрик Эгертер сбрил свою удивительную бороду? Ответы на все эти важнейшие вопросы — под катом.
Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.
Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.
В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.
Представляю вам перевод моей статьи на Medium.com: часть 1, часть 2. Поскольку первая часть статьи содержит в основном уже изложенное в этом посте, то привожу перевод только второй части.
Худеем и переезжаем в контейнеры
В первой части статьи я рассказал о простых подходах, позволяющих построить масштабируемый кластер Selenium без написания кода. В этой части мы рассмотрим более тонкие вопросы работы с Selenium:
Как создать легко масштабируемые рабочие ноды, используя стандартный Selenium Hub
Почему можно и нужно запускать большинство браузеров в контейнерах и как это делается
Какие open-source инструменты для этого существуют
Все разработчики рано или поздно сталкиваются с регулярными выражениями. Практически в 100% случаев нам совершенно не нравится их составлять, считая это побочной работой, не связанной с программированием.
Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).
А как же составить это самое регулярное выражение?
До недавнего времени существовало 2 ответа на этот вопрос:
Изучить документацию по регулярным выражениям и составить регулярку самому
Попросить кого-то более опытного сделать это за вас
Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:
Давным давно, в одном проекте пришел довольно интересный и сложный запрос от внутренних пользователей. Персоналу технической поддержки нужно было самим задавать правила валидации для определенных полей, разным пользователям. Правила должны были часто и очень оперативно изменяться.
В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.
Ремарка: в начале статьи содержится рассуждение автора оригинала о том, зачем Facebook купил WhatsApp за баснословные 19 миллиардов. Если это вам не интересно — просто пролистайте, описание архитектуры будет ниже.
Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).
Как объяснить контейнеру docker-а сколько у него есть ресурсов?
К написанию этой небольшой заметки меня подтолкнула статья-перевод Java и Docker: это должен знать каждый и скудный на результаты поиск информации по теме. Я давно использую LXC, который тоже ограничивает ресурсы контейнеров средствами cgroup, и там эта проблема уже решена.
В течение последних шести лет в Яндексе идет работа над системой под кодовым называнием YT (по-русски мы называем её «Ыть»). Это основная платформа для хранения и обработки больших объемов данных — мы уже о ней рассказывали на YaC 2013. С тех пор она продолжала развиваться. Сегодня я расскажу о том, с чего началась разработка YT, что нового в ней появилось и что ещё мы планируем сделать в ближайшее время.
Кстати, 15 октября в офисе Яндекса мы расскажем не только о YT, но и о других наших инфраструктурных технологиях: Media Storage, Yandex Query Language и ClickHouse. На встрече мы раскроем тайну — расскажем, сколько же в Яндексе MapReduce-систем.
Какую задачу мы решаем?
По роду своей деятельности Яндекс постоянно сталкивается с необходимостью хранить и обрабатывать данные таких объемов, с которыми обычному пользователю никогда не приходится иметь дело. Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства. Для эффективной обработки подобных объемов традиционно используется парадигма MapReduce, позволяющая достичь хорошего баланса между эффективностью вычислений и простотой пользовательского кода.
На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.
Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.
Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?
Про что сама эта история? Это про то, как мы росли, как проект развивался, как происходило какое-то переосмысление каких-то его частей, какого-то взаимодействия. Так или иначе, это про масштабирование проекта, потому что это всё — ради того, чтобы выдержать ещё больше нагрузки, предоставить клиентам ещё больше функционала и при этом не упасть, не потерять ключевых характеристик. В общем, чтобы клиент остался доволен. Ну и немного про то, какой путь мы прошли. С чего мы начинали.
Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?
Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.
Начнём исследование вопроса с определения требований к хранению секретов.
Так вышло, что радость от приобретения нового MacBook Air 13" 2013 в топовой комплектации была сильно омрачена, мягко говоря, странной работой дисплея. Чтобы сразу было понятно, о какого рода проблеме идёт речь, вот видео (смотреть в 1080p).
В этом обзоре MacBook Air 11" 2013 года глюк виден с 1:54 до 2:24 и с 2:42 по 2:54. Есть 1080p версия. Про тормоза экрана в обзоре ни слова. Не знаю, как надо смотреть на экран, чтобы не видеть этого.
Я начал обсуждение этой проблемы в комментариях к обзору MacBook Air 2013, но потом понял, что она заслуживает отдельного поста.
При любом движении на экране, изображение размывается. Выглядит это, как очень высокое время отклика матрицы. Особенно это заметно на тонких линиях (текст, рамки) и контрастных объектах на белом фоне. При скроллинге в браузере или при перетаскивании окон за большинством элементов изображения видны хорошо различимые шлейфы, сравнимые по длине/ширине с самими объектами, их оставляющими. Текст блекнет или меняет цвет.
Проблема бросилась в глаза сразу же. У меня было достаточно разных ноутбуков, от дешёвых до дорогих, чтобы сделать вывод, что такая работа дисплея, особенно в одном из самых дорогих ноутбуков, не может считаться нормальной. На следующий день я позвонил в Apple…
Я буду рассказывать вам об инструментах высоконагруженных проектов, кэшировании, в частности, о memcached, Redis-е и о сервисе очередей RabbitMQ или в простонародье «кролике».
В первой части доклада я расскажу о том, что такое memcached — базовые понятия, что такое Redis, о его особенностях, и чем эти два сервиса отличаются. Расскажу о практическом применении в наших проектах обоих сервисов.
А во второй части я буду рассказывать о брокере сообщений RabbitMQ, об основных понятиях, которые есть в «кролике», о том, как работает маршрутизация сообщений между продюсерами и консьюмерами. Также расскажу о практическом применении в наших проектах данного брокера сообщений.
О кэшировании. Думаю, многие из вас хоть что-то кэшировали в своих веб-проектах, поэтому все будет очень просто и доступно.
Как родилась идея доклада? Я не очень люблю выступать и рассказывать про фичи, особенно про будущие фичи. Выясняется, что и люди не особо любят это слушать. Они любят слушать про то, как все устроено. Это доклад о том, как все устроено или должно быть, с моей точки зрения, устроено в современной СУБД.
Я попробую сделать так, чтобы мы смогли с макроуровня спуститься на микроуровень, т.е. каким образом, сначала отбрасывая макропроблемы, мы можем создать себе пространство для выбора на среднем уровне и микроуровне.
На макроуровне – это то, как должна быть устроена современная СУБД. Почему у нас сегодня есть возможность создавать новые базы данных, почему нельзя взять текущую и удовлетвориться ее производительностью, подтюнить или написать для нее патч? Просто взять и написать патч, который бы ее ускорил, если она медленная? Из какого пространства решений мы выбираем?
Энергии из возобновляемых источников было получено столько, что цены упали ниже нуля
8 мая, в воскресенье, Германия побила новый рекорд в генерации энергии из возобновляемых источников. Благодаря солнечной и одновременно ветреной погоде совокупное производство энергии солнечными, ветро, гидро и биоэнергостанциями составило около 55 ГВт. Всего же в стране в этот день было потреблено 63 ГВт энергии. Таким образом, доля возобновляемых источников составила около 87%. На несколько часов цены ушли в минус, что означает выплаты потребителям энергии.
В последнее время такая ситуация уже не является чем-то уникальным. По всей Европе подобные всплески производства энергии случаются все чаще. Если с 2010 по 2014 года цены уходили в минус всего несколько раз, то в прошлом году это случалось десятки раз. Проблема в том, что цены на рынке энергии в Европе формируются по типу аукциона. Производители запрашивают свою цену, а покупатели, что логично, предлагают собственные варианты. И если энергии слишком много, оптовые поставщики энергии начинают демпинговать, причем цены иногда уходят в минус, как это и случилось сейчас.
В 2014 году 2ГИС выпустил Этажи — это фича, позволяющая посмотреть схему этажей здания и найти на ней нужную организацию. Долгое время она существовала только в мобильных приложениях 2ГИС. Теперь эта возможность появилась и в онлайн-версии.
Этажи для веба сделаны на технологии WebGL: они полностью трёхмерные, их можно крутить и приближать. Это первый проект компании, сделанный на этой технологии, и мы хотели бы поделиться опытом реализации.
Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.
Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.
Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.
В этой статье: что мешает серверу перезагрузиться и как ему помочь.
Начнём с теории ребута.
При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.
Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.
