DevOps *

Kubernetes — это платформа для оркестровки контейнеров, которая позволяет запускать и управлять контейнеризированными приложениями. Иногда необходимо провести отладку или протестировать приложение локально, но при этом не безопасно открывать его внешнему миру. В этом случае на помощь приходит команда kubectl port-forward. Она позволяет перенаправлять трафик с вашего локального компьютера на под, в котором находится контейнеризированное приложение.

Перевели гайд о том, как использовать kubectl port-forward для перенаправления сетевого трафика с нашего локального компьютера на под с веб-сервером nginx. 

Распространённый подход к разработке — аккумулирование всех обновлений в единый пакет с последующим развёртыванием новой версии программного обеспечения. Это простая, понятная, отработанная годами схема, которая отлично подходит небольшим командам с маленьким количеством проектов и изменений. В больших проектах, когда к созданию кода привлечены несколько человек одновременно, это перестаёт работать — все ждут всех, задачи накапливаются, релизы становятся реже. И тогда на помощь приходит практика CI/CD.

Говорят, программисты делятся на два типа: тех, кто использует систему контроля версий, и всех остальных. В Sminex мы причисляем себя к первому типу. Причём, смеем утверждать, что мы один из очень немногих девелоперов, кто успешно внедрил практику CI/CD (Continuous Integration/Continuous Delivery, непрерывные интеграция и поставка) при работе с платформой 1С. Если вообще не единственный. Нам такой подход оказался крайне необходим.

Сначала у меня появилась Orange Pi Zero 2 W, на пробу. Под планируемые задачи она не подошла, но 4 ядра и 4G памяти и размеры понравилось. Так же понравился Type-C и WiFi из коробки. Потом я вспомнил что давно хотелось just for fun попробовать собрать кубер на одноплатниках, а такой объём памяти и ядер уже даже позволяет идее иметь некоторый смысл. При этом wifi позволяет сделать кластер максимально без проводным, а размер позволяет соорудить кубический куб на ладони. И сегодня идея материализовалась.

Эта статья — продолжение истории про разработку Ansible-модулей для взаимодействий с системами хранения данных (СХД) через API, которое удовлетворяет спецификации Swordfish. Эти модули в перспективе облегчат управление парком СХД от разных производителей.

Чтобы тестировать работоспособность созданных модулей, нужен настоящий сервер СХД (или тестовый mock-сервер), который предоставляет необходимый REST API. Получить настоящий сервер от производителя СХД — сложная задача, которая требует финансовых и временных затрат на получение программно-аппаратного обеспечения. В случае open-source разработки такая опция доступна не всем командам. 

Компания SNIA, разработчик спецификации Swordfish, подумала об этом и предоставляет разработчикам свободно распространяемый mock-сервер — Swordfish API Emulator. В рамках проекта Лаборатории YADRO на базе СПбПУ Петра Великого мы протестировали его в работе. В статье расскажем, как он устроен и как с ним взаимодействовать в задачах.

YAML (.yml) — популярный язык для конфигурационных файлов, широко используемый DevOps в подходе «Инфраструктура как Код» (IaC). Несмотря на то, что работать с ним бывает проще, чем с тем же JSON (особенно в контексте взаимодействия с большими объемами данных), иногда использовать его бывает трудно. В этой статье мы рассмотрим несколько советов, которые помогут упростить процесс создания и редактирования yml-файлов.

Все вы знаете, зачем посещать конференции. По крайней мере, на всех рекламных баннерах и других рекламных материалах пишут что-то похожее. Это обновление знаний, обмен опытом, soft skills, новые контакты и «тусовка». На самом деле это не всё, что даёт нам посещение профессиональной конференции. Давайте посмотрим, что ещё вы можете получить на примере DevOpsConf 2024:

Изучение реальных кейсов

Получение обратной связи

Поиск вдохновения и мотивации

Не задумывались ли вы когда-нибудь над тем, чтобы знать о каждом входе на ваши сервера? Меня охватила такая же паранойя: а вдруг, когда я сплю, на мой сервер заходит домовой и творит там ужасы? Хотя логин на наши сервера и запрещен по паролю, а SSH-ключи есть только у меня, в любом случае это вызывает большие опасения.

В этой статье мы развёрнем через Terraform несколько серверов в Yandex.Cloud, а затем при помощи Ansible настроим необходимый софт на каждом сервере. У нас будет основной сервер c Loki (система агрегирования логов) и Grafana (инструмент для визуализации данных), на серверах, которые мы хотим отслеживать, будет установлен Promtail (агент для сбора и отправки логов). Мы разберёмся с тем, как отслеживать входы на сервер, а затем в удобном формате отправлять об этом уведомления в чат с помощью вышеуказанных сервисов.

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

Мы создали универсальное, полностью автоматизированное решение по быстрой сборке VDS, сохранив баланс между удобством и безопасностью. Как это удалось и чем пришлось пожертвовать — под катом.

Разработчики используют плагины каждый день, и их функциональность призвана упростить разработку, например, автоматически проверять проставление всех специальных символов (таких как «;», «:») или соблюдение синтаксиса. Они буквально были созданы для того, чтобы разработчики прямо во время написания кода могли осуществить его проверку на уязвимости и сразу исправлять их, не выходя из IDE. Давайте разберемся, какие бывают плагины и как с ними работать?

Тема, которая будет сегодня освещена, рассказывается от лица backend разработчика. На нашем проекте нет devops'а, который бы мог подсказать, направить. Поэтому нам пришлось выходить из зоны комфорта.

Мы очень любим Kubernetes и мечтаем чтобы все современные технологии поскорее начали использовать его замечательные паттерны.

А вы когда-нибудь задумывались о том чтобы построить своё собственное облако? Могу поспорить что да. Но можно ли это сделать используя лишь современные технологии и подходы, не покидая уютной экосистемы Kubernetes? Нам по опыту разработки Cozystack пришлось с ним как следует разобраться.

Да, вы могли бы возразить что Kubernetes для этого не предназначен и почему бы не использовать OpenStack для Bare Metal-серверов а внутри него запускать Kubernetes как положено. Но поступив так, вы просто переложите ответственность с ваших рук на руки OpenStack администраторов. Что добавит как-минимум ещё одну сложную и неповоротливую систему в вашу экосистему.

Зачем так всё усложнять? - ведь на данный момент Kubernetes уже имеет всё необходимое для запуска Kubernetes кластеров.

Речь пойдёт о сервисе, который изначально мы задумали как внутрикорпоративную систему проверки контрагентов, а затем разработали как коммерческий продукт. Коротко расскажем о том, что делает система, с какими проблемами столкнулись при разработке и как их решали, как запускали, разворачивали, и немного коснемся того,  что “под капотом” у DevOps. Полагаю, что пост позволит оценить усилия команды при создании сервиса, подсветит использование некоторых технических решений, которые нам показались оптимальными, покажет типичные проблемы систем с парсингом из множества разнотипных источников, и будет полезен коллегам при разработке других продуктов. Я честно постараюсь минимизировать рекламную составляющую до короткого дисклеймера и избавить пост от маркетинг булшит. 

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер работает под управлением Deckhouse Kubernetes Platform, а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

Классификация инцидентов по степени серьёзности – ключевой момент в управлении инцидентами. Она нужна, чтобы SRE команда могла быстро и эффективно устранять неполадки в сложных системах и минимизировать их влияние на клиентов. В этой статье описана система SEV (Security Evaluation Version), которая помогает стандартизировать процесс устранения проблем, быстрее восстановить работу системы и уведомить о происшествии всех, кого это касается, в зависимости от серьёзности инцидента.

Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.

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

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

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

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