Управляющий партнер / CEO @ Nixys
Когда компании только начинают рассматривать возможность переноса своих рабочих нагрузок в облако, они часто представляют его как идеальное решение, которое поможет решить все проблемы с масштабируемостью, доступностью и сокращением расходов на IT. Однако, иногда на пути к своей цели организации принимают неверные решения.
Для выполнения похожих задач в Docker нередко есть несколько решений. Одна запутанная область касается инструкций RUN, CMD и ENTRYPOINT Dockerfile. В этом переводе обсуждаются различия между этими инструкциями и показываются примеры их использования в форматах shell и exec.
Всем добрый день, я Станислав Тибекин, CEO компании Nixys. Мы продолжаем серию переводов статей Эяля Эстрина из AWS про особенности создания cloud-native приложений. В этой части обсудим вопросы безопасности.
В этой серии переводов выясним, что вам нужно учесть при создании современных облачных приложений. В первой части поговорим про бизнес-требования, которые влияют на инфраструктурные решения и работу с командой
Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”
На конференции DevOps Conf 2023 я как раз рассказываю об этом, а в качестве основного критерия для выбора модели взаимодействия предлагаю использовать этап жизненного цикла вашего продукта.
Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.
Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.
Ну а API-шлюз, как новинку в этой области, мы оставили на десерт, решив посвятить ему целый пост.
«Spacelift» - это специализированная совместимая с Terraform платформа CI/CD для подхода «Инфраструктура как код». Она была разработана и внедрена опытными DevOps-инженерами на основе их предыдущего опыта с крупномасштабными ПО - а именно с помощью нескольких десятков команд, сотен инженеров и десятков тысяч облачных ресурсов.
При этом стартовать работу со Spacelift очень легко. Можно начать с нуля, и менее чем за одну минуту перейти к полному управлению вашего облачного хранилища без какой-либо предварительной подготовки. Она прекрасно интегрируется с такими крупными платформами как GitHub и AWS.
Контролировать качество исходного кода как можно раньше в жизненном цикле проекта - хорошая практика. Давайте разберемся, как применять этот принцип в работе с Kubernetes.
В целом, компании всегда ищут способы увеличить свою продуктивность на всех уровнях: инфраструктура, люди, процессы и др. Зачастую продуктивность достигается за счет внедрения автоматизированных процессов для облегчения работы и увеличения темпов производства. Подобная автоматизация требует эволюции, адаптации или даже полной трансформации концептов, используемых ранее. Это включает в себя обеспечение и контроль политик безопасности.
В самом деле, с появлением новых методов работы, основанных на гибкости (вроде DevOps), некоторые принципы безопасности пришлось адаптировать к темпам развития и управления компонентами инфраструктуры. Сегодня одна из наиболее безопасных практик - это как можно раньше переместить эти контрольные точки в цепи интеграции, чтобы быстрее обнаруживать любые аномалии, заслуживающие особого внимания.
Когда дело доходит до защиты ваших облачных ресурсов, безопасность должна быть основным приоритетом всей организации. Путь к зрелому DevSecOps нет так прост и очевиден, но есть много экспертов, которые знают, какие необходимы компоненты для надежной программы безопасности.
Почти 85% респондентов Upskilling IT 2022 заявили, что DevOps или DevSecOps являются важными или необходимыми операционными моделями. Поэтому мы обратились к представителям DevOps Institute, которые поделились своим мнением по этой важной теме. Вот несколько общих идей о том, как выстроить эффективную DevSecOps-стратегию:
Помогая пользователям NGINX с разрешением проблемных ситуаций, мы поняли, что большинство из них часто совершает одни и те же ошибки конфигурации. Более того, подобные ситуации вполне могут возникнуть даже у самих инженеров NGINX! В этой статье рассмотрим 10 наиболее распространенных ошибок и объясним как их исправить.
Развертывание Kubernetes на физических серверах рекомендуется организациям, которые находятся в поисках новых возможностей в сфере управления инфраструктурой. Рассмотрим 6 причин попробовать K8s на выделенных серверах.
Kubernetes в общедоступном облаке - это подходящее решение для приложений малого и среднего размера, которые имеют предсказуемые потребности в плане масштабирования. Вместе с тем, bare metal-облако - это путь для организаций, стремящихся к большему контролю и стабильной производительности.
Инструменты оркестрации контейнеров облегчают разработку программного обеспечения, гарантируя гибкость, переносимость с одного устройства на другое, хорошую скорость и простоту масштабирования для распределенных приложений. Являясь фактическим лидером в области оркестрации, Kubernetes поддерживается многими популярными поставщиками облачных услуг.
Хотя сервисы managed Kubernetes, предоставляемые различными провайдерами услуг, обеспечивают простой механизм развертывания и начала работы, в основном они работают на базе виртуализированной инфраструктуры. Виртуальные машины удобны для провайдеров и в большинстве случаев обеспечивают хорошее качество работы для их клиентов. Однако, стоит отметить, что развертывание Kubernetes на обычных серверах также дает несколько существенных преимуществ.
А вы когда-нибудь задумывались о границах масштабируемости Kubernetes? Для тех, кого порой посещают такие мысли, мы решили опубликовать перевод заметки "Kubernetes Scalability thresholds", вам точно будет интересно ознакомиться.
Соберем пазл Ops’ов.
Процесс разработки продукта и деплоя программ непрерывно развивался, чтобы соответствовать требованиям скорости (в связи с ростом спроса), масштабируемости, и повышенной эффективности (по качеству продукта). IT компании должны постоянно изучать новое, забывать старое и адаптироваться под изменяющиеся требования чтобы принести на рынок достойный продукт так быстро, как это возможно.
Раньше, IT отделы представляли собой единые команды, но теперь популярна идея организации команд более эффективно для удовлетворения потребностей компании. Основываясь на этих идеях, IT группы разделяются по специализациям отделов с четкими ролями и требуемыми результатами, продолжая совместную работу. Часть из популярных идей включают в себя TechOps, DevOps, и NoOps.
TechOps, DevOps, и NoOps это не примеры технологий или языков программирования. Это модели работы, определяющие как IT команды будут внедрять и выпускать проекты в релиз. Это просто различные подходы к производству, развертке и поддержке продуктов.
Разберемся в этих идеях.
TechOps
Широкое и зачастую плохо определяемое назначение TechOps специалистов может дать впечатление, что они занимаются вообще всем, что связано с IT. Действительно, TechOps-задачи сильно разнятся от организации к организации, но все они попадают в категорию по предоставлению и обслуживанию существующей технологической инфраструктуры. Это включает такие вещи как сетевая поддержка, управление базами данных, обеспечение и контроль безопасности, аварийное восстановление, оптимизация сети, установка и обновление программного обеспечения и другие задачи поддержки.
DevOps инструменты трансформируют процессы разработки программного обеспечения на мировом уровне. Давайте ознакомимся с лучшими из лучших на сегодняшний день.
В ходе опроса, проведенного аналитическим отделом Harvard Business Review, 48% респондентов заявили, что их компания полностью полагается на DevOps в контексте повышения эффективности. А более 80% представителей индустрии программного обеспечения заявили, что DevOps значительно повышает ценность их работы в том или ином виде.
Более того, согласно результатам вышеупомянутого опроса, DevOps увеличивает скорость выхода на рынок, масштабируемость, инновационный потенциал и качество продукции для компаний-разработчиков программного обеспечения на глобальном уровне.
2021 год станет важным годом для раскрытия потенциала DevOps. Он охватывает как команды разработчиков, Ops, IT и отделы обеспечения безопасности, так и различные этапы разработки программного обеспечения. Именно поэтому для каждой сферы существует множество инструментов на любой вкус и цвет.
Давайте подробно рассмотрим наиболее выдающиеся инструменты DevOps, доступные на рынке в настоящее время, с учетом важных категорий жизненного цикла CI/CD.
Даже после сдачи проекта клиенту работа разработчика программного обеспечения не закончена. Следующей фазой выступает обеспечение надежности оказываемых услуг. В практике проектирование надежности сайта (SRE) есть два ключевых понятия, о которых следует знать инженерам: цель уровня обслуживания (SLO) и индикатор уровня обслуживания (SLI).В этой статье мы рассмотрим важность SLI и SRE и как их применять.
Внутри IT индустрии, и, особенно, большого (относительно) нового мира облачных сервисов, можно сказать, что безопасность не на первом месте у всех разработчиков или консультантов по облачным технологиям. Каждая команда участвующая в процессе разработки облачных сервисов имеет задачи в своем поле деятельности, а безопасность зачастую остается на задних сидениях поезда облачных технологий. Пока Zero Trust Network Architecture (ZTNA — Сетевая архитектура нулевого доверия) становится все более популярным, и принимаемым как один из наиболее безопасных принципов, которых стоит придерживаться, нам необходимо определить и использовать технологии, что позволяют обеспечить мощный центральный механизм политик и соответствующее их исполнение, в то же время обеспечивая возможность автоматизации и внедрения в более масштабные процессы, текущую работу и проекты для гибкости и масштабируемости в долгосрочной перспективе.
Устойчивый рабочий процесс для сборки, деплоя и релиза приложений на любых платформах.
Сегодня мы рады представить Waypoint компании HashiCorp. Это новый проект с открытым исходным кодом, предлагающий разработчикам стабильный процесс для сборки, развертывания и релиза приложений на любых платформах. Waypoint дает разработчикам возможность работать с приложениями от разработки до запуска в продакшн в едином файле и деплоить их с помощью единственной команды: waypoint up.
OpenSearch является продуктом реакции на недавнее изменение условий лицензирования Elasticsearch и прекращения работы в качестве open-source платформы. AWS, Logz.io и ряд других компаний-партнеров в течение нескольких месяцев работали над созданием не просто функциональной замены Elasticsearch, а самостоятельным и перспективным проектом.
После разделения Elasticsearch и Kibana 7.10.2, версия RC1 (1.0.00 OpenSearch и OpenSearch, выпущенных 7 июня 2021 г. RC1 не считается полностью готовой к эксплуатации, но она функциональна и включает в себя все прежние Open Distro плагины (наряду с несколькими новыми), Docker-образы, команды Linux tars, оповещения и возможность визуализации диаграмм Ганта (что изначально не входило в ELK стек).
Инструкции по установке и настройке OpenSearch на протяжении какого-то времени останутся без изменений. Поэтому данный порядок действий поможет с легкостью приступить к установке и настройке.
HashiCorp Boundary — это пропускная система с открытым исходным кодом, которая обеспечивает пользователю безопасный доступ к динамическим хостам и критически важной инфраструктуре в разных средах. Однако, если вам нужен простой и безопасный способ управления доступом к базам данных, кластерам Kubernetes, облачным интерфейсам командной строки, коммутаторам, маршрутизаторам или внутренним веб-приложениям, можно рассмотреть и другие сервисы. В этой статье, мы рассмотрим несколько альтернатив и обсудим сильные и слабые стороны каждой из них. Итак, сделаем экспресс-анализ фичей каждого сервиса, которые, возможно, вас заинтересуют.
Я давно искал какой-нибудь инструмент для низкоуровневой отладки сети Linux. Linux позволяет создавать сложные сети, запускаемые прямо на хосте, используя комбинацию из виртуальных интерфейсов и сетевого пространства имен. Когда что-то идет не так решение возникших проблем утомительно. Если это проблема маршрутизации L3, mtr (Matt's traceroute) имеет неплохие шансы принести пользу. Однако, если проблема на более низком уровне, обычно все заканчивается тем, что я вручную проверяю каждый интерфейс / мост / пространство имен сети / iptables и пару раз запускаю tcpdump в попытках понять что происходит. Если вы не знакомы с настройками сети, то при решении проблем в ней, вас ждет запутанный лабиринт.