Как системному инженеру перейти с Windows на macOS, перенести все проекты и не умереть

Вадим Исаканов

---

Senior Systems Engineer в EPAM Systems. Разрабатывает инфраструктурные решения и системы сборки/деплоя софта, внедряет DevOps-практики. Проводит мероприятия в рамках сообщества Sysadminka. Любит горы, сноуборд, путешествия, фотографировать людей и организовывать IT-мероприятия.

---

Ссылки

Я системный инженер, занимаюсь инфраструктурой. Рабочий день у меня начинается часов в одиннадцать утра, так как я нахожусь на Урале, а работаю уже больше четырёх лет удалённо на Москву. Для работы мне достаточно ноутбука и интернета. Основные инструменты — мессенджер (сейчас это MS Teams), браузер, терминал, IDE типа IntelliJ или редактор вроде Sublime Text.

Консоль позволяет использовать много разных утилит, управлять виртуалками, контейнерами (например, Docker) и инфраструктурой. Кстати, многие утилиты я предпочитаю использовать через виртуальные машины, а ими, в свою очередь, управляю локально, на ноутбуке, через Vagrant. Vagrant — это ПО от компании HashiCorp, которое позволяет менеджерить виртуальные машины и контейнеры.

Сейчас я работаю на макбуке с macOS на борту — перешёл на него около двух с половиной лет назад. А до этого примерно в равной степени использовал Windows и Linux. Такой кочевой образ жизни и использование разных ноутбуков, настольных компьютеров или операционок довольно часты для системных инженеров.

Перейти с Win на macOS помогла полезная яблочная утилита Migration Assistant, но сначала я расскажу про перенос данных, софта и настроек с компьютера с Windows на компьютер с macOS вручную. Прежде чем использовать софт, помогающий мигрировать, полезно разобраться в механике миграции.

Есть несколько больших сущностей, которые вам нужно перенести, — софт, ключи и пароли, данные (фото, музыка, документы и так далее, — то, что в экосистеме Windows принято хранить на диске D), настройки ОС, — а если вы разработчик или системный инженер, то ещё и код ваших проектов.

Программы

Программы придётся переустанавливать вручную. У меня их было не так много: редактор Sublime Text, мессенджер MS Teams (сейчас), Telegram и Slack (раньше), браузер, консольный терминал, редактор кода или IDE и Lens — софт для работы с Kubernetes-кластерами.

Правда, Lens я начал пользоваться, уже когда перешёл на macOS. Но она отлично работает в любой ОС: просто устанавливаешь её на новом рабочем месте, авторизуешься и копируешь настройки.

Это были графические приложения, а ещё у меня есть консольные утилиты:

• Git;
• разная служебная мелочь типа mtr, traceroute, SSH, telnet, доступная в любой ОС;
• утилиты для управления инфраструктурой: Ansible, Terraform, Terragrunt, kubectl;
• консольная утилита для управления кластерами Openshift, AWC CLI;
• Vagrant.

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

Сейчас в Windows есть полноценный PowerShell, он упрощает работу с консолью, но это всё равно далеко не *nix-терминал с *nix-утилитами. Большинство серверов и серверных систем в мире работают на UNIX-подобных ОС (например, Linux). Я вообще работаю только с серверами на Linux, и macOS, будучи UNIX-подобной операционкой, к ним гораздо ближе.

Пароли

Пароли я переносил с помощью менеджера паролей — он сильно упрощает жизнь. Раньше я использовал диспетчер паролей Google Chrome, а теперь пользуюсь Last Pass. Его данные не нужно переносить — достаточно просто установить приложение в новой системе и залогиниться в нём. У обоих решений есть версии под все популярные операционки, в том числе под Windows и macOS.

Ключи

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

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

Виртуальные машины

Виртуалки очень упрощают процесс переезда с одной ОС на другую. Если мы перемещаем виртуальную машину со старого ноута на Windows к себе на Mac, то мы автоматически перемещаем все настройки и данные внутри неё. Единственное, что нужно, — установить софт или утилиты для управления виртуальными машинами и скопировать данные самих виртуалок.

У Mac есть прикольная фича — Migration Assistant. Он умеет переносить различные файлы с вашего старого ноута, в том числе виртуальные машины, — и даже с Windows.

Репозитории

Как правило, репозитории хранятся в облачном хранилище, а на компьютере — только локальная копия. Когда вы переезжаете на новый ноут, нужно просто клонировать свои репозитории через git clone. Git отлично работает в любой операционной системе.

А если даже это вам будет делать лень, то можно просто скопировать локальные директории со своими репами — вручную или через Migration Assistant. И не забудьте сгенерировать новые ключи (это правильный путь), а потом добавить их в свою систему управления репозиториями (GitHub, GitLab, etc).

Большая часть кода, с которым работает современный инфраструктурный инженер, — это описание инфраструктуры и различные пайплайны. Мы уже практически не ходим на серверы по SSH и не настраиваем их вручную — вместо этого мы просто описываем работу инфраструктуры в коде. Поэтому для того, чтобы скопировать необходимые для работы данные, нам достаточно скопировать репозитории с тем самым «конфигурационным» кодом.

Infrastructure as Code, контейнеры, Kubernetes

Подход Infrastructure as Code (IaC) касается не только рабочей инфраструктуры, но и тестирования. Его грамотная организация позволяет быстро разворачивать копию рабочей инфраструктуры для тестов. С появлением контейнеров типа Docker и Kubernetes, инструмента для их оркестрации, всё это стало гораздо проще.

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

А если нужно тестировать что-то локально, то, опять же, правильно написанная IaC с помощью тех же контейнеров Kubernetes позволит запускать тесты в любой ОС. Правда в этом случае придётся переносить между старым и новым компьютером весь код и софт для запуска инфраструктуры.