Как и обещал, возвращаюсь с инструкцией, как можно обойти ограничения и облегчить себе жизнь. 

Нам нужно зеркало, можно использовать одно из публичных (например - https://huecker.io), но я бы не доверял чужим. Лучше поднять свое. Для этого есть два варианта. 

1. Достаточно простой

Берем в аренду сервер не в России. На нем поднимаем свое registry

Создайте файл конфигурации прокси config.yml:

version: 0.1
log:
  level: info
  fields:
    service: registry-proxy
cache:
  blobdescriptor: inmemory
proxy:
  remoteurl: https://registry-1.docker.io
storage:
  filesystem:
    rootdirectory: /var/lib/registry

Запускаем

docker run -d -p 5001:5000 --restart=always --name registry-proxy \
  -v /path/to/config.yml:/etc/docker/registry/config.yml \
  registry:2

Потом уже на своем компьютере или сервере (клиентской стороны) прописываем в файле для Linux /etc/docker/daemon.json или для Windows C:\ProgramData\docker\config\daemon.json

{
  "registry-mirrors": ["http://<your-mirror-host>:5001"]
}

После перезапускаем Docker sudo systemctl restart docker

2. Сложнее - устанавливаем и конфигурируем Nexus. Для этого можно воспользоваться одной из множеств инструкций, например https://timeweb.cloud/tutorials/cloud/ustanovka-i-ispolzovanie-nexus-repository-dlya-hraneniya-artefaktov. 

Для пользователей моего канала и для себя тоже, завтра подниму свое зеркало, и опубликую его адрес. Вам будет достаточно указать его в конфиге на своем компьютере/сервере, если не хотите заморачиваться с настройками.

#Docker #DockerHub #DevOps #Лайфхак

Еще один лайфхак по обходу ограничений - если вам нужно собрать свое и пишнуть в docker hub - можно делать в рамках CI/CD в Github Action. У GitHub пока есть доступ 🙂

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

Можно использовать просто:

docker pull registry.trueops.ru:443/proxy/nginx:latest

Либо указать адрес в registry-mirrors как писал выше.

#Docker #DockerHub #DevOps #Лайфхак

Последние две недели ходил с классной идеей, которую хотел реализовать и выложить на GitHub — резюме как код.

Суть простая: описываем по определенному шаблону в yml файле свое резюме, далее в рамках CI/CD процесса происходит генерация персонального сайта с резюме и блогом, создание резюме в виде PDF файла и публикация/обновление резюме на hh.ru, Habr.Карьера и LinkedIn.

Но когда сел делать исследование перед разработкой, суровая реальность заставила похоронить идею. Habr.Карьера не поддерживает API для кандидатов, только для рекрутеров. В LinkedIn также не нашел метода для работы со своим резюме, кроме его получения. Только hh.ru молодцы — позволяют работать с резюме с помощью API, но делать приложение только для них явно нецелесообразно.

Вот так суровые реалии ограничивают наши возможности. Но ничего, будем искать другие пути и идеи!

#IT #DevOps #резюме #карьера #API #GitHub #CICD #автоматизация

Привет, друзья! 👋

Недавний сбой в работе облачной платформы Microsoft Azure 19 июля вызвал горячие обсуждения в СМИ и особенно на Хабре. Многие спешат обвинить в этом разработчиков, но давайте разберемся глубже.

Основная причина сбоя — ошибка в обновлении ПО от компании CrowdStrike, отвечающей за безопасность. Это обновление вызвало «синий экран смерти» на устройствах с Windows 10, что привело к многочисленным проблемам для компаний по всему миру: от авиакомпаний до банков и больниц.

Однако, обвинять только разработчиков — это упрощение проблемы. Разработчики не работают в вакууме. Для выпуска качественного продукта необходимы здоровые процессы в компании. Вот как это должно выглядеть:

1. Системный аналитик анализирует требования.
2. Разработчик разрабатывает функционал.
3. Тестировщик проводит тестирование.
4. DevOps и релиз-менеджеры автоматизируют публикацию обновлений.

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

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

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

#Microsoft #Azure #сбой #разработчики #CrowdStrike #DevOps #CI_CD #тестирование #ИТпроцессы #команднаяработа

Готовлю доклад по AsyncAPI, обещал рассказать.

AsyncAPI — это спецификация для документирования и проектирования асинхронных API. В отличие от привычного REST, здесь речь идет о взаимодействии между сервисами через события, сообщения и очереди. Это особенно актуально для EDA, микросервисов, IoT-устройств и любых систем, где важен асинхронный обмен данными.

AsyncAPI помогает упорядочить и стандартизировать процессы работы с асинхронными коммуникациями. Это упрощает как разработку, так и поддержку проектов, где задействованы сложные архитектуры. По сути, это своего рода OpenAPI, но для асинхронных систем. Если с ним знакомы - удивитесь как похож синтаксис.

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

Кодогенерация и автоматизация — вот что мне больше всего зашло. Вы буквально можете сгенерировать код клиента или сервера на основе спецификации, а это экономит кучу времени. AsyncAPI отлично работает с современными DevOps процессами, что делает релизы более быстрыми и стабильными.

Если вы работаете с событиями, настоятельно рекомендую попробовать AsyncAPI в вашем следующем проекте.

Интересно, кто уже внедрил у себя? Пишите в комментариях! 👇

#AsyncAPI #API #микросервисы #IoT #документация #кодогенерация #DevOps #технологии #IT

Multi-stage builds и правильный .dockerignore могут уменьшить размер образа в несколько раз. Вместо этого:

FROM node:18
COPY . .
RUN npm install
RUN npm run build

Используйте:

FROM node:18-alpine AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /build /usr/share/nginx/html

А в .dockerignore добавьте node_modules, .git, tests. Образы собираются быстрее и занимают меньше места в registry.

Альтернативный подход - Buildpacks, но они менее гибкие в настройке.
#Docker #optimization #DevOps

Mozilla SOPS + age решают проблему хранения секретов в Git-репозитории. SOPS шифрует только значения, оставляя структуру файла читаемой:

# До шифрования
database:
    user: admin
    password: super_secret

# После шифрования
database:
    user: ENC[AES256_GCM,data=...] 
    password: ENC[AES256_GCM,data=...]

Поддерживает yaml/json/env файлы. Интегрируется с cloud KMS или локальными ключами через age. В отличие от Vault, не требует отдельного сервера.
#security #DevOps #GitOps

Для анализа метрик в Prometheus часто используют increase(metric[5m])/300, но это не самый удачный подход. Rate(metric[5m]) даёт более точные результаты, особенно при нестабильном скрейпинге или пропуске метрик.

Rate сразу показывает значение в секунду и правильно обрабатывает counter reset. Плюс формула короче и понятнее. Win-win!
P.S. Для событий, которые случаются редко (раз в минуту или реже), лучше использовать increase.
#Prometheus #monitoring #DevOps

🔥 Пишу прямо с Highload++! Конференция настолько насыщенная, что только сейчас выдалась минутка поделиться впечатлениями. А через час уже самому выступать!

Хочу рассказать про сногсшибательный доклад Евгения Харченко из Райффайзен Банка про инженерную культуру (Инженерная культура на масштабе: как развивать и оценивать практики). Ребята сделали нереальную вещь – полностью автоматизировали внедрение инженерной культуры! И главное – всё по-инженерному, с измеримыми результатами и доказанной эффективностью на реальных цифрах 📊

Уже взял контакт Евгения для референса. Как только выйдет видео – обязательно поделюсь, это must-watch!

#Highload2024 #EngineeringCulture #DevOps #RaiffeisenBank #ITConference

🎤 Выступил! Делился историей о том, как мы не справились с нагрузкой в 20 000+ RPS, и какие уроки из этого вынесли.

Если честно – это было самое волнительное выступление в моей карьере. И дело не только в масштабе конференции и количестве слушателей, но и в самой теме. Хотелось честно рассказать о том, что проблемы случаются у всех – важно не это, а то, как мы с ними справляемся 💪

Надеюсь, теперь у инженеров будет под рукой наглядный кейс, который можно показать менеджменту – вот что бывает, если игнорировать технические риски на старте 😉

Презентацию можно посмотреть тут

А сейчас пойду немного выдохну и пройдусь по стендам – мерч сам себя не соберет 🎁

#Highload2024 #PublicSpeaking #SystemDesign #DevOps #ITConference

Для регулярных задач в Linux обычно используют crontab, но systemd timers дают больше возможностей. Вместо записи в crontab создаем два файла:

backup.service:

[Service]
ExecStart=/usr/local/bin/backup.sh

backup.timer:

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Преимущества: встроенный журнал событий (journalctl), мониторинг состояния (systemctl status), оповещения о сбоях и возможность задать зависимости между сервисами.

#Linux #automation #DevOps

3 проверенных стека для метрик:

Классика: Prometheus + Grafana
➕ Простота, огромное комьюнити
➖ Масштабируется до средних нагрузок
Идеально для начала и небольших систем

Длинное хранение: VictoriaMetrics + Grafana
➕ Хранит годы данных, совместим с Prometheus
➖ Сложнее в настройке
Отлично для растущих проектов

Распределенный: Thanos + Prometheus + Grafana
➕ Горизонтальное масштабирование
➖ Сложная инфраструктура
Для больших распределенных систем

#monitoring #devops #metrics"

Привет! Если вы думали над тем, чтобы заменить bash на Go для CI/CD, получить мощные инструменты тестирования, отладки и читаемый код, посмотрите на Dagger. Это инструмент, который позволяет писать CI/CD-пайплайны на Go, TypeScript или Python — как обычный код. Например сборка приложения и публикация в registry:

package main

import (
    "context"
    "dagger.io/dagger"
)

func main() {
    ctx := context.Background()
    client, err := dagger.Connect(ctx)
    if err != nil {
        panic(err)
    }
    defer client.Close()

    // Собираем Docker-образ
    image := client.Container().Build(client.Host().Directory("."))
    
    // Пушим в registry
    _, err = image.Publish(ctx, "my-registry/my-app:latest")
    if err != nil {
        panic(err)
    }
}

Из минусов, кода становится больше:

#!/bin/bash
echo "Building app..."
docker build -t my-app .
echo "Pushing to registry..."
docker tag my-app my-registry/my-app:latest
docker push my-registry/my-app:latest

Но на больших и сложных кейсах приемущество становиться очевидным.

#DevOps #CI_CD #Dagger #Automation #GoLang

Мне все больше нравится работать с легковесной альтернативой Elastic - Vector + Loki + Grafana 📊
Легче, дешевле, и работает с PromQL, который вы уже знаете по метрикам!
#мониторинг #логи #vector #loki #grafana #devops