Инфраструктурный блог

Мы, инженеры в ИТ (админы, программисты и тысячи других профессий) работаем со сложными системами. Наши системы росли десятилетия. Умнейшие инженеры планеты наслаивали абстракции, упрощали себе и своим коллегам жизнь, искали различные способы улучшить производительность и надежность. Описание одного только ядра одной операционной системы Linux - это кирпич в 500 страниц убийственно сложного текста, который невозможно читать иначе как по паре страниц за заход. Это я про Linux Kernel Developement сейчас говорю, но вообще он там не один такой - таких книг целая полка и остальные не проще. Описание сетевого стека UNIX еще хуже, там почти тысяча страниц. Если кому-то кажется, что юниксоидов обижают и у пользователей Microsoft жизнь много проще – вас ждет Windows Internals от Соломона и Руссиновича, она тоже порядка 600 страниц, да и внутренний мир windows описывает ограничено, ибо коммерческая тайна. Традиционно ИТ – это много вдумчивого и внимательного чтения гигантских объемов текста. Системы, с которыми мы работаем по сложности напоминают космический корабль – миллион различных ручек, и каждая нужна для чего-то. А неправильная ручка гарантированно приведет к катастрофе. Кажется, что сложность – неотъемлемая часть нашей работы. Как не может быть света без тени, так и не может быть ИТ без сложных, непонятных, опасных в неумелых руках систем. Я жил с этой идеей 20 лет своей карьеры.

Я был неправ.

Контейнеры (и в частности docker) сейчас практически основа современной доставки ПО в инфраструктуру. Если верить опросам Docker (он предвзят, но я не нашел цифр лучше) – 92% разработчиков использует контейнеры в той или иной форме. Контейнеры невероятно удобны – это герметичные образы, которые все свое возят с собой. Их не нужно устанавливать и почти не нужно настраивать, у них нет зависимостей (и проблем с конфликтами зависимостей). Выгрузка таких контейнеров в любую инфраструктуру элементарна, скачал и запустил. Контейнер иммутабелен, у него нет своего состояния и потому не бывает проблем, связанных с потерей состояния. Контейнер изолирован – все, что живет внутри – живет внутри. Не бывает конфликта PID/имен процессов/блокировок в файловой системе/сокетов или портов. Контейнеру можно ограничить ресурсы на уровне ОС и он никогда за пределы этих ресурсов не выйдет. Это делает управление ресурсами в общем делом тривиальным – контейнеры можно паковать в сервер как коробки в кладовку, выбирая профиль нагрузки и under/overcommitement по своему вкусу. Накладные расходы на контейнер минимальны и почти незаметны, с точки зрения операционной системы контейнер – это просто процесс и немного магии ядра для ограничения ресурсов. Контейнер стартует так же быстро, как обычный процесс (ведь по сути это и есть процесс). Контейнер безопасен – процесс, живущий внутри, наружу выберется только через явно разрешенные интерфейсы – сетевые или файловую систему. Или нет?

Terraform – самый популярный фреймворк для управления инфраструктурой как код. Я не нашел нормальной статистики распространенности terraform в сети, самое близкое – отчет от 6Sense показывает рыночную долю Terraform как 37% (и это без учета OpenTofu и ближайший конкурент там Ansible, так что сравнение спорное). В любом случае – превосходство Terraform на рынке IaC подавляющее. Почти всегда если у вас есть облако любого рода – у вас будет Terraform в той или иной форме.

Должен признаться – я люблю книги. Сейчас это не модно, потому, что книги отнимают очень много времени для прочтения, а результативность под вопросом. Ту же самую информацию можно получить в Google за 5 минут поиска. Тем не менее я считаю пользу книг сильно недооцененной. Поиск в Google дает ответ на очень узкий конкретный вопрос (и ответ, часто, не оптимальный, а может и вовсе неверный). Хорошая, качественная книга дает обзор проблемы с разных точек зрения и показывает, как части связываются в единое целое.

В этой статье я собрал лучшие (на мой взгляд) книги для хорошего инфраструктурного инженера (cloud engineer, system administrator, devops, site reliability engineer, как вам больше нравится). Топ получился больше, чем я планировал, потому он разделен на 2 части. В первой части будут книги по техническим знаниям, во второй - по нетехническим, но все равно важным. Я специально отсортировал книги по алфавиту по имени автора, чтобы снизить предвзятость своей оценки.

Должен добавить, что я верю в эффект Линди и потому не удивляйтесь, что здесь есть сравнительно не новые книги. Шанс того, что не прошедшая испытание временем книга окажется хорошей, по моему мнению - невысок.

Экзамен Kubernetes Certified Administrator (CKA) по праву считается самым сложным из “базовых”. Интернет буквально заполнен жалобами людей, которые заплатили 400$ за попытку и не смогли его сдать. Linux Foundation предлагает одну дополнительную попытку и тестовый вариант экзамена (аж 3 тестовых сессии). Это не помогает все равно - LFS сначала сделали упрощенный вариант CKAD (Certified Kubernetes Application Developer), а потом - еще более упрощенный CKAN. Я этот экзамен сдал. С первой попытки и на 86% (то есть я сделал одну ошибку в одном сложном вопросе). Вся подготовка заняла пол-года (на момент старта знания у меня были только теоретические). В этой статье я расскажу, как я готовился, зачем это вообще надо и на что обращать внимание.

Kubernetes иногда называют “операционной системой для дата-центров” – и в этом есть логика. K8s позволяет представить группу серверов (условный ЦОД) как единое вычислительное пространство. Оператор просто бросает задания в K8s, а тот сам выбирает, где тот или иной контейнер лучше разместить. Чаще всего делает это он хорошо. Но иногда появляется необходимость как-то управлять этим процессом. Об этом я и расскажу.

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

VPN придуман давно (IPSec - в 1998 году, например) и имеет множество областей применения - безопасный доступ для удаленных сотрудников, прозрачное объединение корпоративных сетей, безопасный доступ в интернет поверх небезопасных каналов, даже - уклонение от корпоративной и государственной цензуры. Протоколов VPN - целый выводок, а реализации (программы, ПАК, даже чистые аппаратные решения без ПО есть) - еще больше. При этом каждый каждый стандарт имеет свои недостатки. WireGuard - это очередной протокол VPN, попытка эти проблемы решить. При всех плюсах WG (про них - ниже) - он мало известен и на удивление плохо документирован. Эта статья - попытка устранить эти недостатки.

TLS - один из самых распространенных стандартов шифрования и аутентификации в современном интернете. Используется исключительно широко - взаимодействие с пользователем (HTTPS), межпрограммное общение (RPC over HTTPS, gRPC), даже VPN (OpenVPN) и телефония (SIPoTLS). Он обеспечивает шифрование (симметричным ключом), авторизацию (PKI), проверку целостности переданной информации (HMAC). Важная часть TLS - PKI (инфраструктура публичных ключей). Любой публичный ключ в TLS должен быть подписан (публичный ключ с подписью и набором определенных атрибутов называется сертификатом). Центр сертификации – критически важная часть работы TLS, так как он управляет доверием к приложению или сервису (цепочки доверия). В этой статье я расскажу о том, как запустить свой собственный CA на основе CFSSL. Введение получилось неожиданно большим, так что если вам нужна практика - вам сюда

PostgreSQL - это мощная и очень развитая база данных, функциональная и дружелюбная. В комплект входит надежный и очень удобный механизм потоковой репликации (я писал о нем здесь). Не смотря на мощь и удобство – этот инструмент сложен в настройке и не всегда понятен, особенно, если серверов баз много. Все становится еще хуже, если у вас сложная схема репликации с каскадами (master > slave > slave of slave). Чтобы облегчить жизнь DBA в таких ситуациях – известные специалисты по консалтингу Postgres, компания 2ndQuadrant придумали repmgr – специальный инструмент для управления настройками репликации для PostgreSQL.