Обновить
256K+

DevOps *

Методология разработки программного обеспечения

442,05
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Создаем свою матрицу процессов DevSecOps

Время на прочтение5 мин
Охват и читатели2.8K

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

Современная разработка ПО в нашем понимании - это хорошо отлаженный DevSecOps с максимумом автоматизации, который опирается на облачную инфраструктуру. Считаем, что инфраструктура, включая контейнеризацию, есть и готова под любые наши хотелки. А вот что находится выше?

Стандартную восьмерку DevOps вы все видели, вот она.

Читать далее

Docker Swarm для самых маленьких

Время на прочтение13 мин
Охват и читатели245K

Данная статья посвящена настройке и работе с Docker Swarm.

Swarm это стандартный оркестратор для docker контейнеров, доступный из «коробки», если у вас установлен сам docker.

Что нам потребуется для освоения:

Читать далее

Kubernetes 1.24: обзор нововведений

Время на прочтение16 мин
Охват и читатели13K

Этой ночью представят новую версию Kubernetes. Удаление Dockershim — если не самое значимое, то уж точно самое обсуждаемое изменение в релизе 1.24. Также среди интересных нововведений: «мониторинг здоровья» томов; Network Policy Status для оценки состояния подресурсов; набор тестов, с помощью которых определяется готовность Windows-кластеров к production.

В обзоре рассказываем обо всех улучшениях — новых (alpha) и о тех, что перешли на уровень выше (beta, stable).

Читать далее

Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps-пайплайн

Время на прочтение7 мин
Охват и читатели2.8K

0937_SAST_In_SSDLC_ru/image1.png


Репутационные и денежные риски, связанные с уязвимостями, огромны. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки (SSDLC). Сегодня мы поговорим об одном из подходов, используемых в SSDLC, – SAST.

Читать дальше →

Хранение кода в SCM

Время на прочтение11 мин
Охват и читатели10K

Смотри, ты устроился работать в большую компанию, где много команд, каждая разрабатывает свой продукт, часть из них создаёт микросервисы вокруг ядра, часть создаёт свои отдельные полноценные продукты. И, допустим, вся разработка до сих пор не использует централизованное хранение кода, работает без CI/CD и без наработок DevOps. Твоей первой задачей поставили организовать подход к хранению исходного кода в рамках всей компании. По секрету скажу, большие компании любят, когда используется единый подход, индивидуализм для бизнес-конвейеров всегда означает сложность управления сроками разработки, поставки и т.д. Задача, которая кажется простой на первый взгляд, всегда обрастает сложностями в нюансах.

Ты настроен на волну NotOps и в этой статье я постараюсь ответить на вопросы:

Читать далее

Поиск вредоносного кода «голыми руками»

Время на прочтение2 мин
Охват и читатели5.7K

Последнее время появилась острая необходимость проверять, что прилетело с очередными обновлениями кода в папку /vendor /venv или любую другую, где лежат исходники внешних зависимостей проекта. (poetry, composer, go install и тд., кто на чем пишет).

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

Часть задач сводится к тому, чтобы найти определенный текст, ключевые слова, хардкод (например ip адрес) или опасный системный вызов. В голову сразу приходит grep. Но мы же хотим не только искать по одному слову и только в одном или группе файлов. Мы хотим проверить весь код по всем возможным словарям, которые определим сами.

Читать далее

Как избежать 10 частых ошибок в настройке NGINX

Время на прочтение17 мин
Охват и читатели88K


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


  1. Недостаточное количество файловых дескрипторов;
  2. Директива error_log off;
  3. Отсутствие keepalive-соединения с вышестоящими серверами;
  4. Упущение механизмов наследования директив;
  5. Директива proxy_buffering;
  6. Неправильное использование директивы if;
  7. Чрезмерные проверки работоспособности;
  8. Незащищенный доступ к метрикам;
  9. Использование ip_hash, когда весь трафик поступает из одного и того же блока /24 CIDR;
  10. Игнорирование преимуществ вышестоящих групп.
Читать дальше →

Особенности платформы Rancher для управления кластерами Kubernetes

Время на прочтение11 мин
Охват и читатели62K

Spaceship Central Bridge concepts by SolarSouth

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

Команда Kubernetes aaS VK Cloud Solutions написала статью, посвященную платформе управления Kubernetes Rancher. Мы собрали для вас в одном месте всю основную справочную информацию об этой платформе: ее основных функциональных особенностях, кластерных операциях, внутреннем устройстве, безопасности и интеграции с внешними системами. И расскажем, когда вам подойдет именно Rancher, а когда стоит обратить внимание на другие инструменты.
Читать дальше →

Микрооблако. Второй шаг. Создание виртуальной сети

Время на прочтение14 мин
Охват и читатели5.4K

Мы живем в мире, где зависимость от того или иного вендора может привести к катастрофе. Если базировать свой бизнес на Google Cloud, AWS или Azure, или даже каком-то отечественном аналоге, то в любой момент тебе могут сказать, что твоё облако больше не твоё. А ты уже привык или привыкла (я очень надеюсь тут на женский взгляд на проблему) к их гитлабу, нексусу и прочим плюшкам, которые доступны из коробки и заинтегрированы между собой и твоим проектом. Как быть?

Решение тут одно. Нам не нужно одно гигантское облако, как нам не нужны моносервисы. Ими сложно управлять. Нужны микросервисы и микрооблака. Представьте, что вы хотите создать своё приложение для знакомств. Разве вам для его работы нужны ксеоны и прочие суперпроцессоры? Вряд ли. Нужен ли вам гигантский дата-центр? Ответ тот же. Скорее всего, вам достаточно 2-4 виртуалок обычного типа, на которых нужно запустить ваше приложение и небольшую инфраструктурную обвязку вроде api-gateway и sso, а также гитлабов и нексусов, если речь идет о контуре разработки. И обойдется это вам гораздо дешевле. Проблема только в том, что хостингов виртуалок на рынке полно, а вот удобно инструмента превращения этих виртуалок в своё небольшое облако - нет. А теперь представьте, что такой инструмент есть. Тогда если хостинг скажет вам "прости-прощай и собирай манатки", то мы просто берем и переезжаем со словами "а ну и пожалуйста, не очень то и хотелось".

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

Читать далее

Свой Composer без баннеров

Время на прочтение2 мин
Охват и читатели9.6K

Короткий мануал их 7 шагов о том, как собрать из официальных исходников свой Composer без политических лозунгов авторов или просто внести свои изменения и подписать валидной сигнатурой.

Читать далее

PHDays 2022 примет финал Всероссийского конкурса open source проектов

Время на прочтение2 мин
Охват и читатели888

В этом году на площадке Positive Hack Days пройдет финал первого Всероссийского конкурса open source проектов школьников и студентов по направлению «Кибербезопасность». Мероприятие организовано Кружковым движением Национальной технологической инициативы при поддержке Минцифры, Минобрнауки, Positive Technologies и других IT-компаний России.

Регистрация открыта, работы принимаются до 10 мая.

Подробности

О безопасности Kubernetes. Часть 1. Об угрозах

Время на прочтение5 мин
Охват и читатели7.3K

Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.

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

В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.

Читать далее

Оптимизация инфраструктуры: снижаем счет за ресурсы без ущерба для бизнеса

Время на прочтение8 мин
Охват и читатели5.4K

Аудит лишних подписок и участившихся походов в бар — первое, что делает человек, который хочет больше экономить. То же самое можно и нужно делать на уровне компании, когда речь идет о счетах за IT-инфраструктуру. Сегодня поговорим о ряде мер, которые помогут уменьшить ежемесячный платеж за аренду серверов и сопутствующих услуг. Разделим их на базовые, легкие, сложные в реализации и бесплатные.
Читать дальше →

Ближайшие события

Как сэкономить на ресурсах с помощью модуля Terraform для AWS Spot Instance

Время на прочтение9 мин
Охват и читатели3K

Иногда бывает довольно сложно сэкономить на Spot Instance Amazon Web Services (AWS). Не стоит забывать, что по сути это — аукцион. Цены хоть и не меняются так же резко, как на биржах, тем не менее могут расти, пока не достигнут ondemand. Бывает, что такое продолжается не день и не два, а до нескольких месяцев, что приводит к повышению расходов вдвое на обычные ресурсы.

Как не попасть в ситуацию, когда, например, в ноябре всё прошло отлично, а в декабре из-за праздничного ажиотажа прайс удвоился, и вы получили не только дорогую систему, а ещё и с прерыванием? Давайте разберем причины, почему так происходит. Для этого рассмотрим стратегии распределения Spot Instance и поймем, как можно использовать модуль Terraform без всех этих проблем и при этом еще и сэкономить. В этом нам поможет инженер по облачным сервисам и архитектор AWS Владимир Самойлов, участник сообщества FivexL.

Читать далее

Как я вырос из узкого специалиста по эксплуатации в DevOps-инженера

Время на прочтение8 мин
Охват и читатели7.1K

В прошлом году мы в Southbridge запустили стажерскую программу. Стажировку прошли более 80 инженеров. Мы получили много обратной связи, учли разные нюансы и переупаковали программу учебной стажировки в курс DevOps Upgrade в Слёрме.

Сегодня рассказываем историю Вячеслава Лочашвили, который работал в отделе эксплуатации интернет-провайдера, полностью прошел нашу стажировку и теперь трудится в одной из команд Southbridge в роли DevOps-инженера. Передаём слово Вячеславу.

Читать дальше

Ansible: с чего начать и как не перейти на темную сторону

Время на прочтение6 мин
Охват и читатели19K

Николай Месропян, системный инженер Southbridge, подробно рассказал редакции Слёрма о шестилетнем опыте работы с Ansible. Что стоит за слоганом «Simple IT automation»? Почему нельзя остановить темное движение мысли специалиста? И насколько это ясно на старте работы с Ansible? Николай досконально «разложил» все плюсы инструмента на минусы и наоборот.  

Посмотреть раскладку

Автоматизация changelog в системе сборки Gradle

Время на прочтение4 мин
Охват и читатели2.3K


Маленькой команде не составляет труда поддерживать историю изменений приложения в ручном режиме. Но, когда команда начинает расширяться, такой файл как changelog, находящийся в системе контроля версий, становится «узким горлышком» и приводит к постоянным конфликтам и росту напряжения в команде.


На помощь, как всегда, приходит автоматизация. Если интересно узнать о том, как автоматизировать генерацию changelog в gradle проекте, добро пожаловать под кат.

Читать дальше →

Метрики потока создания ценности

Время на прочтение2 мин
Охват и читатели2.6K

Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно.

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

С другой стороны, всегда, когда речь идёт про часто повторяющийся процесс, опирающийся на труд персонала, я агитирую за наличие разумного набора метрик. Так можно убрать разрыв между «я думаю» и «на самом деле», так можно увидеть где теряются деньги и другие ресурсы, так можно проще запустить процесс и сделать его лучше. Вот почему в первых же консалтинговых проектах в 2005-м мы с клиентами проектировали для каждого процесса метрики его эффективности, производительности и прочего. Вот почему сейчас для каждой новой команды разработки ПО вопрос измерения я с клиентами начинаю обсуждать как только речь заходит об организации работы. Без фанатизма, а как один из инструментов наладки.

Кроме метрик, вторая моя любимая тема — поток создания ценности. Этой идеей я увлёкся намного позже, когда до меня, наконец-то, дошло, как можно построить работающий (а не декларируемый) поток в интеллектуальной работе по разработке программного обеспечения. Спасибо ребятам из IT Revolution, они (в числе прочих) помогли мне сложить для себя новую, понятную, непротиворечивую и весьма прикладную картину мира. Многое встало на свои места. Несколько десятков команд мы помогли организовать по принципам потока создания ценности и я вижу, насколько мощный это инструмент.

Читать далее

Безопасная разработка и уязвимости программного кода

Время на прочтение6 мин
Охват и читатели5.4K

Часть 2. Как искать ошибки в чужом коде

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

Читать далее

Приглашаем в машину времени: что вам понравилось на прошлогодних конференциях TechLead и DevOps

Время на прочтение4 мин
Охват и читатели975

Наша объединенная конференция DevOps&TechLead 2022 года уже очень скоро! И пока мы ее вовсю готовим, давайте вспомним, как закончились конференции в прошлом году — и какие доклады вам понравились. Если вы уже участвовали в наших конференциях DevOps&TechLead — это будет для вас как небольшое путешествие в прошлое, где мы воссоздадим в памяти атмосферу и эмоции. А если вы всё пропустили, то сегодня вы сможете представить, как там было. Поехали!

Конечно, в первую очередь докладчики делились проблемами, которые преодолели, предлагая пошаговые сценарии выхода из них. Главная фишка конференций, и наших в том числе — польза. Вы получаете не безликую теорию, а проверенные и еще раз перепроверенные на практике механизмы, метрики и подходы. Которые уже упростили жизнь командам, помогли выявить и решить проблемы.

Читать далее