SAP сейчас активно развивает Cloud Foundry (CF) и внедрила ее в SAP Cloud Platform, в качестве основного элемента облачной инфраструктуры. CF выполняет роль PaaS и позволяет запускать приложения в среде SCP. В этой статье мы расскажем каким образом подготовить CF к выходу вашего проекта в продуктив (фаза «Go Live»), а также, как разворачивать приложения в среде Cloud Foundry SCP и HANA XSA. Мы рассмотрим примеры и расскажем, как разумно управлять вычислительными серверными ресурсами, обеспечивая контролируемую среду для работы приложений.

Разработчик может использовать практически любой IDE и язык программирования, включая языки Python, Java, JavaScript, Go. CF создает изолированную среду исполнения (runtime environment) приложений и таким образом управляет отказоустойчивостью и доступностью приложений. SAP активно развивает проект CF в составе HANA Platform, который получил название HANA XSA (XS Advanced Runtime). Разработчик может легко мигрировать приложения из среды HANA XSA в среду CF в SAP SCP.

Концепция разработки приложений для SAP SCP реализована в Cloud Application Programming Model (CAP) и доступна на сайте. Приложения на базе SAP CAP легко можно перенести в среду CF.

CAP позволяет выполнять разработку приложений на локальном месте разработчика, включая пользовательский интерфейс и back-end сервисы на языках Java и JavaScript, используя БД SqlLite. Миграция готовых приложений в облако SAP SCP и HANA Cloud не требует дополнительных затрат, так как для работы с объектами в БД используется механизм CDS (Core Data Services), который позволяет абстрагироваться от конкретной СУБД.

 В CF/XSA все приложения работают в операционной системе LINUX, поэтому любая среда исполнения программного кода должна иметь реализацию в ОС Linux. Все учебные примеры в данной статье мы рассмотрим на примере Microsoft .NET Core и покажем, как запустить .NET приложение в HANA XSA.

Как успешно развернуть .Net приложение в среде CF / XSA?

В первую очередь следует определить среду исполнения для приложения, которая реализована в виде пакета buildpack, проверить версию компилятора, необходимых системных библиотек, а также установить переменные среды окружения. Мы не будем останавливаться на анатомии CF/XSA, но если вам интересно, то предлагаем ознакомиться с материалами по ссылке.

 На опыте реализованных проектов мы создавали собственные buildpack пакеты и разрабатывали свой процесс установки и запуска приложений.

 Пакет buildpack содержит необходимую логику для проверки условий компиляции и выполнения приложения, позволяет зафиксировать версию используемого компилятора и системных библиотек, необходимых для работы приложения. В рамках HANA XSA сервера приложений поставляется ряд готовых buildpack’ов, которые поддерживаются SAP, а именно: nodejs (javascript), java. Кроме этого, используются пакеты из среды CF, которые также могут работать в среде HANA XSA, а именно: php, go, dotnet_core, ruby.

Зачем создавать собственный buildpack?

· Требуется специфическая версия компилятора или среды исполнения,

· Требуется наличие определенных модулей, которые не доступны в стандартном buildpack,

· Требуется установка специальных системных библиотек, которые совместимы только с конкретной средой исполнения или компилятором определенной версии.

 В любом случае для разработчика главное знать, что HANA XSA не ограничивает его в выборе компилятора и среды исполнения приложений и это важно, так как дает возможность переносить уже созданный и отлаженный код в HANA XSA без изменений.

Весь механизм установки приложений и запуска реализован в процессах execution agent и controller, которые работают на сервере XSA и управляются с рабочего места разработчика, используя инструмент cli из командной строки. Мы не будем останавливаться на деталях реализации архитектуры XSA/CF, все доступно в официальной документации на портале help.sap.com (SAP HANA Developer Guide for XS Advanced Model), вместо этого мы рассмотрим практические примеры.

Процесс разработки собственного buildpack описан в документации, и чтобы его собрать, нужно создать скрипты, реализованные на языке shell script в среде Linux, либо на языке go.

Чтобы создать свой buildpack на базе Microsoft .Net Core Runtime 3.1 для HANA XSA 2.0 SP4, необходимо выполнить следующие шаги: 

1. Скачать и установить среду .NET Core Runtime 3.1. на сервере c установленным HANA XSA, либо на другом с аналогичной версией ОС Linux. В результате установки .NET Core Runtime будет создана директория. dotnet в домашней директории пользователя ОС Linux.

2. Создать архив в формате zip, gzip (любой формат на выбор пользователя), в который поместить содержимое директории. dotnet с установленной средой .NET Core Runtime.

3. Подготовить необходимые скрипты на языке shell script, а именно: compile, detect, release.

4. Создать архив в формате zip (только формат zip), в который поместить архив, созданный на этапе 2, а также скрипты, созданные на этапе 3.

5. Установить созданный buildpack с помощью команды xs create-buildpack (подробное описание команды указано в документации на сайте help.sap.com->SAP HANA Developer Guide for XS Advanced Model в разделе Create a PHP Buildpack for XS Advanced)

 Разрабатывая кастомизированный buildpack, важно понимать логику его работы, которая хорошо изложена в документации Cloud Foundry по ссылке. В данной статье основной упор делается на HANA XSA, где существуют незначительные отличия от среды CF, их мы рассмотрим на следующем примере.

 Основная логика работы buildpack заложена в скриптах compile, detect, release, рассмотрим ниже пример реализации для среды исполнения .Net Core Runtime 3.1 на базе HANA XSA 2.0 SP4.

· Сompile скрипт в среде HANA XSA выполняет задачу сборки (build) приложения из исходных кодов и также выполняет проверку условий компиляции приложения, например наличие файла appsettings.json, требуемого framework, assembly и т.д.

Исходный код скрипта compile >>
#!/bin/bash
# bin/compile <build-dir> <cache-dir>

BUILD_DIR=$1
BIN_DIR=`dirname $0`
BUILD_PACK_DIR=`dirname ${BIN_DIR}`
echo "Extracting .NET runtime into..."
echo ${BUILD_DIR}
cd ${BUILD_DIR}
tar xzvf ${BIN_DIR}/../runtime/runtime.tgz
echo "Extracting .NET runtime Done."

Важно отметить, что скрипт compile не используется в среде CF и был заменен на скрипты supply и finalize, однако для среды HANA XSA требуется использовать compile.

·Detect скрипт в среде HANA XSA выполняет задачу проверки совместимости конкретного buildpack для исполнения кода приложения.

#!/bin/bash
# bin/detect <build-dir>
if [ -f $1/appsettings.json ];
    then exit 0
fi
exit 1

· Release скрипт в HANA XSA выполняет задачу подготовки к запуску приложения, генерирует файл в формате yaml, в котором указывается команда для запуска приложения.

Исходный код скрипта detect >>

#!/bin/bash
# bin/detect <build-dir>
if [ -f $1/appsettings.json ];
    then exit 0
fi
exit 1

· Release скрипт в HANA XSA выполняет задачу подготовки к запуску приложения, генерирует файл в формате yaml, в котором указывается команда для запуска приложения.

Исходный код скрипта release >>

#!/bin/bash
# bin/release

cat <<EOF
---
config_vars:
addons:
default_process_types:
  web: /bin/bash ./start.sh 

EOF

Готовый buildpack для среды исполнения .Net Core Runtime 3.1. доступен для скачивания по ссылке.

В итоге получается следующая структура директории, на базе которой создается архив zip, который, по сути, и является buildpack.

Какую конфигурацию HANA XSA выбрать для продуктивной эксплуатации?

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

 В режиме продуктивной эксплуатации HANA XSA предлагает защищенный вариант Multi-Host, в рамках которого СУБД HANA и сервер HANA XSA размещаются на физически разных серверах (см. Рис.).

Режим HANA XSA Multi-Host позволяет обеспечить экономию памяти продуктивного сервера СУБД HANA, обеспечив запуск приложений на выделенном сервере и при желании снизить требования к оборудованию для запуска HANA XSA.

Режим Multi-Host подразумевает наличие ролей XS_WORKER и XS_STANDBY, которые позволяют создать режим Auto-Failover для запуска приложений в HANA XSA в случае сбоя серверного оборудования.

 Мы не будем рассматривать подробности установки HANA XSA в режиме Multi-Host, вместо этого мы разберем пример запуска приложений в режиме контроля используемых ресурсов памяти.

Как защитить приложения в среде HANA XSA от утечек памяти?

Помимо HANA XSA Multi-Host, рекомендую ознакомиться с вариантами, которые позволяют контролировать использование ресурсов памяти. Как правило среда исполнения приложений должна иметь необходимые параметры для ограничения используемых ресурсов памяти. Но что делать, если таких параметров не предусмотрено?

 Очень важно понимать и использовать механизмы ОС Linux, которые давно предлагают простые и доступные инструменты – Linux Control Groups (Cgroups). Мы не будет останавливаться на деталях реализации механизма Cgroups, но отметим, что этот механизм реализован достаточно давно в ядре Linux и позволяет на уровне процессов ОС задавать ограничения используемых ресурсов памяти в байтах. Таким образом, указывается лимит памяти, которую может запросить процесс у операционной системы. И однозначно запрещается выделение дополнительной памяти, которая может произойти из-за утечек памяти, сбоев, ошибок и привести к остановке других приложений.

 Особенно важно использовать механизм Linux Cgroups, когда выполняется запуск проекта на стадии Go Live, обеспечив тем самым защиту от возможных ошибок в коде и повысив надежность HANA XSA.

 Пример реализации механизма Linux Cgroups указан ниже в виде shell script, который выполняет запуск приложения для buildpack созданного выше на базе среды исполнения .Net Core Runtime 3.1.

Исходный код скрипта start.sh >>

#!/bin/bash


if [ -z "$CGNAME" ]
then
	echo "[ERR]Please check CGNAME to place cgroup name limits."
	exit 1
else
	echo "[OK] CGNAME is set to '$CGNAME'"
fi

if [ -z "$MemoryLimitInMB" ]
then
	echo "[ERR] Please check memory limit settings."
	exit 1
else
	echo "[OK] MemoryLimitInMB is set to '$MemoryLimitInMB'."
fi

if [[ ! $(sudo echo 0) ]]; then echo "[ERR] sudo rights for user '$USER' needed.";exit 1; else echo "[OK] sudo rights for user '$USER' exist"; fi

create_cgroup_for_space(){
	if [[ $(sudo mkdir /sys/fs/cgroup/memory/$CGNAME) ]]; then echo "[ERR] can not create cgroup with name '$CGNAME'."; exit 1; else echo "[OK] cgroup '$CGNAME' successfully created."; fi
}

if [[ ! $(sudo ls /sys/fs/cgroup/memory/$CGNAME 2>/dev/null) ]]
then 
	echo "[WRN] cgroup '$CGNAME' is not set."
	create_cgroup_for_space
else 
	echo "[OK] cgroup '$CGNAME' is set." 
fi

if [[ $(sudo sh -c "echo $MemoryLimitInMB > /sys/fs/cgroup/memory/$CGNAME/memory.limit_in_bytes") ]]
then
	echo "[ERR] Can not set memory limit for app."
	exit 1
else
	echo "[OK] Successfully set memory limit to '$MemoryLimitInMB'."
fi

ATTACH=`awk '/^__MS_DOT_NET_RUN__/ {print NR + 1; exit 0; }' $0`

tail -n+$ATTACH $0 > ./run.sh

_PID=`echo $$`

if [[ ! $(sudo sh -c "echo $_PID > /sys/fs/cgroup/memory/$CGNAME/tasks") ]]
then
	chmod +x ./run.sh && /bin/bash ./run.sh	
else
	echo "[ERR] Unable to start app"
	exit 1
fi

exit 0

__MS_DOT_NET_RUN__

#!/bin/bash

trap "exit" INT TERM ERR
trap "kill 0" EXIT

export ASPNETCORE_URLS="http://localhost:$VCAP_APP_PORT"
 
echo "ASPNETCORE_URLS: '$ASPNETCORE_URLS'";
 
# Getting runnable dll.
runtimeconfigs=($(ls *.runtimeconfig.json));
if [ ${#runtimeconfigs[@]} -gt 1 ] ;
then
    echo "Error! Found '${#runtimeconfigs[@]}' *.runtimeconfig.json files! Expecting only one. Files: '${runtimeconfigs[@]}'.'" 1>&2;
    exit 1;
fi;
 
if [[ ${#runtimeconfigs[@]} -eq 0 ]] ;
then
    echo "Error! Can't find *.runtimeconfig.json file!" 1>&2;
    exit 1;
fi;
 
exeFile=$(echo "${runtimeconfigs[0]//.runtimeconfig.json/}")
if [ -f $exeFile ]
then
    echo "starting '$exeFile'...";
    exec "./$exeFile" --urls $ASPNETCORE_URLS;
    exit;
fi
 
dllFile=$(echo "${runtimeconfigs[0]//.runtimeconfig.json/.dll}")
if [[ !(-e $dllFile) ]] ;
then
    echo "File '$dllFile' is not found." 1>&2;
    exit 1;
fi
 
exec ./dotnet $dllFile --urls $ASPNETCORE_URLS;

В этой статье мы рассмотрели пример и предложили рекомендации о том, как запускать приложения в HANA XSA для продуктивной эксплуатации и обеспечить защиту от возможных сбоев, используя встроенные механизмы ОС Linux и HANA XSA. Все примеры были разработаны и использованы на опыте реальных проектов в Лаборатории Совместных Инноваций компании SAP (SAP Co-Innovation Lab). Если у вас будут вопросы или предложения, пишите в комментариях.

 Автор - Василий Суханов, архитектор Лаборатории Совместных Инноваций SAP Labs CIS