Это может быть полезно при переходе к использованию контейнеров или при необходимости настроить что-то другое в Kubernetes.
В редких случаях вы можете контролировать запускаемое приложение, но, возможно, вы используете технологический стек, который не позволяет легко иметь различные файлы конфигурации для разных сред выполнения, но вы можете запустить пользовательский код при запуске приложения, где вы можете выполнить пользовательскую логику, чтобы определить, запущено ли приложение в контейнере, и затем сделать что-то другое.
Аналогично для определения Docker или Kubernetes (в отличие от Docker иs не-Docker) мы можем использовать пользовательскую логику в скрипте точки входа в Docker, о котором мы расскажем далее
Docker или не-Docker
Docker помещает файл /.dockerenv в корень файловой системы. Хотя еще в 2016 году Docker упоминал, что не рекомендуется полагаться на это.
Если вы проверяете, запущено ли ваше приложение в контейнере, но не с помощью Docker, например Podman, вам также нужно будет сделать что-то другое, поскольку этого файла не будет.
На мой взгляд, наиболее простым и надежным способом является использование переменных окружения.
Вы можете установить значение DOCKER_RUNTIME=1 только при запуске контейнера, и теперь ваше приложение сможет проверять, установлена ли эта переменная окружения при загрузке.
Вы можете назвать ее как угодно.
Предполагается, что когда ваше приложение не запускается в Docker, вы не увидите эту переменную окружения.
Можно создать условие if, проверяющее наличие этой переменной окружения в любой программе.
Kubernetes или Docker
Допустим, ваше приложение работает на сервере с помощью Docker Compose, но у вас также есть приложение, работающее в Kubernetes.
Возможно, вы находитесь в процессе переключения, и веб-серверу вашего приложения требуются несколько иные локальные диапазоны IP-адресов или что-то еще, что немного отличается.
В идеале на уровне приложения или веб-сервера не должно быть никаких различий, но иногда в реальном мире вам нужно просто решение проблемы, а не слова о необходимости рефакторинга приложения или изменения технологического стека.
По умолчанию Kubernetes устанавливает переменную окружения KUBERNETES_SERVICE_HOST, поэтому мы можем использовать ее для определения присутствия Kubernetes во время выполнения.
Вы можете создать и свою собственную переменную окружения, но я уже давно использую встроенную переменную Kubernetes для проекта конкретного клиента, и она работает.
При каждом запуске контейнера запускается скрипт точки входа. Если вы устанавливаете определенное значение конфигурации перед запуском веб-сервера, вы можете использовать пользовательскую логику, например:
if [ -n "${KUBERNETES_SERVICE_HOST}" ]; then
# TODO: Добавьте сюда свою собственную логику или используйте sed для замены чего-либо в файле.
echo "Приложение запущено в Kubernetes!"
fi
При использовании -n проверяется, определена ли и установлена ли переменная env.
С помощью -z можно сделать обратное – проверить, пуста ли она.
Можно также добавить else для обработки обоих случаев.
Этого может быть достаточно, поскольку теперь вы можете выполнять здесь всю свою пользовательскую логику.
Если нет, то можно проверить наличие установленной переменной окружения при загрузке приложения и обойтись без скрипта точки входа, поскольку Kubernetes определит переменную окружения, и она будет доступна в контейнере и доступна вашему приложению.
см. также:
- ☸️ Настройка динамического постоянного хранения томов Kubernetes / OpenShift с помощью GlusterFS и Heketi
- ☸️ Разверните готовый кластер Kubernetes с помощью Ansible & Kubespray
