DevOps *

Краткий обзор нескольких инструментов Container Security. Теория – это хорошо, но иногда легче показать как проверять контейнеры в проде.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

С момента публикации концепции Twelve-Factor App значительно изменилось то, как мы создаём, упаковываем и развёртываем приложения. Контейнеры, Kubernetes и облачные технологии стали основными технологиями, которые позволяют нам создавать переносимые, масштабируемые и надёжные приложения. Тем не менее 12 факторов, сформулированных в концепции, всё ещё актуальны в современном технологическом стеке.

Перевели статью, в которой описывается методология Twelve-Factor App и применение её концепций в контексте контейнеров и Kubernetes.

В августе 2023 года под руководством группы TAG Observability в экосистеме CNCF была выпущена версия 1.0 документа по наблюдаемости (observability). CNCF — флагман развития и продвижения облачных технологий. Организация объединяет в себе множество компаний, разработчиков и специалистов с огромным опытом и экспертизой, которые упаковали в этот документ. Наш материал является его переводом.

Всем привет! В продолжении публикации о возможностях PowerShell, упомянул, что выделю в отдельную статью использование библиотеки Selenium с упомянутым языком. Этот небольшой гайд также может подойти для понимания, что из себя представляет данная библиотека и общее представление, как с ней работать, т.к. не зависимо от выбранного вами языка, принцип работы с Selenium одинаковый. Сразу отвечу на вопрос для тех, кто не знает, что это за библиотека или кому она может понадобиться. Selenium в первую очередь инструмент для функционального тестирования, это когда нужно проделать ряд действий имитируя реального пользователя и убедиться, что функционал Web-приложения работает исправно или неисправно. Реже используется для автоматизации различных задач в браузере (вызов JavaScript функций по средствам нажатий кнопок, заполнение форм и т.п.), для которых не предусмотрено API, а в некоторых случаях может выступать более удобной и полноценной альтернативой. Работая системным администратором, мне было удобно автоматизировать действия в панелях управления различных сервисах, или собирать специфические метрики с отправкой в базу данных. Selenium даже может входить в список инструментов DevOps-инженера. На мой взгляд, инструмент очень интересный с точки зрения творческого подхода к решению различных задач.

Постараюсь разложить все по полочкам, от установки всех зависимостей до примера работы с данным инструментом, также продемонстрирую альтернативный инструмент, который использовал до знакомства с Selenium. Специально для статьи подготовил модуль, который позволяет общаться с бесплатной версией ChatGPT из консоли PowerShell, который вы можете установить, используя всего две команды, а так же покажу, как просто создать такой модуль. Хочу заметить, что осознанно выделяю данную статью в средний уровень сложности Habr, по итогам ознакомления, для людей базово знакомых с PowerShell (для этого у меня есть отдельная работа с заметками), порог вхождения будет минимален.

Большинство современных систем хранения данных (СХД) предоставляют REST API для управления ими, включая настройку, конфигурирование, выполнение различных команд, получение логов, работу с пользователями и т.д. В зависимости от производителя СХД REST API могут отличаться друг от друга. Если вы используете несколько разных систем, их одновременная поддержка становится проблемой: нужно учитывать многообразие протоколов, интерфейсов, команд и способов взаимодействия с API.

Меня зовут Александр Пономарев, вместе с группой студентов СПбПУ Петра Великого на базе Лаборатории YADRO мы изучали способы сделать управление разными СХД менее трудоемким. Вариант, на котором мы остановились, — использовать системы, которые удовлетворяют спецификации Swordfish, в связке с Ansible. Подробнее о проекте, который мы выполняли с инженерами компании и преподавателями университета, рассказываю под катом.

Объектное хранилище — название отражает принцип работы, хранение данных в виде объектов с уникальным индексом.

Хочу расcказать о своем опыте работы с одним из них.Меня заинтересовал один конкретный продукт — MinIO, из‑за достаточно простой установки, настройки и не плохого функционала. Есть несколько вариантов инсталляции MinIO:

HashiCorp Vault имеет в своём арсенале SSH secrets engine, который позволяет организовать защищённый доступ к вашим машинам по ssh, через создание клиентских сертификатов и одноразовых паролей. Про последнее – создание одноразовых паролей (OTP) – мы и поговорим в этой статье.

Для того, чтобы построить облачный сервис понадобится горизонтально масштабируемая база данных. Cloudstack «из коробки» не знает что такое HA, предполагается, что для этого нужно использовать встроенный функционал MySQL или такое решение как Galera Cluster. Но мы пойдем другим путем и остановим свой выбор на Vitess – надежной, легко масштабируемой системы кластеризации для MySQL.

В мире, где каждая учетная запись требует от нас еще одного пароля, и каждый облачный сервис, такой как AWS, зависит от надежности этих ключей, менеджеры паролей вроде Bitwarden выступают как спасители. Они не просто хранят наши ключи и пароли, но и делают их управление значительно удобнее. Однако, даже с таким мощным инструментом, как Bitwarden, мы сталкиваемся с ограничением: он не способен автоматически обновлять и менять используемые в облачных сервисах ключи и пароли. Итак, что делать, когда ручное обновление ключей и паролей становится скучной и малоэффективной задачей? В этой статье мы исследуем, как можно объединить удобство использования Bitwarden с эффективными методами автоматизации для управления учетными данными AWS. Представьте себе – больше нет монотонного ввода паролей и обновлений ключей вручную. Но для этого придется немного постараться.

Хочу показать как развернуть готовый и полностью работающий стек мониторинга Grafana + Loki + Prometheus + Pushgateway + Promtail за пару минут (в прямом смысле этого слова), без необходимости устанавливать на машину дополнительное ПО (плагины docker и плагины логирования) и собирать логи со всех контейнеров машины (или сразу со всех нод, в случае с swarm).

Всем привет! Я давно планировал написать цикл статей на тему Chaos Engineering, чтобы рассказать о том, как его запускать, пилотировать и, конечно, масштабировать. Я обладаю большим опытом и знаниями, которые помогут запустить эту практику в «жестком» и сложном Enterprise, когда у нас идут релизы, а команд десятки. Частично мы уже делились этой информацией на конференциях CodeFest, ArchDays, DevOops conf, TechLead, но здесь мы еще попробуем систематизировать и подать концентрированно.

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

 В  данной статье я  рассмотрел основную проблему в выпуске новых версий приложений в production, также описал суть canary deployment и процесс развертывания с помощью Kubernetes.

Всем привет. Меня зовут Ярослав. Вместе с моим коллегой Володей, мы представляем команду Sunshard. Нашей небольшой командой Hashicorp-энтузиастов мы решаем различные бизнес-задачи для команд разработки.

Мобильная разработка под iOS особенная: собрать приложение можно только на macOS, среда разработки по сути только одна, большая часть принятого в сообществе тулинга написана на Ruby, свой пакетный менеджер появился только пару лет назад. Тяжко.

А когда речь заходит про автоматизацию тестирования и сборок — тушите свет: Xcode Cloud появился полгода назад и почти ничего не умеет, популярные облачные решения могут месяцами не обновлять стек на новые мажорные релизы среды разработки или ОС (вставить ссылку на тред где гитхаб не может привести новую макось уже полгода), а ценник при этом может быть в 10 раз больше, чем за машинки на Linux. Ещё тяжелее.

Меня зовут Леха Берёзка, я iOS-техлид в Додо Пицце и сейчас я расскажу как мы собрали свой CI на М1, с виртуализацией и на полном нативе.

Привет! Меня зовут Василий Куценко, я возглавляю департамент DevOps в Почтатехе и считаю, что девопсов не существует… 

То есть по всем канонам классической DevOps-культуры такой должности не должно быть. Все потому, что DevOps рождался как способ взаимодействия уже существующих ролей в командах разработки и поддержки, а не как отдельная специальность. 

Но как же быть с тем, что компании постоянно ищут DevOps-инженеров, на хантинговых сайтах полно подобных вакансий, а сама должность престижна и хорошо оплачивается? Кто же эти «фантастические девопсы» и что нужно, чтобы быть «труъ», разбираемся в статье.

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

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

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

Представим ситуацию, что мы деплоим по push-модели. В качестве платформы для запуска деплоя у нас используется Gitlab: в нём настроен пайплайн и джобы, разворачивающие приложения в разные окружения в Kubernetes

Какой бы инструмент мы не использовали (kubectl, helm), для манипуляций с ресурсами API нам в любом случае будет необходимо аутентифицироваться при выполнении запросов к Kubernetes. Для этого в запросе надо передать данные для аутентификации, будь то токен или сертификат. И тут возникает несколько вопросов:

1. Где хранить эти креды?

Хранить креды от кластера можно, например, в Gitlab CI/CD Variables и подставлять в джобу деплоя, но тогда потенциально все пользователи будут деплоить с одними и теми же доступами

2. Как сделать так, чтобы у каждого пользователя были свои данные для доступа в кластер?

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

А что если сделать так, чтобы в качестве провайдера аутентификационных данных для Kubernetes выступал сам Gitlab? Тогда не надо было бы нигде хранить креды, и каждый пользователь мог бы аутентифицироваться в кубере под своей учёткой при запуске деплоя

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

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