У меня есть веб-приложение мультипроцесс. Процессы поддерживаются различными пакетами сборки. Процесс по умолчанию запускает веб-приложение. У меня есть вариант использования, в котором данный сценарий оболочки должен быть выполнен до вызова процесса по умолчанию.
Я пробовал следующий подход;
Точка входа.sh
#!/usr/bin/env bash
# Some fancy stuff..
#Invoke the web process
/cnb/process/web
Создайте lauch.toml из скрипта сборки custom-buildpack. Сделайте процесс точки входа процессом по умолчанию.
cat > "$layers_dir/launch.toml" << EOL
[[processes]]
type = "entrypoint"
command = "bash"
args = ["$scriptlayer/bin/entrypoint.sh"]
default = true
EOL
echo -e '[types]\nlaunch = true' > "$layers_dir/assembly-scripts.toml"
Усеченный pack inspect-image
вывод
Processes:
TYPE SHELL COMMAND ARGS
entrypoint (default) bash bash /layers/gw_assembly-scripts/assembly-scripts/bin/entrypoint.sh
task bash catalina.sh run
tomcat bash catalina.sh run
web bash catalina.sh run
Есть ли лучший собственный подход CNB для достижения этого варианта использования?
Здесь у вас есть несколько вариантов:
Самый простой вариант — добавить скрипт .profile
в корень вашего приложения. Это скрипт bash, поэтому все, что вы можете написать в bash, может быть сделано там, однако в первую очередь он предназначен для инициализации вашего приложения и установки дополнительных переменных env.
Этот файл запускается до команды в вашем типе процесса. Я искал документацию по этому поведению, но нашел только кратко упоминается в спецификации buildpacks.
Например, если я помещаю .profile
в корень моего приложения и внутри этого файла, я пишу echo 'Hello World!'
. Я увижу Hello World!
напечатанным до выполнения любого из моих типов процессов.
Если вы хотите создать сборочный пакет, вы можете добиться чего-то похожего на сценарий .profile
, включив в свой сборочный пакет exec.d
двоичный.
Это двоичный файл, который является частью вашего образа запуска и запускается до любого из ваших типов процессов. Он позволяет выполнять действия по инициализации приложения и динамически устанавливать дополнительные переменные среды перед запуском приложения.
Этот механизм часто используется авторами сборочных пакетов для обеспечения динамического поведения во время выполнения на основе изменений переменных среды или привязок службы Kubernetes. Например, включение/выключение таких функций, как инструменты APM, отладка и метрики.
Еще несколько разных заметок.
Ни один из приведенных выше вариантов не позволяет изменить фактический тип процесса. Тип процесса, который будет выполняться, выбирается до запуска этих опций (.profile
и exec.d
), и вы не можете повлиять на него изнутри. Вы можете использовать их только для запуска вещей до запуска типа процесса.
Спецификация пакета сборки не позволяет пакету сборки изменять типы процессов для другого пакета сборки. Таким образом, вы не можете создать пакет сборки, который оборачивает или изменяет типы процессов, установленные другим пакетом сборки. Тем не менее, пакет сборки может переопределить типы процессов, установленные другим пакетом сборки. Пакеты сборки, которые находятся позже в группе заказа, переопределяют более ранние пакеты сборки.
Из спецификации: A combined processes list derived from all launch.toml files such that process types from later buildpacks override identical process types from earlier buildpacks
.
С пакетами сборки entrypoint
всегда launcher
. Launcher — это процесс, который запускает и реализует прикладную часть спецификации buildpack.. Он запускает .profile
, exec.d
исполняемые файлы, настраивает сборочный пакет, предоставляет переменные среды и, в конечном итоге, запускает указанный тип процесса.
Если вы выберете переопределить точку входа для контейнера, то лаунчер не запустится, и ничего из того, что он должен делать, не произойдет. Иногда это желательно, например, если вы устраняете неполадки, но обычно вы хотите, чтобы панель запуска была точкой входа.