Dev Environment as a Code (DEaaC) с DevContainers, Dotfiles и GitHub Codespaces

Оглавление

• Мотивация
• Анатомия среды разработки
  • Dotfiles
  • DevContainers
• Лучший способ делать дотфайлы — Dotbot
• Объединение всего вместе
• Выберите хост. Кодовые пространства GitHub
• Пример
• Резюме
• Ссылка

Мотивация

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

Есть много преимуществ создания воспроизводимой среды разработки. Для меня основных два:

1. Вы открываете проект, и он просто работает. Представьте себе какой-нибудь проект с открытым исходным кодом, который вас заинтересовал, но вы не знаете, как его запустить. С DEaaC проблемы с установкой исчезают.
2. Вы можете поделиться им со своими коллегами. Кодифицированная установка разработчика — это форма знаний, которую можно оценивать и развивать. Это открывает массу новых возможностей.

Анатомия среды разработчика

В принципе, аспекты среды разработчика можно разделить на следующие категории:

Это может показаться много, но, к счастью, у нас есть хорошие инструменты для автоматизации процесса создания лесов. А именно dotfiles и devcontainers.

Dotfiles

Дотфайлы сосредоточены на персональных аспектах конфигурации и обычно поддерживаются одним человеком. Дотфайлы настраиваются для создания уникального опыта разработчика. Ранее я писал об этом здесь: Среда разработки на основе Windows Terminal + WSL + ZSH + dotfiles

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

Вот пример того, как я это делаю: https://github.com/NikiforovAll/dotfiles. Как вы можете видеть, есть три различные установки для windows, wsl и dev-containers.

В результате мы можем создать выбранную dev-среду с нуля. Все, что вам нужно сделать, это запустить однострочную команду:

bash -c "$(wget -qO - https://raw.github.com/nikiforovall/dotfiles/master/src/wsl/os/install.sh)"

Подобный подход действительно работает. Но он раздражает и непрактичен. Мы можем сделать это лучше. Я покажу вам это в ближайшее время.

DevContainers

Из официальной документации:

Расширение Visual Studio Code Remote — Containers позволяет вам использовать контейнер Docker в качестве полнофункциональной среды разработки. Оно позволяет вам открыть любую папку или репозиторий внутри контейнера и воспользоваться всеми возможностями Visual Studio Code. Файл devcontainer.json в вашем проекте указывает VS Code, как получить доступ (или создать) контейнер разработки с четко определенным стеком инструментов и среды выполнения. Этот контейнер можно использовать для запуска приложения или для разделения инструментов, библиотек и времен выполнения, необходимых для работы с кодовой базой.

Файл devcontainer.json в вашем проекте указывает Visual Studio Code (и другим службам и инструментам, поддерживающим этот формат), как получить доступ (или создать) контейнер разработки с определённым стеком инструментов и времени выполнения. В настоящее время этот формат поддерживается расширением Remote — Containers и GitHub Codespaces.

DevContainers предназначены для многократного использования и расширения. Судя по моему опыту, они улучшились в этом отношении. Вот как вы можете добавить зависимости через .devconatiner.json.

{
    "name": "Azure Dev CLI",
    "build": {
        "dockerfile": "Dockerfile", // base docker image
        "args": {
            "VARIANT": "bullseye" // parametrization
        }
    },
    "features": {
        "github-cli": "2",
        "azure-cli": "2.38",
        "dotnet": "6.0",
        "docker-from-docker": "20.10",
    },
    "extensions": [
        "ms-azuretools.azure-dev",
        "ms-azuretools.vscode-bicep",
        "ms-azuretools.vscode-docker",
        "ms-azuretools.vscode-azurefunctions",
        "ms-dotnettools.csharp",
        "ms-dotnettools.vscode-dotnet-runtime",
    ],
}

💡DevContainers определяют конфигурации, специфичные для проекта, а dotfiles определяют конфигурации, специфичные для пользователя.

Лучший способ делать dotfiles — Dotbot

💭 Моя первоначальная версия dotfiles была предназначена для wsl & ранняя версия devcontainers. С тех пор я усвоил несколько уроков. В основном, это хорошая идея сохранить dotfiles простым и полагаться на самое необходимое. Вам не нужно привносить тонны зависимостей и запутанных конфигурационных файлов. Чем проще — тем легче поддерживать и синхронизировать.

Итак, я создал еще одно репо dotfiles: https://github.com/NikiforovAll/dotbot. Он основан на https://github.com/anishathalye/dotbot. Dotbot — это инструмент, который загружает ваши дотфайлы. Он прост в использовании. Я предлагаю вам попробовать его самостоятельно.

Как уже говорилось, поскольку я намеренно решил обойтись без тяжелых зависимостей, установка dotfiles занимает пару секунд. Именно так, как я хочу. Мое общее предложение — перенести тяжелую работу по установке зависимостей в DevContainers.

Один-единственный вариант: cd ~ && git clone https://github.com/NikiforovAll/dotbot && cd ./dotbot && cd ./install.

Вот как выглядит структура проекта:

# oleksii_nikiforov in ~/dotbot
> tree -L 2
.
├── bash
│   ├── plugins.bash
│   └── prompt.bash
├── bash_profile
├── bashrc
├── gitconfig
├── gitignore_global
├── install
├── install.conf.yaml
├── pre-install.sh
├── shell
│   ├── aliases.sh
│   ├── bootstrap.sh
│   ├── dircolors.extra
│   ├── external.sh
│   ├── functions.sh
│   └── plugins
├── zsh
│   ├── plugins
│   ├── plugins_after.zsh
│   ├── plugins_before.zsh
│   ├── prompt.zsh
│   └── settings.zsh
└── zshrc

Объединяем все вместе

Результирующая среда разработки собирается из различных источников. Грубо говоря, хост (машина разработчика/кодовое пространство) состоит из следующих частей:

Выберите хост. Кодовые пространства GitHub

Предлагаемый подход абстрагируется от хоста. Это не обязательно должна быть ваша машина. Именно для этого предназначен продукт «GitHub Codespaces».

Кодовое пространство — это среда разработки, размещенная в облаке. Вы можете настроить свой проект для GitHub Codespaces, зафиксировав файлы конфигурации в своем репозитории (часто известный как Configuration-as-Code), что создает повторяемую конфигурацию кодового пространства для всех пользователей вашего проекта.

GitHub Codespaces работают на различных вариантах вычислительных систем на базе виртуальных машин, размещенных на сайте GitHub.com, которые можно конфигурировать от 2 до 32 ядерных машин. Вы можете подключиться к своим кодовым пространствам через браузер или локально с помощью Visual Studio Code.

Пример

Мы рассмотрим шаблон Azure Developer CLI (azd) — todo-csharp-cosmos-sql. Вот репозиторий, который будет использоваться в качестве примера: https://github.com/NikiforovAll/todo-csharp-cosmos-sql.

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

Это приложение использует следующие ресурсы Azure:

• Azure App Services для размещения веб-фронтенда и API-бэкенда
• Azure Cosmos DB SQL API для хранения данных
• Azure Monitor для мониторинга и ведения журналов
• Azure Key Vault для защиты секретов

Демонстрация сочетает в себе методы из Infrastructure as a Code (IaaC) и Dev Environment as a Code (DEaaC). От нуля до развертывания ресурсов Azure при первом запуске проходит всего 15 ошеломляющих минут.

1️⃣ Настройте dotfiles в «Settings>Codespaces»:

2️⃣ Перейдите в репозиторий и запустите кодовое пространство:

3️⃣ Откройте кодовое пространство в браузере или локально (для демонстрации я буду использовать браузерный вариант)

4️⃣ Войдите в Azure через CLI или расширение VSCode:

az login --use-device-code

5️⃣ Запустите azd up

6️⃣ Установите точку останова

7️⃣ Проверьте проброшенные порты. Обратите внимание, что codespaces выделяет некоторый случайный URL

8️⃣ Сгенерируйте нагрузку

9️⃣ Проверьте журналы, запустив azd monitor --logs

🔟 Снести среду разработки в Azure azd down.

В результате мы получили:

• Развернули всю установку разработчика за 15 минут
• Терминал/шелл настроен
• Git настроен
• Все инструменты и зависимости проекта установлены: dotnet, az и т.д.
• VSCode содержит пользовательские расширения, а также предложенные devcontainer
• Один счастливый разработчик 😉

Резюме

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

Ссылка

• https://dotfiles.github.io
• https://nikiforovall.github.io/productivity/2019/11/30/nikiforovall-setup.html
• https://code.visualstudio.com/docs/remote/create-dev-container
• https://docs.github.com/en/codespaces/overview
• https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers
• https://docs.github.com/en/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account