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

Начну свой рассказ фразой, которая оправдывает себя на все 100: «Если информация не сохранена в трёх местах – её не существует». Не помню, сказал это кто-то из великих или это народная поговорка, но неоднократно убеждался на своём опыте и опыте знакомых в её точности.

Рассмотрим варианты хранения от облачных сервисов до физических носителей дома в тумбочке.

Сразу обозначу о хранимых данных: не будем углубляться в сам материал хранения (для кого-то фото с таранкой из 90х важнее, чем чёрная бухгалтерия тёти Светы). Обобщим хранение важных для каждого электронных данных.

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

Это приятная проблема, но в Сети мало чёткой информации, как аккуратно масштабировать веб-приложение с нуля до сотен тысяч пользователей. Обычно встречаются или пожарные решения, или устранение узких мест (а часто и то, и другое). Поэтому люди используют довольно шаблонные приёмы по масштабированию своего любительского проекта в нечто действительно серьёзное.

Попытаемся отфильтровать информацию и записать основную формулу. Мы собираемся пошагово масштабировать наш новый сайт для обмена фотографиями Graminsta с 1 до 100 000 пользователей.

Запишем, какие конкретные действия необходимо сделать при увеличении аудитории до 10, 100, 1000, 10 000 и 100 000 человек.

Павел Селиванов, архитектор решений Southbridge и преподаватель Слёрма, выступил с докладом на DevOpsConf 2019. Этот доклад — часть одной из тем углубленного курса по Kubernetes «Слёрм Мега».

Слёрм Базовый: введение в Kubernetes проходит в Москве 18-20 ноября.
Слёрм Мега: заглядываем под капот Kubernetes — Москва, 22-24 ноября.
Слёрм Онлайн: оба курса по Kubernetes доступен всегда.

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

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

1066 год, с начала вторжения викингов в Англию прошло уже больше 200 лет. Король Гарольд, собрав отряд рыцарей выступил к реке Дервент для решающего сражения с войсками своего тёзки — норвежского конунга Харальда. Целый месяц трудились оружейники, чтобы выковать достаточное количество доспехов нового поколения, способных защитить рыцаря от удара скандинавским топором. А сколько перед этим было экспериментов и испытаний на турнирах! Но ожидание должно было себя оправдать — лёгкая, но надёжная экипировка позволяла даже в пешем строю, без больших потерь, разметать викингский хирд. И, наконец, они встретились у Стамфорд-Бриджа. Главный отряд рыцарей во главе с командиром в блестящих доспехах схлестнулся посреди моста с врагами. Да, держит удар сталь подгорных мастеров!

Медленно, но верно, викинги переходят к круговой обороне. Кажется, победа уже близко. И на поле боя, наконец-то, находят друг друга командир рыцарей и норвежский ярл.

Я на digital рынке с 2008 года, и за это время видел переход от веб-сайтов на Joomla (помните такую? ) до сегодняшнего Интернета с его mobile-first приложениями и сотнями миллионов IoT устройств, подключенных в сеть.
Атаки в Интернете также за это время неплохо развилиcь :)
Но рынок защиты от DDoS и используемые операторами технологии защиты от атак остаются все еще достаточно сильно закрытым.
Расскажу, что узнал про него, поддерживая веб-сайты и интернет-сервисы, находящиеся под непрерывными атаками несколько последних лет.


Регулярные атаки. 350k req total, 52k req legitimate

В продолжение наших статей с практическими инструкциями о том, как облегчить жизнь в повседневной работе с Kubernetes, рассказываем о двух историях из мира эксплуатации: выделении отдельных узлов под конкретные задачи и конфигурации php-fpm (или другого сервера приложений) под большие нагрузки. Как и прежде, описанные здесь решения не претендуют на идеал, а предлагаются как отправная точка для ваших конкретных случаев и почва для размышлений. Вопросы и улучшения в комментариях — приветствуются!

Прим. перев.: Эта статья продолжает цикл материалов от технического писателя из Google, работающего над документацией для Kubernetes (Andrew Chen), и директора по software engineering из SAP (Dominik Tornow). Их цель — доступно и наглядно объяснить основы организации Kubernetes. В прошлый раз мы переводили статью про high availability, а теперь речь пойдет про такое базовое понятие в Kubernetes, как pod.



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

Pods (Поды) — базовые строительные блоки Kubernetes, однако даже опытные пользователи Kubernetes не всегда могут объяснить, что же это такое.

Данная публикация предлагает лаконичную мысленную модель, которая проливает свет на определяющие характеристики pod'ов Kubernetes. Ради этой краткости пришлось опустить некоторые другие особенности Pod'ов, такие как liveness и readiness probes, разделение ресурсов (включая появившееся недавно namespace sharing — прим. перев.), работу с сетью.

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


На этот раз будут рассмотрены две темы, условно связанные одной темой: доступом пользователей к dev-окружению.

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



В основе материала — доклад-диалог Сергея Бердникова (Золотая Корона) и Артема Каличкина (ЦФТ) c октябрьской конференции DevOops 2017. Под катом — видео и текстовая расшифровка доклада.

На заре карьеры я работал в компании, которая выпускала систему управления контентом. Эта CMS помогала отделам маркетинга самостоятельно управлять сайтами, а не полагаться на разработчиков при каждом изменении. Система помогла клиентам сократить операционные расходы, а мне — научиться создавать веб-приложения.

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

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

Если вы начали работу в таком окружении, а затем приступили к созданию и развёртыванию веб-приложения с нуля, то очень быстро узнаете, что такое «до опасного поверхностные знания».

Кто-то любит ходить в кино, кто-то любит ходить в клубы, кто-то любит ходить в музеи — а я давно мечтал походить по дата-центрам, посмотреть на всё своими глазами, пообщаться с теми, кто там работает. Но организовать всё это казалось нереальным. К счастью, определённая узнаваемость, которую заработал poiskvps.ru за эти годы, и которая теперь меня, порой, удивляет — упростила самое сложное: знакомство. Так что за последние два месяца я побывал уже в двух дата-центрах. Что интересного я увидел в питерском, я ещё планирую написать позднее. А сегодня расскажу, каким увидел подмосковный ЦОД компании RUVDS в городе Королёве — их «малую родину», где с первых серверных стоек в бункере на территории ракетного завода они и стартовали. Да, это не только звучит круто, но и выглядит. Вы только посмотрите на эти гермодвери:



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

У меня есть три сервера, но я не профессиональный сисадмин. Это означает, что несмотря на четыре базы данных и стопяцот приложений, бэкапы нигде не ведутся, к любой проблеме на сервере я подхожу, шумно вздохнув и бросив тарелку в стену, а операционные системы там достигли EOL два года назад. Я бы рад обновить, но на это нужно выделить, наверное, неделю, чтобы всё забэкапить и переставить. Проще забыть про yum update и apt-get upgrade.

Конечно, это неправильно. Я давно присматривался к chef и Puppet, которые, как я думал, решат все мои проблемы. Но я смотрел на конфиги знакомых проектов и откладывал. Это же нужно изучать, разбираться с ruby, бороться с многочисленными, по отзывам, косяками и ограничениями. Две недели назад статья Георгия amarao стала животворящим пинком. Даже не сама статья, а перечисление систем управления конфигурацией. После чтения комментариев и лёгкого гугления решил: возьму Ansible. Потому что питон, и на проблемы никто не жалуется.



Что ж, тогда я первым буду.

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

Алгоритм выбора location обязателен к знанию при настройке nginx. Тем не менее, на официальном сайте nginx (на 2018 год) не сказано ни слова про алгоритм выбора в случаях, когда какие-то location'ы вложены друг в друга, а в статьях в интернете приводятся в корне неверные алгоритмы. В статье также будет дан пример уязвимого конфига.

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

Итак, у нас есть статический публичный IP адрес, который приходит Ethernet шнуром в MikroTik RouterBOARD 750G r3 (hEX). Пробуем собрать вот такую конструкцию.


Настройку L2tp линка в рамках этой статьи я не описываю, а на схеме он нарисован только потому, что в ней упоминается.

Американская компания Anchore, созданная основателем Ansible Inc., с помощью своего сервиса Anchore Navigator, предназначенного для исследования контейнерных образов, проанализировала Docker Hub и ответила на следующие вопросы:

1. Какие операционные системы используются больше всего?
2. Как выбор ОС менялся на протяжении времени?
3. Отличаются ли паттерны их использования для официальных и публичных образов?

Прошлая неделя подарила два «вкусных» релиза из Open Source-мира контейнеров: практически одновременно обновились Docker (версия 17.06) и Kubernetes (версия 1.7). Какие возможности они принесли? В статье представлена информация из анонсов и release notes этих релизов с небольшими уточнениями по некоторым из ключевых изменений.

На дворе 2017 год, а в различных статьях и, тем более, комментариях к ним то и дело приходится встречаться с мнением, что Docker — удел неопытных энтузиастов, экзотических компаний-однодневок и каких угодно экспериментов, максимально удалённых от реального production. И вот пока коллеги готовят новые технические материалы, я решил на публично доступных примерах и фактах показать, что это скорее миф и стереотип, чем мир, в котором живёт ИТ сегодня.

Масштабы и тенденции докеризации

Отправная точка для этой статьи — статистика от сервиса мониторинга Datadog, которая впервые появилась в 2015 году и в последний раз была обновлена буквально на днях, в апреле 2017 года. Datadog — это не какая-то традиционная аналитическая компания, а известная своей дружелюбностью к облачным окружениям система мониторинга (код её агента написан на Python и опубликован как Open Source).

Как наладить работу почтового сервера, умеющего принимать и отправлять электронную корреспонденцию, бороться со спамом, взаимодействовать с клиентами? На самом деле, всё довольно просто.

Сегодня поговорим о почтовых серверах на Linux. Мы расскажем о том, как настроить сервер, о широко распространённом в интернете протоколе SMTP, а также о других протоколах, таких, как POP и IMAP. В итоге вы окажетесь обладателем полноценной системы для работы с электронной почтой.



Начнём с SMTP-сервера на Linux