Доброго времени суток, дорогой читатель!

Последние несколько лет в решении бизнес задач прогрессирует тренд использования Искусственного Интеллекта. Перед специалистами, отвечающими за инфраструктуру встают вопросы о том, какие решения они могут предложить ML-специалистам для закрытия их потребностей в отказоустойчивой и гибкой инфраструктуре с учетом специфических потребностей сферы ML. В том числе растет число инструментов и фич, которые они предоставляют, и многие задаются вопросом: как собрать свой MLOps-стек, чтобы он был удобный, (желательно) бесплатный и закрывал большинство распространенных потребностей.

В сегодняшней статье рассмотрим способы реализации model serving, то есть инструментов, которые нужны для того, чтобы подготовить модель к деплою и запустить в Kubernetes.

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

Серия статей будет представлять собой теоретическую часть и практическую части. В сегодняшней - теоретической - части мы разберем все нюансы кластеризации и особенностей bitrix-составляющей.

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

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

В самом деле, с появлением новых методов работы, основанных на гибкости (вроде DevOps), некоторые принципы безопасности пришлось адаптировать к темпам развития и управления компонентами инфраструктуры. Сегодня одна из наиболее безопасных практик - это как можно раньше переместить эти контрольные точки в цепи интеграции, чтобы быстрее обнаруживать любые аномалии, заслуживающие особого внимания.

Я думаю, многие слышали про громкий инцидент произошедший с Tesla в 2018 году, когда группа хакеров через консоль Kubernetes смогли получить доступ к аккаунту. После чего изрядно повеселились и настроили майнер в облачном сервисе Amazon Web Services. У многих людей сразу же возникает вопрос в голове “Как они это сделали?” и “Почему многоуважаемые ИБ данной компании не подумали о потенциальной дыре в безопасности?”. Как правило при разработке любого продукта бывают лишь две причины возникновения уязвимостей. Первая причина - человеческий фактор. Кто из нас не забывал что-либо в ходе кропотливой работы над проектом и кто не откладывал в бэклог решение “не самых срочных вопросов..?”. И, наконец, вторая причина - отсутствие необходимых компетенций в той или иной области.

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

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

Почти 85% респондентов Upskilling IT 2022 заявили, что DevOps или DevSecOps являются важными или необходимыми операционными моделями. Поэтому мы обратились к представителям DevOps Institute, которые поделились своим мнением по этой важной теме. Вот несколько общих идей о том, как выстроить эффективную DevSecOps-стратегию:

Если у вас 1-2 проекта, а в каждом до 5 приложений, и вы раз в полгода создаете новый чарт в Helm, вы можете просто копировать старые чарты или создавать новые с нуля. Но что делать, если у вас 5 проектов, в каждом по 20 микросервисов, и каждые 2 недели ваши разработчики выкатывают новые и выкидывают старые? А еще надо постоянно что-то обновлять. А если проектов 20 или 50, что делать в этом случае? Тогда вы копируете одни и те же паттерны и шаблоны с общим костяком. Мы заметили это на одном из проектов, в котором нужно было запустить 15 микросервисов, и подумали, а почему бы не запилить единый чарт, через который будет запускаться вообще всё?

Меня зовут Роман Андреев, я DevOps инженер Nixys. Расскажу о практическом применении универсального чарта. На теории останавливаться почти не будем, только в общих чертах, потому что о ней мы уже говорили в предыдущих статьях.

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

Однако, в связи с известными событиями, лавочка по сдаче экзаменов у AWS закрылась, а если говорить точнее - то с переводами оплаты стало сложнее. А так как нам от многих компаний начали поступать запросы на миграцию в Яндекс, было принято решение поголовно пройти бесплатный курс от Яндекс.Практикум «Инженер облачных сервисов» для более близкого ознакомления с облачными ресурсами Яндекса. В первую очередь прохождение касалось именно junior-инженеров и тех, кому не доводилось работать в этом облаке.

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

Итак, каковы основные причины неудачных миграций в облака, и как снизить риски?

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

В этом материале мы будем практиковаться писать Ansible role для автоматического поднятия web-сервера.

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы будем писать Ansible role для поднятия полноценного готового сервера. Отметим, что если вы являетесь опытным администратором, можете смело пропускать данный материал.

Любое написание ansible роли сопровождается планом. В данный план необходимо будет включить все, что необходимо будет установить и настроить.

План:

Пункт 1. Первоначальная настройка сервера.

Пункт 2. Установка LEMP.

Пункт 3. Права и пользователь.

Пункт 4. Настройка LEMP.

Пункт 5. Перенос кода площадки и БД.

Пункт 6. Тестирование.

Пункт 7. Итог.

Компании-разработчики программного обеспечения уже давно полагаются на DevOps-подход с целью повышения уровня гибкости и качества коллабораций при поставке программного обеспечения. Пайплайны CI/CD автоматизируют процессы в жизненном цикле разработки программного обеспечения (SDLC), осуществляя плавную интеграцию и поставку новых функций. Совершенствование программного обеспечения за счет преобразования процессов  автоматизации и гибкости предполагает интеграцию многочисленных инструментов и сервисов, что может привести к возникновению пробелов в защите. Их выявление и устранение является ключом к обеспечению безопасности CI/CD. В данной статье рассмотрим, как защитить ваш пайплайн CI/CD. 

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

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Ansible, Ansible-Playbook, и как поднять полноценный веб-сервер с помощью системы автоматизации. Отметим, что если вы являетесь опытным администратором, можете смело пропускать данный материал.

В этом новом мире удаленной работы и облачных технологий Идентификация и управление доступом (IAM) выходят на первый план. Почти как если бы современная экономика полагалась на гибкую и автоматизированную IAM-систему для обеспечения стремительной и цельной цифровой трансформации. 

Okta ведущий игрок в сфере IAM, и уже достигла немалых успехов в этой области, осваивая искусственный интеллект, выходя таким образом за рамки стандартного использования пароля и других вариантов многофакторной аутентификации.

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

И хотя Okta наиболее популярна, это не означает, что у нее нет альтернатив. Есть несколько других вариантов для предприятий, желающих пойти по пути IAM, и каждый из них имеет свои преимущества. 

Среди этих вариантов - Active Directory Federation Services (ADFS), OneLogin и Akku. О каждой из них и расскажем в этой статье.

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

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

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

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

Настройка LEMP-сервера с помощью docker для простых проектов. Часть третья: docker-compose, Dockerfile.

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Dockerfile, docker-compose и как поднять полноценный веб-сервер с помощью docker. Отмечу, что если вы являетесь опытным администратором, можете смело пропускать данный материал. Эта статья призвана простыми словами объяснить, что такое контейнеры, виртуализация и все, что с этим связанно.

Настройка cервера с помощью docker для простых проектов. Инструкция для самых маленьких. Часть вторая: docker-compose.

Мы продолжаем цикл обучающих статей для самых маленьких наших читателей. В данном обучении мы бы хотели разобрать docker-compose. Данная статья рассчитана на начинающих системных администраторов. Если вы являетесь опытным администратором, можете смело пропускать данный материал. Она призвана объяснить простыми словами, что такое docker-compose. Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля, поскольку регулярно получаем большое количество базовых вопросов от людей, так или иначе, связанных с нашей сферой. Целью статей не является показать как развернуть идеальное окружение, а лишь указать на нюансы в работе и защитить начинающих специалистов от базовых ошибок при настройке.

При настройке CI/CD для приложений мы в компании, как правило, используем Vault от HashiCorp. К тому же сами приложения зачастую используют Vault для хранения секретных данных. Но для того, чтобы начать использовать Vault, сначала необходимо произвести его настройку. Раньше нам приходилось вручную производить подобные манипуляции для каждого проекта, что отнимало немало времени. Найти готовый модуль, который подошел бы нам, не удалось. Поэтому мы написали свой terraform-модуль, который позволяет автоматизировать данный процесс.

На текущий момент созданный нами terraform-модуль покрывает все наши требования, но в дальнейшем он будет дорабатываться. Модуль позволяет создавать политики доступа и хранилища секретов, включать необходимые способы авторизации (certs, jwt, oidc, kubernetes и т.д.), создавать токены, jwt/oidc/token-роли и идентификационные группы. Также при помощи него можно генерировать TLS-сертификаты и jwt ключи в определенной директории.