Как проверить текущую ОС хоста в Docker Compose?
Для контейнеров Linux и Airflow мы должны предоставить контейнеру идентификатор пользователя хоста:
«В Linux для быстрого запуска необходимо знать идентификатор пользователя вашего хоста и установить для идентификатора группы значение 0. В противном случае файлы, созданные в dags, журналах и плагинах, будут созданы с правами root-пользователя. Вы должны обязательно настроить их для создания докера: mkdir -p ./dags ./logs ./plugins echo -e "AIRFLOW_UID=$(id -u)" > .env"
https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html*
Но в нашей команде есть как разработчики под Windows, так и под Linux. Как объединить для них один файл docker-compose, чтобы сделать конфигурацию единообразной и работающей для них обоих?
1 ответ
Вам не нужно беспокоиться об этой разнице.
В Linux упомянутая вами команда запишет UID текущего пользователя в конфигурацию среды воздушного потока, чтобы приложение запускалось под этим пользователем. Благодаря этому все файлы конфигурации и папки, созданные приложением, принадлежат вошедшему в систему пользователю, поскольку они монтируются из текущего каталога пользователя в контейнер Docker.
Примечание. Все, что я написал ниже, предполагает, что в Windows вы будете использовать контейнеры Linux. Если вы используете собственные контейнеры Windows, вам необходимо проверить, есть ли для этого специальные инструкции по воздушному потоку.
В Windows наиболее распространенным способом запуска Docker-контейнеров является запуск их на «виртуальной машине» WSL, где часть ресурсов вашего компьютера используется для загрузки дистрибутива Linux внутри Windows.
Если ваши разработчики уже используют WSL напрямую и внутри экземпляра WSL установлен докер, применяются те же самые действия. Что касается воздушного потока, он работает на хосте Linux, и его не волнует тот факт, что все это находится в еще одном приложении Windows. Вероятно, это так, если вы/ваши разработчики привыкли к рабочему процессу разработки, ориентированному на Linux, даже в Windows.
С другой стороны, если вы в основном ориентированы на Windows, ваши разработчики, скорее всего, используют Docker Desktop или подобное решение. Большинство, если не все, из них запускают виртуальную машину Linux (вероятно, используя сам WSL) и запускают Docker в предоставляемой ею среде Linux. В этом случаеdags
/logs
/plugins
каталоги будут находиться в папке Windows, которая затем сопоставляется с дистрибутивом WSL, где он монтируется внутри контейнера. В этом случае, когда WSL преобразует файлы на стороне Windows для доступа на стороне Linux, он сопоставляет «любого пользователя, вошедшего в систему в Windows», и проблема, которая вас беспокоит, исчезает.