Autor | Zhang Lei Deng Hongchao
Introducción: Recientemente, el equipo de AWS ECS lanzó un proyecto de código abierto llamado Amazon ECS para Open Application Model en GitHub oficial. Cada vez más fabricantes comenzaron a explorar la práctica de OAM. ¿Cuál es el encanto de OAM, dejar que múltiples proveedores de la nube se unan para abrazar?
Sin servidor 与 AWS
La palabra Serverless se usó por primera vez en un artículo de 2012 llamado "Por qué el futuro del software y las aplicaciones es sin servidor". Sin embargo, si realmente va a la arqueología, encontrará que el contenido de este artículo es en realidad el concepto de ingeniería de software de integración continua y control de versiones de código. Hablemos de la "escala a cero" y "pago" que menciona hoy Serverless. sobre la marcha ", FaaS / BaaS, estas cosas no son una cosa en absoluto.
En 2014, AWS lanzó un producto llamado Lambda. El concepto de diseño de este producto es muy simple: cree que la computación en la nube en última instancia proporciona servicios para aplicaciones, y cuando los usuarios desean implementar una aplicación, solo necesita un lugar para escribir sus propios programas para realizar tareas específicas, sin tener que preocuparse por esto. En qué máquina o en qué máquina virtual se ejecuta el programa.
Fue el lanzamiento de Lambda lo que llevó el paradigma "Serverless" a un nivel completamente nuevo. Serverless proporciona una arquitectura de sistema completamente nueva para implementar y ejecutar aplicaciones en la nube, enfatizando que los usuarios no necesitan preocuparse por las configuraciones complejas del servidor, solo necesitan preocuparse por su propio código y cómo empaquetar el código en una plataforma de computación en la nube que puede ser alojada por Entidad operacional ". Después de una serie de características clásicas, como el escalado de instancias de aplicaciones basadas en el tráfico real y la facturación basada en el uso real en lugar de los recursos preasignados, AWS ha establecido gradualmente el estándar de facto en el campo de los servidores sin servidor.
En 2017, AWS lanzó el servicio Fargate, que extendió el concepto de sin servidor a entidades ejecutables basadas en contenedores. Pronto esta idea también fue seguida por Google Cloud Run, etc., y abrió el tiempo de ejecución sin servidor basado en contenedores de "próxima generación". Boom
Sin servidor 与 Modelo de aplicación abierta (OAM)？
Entonces, ¿qué tiene que ver el modelo de aplicación abierta (OAM) con AWS y sin servidor?
En primer lugar, OAM (Open Application Model) es un conjunto de especificaciones de descripción de aplicaciones (spec) iniciadas conjuntamente por Alibaba Cloud y Microsoft y mantenidas conjuntamente por la comunidad nativa de la nube. El concepto central de OAM es: "centrado en la aplicación", que enfatiza que la I + D y la operación y el mantenimiento trabajan juntos en torno a un conjunto de abstracciones declarativas, flexibles y extensibles de nivel superior, en lugar de utilizar directamente API de capa de infraestructura complejas y oscuras.
Por ejemplo, para una aplicación basada en contenedor que usa K8s HPA para expansión horizontal, se definirá mediante los siguientes dos archivos YAML bajo la especificación OAM.
El archivo YAML preparado por la I + D:
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: web-server
spec:
# 待部署的应用详情
workload:
apiVersion: core.oam.dev/v1alpha2
kind: Server
spec:
containers:
- name: frontend
image: frontend:latestEl archivo YAML escrito por la operación y mantenimiento (o plataforma PaaS):
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: helloworld
spec:
components:
- name: frontend
# 该应用运行所需的运维能力
traits:
- trait:
apiVersion: autoscaling.k8s.io/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: scale-hello
spec:
minReplicas: 1
maxReplicas: 10Se puede ver que según la especificación OAM, el enfoque de I + D y la operación y mantenimiento está completamente separado. La I + D y la operación y mantenimiento solo necesitan escribir un número muy pequeño de campos relacionados con ellos mismos, en lugar de completar la implementación de K8s y los objetos HPA, puede definir y publicar aplicaciones fácilmente. Este es el beneficio que nos brinda la "abstracción superior".
Después de que el archivo YAML como el anterior se envíe a K8, el complemento OAM lo convertirá automáticamente en un objeto de implementación y HPA completo para que se ejecute realmente.
Debido a que OAM regula una serie de estándares de definición de entrega de aplicaciones nativas de la nube, como "aplicación", "capacidades de operación y mantenimiento" y "límite de liberación", los desarrolladores de la plataforma de administración de aplicaciones pueden usar esta especificación para describir cada uno de ellos a través de un archivo YAML más conciso. Diversas aplicaciones y estrategias de operación y mantenimiento, y finalmente a través del complemento OAM para mapear estos archivos YAML con los recursos reales de K8 (incluido CRD).
En otras palabras, OAM proporciona un estándar de facto para definir la "abstracción superior", y el papel más importante de esta "abstracción superior" es evitar diversos detalles de infraestructura (como HPA, Ingress, contenedores, Pod, Servicio) Etc.) Filtrado a los compañeros de clase de I + D, lo que causa una complejidad innecesaria. Por lo tanto, una vez que se lanza el OAM, se llama el "arma arma" para desarrollar la plataforma de aplicación K8.
Pero lo que es más importante, esta idea de "eliminar los detalles de la capa de infraestructura y proporcionar la abstracción de nivel superior más amigable para los desarrolladores" de la descripción de la aplicación coincide con el concepto sin servidor de "desestructuración". Más precisamente, OAM es inherentemente sin servidor.
Debido a esto, una vez que se lanzó OAM, recibió una atención significativa en el campo de los servidores sin servidor. Entre ellos, por supuesto, AWS también es indispensable.
La experiencia definitiva: AWS ECS para OAM
A finales de marzo de 2020, el equipo de AWS ECS lanzó un proyecto de código abierto llamado Amazon ECS para Open Application Model en el GItHub oficial.
Dirección del proyecto: https://github.com/awslabs/amazon-ecs-for-open-application-model
Este proyecto es un intento del equipo de AWS para admitir OAM basado en el servicio sin servidor. El tiempo de ejecución subyacente de este proyecto es el servicio de contenedor sin servidor que mencionamos anteriormente: Fargate. Y la experiencia que este proyecto AWS ECS para OAM brinda a los desarrolladores es muy interesante, echemos un vistazo.
Hay tres pasos para el trabajo preparatorio.
1. El usuario debe tener la información de autenticación de la cuenta de AWS localmente, que se puede generar con un clic a través del comando de configuración aws del cliente oficial de AWS;
2. Compile el proyecto y luego puede obtener un archivo ejecutable llamado oam-ecs;
3. Debe ejecutar el comando oam-ecs env para preparar el entorno para su posterior implementación. Una vez que finalice este comando, AWS creará automáticamente una VPC y la subred pública / privada correspondiente para usted.
Una vez completada la preparación, solo necesita definir un archivo YAML de la aplicación OAM localmente (como el ejemplo de la aplicación helloworld mencionado anteriormente). Luego, puede colocar una aplicación completa con HPA en Fargate a través del siguiente comando de una línea Se implementa en Internet y se puede acceder directamente desde la red pública:
oam-ecs app deploy -f helloworld-app.yaml¿Es muy simple?
En la documentación oficial del proyecto AWS ECS para OAM, da un ejemplo más complicado, expliquemoslo.
La aplicación que queremos implementar esta vez consta de tres archivos YAML, que aún se dividen en dos preocupaciones: I + D y operación y mantenimiento:
1. Investigación y desarrollo.
- server-component.yaml: el contenido de este archivo es el primer componente de la aplicación, que describe el contenedor de la aplicación que queremos implementar;
- worker-component.yaml: el segundo componente de la aplicación de contenido en este archivo, que describe específicamente un trabajo de bucle responsable de verificar si la red del entorno actual no está obstruida.
2. O&M es responsable de escribir
example-app.yaml: el contenido de este archivo es la topología completa del componente de la aplicación y las características (características) de operación y mantenimiento de cada componente. Describe específicamente una estrategia de operación y mantenimiento de "escalador manual", que se utiliza específicamente Para expandir el componente trabajador.
Por lo tanto, el ejemplo-app.yaml anterior, que es la descripción completa de la aplicación, es el siguiente:
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: example-app
spec:
components:
- componentName: worker-v1
instanceName: example-worker
traits:
- name: manual-scaler
properties:
replicaCount: 2
- componentName: server-v1
instanceName: example-server
parameterValues:
- name: WorldValue
value: EveryoneComo puede ver, define dos componentes (trabajador-v1 y servidor-v1), y el componente trabajador-v1 tiene una estrategia de expansión manual llamada manual-scaler.
Los tres archivos YAML en esta demostración se pueden ver en este directorio: https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples
Sin embargo, la implementación de las aplicaciones complejas anteriores sigue siendo un comando, muy simple:
oam-ecs app deploy \
-f examples/example-app.yaml \
-f examples/worker-component.yaml \
-f examples/server-component.yamlDespués de ejecutar las instrucciones anteriores (los estudiantes en China pueden necesitar un poco de paciencia debido a problemas especiales de red), puede ver la información de acceso a la aplicación y el nombre DNS a través del comando show de la aplicación oam-ecs. Abra el navegador e ingrese la información de acceso, puede acceder directamente a la aplicación, como se muestra a continuación:
Si desea modificar la configuración de la aplicación, como actualizar la imagen o modificar el valor de replicaCount, solo necesita modificar el archivo YAML anterior y luego implementarlo nuevamente, lo que es una gestión completamente declarativa.
De hecho, si las operaciones anteriores se realizan a través de la consola de AWS, se deben saltar al menos 5 páginas de productos en la nube para varias configuraciones; o, debe aprender la sintaxis de CloudFormation y escribir un CF muy, muy largo Archivo, para extraer todos los recursos requeridos por la aplicación para ejecutar la instancia de Fargate, LoadBalancer, la red, la configuración de DNS, etc.
Sin embargo, a través de la especificación OAM, la definición y la implementación del proceso de aplicación mencionadas anteriormente no solo se han vuelto extremadamente simples, sino que también convirtieron directamente el proceso original de las operaciones del servicio en la nube en un archivo YAML declarativo más conciso y amigable. El trabajo específico requerido para implementar la especificación OAM aquí es en realidad solo unos pocos cientos de líneas de código.
Más importante aún, cuando un servicio sin servidor como AWS Fargate se combina con una definición de aplicación amigable para el desarrollador como OAM, realmente sentirá: Resulta que esta carga mental simple, refrescante y extremadamente baja es Serverless La mejor experiencia para desarrolladores.
Finalmente: cuando el modelo de aplicación se encuentra con Serverless
El modelo OAM ha causado enormes repercusiones en el ecosistema de entrega de aplicaciones nativas de la nube. En la actualidad, el servicio EDAS de Alibaba Cloud se ha convertido en la primera plataforma de gestión de aplicaciones de nivel de producción de la industria basada en OAM, y pronto lanza la experiencia de producto de próxima generación "centrada en aplicaciones"; en la comunidad CNCF, la conocida gestión de aplicaciones entre nubes y El proyecto Crossplane de la plataforma de entrega también se ha convertido en un importante adoptante y mantenedor de la especificación OAM.
Sitio web oficial de EDAS: https://help.aliyun.com/product/29500.html
Crossplane: https://github.com/crossplane/crossplane
De hecho, no solo AWS Fargate, sino todos los servicios sin servidor en nuestro ecosistema de computación en la nube pueden usar fácilmente OAM como una capa de presentación orientada al desarrollador y definición de aplicación, simplificando y abstrayendo así la compleja API original de infraestructura. La operación de proceso complejo original "un clic" se actualiza a la gestión de aplicaciones declarativas al estilo Kubernetes. Más importante aún, gracias a la alta escalabilidad de OAM, no solo puede implementar aplicaciones de contenedor en Fargate, también puede usar OAM para describir funciones, máquinas virtuales, WebAssembly e incluso cualquier tipo de carga de trabajo que pueda imaginar. Se implementan fácilmente en servicios sin servidor e incluso migran sin problemas entre diferentes servicios en la nube. Estas habilidades aparentemente "mágicas" son todas chispas de innovación que pueden chocar cuando un "modelo de aplicación" estandarizado y extensible se encuentra con una plataforma sin servidor.
El modelo de aplicación + Serverless se ha convertido gradualmente en uno de los temas más candentes en la ecología nativa de la nube. Puede unirse al Grupo de Entrega de Aplicaciones Nativas de la Nube de CNCF (SIG App Delivery) para promover el ecosistema de computación en la nube hacia "centrado en la aplicación" ¡Sigue avanzando!
Proyecto de AWS ECS en OAM: https://github.com/awslabs/amazon-ecs-for-open-application-model/
Proyecto de modelo de aplicación abierta: https://github.com/oam-dev/spec
Entrega de aplicaciones CNCF SIG : Https://github.com/cncf/sig-app-delivery
En la actualidad, las especificaciones y modelos de OAM han resuelto muchos problemas existentes, pero su viaje acaba de comenzar. OAM es un proyecto neutral de código abierto, y damos la bienvenida a más personas para que participen en él para definir conjuntamente el futuro de la entrega de aplicaciones nativas de la nube.
Métodos de participación:
- Ingrese al grupo de discusión chino del proyecto OAM
- Participe directamente en discusiones a través de Gitter
- Dirección de implementación de código abierto de OAM
- Haga clic en estrella
Sobre el autor
Zhang Lei Alibaba Cloud experto técnico superior. Es uno de los encargados del proyecto Kubernetes. Actualmente, Zhang Lei trabaja en el equipo Kubernetes de Ali y sus áreas de trabajo incluyen Kubernetes y sistemas de administración de aplicaciones nativos de la nube.
Deng Hongchao es un experto de Alibaba Cloud Container Platform. Ex ingeniero de CoreOS y uno de los autores principales del proyecto K8s Operator.
" Alibaba Cloud Native se enfoca en microservicios, sin servidor, contenedores, malla de servicio y otros campos técnicos, se enfoca en tendencias de tecnología popular nativa en la nube, prácticas de aterrizaje a gran escala nativas en la nube y es el número público que entiende mejor a los desarrolladores nativos en la nube".
