Utilisez Ansible pour automatiser le déploiement d'applications sans serveur

Présentation

Ansible est conçu pour être l'outil de déploiement le plus simple qui fonctionne réellement. Cela signifie que ce n'est pas un langage de programmation complet. Vous devez écrire un modèle YAML qui définit les tâches et répertorie toutes les tâches qui doivent être automatisées.

La plupart des gens considèrent Ansible comme un « SSH dans une boucle for » plus puissant, et dans des cas d'utilisation simples, cela est vrai. Mais en fait, Ansible est une tâche, pas SSH. Dans de nombreux cas, nous nous connectons via SSH, mais il prend également en charge des éléments tels que la gestion à distance de Windows (WinRM) sur les machines Windows et l'API HTTPS en tant que langage commun pour les services cloud.

Dans le cloud, Ansible peut fonctionner sur deux niveaux indépendants : le plan de contrôle et les ressources de l'instance. Le plan de contrôle comprend tout ce qui ne s'exécute pas sur le système d'exploitation. Cela inclut la configuration de votre réseau, la création de nouvelles instances, la fourniture de services de niveau supérieur comme S3 d'Amazon ou DynamoDB, et tout ce dont vous avez besoin pour assurer la sécurité de votre infrastructure cloud et servir vos clients.

Travailler sur l'instance est ce que vous savez déjà qu'Ansible peut faire : démarrer et arrêter des services, créer des modèles de fichiers de configuration, installer des packages et toutes les opérations liées au système d'exploitation via SSH.

Maintenant, qu'est-ce qui est sans service ? Selon la personne à qui vous le demandez, le sans serveur est soit une extension infinie du cloud public, soit un tout nouveau paradigme où tout repose sur des appels API et n'a jamais été fait auparavant.

Ansible prend le premier point de vue. Avant que « sans service » ne soit un terme technique, les utilisateurs devaient gérer et configurer les instances EC2, les réseaux de cloud privé virtuel (VPC) et tout le reste. Le serviceless est une autre étape vers les services gérés et fonctionne bien avec l'architecture sans agent d'Ansible.

Avant de commencer l'exemple Lambda, examinons une tâche de configuration simple de la pile CloudFormation :

- name: Build network
cloudformation:
stack_name: prod-vpc
state: present
template: base_vpc.yml

Écrire une tâche comme celle-ci ne prend que quelques minutes, mais il s'agit de la dernière étape semi-manuelle impliquée dans la construction de l'infrastructure - cliquez sur "Créer une pile" - cela met le playbook avec les autres. Désormais, votre VPC n'est qu'une autre tâche à laquelle faire appel lors de la configuration d'une nouvelle région.

Étant donné que le fournisseur de cloud est la source de vérité sur ce qui se passe dans votre compte, Ansible dispose de nombreuses façons de récupérer, filtrer et interroger les instances ou les réseaux en cours d'exécution à l'aide d'identifiants, de noms et d'autres paramètres. En prenant le module cloudformation_facts comme exemple, nous pouvons obtenir l'ID de sous-réseau, la plage réseau et d'autres données à partir du modèle que nous venons de créer.

- name: Pull all new resources back in as a variable
cloudformation_facts:
stack_name: prod-vpc
register: network_stack

Pour les applications sans serveur, vous aurez certainement besoin d'une fonction Lambda en plus des tables DynamoDB, des buckets S3 et de tout le reste. Heureusement, en utilisant le module lambda, une fonction Lambda peut être créée de la même manière que la pile de la tâche précédente :

- lambda:
name: sendReportMail
zip_file: "{{ deployment_package }}"
runtime: python3.6
handler: report.send
memory_size: 1024
role: "{{ iam_exec_role }}"
register: new_function

Si vous disposez d'autres outils que vous souhaitez utiliser pour fournir des applications sans serveur, cela est également possible. Le framework open source sans serveur possède son propre module Ansible qui fonctionne également :

- serverless:
service_path: '{{ project_dir }}'
stage: dev
register: sls
- name: Serverless uses CloudFormation under the hood, so you can easily pull info back into Ansible
cloudformation_facts:
stack_name: "{{ sls.service_name }}"
register: sls_facts

Ce n'est pas tout ce dont vous avez besoin, car le projet sans serveur doit également exister et vous y définirez fortement vos fonctions et sources d'événements. Pour cet exemple, nous allons créer une fonction qui répond aux requêtes HTTP. Les frameworks sans service utilisent YAML comme langage de configuration (comme Ansible), cela devrait donc vous sembler familier.

# serverless.yml
service: fakeservice
provider:
name: aws
runtime: python3.6
functions:
main:
handler: test_function.handler
events:
- http:
path: /
method: get

À AnsibleFest, je couvrirai cet exemple et d'autres stratégies de déploiement approfondies pour maximiser l'utilisation des playbooks et de l'infrastructure dont vous disposez déjà, ainsi que les nouvelles pratiques sans serveur. Que vous puissiez y arriver ou non, j'espère que ces exemples pourront vous aider à commencer à utiliser Ansible, que vous ayez ou non des services à gérer.

AnsibleFest est une conférence d'une journée qui rassemble des centaines d'utilisateurs, de développeurs et de partenaires industriels d'Ansible. Rejoignez-nous pour des mises à jour de produits, des conversations inspirantes, des analyses techniques approfondies, des démonstrations pratiques et une journée complète de réseautage.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!