Skip to main content

Как сдать экзамен Cerified Kubernetes Administrator: личный опыт

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

Распределяем pod-ы по машинам в kubernetes

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

Restic: backup для современного мира

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

WireGuard: перспективный VPN

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

CFSS: TLS CA со скоростью молнии

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

Repmgr: управление репликацией postgresql

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

Yubikey + GPG – быстрый старт

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

Простой системы логин/пароль уже недостаточно, чтобы обеспечить надежную защиту, и даже система с ассиметричными ключами имеет уязвимости:

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

Systemd – очень быстрый старт

При работе в операционной системе нужно постоянно запускать разные программы. Следить за их состоянием. Перезапускать упавшее. Существует целый пласт утилит, который решает эту задачу (от простейшего init.d до навороченного svc). Сейчас в Linux стандартом де-факто стал systemd – его используют все современные дистрибутивы. Это – очень короткое и очень простое введение в systemd. Минимум текста – максимум пользы.

Потоковая репликация в PostgreSQL – короткое введение

PostgreSQL – великолепная база данных, во многом – лучше MySQL. При этом у PostgreSQL довольно мало документации (кроме официальной) – MySQL раньше стал популярен и сейчас элементарно чаще встречается. Руководств по настройке репликации в MySQL - полный интернет, а для PostgreSQL на русском я пошаговых инструкций просто не видел. Это – именно такая инструкция.

Duplicity – экстремально простой способ резервного копирования

Как гласит старинная шутка, системные администраторы делятся на две группы: те, которые не делают бэкапы, и те, которые уже делают бэкапы. Систем резеревного копирования существует великое множество, от простейшего самописного скрипта до огромных монстров ценой в “боинг”. Все системы нужны для разных целей и выполняют разные задачи.

Как (и зачем) перевести блог на статический сайт

Согласно статстике W3Tech 98.5% современных сайтов – это динамические сайты. Строго говоря – это программы (порой – большие и сложные программы), мощные многоэтажные системы, связаные со сложными системами хранения данных. Каждое посещение такого сайта – это выполнение кода, что требует ресурсов сервера и времени. При этом реально в большинстве случаев вся эта мощь не используется – большинство сайтов довольно компактные и редко обновляются. А значит – мощная, сложная, гибкая, многокомпонентная, что самое страшное – потенциально ненадежная система, в общем-то, не нужна.

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

Резервное копироварие mysql с помощью xtrabackup

MySQL - сверх-популярный сервер баз данных. Его используют (или использовали) практически все. Одна из самых популярных задач в системном администрировании - бэкап (и восстановление). Или, как подвид - миграция данных (бэкап + последующее восстановление). Это делают практически все. И практически все используют для mysql_dump, что категорически неправильно и часто просто опасно. В этой статье я расскажу, почему mysql_dump - это плохое решение и что с ним можно сделать.

Отслеживаем PHP с помощью PINBA на debian

PHP - исключительно популярный язык программирования, до сих пор огромное количество проектов пишется именно на нем. Язык ругают за отвратительный дизайн, неудобный синтаксис, кривое поведение в спорных случаях, отсутствие нормальных средств отладки - но его популярность это никак не снижает. Самое страшное для админа - ситуация, когда на сильно нагруженном проекте начинает тормозить код. Стандартные средства отладки (xprof, xdebug) роняют производительность языка в яму (накладные расходы - вплоть до пятикратного падения скорости), и как отлаживать сложный код на живую - совершенно неясно. Именно для борьбы с такими проблемами придумана PINBA - расширение для мониторинга скорости кода. Тут я расскажу, как установить PINBA (клиент, сервер и интерфейс) на debian и что с ними потом делать.

Миграция на mongo replica set без потери данных

По сути - это не статья, а, скорее, просто памятка, чтобы самому не забыть. MongoDB - популярный документо-ориентированный движок управления базой. Штатно он имеет две разных технологии кластеризации: репликационные наборы (replica set) и шардирование (shard). Разница проста - в случае реплики на всех узлах данные одинаковы и любой узел может выступать источником данных (внимание, mongodb не является CAP-полной базой, так что точность данных тут под большим вопросом!), что обеспечивает отказоустойчивость. В случае шардирования данные “размазаны” по всему набору шарда, но каждый сервер внутри шарда имеет только свои данные. За счет этого распределяется нагрузка (например, с трех узлов данные можно читать параллельно), но снижается надежность - упавший узел означает потерю части данных шарда. В данной статье будет описание, как переехать с единичной монги на репсет не потеряв при этом данные.

Быстрая миграция MySQL на failover cluster

MySQL - одна из самых ходовых, распространенных и простых во внедрении СУБД. Этот СУБД использует, наверное, половина всех проектов веба. Исключительная простота установки и внедрения, распространенность, поддержка “из коробки” во всех ходовых языках программирования для веб (perl, PHP, ruby, python, JS/node). Из-за мнимой простоты внедрения на потенциальные проблемы внедрения внимания просто не обращают - 90% проектов не доживут до того момента, когда заботливо разложенные авторами MySQL грабли больно ударят по лбу.

Одна из серьезных грабель MySQL - серьезные проблемы с производительностью и надежностью. Тюнинг MySQL сложен, так, как изначально MySQL задуман для быстрого внедрения в небольшом проекте. Кроме того, имея серьезный, высоконагруженный проект, хочется снизить риск отказа базы данных (согласно закону Паркинсона, все, что может сломаться - сломается, и частно - в самый неудачный момент). В данной статье я распишу, как мигрировать одиночный MySQL на кластер из трех равновесных машин (для надежности - отказ любого сервера не оставит вас без базы) с автоматическим распределением нагрузки.

Мигрируем Debian на softraid без потери данных

Современные жесткие диски - чудо инженерии и техники. Пластины из магниево-алюминиевого сплава несутся со скоростью 120 оборотов в секунду, при этом считывающую голову от поверхности диска отделяет расстояние в 1/10 толщины человеческого волоса. Сама голова перемещается в любую точку всего за 2мс, что вызывает боковую перегрузку в фантастические 550G. Современные диски обладают впечатляющим объемом, большой линейной скоростью (что на чтение, что на запись) и минимальной задержкой поиска. И платят они за это (кроме цены) серьезным падением надежности. Старенькие Seagate Barracude и Quantum Fireball 6-10 гигабайт объемом без каких-либо нареканий жили десятилетиями, еще более старинные IBM на сотни мегабайт можно было безопасно вскрыть и закрыть в домашних условиях без специальной подготовки. Современные модели крайне чувствительны к вибрациям, тряске, углу наклона, удару и даже шуму (sic!). Средний срок жизни современного террабайтника - три года, если он эксплуатируется не слишком активно. Диски для серверов и NAS живут год-два. Если раньше RAID считался дорогой экзотикой серверного мира (по типу SCSI), то сейчас программный soft-raid - абсолютная необходимость, без которого сервер просто нельзя устанавливать.

Мониторинг задержек при помощи smokeping

Как-то мне (в очередной раз) потребовалось настроить мониторинг доступности клиентского сервиса через интернет. В процессе настройки я обнаружил, что не смотря на существование очень простого, понятного и удобного инструмента под названием SmokePing, по нему практически нет документации на русском (а документация на английском очень ограничена и запрятана в странном месте). Поэтому я решил написать эту небольшую вводную статью.

Коротко о безопасности в сети или краткое руководство для практикующих параноиков

Кто-то, возможно, не поверит, но написать эту статью я собирался довольно давно. Недавние события (утечка личных фотографий звезд и 7 миллионов почтовых паролей от google и yandex) не была поводом, но подтолкнула меня к перу. Безопасности в интернете (и вообще - в ИТ) обычный пользователь уделяет на диво мало внимания, не в пример безопасности физической. Кто-то не хочет ничего делать потому, что лень, кто-то считает, что ему “как честному человеку скрывать нечего” (да-да, я встречал такой лозунг неоднократно, особенно, когда вводили цензуру в интернете на территории 1/5 части суши).

Сравнение систем мониторинга

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

Запуск ruby on rails на uwsgi на примере redmine

Для лично-рабочих нужд я активно использую task-tracking system под названием Redmine. Redmine практически всем хорош из открытых трекеров, но очень любит память. Традиционно он запускается через rails server (WEBRick) или rails-specific сервер thin. Во второй конфигурации у меня он жрал 300Мб оперативной памяти, а среднее время генерации страницы было близко к секунде, что совершенно неприемлимо. По этой причине я решил использовать uwsgi - совершенно прекрасный appserver, который я активно использую для своего творчества на python. Uwsgi работает очень быстро (действительно - очень!), достаточно экономно относится к памяти, обладает широчайшими возможностями конфигурирования - просто-таки мечта, а не сервер. До недавнего времени он умел работать только с python (под который интерфейс uWSGI, строго говоря, и создавался), но теперь умеет обрабатывать ruby и даже PHP. Минусом uwsgid является, во-первых, тот факт, что он находится на переднем крае разработок, а значит - может работать ой как своеобразно. Не менее своеобразно он настраивается, и документации по нему очень мало.