🔧 Terraform + Argo CD: современный способ интеграции для GitOps

В этой свежей статье предложен элегантный способ связать Terraform и Argo CD в рамках GitOps-подхода.

📌 В чём проблема:
Terraform управляет инфраструктурой, а Argo CD — приложениями в Kubernetes. Но часто возникает разрыв: как передавать выходные данные Terraform (outputs) в Argo CD, чтобы оно подхватывало созданные ресурсы (например, адреса сервисов, пути, переменные)?

🧠 Ключевая идея:
Использовать multi-source Argo CD Application — это позволяет в одном объекте Application подключить сразу несколько Git-репозиториев или путей:
- один для output’ов из Terraform (в виде YAML-файлов)
- второй — с настоящими Kubernetes-манифестами приложений

🛠 Пример потока:
1. Terraform генерирует output-файл (например, с URL или secrets) и коммитит в Git
2. Argo CD отслеживает этот файл как отдельный источник
3. Приложение автоматически получает эти значения и применяет манифесты с учётом output’ов

🎯 Зачем это нужно:
• меньше ручной синхронизации
• больше автоматизации в CI/CD
• централизованный контроль через Git
• минимальные костыли: без сторонних скриптов, прокладок и Helm magic

📎 Поддерживается в Argo CD начиная с версии 2.6+
Подробный YAML-пример и реализация — в оригинальной статье 👉 [akuity.io](https://akuity.io/blog/yet-another-take-on-integrating-terraform-with-argo-cd)

💡 Отличный способ повысить чистоту GitOps и устранить разрыв между инфраструктурой и приложениями.

📌 Читать

🛠️ История создания “storage-agnostic” message queue

Автор — Fahim Faisaal — делится опытом разработки гибкой очереди задач на Go, которая может использовать любые хранилища: in-memory, Redis, SQLite и др. :contentReference[oaicite:0]{index=0}

Контекст:
Занимаясь на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы :contentReference[oaicite:1]{index=1}.

⚡ Основная проблема

Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?
🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1. Worker pool — пул воркеров, обрабатывающих задачи.
2. Queue interface — абстракция над очередью, не зависящая от реализации.

Теперь воркер просто берёт задачи из очереди, не зная, где они живут. :contentReference[oaicite:2]{index=2}

---

### 🧠 Пример использования

- In-memory очередь:

w := varmq.NewVoidWorker(func(data any) {
   // обработка задачи
}, 2)
q := w.BindQueue()

- С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)

- С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)

В итоге воркер обрабатывает задачи одинаково — независимо от хранилища. :contentReference[oaicite:3]{index=3}

✅ Почему это круто

- Гибкость: адаптеры позволяют легко менять хранилище без правок воркера.
- Минимальные зависимости: в ядре — zero-deps, весь функционал — через адаптеры.
- Self-hosted и легковесно: можно развернуть локально или в продакшене.
- Написано на Go: использует горутины и каналы, удобен и эффективен.

📣 Отзывы сообщества

На Reddit отметили, что автор добился "queue system that doesn’t care if your storage is Redis, SQLite, or even in-memory" :contentReference[oaicite:4]{index=4}

🔗 Ссылки
- Статья: A Story of Building a Storage‑Agnostic Message Queue на DEV :contentReference[oaicite:5]{index=5}
- GitHub VarMQ (Var-storage-agnostic message queue): репозиторий с кодом адаптеров и примерами использования :contentReference[oaicite:6]{index=6}

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

📌 Читать

🧪 Go synctest — решение для нестабильных (flaky) тестов

Flaky-тесты в многопоточном Go-коде — боль. Новый экспериментальный инструмент synctest из Go 1.24 решает эту проблему с помощью синтетического времени и контроля исполнения goroutine.

📌 Что это такое:
synctest — специальный режим, запускающий тесты в изолированной "песочнице", где:
• time.Sleep не ждёт реального времени
• все goroutine исполняются детерминированно
• нет зависимости от планировщика и нагрузки ОС

🔧 Пример:

import "testing/synctest"

func TestSharedValue(t *testing.T) {
    synctest.Run(func() {
        var shared atomic.Int64
        go func() {
            shared.Store(1)
            time.Sleep(1 * time.Microsecond)
            shared.Store(2)
        }()
        time.Sleep(5 * time.Microsecond)
        if shared.Load() != 2 {
            t.Errorf("shared = %d, want 2", shared.Load())
        }
    })
}

⏱ Даже с Sleep, результат всегда стабилен. Без synctest такой тест может иногда проваливаться.

⚙️ Преимущества:
✅ Устранение race-условий при тестировании
✅ Нет задержек — Sleep срабатывает мгновенно
✅ Можно тестировать поведение с точностью до микросекунды
✅ Подходит для любых atomic, mutex, select, time.After и др.

🚫 Ограничения:
• Пока экспериментально: нужно запускать с GOEXPERIMENT=synctest
• Не подходит для ввода-вывода, работы с сетью или временем вне "bubble"

📖 Подробнее:
https://victoriametrics.com/blog/go-synctest/

📢 GORM теперь поддерживает дженерики — работа с БД в Go стала ещё проще и безопаснее!

С версии GORM v1.30.0 появилась полноценная поддержка дженериков (Go 1.18+), которая позволяет писать более выразительный и типобезопасный код без шаблонных повторов.

🔧 Пример:

ctx := context.Background()

// Создание
gorm.G[User](db).Create(ctx, &User{Name: "Alice"})

// Поиск
user, err := gorm.G[User](db).Where("name = ?", "Alice").First(ctx)

// Обновление
gorm.G[User](db).Where("id = ?", user.ID).Update(ctx, "age", 30)

// Удаление
gorm.G[User](db).Where("id = ?", user.ID).Delete(ctx)

✅ Что это даёт:
• Типобезопасность на этапе компиляции
• Более компактный и читаемый код
• Лёгкая интеграция с OnConflict, Joins, Hints, Preload и пр.
• Улучшенный DX (developer experience)

📎 Документация: https://gorm.io/docs/the_generics_way.html

Если ты пишешь на Go и используешь GORM — самое время перейти на новый стиль.

🚀 Кэширование в Go: как делать правильно

В свежей статье от Leapcell рассматриваются ключевые аспекты эффективного кэширования в Go:

- Планирование объёма памяти: важно заранее оценить, сколько данных будет кэшироваться, чтобы избежать переполнения памяти (OOM).

- Классификация данных: разделение данных на "горячие" и "холодные" помогает оптимизировать использование ресурсов, сохраняя часто используемые данные в быстром доступе, а редко используемые — на более экономичных носителях.

- Стратегии кэширования в распределённых системах:
- Использование распределённого кэша (например, Redis).
- Направление одинаковых запросов на один и тот же экземпляр приложения.
- Репликация кэша на каждом экземпляре приложения.

- Политики вытеснения: применение алгоритма LRU (Least Recently Used) помогает контролировать размер кэша, удаляя наименее используемые элементы.

Подробнее: https://dev.to/leapcell/caching-in-go-doing-it-right-25i5

🌀 Middleware и RoundTripper в Go: гибкая обработка HTTP-запросов

В Go нет встроенного понятия "middleware", как в других фреймворках — но вы можете легко реализовать его сами, особенно в контексте http.RoundTripper.

🔧 RoundTripper — это интерфейс, который обрабатывает HTTP-запросы на уровне клиента (`http.Client`). Это даёт возможность внедрять логику *до* и *после* отправки запроса.

🧱 Пример: логгер запросов

type LoggingRoundTripper struct {
    rt http.RoundTripper
}

func (l *LoggingRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
    log.Printf("📤 Запрос: %s %s", req.Method, req.URL)
    resp, err := l.rt.RoundTrip(req)
    if err == nil {
        log.Printf("📥 Ответ: %d", resp.StatusCode)
    }
    return resp, err
}

📦 Использование:

client := &http.Client{
    Transport: &LoggingRoundTripper{rt: http.DefaultTransport},
}

💡 Таким образом, вы можете создавать middleware прямо внутри http.Client, например:
• логирование
• кэширование
• модификация заголовков
• retry-логика
• трейсинг

🔗 Подробнее: dev.to/calvinmclean/middleware-and-roundtrippers-in-go-30pa

#golang #httpclient #middleware #webdev #devtools

Раньше: многоэтапные собеседования и тестовые
Сейчас: возможность получить оффер за один день!

Сбер зовёт Go-разработчиков на One Day Offer — он пройдёт 21 июня в онлайн-формате. Команда ищет будущих коллег в рекламную платформу SberAds сразу в несколько продуктов:

— Медийная реклама
— Performance Ads
— Инструменты разработки
— RTS

Регистрируйтесь на One Day Offer и будьте готовы к карьерным изменениям и работой над действительно масштабными задачами!