Bienvenido de nuevo a Backspacer Academy.
En esta conferencia, vamos a hablar sobre la tierra, el servicio comenzará hablando sobre los
tiempos de ejecución, lo que son y cómo pueden establecer nuestra tierra, por ejemplo, cuando se invoca y
también hablará sobre cómo la tierra de la función los ejecuta.
Hablaremos sobre cómo podemos desarrollar nuestro código y empaquetarlo y luego implementarlo en una tierra de funciones.
Hablaremos sobre las diferentes formas en que se puede invocar una tierra de funciones.
Hablaremos sobre cómo nuestra tierra para funcionar puede conectarse a Internet, puede conectarse a subredes privadas, puede conectarse
a bases de datos.
Luego hablaremos sobre cómo puede obtener el máximo rendimiento de nuestra tierra, una función.
Y finalmente, hablaremos sobre cómo podemos monitorear el funcionamiento de nuestra tierra para funcionar.
Se ejecuta un tiempo de ejecución de Lambda cuando se invoca la tierra de la función, lo primero que hace es leer el código
de configuración de la función y eso podría estar configurando esa instancia de lambda para no ejecutar JS o Python
o lo que sea.
Y puede haber otras cosas que también deben configurarse para que esa tierra funcione o esa
instancia invocada por Lambda.
Una vez que se ha configurado esa instancia lambda, el tiempo de ejecución leerá el nombre del controlador de una variable de
entorno.
Ahora el controlador que es un código que proporcionó puede no ser Giuse, puede ser Python o lo que sea, pero
ese es el código que va a ejecutar en esta instancia lambda.
Luego leerá los eventos de invocación.
Entonces, por ejemplo, si tuvimos un evento S3 que se dispara cuando cargamos un objeto en una lista de cubo S3,
entonces los datos del evento incluirán un montón de cosas.
Entre otros, tendrá el nombre del depósito S3, tendrá el objeto S3 que se cargó.
Entonces, toda esa información que estaba dentro de ese evento se pasará de la API de Lambda Runtime y
esa información se pasará al controlador para que la procese.
Y luego, una vez que un controlador ha hecho su parte y ha hecho su código, publicará esa
respuesta de nuevo en el tiempo de ejecución y el tiempo de ejecución lo enviará a la API de tiempo de ejecución de LAMBDA,
cómo se administran el tiempo de ejecución al disponible sin JS Python , Java, dot net, ruby y listo.
Ahora, teóricamente, puede crear un tiempo de ejecución personalizado para cualquier idioma que desee, no está limitado al tiempo de ejecución administrado por
los EE. UU., Pero, por supuesto, va a ser mucho trabajo para usted crear su propio tiempo de
ejecución personalizado.
Pero si quieres hacer eso, es posible.
Entonces, un tiempo de ejecución personalizado, se ejecutará en el entorno de ejecución lamda estándar como antes.
Utilizará una API de tiempo de ejecución para recibir eventos y luego devolver esas respuestas.
Entonces, la forma en que configura un tiempo de ejecución personalizado es que en la definición del tiempo de ejecución de
sus funciones, cuando crea esa función, debe configurarla para proporcionarla.
Una vez que hayas hecho eso, debes crear un script.
Y eso podría ser un script de shell.
Podría ser un script en un idioma que se incluye en la distribución de Amazon Linux, o
podría ser un archivo binario ejecutable.
Una vez que haya creado eso, lo coloca dentro de su paquete de implementación o dentro de una capa dentro de
su paquete de implementación.
Y el punto de entrada que Lambda buscará, siempre que el tiempo de ejecución de las funciones esté configurado para proporcionarlo.
Luego buscará un punto de entrada llamado bootstrap, de modo que bootstrap sea un script que comenzará a ejecutar ese
ejecutable en tiempo de ejecución o ese script en tiempo de ejecución.
Para entender la tierra correctamente, necesitamos entender el contexto de ejecución de una instancia de LAMDA de votación de ID,
y esto será bastante diferente a una instancia de la UE porque estas son instancias temporales y
de corta duración.
Por lo tanto, el contexto de ejecución es un entorno de tiempo de ejecución temporal que inicializa las dependencias externas
que requiere nuestro controlador.
Nuestro código principal hará referencia a muchas dependencias externas.
Podrían ser bibliotecas, podrían ser paquetes, sean lo que sean.
Y así la tierra mantendrá el contexto de ejecución durante algún tiempo, permitiendo su reutilización.
Porque la forma en que funciona es que cuando invoquemos una función lambda, llevará tiempo inicializar
esas dependencias externas.
Entonces, si podemos reutilizarlos, hará que el tiempo de invocación de la latencia para lanzar estas instancias temporales sea
mucho más rápido.
La forma en que podemos aprovechar el contexto de ejecución para reducir la latencia de invocación, la latencia que se
necesita para invocar estas instancias es que podemos hacer que nuestros objetos se declaren fuera del controlador de
funciones.
Y así, cuando se desecha esa función, los métodos que están fuera de ese método de controlador de
funciones permanecen inicializados.
Entonces eso podría ser una conexión de base de datos.
Y, por lo tanto, las conexiones a la base de datos pueden tomar un poco de tiempo que podría tomar unos
segundos para que ocurran.
Por lo tanto, mantener esas conexiones de base de datos abiertas y ser reutilizadas por otras instancias tiene sentido.
Otra cosa que debemos tener en cuenta es que tenemos un directorio temporal en todas nuestras instancias de
lamda.
Entonces, normalmente cuando se termina esa instancia, el contenido del directorio temporal también se perderá.
Pero durante un cierto período de tiempo, eso permanece y puede ser reutilizado por otras instancias.
Además, los procesos en segundo plano y las devoluciones de llamada se definen fuera de la función.
Hadleigh también puede permanecer durante un cierto período de tiempo, por lo que debe tenerse cuidado porque puede perder
contenido si está en ese directorio temporal.
Entonces, eso es temporal y asegúrese de tratarlo como temporal o cualquier proceso en segundo plano no deseado que
aún pueda existir.
Debe asegurarse de que se terminen cuando finalice la instancia.
Para desplegar un land para funcionar, necesita crear un land, un paquete de despliegue, y eso es
simplemente un archivo zip que contiene todo su código de función y sus dependencias.
Por lo tanto, puede crear ese archivo zip y puede cargarlo usando la consola cuando esté creando su tierra
para funcionar.
O puede ponerlo en un depósito de Amazon S3 y hacer referencia a ese depósito de S3.
Si el paquete de implementación es superior a 50 meg, debe usar Amazon S3 ahora.
Sus paquetes externos, no necesitan estar en ese código postal.
Puede hacer referencia a aquellos en un paquete.
Jason, si es una aplicación sin JS o en un texto DOT de requisitos, si es una aplicación de Python
y desde allí puede usar el mismo comando Seelie Bill, que puede crear ese paquete y
colocarlo en la ubicación correcta, listo para la implementación.
Cuando creamos nuestra tierra, el paquete de implementación en un archivo zip, podemos ir a la tierra, la consola
y crear esa función y simplemente suministrar ese código o hacer referencia a un cubo S3 que tiene ese
código.
También podemos usar la formación de nubes y lo hacemos al tener un tipo de tierra de Edwards para funcionar.
Y necesitamos definir algunas propiedades.
El código, que será el segmento S3 que contiene ese código, o si no es muy largo, podemos poner el
código como en préstamo, en el código de línea en esa propiedad del código.
También tenemos el controlador y ese será el código que Lander llama para ejecutar su función.
Ese será el archivo y también el nombre del controlador.
También debemos tener un papel para que la tierra funcione, de modo que se definan qué permisos tendrá esa función
de tierra.
Por lo tanto, debemos definir el número de recurso de Irene o AMSANT para ese rol y el tipo de tiempo de ejecución, ¿qué
idioma vamos a utilizar?
Va a ser
No, los de Jessa serán Python Java.
Así que necesitamos definir eso también.
Y es una buena idea darle un nombre de función.
Pero si falta, la formación de nubes generará una única para usted.
También podemos usar la interfaz de línea de comandos o uno de los muchos kits de desarrollo de software, y
usamos un comando de función de creación para hacerlo.
Y nuevamente, necesitaremos definir el código, el controlador, el rol y el tiempo de ejecución para ese comando.
El modelo de aplicación sin servidor, o Sam para abreviar, es parte de la especificación de formación de la
nube, y puede simplificar el despliegue de nuestras aplicaciones Cervalis que pueden incluir no solo Lander sino también otros servicios
como API Gateway, con el fin de contarle a la nube Para saber que vamos
a utilizar el modelo de aplicación sin servidor en nuestra plantilla, necesitamos tener una transformación y luego estar
con el comando Cervalis allí.
Y luego, después de eso, necesitamos definir nuestros recursos.
Entonces, como en cualquier plantilla de formación de nubes, debemos tener recursos.
Por lo tanto, podría haber una combinación de formación de nubes y recursos SAM.
Por lo tanto, podría ser una máquina de estado API de funciones, una tabla Dinamo DB, pero también podría tener una
referencia a una instancia activa.
No tiene que ser simplemente recursos sin servidor lo que estamos definiendo allí.
También hay algo que es único para el mismo modelo y que es globalizar y aquellos que
se utilizan para definir configuraciones compartidas a lo largo de esta plantilla.
Por ejemplo, si todas las instancias que está iniciando, las instancias de Orlanda utilizarán el
mismo tiempo de ejecución sin JS.
Entonces puedes usar ese tiempo de ejecución en todos esos.
No es necesario, puede definirlo como global y luego compartirlo entre todos.
No necesita definir eso nuevamente.
Y lo mismo con el controlador también.
Si desea reutilizar ese controlador sin tener que definirlo para cada uno de ellos, esas
son definiciones para una función.
Y entonces tenemos la misma interfaz de línea de comandos y podemos usar el mismo comando de compilación y eso preparará nuestro
código para la implementación.
Leerá nuestro paquete sin trabajos, Jason, o nuestro archivo de texto de puntos de requisitos de Python.
Y eso lo preparará.
Construirá nuestra aplicación lista para la implementación y la colocará en la ubicación correcta para nosotros y
luego simplemente implementaremos Sam y eso implementaría nuestra aplicación.
Y luego esa aplicación aparecerá en la tierra, la consola como una aplicación.
Y para que esas mismas aplicaciones se puedan administrar simplemente usando la tierra, la consola.
Si hacemos cambios en el código de nuestra función de tierra y no queremos afectar la versión de producción actual que
se está utilizando, lo que podemos hacer es publicar una nueva versión de esa tierra para que funcione.
Y lo que hará es crear una nueva función que tendrá un nombre de recurso de Amazon totalmente
diferente.
Y eso no afectará nuestra versión actual, que tendrá una R. diferente METRO..
Entonces, lo que podemos hacer es que podemos hacer esos cambios en el código y luego podemos publicar esa nueva versión.
Y esa nueva versión incluirá ese código y cualquier dependencia.
Incluirá el tiempo de ejecución de la versión anterior y cualquier configuración, incluidas las variables de entorno.
La forma en que creamos una nueva versión es que vamos a la consola del módulo de aterrizaje,
seleccionamos nuestra función, hacemos los cambios en nuestro código, y luego simplemente publicamos una nueva versión y eso creará una nueva función
con un nuevo ARMM.
O podemos ingresar a la interfaz de línea de comandos de Amazon y podemos usar un comando land para publicar esa versión.
Ahora, una cosa que debe tener en cuenta es que cuando haya cambiado un Aaren de
una tierra, la función, cualquier política basada en recursos que haga referencia a Arryn ya no funcionará, y también cualquier
evento que haga referencia a Arryn.
Por ejemplo, puede tener un evento S3 que se dispara cuando algo se carga en un depósito S3, y si
eso hace referencia a la antigua arryn, entonces eso ya no funcionará o ya no funcionará como
espera que funcione.
Entonces debes tomar eso en consideración.
Una vez que se ha publicado una versión, su código no se puede cambiar.
Entonces entran en la consola lambda y si intentas cambiar el código, simplemente no te dejará hacerlo.
Entonces, lo que debe hacer es seleccionar la última versión y esa es su versión funcional de
ese código.
Realizas tus cambios en eso y luego puedes publicar otra versión.
Pero una vez que se ha publicado una versión, no puede cambiarla después de tener que usar
su versión actual y hacer los cambios a la versión actual.
Para superar el problema de tener estos Arin cambiantes cada vez que tenemos una versión diferente, lo
que podemos hacer es crear un alias y un alias es un puntero a una versión específica de
una función lambda, y su alias tendrá su propio arryn único.
Y así podemos actualizar un alias que apuntaba a una versión anterior y luego podemos hacer que apunte a
nuestra nueva versión.
Y mantenemos ese mismo hÉireann para que podamos hacer que nuestro nuestro código de función sea probado y funcione correctamente.
Y luego podemos usar nuestro alias para señalar la nueva versión.
Y lo que podemos hacer es cambiar el tráfico entre esas dos versiones en función de un porcentaje de blancos.
Entonces, lo que podríamos hacer es comenzar por tener solo el 10 por ciento de nuestro tráfico
yendo a la nueva versión y luego migrarlo lentamente a todo nuestro tráfico.
Y eso va a reducir los dolores de cabeza para nosotros.
Si hay algún problema, no vamos a tener una gran masa de usuarios que van a tener problemas.
Y así, esas políticas basadas en recursos y cualquier evento, pueden hacer referencia al alias Iren.
Y siempre nuestro alias Irene apuntará a esa versión de esa tierra, una función que quisiéramos que queramos
como nuestra versión de producción.
Entonces podemos hacer eso en la consola de tierra, o podemos usar la interfaz de línea de comando
y el comando hay tierra para crear ese alias.
Las variables de entorno son pares de valores de clave específicos de la versión, por ejemplo, puede tener un nombre basado en datos como clave
y luego el nombre de esa base de datos como un valor para esa clave.
Y lo que hacen es que le permiten almacenar secretos de forma segura y ajustar el comportamiento de su función sin
actualizar su código.
Entonces, por ejemplo, podría tener los detalles de conexión de su base de datos, como un nombre de usuario y contraseña,
para que pueda actualizarlos sin tener que ingresar su código y actualizar su código.
También es muy importante para almacenar esos secretos de forma segura y fuera del código de su función.
Es mucho mejor ponerlos en variables de entorno en lugar de codificarlos en su código.
Debe tener en cuenta que no se pueden cambiar después de que se haya publicado una versión.
Por lo tanto, debe usar su última versión de trabajo y luego hacer esos cambios en esas variables de
entorno.
Entonces, la forma en que usamos las variables de entorno es que podemos ir a la
tierra, a la consola, seleccionamos nuestra función y solo hacemos variables de entorno y agregamos variables de entorno.
También podemos usar la interfaz de línea de comandos o uno de los muchos kits de desarrollo de
software y el comando allí es lambda y luego actualizar la configuración de funciones y luego el entorno de escritorio.
Y luego definiríamos las variables y la clave y el valor de esas variables.
También podríamos usar el modelo de aplicación Cervalis o la formación de nubes en las propiedades de nuestra función.
Necesitamos definir el entorno y luego las variables y luego la clave y luego el valor.
Como hemos aprendido de nuestra discusión sobre el contexto de ejecución, la invocación de nuestra tierra para
funcionar se puede ralentizar si muchos paquetes y bibliotecas deben inicializarse de antemano.
Y también nuestro archivo ZIP puede ser bastante grande si incluye también estos paquetes y bibliotecas.
Entonces, lo que hacemos es definir que fuera de nuestra tierra, un manejador de funciones.
Y así se asegurará de que puedan reutilizarse más adelante.
Lo que también podemos hacer es aprovechar la ventaja de poner todas estas bibliotecas y
paquetes en un archivo zip y ponerlos en una capa.
Y esas capas pueden ser reutilizadas por otra tierra de funciones.
Y eso nos permite mantener ese paquete de implementación pequeño para que podamos definir hasta cinco capas por función.
Pero el código de función y todas estas capas aún deben ser inferiores a 250 meg.
Podemos usar la consola lambda para definir una capa y cargar ese archivo zip, o podemos usar la interfaz de línea
de comando y el comando es la configuración de la función de actualización lambda y luego las capas del tablero de instrumentos para
definir esa capa.
También podemos usar el modelo de aplicación de servicio o la formación en la nube y definirlo ahora.
Los recursos de plantilla y los recursos serán de Lib y el tipo será una versión de capa sin servidor de EE.
UU. Y luego solo necesitamos definir el contenido urai, que será la ubicación de ese archivo ZIP que
contiene todas estas bibliotecas y paquetes.
El repositorio de aplicaciones sin servidor es un repositorio administrado para aplicaciones SAM, y nos permite compartir y
reutilizar nuestras aplicaciones y también podemos buscar aplicaciones que han sido hechas y publicadas para
uso abierto por otros usuarios, y también por Amazon Web Servicios.
La consola del repositorio de aplicaciones sin servidor se puede usar para publicar cualquiera de nuestras aplicaciones SAM.
O podemos usar el comando Seelie Sam Publish, que también publicará nuestra aplicación en el sitio.
Lo que debemos hacer es incluir una sección de metadatos en nuestra plantilla SAM y eso
incluirá detalles como nuestro Nombre El día o el nombre de la aplicación, la descripción, la licencia de esa
aplicación y la URL del código fuente.
Si es un repositorio de GitHub, la URL del código fuente también.
Si queremos usar una aplicación que está en el repositorio de aplicaciones de Cervalis, simplemente podemos ir a la
consola y podemos buscarla y buscarla, y encontraremos cualquier aplicación que hayamos puesto allí u otras que hayan
puesto allí que para uso público o tal vez se puso allí.
Una vez que hayamos encontrado uno que usemos y que nos gustaría usar, podemos configurarlo.
Podemos establecer nuestras variables de entorno en cualquier parámetro para eso.
Tal es el tamaño de nuestra función y todo ese tipo de cosas.
Y luego podemos implementarlos como una misma aplicación y podemos administrar eso en la consola de administración de
tierras.
Hay varias maneras diferentes de invocar una función lamda, si queremos invocar la función de Alanda para la prueba,
simplemente podemos usar la consola lambda después de haber creado esa función y simplemente podemos probar y
eso invocará esa función Shetlander y enviará un evento de prueba a esa función lambda.
O podemos usar uno de los muchos kits de desarrollo de software o la interfaz de línea de comandos.
Hay dos tipos diferentes de invocación, la primera es la invocación síncrona, que es
estándar, y ahí es donde esperamos que esa función procese el evento que le hemos enviado.
Y luego vamos a esperar a que esa función lambda devuelva una respuesta.
La otra forma en que podemos invocar la función lambda es con invocación asincrónica y, en esa situación,
lambda la tierra.
El servicio indicará el evento para su procesamiento y devolverá una respuesta inmediatamente antes de que
la función lambda haya sido desocupada.
Y así no tenemos que esperar esa respuesta.
Vamos a obtener una respuesta de inmediato.
Si quisiéramos aprovechar la invocación asincrónica, necesitamos tener un tipo de invocación como eventos
para que los eventos puedan invocar una función directamente.
Por ejemplo, puede tener un evento S3 en un bucket de Amazon S3.
Entonces, cuando se carga un objeto en ese depósito, un evento S3 disparará e invocará directamente una función
lambda.
O podemos tener el servicio de aterrizaje en sí, podemos leer una fuente de eventos.
Así que podría ser una secuencia, podría ser una secuencia de Conesa o una secuencia de Dinamo DB o podría ser una excusa.
P Entonces, el servicio de aterrizaje leerá eso y cuando lo necesite invocará una función.
Y eso se llama mapeo de origen de eventos lambda.
Así que aquí podemos ver que tenemos Synchronoss en vocación y de esa manera tenemos
a nuestros clientes, podrían ser un recurso, podría ser un Amusa, sea lo que sea, ha creado un evento y ha invocado su función.
Y esos clientes están esperando que vuelva una respuesta.
Así que aquí podemos ver que tenemos nuestra invocación sincrónica y que nuestros clientes van a crear un evento y
eso va a entrar en un evento.
P Y tan pronto como eso entra en un evento.
P Entonces, de inmediato, el servicio LAMDA enviará una respuesta y luego el servicio Lambda invocará una tierra de
funciones y pasará los detalles del evento de ese evento.
Q.
Y finalmente, tenemos el mapeo de la fuente de eventos, por lo que aquí se muestran los eventos, el mapeo de McCamey de origen
con una transmisión de Kinesis.
Así que tenemos a nuestro usuario allí o nuestro recurso o lo que sea que esté creando registros que van a
un flujo de datos de Kinesis.
Por lo tanto, el servicio de aterrizaje realizará un mapeo de origen de eventos.
Leerá ese flujo de datos de Kinesis.
Y en función de lo que hay en ese flujo de datos de Kinesis, invocará una función de aterrizaje y enviará ese
evento como un lote para que sea procesado por esa función de aterrizaje.
Si no puede invocar esa función de aterrizaje o el evento no se procesa, el evento entrará
en un evento fallido.
Destino Q.
Los servicios que invocan funciones de Lambda sincrónicamente incluyen la API Gateway Lambda en edX Kinesis Data Firehoses,
pero a diferencia de los firehose de datos de Conesa Streams se invocarán sincrónicamente.
Las funciones de estado invocarán sincrónicamente y los servicios de equilibrador de carga de aplicaciones que invocan de forma
asincrónica incluyen Amazon S3, S. A. S. , SES, formación de nubes, registros de observación
de nubes y eventos de observación de nubes y también servicios de confirmación de código y canalización de códigos de los que Lambda lee eventos mediante el mapeo de origen de eventos y
que son las transmisiones y Qs.
Así que tenemos transmisiones de Conesa, transmisiones de Dinamo DB y disculpen.
P Entonces Lander los leerá y el Servicio Lander invocará esas funciones lambda en función de lo que hay en esas secuencias
o en eso.
Q.
Por defecto, un país de funciones no puede conectarse a ningún recurso dentro de una subred privada en su VPC.
Y la razón es porque su VPC es su propio espacio privado dentro de la nube y el servicio LAMDA no va
a operar dentro de su espacio privado en la nube.
Opera en los Estados Unidos VPC.
Entonces, lo que debemos hacer es asociar esa VPC con nuestra tierra para funcionar y luego con la tierra.
Un servicio creará interfaces de red dentro de nuestras subredes privadas que permitirán que esas funciones LAMDA se conecten
a subredes privadas o recursos dentro de una subred privada.
Ahora, porque se están creando interfaces de red.
Se requiere un papel.
Entonces, Alanda, el servicio requerirá un rol de ejecución para crear interfaces de red.
Entonces, la forma en que lo hacemos es que en la tierra de la consola, asociamos una VPC, las subredes y también los
grupos de seguridad con la tierra, la función.
Así que vamos a la tierra, la consola, editamos esa tierra de la función.
Nos desplazamos hacia abajo hasta VPC y definimos VPC personalizado.
Una vez hecho esto y toma un poco de tiempo, el servicio que atravesará el servicio creará
esa red o una interfaz de red para permitir el acceso dentro de esa subred privada.
También podemos usar la interfaz de línea de comando o uno de los muchos kits de desarrollo
de software y el comando hay tierra para crear la función o la configuración de la función de actualización lamda si es una función lamda existente.
Y luego solo necesitamos definir con la configuración de VPC las ID de subred de nuestras subredes privadas y también cualquier ID
de grupo de seguridad.
También podemos hacerlo con la formación de la nube o el modelo de aplicación sin servidor, y solo
ingresamos a las propiedades de la función y definimos la configuración de VPC y nuevamente, definimos esas ID de subred para las
subredes privadas y las ID de los grupos de seguridad.
Bien, aquí podemos ver cómo funciona todo, así que tenemos la nube y tenemos a
nuestros clientes, nuestro VPC y Aiwass, que tienen su tierra Aiwass, el VPC.
Entonces no somos dueños de eso.
Así que ese es nuestro VPC, nuestro cliente.
Nuestro VPC está en el lado derecho y el VPC está en el lado izquierdo.
Y así, nuestras funciones de aterrizaje se encuentran dentro de esa VPC de Atabay.
Entonces crearemos una instancia de red o servicio de red de VPC a VPC.
Y así se conectará a una interfaz de red elástica que el servicio de aterrizaje creará dentro de
nuestra VPC.
Y eso permitirá que nuestras funciones de lander accedan a recursos dentro de esas subredes privadas.
Por defecto, su país de funciones tampoco puede conectarse a Internet.
Entonces, lo que debemos hacer es que necesitamos tener una VPC con una subred pública y al ser una subred pública, va a tener
una ruta a una puerta de enlace de Internet.
Y debemos permitir que nuestra función acceda a Internet a través de esa subred pública.
Y lo hace nuevamente creando una interfaz de red dentro de esa subred pública.
Por lo tanto, requerimos que nuestra tierra, un servicio, tenga un rol de ejecución, para crear interfaces de red.
Entonces, cuando estamos creando nuestra función, necesitamos definir ese rol de ejecución que tendrá esos permisos
para crear esas interfaces de red.
Luego tenemos una subred pública y luego nuestra subred pública también debe tener una puerta de enlace de red o un instante de red dentro
de ella.
Y eso permitirá ese tráfico saliente.
Una vez que hayamos hecho eso, podemos asociar esa VPC y esa subred pública a esa función de manera
similar a como asociamos nuestras subredes privadas también, y lo hacemos nuevamente usando la consola de aterrizaje,
usando Seelie, todo el SDK o también usando la formación en la nube o el modelo de aplicación de servicio.
Como sabemos por nuestra discusión sobre el contexto de ejecución, las conexiones de bases de datos que deben inicializarse pueden
aumentar nuestras funciones, la latencia de la información, lo que no es bueno.
Entonces, lo que debemos hacer es asegurarnos de que nuestras conexiones estén definidas fuera de nuestro controlador
de funciones.
Y eso permitirá que se reutilicen después de que nuestra función finalice.
Ahora, incluso mejor que eso, podemos usar el servicio proxy de anuncios de Amazon si estamos usando A. RE. s instancias o el
servicio de audio.
Y lo que hará es mantener conexiones para conexiones a ese servicio y tendrá un
único punto final para eso.
Por lo tanto, debemos tener un rol de ejecución para nuestra tierra, una función que debe tener acceso a esa instancia de la
base de datos o al servicio proxy del SIDA que hemos establecido.
Y para que el rol de ejecución se pueda usar para autenticar con el servicio proxy de SIDA en lugar de tener que usar
un nombre de usuario y contraseña.
Y eso, de nuevo, va a reducir nuestra latencia.
Podemos saltar directamente a ese rol de ejecución y comenzar a usar esa base de datos inmediatamente sin
tener que pasar y proporcionar ese nombre de usuario y contraseña.
Si tenemos una gran cantidad de archivos a los que debe acceder nuestra tierra de funciones, podemos conectar nuestra
tierra.
Las funciones para el sistema de archivos elástico y el sistema de archivos AFS se pueden montar en nuestro directorio local
de funciones.
Y puede usar eso de la misma manera que usa su carpeta temporal, pero lo usará como almacenamiento permanente y
ese almacenamiento permanente también se usará y estará disponible para todas sus funciones.
Entonces, la forma en que hacemos eso es que podemos usar la tierra, la consola y luego agregar el
sistema de archivos o seleccionar el volumen HFS y luego definimos la ruta de montaña local y eso comenzará con MENTI.
Y luego definirás esa ruta de mapa local, lo que será.
Y así, desde allí, su tierra, la función puede acceder a esos archivos a través de ese camino de montaña
local.
O podemos usar un Seelie o los kits de desarrollo de software y el comando there is land para
crear la función para una nueva función o la configuración de la función de actualización de land para una función existente.
Y luego simplemente hacemos el sistema de archivos, configuramos y definimos ese sistema de archivos elástico allí.
O podemos usar la formación en la nube o estos modelos de aplicación sin servidor y definir en nuestra plantilla nuestras
funciones.
Propiedades, defina la configuración del sistema de archivos y luego defina nuevamente ese sistema de archivos elástico.
La concurrencia es esa cantidad de solicitudes que su función está atendiendo en un momento dado, y que está sujeta a
un límite regional que comparten todas sus funciones.
Por lo tanto, no es posible tener un millón de invocaciones concurrentes de sus funciones.
Está sujeto a un límite regional.
Lo que puede hacer si tiene funciones críticas que desea asegurarse de tener un
alto nivel de concurrencia disponible, puede definir una concurrencia reservada y eso asegurará que esa función siempre
pueda alcanzar un cierto nivel de concurrencia.
Pero sus otras funciones, no pueden usar esa concurrencia de reserva que ha asignado a esa
función.
Si descubre que tiene un cierto período de tiempo para el que desea aprovisionar una cierta cantidad
de concurrencia, puede usar la concurrencia aprovisionada.
Y eso le permite asignar un nivel de concurrencia antes de que haya un aumento en las indicaciones de un
aumento en la demanda.
Y eso asegurará que esas solicitudes sean atendidas por instancias inicializadas.
Por lo tanto, no solo se asegurará de que la concurrencia esté disponible, se asegurará de que esas
instancias estén inicializadas y listas para funcionar.
También podemos utilizar el servicio de escalado automático de la aplicación Edwards para administrar esta concurrencia de provisión.
Así que asegurándonos de que tenemos instancias inicializadas disponibles y que podemos hacerlo según un cronograma, o podemos hacerlo
según la demanda, según la utilización de la misma manera que lo hacemos con él.
Con un grupo de escalado automático EC2, podemos tener esto, podemos tener esta provisión en moneda cruzada
de estas instancias o invocaciones aprovisionadas, auto escalado automático para nosotros.
Pero, por supuesto, también debe tener en cuenta que puede ser más barato usar un grupo EC2 de escala automática
en lugar de usar tierra porque está pagando por la conveniencia de un servicio Cervalis.
Así que asegúrate de hacer las pruebas y asegúrate de que no hay ningún costo para ti por usar
este gran servicio de tener estos geniales listos para usar, escalar dentro y fuera, usar la aplicación, escalar
automáticamente.
Cuando crea una tierra, una función y define su configuración, la tierra, un
servicio asignará la C. pags. U poder de esa función linealmente en proporción a la cantidad de memoria que ha configurado.
Lo que eso significa es que no puedes cambiar directamente la C. pags. U poder de una función lambda.
Lo que puede hacer es aumentar significativamente la memoria de esa función y eso
aumentará la potencia de la CPU en 1792.
Para realizar una función tiene el equivalente de un VCP completo.
Entonces, si duplica la memoria, eso permitirá el uso de cuatro a cuatro VCP.
Por lo tanto, configurar la memoria para una función lambda establece implícitamente no solo la C. pags. U poder pero también el poder
de la red o la conectividad de red y también algunos otros recursos también.
Entonces, la memoria es lo principal que define.
Si descubre que su función no puede manejar su código, aumente la memoria de esa función.
El campo de funciones se puede utilizar como objetivo para una aplicación de bajo balanceador, y eso tiene una serie
de ventajas significativas.
Permite que la aplicación reciba solicitudes de Internet, saldos bajos, punto final único.
También le permite crear reglas de equilibrador de carga para redondear esas solicitudes HTTP a una función específica basada
en una ruta o en valores dentro del encabezado de esa solicitud.
Y eso es muy importante porque podría tener una tierra, una función para el comercio electrónico, una tierra de
función para el procesamiento de imágenes, y puede definir los recursos exactos para los que desea hacerlo.
También podría tener esas funciones críticas, tener un mayor nivel de concurrencia disponible para otras funciones que
no son tan críticas y asegurarse de que esas solicitudes vayan a las ubicaciones
correctas de esas funciones críticas.
Ahora, el ALB, invoca esas funciones sincrónicamente con un evento que contiene el cuerpo de la solicitud y
cualquier metadato con esa solicitud.
Por defecto, Lander monitorea sus funciones y envía métricas para esas funciones a la nube, ¿qué
servicio?
Y puede ver esos gráficos de monitoreo de esas métricas en la consola del módulo de aterrizaje.
OK, en el tablero aquí, tenemos que podemos ver las invocaciones que serán el número de indicaciones en
ese momento.
Entonces, si hay 20 invocaciones de una función que aparecerán allí, la duración de
esa invocación duró los errores y la tasa de éxito, el número de veces que la función necesitaba ser
acelerada debido a demasiadas solicitudes, también tenemos La edad del iterador.
Lo que es eso es que cuando usamos el servicio lambda con una transmisión o con una cola de EE. UU., Será la
edad desde que ese registro ingresó a la transmisión para ganar la tierra, se invocó la función.
Y eso variará dependiendo de qué tan grande sea y sea esa transmisión.
También tenemos errores de letra muerta.
Entonces, esos serán errores o serán solicitudes que no podrían ser atendidas por la tierra, la función, y
entrarán en una letra muerta.
Q.
Las métricas que se envían a la nube, qué servicio después de que su función ha procesado
un evento, se pueden dividir en tres tipos principales: métricas de invocación, rendimiento o concurrencia.
El primero, hay indicaciones, una serie de invocaciones de nuestra función que
tenemos en ese momento, los errores en ese momento, la cantidad de veces que la
función necesitaba ser estrangulada, tenemos la provisión, concurrencia invocaciones
¿Cuántas de esas invocaciones son sobre concurrencia previa?
¿Cuántos de ellos son de propagación de concurrencia aprovisionada a invocaciones estándar?
O también tenemos asíncronos como puramente para indicaciones asíncronas y son los errores de letra muerta.
Entonces, cuando un evento no se pudo entregar y tampoco se pudo ingresar la letra muerta.
Q también.
Y también tenemos fallas en la entrega del destino donde ese evento tampoco se pudo entregar.
También teníamos allí que las métricas de rendimiento eran la duración de la invocación y la edad del
iterador.
Entonces, cuando estamos usando una secuencia o una A Q, la edad de ese registro desde el momento en que ingresó esa secuencia
hasta el momento en que un servicio invoca esa función y las métricas de concurrencia.
Entonces, las ejecuciones concurrentes de esa función, la provisión de ejecución concurrente de cuántos de ellos
son concurrencia aprovisionada y la utilización de concurrencia de provisión, cuánto estamos utilizando esa
disposición.
Concurrencia y nuestra ejecución de concurrencia sin reservas.
Entonces, ¿cuántos de ellos están operando con concurrencia sin reservas?
Cuando crea una función lamda, la tierra, el servicio crea automáticamente un grupo de registro de observación de la nube para
esa función de aterrizaje y cada vez que se invoca esa función, creará una secuencia de registro para cada
una de esas invocaciones de esa tierra de función .
Y cuando esa tierra, se invoca la función, su tiempo de ejecución enviará detalles sobre cada una de esas
invocaciones a esa secuencia de registro específica.
Ahora, también podemos aprovechar este registro de observación en la nube en esta secuencia de registro enviando detalles sobre lo que está ocurriendo
en nuestro código para que podamos enviar un comando que pueda enviar un mensaje a esa secuencia de registro.
La forma en que lo hacemos es en donde un código de función que se envía a la consola se enviará a los registros
de vigilancia de Callao porque nuestra tierra, el servicio no tiene una pantalla de consola, por lo que se envía directamente a
nuestro registro de vigilancia en la nube.
Entonces, la forma en que lo hacemos es usar el comando de registro de consola no Ge'ez o el comando de impresión
en Python, y eso enviará ese mensaje.
Lo que esté en ese comando de registro de consola o el comando DNAPrint irá directamente a esa secuencia de registro.
Si queremos monitorear el acceso a la tierra, al servicio y nuestra tierra de funciones, podemos usar el servicio de seguimiento de
la nube para hacerlo.
Y Cloud Trail capturará todas las llamadas API realizadas a LAMDA desde la consola, desde la interfaz de línea de comandos o desde
uno de los muchos kits de desarrollo de software.
Y lo almacenará en un registro de viaje en la nube.
Y eso, en cada una de esas entradas, tendrá la dirección IP de ese usuario.
Tendrá el Amusa o la función que se utilizó para acceder a Landen y también la marca de tiempo de su llamada
API.
Entonces, si una prueba está habilitada, todos los eventos se guardarán en Amazon S3 si no ha habilitado una
prueba.
Aún puede ver los eventos más recientes en el historial de eventos de registro de la consola de prueba en la nube.
Eso nos lleva al final de una discusión bastante detallada sobre la tierra, un servicio.
Y es un gran servicio y muy divertido para tener en tus manos.
Entonces, a continuación, vamos a tener algunos laboratorios en Lander, y espero que los disfruten.
Y espero verte en los próximos.