SRE-инженер — стажер

Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health.

Мне предстояло неделю всюду следовать за SRE-инженером. То есть я присутствовал на передаче дежурства, наблюдал за теми же каналами оповещений и реагировал на инциденты, если и когда таковые имели место.

Мы становимся тем, что мы лицезреем. Сначала мы формируем инструменты, потом инструменты формируют нас.

—Маршал Маклюэн

Хотелось бы искренне поблагодарить и выразить признательность моему хорошему другу Рикардо Суэйрасу за его обзор, вклад и за то, что не давал мне бросить эту статью недописанной. Рикардо, ты просто легенда!

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

Сегодня мы с огромной радостью представляем доклад Sysdig об использовании контейнеров за 2019 год (Sysdig 2019 Container Usage Report). Kubernetes продолжает набирать обороты, активнее осваиваются облачные архитектуры, и все это меняет не просто паттерны использования, но и процессы и организационные структуры. Удивительно, но в этом году двукратно увеличилось число контейнеров, срок жизни которых не превышает 5 минут. Чем динамичнее становятся сервисы, тем лучше облачные команды сознают необходимость интеграции безопасности в процессы DevOps. В рамках доклада об использовании за 2019 год мы впервые исследуем детали безопасности и соответствия — в дополнение к ряду деталей о том, как клиенты используют контейнеры, Kubernetes и проч.

Говорят, что лучший пароль — тот, который не надо запоминать. В случае с MySQL это реально благодаря плагину auth_socket и его версии для MariaDB — unix_socket.

Оба эти плагина — вовсе не новы, о них много говорилось в этом же блоге, например в статье о том, как изменять пароли в MySQL 5.7, используя плагин auth_socket. Однако, разбирая, что новенького в MariaDB 10.4, я обнаружил, что unix_socket теперь устанавливается по умолчанию и является одним из методов аутентификации ("одним из", потому как в MariaDB 10.4 одному пользователю для аутентификации доступно больше одного плагина, что и объяснятется в документе "Аутентификация" от MariaDB 10.04).

Моя основная работа — это, по большей части, развертывание систем ПО, то есть уйму времени я трачу, пытаясь ответить на такие вот вопросы:

• У разработчика это ПО работает, а у меня нет. Почему?
• Вчера это ПО у меня работало, а сегодня нет. Почему?

Это — своего рода отладка, которая немного отличается от обычной отладки ПО. Обычная отладка — это про логику кода, а вот отладка развертывания — это про взаимодействие кода и среды. Даже если корень проблемы — логическая ошибка, тот факт, что на одной машине все работает, а на другой — нет, означает, что дело неким образом в среде.

Поэтому вместо обычных инструментов для отладки вроде gdb у меня есть другой набор инструментов для отладки развертывания. И мой любимый инструмент для борьбы с проблемой типа "Почему это ПО у меня не пашет?" называется strace.

Эта статья из серии, посвященной ликбезу в области космических технологий.

Starlink — план SpaceX раздавать интернет через десятки тысяч спутников — главная тема в посвященной космосу прессе. Еженедельно выходят статьи о последних достижениях. Если в общем-то схема ясная, да ознакомившись с отчетами в Федеральной комиссии связи, хорошо мотивированный человек (скажем, ваш покорный слуга) может накопать очень много деталей. Тем не менее с этой новой технологией по-прежнему связано много заблуждений, даже у просвещенных обозревателей. Нередко попадаются статьи, в которых Starlink сравнивают с OneWeb и Kuiper (среди прочих) так, будто они конкурируют на равных. Другие авторы, явно озабоченные благом планеты, вопиют о космическом мусоре, космическом праве, стандартах и безопасности астрономии. Надеюсь, что дочитав эту — довольно длинную — статью, читатель лучше поймет и проникнется идеей Starlink.

Представлять инфраструктуру в виде кода в повторяемом текстовом формате — простая лучшая практика для систем, с которой не нужно мышевозить. За этой практикой закрепилось название — Infrastructure as Code, и пока что для ее осуществления, особенно в AWS, есть два популярных инструмента: Terraform и CloudFormation.

Сравниваю опыт работы с Terraform и CloudFormation

До прихода в Twitch (он же Amazon Jr.) я трудился в одном стартапе и года три использовал Terraform. На новом месте я тоже вовсю использовал Terraform, а потом компания продавила переход на все а-ля Amazon, включая CloudFormation. Я усердно разрабатывал лучшие практики и для того, и для другого, и оба инструмента использовал в очень сложных рабочих процессах в масштабах организации. Позднее, вдумчиво взвесив последствия перехода с Terraform на CloudFormation, я убедился, что Terraform, наверное, — лучший выбор для организации.

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

В GitLab 12.4 появилось несколько улучшений в сфере управления, включая Audit API, утверждение от владельца кода для защищенных веток и контроль доступа для Pages. Зависимости мердж-реквестов помогают управлять работой в командах, а другие замечательные фичи позволяют работать эффективнее и быстрее поставлять ПО лучшего качества.

Зависимости мердж-реквестов

GitLab улучшает прозрачность, совместную работу и продуктивность. Когда разработчики вместе работают над большим проектом, небольшие изменения часто нужно применять в определенной последовательности. Чтобы упросить эту задачу, функция зависимости мердж-реквестов позволяет определять зависимости в мердж-реквестах, чтобы изменения не поступали в хаотичном порядке и можно было видеть все зависимости во время ревью кода. Эта фича была представлена как зависимости мердж-реквестов между проектами в релизе 12.2, но теперь переименована в зависимости мердж-реквестов и поддерживает больше типов зависимостей. Сюда входят зависимости мердж-реквестов как между проектами, так и в одном проекте.

Мы понимаем, как важно всем управлять. Вот несколько улучшений в релизе 12.4, с которыми управление станет проще.

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

Я посмотрел, как эти компании вычисляют показатели безопасности других компаний. Оказалось, они смотрят на сочетание использования НТТР-заголовка для безопасности и репутации IP-адресов.

Репутация IP-адреса основывается на данных черных списков и списков спамеров в сочетании с данными о владельце общедоступного IP-адреса. Она, в принципе, должна быть чистой, если ваша компания не рассылает спам и в состоянии быстро определить и остановить вредоносное внедрение. Использование заголовка безопасности НТТР вычисляется аналогично тому, как работает Observatory от Mozilla.

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

В предстоящем выпуске Red Hat Ansible Engine 2.9 вас ждут впечатляющие улучшения, и некоторые из них описаны в этой статье. Как обычно, мы разрабатывали улучшения Ansible Network в открытую, при поддержке сообщества. Присоединяйтесь — загляните на доску задач на GitHub и изучите план развития для выпуска Red Hat Ansible Engine 2.9 на странице wiki для Ansible Network.

Как мы недавно объявили, Red Hat Ansible Automation Platform теперь включает Ansible Tower, Ansible Engine и весь контент Ansible Network. Сейчас большинство популярных сетевых платформ реализуется через модули Ansible. Например:

• Arista EOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

Полный список платформ, которые полностью поддерживаются Red Hat через подписку Ansible Automation, опубликован здесь.

Как наша команда Delivery, используя только собственные ресурсы, переделала нашу систему под CI/CD.

Команды инженеров постоянно испытывают давление: нужно выдавать новые функции в виде достойного продукта и при этом постоянно минимизировать время цикла. Зачастую специалисты не думая хватаются за современный инструментарий. Непрерывная интеграция и поставка (CI/CD) встроены в GitLab, наше единственное приложение для жизненного цикла DevOps, и сейчас мы, чтобы еще больше сократить время цикла, всем составом мигрируем на Kubernetes. Однако к CI/CD — и в конечном итоге Kubernetes — мы шли не совсем обычным путем. Команда Delivery, переводя нас на непрерывную поставку GitLab.com, напрягла старую систему, и только потом мы полностью перешли на Kubernetes.

Многие сетевые приложения состоят из веб-сервера, обрабатывающего трафик в реальном времени, и дополнительного обработчика, запускаемого в фоне асинхронно. Есть множество отличных советов по проверке состояния трафика да и сообщество не перестает разрабатывать инструменты вроде Prometheus, которые помогают в оценке. Но обработчики порой не менее – а то и более – важны. Им также нужны внимание и оценка, однако руководства по тому, как осуществлять это, избегая распространенных подводных камней, мало.

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

Мы увидим, как использовать метрики таким образом, чтобы обеспечить точную оценку, а в заключении покажем эталонную реализацию prometheus-client-tracer с открытым исходным кодом, который и вы можете применить в своих приложениях.

[отсылка к американской детской сказке "Маленький паровозик, который верил в себя " ("The Little Engine That Could") — прим. пер.]*

Как автомагически создавать крохотные docker-образы для своих нужд

Необычная одержимость

Последние пару месяцев я был одержим навязчивой идеей: насколько можно уменьшить образ Docker, так чтобы при этом приложение работало?

Понимаю, идея странная.

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

Почему размер имеет значение

Сокращая содержимое образа Docker, мы тем самым сокращаем список уязвимостей. Дополнительно мы делаем образы чище, ведь они содержат только то, что нужно для запуска приложений.

Релиз GitLab 12.3 этого месяца особенно интересен после содержательной недели, на которой мы провели первую конференцию пользователей GitLab в Бруклине, штат Нью-Йорк, и объявили о завершении этапа финансирования серии E: собрали 268 млн долларов. На эти деньги мы сможем значительно улучшить все наши предложения для DevOps, включая мониторинг, безопасность и планирование.

Istio — это удобный инструмент для соединения, защиты и мониторинга распределенных приложений. В Istio используются разные технологии для масштабного запуска ПО и управления им, включая контейнеры для упаковки кода приложения и зависимостей для развертывания и Kubernetes — для управления этими контейнерами. Поэтому для работы с Istio вы должны знать, как приложение с несколькими сервисами на основе этих технологий работает без Istio. Если эти инструменты и понятия вам уже знакомы, смело пропускайте это руководство и переходите прямо к разделу Установка Istio на Google Kubernetes Engine (GKE) или установке расширения Istio on GKE.

Это пошаговое руководство, где мы рассмотрим весь процесс от исходного кода до контейнера на GKE, чтобы вы получили базовое представление об этих технологиях на примере. Также вы увидите, как Istio использует возможности этих технологий. Предполагается, что вы не знаете ничего о контейнерах, Kubernetes, service mesh или Istio.

И снова ERROR 1040…

Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

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

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

Случай первый

Суббота, 15 июня 2019 г., 17:12

Я в общих чертах расскажу о перекрестной репликации между PostgreSQL и MySQL, а еще о методах настройки перекрестной репликации между этими двумя серверами базы данных. Обычно базы данных в перекрестной репликации называются однородными, и это удобный метод перехода с одного сервера реляционной СУБД на другой.

Базы данных PostgreSQL и MySQL принято считать реляционными, но с дополнительными расширениями они предлагают возможности NoSQL. Здесь мы обсудим репликацию между PostgreSQL и MySQL, с точки зрения реляционных СУБД.

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

TL;DR

• Чтобы добиться высокой наблюдаемости контейнеров и микросервисов, журналов и первичных метрик мало.
• Для более быстрого восстановления и повышения отказоустойчивости приложения должны применять Принцип высокой наблюдаемости (HOP, High Observability Principle).
• На уровне приложение для НОР требуется: должное журналирование, тщательный мониторинг, проверки работоспособности и трассировки производительности/переходов.
• В качестве элемента НОР используйте проверки readinessProbe и livenessProbe Kubernetes.