Реализовать функциональность, аналогичную Entrypoint, в Cloud Native Buildpack

У меня есть веб-приложение мультипроцесс. Процессы поддерживаются различными пакетами сборки. Процесс по умолчанию запускает веб-приложение. У меня есть вариант использования, в котором данный сценарий оболочки должен быть выполнен до вызова процесса по умолчанию.

Я пробовал следующий подход;

  1. Создать пользовательский пакет сборки
  2. Создайте скрипт, который необходимо выполнить, и вызовите в нем веб-процесс.
  3. Создайте новый процесс на основе приведенного выше сценария оболочки, указав его в определении launch.toml.
  4. Сделать пакет сборки доступным для запуска

Точка входа.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 для достижения этого варианта использования?


1
82
1

Ответ:

Решено

Здесь у вас есть несколько вариантов:

  1. Самый простой вариант — добавить скрипт .profile в корень вашего приложения. Это скрипт bash, поэтому все, что вы можете написать в bash, может быть сделано там, однако в первую очередь он предназначен для инициализации вашего приложения и установки дополнительных переменных env.

    Этот файл запускается до команды в вашем типе процесса. Я искал документацию по этому поведению, но нашел только кратко упоминается в спецификации buildpacks.

    Например, если я помещаю .profile в корень моего приложения и внутри этого файла, я пишу echo 'Hello World!'. Я увижу Hello World! напечатанным до выполнения любого из моих типов процессов.

  2. Если вы хотите создать сборочный пакет, вы можете добиться чего-то похожего на сценарий .profile, включив в свой сборочный пакет exec.d двоичный.

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

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

Еще несколько разных заметок.

  1. Ни один из приведенных выше вариантов не позволяет изменить фактический тип процесса. Тип процесса, который будет выполняться, выбирается до запуска этих опций (.profile и exec.d), и вы не можете повлиять на него изнутри. Вы можете использовать их только для запуска вещей до запуска типа процесса.

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

    Из спецификации: A combined processes list derived from all launch.toml files such that process types from later buildpacks override identical process types from earlier buildpacks.

  3. С пакетами сборки entrypoint всегда launcher. Launcher — это процесс, который запускает и реализует прикладную часть спецификации buildpack.. Он запускает .profile, exec.d исполняемые файлы, настраивает сборочный пакет, предоставляет переменные среды и, в конечном итоге, запускает указанный тип процесса.

    Если вы выберете переопределить точку входа для контейнера, то лаунчер не запустится, и ничего из того, что он должен делать, не произойдет. Иногда это желательно, например, если вы устраняете неполадки, но обычно вы хотите, чтобы панель запуска была точкой входа.