Мы рады представить вам релиз GitLab 14.4 с запуском DAST-сканирований по расписанию, интегрированным в GitLab отслеживанием ошибок без использования отдельного инстанса Sentry, просмотром удалённых GitLab-репозиториев в Visual Studio Code, графиком динамики внедрения DevOps, GitLab Operator в общем доступе и многим другим!
Одновременно с ростом кластера растет количество ресурсов, volume и других API-объектов. Рано или поздно вы упретесь в потолок, будь то etcd, память или процессор. Зачем подвергать себя ненужной боли и проблемам, если можно установить простые — хотя и довольно изощренные — правила? Вы можете настроить автоматизацию и мониторинг, которые будут содержать кластер в аккуратном состоянии. В статье разберемся, как избавиться от лишних нагрузок, через которые утекают ресурсы, и устаревших накопившихся объектов.
HashiCorp Boundary — это пропускная система с открытым исходным кодом, которая обеспечивает пользователю безопасный доступ к динамическим хостам и критически важной инфраструктуре в разных средах. Однако, если вам нужен простой и безопасный способ управления доступом к базам данных, кластерам Kubernetes, облачным интерфейсам командной строки, коммутаторам, маршрутизаторам или внутренним веб-приложениям, можно рассмотреть и другие сервисы. В этой статье, мы рассмотрим несколько альтернатив и обсудим сильные и слабые стороны каждой из них. Итак, сделаем экспресс-анализ фичей каждого сервиса, которые, возможно, вас заинтересуют.
В Arenadata мы используем Jenkins для CI. Почему? Как бы банально это ни звучало — так исторически сложилось. Мы хранили код в GitHub, когда там ещё не было Actions, и продолжаем хранить, потому что много работаем с Open Source. За три года работы с Jenkins мы неплохо разобрались в нём, в том числе научились быстро масштабироваться, чтобы удовлетворять запросы разработки. В этой статье хочу поделиться тем, что мы успели понять про разные способы балансировки нагрузки в Jenkins. Если вам это близко, добро пожаловать под кат.
Студенты и специалисты в различных областях, связанных с информационными технологиями, смогут сдать экзамены на русском языке, чтобы получить международную сертификацию Microsoft. Получение Microsoft Certification является отличным способом входа в отрасль высоких технологий, сертификат позволяет подтвердить уровень знаний и опыта, что полезно как новичкам, так и профессионалам. Для тех, кто планирует развивать свою карьеру и становится востребованным на рынке, сертификация поможет выделить резюме среди остальных и даст возможность руководителю узнать степень профессиональной подготовки и компетентности.
Я давно искал какой-нибудь инструмент для низкоуровневой отладки сети Linux. Linux позволяет создавать сложные сети, запускаемые прямо на хосте, используя комбинацию из виртуальных интерфейсов и сетевого пространства имен. Когда что-то идет не так решение возникших проблем утомительно. Если это проблема маршрутизации L3, mtr (Matt's traceroute) имеет неплохие шансы принести пользу. Однако, если проблема на более низком уровне, обычно все заканчивается тем, что я вручную проверяю каждый интерфейс / мост / пространство имен сети / iptables и пару раз запускаю tcpdump в попытках понять что происходит. Если вы не знакомы с настройками сети, то при решении проблем в ней, вас ждет запутанный лабиринт.
Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.
В этой статье мы подробно расскажем о том, как мы трансформируем процессы разработки в наших командах и обрисуем план по внедрению TBD.
Продолжаем цикл статей о возможностях Roxy-WI. Сегодня мы поговорим ещё об одном важном наборе функций, связанных с управлением сервисами (а именно ― HAproxy и Nginx) в docker-контейнерах. Мы старались сделать эту функцию максимально простой и удобной в использовании. О том, что у нас получилось, и пойдёт речь ниже.
Как все члены наших проектных команд вдруг стали немножко DevOps’ами
Привет, Хабр! Мы недавно с коллегами читали статью компании Flant о динамических окружениях в GitLab и хотели бы поделиться с вами мыслями о том, почему мы эту, казалось бы, очень долгожданную и классную фичу не используем. Не потому что она плохая, а потому что организационно мы хотели получить решение, которое было бы доступно для использования всеми членами проектных команд, а не только DevOps-инженерами.
В этом посте мы рассказываем, почему нам не подошли средства GitLab, что мы хотели получить взамен и к какому альтернативному решению пришли. Если вам тоже хочется попробовать применить это решения для организации процессов в своих проектах, мы подготовили небольшой туториал, который поможет вам начать.
Эта статья о вреде выделенных команд DevOps инженеров в организации. Начну издалека. В книге Джорджа Массера "Нелокальность" приводится такой интересный момент оценки расстояния с точки зрения влияния. "Лев близко, значит он может напасть" - это о влиянии через определение пространства. Однако концепция "Лев может напасть, значит он близко" - нивелирует саму концепцию пространства. Так и альтернативный взгляд на DevOps может переопределить само понимание об его месте в производственном процессе. К сожалению, в сфере DevOps все скатывается в набор ритуалов и надутые щеки DevOps методологов-футурологов-идеологов и много чего. Речь разумеется не идет про лидеров индустрии, речь идет скорее про среднестатистические компании на рынке. Давайте перевернем все с головы на ноги!
Никита Соболев покажет множество функций Github Actions, поделится собственными впечатлениями и болями от первых месяцев использования, покажет, как сделать собственные инструменты.
Platform as a Service в Авито — это набор проработанных решений, которые позволяют продуктовой разработке не тратить много времени на рутинные задачи и низкоуровневые инструменты. Наши спикеры рассказали, как происходит локальная разработка, автоматическое тестирование, деплой и эксплуатация сервисов в PaaS. Собрали записи с таймкодами и презентации в посте.
В этой статье я хотел бы рассказать о том, как мы меняли подход к оркестрации на нашем стартап-проекте, зачем мы это делали и какие проблемы по дороге решали. Претендовать на уникальность эта статья вряд ли может, но все же думаю, что она может быть кому-то полезна, так как в процессе решения задачи материал собирался нами с приличным скрипом.
Что мы имели и о чем вообще речь? А имели мы стартап-проект с примерно 2-летней историей разработки из advertisement области. Проект изначально строился как микросервисный, и серверная его часть написана на Symfony + немного Laravel, Django и нативного NodeJs. Сервисы представляют из себя в основном API для мобильных клиентов (их в проекте 3) и нашего собственного SDK для IOS (встраивается в приложения наших кастомеров), а также веб-интерфейсы и разные дашборды этих самых кастомеров. Все сервисы были изначально докеризированы и работали под управлением docker-compose.
Правда, docker-compose использовался не везде, а только в локальном окружении у разработчиков, на тестовом сервере и внутри pipeline при сборке и тестировании сервисов. А вот в production окружении использовался Google Kubernetes Engine (GKE). Причем настройку GKE на старте проекта мы делали полностью через его web-интерфейс, что было довольно быстро и, как нам тогда казалось, удобно. Автоматизирован тут был только процесс сборки docker images для запуска сервисов в GKE.
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
Максимально переложив ответственность за онлайн своего приложения, ты сможешь сфокусироваться на других задачах, думать больше о новых фичах и новых приложениях. Ведь попробуй просто представить себе, как ты с утречка начинаешь поднимать 20 ботов на своём бедном Lenovo в надежде, что сегодня ни свет, ни интернет не выключится? Представил? А теперь представь если 20 ботов висят на сервере и ты с утра заходишь, смотришь какой у них статус с помощью удобного дашборда. Так и 21е приложение не за горами будет :)
Понимаю, всё звучит так классно, но ты возразишь, а деньги на сервер зачем выбрасывать? Тебе кажется, что твой бот только тебе и интересен, зачем же тратиться. А если я скажу что есть сервис, бесплатный, качественный, функциональный, который в начале кажется сложным, но как всё сложное, его нужно лишь понять и станет простым и отличным помощником.
Выглядит как промо за 50$, но на самом деле я был поражен лишь тем фактом, что если зайти на цены, то там есть раздел Hobby. Это на моей памяти первый случай, когда сервис есть в бесплатном виде, чтобы поддерживать начинания разработчиков, и потом, когда идея окажется работоспособной, тут же можно понемногу увеличивать возможности своего сервиса. Только за это уже можно читать дальше, разве нет?
Привет, Олимпийский Хабр! Меня зовут Аня, я работаю в Ozon: строю и развиваю инфраструктуру мониторинга в Observability-платформе. Моя команда помогает разработчикам следить за своими сервисами и своевременно получать алерты, если что-то идёт не так.
На Хабре довольно много статей о том, что такое кроны, как и где можно запускать их по расписанию, о плюсах и минусах каждого варианта и о том, как запускает кроны Kubernetes. Поэтому в моей статье об этом мы говорить не будем.
Я расскажу, как мы решали конкретную проблему мониторинга CronJob, запущенных в Kubernetes.
До конференции DevOops, посвященной инженерным DevOps-решениям, осталось меньше двух недель. Все спикеры на низком старте, программа составлена, и в этом хабрапосте рассказываем о ней.
На конференции будем не спорить о том, существуют ли девопс-инженеры (что тут спорить, не существуют), а делиться опытом реальных проектов, фейлами и историями успеха. И задавать вопросы об этом всем. Подробно о докладах — под катом.
У всех, кто запускал статический анализатор в первый раз на большом проекте, был небольшой шок по поводу сотен, тысяч или даже десятков тысяч предупреждений. Как-то грустно становится после такого. То ли код настолько плох, то ли анализатор привирает. В любом случае фильтрация по критичности поправляет ситуацию, правда не до конца. Поэтому мы и задумались, как можно улучшить первый опыт использования анализатора. Но обо всём по порядку...
Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Аннотации для мониторинга приложений и что делать когда их гибкости не хватает
Kubenav — бесплатное приложение с открытым исходным кодом. Его основная цель — предоставление удобного GUI для управления кластером Kubernetes из-под всех возможных платформ. Их ассортимент действительно богат: десктоп-клиенты (для Linux, macOS и Windows), мобильные (для Android и iOS), а также веб-версия.
