Amazon Translate : Présentation et traduction en temps réel

L’intelligence artificielle est aujourd’hui largement utilisée pour automatiser des tâches liées au traitement du langage naturel. La traduction automatique en est un bon exemple : les modèles de machine learning permettent de traduire du contenu d’une langue vers une autre tout en prenant en compte le contexte du texte.

Dans cet article, nous allons découvrir Amazon Translate, le service AWS de traduction automatique basé sur le machine learning. Nous verrons ses principaux cas d’usage ainsi que différentes façons de l’utiliser.

Amazon Translate

Amazon Translate est un service de traduction automatique neuronale entièrement managé par AWS. Il s’appuie sur des modèles de machine learning capables de prendre en compte le contexte du texte afin de produire des traductions naturelles et adaptées au sens du contenu source.

Contrairement aux solutions de traduction traditionnelles basées principalement sur des règles linguistiques, Amazon Translate utilise des technologies de deep learning pour améliorer la qualité et la fluidité des traductions.

En tant que service managé, Amazon Translate ne nécessite aucune infrastructure à provisionner ni à maintenir. AWS prend en charge la disponibilité, la scalabilité et l’infrastructure sous-jacente, tandis que les équipes de développement se concentrent sur l’intégration du service dans leurs applications et leurs pipelines.

Amazon Translate prend en charge plusieurs langues et permet de traduire du contenu entre de nombreuses paires linguistiques.

Les deux modes de traduction

Amazon Translate propose deux modes d’utilisation:

• Traduction en temps réel (synchrone) : on envoie un texte et on reçoit la traduction immédiatement. C'est le mode utilisé pour traduire une interface utilisateur, un message de chat, ou un contenu généré dynamiquement.
• Traduction par lot (batch, asynchrone) : on soumet un ou plusieurs documents stockés dans un bucket S3, et Amazon Translate traite le job en arrière-plan avant de déposer les résultats dans un autre emplacement S3. C'est le mode adapté pour traduire de gros volumes de documents (catalogues produits, bases de connaissances, archives).

Cas d'usage typiques

Amazon Translate peut être utilisé dans de nombreux scénarios, comme :

• Applications ou de sites web multilingues
• Traduction de tickets de support client en temps réel
• Traduction de documents internes (contrats, rapports) avec prise en charge de différents formats de fichiers
• Sous-titrage ou traduction de contenus générés par d'autres services AWS (Amazon Transcribe pour la transcription). Par exemple, Amazon Transcribe peut convertir un fichier audio en texte, puis Amazon Translate peut traduire ce texte vers une autre langue. Ces services peuvent ainsi être intégrés dans un même pipeline automatisé.

Demo: Amazon Translate en temps réel

Via la console

Pour effectuer une traduction en temps réel depuis la console AWS, ouvrez le service Amazon Translate, puis sélectionnez Real-time translation dans le menu de navigation situé à gauche.

Sélectionnez ensuite la langue source et la langue cible (Il est également possible de laisser Amazon Translate détecter automatiquement la langue source), et saisissez le texte à traduire dans la zone Enter text. La traduction s'affiche immédiatement dans la zone Transltedd text.

Via la CLI

La commande translate-text permet d'effectuer une traduction synchrone directement en ligne de commande :

aws translate translate-text --text "Bonjour, Vous êtes sur le blog Cloudedlabs" --source-language-code "fr" --target-language-code "en" --region eu-west-3

Amazon Translate peut ainsi être utilisé depuis un script ou intégré dans un pipeline automatisé afin de traduire du contenu à la demande.

Via le SDK

Pour aller plus loin, Amazon Translate peut être appelé directement depuis le code d'une application grâce à AWS SDK. Voici un exemple simple en Node.js :

Cette approche permet d'intégrer Amazon Translate directement dans une application  et d'effectuer des traductions à la demande, sans passer par la console AWS ou la CLI.

Dans le prochain article, nous verrons comment mettre en place un pipeline de traduction par lot avec Amazon S3 et Amazon Translate.

Read More

AWS Wavelength : déployer un site web public sur EC2 derrière Carrier Gateway

Dans l'article précédent, nous avons découvert le fonctionnement des Wavelength Zones et activé celle de Casablanca. Passons maintenant à la pratique: déployer un site web public dans cette zone. 

Avant de plonger dans le déploiement, il faut d'abord comprendre comment une ressource déployée dans une Wavelength Zone devient accessible depuis internet. c'est le rôle de la Carrier Gateway. 

Qu'est-ce qu'une Carrier Gateway ?

Dans un VPC classique, pour donner un accès public à une instance EC2, on utilise une Internet Gateway. Dans une Wavelength Zone, ce rôle est joué par la Carrier Gateway. Elle permet d'assurer la connectivité entre les ressources de la Wavelength Zone et le réseau de l'opérateur via des Carrier IP

Nous allons déployer dans cet article une instance Amazon EC2 dans la Wavelength Zone de Casablanca (eu-west-3-cmn-wlz-1a), avec une Carrier IP, afin qu'elle soit accessible publiquement depuis le réseau d'Orange. 

Pour se faire, Les étapes sont les suivantes :

1. Créer la Carrier Gateway
2. Créer un sous-réseau dans la Wavelength Zone
3. Associer une table de routage
4. Lancer l'instance EC2 avec une Carrier IP
5. Tester l'accès public

1. Créer la Carrier Gateway

Dans la console VPC, section Carrier gateways, cliquez sur Create carrier gateway.

Donnez un nom, par exemple carrier-gw-casablanca, sélectionnez le VPC concerné. et cliquer sur Create carrier gateway.

Cela crée aussi une table de routage, qu on peut associer aux subnets de la Wavelength

2. Créer le sous-réseau dans la Wavelength Zone

Dans la console VPC, accédez à la section Subnets et sélectionnez Create subnet. 

Sélectionnez ensuite le VPC concerné et donnez un nom au sous-réseau, par exemple subnet-wlz-casablanca. Dans Availability Zone, choisissez eu-west-3-cmn-wlz-1a afin de créer le sous-réseau dans la Wavelength Zone de Casablanca. Pour IPv4 CIDR block, indiquez par exemple 10.0.1.0/24, puis sélectionnez Create subnet pour finaliser sa création.

3. Configurer le routage

Une fois le sous-réseau créé, il faut l'associer à la table de routage utilisée pour la Wavelength Zone.o

Pour cela, dans les paramètres dy subnet, dans l'onglet Route table, sélectionnez Edit route table association 

Puis choisissez la table de routage créée précédemment avec la Carrier Gateway.

Cette table contient une route par défaut (0.0.0.0/0) dont la cible est la Carrier Gateway, permettant au sous-réseau de communiquer avec internet.

4. Lancer l'instance EC2 avec une Carrier IP

L’objectif est de lancer l’instance directement dans le subnet de la Wavelength Zone et de lui attribuer une Carrier IP.

Lors de la création de la mchine EC2, il faudra, ,dans Network settings, sélectionner le VPC concerné, puis le subnet subnet-wlz-casablanca. et ensuite activez Auto-assign Carrier IP pour associer une Carrier IP à l’instance.

Pour automatiser la configuration du serveur Web au démarrage de l’instance, je vais utiliser User data dans Advanded details, et je mets le script suivant qui installe Nginx, démarre le service et crée une page Web simple :

#!/bin/bash

yum install -y nginx
systemctl enable nginx
systemctl start nginx

cat <<EOF > /usr/share/nginx/html/index.html
<html>
  <head>
    <title>Wavelength Casablanca</title>
  </head>
  <body>
    <h1>Welcome to CloudedLabs.com</h1>
    <p>Ce serveur est déployé dans la Wavelength Zone de casa blanca.</p>
<img src="https://blogger.googleusercontent.com/img/a/AVvXsEiBIHeZ9p77AOlzXKdJYyFOLhvO7ZH_4oUyaNfSwMR1XggJCTyHbtv0Xkt20qObTHD6avL8iNktLmTiGcsauxOX1bvRmKcE1JzL5TyLDXFyNAVM06uHbAVR_iAEm7WbR6kqJKaZdYS8kyqjnTYjRrjTcS3WeFQeRVH5jPUulYv2VQx0pcYC7Qalt5Ya_vjT
"
     alt="AWS Wavelength Zone Casablanca"
     style="max-width:100%; height:auto;">
  </body>
</html>
EOF

5. Tester l'accès public

Une fois l'instance au statut Running, récupérez sa Carrier IP depuis la console EC2.

En testant avec cette IP dans le navigateur, la page Web configurée via User Data s’affiche, confirmant ainsi que l’instance est accessible depuis Internet via sa Carrier IP.

Read More

Utiliser la Wavelength Zone de Casablanca

Vos utilisateurs sont principalement basés au Maroc ou en Afrique du Nord ? Vos applications nécessitent une très faible latence ou doivent respecter des contraintes de résidence des données ? auparavant, il fallait choisir entre déployer ses applications dans une région AWS proche telque Madrid ou Paris ou investir dans un Datacenter local.

Avec la disponibilité générale de la AWS Wavelength Zone de Casablanca, en partenariat avec Orange Maroc, il est désormais possible de déployer des ressources AWS directement au plus près des utilisateurs marocains, tout en continuant à bénéficier des services, des API et des outils de la plateforme AWS.

Dans cet article, nous allons découvrir le fonctionnement des Wavelength Zones, les différences avec les Availability Zones et les Local Zones, puis ultérieurement, on va déployer notre première instance Amazon EC2 dans la Wavelength Zone de Casablanca.

Qu'est-ce qu'une AWS Wavelength Zone ?

Normalement, une région est composée d'au moins 3 zones de disponibilité, chacune correspondant à un ou plusieurs data centers.

AWS Wavelength est une extension d'une région AWS déployée directement dans le réseau d'un opérateur télécom, tel que Orange ou Vodafone.

Le data center de la zone de disponibilité est géré par AWS, alors que celui de la Wavelength Zone est géré par un opérateur. Donc les machines créées dans une Wavelength Zone sont démarrées dans le data center de l'opérateur et ne quittent jamais ce data center.

La Wavelength Zone de Casablanca

La première Wavelength Zone d'Afrique du Nord est hébergée à Casablanca en partenariat avec Orange Maroc.

Elle est rattachée à la région Europe (Paris) :

• Région parente : eu-west-3

• Wavelength Zone : eu-west-3-cmn-wlz-1a

L'ensemble des ressources créées dans cette zone est donc administré depuis la région Paris.

Services disponibles

Toutes les ressources AWS ne sont pas disponibles dans une Wavelength Zone.

Les principaux services disponibles sont :

• Amazon EC2 (certains types d'instances uniquement)

• Amazon EBS

• Amazon VPC

• Carrier Gateway

• Amazon ECS

• Amazon EKS

• EC2 Auto Scaling

• Elastic Load Balancer

La disponibilité exacte des services peut évoluer selon les Wavelength Zones.

Activer la Wavelength Zone

Les Wavelength Zones doivent être activées (Opt-in) avant de pouvoir être utilisées. Pour se faire:

Depuis la console AWS

Allez dansla console Amazon EC2, Sélectionnez la région (Paris), cliquez sur le menu Dashboard, puis Cliquez sur Zones dans la section sur Account attributes .

Dans l'onglet Wavelength Zones, cherchez eu-west-3-cmn-wlz-1a et activez la en cliquant sur Opt-in

Depuis AWS CLI

aws ec2 modify-availability-zone-group --region eu-west-3 --group-name eu-west-3-cmn-wlz-1 --opt-in-status opted-in

Vérification :

aws ec2 describe-availability-zones --region eu-west-3 --all-availability-zones --filters Name=zone-type,Values=wavelength-zone

La sortie doit afficher la zone eu-west-3-cmn-wlz-1a avec le statut Opted-in

Conclusion

Avec la disponibilité de la Wavelength Zone de Casablanca, les entreprises marocaines et nord-africaines peuvent désormais déployer des charges de travail critiques à très faible latence, tout en conservant les mêmes outils, les mêmes API et les mêmes pratiques opérationnelles qu'au sein d'une région AWS classique.

Dans le prochain article, nous verrons comment créer l'ensemble de l'architecture réseau nécessaire (VPC, sous-réseau Wavelength, Carrier Gateway et tables de routage) avant de déployer une application complète dans la Wavelength Zone de Casablanca.

Read More

Amazon ECS : de la théorie au déploiement d'un service

Amazon Elastic Container Service (ECS) est un service d'orchestration de conteneurs entièrement géré par AWS. Il permet de déployer, faire évoluer et gérer des applications conteneurisées sans avoir à installer ni administrer soi-même un orchestrateur.

ECR (vu dans les articles précédents) se contente de stocker les images Docker, ECS s'occupe de les exécuter : il décide sur quelle machine lancer un conteneur, combien d'instances faire tourner, comment les remplacer en cas de panne, et comment les exposer au trafic réseau.

ECS peut être vu comme une alternative plus simple et plus intégrée à AWS que Kubernetes (ou son équivalent managé, EKS) : moins de concepts à apprendre, une intégration native avec IAM, VPC, CloudWatch et les load balancers AWS, au prix d'une portabilité moindre en dehors d'AWS.

Les deux modes de calcul : EC2 et Fargate

ECS ne fournit pas lui-même la puissance de calcul : il orchestre des conteneurs sur une infrastructure sous-jacente, qui peut être de deux natures.

Mode EC2

Les conteneurs s'exécutent sur des instances EC2 que vous provisionnez et gérez vous-même. Ces instance font tourner un agent ECS qui communique avec le control plane ECS pour recevoir et exécuter des tâches. Ce mode offre plus de contrôle (choix du type d'instance, accès SSH, optimisation fine des coûts avec des réservations ou du spot) mais implique aussi de gérer le patching, le scaling et le dimensionnement du cluster.

Mode Fargate

Fargate est un mode d'exécution serverless : AWS provisionne et gère automatiquement l'infrastructure nécessaire pour exécuter les conteneurs. Il n'y a plus d'instances EC2 à gérer, plus de capacité à dimensionner à l'avance. La facturation se fait à la ressource réellement consommée (vCPU/mémoire) pendant la durée d'exécution des contenaires.

Les composants clés d'ECS

Les principaux composants d'ECS

• Cluster : espace logique qui regroupe les ressources sur lesquelles les conteneurs seront exécutés.
• Task Definition : modèle décrivant l'application à exécuter (image Docker, CPU, mémoire, ports, variables d'environnement, etc.).
• Task : instance en cours d'exécution d'une Task Definition.
• Service : maintient un nombre défini de tâches en fonctionnement et permet leur intégration avec un Load Balancer ainsi que la mise à l'échelle.

Dans cet article, nous créerons un cluster ECS utilisant AWS Fargate, puis nous déploierons l'image Docker publiée précédemment dans Amazon ECR afin de rendre notre application accessible via un Application Load Balancer (ALB).

Déploiement

Cluster

On commence par la création d'un Cluster.

Dans le service Elastic Container Service, cliquez sur Clusters, puis sur Create cluster.

Donnez un nom à votre cluster, par exemple demo-cluster.
Dans la section Infrastructure, sélectionnez le type de capacité souhaité. ici je selectionne Fargate and self-managed instances qui permet d'utiliser Farget et aussi avoir des instances EC2 que je gère moi-même.

Enfin Cliquez sur Create.

Task Definition

Une fois le cluster créé, on définit la Task Definition qui décrit comment exécuter notre conteneur demo-app (l'image poussée sur ECR dans l'article précedent).

Dans le menu de gauche, cliquez sur Task definitions, puis sur Create new task definition.

Donnez un nom, par exemple demo-app-task, choisissez le type de lancement : AWS Fargate.
Configurez la taille de la Task :

• CPU : par exemple 0.5 vCPU.
• Mémoire : par exemple 1 GB.

Dans la section Container details, ajoutez un conteneur :

• Name : demo-app.
• Image URI : <account_id>.dkr.ecr.eu-west-3.amazonaws.com/demo-app:latest.
• Container port : le port exposé par l'application, par exemple 80.

Cliquez sur Create.

Service:

Maintenant on lance des containers.

Depuis la page du cluster demo-cluster, allez dans l'onglet Services, puis cliquez sur Create.

Selectionnez la task definition

Dans deployment configuration, on specifier le nombre de contenairs à créer

Dans Networking, choisissez le VPC et les subnets, et un security group autorisant le trafic sur le port du conteneur (80).

Dans Load balancing, vous pouvez associer un Application Load Balancer existant (ou en créer un) pour répartir le trafic entre les load balancers. 

enfin cliquez sur Create.

Vous trouverez un Load balancer en cours de création

C'est en utilisant le DNS du load balancer qu on peu acceder à l'appli qui toune dans des containers

Et voila tout est ok

Read More

Amazon ECR : stocker et gérer vos images Docker sur AWS

Vous êtes sur AWS et vous cherchez où stocker vos images Docker ? Amazon Elastic Container Registry (ECR) est la réponse native d'AWS à ce besoin : un registre d'images de conteneurs entièrement géré, qui permet de stocker, gérer et déployer des images Docker (ou tout autre format compatible OCI)

Concrètement, ECR joue le même rôle que Docker Hub, mais avec une intégration native aux autres services AWS : IAM pour les permissions, ECS et EKS pour le déploiement, ou encore CloudTrail pour l'audit.

ECR propose deux types de repositories :

Type	Usage
Privé	Accessible uniquement par les principals IAM autorisés de votre compte (ou de comptes tiers explicitement autorisés)
Public	Accessible publiquement en lecture

Dans cette démo, nous allons nous concentrer sur un repository privé, cas d'usage le plus courant en entreprise.

Création d'un repository ECR

Via la console

Depuis la console AWS, ouvrez le service Amazon Elastic Container Registry (ECR). Dans le menu de gauche, sous la section Private registry, cliquez sur Repositories, puis sur Create repository.

Donnez un nom à votre repository, par exemple demo-app.
Laissez les autres paramètres par défaut et cliquez sur Create.

Une fois créé, le repository apparaît dans la liste avec son URI:

Création Via la CLI

La même opération peut être réalisée avec l'AWS CLI :

aws ecr create-repository \
  --repository-name demo-app \
  --region eu-west-3

Push des images

Avant de pousser une image, Docker doit s'authentifier auprès du registre ECR.

Authentification (console → récupération de la commande)

Depuis la console ECR, sélectionnez votre repository demo-app.
Cliquez sur View push commands en haut à droite.

Une fenêtre s'ouvre et affiche les commandes nécessaires pour authentifier Docker, taguer l'image et la pousser vers le registre.

La premiere commande permet d'authentifier Docker auprès d'ECR. cela génère un jeton d'authentification temporaire. Une fois l'authentification réussie, Docker est autorisé à interagir avec le registre ECR, notamment pour pusher ou puller des images Docker.

La dernière commande push l'image dans le registry

Une fois le docker push terminé, l'image apparaît dans le repository ECR. Elle est désormais disponible et peut être utilisée par des services AWS tels qu'Amazon ECS ou Amazon EKS pour déployer des conteneurs.

Conclusion

À ce stade, notre image Docker est stockée dans Amazon ECR et prête à être utilisée. Dans le prochain article, nous verrons comment déployer cette image sur Amazon Elastic Container Service (ECS) afin d'exécuter notre application dans des conteneurs, la rendre accessible via un Application Load Balancer et bénéficier des fonctionnalités de haute disponibilité et de montée en charge offertes par ECS.

Read More