Привет, Хабр! В этой статье хотел бы поделиться опытом участия в процессе цифровизации огромной компании. Под катом расскажу об особенностях, с которыми столкнулся при взаимодействии с большим количеством команд разработки. На их основе во второй части статьи рассмотрим, какие принципы помогли справиться с работой в таких условиях и оптимизировать ее.
Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.
Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.
Ну а API-шлюз, как новинку в этой области, мы оставили на десерт, решив посвятить ему целый пост.
Во второй части статьи про bitrix кластер мы будет рассматривать настройку percona xtradb cluster mysql 5.7, настройка арбитра, настройка удобного dashboard.
Если вы пропустили предыдущие части: Первая часть.
Кто-нибудь из вас когда-нибудь слышал о теории “Чёрный лебедь”? Если говорить вкратце, то данная теория рассматривает труднопрогнозируемые события, которые несут за собой огромные последствия для всей системы. К примеру, ваш кластер k8s располагается в ДЦ в конкретно взятом регионе. Всё было прекрасно, но с берега пришло цунами и его затопило, вследствие чего все сервера стали недоступны и ваше приложение не работает. Так кто же в этом будет виноват? Карма? Подводные землетрясения? Ответ прост - вы сами.
«Spacelift» - это специализированная совместимая с Terraform платформа CI/CD для подхода «Инфраструктура как код». Она была разработана и внедрена опытными DevOps-инженерами на основе их предыдущего опыта с крупномасштабными ПО - а именно с помощью нескольких десятков команд, сотен инженеров и десятков тысяч облачных ресурсов.
При этом стартовать работу со Spacelift очень легко. Можно начать с нуля, и менее чем за одну минуту перейти к полному управлению вашего облачного хранилища без какой-либо предварительной подготовки. Она прекрасно интегрируется с такими крупными платформами как GitHub и AWS.
Доброго времени суток, дорогой читатель!
Последние несколько лет в решении бизнес задач прогрессирует тренд использования Искусственного Интеллекта. Перед специалистами, отвечающими за инфраструктуру встают вопросы о том, какие решения они могут предложить 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. О каждой из них и расскажем в этой статье.