В Bestmile мы используем Terraform для AWS IaC. Но чем больше развивалась наша инфраструктура, тем запутаннее становился код Terraform.

Код Terraform стало сложнее обслуживать. Он терял эффективность. Terraform — отличный инструмент, но нуждается в дополнениях. Здесь-то и пригодится Terragrunt.

Terragrunt — это обертка (wrapper) для Terraform, которая расширяет его функционал и устраняет некоторые ограничения. Terragrunt взаимодействует с Terraform с помощью кода HCL (HashiCorp Configuration Language), поэтому Terragrunt будет выполнять код Terraform в зависимости от того, как вы определите код HCL. Именно он дает дополнительные преимущества, как описано ниже, и превращает Terragrunt в волшебный инструмент.

В этой статье пойдет речь про I2P — некоммерческую сингулярность сетевой приватности и анонимности, где никто кроме вас не знает куда и кто передает вашу информацию. Сеть I2P (расшифровывается как «Invisible Internet Project», Проект невидимого интернета) — это оверлейная децентрализованная одноранговая сеть. Оверлейная — значит работает поверх других сетей, например, обычного интернета; децентрализованная — распределенная, не имеющая единой точки отказа: упадет один узел, полсети, или во всей сети останется 3 пользователя — I2P все равно будет функционировать. I2P является одноранговой сетью, так как все участники имеют равные права и возможности: каждый пользователь скрытой сети строит свои туннели через других участников и сам является потенциальным звеном в цепочке другого пользователя. При этом естественная сетевая активность никак не компрометирует абонента перед домашним провайдером или участниками скрытой сети.

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

Тем не менее, когда узел выходит из строя, pods, спланированные на данный узел, продолжают работать на нём еще в течение некоторого времени, а также получать запросы. Думаю, это совсем не то поведение, которое вы ожидали от Kubernetes.

В этой статье мы разберёмся, как сократить время реакции Kubernetes на выход узлов из строя, чтобы избежать возможных проблем.

Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.

О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.

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

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Здравствуйте, уважаемые читатели Хабра. Меня зовут Олег Плотников, я директор Центра Промышленного Интернета одной из IT-компаний.

Этой статьей я бы хотел начать целый цикл заметок про Интернет Вещей и конкретно про технологию LoRa. О ней уже не раз писали на Хабре, писали интересно и с разных сторон. Однако, наш Центр построил и уже почти год эксплуатирует сеть LoRaWAN и мы накопили большой опыт именно практической эксплуатации этой технологии. Давайте договоримся, я не ставлю своей целью пиар компании, в которой работаю. Но буду периодически обращаться к нашим проектам, когда потребуется что-то проиллюстрировать. Главный акцент своих заметок я бы хотел сделать не на теории, а на практике. Постараюсь заразить вас идеей, что Интернет Вещей – это интересно и черепахоподобная LoRa станет важным кирпичиком в общем фундаменте.

Kubernetes отказывается от Docker для выполнения контейнеров после версии 1.20. (Прим. переводчика: в декабре мы уже писали о том, как это изменение повлияет на задачи разработчиков и инженеров эксплуатации: «Docker is deprecated — и как теперь быть?»)

Без паники. Контейнеры Docker все еще поддерживаются, но без dockershim/Docker — слоя между Kubernetes и containerd, который будет удален, начиная с версии 1.22+.

Если вы используете Docker, нужно перейти на поддерживаемый интерфейс container runtime interface (CRI). Хорошим вариантом будет containerd — он уже есть у вас на ноде Kubernetes, если вы работаете с Docker.

В прошлой части были рассмотрены рекомендации по множеству механизмов Kubernetes для оптимального деплоя высокодоступных приложений включая особенности работы планировщика, стратегии обновления, приоритеты, пробы и т.п. Во втором и заключительном материале поговорим о трёх важных оставшихся темах: PodDisruptionBudget, HorizontalPodAutoscaler, VerticalPodAutoscaler, — продолжив нумерацию из первой части.

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

В этом руководстве мы кратко обсудим, как Helm может помочь упростить управление приложениями Kubernetes, и узнаем, как использовать Helm для создания базового чарта.

Управление приложениями — сложный аспект Kubernetes. Helm значительно упрощает его, предоставляя единый метод упаковки программного обеспечения, поддерживающий контроль версий. Helm устанавливает пакеты (называются Чартами в Helm) для Kubernetes и управляет ими, как это делают yum и apt.

В этом руководстве мы позволим Helm создать для нас базовый чарт. В этом руководстве предполагается, что у вас есть хотя бы базовое понимание того, что такое Helm. Если вы не знакомы с ним, я предлагаю вам ознакомиться с этим руководством, прежде чем приступить к статье: https://www.alibabacloud.com/help/doc-detail/86511.htm

Установка и управление Helm Charts может вызвать у вас некоторые сложности, с которыми вы, возможно, не сталкивались раньше.

Helm Charts упаковывает приложения для установки в кластеры Kubernetes. Установка Helm Chart немного похожа на запуск мастера установки, поэтому разработчики Helm Chart сталкиваются с некоторыми из тех же проблем, с которыми сталкиваются разработчики, производящие установщики:

• Какие предположения можно сделать об окружении, в которой выполняется установка?
• Может ли приложение взаимодействовать с другими приложениями?
• Какие конфигурации должны быть доступны пользователю и как их предлагать?

Всем привет.

Есть такие люди, которые работают с облачной инфраструктурой и не используют автоматизацию, потому что это долго, нужно вникать, а им надо фичи пилить. Накликали что-то там в UI, подключились по ssh, поставили всякого с помощью apt и т.д. и конфигурационные файлы ещё вручную поменяли. Документации конечно же написать времени не хватило или в ней много разных хитрых шагов и повторить настройку этой инфраструктуры в точности уже нельзя или очень сложно, а сервисы крутятся в проде. А потом человек забыл что и как делал в точности или вообще уволился.

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

Братцы! Скорее всего вы уже знаете, что Kubernetes отказался от поддержки Docker в качестве среды выполнения контейнеров (container runtime) в будущих версиях. В релизе 1.20, вышедшем в конце 2020 года Dockershim помечен как устаревший (deprecated). В релизе 1.22, выход которого запланирован на конец 2021 года, от его поддержки планируют полностью отказаться.

Если вы используете управляемые кластеры Kubernetes (такие как GKE, EKS, AKS) это не станет для вас серьезной проблемой и скорее всего переключение будет простым. Но если вы управляете кластером самостоятельно (например, с помощью kubeadm) и используете Docker container runtime, рано или поздно, вам придется заменить ее, чтобы иметь возможность обновлять Kubernetes до последних версий.

Задача этой статьи не дать исчерпывающую информацию о причинах такого решения со стороны разработчиков Kubernetes или подробно изучить поведения конкретных container runtime в кластере Kubernetes. Вместо этого мы шаг за шагом разберемся как переключить Docker container runtime на другое решение, поддерживающее стандарт Container Runtime Interface (CRI). Если вас интересуют причины из-за которых Docker больше не рекомендован к использованию, ознакомьтесь со статьей из официального блога Kubernetes  Don't Panic: Kubernetes and Docker.

Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.

В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:

journald решает все наши проблемы

документации по нему подозрительно мало (особенно, в сравнении с systemd)

при том, что его поведение более-менее разумно, интуиция о том, как он работает, практически отсутствует и её надо набирать.

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

Моя команда использует ClickHouse как хранилище для 100 млрд записей с трафиком по 300 млн в сутки и поиском по таблице. Я расскажу об устройстве движка таблиц MergeTree. Рассказ буду вести, показывая физические данные, а не абстрактные схемы.

В данной статье будет рассмотрено понятие сокета в операционной системе Linux: основные структуры данных, как они работают и можно ли управлять состоянием сокета с помощью приложения. В качестве практики будут рассмотрены инструменты netcat и socat.