Windows: winget configure. Настройка рабочего места одной командой

Мы уже говорили про winget install. Но Microsoft пошли дальше и представили winget configure — декларативный способ настройки окружения. Это ваш личный ansible-playbook для Windows-машины.
Вы больше не пишете скрипт "как установить". Вы создаете YAML-файл, описывающий, каким должно быть ваше окружение.

Как это работает:
Создаём конфигурационный файл workstation.dsc.yaml:
В нём мы описываем нужные приложения из winget и желаемые настройки PowerShell-модулей DSC.

YAML

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: install-powertoys
      directives:
        description: Install Microsoft PowerToys
      settings:
        id: Microsoft.PowerToys
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: install-vscode
      directives:
        description: Install Visual Studio Code
      settings:
        id: Microsoft.VisualStudioCode
        source: winget

    - resource: Microsoft.Windows.Developer/DeveloperMode
      id: enable-devmode
      directives:
        description: Enable Developer Mode
      settings:
        Ensure: Present

  configurationVersion: 0.2.0

Применяем конфигурацию:
Одна команда, которая проверит систему и приведёт её в соответствие с файлом.

PowerShell

# Сначала проверяем, что изменится (dry-run)
winget configure --file workstation.dsc.yaml

# Применяем конфигурацию
winget configure --file workstation.dsc.yaml --accept-configuration-agreements

Взгляд архитектора:
winget configure — это огромный шаг к Infrastructure as Code (IaC) на рабочих станциях. Конфигурационные YAML-файлы можно хранить в Git, версионировать и шарить внутри команды. Это обеспечивает идемпотентность и воспроизводимость окружения, гарантируя, что у каждого разработчика и админа будет одинаковый и предсказуемый набор инструментов.

#windows #winget #powershell #dsc #iac #automation #гайд

Windows & DSC: Аудит и принудительная настройка безопасности
Один из принципов архитектора — не просто настраивать систему, а гарантировать её состояние. PowerShell Desired State Configuration (DSC) позволяет описать, каким должен быть ваш сервер, и автоматически исправлять любые отклонения.

Давайте создадим простую, но мощную DSC-конфигурацию, которая следит за критически важными параметрами безопасности.

Что делает конфигурация:
Убеждается, что служба удаленного реестра (Remote Registry) отключена.
Гарантирует, что PowerShell v2 (старая и небезопасная версия) удален.
Включает WinRM (Windows Remote Management) для централизованного управления.
Код конфигурации (SecurityBaseline.ps1):

PowerShell

Configuration SecurityBaseline
{
    Node "localhost"
    {
        Service "RemoteRegistry"
        {
            Name        = "RemoteRegistry"
            StartupType = "Disabled"
            State       = "Stopped"
            Ensure      = "Present"
        }

        WindowsFeature "PowerShell-V2"
        {
            Name   = "PowerShell-V2"
            Ensure = "Absent"
        }
        
        WindowsFeature "WinRM"
        {
            Name   = "WinRM"
            Ensure = "Present"
        }
    }
}

# Компилируем конфигурацию в MOF-файл
SecurityBaseline

# Применяем конфигурацию
Start-DscConfiguration -Path ./SecurityBaseline -Wait -Verbose -Force

Взгляд архитектора: DSC — это не просто скрипт. Это реализация Infrastructure as Code (IaC) для Windows. Храните такие конфигурации в Git. Запускайте Test-DscConfiguration по расписанию, чтобы обнаруживать дрейф конфигурации (configuration drift) и получать алерты, когда состояние сервера отклоняется от эталона.

#windows #powershell #dsc #iac #security #гайд

AI-промпт: "Напиши за меня production-ready Terraform-модуль"

Админ просит AI: "напиши tf-файл для создания VM". Архитектор просит AI: "напиши переиспользуемый модуль".

Правильно написанный модуль main.tf, variables.tf, outputs.tf — это основа Infrastructure as Code (IaC). Давайте заставим AI следовать лучшим практикам.

Промпт (для ChatGPT/Gemini/Copilot):

Выступи в роли Senior DevOps Engineer, сертифицированного HashiCorp.

Создай структуру Terraform-модуля для развертывания "Azure Virtual Machine" (Linux). Модуль должен быть переиспользуемым, безопасным и следовать best practices.

Требования:
1.  Файлы: Раздели код на `main.tf`, `variables.tf` и `outputs.tf`.
2.  `main.tf`: Должен создавать группу ресурсов, VNet, Subnet, сетевой интерфейс (NIC) и саму VM (SKU `Standard_B2s`).
3.  `variables.tf`: Создай переменные для `location`, `vm_name`, `admin_username` и `admin_ssh_key` (публичный ключ).
4.  Безопасность: Не создавай публичный IP-адрес для VM. Доступ должен быть только по приватному IP.
5.  `outputs.tf`: Выведи наружу `private_ip_address` созданной VM.
6.  Комментарии: Добавь комментарии, объясняющие ключевые блоки.

Предоставь код для каждого из трех файлов.

Взгляд архитектора: AI здесь — не просто генератор кода. Это ускоритель для создания стандартных блоков (building blocks). Архитектор не тратит время на написание типовых модулей. Он использует AI, чтобы быстро получить 80% готового, качественного кода, а затем тратит 20% своего времени на его доработку, аудит и интеграцию в общую систему.

#ai4admin #terraform #iac #devops #azure #промпты #architect

Ansible: Хватит хранить пароли в Git! Используем ansible-vault

Вы написали гениальный плейбук, но в group_vars/all.yml у вас лежит db_password: "MySuperSecretPassword123". Теперь этот плейбук нельзя безопасно положить в Git.

Ansible Vault — это не отдельный инструмент, это встроенный в Ansible механизм шифрования. Он позволяет шифровать не целые плейбуки, а только файлы с чувствительными данными (например, vars/secrets.yml).

Как это работает (магия в 3 команды):

Создаём зашифрованный файл: Вместо nano vars/secrets.yml вы пишете:

Bash

ansible-vault create vars/secrets.yml

Ansible попросит вас придумать пароль (vault password) и откроет редактор. Вы вводите свои секреты, сохраняете, и файл на диске оказывается полностью зашифрован.

Редактируем файл:

Bash

ansible-vault edit vars/secrets.yml

Снова вводите пароль, редактируете, сохраняете. Файл остается зашифрованным.

Запускаем плейбук: Ansible сам поймет, что файл зашифрован, и спросит пароль при запуске.

Bash

# Ansible спросит пароль в консоли
ansible-playbook site.yml

# ...или используем файл с паролем (для CI/CD)
ansible-playbook site.yml --vault-password-file ~/.vault_pass

Взгляд архитектора: Это и есть GitOps в действии. Ваши секреты хранятся вместе с кодом, они версионируются, но остаются в безопасности. Архитектор строит единый источник правды (Single Source of Truth). С ansible-vault ваш Git-репозиторий становится этим источником для всей инфраструктуры, включая пароли и ключи.

#linux #ansible #devops #security #iac #gitops #гайд

Что такое GitOps?

Это не "Git". Это принцип, при котором ваш Git-репозиторий — единственный источник правды.

Как это работает:

1. Инженер: Пушит config.yml в Git.

2. Автоматика (CI/CD): Видит изменение.

3. Система (Kubernetes/Ansible): Приводит инфраструктуру в соответствие с Git.

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

#architect #devops #gitops #git #iac #sre

Архитектура: Принцип Idempotency (Идемпотентность)

Если вы дважды (или сто раз) запустите одну и ту же операцию, результат всегда будет одинаковым.

Простой пример:

Неидемпотентно: команда_создать_пользователя_Вася (выдаст ошибку, если Вася уже есть).

Идемпотентно: команда_убедиться_что_пользователь_Вася_существует (создаст, если нет; ничего не сделает, если есть).

Взгляд архитектора: Это основа Infrastructure as Code (IaC). Ваш Ansible-плейбук или Terraform-конфиг должны быть идемпотентны. Вы не боитесь запустить их 10 раз — они просто убедятся, что система в нужном состоянии, без побочных эффектов.

#architect #devops #iac #ansible #terraform #принципы

🧠 Skill: "Terraform Drift Detection" — навык №1 в 2026 году ☁️

В эпоху IaC (Infrastructure as Code) самая большая проблема — это Drift (отклонение).
Это когда кто-то зашел в консоль AWS/Azure/Yandex руками и поменял тип инстанса или открыл порт, а в коде Terraform осталось старое значение.

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

Что учить:

1. Terraform Plan Automation: Настрой запуск terraform plan в CI/CD раз в час.

2. Инструменты: Посмотри в сторону Driftctl или встроенного режима --refresh-only.

3. Команда для проверки "разрыва" между кодом и реальностью: terraform plan -refresh-only

Умение находить и устранять такие расхождения без даунтайма — это то, за что сегодня платят Senior DevOps инженерам. 🚀

#devops #terraform #iac #cloud #skills #automation #gitops

🧠 Skill: «Git-гигиена» — пиши коммиты для людей, а не для галочки

В 2026 году даже «чистый» админ живет в парадигме **Infrastructure as Code (IaC)**. Твои конфиги Ansible, Terraform или просто Bash-скрипты лежат в Git. Но есть проблема: коммиты типа `fixed bug`, `update` или `.....` — это мусор. Через полгода ты сам не поймешь, что там изменилось.

Как делать правильно:

1. Заголовок до 50 символов: Краткая суть (что изменилось).
2. Пустая строка после заголовка: Это стандарт Git для корректного отображения в логах.
3. Тело коммита: Опиши ПОЧЕМУ ты это сделал. Какой баг пофиксил или какой тикет в Jira закрыл.

Пример идеального коммита:

feat(network): переход на nftables для SSH-фильтрации

- Удалены старые правила iptables из конфига
- Внедрены динамические сеты для защиты от брутфорса
- Исправлена проблема с ложными срабатываниями на IP офиса (тикет #402)

Хорошая история коммитов — это лучшая документация твоей работы.

#skills #git #iac #devops #bestpractices #sysadmin #admin_future

🚀 Skills: Инфраструктурный нигилизм. Почему «надежность» больше не цель

Помните, как мы гордились серверами с аптаймом в 500 дней? В 2026 году такой сервер — это позор и огромная дыра в безопасности. Если ваша система не перезагружалась полтора года, значит, она не видела патчей ядра, обновлений микрокода ARM и критических фиксов библиотек.

Техническая суть:

Главный навык админа сегодня — не «поддержать жизнь», а «уметь убить и воскресить». Мы переходим от концепции надежности железа к концепции Resilience (упругости). Инфраструктура должна быть эфемерной.

Под капотом: Мы внедряем **Immutability** (неизменяемость). Конфигурация сервера не правится руками через SSH. Если нужно изменить один параметр в `sysctl`, вы меняете его в коде (IaC), пересобираете образ и пересоздаете инстанс.

Практика:

Ваш рабочий день должен начинаться не с проверки мониторинга «всё ли зеленое», а с проверки «пройдет ли сегодня автоматический редеплой 10% инфраструктуры».

# Пример декларативного описания состояния (Inspec / Goss)
# Мы проверяем не "как долго оно работает", а "соответствует ли оно стандарту 2026 года"

file:
  /etc/ssh/sshd_config:
    exists: true
    contains:
      - "Protocol 2"
      - "PermitRootLogin no"
      - "PubkeyAuthentication yes"
      - "KexAlgorithms curve25519-sha256@libssh.org" # Квантово-устойчивые алгоритмы

command:
  check_kernel_version:
    exec: "uname -r"
    exit-status: 0
    stdout:
      - "6.12" # Мы не сидим на старье

Зачем это нужно:

Это избавляет вас от «дрейфа конфигураций» (configuration drift). Когда у вас 1000 серверов, вы не можете быть уверены, что на 734-м какой-то стажер не поправил конфиг руками в три часа ночи. Только полная пересборка гарантирует идентичность и предсказуемость.

Вывод: Ваша ценность как инженера — в скорости восстановления системы с нуля, а не в умении годами латать дырявое корыто.

#skills #iac #observability #resilience #devops #admin_future

🚀 Skills: GitOps Lite. Почему твой /etc должен быть репозиторием

Помнишь то чувство ужаса, когда ты поправил конфиг, сервис упал, а ты забыл, что именно изменил? В 2026 году фраза «я сейчас всё верну как было по памяти» звучит как признание в профнепригодности. Админ сегодня — это не тот, кто много помнит, а тот, кто всё записывает в Git.

Техническая суть:

Концепция Infrastructure as Code (IaC) начинается не с Terraform, а с обычного git init в папке с твоими скриптами или конфигами.
Под капотом: Использование Git дает тебе машину времени. Ты всегда видишь, кто, когда и зачем изменил параметр в nginx.conf или в настройках active_directory. В 2026-м это стандарт: любой аудит безопасности начинается с просмотра истории коммитов в инфраструктурном репозитории.

Практика:
Начни внедрять GitOps на минималках прямо сейчас. Это спасет твою нервную систему:

# 1. Инициализируем репозиторий для критических конфигов
cd /etc/myapp/
git init

# 2. Создаем понятный коммит (забудь про "fix", пиши суть!)
git add .
git commit -m "CHG: Изменен таймаут коннекта к БД для ARM-кластера (Ticket #404)"

# 3. Если всё сломалось — откат за одну секунду
git checkout HEAD^1 config.yaml
systemctl restart myapp

# 4. Просмотр "кто виноват" (blame)
git blame config.yaml

Зачем это нужно:

Личное спокойствие и коллективная ответственность. Когда в команде больше одного человека, Git становится единственным источником правды. Больше никаких config.bak, config.old.2, config_LAST_FINAL. Только чистая история изменений и возможность мгновенного отката.

#skills #git #iac #devops #bestpractices #admin_future

🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически

Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?

Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.

Два подхода в зависимости от инструмента:

# ---- ANSIBLE: детекция дрейфа через --check --diff ----
# Запускаем playbook в режиме проверки без изменений
ansible-playbook site.yml \
  -i inventories/production/hosts.yml \
  --check \
  --diff

# Вывод покажет ВСЕ расхождения между кодом и реальностью
# Строки с "-" = что есть сейчас, "+" = что должно быть по коду

# Автоматизируем: добавляем в cron или CI/CD pipeline
# crontab -e:
# 0 9 * * 1 ansible-playbook /opt/ansible/site.yml -i production --check --diff \
#   2>&1 | mail -s "Weekly drift report" admin@company.com

# ---- TERRAFORM: детекция дрейфа через plan ----
# Показывает расхождения между state и реальным состоянием ресурсов
terraform plan -detailed-exitcode
# Exit code: 0 = нет изменений, 1 = ошибка, 2 = есть изменения (drift!)

# В CI/CD (GitLab CI пример):
# drift_check:
#   schedule: "0 8 * * *"  # каждый день в 8:00
#   script:
#     - terraform init
#     - terraform plan -detailed-exitcode
#   allow_failure: false

# ---- ПРАВИЛО: что делать при обнаруженном дрейфе ----
# Вариант 1: исправить реальность под код (правильно)
#   ansible-playbook site.yml -i production  # применяем playbook
#   terraform apply                           # применяем план

# Вариант 2: зафиксировать реальность в код (если изменение было намеренным)
#   Обновить playbook/tf-файл, commit, PR, code review
#   terraform import resource_type.name resource_id  # импортируем в state

Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.

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

#skills #iac #ansible #terraform #drift #sysadmin #admin_future

🧠 Skills: Cattle vs Pets — принцип которому 15 лет, но половина инфраструктур его игнорирует

Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.

Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.

Как выглядят «питомцы» в реальной жизни:

ПРИЗНАКИ "ПИТОМЦА":
  - У сервера есть имя собственное: "Старый-Файловый",
    "Сервак-Богдана", "Этот-трогать-нельзя"
  - Никто не знает что на нём запущено кроме одного человека
  - Последний раз переустанавливали в 2019 году
  - Конфиги правились руками, в git не попадали
  - Апгрейд невозможен — "упадёт всё"

ПРИЗНАКИ "СКОТА":
  - Серверы называются по роли + номер: web-01, db-03
  - Любой сервер можно удалить и поднять заново за минуты
  - Конфигурация полностью в Ansible/Terraform
  - Нет уникальных ручных настроек которые нигде не записаны
  - Новый член команды может задеплоить среду с нуля

Практический переход от питомцев к скоту — четыре шага:

# ШАГ 1: Аудит — какие серверы у нас "питомцы"?
# Признак: uptime больше года без переустановки
uptime -s  # дата последнего старта
# Если дата 2023 и раньше на продакшн-сервере — питомец

# ШАГ 2: Документируем что реально запущено (chef-solo, ansible-pull)
# На подозрительном сервере:
ss -tlnp          # что слушает
systemctl list-units --type=service --state=running
crontab -l; ls /etc/cron.d/   # кроны
find /etc -newer /etc/os-release -type f 2>/dev/null | head -20
# Последнее — файлы изменённые после установки ОС

# ШАГ 3: Описываем текущее состояние как Ansible playbook
# ansible-pull или ручное написание по результатам аудита
# Проверяем идемпотентность:
ansible-playbook site.yml --check --diff

# ШАГ 4: Blue/Green замена
# Поднимаем новый сервер по playbook
# Переключаем трафик (DNS, LB)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай

Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.

Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.

Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.

#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future