Методология разработки программного обеспечения
Вы когда-нибудь задумывались о том, какие вопросы задают DevOps инженеру на собеседовании? Да, есть вполне обоснованное мнение, что таких инженеров в принципе быть не может (или все инженеры команды являются проводниками методологии DevOps), но все же на рынке хватает вакансий «DevOps Engiineer» разных уровней. Сегодня мы рассмотрим вопросы DevOps инженерам высшего (без пипл менеджмента) уровня – Senior.
В статье мы расскажем, как столкнулись с множественными запросами к API-серверу Kubernetes от одного из приложений, к чему это привело и каким образом проблема была решена.
Revel: для быстрой разработки и масштабируемости
Revel — один из самых популярных фреймворков для разработки веб-приложений на Golang в текущем году. Он прост в изучении и использовании; подходит как для начинающих, так и для опытных специалистов. Хорошо справляется с быстрой разработкой приложений, демонстрирует высокую масштабируемость и производительность.
Несколько месяцев назад коллеги, работающие с одним из кластеров Kubernetes в dev-окружении, обратились с проблемой недоступности API-сервера Kubernetes. Dev-среды обычно не подключены к дежурной смене, и решением проблем занимаются владельцы или, если проблемы нестандартные, обращаются к профильным специалистам. В ходе диагностики оказалось, что kube-api стал потреблять значительно больше памяти. Это приводило к возникновению ошибки с OOM.
Давайте будем честными — если бы это произошло в production-окружении, мы, скорее всего, закинули бы больше памяти и успешно бы забыли про проблему. Но dev-стенд не имеет жёстких SLA с финансовой ответственностью, и это дало нам возможность и время разобраться с прожорливым kube-api.
Всех, кому интересно, что из этого вышло, прошу под капот.
Всё еще публикуете релизы Android приложений вручную? Почитайте наше подробное руководство как полностью автоматизировать публикацию Android приложений в Google Play и Huawei AppStore через Gradle и CI/CD. Подробно от А до Я.
Разработка собственной Kubernetes-платформы — большой и сложный проект со множеством взаимодействующих компонентов. В процессе неизбежно сталкиваешься с различными трудностями. Иногда их даже создаешь себе сам. В статье кратко рассмотрим три проблемы, с которыми нам пришлось столкнуться во время подготовки Deckhouse 1.43 к релизу, как мы их устраняли и какие выводы из всего этого сделали.
Не так давно мы в компании столкнулись с маленькой проблемкой - RabbitMQ (далее просто кроль и тп) на дев кластере упал, мы его оживили, а за definitions.json для восстановления юзеров, очередей и тд. пришлось бегать к разработчику, который по чистой случайности эти файлики часто снимал. Это был первый звоночек.
Вторым звоночком стал DR (Disaster Recovery) - сценарий/упражнение по экстренному поднятию нашего продукта в облаке в случае взрыва и уничтожения нашего физического дата центра. Тут надобность в бэкапах нашего кролика стала очевидной и мы занялись решением этой проблемы
Кратко о том, какие способы управления конфигурацией (создание пользователей, очередей и т. д.) RabbitMQ имеют место быть.
В данной статье мы расскажем как перевести статический веб-сайт с Markdown (Zola, Hugo, Jekyll, Pelican, Gatsby, и д.р.) на все языки мира и поддерживать переводы в актуальном состоянии при изменении исходных текстов.
Какие вызовы стоят перед Kubernetes? Каким будет текущий, 2023 год? Что ждет Kubernetes в будущем? Мы проанализировали различные профильные исследования и постарались выделить все самое интересное, чтобы ответить на эти и другие вопросы. Рады поделиться с вами полученной информацией.
Сегодняшняя статья будет посвящена Docker Compose. При работе с контейнерами Docker рано или поздно наступает момент, когда наше приложение превращается в несколько распределенных сервисов, которым необходимо взаимодействие друг с другом. В таком случае для автоматизации управления компонентами такого распределенного приложения нам потребуется Docker Compose. В качестве примера такого приложения можно привести веб ресурс, взаимодействующий с базой данных или служба, использующая дополнительные компоненты, такие как кэш Redis.
Docker Compose это средство, предоставляющее способ организации управления несколькими контейнерами для совместной работы. Если вы используете модель микросервисов для разработки своего приложения, вы можете использовать Docker Compose для разделения кода приложения на несколько независимо работающих служб, которые взаимодействуют с помощью веб-запросов.
По сути, Docker Compose это тот же Docker, но позволяющий автоматизировать работу с более сложными приложениями. Кроме того, для сценариев с одним контейнером использование Docker Compose обеспечивает независимую от инструмента конфигурацию таким образом, чего не делает отдельный файл Dockerfile. Параметры конфигурации, такие как подключение тома для контейнера, сопоставления портов и переменные среды, могут быть объявлены в файлах docker-compose YML.
Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys — мы помогаем другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.
А еще — делимся знаниями и опытом в этой сфере. Сегодня представляем продолжение серии обучающих видеороликов на YouTube "Terraform: от незнания к best practices" и выкладываем сразу два видео!
Привет! Меня зовут Михаил Черешнев, я работаю в компании Swordfish Security, где плотно занимаюсь вопросами внедрения DevSecOps. В этой статье мы рассмотрим процесс безопасной разработки контейнеризированных приложений от IaC манифестов до Runtime. А также попробуем определить самые простые и эффективные методы обеспечения защищенности и приземления технологий с минимальными затратами.
Вы слышали о Red Hat OpenShift и VMWare Tanzu? Мы сделали российскую альтернативу этих продуктов. Сегодня я хочу поделиться, как мы с командой собираем комплект баз данных, которые можно использовать для запуска микросервисных приложений.
Привет! Меня зовут Денис, я бэкенд-тимлид в KTS.
Tarantool и Redis по большей части — два очень разных продукта. Начиная от заложенной в них функциональности и заканчивая протоколом, репликацией и кластерными решениями.
Тем не менее в них много схожего. И в статье мы хотим рассмотреть: что, если взять Tarantool как замену Redis? Просядет ли производительность из-за всех «дополнительных» фичей в Tarantool? Насколько хорошо или плохо справится дисковая подсистема с нагрузкой?
Мы взяли типичные кейсы работы с Redis и реализовали такие же механики на Tarantool, начиная от простых K-V операций и заканчивая вторичными ключами и производительностью кластерных решений: для Tarantool это Tarantool Cartridge, для Redis — Redis Cluster.
Нередко управление «мобильным» CI/CD ложится на плечи разработчиков, хотя это и не относится к их основным обязанностям напрямую. Тогда возникают проблемы, связанные со снижением производительности и неэффективным расходованием времени.
Чтобы оптимизировать управление «мобильными» CI/CD, важно иметь в команде человека, который разбирается и в мобильной разработке, и в CI/CD. Идеальная ситуация, когда это бывший разработчик мобильных приложений, который перешёл на должность инженера. Но, конечно, такой человек есть не везде. В статье дальше делимся правилами и рекомендациями, которые помогут избежать трудностей при настройке Jenkins для Android-проектов.
Микросервисная архитектура сильно впечаталась в умы разработки. Но на проде все это не всегда вызывает много энтузиазма. Все это, скажем так, давно известные истины. Но как быть? Надо как-то этим управлять.
Что получится, если объединить Prometheus, работающий на Kubernetes, умный движок, взаимодействующий с ChatGPT, и мессенджер типа Slack? Вы получите платформу с открытым исходным кодом для поиска и устранения ошибок в Kubernetes под названием Robusta.
В этом посте мы рассмотрим применение Robusta поверх стека мониторинга Prometheus и покажем, почему возникают алерты и как их можно устранить.
