Один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. А ФСТЭК суров. Перед нами была поставлена задача: настроить шифрование бэкапов. В статье покажу, как мы это сделали.
Ещё расскажу вам про такой инструмент как clickhouse-backup, распишу его плюсы и минусы и продемонстрирую, как легко восстановить данные из шифрованных бэкапов.
Эта статья предназначена для тех, кто только начинает свой путь в мире Kubernetes и хочет понять, как развернуть кластер Kubernetes на собственных серверах с отказоустойчивым балансировщиком в виде MetalLB.
MetalLB — это решение для балансировки нагрузки в средах Kubernetes, которые не имеют доступа к встроенным балансировщикам, как в облачных провайдерах. Этот инструмент предлагает простой и эффективный способ добиться внешней доступности для сервисов в Kubernetes с помощью собственной инфраструктуры.
Связка MetalLB, Longhorn и Kubespray позволяет обойтись меньшим количеством виртуалок и построить закрытую, высокоэффективную систему, способную удовлетворить специфические потребности вашего бизнеса.
Приветствую всех читателей!
Подошло время для второй части нашей серии статей по настройке почтового сервера. Напомню, что в первой части мы рассмотрели основные моменты, касающиеся настройки почтового сервера, а также конфигурировали Exim4 для корректной отправки почты.
В этой статье мы настроим полноценный почтовый сервер. Использовать будем PostfixAdmin, Dovecot и RainLoop.
В этой серии переводов выясним, что вам нужно учесть при создании современных облачных приложений. В первой части поговорим про бизнес-требования, которые влияют на инфраструктурные решения и работу с командой
Всем привет, на связи Пётр, инженер компании Nixys. В прошлой статье мы разобрали основные концепции Redis. Теперь рассмотрим базовую репликацию Redis и настроим эту БД на высокий уровень отказоустойчивости.
В финальной статье мне хочется поделиться кейсом повышения безопасности одного из самых важных компонентов инфраструктуры — базы данных (в моём случае — PostgreSQL v14 с управлением через patroni). Расскажу про то, как повысить скорость анализа потенциальных инцидентов, как настроить процессы шифрования дисков, как сгенерировать SSL‑сертификаты для базы данных и обеспечить их двухстороннюю проверку. А ещё поговорим про бэкапы и wal‑g-backup. Надеюсь, статья поможет каждому избежать ошибок в планировании и узнать что-то новое.
Всем привет, меня зовут Пётр, я инженер компании Nixys. На современных проектах используется огромное разнообразие баз данных: реляционные, ключ-значение, документоориентированные. Особое место среди них занимают колоночные базы данных, ярким представителем которых является ClickHouse. Это мощный инструмент, который способен обрабатывать миллиарды строк в секунду при минимальном времени ответа. Однако, для максимальной эффективности ClickHouse необходимо понимать ряд фундаментальных моментов для того, чтобы использовать его по назначению. В этой серии статей мы разберем особенности работы ClickHouse, которые помогут в выжимании максимума из этой базы. И сегодня начнём с фундаментальных теоретических моментов, чтобы составить максимально полное общее впечатление, которое поможет нам в дальнейшем.
Очень часто на этапе стажировки новых сотрудников мы в нашей компании сталкиваемся с типичными простыми ошибками, непониманием работы DNS и почты. При этом обучение новых сотрудников по этой теме — достаточно длительный и сложный процесс, так как сами вопросы требуют построения сложных логических цепочек в голове у начинающего инженера. В один момент мы составили свою вики и схемы для обучения и решили поделиться этим опытом на Хабре в виде серии статей, чтобы людям, которые решили связать свою жизнь с IT вообще и администрированием в частности, стало проще. Материалы этой серии предназначены для начинающих администраторов.
В этом материале будет представлена связка полноценного почтового сервера в виде Exim4+Dovecot+PostfixAdmin+RainLoop.
Что-то было модно, что-то вышло из моды, а что-то вечно и вечность в нашей статье — это кибербезопасность. В рамках серии статей хотелось бы поговорить об этом и поделиться нашим опытом.
Во второй части я продолжу рассказ про проект, с которым мы уже познакомились ранее.
1. Напомню про требования:
2. Замкнутый контур;
3. Отсутствие CVE во всех используемых продуктах;
4. Контроль безопасности уже имеющейся инфраструктуры;
5. Контроль доступа до среды;
6. Автоматизация процессов.
Но как быть, если ваша инфраструктура располагается в рамках kubernetes оркестратора? Как быть, если вы используете managed решение? Какие подходы для организации безопасности будут применимы? Под катом — про это, а еще про Managed Service for Kubernetes и Yandex Cloud, Kyverno, Tetragon, Falco и многое другое.
Давайте посмотрим, что было дальше?
Кибербезопасность сейчас в тренде, безопасность инфраструктуры и ПО, располагаемого в ней, тоже. В рамках серии статей хотелось бы поговорить об этом и поделиться нашим опытом.
В первой части я расскажу про проект, который недавно пришел к нам с таким ТЗ:
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.