DevOps *

Привет, Хабр! 

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

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

И вот как раз о данных (а точнее о базах данных) в таких средах и хотелось бы поговорить. А именно — где и как их взять, как сделать их максимально приближенными к боевым и как защититься от их утечки. Для решения этих задач мы в Nixys используем собственный инструмент — nxs-data-anonymizer. Хотим поделиться им с вами.

В серии статей по теме DevOps мы рассказываем о проверенных инструментах выстраивания инфраструктуры, которыми с недавнего времени пользуемся сами. В первой части мы остановились на основных предпосылках внедрения и выбранном подходе. В этой статье вместе с  Lead DevOps инженером департамента информационных систем ИТМО Михаилом Рыбкиным рассмотрим подробнее фундамент нашей инфраструктуры — Kubernetes. 

Разумеется, статей об этом оркестраторе огромное множество, и можно на протяжении всей карьеры узнавать о нем что-то новое. Сразу уточним — в этой части мы не планируем копать глубоко. Попытаемся дать основы, описать Kubernetes так, чтобы сложилось базовое представление об этом инструменте. 

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры. 

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется. 

Звучит как фантастика?

Дисклеймер: весь текст основан на субъективном опыте. Это не руководство к действию, а мой личный путь, который только начался. Профессиональные рекомендации и истории про ваши карьерные треки пишите в комментариях.

Привет, Хабр! В статье расскажу, как сделать CI-конвейер в домашних условиях и делать простые android-приложения без знаний Java и Kotlin.

Облачные сервисы — это отлично, но, если ими начинают пользоваться разные команды в компании, вопрос управления затратами превращается в «черный ящик». Когда мы только начинали нашу историю с FinOps, то даже не представляли, насколько эффективнее можно раскрутить историю с арендой облачных мощностей. Но оказалось, что расширение практик управления затратами помогает получить от облаков еще больше отдачи и не допустить необдуманных трат (а то один стартап решил как-то вечером расшифровывать ДНК на арендованных мощностях, а утром закрыл компанию, потому что потратил все деньги). О том, как это было, какие грабли мы собрали по пути, как нам помогла команда ИБ и за счет чего мы теперь экономим до 20% на облачных счетах, читайте под катом.

Cтатья будет полезна разработчикам и инженерам по ИБ, желающим повысить уровень безопасности приложений за счет внедрения проверок, запрещающих вносить секреты в открытом виде в исходный код.

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

В статье рассмотрим внедрение Gitleaks применительно к Azure DevOps Server в процесс анализа запросов на вытягивание (pull requests) при слиянии ветвей. Система управления исходным кодом Azure Repos является частью Azure DevOps Server.

Сейчас DevOps-инженеры довольно востребованны: в их услугах нуждаются различные компании, чья деятельность в той или иной степени связана с ИТ-отраслью. В профессию приходят как разработчики, системные администраторы и реже — тестировщики, так и полные новички (обычно это становится возможно благодаря стажировкам).

Меня зовут Евгений Цигельников, и я ведущий DevOps-инженер в направлении интеграционных решений в Лиге Цифровой Экономики. В этом материале поделюсь опытом и расскажу, чего ожидать новичкам в DevOps на старте карьеры и как преодолевать первые трудности.

DevOps-инженер связывает и синхронизирует все этапы разработки программного обеспечения: от составления технического задания до релиза.

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

Со стороны hard skills это очень творческое направление — можно построить инфраструктуру или автоматизировать работу совершенно разными способами, приходится разбираться в процессах ИТ-бизнеса. Последнее, кстати, будет актуально для тех, кто в будущем планирует строить свой стартап. А еще это отличная профессия для общительных людей. 

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

Привет! Меня зовут Сергей Птушкин, в этом посте я поделюсь с вами нашим чеклистом для оперативного и безболезненного переезда в Kubernetes. У SM Lab очень много разных продуктов, а как следствие — разных команд разработчиков и администраторов. У всех своя архитектура, стек, любимые языки программирования, SLA и требования по нагрузке.

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

Итак, давайте разберем на примере нашей ситуации. Мы переезжали в Kubernetes из Mesos и Oracle Weblogic и знали, что разработчики тестируют приложения при помощи docker-compose или локально на станциях. Нам нужно было придумать единый подход для следующих возможностей:

Привет, меня зовут Панов Михаил, я DevOps‑инженер МТС Digital. Хочу поделиться с вами опытом построения «модульных» pipelines на основе gitlab-ci. В этой статье я расскажу, что такое модульный CI/CD, из чего он состоит, для чего нужен и как поможет командам, поддерживающим большой список нетиповых репозиториев.

Если вы знаете, что такое Site Reliability Engineering, вам может быть интересно, как эти практики связаны с DevOps. Важно сразу оговориться, что мы не ставим между ними слово «против». Хотя у этих подходов есть некоторые отличия в том, как лучше делать и быстрее доставлять программное обеспечение. В этом посте разберём каждый подход и выясним, чем отличаются DevOps и SRE. Вы заметите, что у подхода SRE есть своё мнение по поводу запуска производственных систем, в то время как DevOps больше фокусируется на людях, процессах и инструментах — именно в этом порядке.

Антон Губарев, инженер в команде Platform as a Service (PaaS) Авито, рассказал, как они с командой внедряли политики авторизации с помощью Open Policy Agent (OPA), и с какими проблемами столкнулись на пути.

Всем привет. Меня зовут Игорь, я Tech Lead команды DevOps-инженеров и активно развиваю направления мониторинга в компании. В продолжение статьи своего коллеги по цеху @EvgenNet хочу познакомить вас с шаблоном для Zabbix и дашбордом в Grafana для визуализации активности пользователей OpenVPN. Возьмите вкусняшек, чайку и присаживайтесь поудобнее.

Всем привет, у нас в НЛМК создается множество приложений и систем для производства и поддержки бизнеса. Большинство размещаются в нашей Единой Цифровой Платформе (коротко ЕЦП), а по-современному: Internal Developer Platform.

Мы с коллегами как раз занимаемся развитием Единой Цифровой Платформы НЛМК, частью которой являются кластеры Openshift/OKD/K8S, количество которых постепенно увеличивается, что требует понятного, прозрачного подхода к управлению и конфигурированию как самих кластеров, так и различных приложений, работающих в них. Далее я расскажу, как мы это делаем с помощью ArgoCD и подхода GitOps

Всем привет!

Меня зовут Антон Башарин, я технический директор Swordfish Security, занимаюсь внедрением ИБ-практик в DevOps, построением и автоматизацией процессов безопасной разработки. В предыдущей статье мы с вами поговорили о роли инструмента класса ASOC в оптимизации работы с уязвимостями, а также проанализировали результативность его решений с помощью дашбордов, разработанных нами для модуля визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. Мы обещали вам продолжение: на этот раз покажем и расскажем, как наши графики позволяют оценить уровень зрелости подхода Shift Left и его эффективность с точки зрения информационной безопасности. Поехали!

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

Хорошо быть умелым разработчиком и самому закрывать все задачи по запуску микросервисных приложений. Но как быть, если команда разработчиков тратит все время на управление микросервисными приложениями, настройку систем безопасности, аутентификации, мониторинга, логирования? Можно писать код и самостоятельно запускать каждый компонент, а можно нажать несколько кнопок и развернуть микросервис. Именно для этого мы создали консоль в платформе контейнеризации dBrain.cloud. В этой статье хотим подробнее рассказать, зачем и кому она будет полезна.

Привет, Хабр! Меня зовут Сергей Задорожный, я автор курса «DevOps для эксплуатации и разработки» в Яндекс Практикуме. Давным-давно, когда жил в общежитии мехмата, любил почитывать SecurityLab, баловался с XSpider от Positive Technologies, nmap, cain, metasploit и прочими интересными штуками. С тех пор я не раз подумывал посетить PhDays, и свершилось: у меня был подходящий доклад и конференция на горизонте.

Где-то за неделю до закрытия приёма заявок зашёл на сайт PHDays, заполнил форму и подался. Написал кратко о себе, о чём собираюсь рассказать, и кинул ссылки на видео с докладом и презентацию.

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

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

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