Серверное администрирование *

Небольшая инструкция по обновлению SSL-сертификата Let's Encrypt для почтового сервера Zimbra, написанная по причине окончания действия корневого сертификата, повлекшего несколько крайне неприятных последствий.

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

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

Наверное всем не нравится консоль для запуска ранбуков у Microsoft System Center Orchestrator. Она неудобная и тормозная. Давно вынашивал идею сделать что-то более удобное, избавиться от Silverlight и... наконец-то подвернулась возможность её реализовать.

30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let's Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а "устаревшие системы" - это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?

Хабр, привет! Меня зовут Георгий Липатов. Я — DevOps-инженер, работаю в Сбере, также сопровождаю мониторинг и бэкапы в Sber Tax Free.

Мы начали строить этот сервис в конце прошлого года — тогда наша ИТ-команда состояла из двух backend-разработчиков, DevOps-инженера и пары специалистов по frontend’у. Чтобы не терять время и проверить первые гипотезы, мы решили развернуть стенды для разработки и тестирования в облаке. Помимо решений в области информационной безопасности нам, конечно же, были необходимы удобные инструменты для развертывания, мониторинга и бэкапов. Плюс — масштабируемые ресурсы в зависимости от потребностей проекта.

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

Далее я расскажу о настройке стенда для тестового приложения в формате пошагового туториала. Всех заинтересовавшихся приглашаю под кат.

В этой статье повествуется о тестнетах и нодах, их разновидностях и важности проведения подобных активностей для развивающихся криптопроектов.

Фото Florencia Viadana, Unsplash.com

После почти пятилетних разработок протокол HTTP/3 наконец приближается к окончательному выпуску. Предыдущие итерации уже доступны как экспериментальная функция, но в 2021 году мы ждём широкого распространения протокола. Что такое HTTP/3? Зачем выпускать его так рано после HTTP/2? Как его можно или нужно использовать? Как он влияет на производительность?

Мы рады объявить дату выхода новой ОС Windows 11 — это 5 октября 2021 года. С этого дня станет доступно бесплатное обновление до Windows 11 для соответствующих требованиям ПК с Windows 10 и станут доступны для приобретения новые компьютеры с Windows 11. Новая операционная система Windows 11 создана, чтобы сделать вас ближе к тому, что вы любите.

В этой статье напомним о новинках системы и поделимся подробностями релиза.

Фото Bertrand Bouchez, Unsplash.com

В прошлой статье мы с помощью Prometheus AlertManager настроили правила, чтобы отправлять уведомления через Slack при срабатывании алертов. И хотя алерты и уведомления — это удобно и полезно, сами по себе метрики не до конца объясняют проблему. Они просто показывают, что значения одного экземпляра вышли за установленные лимиты, но в распределённых системах метрики не могут отследить запрос, который проходит через несколько компонентов. С распространением микросервисов системы усложняются, поэтому мы должны проследить весь путь запроса, чтобы понять, что пошло не так. Для этого можно использовать распределённую трассировку, которая записывает действия, выполняемые в связи с запросом, и дает контекст, который мы не найдем в метриках и логах.

В этой статье мы расширим возможности observability (наблюдаемости) приложения — создадим спаны (span) и экспортируем их в распределённую опенсорс-систему Jaeger. Но сначала разберемся, что такое трейс.

Инструкция была основана на базе видео "Установка кластера Kubernetes с помощью Kubespray" в Youtube.

Код был форкнут из репозитория https://git.cloud-team.ru/lections/kubernetes_setup и добавлен с патчами в репозиторий https://github.com/patsevanton/kubespray_terraform_yandex_cloud

Самое интересное в этом посте для devops специалистов с опытом это скрипт для создания ansible inventory файла из terraform структур.

20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.

Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер. 

Во второй части мы перенесемся на несколько месяцев вперед - в март 2013, когда докер был представлен на конференции PyCon. На тот момент он уже обладал практически всеми знакомыми нам функциями. А в третьей части я постараюсь рассмотреть переход Docker с LXC на собственную разработку, произошедший годом позже.

Несколько больших нод или много маленьких?

Управление Kubernetes-кластером - это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь - это обеспечение стабильной и отказоустойчивой работы приложений.

Как site-reliability и DevOps инженерам вам нужно иметь в виду потребности приложений, которые будут запускаться в кластере, и учитывать различные факторы при его проектировании.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших - это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Фото Ricardo Gomez Angel, Unsplash.com

Используем метрики для отправки уведомлений через Slack

В предыдущей статье мы задеплоили оператор Prometheus с помощью helm-чарта и на примере набора сервисов увидели, как можно собирать метрики через prom-client и экспортеры. Как вы помните, цель observability (наблюдаемости) — узнать статус системы, поэтому нужные люди должны получать уведомления, когда значения метрик выходят за установленные пределы. Для этого надо настроить алерты.

Сегодня речь пойдёт о новых салазках для жёстких дисков SFF формата Gen10 v2.

На первый взгляд.

На первый взгляд они идентичны, но...