Рабочая станция DevOps на Windows: SSH, Git, Docker и WSL

Зачем DevOps-инженеру правильно настраивать рабочую станцию

Рабочий компьютер DevOps-инженера - это фактически точка управления всей инфраструктурой. С него выполняются подключения по SSH, работа с Git, просмотр логов, управление Docker-контейнерами, запуск Terraform и Ansible, подключение к Kubernetes, проверка HTTP-запросов и диагностика сетевых проблем.

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

Разберем практический набор ПО для DevOps-инженера, который работает на Windows, но регулярно взаимодействует с Linux-серверами, контейнерами и облачной инфраструктурой.

Терминал: основа рабочей станции

Большая часть работы DevOps выполняется через командную строку. Даже если для Kubernetes, Docker или Git существуют графические интерфейсы, терминал остается универсальным способом управления инфраструктурой.

На Windows стоит иметь как минимум PowerShell и современный терминал с поддержкой нескольких вкладок. Удобная схема работы выглядит примерно так:

PowerShell
├── Git
├── ssh
├── docker
├── kubectl
├── terraform
├── ansible через WSL
└── вспомогательные CLI-утилиты

Главное преимущество такого подхода - большинство операций выполняется одинаково независимо от конкретного сервера или проекта.

Проверяем доступность SSH

Первое, что стоит проверить после настройки системы:

ssh -V

После этого можно подключаться к Linux-серверу:

ssh user@192.168.1.100

Однако постоянно вводить IP-адреса, логины и дополнительные параметры неудобно. Лучше использовать SSH config.

Создайте файл:

C:\Users\USERNAME\.ssh\config

И добавьте подключение:

Host production
    HostName 192.168.1.100
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519

После этого подключение выполняется короткой командой:

ssh production

Для нескольких серверов можно создать отдельные записи production, staging, database, monitoring и использовать понятные имена вместо IP-адресов.

Git для работы с конфигурациями и Infrastructure as Code

Git нужен DevOps-инженеру не меньше, чем разработчику. В репозиториях обычно хранятся Dockerfile, Compose-конфигурации, Kubernetes manifests, Helm charts, Terraform-код, Ansible playbooks, CI/CD pipelines и внутренние runbook.

После установки Git проверьте его работу:

git --version

Настройте имя и email:

git config --global user.name "DevOps Engineer"
git config --global user.email "devops@example.com"

Посмотреть текущую конфигурацию:

git config --global --list

Для доступа к Git-серверам удобнее использовать SSH-ключи вместо постоянного ввода пароля.

ssh-keygen -t ed25519

Публичная часть ключа обычно располагается в файле:

~/.ssh/id_ed25519.pub

Приватный ключ нельзя отправлять коллегам, помещать в Git-репозиторий или хранить в общедоступных папках.

Visual Studio Code как редактор конфигураций

Для DevOps нужен редактор, который одинаково удобно работает с YAML, JSON, Dockerfile, Bash, Python и конфигурационными файлами. Один из распространенных вариантов - Visual Studio Code.

Типичная структура инфраструктурного проекта может выглядеть так:

infrastructure/
├── docker/
│   ├── Dockerfile
│   └── compose.yaml
├── kubernetes/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf
├── ansible/
│   ├── inventory.ini
│   └── playbook.yml
└── scripts/
    ├── backup.sh
    └── deploy.sh

При работе с инфраструктурой особенно полезны подсветка синтаксиса, встроенный терминал, просмотр Git diff и автоматическое форматирование файлов.

WSL: Linux-среда внутри Windows

Даже если основной системой остается Windows, DevOps-инженеру часто требуется полноценное Linux-окружение. Многие серверные инструменты изначально ориентированы именно на Linux.

WSL позволяет получить Linux shell непосредственно на рабочей станции и использовать привычные команды:

grep
sed
awk
curl
ssh
rsync
tar
find
chmod
chown

Например, поиск ошибки во вложенных логах:

grep -R "connection refused" ./logs

Поиск крупных файлов:

find . -type f -size +100M

Просмотр последних строк журнала:

tail -n 100 application.log

WSL особенно удобен, если production-среда работает на Linux: локальные команды и скрипты становятся гораздо ближе к тем, которые используются непосредственно на серверах.

Docker для локального запуска инфраструктуры

Контейнеры позволяют запускать локально базы данных, Redis, веб-приложения, очереди сообщений, системы мониторинга и множество других компонентов без ручной установки каждого сервиса в Windows.

После настройки Docker проверьте его работу:

docker version

Затем запустите тестовый контейнер:

docker run --rm hello-world

Посмотреть активные контейнеры:

docker ps

Все контейнеры, включая остановленные:

docker ps -a

Для нескольких связанных сервисов удобно использовать Compose.

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: development-password
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:alpine

volumes:
  postgres_data:

Такое окружение запускается одной командой:

docker compose up -d

И полностью останавливается:

docker compose down

Для локальной разработки это значительно удобнее, чем устанавливать PostgreSQL, Redis и другие инфраструктурные компоненты непосредственно в операционную систему.

kubectl для управления Kubernetes

Если компания использует Kubernetes, на рабочей станции понадобится kubectl. Это основной CLI-инструмент для взаимодействия с Kubernetes API.

Проверка доступных кластеров:

kubectl config get-contexts

Посмотреть текущий context:

kubectl config current-context

Проверить pod:

kubectl get pods -A

Посмотреть deployment:

kubectl get deployments -n production

Получить логи контейнера:

kubectl logs api-7b7d7b59d9-xk2lz -n production

При наличии нескольких кластеров особенно важно всегда проверять активный context перед выполнением команд:

kubectl config current-context

Это простая привычка, которая помогает избежать выполнения команды в production вместо staging.

Terraform для управления инфраструктурой

Terraform позволяет описывать инфраструктуру декларативно и хранить ее конфигурацию в Git. Для DevOps-инженера это один из способов уйти от ручного создания серверов, сетей и других ресурсов.

После установки:

terraform version

Основной рабочий цикл:

terraform init
terraform fmt
terraform validate
terraform plan

Команду terraform apply желательно выполнять только после внимательной проверки plan.

Например:

terraform plan -out=tfplan

После этого можно посмотреть сохраненный plan:

terraform show tfplan

Так гораздо проще увидеть потенциальное удаление или пересоздание ресурсов до фактического изменения инфраструктуры.

HTTP-клиент для диагностики API

DevOps регулярно приходится проверять доступность API, reverse proxy, балансировщиков и внутренних сервисов. Поэтому на рабочей станции обязательно нужен удобный способ выполнять HTTP-запросы.

Для быстрой диагностики достаточно curl:

curl https://example.com

Только заголовки:

curl -I https://example.com

Подробная информация о соединении:

curl -v https://example.com

Проверка API:

curl -X POST https://api.example.com/v1/test \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'

Для сложных REST-запросов можно дополнительно использовать графический API-клиент, но для диагностики серверов знание curl все равно остается крайне полезным.

Архиваторы и дополнительные системные утилиты

Несмотря на развитие облачных инструментов, DevOps регулярно сталкивается с архивами: резервными копиями, выгрузками логов, дистрибутивами, дампами и пакетами для передачи между серверами.

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

Если требуется подобрать дополнительное бесплатное программное обеспечение, можно использовать тематические каталоги программ, например soft-4-free.ru, а перед непосредственной установкой дополнительно сверять актуальную версию и разработчика программы с официальным сайтом.

Такой подход особенно важен для рабочей станции администратора: заражение компьютера, на котором находятся SSH-ключи и доступы к инфраструктуре, гораздо опаснее заражения обычного пользовательского ПК.

Утилиты для сетевой диагностики

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

Проверяем DNS

nslookup example.com

Если приложение обращается к серверу по доменному имени, а DNS не возвращает нужный адрес, дальнейшая диагностика HTTP-приложения практически бессмысленна до устранения проблемы разрешения имени.

Проверяем маршрут

tracert example.com

В Linux:

traceroute example.com

Проверяем TCP-порт

В PowerShell:

Test-NetConnection example.com -Port 443

Команда позволяет понять, удается ли установить TCP-соединение с определенным портом.

Например:

Test-NetConnection 192.168.1.100 -Port 22

Так можно отдельно проверить сетевую доступность SSH, не пытаясь сразу диагностировать сам SSH-клиент.

Менеджер паролей вместо passwords.txt

DevOps-инженер работает с большим количеством учетных записей: панели облачных провайдеров, Git-серверы, системы мониторинга, VPN, DNS, хостинги и внутренние сервисы.

Хранить такие данные в текстовом файле, заметках браузера или сообщениях самому себе - плохая практика.

Минимальная схема безопасности рабочей станции должна включать:

менеджер паролей;
уникальный пароль для каждой важной системы;
двухфакторную аутентификацию там, где она поддерживается;
SSH-ключи вместо паролей для серверов;
отдельное хранение recovery codes;
блокировку рабочего компьютера при отходе от него.

Особенно внимательно нужно относиться к токенам доступа Git, API-ключам облачных платформ и kubeconfig: компрометация одного такого файла иногда предоставляет гораздо больше возможностей, чем утечка обычного пользовательского пароля.

Не храните секреты прямо в Git

Даже приватный репозиторий не должен использоваться как хранилище паролей.

Например, такой Compose-файл уже создает проблему:

services:
  app:
    environment:
      DATABASE_PASSWORD: SuperSecretPassword123
      API_TOKEN: abcdef123456

Лучше передавать значения через environment или отдельную систему управления секретами:

services:
  app:
    environment:
      DATABASE_PASSWORD: ${DATABASE_PASSWORD}
      API_TOKEN: ${API_TOKEN}

А файл .env добавить в .gitignore:

.env
.env.*
*.key
*.pem

Перед первым commit полезно выполнить:

git status
git diff --cached

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

Как сделать установку рабочей станции воспроизводимой

Если DevOps-инженер меняет компьютер или переустанавливает Windows, ручной поиск и установка всех инструментов занимает много времени. Поэтому список необходимого ПО лучше хранить в отдельном репозитории.

Например:

workstation/
├── README.md
├── powershell/
│   └── setup.ps1
├── ssh/
│   └── config.example
├── git/
│   └── gitconfig.example
├── vscode/
│   └── extensions.txt
└── docs/
    └── installation.md

В README можно зафиксировать порядок настройки:

Установить терминал и Git.
Восстановить SSH-ключи из защищенного хранилища.
Настроить WSL.
Установить Docker.
Установить kubectl.
Установить Terraform.
Настроить редактор.
Добавить корпоративный VPN.
Проверить доступ к dev и staging.
Только после этого настраивать доступ к production.

В идеальном варианте часть установки можно автоматизировать PowerShell-скриптом. Тогда подготовка нового компьютера становится воспроизводимой процедурой, а не набором действий по памяти.

Разделяйте рабочие и личные инструменты

Еще одна полезная практика - не превращать DevOps-станцию в компьютер, на котором устанавливается любое найденное ПО.

Чем больше приложений работает с повышенными правами, добавляет фоновые службы или вмешивается в сетевые настройки, тем сложнее диагностировать проблемы.

Особенно осторожно следует устанавливать:

VPN-клиенты;
антивирусные и сетевые фильтры;
виртуальные сетевые адаптеры;
средства виртуализации;
прокси-клиенты;
драйверы;
программы, требующие постоянных прав администратора.

Например, одновременно установленные VPN, Docker, WSL и стороннее ПО для виртуализации могут создавать сложную сетевую конфигурацию. Поэтому после каждой серьезной установки полезно проверять, что SSH, DNS, Docker и корпоративная сеть продолжают работать корректно.

Минимальный набор DevOps-инструментов

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

Терминал и PowerShell - управление локальной системой и запуск CLI.
SSH - подключение к Linux-серверам.
Git - хранение инфраструктурного кода и конфигураций.
Редактор кода - YAML, JSON, Bash, Dockerfile, Terraform и документация.
WSL - полноценная Linux-среда.
Docker - контейнеры и локальные сервисы.
kubectl - управление Kubernetes.
Terraform - Infrastructure as Code.
curl - проверка HTTP и API.
Сетевые утилиты - DNS, маршруты и TCP-порты.
Архиватор - работа с логами, backup и дистрибутивами.
Менеджер паролей - безопасное хранение учетных данных.

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

Чек-лист после настройки рабочего компьютера

Перед тем как считать рабочую станцию готовой, проверьте базовые операции:

git --version
ssh -V
docker version
kubectl version --client
terraform version
curl --version

Затем выполните практические проверки:

Git может клонировать рабочий репозиторий.
SSH подключается к тестовому серверу.
Docker запускает тестовый container.
kubectl видит нужный Kubernetes context.
Terraform выполняет terraform validate на тестовом проекте.
DNS корректно разрешает внутренние и внешние домены.
VPN не ломает доступ к необходимым ресурсам.
SSH-ключи и токены не находятся в публичных каталогах.
Включена блокировка рабочей станции.
Настроено резервное копирование действительно важных конфигураций.

Итог

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

Начать достаточно с терминала, SSH, Git, редактора и WSL. Затем по мере необходимости добавить Docker, kubectl, Terraform и инструменты сетевой диагностики. При этом доступы, SSH-ключи и API-токены должны защищаться не менее тщательно, чем production-серверы.

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