Construyendo su propio servidor sin servidor basado en Fn


La informática sin servidor es una de las tendencias más visibles en la informática en la nube. El principio básico del trabajo es que la infraestructura no es asunto de DevOps, sino del proveedor de servicios. El escalado de recursos se adapta automáticamente a la carga y tiene una alta tasa de cambio.


Otra característica común es la tendencia a minimizar y enfocar el código, por lo que la informática sin servidor a veces se denomina "función como servicio" (FaaS).


Históricamente, el primer proveedor de servicios en la nube que ofreció FaaS con AWS Lambda fue Amazon, de donde proviene el nombre. Otros proveedores de servicios en la nube también ofrecen análogos:


  • Funciones de Google Cloud
  • Funciones de Azure de Microsoft

Todas estas empresas proporcionan computación sin servidor, escala automática y pagan solo por los recursos realmente utilizados, pero al mismo tiempo vinculan a los clientes con su producto patentado. Sin embargo, existen alternativas gratuitas de código abierto para la informática sin servidor. Vale la pena señalar:



Todos ellos son completamente independientes de las nubes, es decir, se instalan en cualquier nube, incluida la suya, pública o privada y, por supuesto, en Exoscale.


Cómo funciona el proyecto Fn


Fn está completamente basado en Docker, consta de dos componentes principales:


  • Programa CLI diseñado para gestionar todos los aspectos de la infraestructura Fn e interactuar con el servidor Fn,
  • En realidad, el servidor Fn, la aplicación habitual empaquetada en un contenedor para Docker.

Las funciones implementadas en Fn también se realizan en contenedores separados, lo que le permite admitir muchos lenguajes de programación, por ejemplo ... ¡Clojure!


Los argumentos de las funciones se transfieren a la entrada estándar (STDIN), los resultados se escriben en la salida estándar (STDOUT). Si los argumentos o los valores de retorno no son valores simples (por ejemplo, un objeto JSON), se pueden convertir utilizando la capa de abstracción proporcionada por el propio Fn como un kit de desarrollo de funciones (FDK).


Para mayor comodidad, las plantillas integradas están disponibles para facilitar el despliegue de FaaS en una extensa lista de diferentes idiomas y sus versiones (Go, diferentes versiones de Java, Python, etc.).


Crear FaaS es fácil siguiendo este patrón:


  • Implementamos la función usando la CLI Fn: se crea un archivo de configuración de la aplicación para Fn, basado en la plantilla seleccionada.
  • Implementamos nuestra propia función, nuevamente utilizando la CLI Fn: la imagen del contenedor se coloca en un determinado repositorio, después de lo cual se notifica al servidor la existencia y ubicación de esta imagen.


Principio de entrega de funciones en Fn


Instalación local y prueba de funciones sin servidor


Procedemos a instalar Fn en la máquina local. Docker se instala primero, como lo requiere Fn. Se supone que estamos en Debian / Ubuntu:


$ sudo apt-get update $ sudo apt-get install docker.io 

Bueno, o use la compilación de administrador de paquetes / Docker de acuerdo con su sistema. Luego puede ir directamente a la instalación de Fn CLI. Por ejemplo, usando curl:


 $ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh 

Si está ejecutando OSX con Homebrew instalado, puede hacer lo contrario:


 $ brew install fn ==> Downloading https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb ######################################################################## 100.0% ==> Pouring fn-0.5.8.high_sierra.bottle.tar.gz /usr/local/Cellar/fn/0.5.8: 5 files, 16.7MB 

Ahora todo está listo para la implementación inicial de nuestra función utilizando la CLI. Para simplificar, utilizaremos el entorno incorporado para ejecutar, por ejemplo, Nodo:


 $ fn init --runtime node --trigger http hellonode Creating function at: /hellonode Function boilerplate generated. func.yaml created. 

Se hellonode un nuevo directorio hellonode para desarrollar aún más nuestra función Fn con algunos archivos de configuración básicos. Dentro del directorio recién creado, puede crear su aplicación que siga los estándares de su idioma o tiempo de ejecución elegido:


 #   node  : hellonode ├── func.js ├── func.yaml └── package.json #   Java11 : hellojava11 ├── func.yaml ├── pom.xml └── src ├── main │ └── java │ └── com │ └── example │ └── fn │ └── HelloFunction.java └── test └── java └── com └── example └── fn └── HelloFunctionTest.java 

Fn crea la estructura inicial del proyecto, crea un archivo func.yaml que contiene la configuración necesaria para Fn e instala una plantilla para el código en el idioma que seleccionó.


En el caso del tiempo de ejecución de Node, esto significa:


 $ cat hellonode/func.js const fdk=require('@fnproject/fdk'); fdk.handle(function(input){ let name = 'World'; if (input.name) { name = input.name; } return {'message': 'Hello ' + name} }) 

Ahora comprobaremos rápidamente nuestra función localmente para ver cómo funciona todo.


Primero, iniciaremos el servidor Fn. Como ya se mencionó, el servidor Fn es un contenedor Docker, por lo tanto, después de comenzar, irá y tomará la imagen del registro Docker.


 $ fn start -d #      Unable to find image 'fnproject/fnserver:latest' locally latest: Pulling from fnproject/fnserver ff3a5c916c92: Pull complete 1a649ea86bca: Pull complete ce35f4d5f86a: Pull complete ... Status: Downloaded newer image for fnproject/fnserver:latest 668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5 

Para ejecutar nuestra función, debe implementarla. Esto requiere un : en Fn, todas las aplicaciones deben definirse como espacios de nombres para funciones relacionadas.


Fn CLI buscará el archivo func.yaml en el directorio actual, que se usará para configurar la función. Entonces, primero debes ir a nuestro directorio hellonode .


 $ cd hellonode $ fn deploy --app fnexo --local #   ,   - fnexo. #  local      , #    Deploying hellonode to app: fnexo Bumped to version 0.0.2 Building image nfrankel/hellonode:0.0.3 . Updating function hellonode using image nfrankel/hellonode:0.0.3... Successfully created app: fnexo Successfully created function: hellonode with nfrankel/hellonode:0.0.3 Successfully created trigger: hellonode-trigger 

Como puede ver en el resultado del comando, se crea una nueva imagen de contenedor para Docker que contiene nuestra función. La función está lista para ser llamada, y tenemos dos formas de hacerlo:


  • utilizando el comando invoke fn
  • llamando directamente a través de http

Llamar a invoke través de Fn simplemente emula el trabajo HTTP para las pruebas, lo cual es conveniente para una verificación rápida:


 $ fn invoke fnexo hellonode #   hellonode  fnexo {"message":"Hello World"} 

Para llamar a la función directamente, debe conocer la URL completa:


 $ curl http://localhost:8080/t/fnexo/hellonode-trigger {"message":"Hello World"} 

El servidor Fn proporciona sus funciones a través del puerto 8080, y parece que la URL de la función coincide con el esquema t/app/function , pero no completamente. A través de HTTP, la función no se llama directamente, sino a través del llamado disparador, que, según su nombre, "inicia" la llamada a la función. Los disparadores se definen en el proyecto `func.yml :


 schema_version: 20180708 name: hellonode version: 0.0.3 runtime: node entrypoint: node func.js format: json triggers: - name: hellonode-trigger type: http source: /hellonode-trigger # URL  

Podemos cambiar el nombre del disparador para que coincida con el nombre de la función, esto simplificará todo:


 triggers: - name: hellonode-trigger type: http source: /hellonode #     

Luego comenzamos la entrega de la función nuevamente y la llamamos desde el nuevo disparador:


 $ fn deploy --app fnexo hellonode --local $ curl http://localhost:8080/t/fnexo/hellonode {"message":"Hello World"} 

¡Todo funciona! ¡Es hora de realizar experimentos a gran escala y publicar nuestro FaaS en el servidor!


Instalar servicios de funciones sin servidor en su propia infraestructura


Instalemos rápidamente una máquina virtual con CLI Exoscale. Si aún no lo configuró, puede usar nuestra guía para iniciarlo rápidamente . Esta es una herramienta genial que mejorará aún más su productividad. ¡No olvide que necesita configurar una regla para abrir el puerto 8080 en el Grupo de seguridad! Los siguientes comandos lanzarán una máquina virtual limpia, lista para alojar nuestras funciones:


 $ exo firewall create fn-securitygroup $ exo firewall add fn-securitygroup ssh --my-ip $ exo firewall add fn-securitygroup -p tcp -P 8080-8080 -c 0.0.0.0/0 $ exo vm create fn-server -s fn-securitygroup 

Luego puede ssh en la máquina virtual e instalar el servidor remoto Fn:


 $ exo ssh fn-server The authenticity of host '185.19.30.175 (185.19.30.175)' can't be established. ECDSA key fingerprint is SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '185.19.30.175' (ECDSA) to the list of known hosts. Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64) 

Luego instale Docker y el servidor Fn de la misma manera que lo hicimos en la máquina local, inicie el servidor:


 $ sudo apt-get update $ sudo apt-get install docker.io $ sudo systemctl start docker $ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh $ sudo fn start ... ______ / ____/___ / /_ / __ \ / __/ / / / / /_/ /_/ /_/ v0.3.643 

¡Fn está listo para las funciones! Para la transferencia dirigida de funciones a un servidor remoto, utilizaremos el comando de deploy desde la computadora local, omitiendo el indicador --local .


Además, Fn requiere que especifique la ubicación del servidor Fn y el registro Docker. Estos parámetros se pueden establecer a través de las variables de entorno FN_API_URL y FN_REGISTRY respectivamente, pero se ofrece una forma más conveniente para administrar fácilmente la creación y administración de configuraciones para la implementación.


En términos de Fn, la configuración para la implementación se llama context . El siguiente comando creará el contexto:


 $ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel 

Puede ver los contextos disponibles como este:


 $ fn list contexts CURRENT NAME PROVIDER API URL REGISTRY default default http://localhost:8080/ exoscale default http://185.19.30.175:8080 nfrankel 

Y cambie al contexto que acaba de crear, así:


  $ fn use context exoscale Now using context: exoscale 

A partir de este momento, el suministro de funciones Fn cargará imágenes de Docker utilizando la cuenta seleccionada en DockerHub (en mi caso, nfrankel ), y luego notificará al servidor remoto (en este ejemplo, http://185.19.30.175:8080 ) sobre la ubicación y la versión La última imagen que contiene tu función.


 $ fn deploy --app fnexo . #       hellonode Deploying function at: /. Deploying hellonode to app: fnexo Bumped to version 0.0.5 Building image nfrankel/hellonode:0.0.5 . 

Por último:


 $ curl http://185.19.30.175:8080/t/fnexo/hellonode {"message":"Hello World"} 


Ciclo de vida de la función en informática sin servidor basada en Fn


Las ventajas de la informática sin servidor en sus instalaciones


La informática sin servidor es una solución conveniente para implementar rápidamente partes de aplicaciones independientes que interactúan con aplicaciones o microservicios más complejos.


A menudo, esto se debe al costo oculto de vinculación con el proveedor seleccionado, que, dependiendo del caso de uso específico y el volumen, puede conducir a mayores costos y una menor flexibilidad en el futuro.


Las arquitecturas de nube híbrida y de múltiples nubes también se ven afectadas en este caso, porque puede encontrarse fácilmente en una situación en la que le gustaría utilizar la informática sin servidor, pero debido a la política corporativa, esto puede no ser posible.


Fn es bastante simple de trabajar, puede proporcionar casi la misma interfaz FaaS, con bajos costos. Elimina cualquier enlace al proveedor; puede instalarlo localmente o en cualquier proveedor conveniente de soluciones en la nube de su elección. También hay libertad para elegir un lenguaje de programación.


Solo se presentan los conceptos básicos de Fn en el artículo, pero la creación de su propio entorno de tiempo de ejecución es bastante simple, y la arquitectura general se puede ampliar más ampliamente utilizando el equilibrador de carga Fn, o colocando Fn detrás de un proxy para protección.

Source: https://habr.com/ru/post/475044/


All Articles