Что такое Job и CronJob в Kubernetes, для чего они нужны, а для чего их использовать не стоит.
Эта статья — выжимка из лекции вечерней школы «Слёрм Kubernetes».

Преобразовывайте свои журналы прямо во время запроса, настраивайте уведомления с Loki.

Недавно я начал применять Terraform для создания облачной лабы для тестов, и это довольно круто. Буквально за несколько дней я поднялся с «никогда не использовал AWS» до «я умею декларативно создавать изолированную инфраструктуру в облаке». Я поставил парочку серверов в выделенной сети в VPC с security group и отдельными ключами SSH, все это заняло у меня несколько сотен строк кода.

Все приятно и прельстиво, но после создания сервера из некоторого базового AMI мне надо его развернуть. Мой типовой инструмент для этого — Ansible, но, к сожалению, у Terraform нет встроенного модуля для Ansible (есть обратный, начиная с Ansible 2.5, прим. переводчика), в отличие от Chef и Salt. Это не похоже на Packer, имеющий ansible (удаленный) и ansible-local, который я использовал для сборки образов Docker.

Так что я потратил немножко времени и нашел несколько способов подружить Terraform и Ansible, о чем расскажу в этой статье. Но сначала — поговорим о развертывании.

Легко и непринужденно настраиваем Istio для уменьшения нагрузки и влияния как на control, так и на data plane, используя ресурс Sidecar.

Grafana Labs с гордостью представляет простую в эксплуатации, масштабируемую, экономичную, распределенную систему трассировки: Tempo. Она разработана в качестве надежного хранилища, оптимизированного для поиска идентификаторов, единственная ее зависимость — объектное хранилище (GCS/S3).

Jason Dorfman, MIT CSAIL

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

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

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

По мере роста числа людей и компаний, принявших DevOps, стало ясно, что понятие «DevOps» не может полностью описать полное состояние движения, его принципы и цели. Я чуть ранее называл все это словом DevQaOps, и рекомендую внедрять методы тестирования ShiftLeft там, где это возможно.

Site Reliability Engineering (SRE) — это одна из форм реализации DevOps. SRE-подход возник в Google и стал популярен в среде продуктовых IT-компаний после выхода одноимённой книги в 2016 году.

В статье опишем, как SRE-подход соотносится с DevOps, какие задачи решает инженер по SRE и о каких показателях заботится.

Пару недель назад я посмотрела демонстрацию Waypoint— нового инструмента, который представила 15 октября 2020 года компания Hashicorp. Инструмента, который предназначен для создания легкого, интуитивного и настраиваемого под пользователя рабочего процесса сборки, развертывания и релиза.

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

Мы в Lifion строим распределенную платформу и портфель продуктов для клиентов по всему миру. С учетом этого важно, чтобы мы могли выпускать обновления нашей платформы непрерывно прямо во время ее работы, прозрачно для наших пользователей, которым важна доступность системы, при этом они находятся в разных регионах и часовых поясах. В этой статье мы поделимся с вами путем, которым мы шли, чтобы получить нулевые простои при непрерывном обновлении с помощью Kubernetes. Мы запускаем наши нагрузки с помощью управляемого сервиса Kubernetes — AWS EKS. В качестве шлюза API мы применяем Ambassador, сборку Envoy с открытым исходным кодом, специально разработанную для Kubernetes. Наша платформа состоит из более чем 150 микросервисов, большинство из них написаны на Node.js, запускаются в многих подах поверх многочисленных рабочих узлов.

Есть множество материалов по установке WordPress, поиск в Google по ключевым словам "WordPress install" выдаст порядка полумиллиона результатов. Но тем не менее фактически среди них весьма мало годных руководств, по которым можно установить и настроить WordPress и нижележащую операционную систему так, чтобы они были способны к поддержке в течение длительного периода времени. Возможно, правильные настройки сильно зависят от конкретных потребностей, или же это связано с тем, что подробное объяснение делает статью тяжелой для чтения.

В этой статье мы постараемся собрать лучшее из двух подходов, предоставляя скрипт на bash для автоматической установки WordPress на Ubuntu, а также пройдемся по нему, поясняя, что делает каждый его кусочек, а также на какие компромиссы мы пошли при его разработке. Если вы опытный пользователь — можете пропустить текст статьи и просто взять скрипт для модификации и использования в ваших окружениях. На выходе скрипта получается настраиваемая установка Wordpress с поддержкой Lets Encrypt, работающая на NGINX Unit и пригодная для промышленного применения.

HashiCorp показала новый проект Waypoint на HashiCorp Digital. Он использует файл на основе HCL для описания сборки, поставки и выпуска приложений для различных облачных платформ, начиная от Kubernetes и заканчивая AWS и Google Cloud Run. Можно представить, что Waypoint — это сложенные вместе Terraform и Vagrant для описания процесса сборки, поставки и выпуска ваших приложений.

Jacky Parker Photography / Getty Images

Компания Robin, автор одноименного cloud-native решения для управления данными и приложениями корпоративных клиентов, например USAA, Sabre, SAP, Palo Alto Networks и Rakuten Mobile, сегодня рассказала о запуске новой бесплатной версии своего сервиса, в дополнение к крупному обновлению основного инструментария.

Статья является продолжением этой и этой статей, в ней будут ответы на часто задаваемые вопросы по новым ограничениям использования сервисов от компании Docker, которые вступят в силу с 1 ноября 2020 года.

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

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

Мы рады представить предварительную версию NGINX Service Mesh (NSM), связанную легковесную service mesh, использующую data plane на основе NGINX Plus для управления трафиком контейнеров в окружениях Kubernetes.

NSM можно бесплатно скачать здесь. Мы надеемся, что вы попробуете его использовать для dev и test окружений — и ждем ваших отзывов на GitHub.

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

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

Дмитрий Симонов, CTO и создатель канала «Техдирские заметки» решил по-осеннему да по-есенински удариться в глубокую философию взаимоотношений с командой. Как достигнуть истинной эффективности команды?

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



Southbridge поддерживает высоконагруженные серверы с 2008 года. Сейчас в штате 55 сотрудников, из них 19 — системные инженеры, больше половины работает 5 лет и дольше.

В статье опишем процесс поиска новых сотрудников, а также немного расскажем про онбординг и удержание в команде.

На прошлой неделе Слёрм провел опрос об оркестраторах среди тех, кто прошел курсы или вечернюю школу по Kubernetes.

Результат, мягко говоря, удивил: 49 человек из 316 ответивших используют Docker Swarm, на котором мы поставили крест ещё два года назад! И это среди тех, кто как минимум знаком с Kubernetes.

Возможно, это аномалия. Возможно, Docker Swarm не так мертв, как нам казалось. Расскажите, пожалуйста, пользуетесь ли вы Свормом и почему?

В мобильной версии хабра не видно опросов. На этот случай гуглоформа с опросами: https://forms.gle/veaYBFirHVJoPtvm8