Методология разработки программного обеспечения
HashiCorp Vault имеет в своём арсенале SSH secrets engine, который позволяет организовать защищённый доступ к вашим машинам по ssh, через создание клиентских сертификатов и одноразовых паролей. Про последнее – создание одноразовых паролей (OTP) – мы и поговорим в этой статье.
В мире, где каждая учетная запись требует от нас еще одного пароля, и каждый облачный сервис, такой как 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-триггеров и их ключевую роль в создании и обслуживании исторических таблиц.
Расскажу как просто задеплоить телеграмм бота на Aiogram 3 с webhook на VPS/VDS. Посмотреть видео версию, которую я выложил, можно на YouTube
Также покажу установку двух типов сертификатов SSL: ...
C Nginx и без него ...
Представьте себе команду, которая пишет F2P-игру для мобильников. Даже если это инди-проект из трёх человек, в этой команде всё равно будут разработчики, тестировщики и хоть кто-то ответственный за инфобезопасность. И, допустим, в команде хаос.
Разрабы долго ждут обратную связь от QA, половина документации нечитабельна, в Git пропала версия кода, до которой очень нужно откатиться прямо сейчас, потому что в новой всё поломалось в проде и надо вернуть как было… Ещё и вся команда в ссоре и ни один дейли не проходит без скандала. Как вы думаете, быстро ли эта игра дойдёт до рынка?
Это, конечно, драматическое преувеличение, но для решения таких проблем и нужны DevOps-практики.
Все привет! В продолжение статьи о возможностях PowerShell, хочу поделиться несложной реализацией создания REST API и простого Web-сервера, используя только PowerShell на базе класса .NET HttpListener. Такая реализация позволяет настроить endpoint (конечные точки) для обработки GET и POST запросов, которые принимают параметры в заголовке запроса, использовать Basic-авторизацию (на основе Base64), обрабатывать любые коды возврата, а так же без лишнего кода, отдавать информацию в разных форматах: json, xml, html, csv.
Всем привет! Несколько месяцев назад прошел GrafanaCON 2023, на котором объявили о выходе десятой версии Grafana — инструмента для мониторинга и визуализации данных с аудиторией в 20 миллионов по всему миру.
Grafana 10 помогает добиться большего: подробнее анализировать данные и приходить к надежным выводам, удобнее работать в команде и делать более красивые дашборды. Grafana 10 полезна как опытным аналитикам, так и тем, кто только начинает свой путь.
В этой статье мы обсудим нововведения Grafana 10. Кроме того, вы можете сами ознакомиться с новыми функциями:
В начале не было ничего. И создал DevOps кластер Kubernetes и сказал, что это есть хорошо. Но пришли злые программисты и начали требовать информацию о том, сколько ресурсов потребляют их контейнеры.
Всем привет!
Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Продолжаем рассказывать вам о метриках безопасной разработки — и показывать их на дашбордах модуля визуализации метрик DevSecOps платформы AppSec.Hub. Напомню, мы уже писали об оценке рисков ИБ, о зрелости подхода Shift Left и об обработке найденных уязвимостей.
В предыдущей статье мы начали говорить о проверках ИБ в контексте принципов DORA, а сегодня разберем вторую часть дашборда по сканированиям ИБ и попробуем ответить на вопрос: «Как оценить покрытие практиками ИБ приложения/всех систем?»