🚀 DevOps: Скрипт "CI/CD-раннер за 60 секунд" (Docker)

Боль: Ваш docker build в общем CI/CD GitLab/GitHub "висит" в очереди 20 минут. Вы не можете работать, потому что все "раннеры" заняты.

Реакция админа: "Пойду попью кофе, подожду".
Реакция архитектора: "Я запущу свой runner на своей Home Lab (или VDS) за 60 секунд".

Эти "однострочники" — это не просто docker run, это мгновенное масштабирование вашего CI/CD.

Скрипт для GitLab Runner:

# 1. Получите ваш Registration Token из GitLab (Settings -> CI/CD -> Runners)
GITLAB_TOKEN="ВАШ_ТОКЕН"

# 2. Запускаем "вечный" раннер в Docker
docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

# 3. Регистрируем раннер
docker exec -it gitlab-runner \
    gitlab-runner register \
    --non-interactive \
    --url "https://gitlab.com/" \
    --registration-token "$GITLAB_TOKEN" \
    --executor "docker" \
    --docker-image "docker:20.10" \
    --description "My-Docker-Runner"

Скрипт для GitHub Actions Runner: (Процесс похож, но требует docker-compose для авто-регистрации)

Взгляд архитектора: Это "Infrastructure on-demand" (Инфраструктура по требованию). Вы не ждете ресурсы, вы создаете их. Вы строите распределенную CI/CD-систему, используя Docker как "строительный блок".

#devops #docker #cicd #gitlab #github #automation #скрипты #гайд

🧠 Skills: Публичный GitHub — почему это важнее резюме в 2026 году

Коллеги, вторник — хороший момент для темы которую откладывают до лучших времён. Лучших времён не будет. Говорим о публичном профиле инженера.

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

В 2026 году это уже не нейтральная позиция — это упущенное преимущество.

Три конкретных шага которые меняют ситуацию:

ШАГ 1: ПУБЛИЧНЫЙ GITHUB С РЕАЛЬНЫМИ ИНСТРУМЕНТАМИ
(не "hello world", а то что реально используешь)

Что можно публиковать без риска:
  - Ansible roles для типовых задач
    (hardening, monitoring setup, backup scripts)
  - PowerShell-скрипты для AD-аудита
  - Docker-compose шаблоны для dev-окружений
  - Конфиги nginx/haproxy с комментариями
  - Runbook-шаблоны в Markdown

Что НЕ публиковать:
  - IP-адреса и имена хостов своей инфраструктуры
  - Credentials, tokens, пароли (даже в коментах)
  - Конфиги с именами пользователей и доменов компании
  - Специфику уязвимостей которые ещё не закрыты

Как проверить перед публикацией:
  git grep -E "password|secret|token|key" -- '*.yml' '*.sh'
  trufflehog filesystem . --only-verified

ШАГ 2: README КОТОРЫЙ ОБЪЯСНЯЕТ ЗАЧЕМ, А НЕ ТОЛЬКО КАК
  Плохой README: "Скрипт для бэкапа"
  Хороший README:
    "Скрипт автоматизирует ежедневный бэкап PostgreSQL
     с шифрованием через age, загрузкой в S3-совместимое
     хранилище и алертом в Telegram при ошибке.
     Используется на 15 серверах в продакшне."

  Разница: второй показывает что ты думал о надёжности,
  безопасности и масштабе — а не просто написал bash.

ШАГ 3: ОДИН РЕПОЗИТОРИЙ В МЕСЯЦ
  Не нужно всё сразу. Один полезный скрипт или плейбук
  с нормальным README в месяц — за год это 12 проектов.
  Это уже профиль который можно показать.

Почему это важно именно для сисадмина (не только для разработчика):

В 2026 году граница между sysadmin и infrastructure engineer размытая. Карьерный рост в IT-инфраструктуре предусматривает движение от технической поддержки и системного администрирования к старшему инженеру, архитектору и далее к руководящим ролям. На каждом переходе — публичный портфолио работает лучше чем пересказ резюме.

Зачем начинать сейчас: инженер который решил CVE-2026-46333 через ptrace_scope + ротацию ключей, написал плейбук для ModuleJail, и опубликовал его с README — это не просто хорошая история для собеседования. Это живое доказательство экспертизы.

Итог: один публичный репозиторий с чем-то реальным и полезным — лучшая инвестиция в карьеру которую можно сделать за вечер. Начни с того скрипта который написал на прошлой неделе.

#skills #github #карьера #портфолио #sysadmin #admin_future