добавил новую статью про мой факап с настроками wireguard и поправил frontmatter статей, добавил hero в шаблон постов
This commit is contained in:
@@ -0,0 +1,254 @@
|
||||
---
|
||||
date: '2026-04-26T04:58:44-04:00'
|
||||
lastmod: '2026-04-26T04:58:44-04:00'
|
||||
draft: false
|
||||
title: 'Ansible в Windows 10 через WSL2: Debian, uv, VHDX и удобный рабочий процесс'
|
||||
slug: 'ansible-controller-on-win10'
|
||||
description: ''
|
||||
|
||||
categories:
|
||||
- 'devops'
|
||||
|
||||
tags:
|
||||
- 'devops'
|
||||
- 'ansible'
|
||||
- 'windows'
|
||||
- 'iac'
|
||||
|
||||
keywords:
|
||||
- 'wsl'
|
||||
- 'win10'
|
||||
- 'ansible'
|
||||
- 'powershell'
|
||||
- 'iac'
|
||||
|
||||
cover:
|
||||
image: "hero.svg"
|
||||
alt: "Ansible в Windows 10 через WSL2"
|
||||
relative: true
|
||||
---
|
||||
|
||||
На домашней машине у меня всё еще Winodws 10 стоит(домашние предпочитают удобные цепи закрытого софта вместо свободы), но доставать ноут каждый раз когда нужно управлять инфраструктурой через Ansible бывает сложно, самый практичный путь — поставить Debian в WSL2 и работать уже внутри него. Такой сценарий дает полноценную Linux-среду, не требует отдельной виртуальной машины и удобно бэкапится целиком через wsl --export в формат VHDX.
|
||||
|
||||
Ниже — полностью рабочая схема без Microsoft Store: ручная установка WSL2, импорт Debian, настройка uv, установка ansible-core, маппинг проекта на D:\ansible и резервное копирование через VHDX.
|
||||
|
||||
## Что понадобится
|
||||
|
||||
Для WSL2 на Windows 10 нужна версия 2004 и сборка 19041 или новее, а также включенная аппаратная виртуализация в BIOS/UEFI. Установка WSL и Debian выполняется из PowerShell от имени администратора.
|
||||
|
||||
- Windows 10 с поддержкой WSL2.
|
||||
- PowerShell с правами администратора.
|
||||
- Доступ к интернету для загрузки компонентов и пакетов.
|
||||
- Папка для WSL, например D:\WSL\Debian.
|
||||
- Папка для проектов, например D:\ansible.
|
||||
|
||||
## Включаем WSL2 вручную
|
||||
|
||||
Если Microsoft Store недоступен или вы не хотите им пользоваться, включите компоненты Windows вручную:
|
||||
|
||||
```powershell
|
||||
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
|
||||
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
|
||||
```
|
||||
|
||||
После этого перезагрузи ПК. Эти два компонента нужны для работы WSL2, потому что дистрибутив запускается внутри легковесной виртуальной машины.
|
||||
|
||||
Затем задаём WSL2 как версию по умолчанию:
|
||||
|
||||
```powershell
|
||||
wsl --set-default-version 2
|
||||
```
|
||||
|
||||
## Устанавливаем Debian без Store
|
||||
|
||||
Для установки Debian без Microsoft Store удобнее использовать импорт rootfs-архива или готового VHDX-образа. Важно не искать случайные архивы по форумам, а брать Debian из официального источника или собирать rootfs на основе официального образа Debian.
|
||||
|
||||
На практике удобны два пути:
|
||||
|
||||
скачать официальный Debian-образ и подготовить из него rootfs;
|
||||
|
||||
либо сразу импортировать уже готовый rootfs-архив, если он у вас есть.
|
||||
|
||||
Пример импорта:
|
||||
|
||||
```powershell
|
||||
mkdir D:\WSL\Debian
|
||||
wsl --import Debian D:\WSL\Debian D:\Downloads\debian-rootfs.tar --version 2
|
||||
```
|
||||
|
||||
После этого запускаем Debian так:
|
||||
|
||||
```powershell
|
||||
wsl -d Debian
|
||||
```
|
||||
|
||||
Если Debian уже был установлен из Store, его можно перенести в управляемый каталог через экспорт и повторный импорт, что особенно удобно для бэкапа и миграции.
|
||||
|
||||
## Перенос Debian из Store
|
||||
|
||||
Сценарий переноса простой: экспортируем текущий дистрибутив, затем импортируем его в нужную папку. Microsoft документирует wsl --export, wsl --unregister и wsl --import как штатный путь для переноса и резервного копирования WSL-дистрибутивов.
|
||||
|
||||
```powershell
|
||||
|
||||
# Смотрим имя дистрибутива:
|
||||
wsl -l -v
|
||||
|
||||
#Останавливаем WSL
|
||||
wsl --shutdown
|
||||
|
||||
#Экспортируем Debian в архив
|
||||
wsl --export Debian D:\Backup\Debian.tar
|
||||
|
||||
#Удаляем старую регистрацию, если нужен чистый перенос
|
||||
|
||||
wsl --unregister Debian
|
||||
|
||||
#Импортируем в управляемую папку
|
||||
wsl --import Debian D:\WSL\Debian D:\Backup\Debian.tar --version 2
|
||||
```
|
||||
|
||||
После этого Debian будет жить в D:\WSL\Debian, а не в Store-профиле пользователя, и им станет проще управлять и делать бэкап.
|
||||
|
||||
## Настраиваем Ansible через uv
|
||||
|
||||
Для Ansible в WSL2 я рекомендую не системную установку и не pip в системный Python, а отдельное виртуальное окружение, управляемое через uv. Такой подход изолирует зависимости, не трогает системный Python Debian и позволяет легко воспроизводить окружение после восстановления из бэкапа.
|
||||
|
||||
ansible-core — это базовый движок Ansible. В отличие от полного пакета ansible, он содержит только ядро: выполнение playbook’ов, inventory-логику, CLI и основную инфраструктуру. Это делает установку легче, прозрачнее и удобнее для проектного workflow.
|
||||
|
||||
Минимальный набор для установки:
|
||||
|
||||
- uv;
|
||||
- ansible-core;
|
||||
- openssh-client;
|
||||
- git;
|
||||
- python3.
|
||||
|
||||
После входа в Debian:
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install -y curl git openssh-client python3
|
||||
curl --proto '=https' --tlsv1.2 -LsSf https://releases.astral.sh/github/uv/releases/download/0.11.7/uv-installer.sh | sh
|
||||
```
|
||||
|
||||
После установки uv нужно переоткрытьshell-сессию или добавьте uv в PATH, если установщик это не сделал автоматически. uv умеет создавать виртуальные окружения и ставить пакеты внутрь них, а также работать с выбранным Python-интерпретатором.
|
||||
|
||||
Создаем окружение
|
||||
Если проект лежит в ~/ansible:
|
||||
|
||||
```bash
|
||||
cd ~/ansible
|
||||
uv venv
|
||||
source .venv/bin/activate
|
||||
uv pip install ansible-core
|
||||
```
|
||||
|
||||
Если нужен линтер:
|
||||
|
||||
``` bash
|
||||
uv pip install ansible-core ansible-lint
|
||||
```
|
||||
|
||||
Такой workflow хорош тем, что версию Ansible можно менять независимо от системы, а зависимости проекта не смешиваются с Debian-пакетами.
|
||||
|
||||
Почему ansible-core удобнее
|
||||
Для рабочей машины под Ansible ansible-core обычно удобнее, чем полный пакет ansible, по нескольким причинам. Во-первых, он меньше и чище, поэтому окружение проще поддерживать. Во-вторых, вы явно контролируете, какие коллекции и зависимости нужны именно вашему проекту. В-третьих, это снижает зависимость от версии, которую выдает системный репозиторий Debian.
|
||||
|
||||
Практически это означает следующее:
|
||||
|
||||
- ansible-core ставится в проектный venv;
|
||||
- коллекции ставятся отдельно через ansible-galaxy или по requirements.yml;
|
||||
- при необходимости окружение можно пересоздать за пару минут.
|
||||
|
||||
Рекомендуемый workflow
|
||||
|
||||
```bash
|
||||
mkdir -p ~/ansible
|
||||
cd ~/ansible
|
||||
uv venv
|
||||
source .venv/bin/activate
|
||||
uv pip install ansible-core
|
||||
```
|
||||
|
||||
Дальше в репозитории храним:
|
||||
|
||||
- playbook’и;
|
||||
- inventory;
|
||||
- requirements.yml;
|
||||
- ansible.cfg.
|
||||
Сами зависимости и .venv в Git не добавляем. Это делает проект переносимым и аккуратным.
|
||||
|
||||
## Маппинг ~/ansible в D:\ansible
|
||||
Если хотите хранить проект на диске Windows, используйте стандартный путь WSL: D:\ansible в Linux виден как /mnt/d/ansible. Это штатный механизм WSL, а для обратного преобразования путей существует wslpath.
|
||||
|
||||
Самый простой вариант:
|
||||
|
||||
```bash
|
||||
cd /mnt/d/ansible
|
||||
```
|
||||
|
||||
Если хотите, чтобы в Linux путь был именно ~/ansible, создайте символическую ссылку:
|
||||
|
||||
```bash
|
||||
rm -rf ~/ansible
|
||||
ln -s /mnt/d/ansible ~/ansible
|
||||
```
|
||||
|
||||
После этого ~/ansible будет указывать на D:\ansible. Это удобно: в Ansible-проектах вы работаете с привычным Linux-путем, а файлы физически лежат на Windows-диске.
|
||||
|
||||
|
||||
## Команды управления WSL
|
||||
Минимальный набор команд для повседневной работы:
|
||||
|
||||
```powershell
|
||||
# Показать все дистрибутивы и их версию
|
||||
wsl -l -v
|
||||
|
||||
# Запустить Debian
|
||||
wsl -d Debian
|
||||
|
||||
# Сделать Debian дистрибутивом по умолчанию
|
||||
wsl --set-default Debian
|
||||
|
||||
# Полностью остановить WSL2
|
||||
wsl --shutdown
|
||||
|
||||
# Остановить только Debian
|
||||
wsl --terminate Debian
|
||||
|
||||
# Перевести Debian в WSL2, если он вдруг оказался в WSL1
|
||||
wsl --set-version Debian 2
|
||||
```
|
||||
|
||||
## Бэкап через VHDX
|
||||
Для WSL2 самый удобный резервный формат — VHDX. Microsoft прямо поддерживает экспорт дистрибутива в VHDX через wsl --export ... --vhd, а затем импорт обратно через wsl --import ... --vhd. Это сохраняет весь дистрибутив целиком, включая Ansible, Python-окружение, ключи, историю shell и рабочие файлы.
|
||||
|
||||
```powershell
|
||||
# Перед бэкапом обязательно останавливаем WSL
|
||||
wsl --shutdown
|
||||
|
||||
# Затем создаtv бэкап
|
||||
wsl --export Debian D:\Backup\Debian\Debian.vhdx --vhd
|
||||
```
|
||||
|
||||
Это удобнее ручного копирования ext4.vhdx, потому что команда сразу создает переносимый снимок дистрибутива в формате VHDX.
|
||||
|
||||
## Восстановление
|
||||
Если нужно восстановить среду из такого бэкапа, импортируем VHDX как дистрибутив:
|
||||
|
||||
```powershell
|
||||
wsl --import DebianRestored D:\WSL\DebianRestored D:\Backup\Debian\Debian.vhdx --vhd --version 2
|
||||
```
|
||||
|
||||
Если мы храним дистрибутив в отдельной папке и используете import-in-place, можно подключить существующий VHDX без распаковки. Это особенно удобно при переносе среды на другой диск или другой компьютер.
|
||||
|
||||
## Практичная схема для работы
|
||||
Для повседневного использования я бы рекомендовал такую схему:
|
||||
|
||||
- Debian живет в WSL2;
|
||||
- Ansible ставится через uv в .venv;
|
||||
- проекты лежат в D:\ansible и маппятся через /mnt/d/ansible;
|
||||
- резервная копия делается через wsl --export ... --vhd;
|
||||
- .venv в Git не хранится, а dependencies фиксируются в документации или requirements.yml.
|
||||
|
||||
Такой подход дает хорошую изоляцию, быстрый старт после восстановления и удобную миграцию между машинами. Для WSL2 это один из самых практичных способов использовать Ansible в Windows 10 без необходимости перезагрузки.
|
||||
Reference in New Issue
Block a user