Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Sessions persistantes avec cookies basés sur les applications Lorsque vous utilisez un Application Load Balancer avec un cookie basé sur une application : + L'Application Load Balancer utilise le [poids du groupe cible](https://aws.amazon.com/premiumsupport/knowledge-center/elb-make-weighted-target-groups-for-alb/) pour déterminer comment équilibrer le trafic entrant entre les groupes cibles. + Par défaut, l'Application Load Balancer utilise la méthode round robin [pour acheminer les demandes vers les EC2 instances du](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm) groupe cible de destination. + Une fois que le trafic a été initialement acheminé vers une EC2 instance, la réponse de l'application de l' EC2 instance doit contenir un cookie d'application personnalisé, qui est renvoyé au client avec un cookie Application Load Balancer automatisé. + Le trafic suivant restera concentré sur l' EC2 instance si le client renvoie le cookie d'application et le cookie Application Load Balancer. + Le cookie basé sur l'application expire après non-utilisation pendant la durée configurée. **Modèle :** utilisez le CloudFormation modèle `stickysessionsapp.yml` (inclus dans le [fichier .zip de code d'exemple](samples/stickiness.zip)) pour essayer des sessions persistantes avec des cookies basés sur des applications. ## Cas d’utilisation courants Utilisez des sessions persistantes avec des cookies générés par l'application lorsque vous souhaitez un contrôle supplémentaire dans les scénarios suivants : + Serveurs Web PHP + Serveurs qui conservent des données de session temporaires telles que les journaux, les paniers d'achat ou les conversations par chat ## Changements de code depuis basic.yml Le seul changement de code concerne la configuration du groupe cible. Nous avons ajouté une configuration d'adhérence aux attributs de l'Application Load Balancer et du groupe cible. La durée du cookie d'application est spécifiée et le groupe cible a activé le caractère persistant des cookies d'application. **** | | | | --- |--- | | basic.yml | stickysessionsapp.yml | | 
TG1:
   Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
   Properties:
     Name: TG1
     Protocol: HTTP
     Port: 80
     TargetType: instance
     Targets:
       - Id: !Ref Instance1
       - Id: !Ref Instance2
VpcId: !Ref CustomVPC
| 
TG1:
  Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
  Properties:
    Name: TG1
    Protocol: HTTP
    Port: 80
    TargetType: instance
    Targets:
      - Id: !Ref Instance1
      - Id: !Ref Instance2
    VpcId: !Ref CustomVPC
    TargetGroupAttributes:
      - Key: stickiness.enabled
        Value: true
      - Key: stickiness.type
        Value: app_cookie
      - Key: stickiness.app_cookie.duration_seconds
        Value: 10
      - Key: stickiness.app_cookie.cookie_name
        Value: TESTCOOKIE
| ## Étapes **Remarques** Les passerelles NAT sont peu coûteuses. Plusieurs EC2 instances utiliseront vos heures de niveau gratuit plus rapidement qu'une seule EC2 instance. 1. Déployez le CloudFormation modèle `stickysessionslb.yml` dans un environnement de laboratoire. 1. Attendez que l'état de santé des instances de votre groupe cible passe d'un état **initial** à un état **sain**. 1. Accédez à l'URL de l'Application Load Balancer dans un navigateur Web à l'aide du protocole HTTP (TCP/80). Par exemple : `http://alb-123456789.us-east-1.elb.amazonaws.com/` La page Web affiche l'un des éléments suivants : **Instance 1 - TG1**, **Instance 2 - TG1**, **Instance 3 - TG2** ou **Instance 4 - TG2**. 1. Actualisez la page plusieurs fois. ## Résultats attendus **Note** Le CloudFormation modèle de cet exemple a configuré l'adhérence pour qu'elle dure 10 secondes. La configuration valide de la durée d'adhérence est comprise entre 1 seconde et 1 semaine. L'instance qui charge la page Web doit rester la même, comme indiqué par le texte de la page. La durée de conservation n'est pas actualisée, mais est basée sur l'expiration configurée dans l'Application Load Balancer pour le cookie d'application généré par l'instance. EC2 **Exemple 1 :** attendez 5 secondes pour actualiser la page. La même instance se chargera et le caractère collant sera actualisé pendant 10 secondes supplémentaires. **Exemple 2 :** attendez plus de 10 secondes pour recharger la page. Le cookie d'application expire et vous êtes redirigé vers une autre EC2 instance. Cette nouvelle instance génère un autre cookie d'application d'une durée de 10 secondes. ## Comment ça marche + Dans cet exemple, un serveur Web Apache (`httpd`) est installé sur les EC2 instances. Le `httpd.conf` fichier est configuré pour renvoyer une `Set-Cookie` valeur statique au client (votre navigateur Web). La `Set-Cookie` valeur est codée en dur pour être. `TESTCOOKIE=` + Ouvrez l'option **Inspect Element** de votre navigateur, choisissez l'onglet **Réseau**, puis choisissez la méthode **Get**, qui charge la page. Vous verrez un onglet **Cookies**. + Le navigateur est une application cliente qui est automatiquement configurée pour renvoyer toutes les mises à jour ultérieures au serveur avec les cookies qu'il reçoit dans la `Set-Cookie` réponse du serveur. + Lorsque vous rechargez la page, les cookies reçus lors du chargement initial de la page sont automatiquement renvoyés à l'Application Load Balancer. + Si le cookie a expiré (c'est-à-dire que 10 secondes se sont écoulées depuis le dernier appel), l'Application Load Balancer utilise une nouvelle logique pour déterminer l'instance vers EC2 laquelle acheminer le trafic. + Si le cookie n'a pas expiré, l'Application Load Balancer achemine le trafic vers la même EC2 instance.