Основной chart и единая конфигурация
Для начала создадим директории для основного чарта, сабчартов и типовых шаблонов.
Мы решили ,что для исключения путаницы имя директории основного чарта должно совпадать с его названием, именно под ним он будет помещен в репозиторий и будет использоваться в командах helm. У нас он называется exerica, здесь я буду использовать oursystem. Создадим для него следующую структуру:
Тут совсем мало файлов, поскольку в этом чарте определяются только:
-
зависимости в Chart.yaml
-
общие именованные шаблоны в _helpers.tpl
-
единый конфиг системы в configmap.yaml
-
сообщение, которое будет выведено после развертывания системы (NOTES.txt)
Параметры для всех приложений будут сгенерированы скриптом при сборке и записаны в values.yaml.
Определение единого конфига из configmap.yaml тоже совсем небольшое:
Шаблон toPropertiesYaml конвертирует произвольный (почти) yaml в массив пар «ключ-значение», где ключ формируется как последовательность ключей на пути от корня yaml-объекта:
Создадим файл versions.yaml, определяющий версии приложений, которые будем развертывать.
Все параметры конфигурации, которые будем выносить в единый конфиг системы, определим в одном файле templates/variables.yaml.
В дальнейшем в процессе сборки эти параметры дополняются «вычисляемыми» значениями, которые также нужны для конфигурирования приложений, например полный URL для ingress: ingressUrl. При сборке основного чарта эти параметры будут вставлены в секцию .Values.global.configuration и сформируют ConfigMap с единым конфигом системы. В частности, на них мы будем ссылаться в переменных окружения для контейнеров.
Таким образом можем передать параметры приложению webapi через переменные окружения, например такие:
-
DEPLOY_ENVIRONMENT — глобальное имя среды в которой функционирует приложение, берется из параметра common.envName
-
ProcessingRemoteConfiguration__RemoteAddress — адрес сервиса, с которым взаимодействует приложение webapi, берется из параметра processing.serviceUrl
Переменные среды считываются и передаются приложению при его запуске. Если при развертывании очередной версии системы какое-то приложение не поменялось, но поменялась конфигурация системы, то его под не будет перезапущен. Для решения этой проблемы удобно использовать контроллер Reloader, который отслеживает изменения объектов ConfigMap, Secret и производит плавающее обновление (rolling update) для подов, которые зависят от них. Мы включили его в состав системы, как внешнюю зависимость через helm chart. В нашем подходе это делается буквально в несколько строчек.
Создание класса репозитория учащихся
В папке DAL создайте файл класса с именем IStudentRepository.CS и замените существующий код следующим кодом:
Этот код объявляет типичный набор методов CRUD, включая два метода чтения — один, который возвращает все сущности, и один объект, который находит одну сущность по идентификатору.
В папке DAL создайте файл класса с именем StudentRepository.CS File. Замените существующий код следующим кодом, который реализует интерфейс:
Контекст базы данных определен в переменной класса, и конструктору требуется передать вызывающий объект в экземпляр контекста:
Можно создать новый контекст в репозитории, но если вы использовали несколько репозиториев в одном контроллере, каждый из них будет иметь отдельный контекст. Позже вы будете использовать несколько репозиториев в контроллере, и вы увидите, как класс единиц работы может гарантировать, что все репозитории будут использовать один и тот же контекст.
Репозиторий реализует интерфейс IDisposable и удаляет контекст базы данных, как показано ранее в контроллере, и его методы CRUD выполняют вызовы к контексту базы данных так же, как вы видели ранее.
Альтернативы
Helm — не единственное решение для управления сервисами. К нему много вопросов, наверное, поэтому так быстро появилась третья версия. Конечно, есть альтернативы.
Это могут быть как специализированные решения, например, Ksonnet или Metaparticle. Вы можете использовать свои классические средства управления инфраструктурой (Ansible, Terraform, Chef и пр.) для тех же целей, о которых я говорил.
Наконец, есть решение , популярность которого растет.
Оно более нативно для CNCF и Kubernetes, но порог вхождения намного выше, нужно больше программировать и меньше описывать манифесты.
Есть различные addons, такие, как Draft, Scaffold. Они сильно облегчают жизнь, например, разработчикам упрощают цикл отправки и запуска Helm для деплоя тестового окружения. Я бы назвал их расширителями возможностей.
Вот наглядный график о том, где что находится.
Operator Framework абсолютно нативен для Kubernetes и позволяет управлять им намного элегантнее и скрупулёзнее (но помним про уровень вхождения). Скорее, это подойдет для специализированного приложения и создания для него менеджмента, нежели массового комбайна по упаковке огромного количества приложений с помощью Helm.
Расширители просто чуть улучшают контроль, дополняют workflow или срезают углы CI/CD pipelines.
Перенос реестра для хранения артефактов OCI Helm
Если вы ранее настроили реестр контейнеров Azure в качестве репозитория чартов с помощью Helm 2 и команд , рекомендуем обновить клиент для Helm 3. Затем выполните следующие действия, чтобы сохранить диаграммы в виде артефактов OCI в реестре.
Важно!
- После завершения перехода с репозитория чартов Helm 2 (на основе файла index.yaml) на репозитории артефактов OCI используйте интерфейс командной строки Helm и команды для управления чартами. См. предыдущие разделы данной статьи.
- Репозитории артефактов OCI Helm не обнаруживаются с помощью таких команд Helm, как и . Дополнительные сведения о командах Helm, используемых для хранения чартов в качестве артефактов OCI, см. в документации по Helm.
Включение поддержки OCI
Убедитесь, что вы используете клиент Helm 3:
Включите поддержку OCI в клиенте Helm 3. В настоящее время эта поддержка носит экспериментальный характер и может быть изменена.
Выведите список чартов, хранящихся в реестре, с именем myregistry:
В выходных данных показаны чарты и их версии:
Архив диаграммы извлечения в локальной среде
Для каждой диаграммы в репозитории сделайте Архив диаграммы локально и запишите имя файла:
Создается локальный архив диаграммы, например, .
Передача диаграмм как артефактов OCI в реестр
Войдите в реестр:
Отправьте каждый архив диаграммы в реестр. Пример
После отправки чарта убедитесь, что он хранится в реестре:
После отправки всех чартов при необходимости удалите репозиторий чартов Helm 2 из реестра. Это сокращает объем хранилища в реестре:
Step 3 — Installing a Helm Chart
Helm software packages are called charts. Helm comes preconfigured with a curated chart repository called stable. You can browse the available charts in their GitHub repo. We are going to install the Kubernetes Dashboard as an example.
Use to install the package from the repo:
Notice the line, highlighted in the above example output. In this case we specified the name . This is the name of our release. A Helm release is a single deployment of one chart with a specific configuration. You can deploy multiple releases of the same chart with, each with its own configuration.
If you don’t specify your own release name using , Helm will create a random name for you.
We can ask Helm for a list of releases on this cluster:
We can now use to verify that a new service has been deployed on the cluster:
Notice that by default the service name corresponding to our release is a combination of the Helm release name and the chart name.
Now that we’ve deployed the application, let’s use Helm to change its configuration and update the deployment.
Бонус
Эта часть не относится напрямую к безопасности, но тоже будет полезна. Покажу некоторые интересные вещи, о которых немногие знают. Например, как искать чарты — официальные и неофициальные.
В репозитории сейчас порядка 300 чартов и два стрима: stable и incubator. Тот, кто контрибьютит, прекрасно знает, как тяжело попасть из incubator в stable, и как легко из stable вылететь. Однако, это не лучший инструмент, чтобы искать чарты для Prometheus и всего, что вам нравится, по одной простой причине — это не портал, где удобно искать пакеты.
Но есть сервис , с помощью которого находить чарты гораздо удобнее. Самое главное, там намного больше внешних репозиториев и доступно почти 800 чаротов. Плюс, вы можете подключить свой репозиторий, если по каким-то причинам не хотите отправлять свои чарты в stable.
Попробуйте hub.helm.sh и давайте вместе его развивать. Этот сервис под Helm-проектом, и вы можете контрибьютить даже в его UI, если вы фронтендер и хотите просто улучшить внешний вид.
Еще хочу обратить ваше внимание на Open Service Broker API integration. Звучит громоздко и непонятно, но решает задачи, с которым все сталкиваются
Поясню на простом примере.
Другие, например, мы в Chainstack, используют managed базы данных, например, MySQL или PostgreSQL, для серверов. Поэтому у нас БД находятся где-то в облаке.
Но возникает проблема: нужно связать наш сервис с базой данных, создать flavor базы данных, передать credential и как-то им управлять. Все это обычно делается вручную системным администратором или разработчиком. И нет никакой проблемы, когда приложений мало. Когда их много, нужен комбайн. Такой комбайн есть — это Service Broker. Он позволяет использовать специальный плагин к кластеру публичного облака и заказывать ресурсы у провайдера через Broker, как будто это API. Для этого можно использовать нативные средства Kubernetes.
Это очень просто. Можно запросить, например, Managed MySQL в Azure с базовым tier (это можно настроить). С использованием API Azure база будет создана и подготовлена к использованию. Вам не понадобиться в это вмешиваться, за это отвечает плагин. Например, OSBA (плагин Azure) вернет credential в сервис, передаст это Helm. Вы сможете использовать WordPress с облачным MySQL, вообще не заниматься managed базами данных и не париться о statefull-сервисах внутри.
Можно написать свой плагин и использовать всю эту историю on-premise. Тогда у вас просто будет свой плагин к корпоративному Cloud-провайдеру. Я советую попробовать такой подход, особенно если у вас большой масштаб и вы хотите быстро развернуть dev, staging или всю инфраструктуру под фичу. Это упростит жизнь вашим operations или DevOps.
Еще одна находка, которую я уже упоминал — это плагин helm-gcs, который позволяет использовать Google-buckets (объектное хранилище), чтобы хранить Helm-чарты.
- установить плагин;
- инициировать его;
- задать путь к bucket, который находится в gcp;
- опубликовать чарты стандартным способом.
Прелесть в том, что будет использоваться нативный способ gcp для авторизации. Вы можете использовать сервисный аккаунт, аккаунт разработчика — все, что угодно. Это очень удобно и ничего не стоит в эксплуатации. Если вы, как и я, пропагандируете opsless-философию, то это будет очень удобно, особенно для небольших команд.
Основные операции
Акей, helm готов, нужно с ним чего-нибудь поделать. Например, найти какой-нибудь стандартный чарт и установить его, проверить статус и удалить к такой-то бабушке.
Поиск
сразу выплёвывает все известные чарты, но на самом деле я уже примерно представляю, что именно мне нужно. Так что, сузив поиск при помощи , нужный кандидат оказывается вверху списка, и можно сразу переходить к его установке:
Search package
Shell
helm search prometheus
#NAME CHART VERSION APP VERSION DESCRIPTION
#stable/prometheus 6.8.0 2.3.1 Prometheus is a monitoring system and time seri…
#stable/prometheus-blackbox-exporter 0.1.0 0.12.0 Prometheus Blackbox Exporter
#…
|
1 4 |
helm search prometheus #NAME CHART VERSION APP VERSION DESCRIPTION #stable/prometheus-blackbox-exporter 0.1.0 0.12.0 Prometheus Blackbox Exporter |
Установка
— вот, что мы будем устанавливать, и чего уж тут медлить:
helm install
Shell
helm install stable/prometheus
#NAME: willing-grizzly
#…
#RESOURCES:
#==> v1/PersistentVolumeClaim
#…
#==> v1/Pod(related)
#…
#==> v1beta1/Deployment
#…
#NOTES:
#…
#The Prometheus alertmanager can be accessed via port 80 on the following DNS name from within your cluster:
#willing-grizzly-prometheus-alertmanager.default.svc.cluster.local
#
#Get the Alertmanager URL by running these commands in the same shell:
# export POD_NAME=$(kubectl get pods —namespace default -l «app=prometheus,component=alertmanager» -o jsonpath=»{.items.metadata.name}»)
# kubectl —namespace default port-forward $POD_NAME 9093
#…
|
1 12 19 |
helm install stable/prometheus #NAME: willing-grizzly #… #… |
Вот что, кстати, удобно. В конце логов установки идёт секция , в которой сразу есть насколько полезных советов. Например, в строках 17-18 есть команды для проброса порта 9093 наружу, так что мы сможем зайти в админку одного из установленных прометеевских сервисов — .
Посмотреть Notes можно и позже с командой .
Смотрим установленные чарты (релизы)
Посмотреть, что уже установлено, тоже довольно просто:
View installed charts
Shell
helm list
#NAME REVISION UPDATED STATUS CHART NAMESPACE
#willing-grizzly 1 Mon Jul 9 23:08:26 2018 DEPLOYED prometheus-6.8.0 default
|
1 |
helm list #NAME REVISION UPDATED STATUS CHART NAMESPACE |
Кстати, запомните число во втором столбце () — оно очень пригодится, когда мы будем делать апгрэйды и их откаты.
Удаляем релиз
Это вообще просто — и всё. Правда, удалять его прямо сейчас я не хочу, поэтому в конце команды добавлю флаг , чтобы всё прошло понарошку:
Remove package
Shell
helm delete willing-grizzly —dry-run
# release «willing-grizzly» deleted
|
1 |
helm delete willing-grizzly—dry-run # release «willing-grizzly» deleted |
Helm
Это менеджер пакетов (чартов) для Kubernetes. Самый понятный и универсальный способ приносить приложения в Kubernetes-кластер.
Почему Helm? В первую очередь потому, что он поддерживается CNCF. Cloud Native — большая организация, является материнской компанией для проектов Kubernetes, etcd, Fluentd и других.
Другой важный факт, Helm — очень популярный проект. Когда в январе 2019 я только задумал рассказать о том, как сделать Helm безопасным, у проекта была тысяча звездочек на GitHub. К маю их стало 12 тысяч.
Многие интересуются Helm, поэтому, даже если вы до сих пор его не используете, вам пригодятся знания относительно его безопасности
Безопасность — это важно
Основную команду Helm поддерживает Microsoft Azure, и поэтому это довольно стабильный проект в отличие от многих других. Выход Helm 3 Alpha 2 в середине июля свидетельствует о том, что над проектом работает достаточно много людей, и у них есть желание и силы развивать и улучшать Helm.
- Пакетирование приложения. Даже приложение типа «Hello, World» на WordPress уже представляет из себя несколько сервисов, и их хочется упаковать вместе.
- Управление сложностью, которая возникает с менеджментом этих приложений.
- Жизненный цикл, который не заканчивается после установки или деплоя приложения. Оно продолжает жить, его нужно обновлять, и помогает в этом Helm и старается принести для этого правильные меры и политики.
Пакетирование устроено понятным образом: есть метаданные в полном соответствии с работой обычного пакетного менеджера для Linux, Windows или MacOS. То есть репозиторий, зависимости от различных пакетов, метаинформация для приложений, настройки, особенности конфигурирования, индексирование информации и т.п Все это Helm позволяет получить и использовать для приложений.
Управление сложностью. Если у вас много однотипных приложений, то нужна параметризация. Из этого вытекают шаблоны, но чтобы не придумывать свой способ создания шаблонов, можно использовать то, что Helm предлагает из коробки.
Менеджмент жизненного цикла приложения — на мой взгляд, это самый интересный и нерешенный вопрос. Это то, почему в свое время я пришел к Helm. Нам нужно было следить за жизненным циклом приложения, мы хотели перенести свой CI/CD и циклы приложений в эту парадигму.
Helm позволяет:
- управлять деплоями, вводит понятие кофигурации и ревизии;
- успешно проводить rollback;
- использовать хуки на разные события;
- добавлять дополнительные проверки приложений и реагировать на их результаты.
Кроме того у Helm есть «батарейки» — огромное количество вкусных вещей, которые можно включить в виде плагинов, упростив свою жизнь. Плагины можно писать самостоятельно, они достаточно изолированные и не требуют стройной архитектуры. Если вы хотите что-то реализовать, я рекомендую сделать это в виде плагина, а потом возможно включить в upstream.
Helm зиждется на трех основных концепциях:
- Chart Repo — описание и массив параметризации, возможной для вашего манифеста.
- Config —то есть значения, которые будут применены (текст, численные значения и т.п.).
- Release собирает в себя два верхних компонента, и вместе они превращаются в Release. Релизы можно версионировать, тем самым добиваясь организации жизненного цикла: маленького на момент установки и крупного на момент upgrade, downgrade или rollback.
Чарты
Пакеты Helm называются чартами, они состоят из нескольких конфигурационных файлов YAML и некоторых шаблонов, которые отображаются в файлах манифеста Kubernetes. Вот основная структура каталогов чарта:
Эти каталоги и файлы имеют следующие функции:
- charts/: в этот каталог могут быть помещены вручную управляемые зависимости чартов, хотя для динамической привязки зависимостей обычно лучше использовать requirements.yaml.
- templates/: этот каталог содержит файлы шаблонов, которые объединены с значениями конфигурации (из values.yaml и командной строки) и отображаются в манифестах Kubernetes. Шаблоны используют формат языка программирования Go.
- Chart.yaml: это файл YAML с метаданными о чартах (он содержит имена чартов, версии, информацию о поддерживающем устройстве, веб-сайт и ключевые слова для поиска).
- LICENSE: лицензия чарта.
- README.md: файл readme с информацией для пользователей чарта.
- requirements.yaml: файл YAML, в котором перечислены зависимости чарта.
- values.yaml: файл YAML с конфигурацией по умолчанию для чарта.
Команда helm может установить чарт из локального каталога или из упакованной версии .tar.gz этой структуры каталогов. Эти упакованные чарты также могут автоматически загружаться и устанавливаться из репозиториев чартов.
Ниже мы рассмотрим эти репозитории подробнее.
Репозитории чартов
Репозиторий чартов Helm – это простой HTTP-сайт, который обслуживает файлы index.yaml и .tar.gz. Команда helm имеет подкоманды, которые помогают упаковать чарты и создать требуемый файл index.yaml. Эти файлы могут обслуживаться любым веб-сервером, сервисом хранения объектов или хостом, таким как GitHub Pages.
Helm по умолчанию поставляется с репозиторием чартов под названием stable. Этот репозиторий указывает на корзину Google Storage на странице https://kubernetes-charts.storage.googleapis.com. Источник репозитория stable можно найти в репозитории helm/charts на GitHub.
Альтернативные репозитории можно добавить с помощью команды helm repo add. Вот некоторые популярные альтернативные репозитории:
- Официальный репозиторий incubator, в котором хранятся чарты, пока что не готовые для stable. Инструкции для этого репо можно найти на этой странице.
- Bitnami Helm Charts, который предоставляет чарты, которых нет в официальном репо stable.
Независимо от того, устанавливаете ли вы локальный чарт или чарт из репо, вам необходимо настроить его в среде. Ниже мы рассмотрим конфигурационные файлы чартов.
Настройка чартов
Обычно чарт поставляется с конфигурацией по умолчанию, которая находится в файле values.yaml. Некоторые приложения могут быть полностью развернуты со значениями по умолчанию, но, как правило, некоторые конфигурации необходимо переопределять в соответствии с потребностями конкретной среды.
Значения, отображаемые в конфигурации, определяются автором чарта. Некоторые из них используются для настройки примитивов Kubernetes, а некоторые могут быть переданы в базовый контейнер для настройки самого приложения.
Вот фрагмент возможных значений:
Это параметры для настройки ресурса сервиса Kubernetes. Вы можете использовать helm inspect values chart-name, чтобы сбросить все доступные значения конфигурации чарта.
Эти значения можно переопределить, написав свой собственный файл YAML и используя его при запуске helm install или путем индивидуально в командной строке с флагом –set. Вам нужно указать только те значения, которые вы хотите изменить.
Чарт Helm, развернутый с определенной конфигурацией, называется релизом.
Передача values в сабчарты
Чтобы передать данные из родительского чарта в сабчарт необходимо определить следующие values в родительском чарте:
В сабчарте эти данные можно использовать с помощью обращения к соответствующим параметрам без указания ключа :
Данные, определенные глобально в ключе верхнего уровня , также доступны в сабчартах:
Обращаться к ним необходимо как обычно:
В сабчарте будут доступны только данные ключей и .
ЗАМЕЧАНИЕ Файлы сабчартов не будут использоваться во время процесса деплоя, несмотря на то, что данные секретов из главного чарта и данные переданные через параметр будут доступны через массив как обычно.
Использование Helm в кластере Kubernetes
Первым шагом в использовании helm является установка диаграмм в вашей локальной системе. Центр артефактов содержит сотни общедоступных репозиториев диаграмм, которые вы можете установить локально в своей системе. Artifacts Hub — это проект с открытым исходным кодом, который содержит тысячи пакетов Kubernetes.
Чтобы установить диаграмму из хаба «Артефакты», найдите ее имя в текстовом поле. В этом примере мы ищем диаграмму MariaDB.
Когда вы нажмете ENTER, вам будет предоставлен список диаграмм на выбор.
Выберите желаемую диаграмму, и вам будет предоставлен список инструкций по ее установке.
Тесты
Helm поддерживает создание высокоуровневых тестов. Они запускаются вручную командой и могут использоваться для проверки взаимодействия сервисов или же доступности внешних систем (№ баз данных). Тестовый файл представляет из себя шаблон с описанием Kubernetes-объекта, который должен выполнять некое разовое действие, например http-запрос. Если команда завершается штатно, то тест считается пройденным.
Наш тест будет проверять доступность нашей системы, делая запрос к сервису шлюза. Тест будет состоять из Kubernetes-объекта Job — удобной абстракции над подом, как раз предназначенной для выполнения разовых действий. В случае неудачи, Job будет перезапускать контейнер и повторять запрос максимум 3 раза (опция backoffLimit)
Обращу внимание на аннотации helm.sh/hook и helm.sh/hook-delete-policy. Они сигнализируют Helm, что это описание тестового объекта, и что он должен быть уничтожен после выполнения теста
interaction-test.yaml:
Включение сабчарта для проекта
-
Определим зависимость для нашего werf чарта с помощью файла :
ЗАМЕЧАНИЕ. Необязательно определять полный с именем и версией как для стандартного helm-чарта. werf генерирует имя чарта и версию на основе директивы из файла . См. больше информации в статье про чарты.
-
Далее требуется сгенерировать с помощью команды .
Данная команда создаст и скачает все зависимости в директорию .
-
Файл следует коммитнуть в git репозиторий, а директорию можно добавить в .
Позднее, во время процесса деплоя (командой или ) или рендеринга шаблонов (командой ), werf автоматически скачает все зависимости указанные в lock-файле .
ЗАМЕЧАНИЕ. Файл должен быть коммитнут в git репозиторий, больше информации .
Кто такой helm
Helm — это установщик пакетов для Kubernetes. Примерно такой же, как для nodejs или для цивилизованного мира. Говоря helm, мы на самом деле подразумеваем целых два приложения: клиентский helm и его серверного, живущего в Kubernetes компаньона — tiller. На пару они могут искать, устанавливать, апгрэйдить и удалять пакеты-приложения, в хельмовской терминологии называемые чартами (chart).
‘Chart’ — не единственный странный выбор слов. Например, чарт, установленный в Kubernetes, уже называется релиз (release). Если установить чарт-пакет два раза, то получится два релиза. И т.п.
Но зато репозиторий для чартов так и называется — репозиторий. Ну и конечно, есть как «дефолтный» репозиторий, так и собственные, локальные.
Разобравшись с терминологией, теперь можно посмотреть на хельм поближе.
Создание пакетов
Если вы не можете найти существующий пакет для своего программного обеспечения, вы можете создать собственный пакет. Helm может вывести схему каталога пакетов с помощью команды . При этом будет создана папка с файлами и каталогами, которые мы обсуждали в разделе выше.
Теперь вы можете заполнить метаданные пакетов в файле и поместить файлы манифеста Kubernetes в каталог . В этом случае вам нужно извлечь переменные конфигурации из манифестов в файл , а затем включить их в шаблоны манифеста с помощью системы шаблонов.
Команда имеет множество субкоманд для тестирования, упаковки и обслуживания пакетов. Дополнительную информацию можно найти в официальной документации Helm по разработке пакетов.
Пакеты и пакетные менеджеры для k8s +22
- 13.12.18 10:34
•
osminog
•
#431540
•
Хабрахабр
•
•
1800
Системное администрирование, IT-инфраструктура, DevOps, Блог компании Конференции Олега Бунина (Онтико)
Все мы пользуемся каким-либо видом пакетных менеджеров, включая уборщицу тетю Галю, у которой в кармане прямо сейчас обновляется айфон. Но общего соглашения о функциях пакетных менеджеров нет, и стандартные для ОС rpm и dpkg, и системы сборки называют пакетными менеджерами. Предлагаем поразмышлять на тему их функций — что это такое и для чего они нужны в современном мире. А потом будем копать в сторону Kubernetes и внимательно рассмотрим Helm с точки зрения этих функций.
Разберемся, почему на этой схеме только функция шаблонизатора выделена зеленым, и в чем проблемы со сборкой и пакетированием, автоматизацией окружения и прочим. Но не беспокойтесь, статья не закончится на том, что все плохо. Сообщество не могло с этим смириться и предлагает альтернативные инструменты и решения — разберемся и с ними.
Помог нам в этом Иван Глушков (gli) своим докладом на РИТ++, видео и текстовая версия этого подробного и обстоятельного выступления ниже.
О спикере:DevZenздесьздесь
