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

В первой части я расскажу про проект, который недавно пришел к нам с таким ТЗ: 

1. Замкнутый контур;

2. Отсутствие CVE во всех используемых продуктах;

3. Контроль безопасности уже имеющейся инфраструктуры;

4. Контроль доступа до среды;

5. Автоматизация процессов.

Давайте посмотрим, что из этого вышло. 

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

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

Привет! Меня зовут Алексей, я DevOps-инженер компании Nixys. «Как правильно и своевременно предоставлять и отнимать доступ у различных сотрудников?» — этот вопрос беспокоит всех. Особую важность эта задача приобретает, когда продукт начинает быстро расти — если ваш штат регулярно меняется, вопросы безопасности данных и работоспособности системы должны стоять на особом контроле.

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

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

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

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

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

Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys — мы помогаем другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.

А еще — делимся знаниями и опытом в этой сфере. Сегодня представляем продолжение серии обучающих видеороликов на YouTube "Terraform: от незнания к best practices" и выкладываем сразу два видео!

Всем привет!

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

Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”

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

В наши дни весь современный бизнес имеет взлеты и падения - если мы говорим о команде, разрабатывающей свой продукт. Мы можем стать либо свидетелями рождения истории, либо её участниками. Именно так в 1987 году бывший офицер Шэньчжэнь создал свою компанию с капиталом в 20 000 юаней. Её название знает сейчас каждый инженер, но многие не задумываются в смысловом содержании этого названия Hua - “Китай” и Wei - “Достижение”.

“Так, стоп”, - мысленно подумал сейчас про себя каждый, - “Зачем я сейчас читаю про это? Я хочу узнать что-то про SberCloud, и как там обстоят дела с k8s”. А вот нельзя говорить о SberCloud и не говорить о Huawei Cloud, ведь по своей сути это один и тот же продукт, который предоставляется нам сейчас на рынке. Но не хотелось бы впадать в полемику и говорить о том, почему так и никак иначе. Лучше обсудим ряд вопросов, которые действительно интересуют любого инженера, решившего связать свою проектную деятельность со SberCloud.

4 года назад наша команда Nixys рассказывала, почему мы решили сделать собственный инструмент для резервного копирования и почему другие инструменты нам не подошли. Сегодня хочу рассказать, какие проблемы и недостатки в старой версии нам мешали, почему мы решили всё переписать и что у нас в итоге получилось. Добро пожаловать под кат.

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

Именно поэтому было решено посвятить статью одному из таких продуктов. Речь пойдет о российской операционной системе РЕД ОС — дистрибутиве, построенном на базе ядра Linux и пакетной базе RPM. Со слов разработчиков дистрибутива, РЕД СОФТ опирается на опыт ведущих мировых сообществ Open Source и придерживается конвенций о наименовании пакетов и спецификации сборок.

Решающим фактором в выборе РЕД ОС является наличие свидетельства государственной регистрации программ ЭВМ и ее наличие в едином реестре российских программ.

В рамках статьи будет продемонстрировано развертывание простого Bitrix окружения на этой ОС, а именно развертывание стандартного LEMP (Linux, Nginx, MySQL, PHP) и установка дополнительных решений для работы проекта на данном дистрибутиве. Однако мы посчитали скучным описание установки стека LEMP только из родного репозитория, поэтому решили в рамках статьи развернуть СУБД MySQL 5.7, пакеты которой отсутствуют в репозиториях РЕД ОС. Как показывает наша практика, данная версия MySQL все еще остается одной из самых популярных для LEMP‑стек проектов.

Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys, которая помогает другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.

Сегодня я приглашаю вас вместе со мной пройти путь «от незнания к best practices» в работе с Terraform. Этот материал подготовлен для серии наших одноименных видеороликов на YouTube, но мы решили дополнить его и предложить вам более детальное описание процесса в этой статье.

Не забывайте следить за нашими обновлениями на YouTube, Habr и подписывайтесь на наш Telegram‑канал DevOps FM — мы всегда рады новым друзьям. Начнём?

Доброго времени суток.

При работе с Bitrix‑инфраструктурой в определенный момент вы можете столкнуться с проблемой увеличения времени открытия различных страниц на вашей площадке (сайте), медленной отдачей заказов или замедленной выгрузкой новых товаров на площадку. Чаше всего это связанно с ростом проекта и повышением потока клиентов, из‑за чего сервера могут не справляться. И здесь мы сталкиваемся с необходимостью расширения Bitrix‑инфраструктуры — спасти ситуацию может переезд на новые сервера, а вместе с тем и улучшение пропускной способности площадки.

Всем большой привет. Меня зовут Виктор, и я DevOps-инженер в команде Nixys. Мы решили выложить обучающее видео, которое будет полезно новичкам в мире DevOps. Тема сегодняшнего туториала - “Знакомство с Terraform”. Также под ссылкой на видео мы поделимся наиболее важными, на наш взгляд, преимуществами этого инструмента.

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

Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.

Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.

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

Во второй части статьи про bitrix кластер мы будет рассматривать настройку percona xtradb cluster mysql 5.7, настройка арбитра, настройка удобного dashboard.
Если вы пропустили предыдущие части: Первая часть.

Кто-нибудь из вас когда-нибудь слышал о теории “Чёрный лебедь”? Если говорить вкратце, то данная теория рассматривает труднопрогнозируемые события, которые несут за собой огромные последствия для всей системы. К примеру, ваш кластер k8s располагается в ДЦ в конкретно взятом регионе. Всё было прекрасно, но с берега пришло цунами и его затопило, вследствие чего все сервера стали недоступны и ваше приложение не работает. Так кто же в этом будет виноват? Карма? Подводные землетрясения? Ответ прост - вы сами.

«Spacelift» - это специализированная совместимая с Terraform платформа CI/CD для подхода «Инфраструктура как код». Она была разработана и внедрена опытными DevOps-инженерами на основе их предыдущего опыта с крупномасштабными ПО - а именно с помощью нескольких десятков команд, сотен инженеров и десятков тысяч облачных ресурсов.

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