🔥 Знакомьтесь с экспертом Proglib.academy: Эмиль Сатаев

Эмиль — эксперт с 8-летним опытом в разработке, который специализируется на внедрении LLM и агентных подходов в реальные коммерческие сервисы. Он точно знает, как проектировать архитектуру так, чтобы ИИ-функции работали стабильно в связке с внешними системами.

🏃‍♀️ Уже 14 мая Эмиль проведет открытый вебинар!

Обсудим самую «больную» тему: «Почему AI-продукты на базе LLM ломаются и как сделать, чтобы работало».

🗓 Когда: 14 мая в 19:00 (Мск)

Почему Эмиля стоит послушать:

🟣 8+ лет в разработке (Backend и Frontend)

Прошел путь от фулстека до Backend Platform Developer в SMIT.Studio.

🟣 Международный исследовательский опыт

Работал исследователем в Институте ИИ НИУ ВШЭ и в Национальном университете Сингапура (NUS).

🟣 Преподаватель-практик

Ведет семинары в НИУ ВШЭ, в том числе по проектированию и разработке агентских систем.

🟣 Мастер интеграции AI в Backend

Его главная суперсила — умение правильно встраивать LLM через API, выстраивать workflow и агентную логику в сложных распределенных системах.

🔗 Зарегистрироваться на вебинар

🧑‍💻 5 базовых команд девопса

➡️ Команда wc -l считает строки в файле или в пайпе. Одна из тех вещей, которые используешь каждый день. Логи, CSV, исходники, конфиги.

Везде, где нужно быстро понять объём:

$ wc -l server.log
4821 server.log

Набирать wc -l несложно, но можно сделать ещё проще. Создаём алиас lc (line count) и добавляем в конфиг шелла:

# Добавьте в ~/.bashrc или ~/.zshrc, затем: source ~/.bashrc
alias lc='wc -l'

Теперь вместо wc -l пишем просто lc:

$ lc server.log
4821 server.log

Работает и с пайпами:

$ cat access.log | grep "500" | lc
37

37 пятисотых ошибок. Быстро и понятно.

➡️ du -sh * — сколько весит каждая папка

Когда заканчивается место на диске, первым делом хочется понять, кто его съел.

du -sh * покажет размер каждого элемента в текущей директории в человекочитаемом формате:

$ du -sh *
1.2G    node_modules
4.0K    README.md
256M    dist
12K     src

node_modules на первом месте. Как обычно.

Если нужно отсортировать по размеру, добавляем sort:

$ du -sh * | sort -rh
1.2G    node_modules
256M    dist
12K     src
4.0K    README.md

Флаг -r сортирует по убыванию, -h понимает суффиксы K, M, G.

➡️ xargs — передать результат одной команды как аргументы другой

xargs берёт строки из stdin и подставляет их как аргументы. Например, найти все .log файлы и удалить их:

$ find /tmp -name "*.log" | xargs rm

Если в именах файлов есть пробелы, безопаснее использовать разделитель через null:

$ find /tmp -name "*.log" -print0 | xargs -0 rm

Ещё полезный приём. Посчитать общее количество строк во всех Python файлах проекта:

$ find . -name "*.py" | xargs wc -l

➡️ column -t — превратить текст в ровную таблицу

Вывод многих команд выглядит как каша из слов, разделённых пробелами. column -t выравнивает столбцы и делает вывод читаемым:

$ cat data.txt
name age city
alice 30 berlin
bob 25 munich

$ column -t data.txt
name   age  city
alice  30   berlin
bob    25   munich

Хорошо работает с CSV, если указать разделитель:

$ column -t -s',' users.csv

➡️ watch — повторять команду каждые N секунд

watch запускает любую команду с заданным интервалом и обновляет вывод в терминале. По умолчанию интервал 2 секунды:

$ watch df -h

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

Можно изменить интервал через -n:

$ watch -n 5 kubectl get pods

Каждые 5 секунд обновляет статус подов. Проще, чем жать стрелку вверх и Enter раз за разом.

Все эти команды работают в любом Linux и macOS из коробки. Ничего ставить не нужно.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

📣 Топ-вакансий для девопсов за неделю

Выбирайте любую из трёх вакансий, все на удалёнку:

• DevOps Engineer Middle

• DevOps Архитектор

• DevOps-инженер (on-call)

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

🐸Библиотека devops'a

#вакансия_недели

Talanto.work - сайт для всех, кто ищет работу в IT.

Мы спарсили за вас все возможные телеграм каналы и сайты с вакансиями исключительно из сферы IT.
Вам не нужно следить за тем, когда выходит вакансия и где, всё это уже сделано за вас.

Просто настройте фильтры у нас на сайте и получайте уведомления в телегу, как только вакансия вышла.

Например: все вакансии DevOps

На talanto.work собрано 28.000+ вакансий из разных .ru и иностранных сайтов: разработка, QA, аналитика, DevOps, продакт, дизайн, менеджмент и другие IT/Digital-направления.

Более 1700 вакансий за последний месяц из телеграм каналов.

Что еще есть на сайте:

🟠 Фильтры для нормального поиска
Можно искать по стеку, грейду, зарплате, стране, формату работы, релокации и типу занятости.

🟠 Разбор резюме
Загружаете CV и получаете конкретные рекомендации: что улучшить, какие навыки добавить, где слабая структура и что может мешать пройти ATS.

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

🟠Сопроводительное письмо за 10 секунд
Вставляете вакансию и получаете персональное письмо под конкретную компанию и роль, а не шаблон “прошу рассмотреть мою кандидатуру”.

🟠Уведомления в Telegram
Задаёте фильтры один раз и бот присылает новые подходящие вакансии прямо в Telegram.

Поиск работы в IT сейчас и так сложный. Мы хотим, чтобы вы тратили меньше времени на листание сайтов и больше на точные отклики туда, где у вас реально есть шанс.

✈️ 28.000+ вакансий
🟢Бот с уведомлениями о ваших вакансиях: @TalantoWorkBot
🟢Написать сопровод
🟢Разобрать резюме
🟢Проверить соответствие резюме вакансиям

Реклама. Киренкина Марина Дмитриевна, ИНН 345702417736. Erid 2Vtzqx28ab1

🔄 Leaf 1.21.0

leaf — терминальный превьювер Markdown на Rust. Показывает .md файлы прямо в консоли с подсветкой синтаксиса, таблицами, оглавлением и навигацией. По ощущениям ближе к GUI, чем к обычному cat.

В версии 1.21.0 два заметных обновления.
 
Флаг --inline для вывода в stdout
 
Раньше leaf работал только в интерактивном режиме — открывал TUI и ждал ввода. Теперь можно рендерить Markdown и сразу печатать результат в stdout без запуска интерфейса.
 
Это полезно, когда нужно встроить leaf в пайплайн или скрипт. Например, отрендерить файл и сохранить результат:

leaf --inline README.md > rendered.txt

 
Или прокинуть через пайп:

cat CHANGELOG.md | leaf --inline

Обновиться:

leaf --update

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📎 Что будет в Podman 6

Podman 6.0 это мажорный релиз с ломающими изменениями. Убраны устаревшие компоненты, переработана конфигурация, обновлён сетевой стек.

Если вы используете Podman в продакшене или на локальной машине, стоит знать, что изменится и к чему готовиться.

Удаление устаревших компонентов

Всё, что было deprecated в пятой ветке, в шестой удалено окончательно.

slirp4netns больше нет. Начиная с Podman 5.0 для rootless-сетей по умолчанию использовался Pasta. Теперь это единственный вариант, slirp4netns вырезан из кода вместе с флагом --network-cmd-path.

CgroupsV1 больше не поддерживается. Весь связанный код и тесты удалены. Если у вас система на cgroups v1, Podman 6 работать не будет.

BoltDB тоже убран. SQLite стал дефолтным бэкендом ещё в Podman 4.8. В 5.7 добавили предупреждение, в 6.0 поддержку BoltDB убрали полностью. Если вы не мигрировали базу, после обновления состояние контейнеров окажется недоступным.

Перед обновлением до Podman 6 рекомендуется сначала обновиться до 5.8 и перезагрузиться. Это запустит автоматическую миграцию с BoltDB на SQLite.

Переработка конфигурации

Одно из заметных изменений. Файлы конфигурации containers.conf и storage.conf переделывают с нуля. Проблема была в том, что удалённые клиенты на Windows и macOS использовали те же конфиги, что и серверная часть. Это приводило к путанице и ошибкам.

Новый подход разделяет конфигурацию на клиентскую и серверную части. Логика парсинга containers.conf и storage.conf унифицируется. Если вы работаете с Podman через удалённый клиент, возможно, придётся обновить свои конфиги.

Изменения в сетевом стеке

Netavark, сетевой бэкенд Podman, тоже получил обновления.

Поддержка iptables убрана. Остаётся только nftables. Это затронет тех, кто вручную настраивал iptables для контейнеров.

Логика создания сетей перенесена внутрь Netavark, а внутренние структуры данных изменены, чтобы сохранять порядок подключённых сетей для контейнеров.

Новый conmon

Ведётся работа над новой версией conmon. Подробностей пока мало, но обещают улучшения в производительности и пользовательском опыте.

Как проверить готовность к обновлению

Убедитесь, что ваша система использует cgroups v2. Проверить можно так:

stat -fc %T /sys/fs/cgroup/

Если в ответе cgroup2fs, всё в порядке.

Проверьте, на каком бэкенде работает ваша база Podman:

podman info --format '{{.Host.DatabaseBackend}}'

Если ответ sqlite, миграция не нужна. Если boltdb, обновитесь сначала до Podman 5.8 и перезагрузитесь.

Убедитесь, что для rootless-сетей используется Pasta, а не slirp4netns:

podman info --format '{{.Host.Pasta.Executable}}'

Podman 6.0 убирает всё устаревшее и приводит кодовую базу к единому стандарту. Миграция для большинства пользователей должна пройти гладко, потому что Pasta, nftables и SQLite уже были дефолтами.

Но если вы работаете на нестандартных конфигурациях с iptables, BoltDB или cgroups v1, нужно подготовиться заранее.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

🔒 Спрятать VM от интернета и не потерять к ней доступ

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

Есть подход лучше. Называется «Private First». Суть в том, чтобы VM вообще не имела публичного адреса с момента создания. Нет адреса — нет поверхности атаки. А доступ к машине и выход в интернет настраиваются отдельными, контролируемыми каналами.

Что понадобится

VM без внешнего IP (например, e2-medium, Ubuntu 24.04 LTS), Cloud NAT с Cloud Router, Identity-Aware Proxy (IAP) для SSH и Tailscale для доступа к веб-интерфейсу. Всё это укладывается в бесплатный кредит GCP на $300.

Cloud NAT — выход в интернет без входа

VM без публичного IP не может сама ходить в интернет. Ни apt update, ни docker pull работать не будут. Cloud NAT решает это. Он даёт машине исходящий трафик через Cloud Router, но входящих соединений извне не пропускает.

VM видит интернет, интернет не видит VM.

IAP — SSH без открытого порта

Вместо того чтобы открывать порт 22 для всего мира, вы открываете его только для диапазона 35.235.240.0/20. Это адреса IAP-туннеля Google.

Каждая SSH-сессия проходит аутентификацию через Google Identity ещё до того, как первый пакет долетит до VM.

Подключение выглядит так:

gcloud compute ssh --tunnel-through-iap <instance-name>

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

Tailscale — доступ к веб-интерфейсу

Допустим, на VM крутится n8n, Metabase или любой другой сервис с веб-панелью. Выставлять её в интернет не нужно. Ставите Tailscale на VM и на свой ноутбук. Получаете приватную mesh-сеть поверх WireGuard. Дашборд доступен по адресу вроде http://<tailscale-ip>:5678 с любого вашего устройства. Без SSL-сертификатов, без reverse proxy, без публичного DNS.

Два нюанса с Docker

Если вы запускаете n8n в Docker, учтите два момента.

Контейнер может падать при старте из-за прав на директорию ~/.n8n. Внутренний пользователь n8n ожидает владельца 1000:1000. Фиксится одной командой:

sudo chown -R 1000:1000 ~/.n8n

По умолчанию n8n выставляет N8N_SECURE_COOKIE=true и принимает сессионные куки только по HTTPS. Через Tailscale вы ходите по HTTP на приватный IP, поэтому логин будет молча ломаться. Выставьте N8N_SECURE_COOKIE=false в переменных окружения Docker. На приватной VPN-сети это безопасно.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🔄 nginx 1.31.0: шесть CVE и встроенный forward proxy

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

Помимо фиксов, появилась долгожданная фича — поддержка HTTP CONNECT, то есть nginx теперь умеет работать как forward proxy.

Что исправлено

CVE-2026-42926 — инъекция данных в проксируемый запрос при использовании proxy_set_body с HTTP/2-бэкендом.

CVE-2026-42945 — переполнение буфера в ngx_http_rewrite_module. Специально сформированный запрос мог привести к выполнению произвольного кода. Одна из самых серьёзных уязвимостей в этом релизе.

CVE-2026-42946 — чтение за границами буфера в ngx_http_scgi_module и ngx_http_uwsgi_module. Атакующий мог вызвать раскрытие памяти рабочего процесса или его падение через специально сформированный ответ.

CVE-2026-42934 — аналогичная проблема с чтением за границами буфера, но уже в ngx_http_charset_module при декодировании UTF-8 через директиву charset_map.

CVE-2026-40460 — спуфинг адреса клиента в HTTP/3. При миграции соединения новые QUIC-стримы получали новый адрес клиента до его валидации.

CVE-2026-40701 — use-after-free при обработке DNS-ответов, если использовалась директива ssl_ocsp. Могло привести к повреждению памяти или падению рабочего процесса.

Что нового

Главное нововведение — модуль ngx_http_tunnel_module. Nginx теперь умеет обрабатывать HTTP CONNECT-запросы и работать как forward proxy. Модуль поддерживает аутентификацию через auth_basic, satisfy и auth_delay.

Также добавлена директива least_time внутри блока upstream. Она выбирает бэкенд с наименьшим временем ответа. Раньше эта функциональность была доступна только в NGINX Plus.

В stream-модуле появилась директива proxy_ssl_alpn для указания ALPN-протокола при проксировании с TLS.

Изменения в поведении

nginx теперь отклоняет HTTP/2 и HTTP/3 запросы с заголовками Connection, Proxy-Connection, Keep-Alive, Transfer-Encoding, Upgrade, а также TE с любым значением кроме trailers. Это соответствует спецификации, но если у вас есть клиенты, которые отправляют такие заголовки через HTTP/2, после обновления они получат ошибку.

Модуль ngx_http_dav_module теперь отклоняет COPY/MOVE, если источник и назначение совпадают или находятся в отношении «родитель-ребёнок».

Уровень логирования ошибок SSL «invalid alert» и «record layer failure» понижен с crit до info.

Обновление

Учитывая количество и критичность закрытых уязвимостей, обновляться стоит как можно скорее. Особенно если вы используете proxy_set_body, модуль rewrite, SCGI/uWSGI-бэкенды или HTTP/3.

➡️ Полный список изменений

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

⭐️ Три команды для быстрой диагностики Linux

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

Информация о системе

hostnamectl выводит сводку по ОС, ядру, архитектуре и типу виртуализации.

hostnamectl

Пример вывода:

Static hostname: linux-server
 Operating System: Ubuntu 24.04 LTS
 Kernel: Linux 6.8.0
 Architecture: x86-64
 Virtualization: oracle

Здесь сразу видно, на какой ОС работает сервер, какая версия ядра установлена, какая архитектура используется и запущена ли система внутри виртуальной машины. Одна команда вместо четырёх.

Информация о процессоре

lscpu показывает всё, что касается CPU.

lscpu

Пример вывода:

Architecture:        x86_64
CPU(s):              8
Model name:          Intel(R) Core(TM) i7
Thread(s) per core:  2
Core(s) per socket:  4

Обратите внимание на разницу между полями. CPU(s) — это общее число логических процессоров. Core(s) per socket — физические ядра. Thread(s) per core — количество потоков на ядро, то есть показатель гиперпоточности.

Команда полезна, когда проверяете характеристики сервера, ищете причину просадки производительности или хотите убедиться, что виртуалке выделено столько ресурсов, сколько заявлено.

Информация о дисках и разделах

lsblk выводит структуру блочных устройств.

lsblk

Пример вывода:

NAME   SIZE TYPE MOUNTPOINT
sda    100G disk
├─sda1  1G part /boot
├─sda2 50G part /
└─sda3 49G part /home

Команда показывает диски, разделы, их размеры и точки монтирования. Если путаете эти понятия, вот простое правило. Диск — это физическое или виртуальное устройство хранения целиком. Раздел — логическая часть внутри диска. В примере sda — это диск на 100 ГБ, а sda1, sda2, sda3 — три раздела внутри него.

Итого

Три команды, которые стоит запомнить:

hostnamectl — что за система
lscpu — что за процессор
lsblk — что за диски

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

❓ Где хранятся тома Docker в Linux по умолчанию

Вы создали volume командой docker volume create mydata. Куда на диске он попал?

💡 Подсказка: путь начинается с /var, а Docker хранит там не только тома, но и образы, контейнеры и сети.

➡️ Ответ

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#задача_со_звёздочкой

🛠 Продолжаем копать Kubernetes v1.36

В Kubernetes v1.36 поле .spec.externalIPs у Service официально помечено как deprecated. Удаление запланировано на v1.43. Если вы используете externalIPs в своих манифестах, пора планировать миграцию.

В чём проблема

Поле externalIPs появилось как способ направить внешний трафик на кластерные поды без облачного балансировщика. Идея простая: указываете IP, и kube-proxy создаёт правила iptables для маршрутизации трафика.

Проблема в том, что API не проверяет, кому принадлежит указанный IP. Любой пользователь с правами на создание или редактирование Service может указать произвольный внешний адрес. kube-proxy послушно создаст NAT-правила, и трафик, предназначенный для этого IP, уйдёт в под атакующего.

Это классическая атака «человек посередине». В мультитенантных кластерах, где у тенантов есть права на управление сервисами в своём неймспейсе, один скомпрометированный тенант может перехватывать трафик всего кластера. Уязвимость описана в CVE-2020-8554 ещё в декабре 2020 года.

Вот пример вредоносного сервиса, который перехватывает трафик к внешнему IP:

apiVersion: v1
kind: Service
metadata:
  name: mitm-externalip
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: echoserver
  type: ClusterIP
  externalIPs:
    - 104.16.185.241

После создания такого сервиса весь трафик с нод кластера к 104.16.185.241:80 будет перенаправлен на под echoserver. Без каких-либо предупреждений.

Почему так долго тянули

Проект Kubernetes рекомендовал отключать externalIPs ещё с версии 1.21, когда появился admission controller DenyServiceExternalIPs. Но SIG Network посчитала, что блокировка по умолчанию стала бы слишком серьёзным breaking change.

Спустя пять лет подход изменился. В v1.36 добавлен feature gate AllowServiceExternalIPs (по умолчанию true). Процесс удаления разбит на этапы:

В v1.36 kube-proxy получает возможность не создавать правила для externalIPs через feature gate. Использование поля генерирует deprecation warning.

В последующих релизах feature gate будет по умолчанию переключён на false, а затем поле будет полностью удалено. Финальное удаление запланировано на v1.43.

Что делать

Проверьте свои манифесты на наличие externalIPs:

kubectl get svc -A -o json | jq '.items[] | select(.spec.externalIPs != null) | {name: .metadata.name, ns: .metadata.namespace, ips: .spec.externalIPs}'

Варианты замены зависят от сценария. Для облачных кластеров подойдут Service типа LoadBalancer. Для bare-metal окружений стоит посмотреть в сторону MetalLB или другого контроллера внешних балансировщиков. Для HTTP-трафика есть реализации Gateway API.

Если вы уже используете Cilium в режиме замены kube-proxy, уязвимость CVE-2020-8554 вас не затрагивала, но миграция с externalIPs всё равно нужна, потому что само поле из API исчезнет.

Шесть лет жизни с известной MITM-уязвимостью подходят к концу. Поле externalIPs получило статус deprecated в v1.36 и будет удалено в v1.43. Времени достаточно, но аудит манифестов лучше провести сейчас, пока это ещё предупреждения, а не ошибки.

➡️ Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#локализация

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

👨‍💻 Terraform 1.15 — динамические источники модулей, deprecation переменных и другие обновления

Вышел Terraform 1.15. В этом релизе появились переменные в источниках модулей, механизм deprecation для переменных и output, функция convert для явного приведения типов и нативная поддержка Windows ARM64. Разберём основные изменения.

Динамические источники модулей

Раньше source в блоке module принимал только статическую строку. Теперь можно использовать переменные. Для этого добавлен новый атрибут const у переменных. Он принимает true или false и указывает, что значение доступно уже на этапе terraform init:

variable "folder" {
  type  = string
  const = true
}

После этого переменную можно подставлять в source:

module "zoo" {
  source = "./${var.folder}"
}

Важный момент — const нельзя сочетать с sensitive или ephemeral. Если вы сошлётесь на что-то кроме const-переменной, Terraform выдаст ошибку при init.

Deprecation переменных и output

Авторы модулей теперь могут помечать переменные и output как устаревшие через атрибут deprecated. При обращении к такому элементу Terraform покажет предупреждение на этапе валидации.

variable "bad" {
  deprecated = "Please use 'good' instead, this variable will be removed"
}

output "old" {
  value      = "some_value"
  deprecated = "Please use 'new' instead, this output will be removed"
}

Логика работает на нескольких уровнях. Если кто-то передаёт значение в deprecated-переменную через CLI или переменные окружения, будет warning. Если модуль ссылается на deprecated output дочернего модуля внутри своего deprecated output, предупреждение не сработает. Но если deprecated output стоит на корневом уровне, это уже ошибка.

Такой подход позволяет авторам модулей плавно выводить старые интерфейсы из обращения.

Inline-приведение типов через convert

Новая функция convert решает давнюю проблему с неявным приведением типов. Terraform обычно сам определяет типы, но в ряде случаев это работает некорректно. Например, {} интерпретируется как пустой object без атрибутов, а не как пустой map. Аналогично [] — это пустой tuple, а не list.

convert позволяет явно указать нужный тип и создавать корректные нулевые значения для сложных коллекций. Это особенно полезно в условных выражениях, где ветки возвращают данные разных типов.

Прочие изменения

Terraform 1.15 теперь собирается под Windows ARM64. Это актуально для владельцев Surface Pro, Windows Dev Kit 2023, а также для тех, кто запускает Windows-виртуалки на Mac M1/M2 через Parallels.

S3-бэкенд получил поддержку аутентификации через aws login (AWS CLI v2.32.0+). Это значит, что можно использовать credentials из консоли AWS без долгоживущих access-ключей.

У output-блоков появились type constraints — явные ограничения типа, аналогичные тем, что давно есть у input-переменных:

output "string" {
  type  = string
  value = var.some_string
}

В Terraform Test теперь разрешены функции внутри mock-блоков. Можно генерировать тестовые данные через uuid() или format(), что упрощает мокирование ресурсов с конкретными форматами ID.

Для Stacks добавлены validation-блоки в переменных с атрибутами condition и error_message. Это помогает ловить ошибки конфигурации на раннем этапе.

Обнова за обновой выходит каждый день. Мы отбираем только самое важное для вас в нашей рассылке. 👉 Подпишитесь

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии