В конце февраля вышла шестая версия платформы для мониторинга Grafana. В материале мы расскажем подробнее об особенностях этого релиза и новых возможностях инструмента.

Скандальные, важные и просто очень крутые материалы выходят в СМИ не каждый день, да и со 100% точностью спрогнозировать успешность той или иной статьи не возьмётся ни один редактор. Максимум, чем располагает коллектив — на уровне чутья сказать, «крепкий» материал или же «обычный». Все. Дальше начинается непредсказуемая магия СМИ, благодаря которой статья может выйти в топы поисковой выдачи с десятками ссылок от других изданий или же материал канет в Лету. И вот как раз в случае публикации крутых статей сайты СМИ периодически падают под чудовищным наплывом пользователей, который мы с вами скромно называем «хабраэффектом».

Этим летом жертвой профессионализма собственных авторов стал сайт издания Republic: статьи на тему пенсионной реформы, о школьном образовании и правильном питании в общей сложности собрали аудиторию в несколько миллионов читателей. Публикация каждого упомянутого материала приводила к настолько высоким нагрузкам, что до падения сайта Republic оставалось совсем «вот столечко». Администрация осознала, что надо что-то менять: нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.

По итогам совместного со специалистами Republic обсуждения различных вариантов реализации озвученных хотелок мы решили перевести сайт издания на Kubernetes*. О том, чего нам всем это стоило, и будет наш сегодняшний рассказ.

*В ходе переезда ни один технический специалист Republic не пострадал

Перевели для вас статью Юлиуса Минмо о настройке непрерывного развертывания (Continuous Deployment) для своего проекта. Автоматизация позволяет сэкономить кучу времени и сил. Статья будет полезна, в первую очередь, начинающим программистам.

Непрерывное развертывание — отличная штука. Один раз коммитим проект и далее все происходит в автоматическом режиме, наблюдение за этим процессом просто гипнотизирует. В этой статье я покажу, как можно все настроить для домашнего проекта.

В предыдущем посте мы масштабировали набор реплик MongoDB и познакомились со StatefulSet. Сейчас мы займемся оркестрацией кластера высокой доступности Elasticsearch (с другими мастер-нодами, нодами данных и клиентскими нодами) и задействуем ES-HQ и Kibana.

Вам понадобятся:

1. Базовое представление об Elasticsearch, его типах нод и их ролях.
2. Работающий кластер Kubernetes как минимум с тремя нодами (не меньше четырех ядер, 4 ГБ).
3. Умение работать с Kibana.

Как поднять High-Availability Kubernetes кластер и не взорвать мозг? Использовать Kubespray, конечно же.

Kubespray — это набор Ansible ролей для установки и конфигурации системы оркестрации контейнерами Kubernetes.

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

Осторожно, под катом 4 скриншота elasticsearch и 9 скриншотов prometheus!

---

В этой статье описывается возможность/идея/концепт изменения глобальных настроек на локальных серверах команд в большой инфраструктуре используя Gitlab CI и Ansible.

Допустим у вас имеются 20 команд разработчиков и 1 команда админов/DevOps. Как менять на всех серверах пароли админов? Как добавить корневой сертификат Предприятия на все сервера? И т.д.

В этой статье речь пойдет о балансировке нагрузки в веб-проектах. Многие считают, что решение этой задачи в распределении нагрузки между серверами — чем точнее, тем лучше. Но мы же знаем, что это не совсем так. Стабильность работы системы куда важнее с точки зрения бизнеса.



Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).


Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6

Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).

Доброго времени суток. Очередная заметка из моего опыта. В этот раз поверхностно о базовой инфраструктуре, которую использую, если надо что-то выгрузить, а рядом нет devOps ребят. Но текущий уровень абстракции, в технологиях, позволяет уже около года жить с этой инфраструктурой, поднятой за ночь, используя интернет и готовые вещи.

Ключевые слова — AWS + Terraform + kops . Если это полезно мне — возможно будет полезно кому-нибудь еще. Добро пожаловать в комментарии.

Про обновление систем «на лету» без их остановки (zero-downtime deployment) написано немало статей и многие аспекты этого подхода является достаточно очевидными. На мой взгляд, наиболее сложная часть деплоймента в этом случае — обновление хранилищ данных, в случае если их контракт (схема) изменился. Именно этот аспект я бы и хотел рассмотреть в этой статье.

Про Helm и работу с ним «в общем» мы рассказали в прошлой статье. Теперь подойдём к практике с другой стороны — с точки зрения создателя чартов (т.е. пакетов для Helm). И хотя эта статья пришла из мира эксплуатации, она получилась больше похожей на материалы о языках программирования — такова уж участь авторов чартов. Итак, чарт — это набор файлов…

Компьютеры – это «железо». И сегодня мы вернулись в исходную точку, в том смысле, что сейчас редко найдешь физический хост, на котором выполняется одна единственная задача. Даже если на сервере крутится только одно приложение, оно, скорее всего, состоит из нескольких процессов, контейнеров или даже виртуальных машин (ВМ), и все они работают на одном сервере. Red Hat Enterprise Linux 7 неплохо справляется с распределением системных ресурсов в таких ситуациях, но по умолчанию ведет себя как добрая бабушка, угощающая внуков домашним пирогом и приговаривающая: «Всем поровну, всем поровну».



В теории принцип «всем поровну», конечно, прекрасен, но на практике некоторые процессы, контейнеры или ВМ оказываются важнее других, и, следовательно, должны получать больше.

Когда мы были детьми, мы многого не понимали, что на данный момент является абсолютно очевидным. "Почему я не могу есть одни конфеты? Почему бутерброды — не еда, я же это ем? Почему я не могу спать с хомяком? Зачем чистить зубы каждый день, да еще целых два раза?!" Действительно, зачем? Но будучи взрослыми, зрелыми людьми, мы не задаемся подобными вопросами.

Похожая ситуация происходит и в мире IT (возможно, это касается любой профессиональной деятельности). Многих вещей на начальных стадиях мы можем не понимать. "Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress? Зачем тратить время на автоматическое тестирование, если и так все работает? Git? Linux? SOLID, DRY, DDD, TDD? Что за страшные слова?". Новичкам сложно понять, зачем нужно так много всего. Осознание приходит со временем и вскоре такие вещи становятся не только понятными, но и очевидными.

Хочу рассказать свою историю того, как я дорос до Docker и что этому поспособствовало.

Предистория

Одним прекрасным днём мне понадобилось развернуть среду разработки для своего проекта. Vagrant уже порядком поднадоел и хотелось иметь единую среду разработки для всех участников проекта которая была бы идентичной production серверу. Соответственно наслушавшись информации про хипстерский docker, я решил начать с ним разбираться. Далее я постараюсь максимально подробно описать все шаги начиная от установки докера на локалке вплоть до разворачивания продуктива на KVM.

Исходный стек технологий:

— Docker
— Symfony 4
— nginx
— php-fpm
— postgresql
— elasticsearch
— rabbitmq
— jenkins

Железо:

— ноутбук под ОС Ubuntu 16.04
— продакшн сервер на хостинге KVM

Почему кроме технологического стека я перечислил ещё и стек железа?

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

Первый и наверно самый важный аспект при начале работы с докером — это операционная система вашего ноутбука. Проще всего работать с докером именно на linux системах. Если вы работаете на Windows или Mac то у вас 100 % будут некоторые сложности, но эти сложности не будут являться критическими и при желании «нагуглить» как это исправляется не составит никаких проблем.

Второй вопрос — это хостинг. Зачем нужен Hosting именно с типом виртуализации KVM? Причина в том, что виртуализация VPS разительно отличается от KVM и установить сам docker на VPS у вас попросту не выйдет, так как VPS распределяет ресурсы сервера динамически.

Подитог: для самого быстрого старта на докере резоннее всего выбирать Ubuntu в качестве локальной операционки и KVM хостинг (либо собственный сервер). Далее рассказ пойдёт опираясь именно на эти две составляющие.

Email маркетинг все чаще используют компании для эффективного продвижения. Но без хорошей доставляемости писем добиться результативности email рассылки будет сложно.

По статистике 21 % email рассылок коммерческого назначения не доходят до адресатов. Это значит, что каждое пятое отправленное письмо блокируется почтовым сервисом или теряется из-за несуществующих адресов и переполненных ящиков пользователей.

Если при создании Linux-инстанса в AWS не была создана пара ключей (KeyPair) для доступа к нему через SSH либо они утеряны, то необходимо совершить ряд операций для получения доступа к машине. К уже запущенному инстансу добавить ключи через консоль AWS невозможно. Существует три способа, с помощью которых мы сможем восстановить доступ по SSH к инстансу.

Самый простой способ — настройка ключа с использованием механизма cloud-init (спасибо за подсказку yusman). Но он не работает если права на директорию /home повреждены или дистрибутив не поддерживает директивы cloud-init.

Второй способ — создание образа (Amazon Machine Image) с существующего инстанса и последующий запуск нового инстанса на его основе, но с созданием ключа. Таким образом фактически будет клонирована существующая машина с той лишь разницей, что на последнем этапе возможно создать новые ключи. Создание образа может занять длительное время для инстанса с дисками большого объема, и вам придется настраивать все сервисы, завязанные на эту машину заново. Поэтому данный способ в большинстве случаев займет больше времени.

В официальной документации от Amazon описывается и другой способ. Он позволяет восстановить доступ и свести к минимуму издержки на перенастройку сервисов (по сравнению со вторым способом), которые завязаны на инстанс, к которому потерян доступ. В статье дается его пошаговое описание.

По статистике, около 33% компаний попадают под DDoS-атаки. Предсказать атаку невозможно, а некоторые из них могут быть действительно мощными и достигать 300-500 Гб/с. Для того чтобы обезопасить себя от DDoS-атак можно воспользоваться услугами специализированных сервисов. Не все владельцы сайтов знают, куда бежать, если попал под атаку — так что я решил собрать несколько вариантов в одном топике.

Примечание: при подготовке к посту использовались англоязычные материалы и публикации на Хабре

В компании нашу команду по противостоянию DDoS-атакам называют «отбрасыватели пакетов» (the packet droppers — прим. пер). Пока все остальные команды делают клёвые штуки с проходящим через нашу сеть трафиком, мы развлекаемся поиском новых способом избавиться от него.


Фотография: Brian Evans, CC BY-SA 2.0

Умение быстро отбрасывать пакеты очень важно в противостоянии DDoS-атакам.

Отбрасывание пакетов, достигающих наших серверов, может быть выполнено на нескольких уровнях. Каждый способ имеет свои плюсы и минусы. Под катом мы рассмотрим всё, что мы опробовали.

Сегодня расскажем, как переводили на микросервисы монолитное решение. Через наше приложение круглосуточно проходит от 20 до 120 тысяч транзакций в сутки. Пользователи работают в 12 часовых поясах. В то же время функционал добавлялся много и часто, что довольно сложно делать на монолите. Вот почему системе требовались устойчивая работа в режиме 24/7, то есть HighLoad, High Availability и Fault Tolerance.

Мы развиваем этот продукт по модели MVP. Архитектура менялась в несколько этапов вслед за требованиями бизнеса. Первоначально не было возможности сделать всё и сразу, потому что никто не знал, как должно выглядеть решение. Мы двигались по модели Agile, итерациями добавляя и расширяя функциональность.

Прим. перев.: Этой статьёй мы открываем цикл публикаций про пакетный менеджер для Kubernetes, который активно используем в повседневной работе, — Helm. Оригинальным автором материала является Matt Butcher — один из основателей проекта Helm, работающий над Open Source-проектами в Microsoft и написавший 8 технических книг (в частности, «Go in Practice»). Однако статья дополнена нашими (местами — обширными) комментариями, а в скором времени будет ещё больше расширена новыми заметками по Helm более практической направленности. ОБНОВЛЕНИЕ (03.09.2018): вышло продолжение — «Практическое знакомство с пакетным менеджером для Kubernetes — Helm».



В июне Helm перешёл из статуса ведущего проекта Kubernetes в фонд Cloud Native Computing Foundation (CNCF). CNCF становится родительской организацией для лучших в своём роде cloud native-инструментов с открытым исходным кодом. Поэтому большая честь для Helm стать частью такого фонда. И наш первый значимый проект под покровительством CNCF по-настоящему масштабный: мы создаём Helm 3.