Immutable-инфраструктура и ее преимущества

Pulumni

Pulumi

Immutable-инфраструктура и ее преимущества

Собираем образ, проставляем метаданные в зависимости от приложения

Собираем образ с помощью packer, проставляем метаданные в зависимости от приложения

Immutable-инфраструктура и ее преимущества

Стартовым можно считать использование инструментов вроде Ansible, Puppet, Chef, Saltstack и др. Стоит помнить, что, как и в остальных инструментах Immutable, хранилище стейта должно быть отделено от виртуальной машины

У Ansible, Puppet, Chef, Saltstack нет state, а у terraform есть. Но в пункте ничего про terraform не написано.

Immutable-инфраструктура и ее преимущества

Виды инструментов Immutable infrastructure

1. Инструменты доставки конфигурации

Стартовым можно считать использование инструментов вроде Ansible, Puppet, Chef, Saltstack и др.

Наоборот. Ansible, Puppet, Chef, Saltstack это инструменты для mutable инфраструктуры. Они подключаются к серверу и настраивают его.

Только в связке с packer это инструменты immutable инфраструктуры. Но в этом пункте вы это не упомянули.

Immutable-инфраструктура и ее преимущества

1. Более медленный деплой новых версий по сравнению с Mutable-инфраструктурой, так как поднимаются новые машины.

Наоборот, более быстрый деплой по сравнению с Mutable инфраструктурой. Вы просто указываете новый образ, в котором уже был деплой приложений и библиотек когда вы его паковали, например, с помощью packer.

Immutable-инфраструктура и ее преимущества

3. Упрощение конфигурации. Не нужно помнить, что и на какой машине установлено, если есть готовый образ, из которого она создана, со своим описанием в виде файла конфигурации.

4. Благодаря согласованной конфигурации машин проще выкатывать обновления и тестировать новые версии.

5. Инстансы с одним и тем же приложением одинаковы.

Если использовать практики infrastructure as a code и идемпотентность, то эти пункты можно реализовать на изменяемой инфраструктуре.

Immutable-инфраструктура и ее преимущества

1. Возможность версионирования.

a. Можно отследить, в каком из обновлений возникла ошибка.

2. Конфигурационные файлы выступают в качестве документации состояния инфраструктуры. 

Вы это можете делать и с изменяемой инфраструктурой.

Immutable-инфраструктура и ее преимущества

1. Отсутствие документации версий инфраструктуры, трудно отследить проблемы, которые могли возникнуть из-за выкатки новой версии.

Это применимо как изменяемой так и к неизменяемой инфраструктуре.

Immutable-инфраструктура и ее преимущества

Спасибо за пост. Как связано понимание этих концепции и что любой инструмент может перестать быть опенсорсом? Скорее эти фразу стоило разделить на 2 предложения.

Kubernetes в Тензоре

Спасибо за интересный пост.

Встроенный в Cilium механизм BGP не поддерживает BFD.

Не делали issue?

Для реализации выбрали Kyverno.  Дополнительно написали GUI.

Планируете ли выложить в open source?

При развёртывании Deployment, StatefulSet и подобных ресурсов "автоматом" создаём для них VPA-ресурс в режиме рекомендаций. Для удобной визуализации разработали GUI.

Планируете ли выложить в open source?

Через DaemonSet запускаем Core Dump Handler на всех нодах. Он собирает дампы и закидывает их в S3-хранилище, а триггер уведомляет об этом эксплуатацию. Его мы немного пропатчили.

Планируете ли отправить PR с исправлением?

Вышел Linux 6.5

В https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5 и в https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13 можно найти коммит с названием "drm/amdgpu: Fix desktop freezed after gpu-reset"

Пишут что в https://launchpad.net/ubuntu/+source/linux/6.2.0-25.25 это исправлено: "drm/amdgpu: Fix desktop freezed after gpu-reset". Я как выставил параметры ядра в Grub, так и не убирал их, поэтому не знаю исправили ли они проблему или нет.

Появился репозиторий с новыми версиями ядра Linux для Debian и Ubuntu

Попробуйте добавить  amdgpu.dcdebugmask=0x10 in /etc/default/grub:

...
GRUB_CMDLINE_LINUX="... amdgpu.dcdebugmask=0x10"
...

Возможно вам помогут другие параметры ядра. Мои параметры:

GRUB_CMDLINE_LINUX_DEFAULT="initcall_blacklist=acpi_cpufreq_init amd_pstate=passive amd_pstate.shared_mem=1 amdgpu.noretry=0 amdgpu.dcdebugmask=0x10"

Обсуждение issue здесь: https://gitlab.freedesktop.org/drm/amd/-/issues/2443

Исправлено в Linux Kernel 6.5-rc1

11 полезных плагинов для kubectl

А можете подробнее рассказать про "Этот плагин обнаруживает проблемы и потенциальные уязвимости в вашем конфигурационном файле Kubernetes и предлагает рекомендации по исправлению." у kubepug?

Я не нашел этого у них https://github.com/rikatz/kubepug

Как создавать Kubernetes секреты из Vault, используя external-secrets-operator

Да, вы правы. Kubernetes auth позволяет использовать short-lived token, что выглядит безопаснее. Мое мнение что app-role проще, чем Kubernetes auth.

Как создавать Kubernetes секреты из Vault, используя external-secrets-operator

В pod можно использовать секрет вот так

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      optional: true

Источник примера https://kubernetes.io/docs/concepts/configuration/secret/

15 лет «Фланта»: переход от сервисной компании к продуктовой, покупка внешнего продукта, вера в Open Source

Есть сравнение Mimir и Victoriametrics - https://victoriametrics.com/blog/mimir-benchmark/

Резюме
В этом бенчмарке было два раунда тестов.

В первом раунде Miami и Victoria Metrics работали с одинаковой нагрузкой и на одном и том же оборудовании. Контрольными результатами были следующие:

• VictoriaMetrics использует на 1,7 процессора меньше при той же рабочей нагрузке;

• VictoriaMetrics использует в 5 раз меньше оперативной памяти для того же количества активных серий;

• VictoriaMetrics использует в 3 раза меньше места для хранения данных, собранных в течение 24 часов во время тестирования.
  

Во втором раунде нагрузка была увеличена в 5 раз с использованием того же оборудования. У Mimir было недостаточно ресурсов, чтобы справиться с нагрузкой, поэтому была доступна только статистика VictoriaMetrics.

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Вышел первый релиз VictoriaLogs - https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs

Docs: https://docs.victoriametrics.com/VictoriaLogs/
Helm Chart: https://github.com/VictoriaMetrics/helm-charts/tree/master/charts/victoria-logs-single

Так же подготовили Benchmark for VictoriaLogs, взять можно из https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/deployment/logs-benchmark

Bug report + feature request ждём в https://github.com/VictoriaMetrics/VictoriaMetrics/issues/new

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Спасибо за пост. Жаль, что в статье довольно мало технических деталей.

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Чат по Loki в telegram https://t.me/ru_loki

Infrastructure as a Code: ожидания и реальность

Книгу я читал. Я спрашивал именно про инфраструктурный код (terraform hcl, kubernetes yaml). И в этой главе не написано что "SRE 50% времени пишут инфраструктурный код (terraform hcl, kubernetes yaml)". Процитируйте, предложение из этой главы где это написано.