Pourquoi une entreprise a besoin d'un jumeau, et comment Mithril en fournit un
La production est le mauvais endroit pour apprendre qui peut atteindre un système sensible, à quoi ressemble un refus, ou si le cluster en cours d'exécution correspond à celui qui a été déclaré. Un jumeau conserve ces noms et n'applique pas le résultat. Mithril fait de ce jumeau un document : les composants en domaine inversé se composent, une exécution renvoie la réponse et la décision, et un cluster est vérifié par rapport à l'observation sans être démarré.
Cet article a été traduit par une machine.
Une entreprise a besoin d'un jumeau parce que les questions qui comptent ne peuvent pas être posées en production. Qui peut atteindre un système qui détient des données de clients. À quoi ressemble un appel refusé lorsqu'un quota est épuisé. Si le cluster qui s'exécute aujourd'hui est le cluster qui a été déclaré. La production est l'endroit où les clients, les paiements et l'identité vivent déjà. L'utiliser comme lieu pour apprendre ces réponses associe la curiosité à une interruption de service. Geler chaque changement jusqu'à ce qu'un comité soit sûr est l'autre échec : le parc continue de bouger, et le modèle de ce parc ne bouge pas.
Un jumeau est une seconde copie de ce parc, avec les mêmes noms et une règle stricte selon laquelle rien n'est appliqué. Le principal, le bucket, la file d'attente et le cluster sont assez réels pour répondre à la question. L'effet s'arrête à la copie. La sécurité, la plateforme et l'architecture peuvent répéter une autorisation, un refus, une défaillance et une dérive avant que l'un de ceux-ci n'atteigne le compte qui facture les clients.
Mithril fait du jumeau un document, et non un second cloud. Chaque partie du parc est un composant nommé par son domaine inversé, et les composants se composent. L'identité, l'autorisation, le quota, la cohérence, la défaillance et TLS se situent sous le service qui en a besoin. Une exécution parcourt cette chaîne et renvoie 2 choses que l'appelant peut conserver : la réponse qu'un client verrait, et la décision qui l'a produite. L'indicateur applied reste false. Le runtime n'ouvre aucune socket, et un document qui nomme un hôte actif ou un secret est refusé avant de s'exécuter.
La même frontière couvre le cluster. Docker et Podman sont enveloppés sous la forme d'un document Mithril qui énonce quels services doivent exister et comment ils dépendent les uns des autres. Le rendu de ce document produit le fichier Compose. La vérification compare la déclaration à ce qui est réellement observé. La vérification ne démarre pas de conteneurs. L'entreprise obtient une répétition de son propre parc, à côté des moteurs qui parlent déjà les protocoles du cloud, avec une trace de ce qui a été décidé et de ce qui n'a délibérément pas été appliqué.