[Préface] En tant que premier modèle d'architecture et de définition standard d'applications natives du cloud, le concept central d'OAM (Open Application Model) est le suivant: "centré sur l'application", qui met l'accent sur la R & D et le fonctionnement et la maintenance autour d'un ensemble de déclarations déclaratives et flexibles Les abstractions étendues de niveau supérieur collaborent au lieu d'utiliser directement des API de couche d'infrastructure complexes et obscures. Récemment, l'équipe AWS ECS a publié un projet open source appelé Amazon ECS pour Open Application Model sur le GitHub officiel. De plus en plus de fabricants ont commencé à explorer la pratique de l'OAM. Quel est le charme d'OAM, de sorte que plusieurs fournisseurs de cloud peuvent s'unir et s'embrasser?
Auteur | Zhang Lei, expert technique principal de la plate-forme d'application native d'Alibaba Cloud
Deng Hongchao, expert technique d'Alibaba Cloud
Rédacteur en chef | Tang Xiaoyin
头图 | Téléchargement CSDN depuis Oriental IC
Vente | CSDN (ID: CSDNnews)
Le mot sans serveur a été utilisé pour la première fois dans un article de 2012 intitulé «Pourquoi l'avenir des logiciels et des applications est sans serveur». Cependant, si vous allez vraiment à l'archéologie, vous constaterez que le contenu de cet article est en fait le concept d'ingénierie logicielle d'intégration continue et de contrôle de version de code. Parlons de «l'échelle à zéro» et du «paiement» mentionnés par Serverless aujourd'hui. comme vous allez ", FaaS / BaaS, ces choses ne sont pas du tout une chose.
En 2014, AWS a lancé un produit appelé "Lambda". Le concept de conception de ce produit est très simple: il estime que le cloud computing est en fin de compte orienté pour fournir des services aux applications, et lorsque les utilisateurs souhaitent déployer une application, il n'a besoin que d'un endroit pour écrire leurs propres programmes pour effectuer des tâches spécifiques sans souci. Sur quelle machine ou sur quelle machine virtuelle ce programme s'exécute.
C'est la sortie de Lambda qui a amené le paradigme "Serverless" à un tout nouveau niveau. Serverless fournit une toute nouvelle architecture système pour déployer et exécuter des applications dans le cloud, en soulignant que les utilisateurs n'ont pas besoin de se soucier des configurations de serveur complexes, mais seulement de se soucier de leur propre code et de la façon de regrouper le code dans une plate-forme de cloud computing pouvant être hébergée " Entité opérationnelle ". Après une série de fonctionnalités classiques telles que la mise à l'échelle des instances d'application en fonction du trafic réel et de la facturation en fonction de l'utilisation réelle plutôt que des ressources préallouées, AWS a progressivement établi la norme de facto dans le domaine des serveurs sans serveur.
En 2017, AWS a lancé le service Fargate, qui a étendu le concept de serveur sans serveur aux entités exécutables basées sur des conteneurs. Bientôt, cette idée a également été suivie par Google Cloud Run, etc., et a ouvert le runtime sans serveur basé sur des conteneurs de «nouvelle génération». Boom.
Sans serveur 与 Open Application Model (OAM)？
Alors, qu'est-ce que OAM a à voir avec AWS et sans serveur?
Tout d'abord, l'Open Application Model (OAM) est un ensemble de spécifications de description d'application (spec) lancées conjointement par Alibaba Cloud et Microsoft, et maintenues conjointement par la communauté native du cloud. Le concept de base de l'OAM est: "centré sur l'application", qui souligne que la R & D et l'exploitation et la maintenance sont coordonnées autour d'un ensemble d'abstractions de niveau supérieur déclaratives, flexibles et extensibles, plutôt que d'utiliser directement des API de couche d'infrastructure complexes et obscures.
Par exemple, pour une application basée sur un conteneur qui utilise HPA K8 pour l'expansion horizontale, elle sera définie par les deux fichiers YAML suivants sous la spécification OAM:
# 研发负责编写这个 YAML 文件
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:latest
---
# 运维（或者 PaaS 平台）负责编写这个 YAML 文件
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: 10Une fois un tel fichier YAML soumis à K8, il sera automatiquement traduit en un objet Déploiement et HPA complet par le plug-in OAM et exécuté. On peut voir que sous la spécification OAM, la R & D et le fonctionnement et la maintenance sont complètement séparés. La R & D n'a qu'à écrire un très petit nombre de champs liés à vous-même, et n'a pas besoin d'apprendre l'API complète des K8. Définition et publication de l'application.
Étant donné qu'OAM réglemente une série de normes de définition de livraison d'applications natives dans le cloud telles que "application", "capacités d'exploitation et de maintenance" et "limite de publication", les développeurs de la plateforme de gestion des applications peuvent utiliser cette spécification pour décrire chacun d'eux à travers un fichier YAML plus concis. Diverses applications et stratégies d'exploitation et de maintenance, et enfin via le plug-in OAM pour mapper ces fichiers YAML avec les ressources réelles des K8 (y compris CRD).
En d'autres termes, OAM fournit une norme de facto pour définir «abstraction supérieure», et le rôle le plus important de cette «abstraction supérieure» est d'empêcher divers détails d'infrastructure (tels que HPA, Ingress, conteneurs, Pod, Service) Etc.) Fuite aux camarades de classe de R & D, causant une complexité inutile. Par conséquent, une fois que l'OAM est sorti, il est appelé "arme d'arme" pour développer la plate-forme d'application K8s.
Mais plus important encore, cette idée de "supprimer les détails de la couche d'infrastructure et de fournir l'abstraction de niveau supérieur la plus conviviale pour les développeurs" de la description de l'application coïncide avec le concept sans serveur de "de-infrastructure". Plus précisément, OAM est intrinsèquement sans serveur .
Pour cette raison, une fois OAM sorti, il a reçu une attention considérable dans le domaine du serveur sans serveur. Parmi eux, bien sûr, AWS est également indispensable.
L'expérience ultime: AWS ECS pour OAM
Fin mars 2020, l'équipe AWS ECS a publié un projet open source appelé Amazon ECS pour Open Application Model sur GitHub officiel.
Adresse du projet: https://github.com/awslabs/amazon-ecs-for-open-application-model
Ce projet est une tentative de l'équipe AWS de prendre en charge OAM sur la base du service sans serveur. Le runtime sous-jacent de ce projet est le service de conteneur sans serveur que nous avons mentionné précédemment: Fargate. Et l'expérience que ce projet AWS ECS pour OAM apporte aux développeurs est très intéressante, jetons un coup d'œil.
Le travail préparatoire se déroule en trois étapes.
L'utilisateur doit disposer des informations d'authentification du compte AWS localement, qui peuvent être générées en un seul clic via la commande aws configure du client officiel AWS.
Compilez le projet, puis vous pouvez obtenir un fichier exécutable appelé oam-ecs.
Vous devez exécuter la commande oam-ecs env pour préparer l'environnement pour votre déploiement ultérieur. Une fois cette commande terminée, AWS créera automatiquement un VPC et un sous-réseau public / privé correspondant pour vous.
Une fois la préparation terminée, il vous suffit de définir un fichier YAML d'application OAM localement (tel que l'exemple d'application helloworld mentionné ci-dessus). Ensuite, vous pouvez placer une application complète avec HPA dans Fargate via la commande d'une ligne suivante Il est déployé sur Internet et accessible directement sur le réseau public:
oam-ecs app deploy -f helloworld-app.yamlC'est très simple?
Dans la documentation officielle du projet AWS ECS pour OAM, il donne un exemple plus compliqué, expliquons-le.
L'application que nous voulons déployer cette fois se compose de trois fichiers YAML, qui sont toujours divisés en deux préoccupations: R&D et exploitation et maintenance:
R & D est responsable de la rédaction:
server-component.yaml
Le contenu de ce fichier est le premier composant de l'application et il décrit le conteneur d'application que nous voulons déployer.
worker-component.yaml
Le deuxième composant de l'application de contenu de ce fichier décrit spécifiquement un travail de boucle chargé de vérifier si le réseau dans l'environnement actuel n'est pas obstrué.
L'exploitation et la maintenance sont responsables de la rédaction:
exemple-app.yaml
Le contenu de ce fichier est la topologie complète des composants de l'application et les caractéristiques de fonctionnement et de maintenance de chaque composant. Il décrit spécifiquement une stratégie de fonctionnement et de maintenance "de mise à l'échelle manuelle", qui est spécifiquement utilisée pour développer le composant de travail.
Par conséquent, l'exemple-app.yaml ci-dessus, qui est la description complète de l'application, est le suivant:
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: EveryoneComme vous pouvez le voir, il définit deux composants (worker-v1 et server-v1), et le composant worker-v1 a une stratégie d'expansion manuelle appelée manual-scaler.
Les trois fichiers YAML de cette démo peuvent être consultés dans ce répertoire:
https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples
Cependant, le déploiement des applications complexes ci-dessus reste une commande, très simple:
oam-ecs app deploy \
-f examples/example-app.yaml \
-f examples/worker-component.yaml \
-f examples/server-component.yamlUne fois les instructions ci-dessus exécutées (les étudiants en Chine peuvent avoir besoin d'un peu de patience en raison de problèmes de réseau particuliers), vous pouvez afficher les informations d'accès à l'application et le nom DNS via la commande show app oam-ecs. Ouvrez le navigateur et entrez les informations d'accès, vous pouvez accéder directement à l'application, comme indiqué ci-dessous:
Si vous souhaitez modifier la configuration de l'application, comme la mise à jour de l'image ou la modification de la valeur de replicaCount, il vous suffit de modifier le fichier YAML ci-dessus, puis de le déployer à nouveau, ce qui constitue une gestion entièrement déclarative.
En fait, si les opérations ci-dessus sont effectuées via la console AWS, au moins 5 pages de produits cloud doivent être reliées les unes aux autres pour différentes configurations; ou, vous devez apprendre la syntaxe CloudFormation et écrire un CF très, très long Fichier, afin de récupérer toutes les ressources nécessaires à l'application pour exécuter l'instance Fargate, LoadBalancer, le réseau, la configuration DNS, etc.
Cependant, grâce à la spécification OAM, la définition et le déploiement susmentionnés du processus d'application sont non seulement devenus extrêmement simples, mais ils ont également converti directement le processus d'origine des opérations de service cloud en un fichier YAML déclaratif plus concis et convivial. Le travail spécifique requis pour implémenter la spécification OAM ici n'est en fait que de quelques centaines de lignes de code.
Plus important encore, lorsqu'un service sans serveur comme AWS Fargate est combiné avec une définition d'application conviviale pour les développeurs comme OAM, vous vous sentirez vraiment: il s'avère que cette charge mentale simple, rafraîchissante et extrêmement faible est sans serveur L'expérience ultime pour les développeurs.
Enfin: quand le modèle d'application rencontre Serverless
Le modèle OAM a eu d'énormes répercussions sur l'écosystème de livraison d'applications natives du cloud. À l'heure actuelle, le service EDAS d'Alibaba Cloud est devenu la première plate-forme de gestion des applications au niveau de la production basée sur OAM, et lance bientôt l'expérience produit de nouvelle génération "centrée sur les applications"; dans la communauté CNCF, bien connue Le projet de plate-forme de livraison Crossplane est également devenu un important adoptant et mainteneur de la spécification OAM.
Site officiel EDAS: https://help.aliyun.com/product/29500.html
Crossplane: https: //github.com/crossplane/crossplane
En fait, non seulement AWS Fargate, tous les services sans serveur de notre écosystème de cloud computing peuvent facilement utiliser OAM comme couche de présentation orientée développeur et définition d'application, simplifiant et résumant ainsi l'API d'infrastructure complexe d'origine, Mise à niveau «en un clic» de l'opération de processus complexe d'origine vers la gestion déclarative des applications de style Kubernetes.
Plus important encore, grâce à la grande évolutivité d'OAM, vous pouvez non seulement déployer des applications de conteneur sur Fargate, vous pouvez également utiliser OAM pour décrire Function, machine virtuelle, WebAssembly et même tout type de charge de travail auquel vous pouvez penser. Ils sont facilement déployés sur des services sans serveur et migrent même de manière transparente entre différents services cloud. Ces capacités apparemment «magiques» sont toutes des étincelles d'innovation qui peuvent entrer en collision lorsqu'un «modèle d'application» normalisé et extensible rencontre une plate-forme sans serveur.
Le modèle d'application + Serverless est progressivement devenu l'un des sujets les plus chauds de l'écologie native du cloud. Vous êtes invités à rejoindre le groupe de livraison d'applications natives du cloud CNCF (SIG App Delivery) pour promouvoir l'écosystème du cloud computing vers "centré sur l'application" Continuez d'avancer!
Projet AWS ECS sur OAM: https://github.com/awslabs/amazon-ecs-for-open-application-model/
Projet de modèle d'application ouvert: https://github.com/oam-dev/spec
Livraison de l'application CNCF SIG: https: //github.com/cncf/sig-app-delivery
À propos de l'auteur:
Zhang Lei, expert technique principal de la plate-forme d'application native d'Alibaba Cloud, ambassadeur de la CNCF en Chine, président de la CNCF Application Delivery Sig.
Deng Hongchao, expert technique d'Alibaba Cloud et l'un des auteurs originaux du mécanisme Kubernetes Operator, a plus de recherches et d'expérience sur le système de gestion des applications K8s.
【FIN】
Les avantages d'aujourd'hui
Rencontrez Lu Qi
Également un élément important de «Un million de personnes apprennent l'IA», la conférence Ten Thousand Developer 2020 d'AIProCon sera diffusée en ligne du 3 au 4 juillet, permettant aux développeurs de se familiariser avec la technologie de pointe de l'IA en un seul arrêt. Recherche, technologie et application de base, et expérience pratique des cas d'entreprise, et peut également participer à des salons de développeurs passionnants et diversifiés et à des projets de programmation en ligne. En participant à la série d'activités prospectives et à l'interaction de diffusion en direct en ligne, vous pouvez non seulement communiquer avec des dizaines de milliers de développeurs, mais aussi avoir la possibilité de gagner des cadeaux exclusifs pour des diffusions en direct et même de rejoindre le géant de la technologie.
Les billets sont limités au grand spectacle! À partir d'aujourd'hui, cliquez pour lire l'inscription originale "2020 AI Developer Ten Thousand Conference", utilisez le code promo "AIP211", vous pouvez obtenir un billet de conférence en ligne gratuit d'une valeur de 299 yuans. Limité à 100 feuilles, premier arrivé, premier servi! Venez utiliser votre doigt pour devenir membre gratuitement!
Cliquez pour lire le texte original et allez directement sur le site officiel de la conférence.
