Слава Богу, что мы этот путь уже прошли

Василий Кечин, глава отдела разработки, рассказывает о формировании отдела и рабочих процессов.

Когда задач мало, бардак не сильно мешает.

10 лет назад была хрестоматийная ситуация: в компании работало несколько разрозненных программистов, мы поодиночке решали ситуативные вопросы. За наши ресурсы шла война, задачи не фиксировались, выполнять их нужно было быстро и, желательно, вчера. Когда у бизнеса назрела потребность в централизованном управлении разработкой, мне предложили сформировать отдел и навести порядок. Я начал с регулирования потока входящих задач, стандартизировал формат их постановки. Понемногу собралась команда на стеке Node.js. Мы сидели впятером в маленькой комнатушке — и этого было достаточно для развертывания OpenStack и старта работ по Консоли.

Мы изначально решили, что код должен быть добротным.

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

Мы потратили время, чтобы внедрить стандарты написания кода.

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

Без тестов было страшно.

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

Когда ресурс ограничен, нет тех, кто просиживает штаны.

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

#обновления в Консоли PS Cloud Services

Полезные новости для тех наших клиентов, кто пользуется админ-панелью console.ps.kz. Ниже список обновлений с начала года.

1. Управление аккаунтом

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

Напоминаем, что у каждого пользователя Консоли есть возможность создавать неограниченное количество аккаунтов для совершения операций от имени физических и юридических лиц. Также пользователь может назначать роли другим пользователям: предоставлять им разные права доступа к его аккаунтам для выполнения профильных задач (администрирование, бухгалтерия).

***

Вы просили — мы сделали: в карточке аккаунта количество зарегистрированных доменов вынесено из общего количества приобретенных услуг и теперь отображается отдельно.

2. Коммуникации

Запустили раздел «Новости», он доступен в боковом меню. В этом разделе мы информируем пользователей об изменениях в услугах, планировании и проведении технических работ, скидках и акциях. Не забывайте заглядывать — там только польза и свобода от рекламного спама.

***

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

3. Продукты и услуги

В разделе «Услуги дата-центра» на промо-странице услуги «IP-адреса» упростили форму подачи заявки в отдел продаж.

***

В разделе «Безопасность» добавили альфа-версию пользовательской панели управления услугой «Security Operations Center (SOC / ОЦИБ)», где отображаются источники событий и инциденты кибербезопасности.

4. Оформление документов

В форме заполнения реквизитов аккаунта было добавлено дополнительное поле «ID налогоплательщика» для нерезидентов РК и зарубежных компаний.

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

Дата: 15 марта, 9:20 (GMT +05:00)

Офлайн: Алматы, InterContinental, ул. Желтоксан, 181

Онлайн: на YouTube канале Profit Kazakhstan

Для офлайн-участия в конференции регистрируйтесь по ссылке https://profitday.kz/cloud

Profit Cloud Day пройден

На конференции Profit Cloud day мы показали панель управления, раздали подарки, послушали саксофон и выяснили, что у людей по-прежнему много вопросов об устройстве облаков. И это хорошо, будем рассказывать дальше.

Тех из вас, кто не смог присоединиться к нам в пятницу, приглашаем пересмотреть конференцию на YouTube:

— панельная дискуссия с участием нашего CEO, Никиты Красулина;
— презентация панели управления облачными услугами от Василия Кечина;
— полная запись конференции от организаторов.

Всем спасибо, друзья! До следующих встреч.

O'zbekistonga xush kelibsiz!

Добро пожаловать в Узбекистан!

Мы рады сообщить, что наша компания начала оказывать услуги в Узбекистане. В новом регионе мы обеспечиваем привычный для казахстанских клиентов высокий уровень сервиса. Предлагаем удобный интерфейс управления услугами.

Наши услуги:

— Облачные серверы;
— Облачные VPS;
— Хостинг сайтов;
— Конструктор сайтов;
— Регистрация доменов в зоне .UZ (официальный регистратор).

По услугам Colocation и Dedicated мы предлагаем индивидуальные решения для каждого клиента.

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

Оплата принимается в узбекских сумах, платежными картами или банковским переводом.

Техническую поддержку клиентов оказывают наши специалисты, готовые помочь в любое время 24/7.

Контакты:

Узбекистан: +998-55-520-20-30
Казахстан: +7-727-388-82-31.
Почта: info@pscloud.uz

В прошлом году наша компания отметила двадцатилетие на рынке Казахстана. Юбилей совпал с нашим решением расширить присутствие на рынок Республики Узбекистан. При учете динамичного развития цифровой инфраструктуры соседней страны мы создали необходимую инфраструктуру в Ташкенте летом 2023 г. Осенью начали предоставлять услуги: пользуется спросом облако, растут регистрации доменов в зоне .UZ

Будьте в курсе новостей и делитесь этой информацией.

📢 Новые видео на нашем YouTube канале! 🎥

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

🎬 В первом видео вы узнаете, как эффективно управлять доступами к вашим доменам и сайтам в панели управления Plesk. Мы подробно описали все этапы настройки, чтобы вы могли легко освоить этот процесс.

🔗 Ссылка на видео: Как настроить доступы на хостинге сайтов

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

🔗 Ссылка на видео: Как настроить резервное копирование на хостинге сайтов

Повышайте надежность вашего веб-пространства с нашими видеоуроками! Подписывайтесь на наш YouTube канал. 🚀👨‍💻

Новая услуга «DDoS Secure» против разных типов DDoS-атак

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

1. Прямые объемные атаки.

‣ High packet rate. Генерация большого количества пакетов за короткий промежуток времени.
‣ Small packet size or large packet size. Использование очень маленьких или очень больших пакетов для нарушения обработки трафика сетевыми устройствами или переполнения канала связи.
‣ L3/L4 UDP attacks. Отправка большого количества UDP-пакетов для перегрузки целевого сервера, так как UDP не требует установления соединения.
‣ ICMP (including echo request, echo reply, unreachable). Запросы ICMP, например, ping, вынуждают цель отвечать на массовые запросы.
‣ L2/L3 floods (IGMP, SSDP, CHARGEN, QOTD, BT, Kad). Перегрузка сети путем генерации множественных пакетов с использованием различных протоколов сетевого уровня.

2. Сложные атаки на протоколы и манипуляции с пакетами.

‣ L3/L4 TCP attacks (SYN, FIN, ACK, RST, invalid flag combinations). Эксплуатация TCP-протокола, например, создание фиктивных сессий (SYN flood) или неправильное использование флагов для сбоя обработки пакетов.
‣ Attacks involving fragmented packets, truncated or malformed packets. Отправка не полностью сформированных или некорректных пакетов для вызова ошибок и перегрузки в системе обработки данных.
‣ Fragmented packet floods (Frag. UDP Flood, Frag. TCP ACK flood, Frag. ICMP Flood). Перегрузка сети путем генерации фрагментированных пакетов, что заставляет цель тратить ресурсы на их пересборку и обработку.
‣ IP spoofing attacks. Подделка IP-адресов отправителя для обмана целевой системы или скрытия истинного источника атаки.
‣ Amplification attacks (DNS NTP, SNMP, LDAP). Использование уязвимостей в протоколах для многократного усиления объема атакующих данных.

(продолжение следует)

(продолжение)

3. Распределенные сетевые атаки.

‣ Fan-in (many IPs to one IP). Множество источников атакует и перегружает одну цель.
‣ Fan-out (one IP to many IPs). Один источник направляет трафик на множество целей для разведки уязвимостей или создания отвлекающего маневра
‣ Swarms (many IPs to many IPs). Скоординированная атака множества источников по множеству целей для создания массового хаоса.
‣ Multiple targets attacks. Как скоординированные, так и непоследовательные атаки по различным целям, направленные на манипуляцию защитными ресурсами.

4. Атаки разной продолжительности и интенсивности.

‣ Long persistent attacks. Продолжительные атаки, создающие постоянную нагрузку на цель.
‣ Pulsed attack. Чередование активной фазы атаки с периодами покоя.
‣ Slow evolving attacks. Атаки с постепенным нарастанием интенсивности, что делает их менее заметными для систем мониторинга на ранней стадии.
‣ Low-rate attacks (from 1000 pps/10 Gbps). Атаки с низкой скоростью отправки пакетов, маскирующиеся под легитимный трафик.

Сервис «DDoS Secure» блокирует все эти атаки, автоматически адаптируясь к их методам в течение 25 секунд после обнаружения.

Как устроена тарификация PAYG в PS Cloud?

PAYG — («Pay-As-You-Go», оплата по мере потребления) — общепринятая для облачных сервисов модель тарификации. PAYG аналогична оплате электроэнергии по счетчику. Клиент оплачивает только те ресурсы, которые он использовал, без расходов на резервирование оборудования. В итоге клиент получает выгодное персонифицированное предложение, а провайдер — оптимизацию мощностей.

Облачная платформа PS Cloud — это совокупность сервисов «Облачные серверы», «Облачные базы данных», «Балансировщики нагрузки» и «Кластеры Kubernetes». Для клиента все эти сервисы — набор базовых ресурсов: ядра процессора, оперативная память, диски и IP-адреса. Характеристики и сочетания ресурсов могут отличаться, но суть всегда одна и та же:

PS Cloud = CPU + RAM + DISK + IP

Из этого набора ресурсов клиент может конструировать IT-инфраструктуру любой конфигурации:

1 CPU + 1 RAM + 1 DISK + 1 IP

Добавлять ресурсы, когда появляется необходимость:

2 CPU + 2 RAM + 2 DISK + 2 IP

Отключать лишние ресурсы, когда потребность в них исчезает:

1 CPU + 2 RAM + 1 DISK + 2 IP

В ряде случаев используется пятый ресурс — виртуальная машина или экземпляр (INSTANCE). По сути, это все те же 4 ресурса, объединенные в неразборную конструкцию.

INSTANCE = (CPU + RAM + DISK + IP)

Масштабирование экземпляров возможно только целиком. До масштабирования:

1 INSTANCE = 1 (CPU + RAM + DISK + IP)

После масштабирования:

2 INSTANCE = 2 (CPU + RAM + DISK + IP)

На странице сервиса «Облачные серверы» есть калькулятор цен, в котором можно прогнозировать потребление ресурсов. Точная сумма формируется ежечасно по факту потребления и отражается в разделе «Расходы» консоли управления облачным проектом.

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

Мы сертифицировали все ЦОДы и облако по PCI DSS

С гордостью сообщаем, что мы завершили процесс сертификации всех дата-центров Казахстана и Узбекистана по стандарту PCI DSS 3.2.1. Теперь этому стандарту соответствует большинство наших услуг: размещение и аренда серверов, вся облачная платформа PS Cloud — IaaS, K8saaS, DBaaS, LBaaS — облачные VPS, объектное хранилище и Virtuozzo Application Platform.

Для справки: PCI DSS, «Payment Card Industry Data Security Standard», учрежден международными платежными системами (VISA, MasterCard и прочими) для защиты данных платежных карт. Его соблюдение обязательно для компаний, которые обрабатывают, хранят или передают данные карт, по условиям международных платежных систем (Visa, MasterCard и другие). Клиенты компаний, соответствующих PCI DSS, могут безопасно проводить транзакции и значительно снизить риск утечки платежных данных.

Получение сертификации включает детальный аудит более 600 контрольных пунктов по всем аспектам безопасности данных: защищенности сетей, управления уязвимостями, контроля физического и сетевого доступа, шифрования данных, поддержки политики ИБ, мониторинга и тестирования. Размещая IT-инфраструктуру у нас, в зависимости от выбранного типа хостинга, вы автоматически выполняете до половины требований PCI DSS. Ниже вкратце описаны наши зоны ответственности.

Ограничение физического доступа к данным

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

Установка и поддержка межсетевого экрана

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

Изменение параметров по умолчанию

Учетные записи, системные пароли и прочие параметры ПО, заданные производителем по умолчанию, легко доступны для злоумышленников. Поэтому мы меняем все дефолтные параметры и устраняем известные уязвимости до установки подсистем в дата-центры.

Антивирусная защита

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

Контроль доступа к сетевым ресурсам и данным

Система автоматически генерирует журналы событий и позволяет отслеживать подозрительную активность пользователей. Регистрируются все действия пользователя с неограниченными правами (root) и административными привилегиями, а также создание и удаление объектов системного уровня. Журналы событий безопасности проверяются ежедневно.

Тестирование систем безопасности

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

Кроме того мы разделяем с клиентом еще несколько зон ответственности: безопасное хранение данных, шифрование данных при передаче через общедоступные сети, аспекты разработки безопасных приложений, идентификацию пользователей и соблюдение политик ИБ. Подробности вы сможете узнать при обращении в отдел продаж: info@ps.kz.

Облачный вебинар в Узбекистане

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

Завтра, 27 июня в 15:00, мы расскажем:

— что такое облака, и как они помогают бизнесу расти;
— почему облака — это следующее поколение хостинга;
— для какого бизнеса подходят облака;
— как сократить капитальные расходы на хостинг IT-инфраструктуры.

Если вы планируете развивать бизнес в Узбекистане, приглашаем вас послушать выступления наших специалистов. Подарок каждому участнику вебинара — 1 000 000 сумов в виде бонусов на новый облачный проект.

Регистрация на вебинар по ссылке.

PS Cloud Services — сертифицированный провайдер услуг Kubernetes

Что общего между Боинг, Нетфликс, университетом Принстон, ИКЕА, Эфириум, БиБиСи и правительством Его Величества Карла III? Эти и сотни других организаций состоят в Linux Foundation (LF), консорциуме, который поддерживает разработку и распространение открытого ПО.

Членство в консорциуме можно получить, обладая большими деньгами или глубокой экспертизой. Фонд Cloud Native Computing Foundation (CNCF), одно из направлений деятельности LF, занимается поддержкой облачных технологий, включая Kubernetes, и сертифицирует лучших облачных провайдеров по всему миру.

Теперь мы в их числе. PS Cloud Services — серебряный партнер Linux Foundation и CNCF, сертифицированный провайдер услуг Kubernetes (KCSP). Мы гордимся новой победой и рады поделиться ею с вами.

Если вы разрабатываете cloud native приложения, обращайтесь за консультацией к нашим экспертам. Команда Certified Kubernetes Administrator поможет минимизировать операционные риски, повысить производительность вашей инфраструктуры и оптимизировать процессы DevOps.

Цикл лекций Алексея Антошевского
«Облака для самых маленьких‎»

Алексей Антошевский — Senior System Administrator, RHCA, обладатель черного пояса по Linux-администрированию — задает правильный вектор в обучении и эксплуатации облачных инфраструктур.

Часть 1.1. Четыре шага к пониманию облаков

Дисклеймер: употребление слова «эффективность‎» в материале зашкаливает.‎

Современный интернет характерен динамичными нагрузками. Например, Каспи объявил «Жұма 0-0-24» и вызвал огромный наплыв покупателей в течение двух суток. Трафик на стриминговых сервисах растет каждый вечер, когда люди возвращаются домой и ужинают под новую серию «Пацанов».

Маркетплейсам и стримингам и многим другим компаниям необходимо оперативно реагировать на такие нагрузки: масштабировать ресурсы приложений. Для эффективного управления приложениями были созданы облака.

Облака появились в 2006 году, первопроходцем был Amazon. Через два года зашел Google, в 2010 — Microsoft. Мы запустили облако в 2018 году.

Для понимания сути работы облака вам нужно пройти четыре простых шага.

Шаг 1. Никаких облаков не существует. Есть условно бесконечные физические ресурсы облачного провайдера. Провайдер следит за тем, чтобы ресурсы не заканчивались, за физической безопасностью и эксплуатацией оборудования, за обеспечением бесперебойного электричества, доступа в интернет и так далее.

«Над» оборудованием провайдер создает слои виртуализации и управляет ими. Пользователи могут практически мгновенно получать аппаратные ресурсы в виде виртуальных машин и сетей.

Шаг 2. Для управления облаками нужен интерфейс. Главный компонент управления — это API, который позволяет выделять и высвобождать ресурсы. Поверх API могут находиться:

✓ графический интерфейс, например, console.ps.kz, для простого управления ресурсами на пользовательском уровне;
✓ командный интерфейс, CLI, — для быстрого администрирования через командную строку;
✓ утилита типа Terraform — для автоматизации управления инфраструктурой.

Шаг 3. Эффективное управление ресурсами выгодно всем. Если у вас есть возможность очень быстро выделять и высвобождать ресурсы, то вам выгодно платить только за то, что вы использовали по факту в течение часа. А провайдер может максимально утилизировать имеющиеся ресурсы.

Подробнее про модель оплаты PAYG мы писали выше.

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

Иначе говоря, cloud native — это подход к построению облачной инфраструктуры и разработке приложения для достижения максимальной эффективности их взаимодействия.

О том, что общего между cloud native и скотоводством, читайте в следующей части или смотрите лекцию целиком на YouTube.

Друзья, нам исполнился 21 год! И пролетевший год был очень продуктивным.

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

В шести дата-центрах Казахстана и Узбекистана, а также в облачной платформе PS Cloud, мы создали условия для соответствия требованиям международного стандарта безопасности индустрии платежных карт PCI DSS 3.2.1. и получили соответствующие сертификаты. Несколько крупных финансовых организаций, разместив у нас инфраструктуру, выполнили до половины требований стандарта, значительно сэкономили на сертификации и снизили риск утечки данных своих клиентов.

Мы стали серебряным партнером Linux Foundation, Cloud Native Computing Foundation и сертифицированным провайдером услуг Kubernetes (KCSP). Таким образом, наши специалисты в очередной раз подтвердили свою экспертизу в администрировании Kubernetes и сопровождении клиентских проектов.

Еще мы запустили услуги в пятом дата-центре в Алматы и соединили все дата-центры в городе собственным оптоволокном, запустили сервис защиты от DDoS-атак, тестируем новую услугу аренды облачных серверов для 1С. И это — только крупные вехи минувшего года.

Спасибо вам за то, что нам есть, ради кого развиваться такими темпами. Спасибо, что вы с нами!

🥇 Золотой спонсор DevOpsDays Almaty 24 — PS Cloud Services

PS Cloud Services — независимый казахстанский облачный провайдер, размещает оборудование в 7-ми дата-центрах в Алматы, Астане и Ташкенте. За 20 лет работы на рынке стал партнером значительной части Казнета.

Предоставляет сервисы на базе собственной облачной платформы PS Cloud, услуги SOC/ОЦИБ, все виды веб-хостинга, лицензии на ПО.

🤝 Такое партнерство поможет объединить опыт и знания, а также обменяться передовыми практиками и идеями — всё это послужит на благо казахстанскому DevOps-сообществу.

👉🏻 Регистрируйтесь на DevOpsDays Almaty’24 и будьте готовы к мощному контенту, полезным знакомствам и крутому нетворкингу — интересного будет много.

#devops #devopsdays #partners

@devopsdayskz

⭐️ Спикер #5 на DevOpsDays Almaty'24 — Алексей Антошевский, Senior Linux Engineer, RHCA.

Алексей занимается автоматизацией и участвует в создании облачных услуг в PS Cloud Services.

В своем докладе Алексей расскажет, как устроены сервисы в облаке на примере сервиса для 1С: какой процесс видит пользователь и что происходит со стороны провайдера.

Также Алексей затронет тему синтетических тестов производительности 1С, поговорит о дилемме baked vs fried, о подготовке образа и cloud init, а также о роли AWX (Ansible Tower) в создании сервиса. ✨

👉🏻 Регистрируйтесь на DevOpsDays Almaty’24 и не пропускайте ни одного докладчика — интересного будет много.

#devops #devopsdays #speakers

@devopsdayskz

Продолжение цикла лекций Алексея Антошевского
«Облака для самых маленьких‎»‎

Алексей Антошевский — Senior System Administrator, RHCA, обладатель черного пояса по Linux-администрированию — задает правильный вектор в обучении и эксплуатации облачных инфраструктур.

Часть 1.2. Cloud native: краткое пособие по скотоводству

Не каждый сервер или приложение может считаться cloud native. Это сильно зависит от подхода к настройке сервера и построению приложения. До венца эволюции под названием «cloud native» есть несколько подходов — вручную, с помощью системы управления конфигурациями, описание инфраструктуры в виде кода. Каждый подход имеет право на существование, но чем больше соответствие cloud native, тем эффективнее использование облака.

Ручная настройка

Настройка сервера вручную — это самый быстрый и простой способ, но он приводит к проблеме «сервера-снежинки». Уникальная и хрупкая настройка такого сервера известна обычно только тому, кто ее выполнял, и повторить ее сложно. Часть этой проблемы можно решить настройкой сервера скриптами, но этот метод не гибкий.

Управление конфигурациями (SCM)

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

Инфраструктура как код (IaC)

Использование подхода «инфраструктура как код» отчасти решает эту проблему. Мы декларативно описываем состояние инфраструктуры, а инструменты вроде Terraform или OpenStack Heat приводят систему в это состояние. Но и тут есть свои нюансы. При работе с облаком нет понятия установки операционной системы: инстансы запускаются из образов. Возникает дилемма. Образ, из которого мы запускаем инстанс, можно подготовить заранее — этот процесс называется «выпекание». Альтернатива ему — «прожарка»: взять образ чистой ОС, запустить его и настроить.

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

Иммутабельная инфраструктура: от питомца к стаду

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

В этом и заключается «cloud native». Начать практику вы можете прямо сейчас, у нас в PS Cloud.

Кроме того, в пятницу Алексей раскроет тему подробнее в докладе «50 оттенков жёлтого: пилим кастомный SaaS на базе OpenStack» на конференции DevOpsDays'24. Все билеты уже распроданы, но вы сможете подключиться онлайн.

Продолжение цикла лекций Алексея Антошевского «Облака для самых маленьких‎»‎

Алексей Антошевский — Senior System Administrator, RHCA, обладатель черного пояса по Linux-администрированию — задает правильный вектор в обучении и эксплуатации облачных инфраструктур.

Часть 2.1 Золотой образ

С чего начинается работа любого сервера? Правильно, с установки операционной системы. Но поскольку мы находимся в облаке, традиционной установки ОС не будет. В облачной среде инстансы разворачиваются на основе готовых или кастомных образов операционных систем. Из этих образов создаются тома (volume), на которых поднимаются инстансы — процесс, известный как image-based provisioning.

Хотя образы одинаковы, у каждого инстанса могут быть свои особенности, и их нужно настроить. Эта задача выполняется с помощью системы cloud-init.

Предварительная настройка инстансов

Cloud-init — это система инициализации облачных инстансов, встроенная во все образы для работы в облаке. На входе она получает конфигурационные данные, метаданные от вендора и пользователя, после чего настраивает инстанс в соответствии с ними. Процесс настройки включает пять этапов.

1. Cloud-init определяет, нужно ли запускаться при загрузке.
2. Система настраивает источники метаданных и применяет сетевые настройки.
3. Начинается использование пользовательских данных, происходит настройка дисков и монтирование файловых систем.
4. Выполняются модули cloud-init, которые не влияют на другие этапы загрузки.
5. Устанавливаются пакеты, запускаются SCM-инструменты и пользовательские скрипты.

Способы конфигурирования инстансов

Весь этот процесс нужно контролировать, чтобы инстанс соответствовал нашим требованиям.

Для конфигурации инстансов есть несколько вариантов. Один из них — использование модулей cloud-init. Они позволяют хранить конфигурации в YAML-файлах и охватывают большинство задач по локальной настройке системы. Однако есть и недостатки: сложность отладки и обработки исключений — если важно получить рабочий сервер с первого раза.

Другой вариант — использование кастомных скриптов. Они работают аналогично модулям cloud-init, но также могут быть сложными в поддержке. Третий вариант — внешние инструменты управления, такие как AWX (Ansible Tower), Puppet, Chef и т.д. Они предоставляют большие возможности для обработки исключений и выполнения операций второго дня, но добавляют дополнительную точку отказа.

Создание золотого образа

Вернемся к образам. На прошлой лекции мы уже говорили о дилемме baking vs frying. Мы выберем золотую середину: подготовим образ заранее, но так, чтобы его можно было быстро настроить при развертывании. Для этого можно использовать GitLab CI и автоматизировать сборку «золотого образа».

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

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

Об Ansible-плейбуках, резервном копировании и провиженинге managed-сервиса 1С Алексей рассказал на DevOpsDays — вот полная запись доклада.

Друзья, на этом турне Антошевского не заканчивается. Уже в субботу он выступит на Open SysConf 2024 с докладом «Три системы, которые ты захочешь развернуть и настроить».

Конференция Open SysConf — это местный IT-андеграунд (по меткому выражению коллег из Profit) и наш давний партнер. Регистрация открыта, присоединяйтесь.

Когда: 12 октября, с 10:00 до 20:00.
Где: ул. Байзакова, 280 (SmArt.Point, зал: Amphitheatre).

Помогаем мигрировать в Kubernetes

Вышел пресс-релиз CNCF с упоминанием PS Cloud Services в перечне новых партнеров. Напоминаем, что в этом году мы получили статус «Kubernetes Certified Service Provider» и Silver Member в организации CNCF, развивающей Kubernetes и другие Open Source-проекты. Несколько инженеров нашей компании, оказывающих платную техподдержку в рамках услуги «Администрирование серверов», являются обладателями сертификатов «Certified Kubernetes Administrator».

Что означает наш новый статус на практике — рассказываем на примере свежего кейса.

Один наш клиент «вырос» из традиционной серверной архитектуры и искал решение, которое позволило бы динамически масштабировать приложения и минимизировать простой при обновлениях и сбоях. Мы предложили мигрировать в Kubernetes, что позволило бы клиенту добиться необходимых целей по масштабируемости, отказоустойчивости и автоматизации процессов. Процесс работы включал в себя:

1. Аудит и документирование текущей инфраструктуры
Мы провели полный анализ всех сервисов и их взаимодействий. Это дало нам чёткую картину того, какие приложения требуют доработки перед переносом в Kubernetes.

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

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

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

5. Проектирование системы логирования и мониторинга
Мы внедрили централизованную систему сбора логов и мониторинга Grafana + Loki + Promtail, что позволило клиенту отслеживать все процессы в реальном времени и быстро реагировать на возможные сбои.

6. Автоматизация CI/CD
Настроили автоматизированные процессы развертывания и тестирования приложений с помощью ArgoCD, что значительно ускорило цикл релизов.

7. Создание манифестов Kubernetes
Для каждого сервиса были разработаны манифесты для деплоя в кластер. Мы провели тестирование развертываний, убедившись в их стабильности.

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

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

Результат

После успешного завершения миграции клиент получил систему, которая полностью отвечает его требованиям по отказоустойчивости и масштабируемости. Теперь его разработчики могут:

1. Автоматически разворачивать новые версии приложений с помощью ArgoCD.
2. Откатываться к предыдущим версиям без длительных простоев.
3. Динамически масштабировать приложения в зависимости от нагрузки с помощью Horizontal Pod Autoscaling.
4. Автоматически поддерживать необходимое количество копий приложений и перезапускать их в случае сбоя.

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

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