Potencia de serverless con SAP BTP, Kyma runtime. Anulación de la imagen base.
By s4pcademy
 |
 |
Este resumen es para demostrar cómo se pueden aprovechar las funciones sin servidor seleccionadas del tiempo de ejecución de SAP BTP Kyma. Esta cuota cubre:
|
SAP BTP, Kyma runtime es la oferta comercial de kubernetes completamente administrada de SAP, parte de SAP Business Technology Platform. A menudo se incluye con SAP Commerce Cloud y hoy en día se está convirtiendo en el tiempo de ejecución de extensibilidad de elección.
Kyma trae adicional componentes encima de un racimo de jardineros lisos. Y sin servidor es uno de ellos.
Bueno saber:
- Él sin servidor Las características descritas en esta y las siguientes entregas se pueden usar con el no administrado Sistema operativo Kyma en Jardinero y Gestionado por SAP SAP BTP, tiempo de ejecución de Kyma.
el inútil arquitectura está lejos de ser trivial. Por favor estudie el diagrama cuidadosamente.
A continuación, echemos un vistazo a la Especificación de la función.
Aparentemente, una de las mejores características con Kyma sin servidor CRD es la capacidad de anular la imagen de tiempo de ejecución base de una función.
Esto puede ser realmente útil cuando el imagen de tiempo de ejecución predeterminada simplemente no es lo suficientemente bueno para adaptarse a algunas dependencias de tiempo de ejecución específicas.
Sin embargo, tenga en cuenta la brecha. Las imágenes de la función de tiempo de ejecución base predeterminada de kyma están basadas en Alpine. Y las imágenes de nodejs basadas en Alpine tienen un recuento extremadamente bajo de vulnerabilidades de seguridad;
Por el bien de este resumen, probemos con el nodejs16 funciones Sin embargo, el mismo enfoque es válido para cualquier otro tiempo de ejecución sin servidor compatible, por ejemplo, con python 3.9.
Para reemplazar una imagen base predeterminada de una función nodejs16, debemos tratar de entender cómo lo hace kyma.
Echemos un vistazo a un Dockerfile definición utilizado por el propio kyma para crear una imagen base de función, a saber:
# image base on 16.19.0-alpine3.17
FROM node@sha256:e427ffd1ba7915ca8d8aeba45806ef3f1f1e6b65ce152b363645cd7428f8d75a
ARG NODE_ENV
ENV NODE_ENV $NODE_ENV
ENV npm_config_cache /tmp/
RUN mkdir -p /usr/src/app
RUN mkdir -p /usr/src/app/lib
WORKDIR /usr/src/app
COPY package.json /usr/src/app/
RUN npm install && npm cache clean --force
COPY lib /usr/src/app/lib
COPY server.js /usr/src/app/server.js
CMD ["npm", "start"]
EXPOSE 8888
La compilación del Dockerfile anterior dará como resultado lo siguiente imagen de archivoque eventualmente se usará en la función kaniko build
eu.gcr.io/kyma-project/function-runtime-nodejs16:v20230117-d8ab8401Bueno saber:
- Los archivos acoplables utilizados en la creación de funciones se almacenan como mapas de configuración en espacios de nombres de clúster de kyma. Vaya a su clúster para buscarlos.
Creación de una imagen personalizada.
Para crear una imagen personalizada, primero debe clonar el proyecto kyma github repositorio:
gh repo clone kyma-project/kyma
cd components/function-runtimes/nodejs16/
...............
add your Dockerfile, build the custom image and push it
to an internet facing docker repository
...............
cp Dockerfile Dockerfile.custom.nodejs16
nano Dockerfile.custom.nodejs16
...............
edit your Dockerfile.custom.nodejs16 then save it
and build your custom image
...............
docker build --platform amd64 -t <docker_id>/<docker_repo>:bullseye-slim16 -f ./Dockerfile.custom.nodejs16 .También necesitas hacer un decisión acerca de una nuevo imagen base nodejs16. Esa es una decisión importante, ya que usted es totalmente responsable de esta elección y de la imagen personalizada que se creará en función de ella.
Por el bien de este resumen, he elegido un público nodo: 16.19.0-bullseye-slim como mi nueva imagen base de nodejs16.
A continuación, puede crear una imagen base de función personalizada utilizando un Dockerfile.custom.nodejs16 definición (abajo).
Por último, pero no menos importante, deberá publicar la imagen construida a un público y frente a internet repositorio acoplable.
Por ejemplo, digamos que la nueva imagen base de nodejs es node:16.19.0-bullseye-slim y que vamos a añadir un racimo una biblioteca de Linux para adaptarse a cualquier dependencia de tiempo de ejecución específica, de la siguiente manera:
FROM node:16.19.0-bullseye-slim
ARG NODE_ENV
ENV NODE_ENV $NODE_ENV
ENV npm_config_cache /tmp/
RUN mkdir -p /usr/src/app
RUN mkdir -p /usr/src/app/lib
WORKDIR /usr/src/app
COPY package.json /usr/src/app/
RUN npm install && npm cache clean --force
RUN apt-get update
RUN apt-get install -y openssl python make g++
COPY lib /usr/src/app/lib
COPY server.js /usr/src/app/server.js
CMD ["npm", "start"]
EXPOSE 8888
Construyamos y publiquemos la imagen personalizada:
docker build --platform amd64 -t <docker_id>/<docker_repo>:bullseye-slim16 -f ./Dockerfile.custom.nodejs16 .
[+] Building 2.4s (16/16) FINISHED
=> [ 1/10] FROM docker.io/library/node:16.19.0-bullseye-slim@sha256:cfb2b5e2b39f341056ac624d32fae00ba0ab94145364111b7edfd9db703526e0 0.0s
=> CACHED [ 2/10] RUN mkdir -p /usr/src/app 0.0s
=> CACHED [ 3/10] RUN mkdir -p /usr/src/app/lib 0.0s
=> CACHED [ 4/10] WORKDIR /usr/src/app 0.0s
=> CACHED [ 5/10] COPY package.json /usr/src/app/ 0.0s
=> CACHED [ 6/10] RUN npm install && npm cache clean --force 0.0s
=> CACHED [ 7/10] RUN apt-get update 0.0s
=> CACHED [ 8/10] RUN apt-get install -y openssl python make g++ 0.0s
=> CACHED [ 9/10] COPY lib /usr/src/app/lib 0.0s
=> CACHED [10/10] COPY server.js /usr/src/app/server.js 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => naming to docker.io/<docker_id>/<docker_repo>:bullseye-slim16 empuje de la ventana acoplable <docker_id>/<docker_repo>:bullseye-slim16
Eventualmente, esta imagen personalizada se puede usar con funciones kyma serverless nodejs16, por ejemplo:
apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
name: runtime-image-override
labels:
app.kubernetes.io/name: runtime-image-override
annotations: {}
namespace: default
spec:
runtime: nodejs16
source:
inline:
source: |-
module.exports = {
main: async function (event, context) {
const message = `Hello World`
+ ` from the Kyma Function ${context["function-name"]}`
+ ` running on ${context.runtime}!`;
console.log(message);
return message;
}
}
runtimeImageOverride: <docker_id>/<docker_repo>:bullseye-slim16 Por lo tanto, todo lo que se necesita es agregar especificación.runtimeImageOverride a la definición de la función con el nombre de la imagen personalizada y aplicando la nueva definición.
Bueno saber:
- para forzar el cambio de imagen con una función existente, es posible que sea necesario cambiar el código fuente de esta función, así como activar el proceso de creación de la función.
Espero que hayas disfrutado leyendo la entrada del blog. Siéntase libre de proporcionar comentarios en la sección de comentarios a continuación.
En la próxima entrega de esta serie, demostraré cómo usar las bibliotecas SAP estándar para acceder secretos montados como volúmenes.
|
Pre-requisitos: SAP BTP, tiempo de ejecución de Kyma (SKR):
OS Kyma en jardinero: Descargo de responsabilidad:
|
