5.2. Sources des événements

Procédure

1. Dans la perspective Administrator de la console web OpenShift Container Platform, naviguez vers Serverless Eventing.
2. Dans la liste Create, sélectionnez Event Source. Vous serez dirigé vers la page Event Sources.
3. Sélectionnez le type de source d'événement que vous souhaitez créer.

1. Créez un compte de service, un rôle et une liaison de rôle pour la source d'événement sous la forme d'un fichier YAML :

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   Remplacez cet espace de noms par l'espace de noms que vous avez sélectionné pour l'installation de la source d'événements.

2. Appliquer le fichier YAML :

   $ oc apply -f <filename>

3. Dans la perspective Developer, naviguez vers Add Event Source. La page Event Sources s'affiche.
4. Facultatif : si vous avez plusieurs fournisseurs pour vos sources d'événements, sélectionnez le fournisseur requis dans la liste Providers pour filtrer les sources d'événements disponibles du fournisseur.
5. Sélectionnez ApiServerSource puis cliquez sur Create Event Source. La page Create Event Source s'affiche.

6. Configurez les paramètres de ApiServerSource en utilisant les boutons Form view ou YAML view:

   Note

   Vous pouvez passer de la vue Form view à la vue YAML view. Les données sont conservées lors du passage d'une vue à l'autre.

   1. Saisissez v1 comme APIVERSION et Event comme KIND.
   2. Sélectionnez le site Service Account Name pour le compte de service que vous avez créé.
   3. Sélectionnez le site Sink pour la source de l'événement. Un Sink peut être soit un Resource, tel qu'un canal, un courtier ou un service, soit un URI.
7. Cliquez sur Create.

Suppression de la source du serveur API

1. Naviguez jusqu'à la vue Topology.

2. Cliquez avec le bouton droit de la souris sur la source du serveur API et sélectionnez Delete ApiServerSource.

   

1. Créez un compte de service, un rôle et une liaison de rôle pour la source d'événement sous la forme d'un fichier YAML :

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   Remplacez cet espace de noms par l'espace de noms que vous avez sélectionné pour l'installation de la source d'événements.

2. Appliquer le fichier YAML :

   $ oc apply -f <filename>

3. Créez une source de serveur API dotée d'un puits d'événements. Dans l'exemple suivant, le puits est un courtier :

   $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

4. Pour vérifier que la source du serveur API est correctement configurée, créez un service Knative qui déverse les messages entrants dans son journal :

   $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

5. Si vous avez utilisé un courtier comme puits d'événements, créez un déclencheur pour filtrer les événements du courtier default vers le service :

   kn trigger create <trigger_name> --sink ksvc:<service_name> $ kn trigger create <trigger_name>

6. Créer des événements en lançant un pod dans l'espace de noms par défaut :

   $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

7. Vérifiez que le contrôleur est correctement mappé en inspectant la sortie générée par la commande suivante :

   $ kn source apiserver describe <nom_de_la_source>

   Exemple de sortie

   Name:                mysource
   Namespace:           default
   Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:                 3m
   ServiceAccountName:  events-sa
   Mode:                Resource
   Sink:
     Name:       default
     Namespace:  default
     Kind:       Broker (eventing.knative.dev/v1)
   Resources:
     Kind:        event (v1)
     Controller:  false
   Conditions:
     OK TYPE                     AGE REASON
     ++ Ready                     3m
     ++ Deployed                  3m
     ++ SinkProvided              3m
     ++ SufficientPermissions     3m
     ++ EventTypesProvided        3m

1. Obtenez les cosses :

   $ oc get pods

2. Affichez les journaux des fonctions de l'expéditeur de messages pour les modules :

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Exemple de sortie

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Suppression de la source du serveur API

1. Supprimer le déclencheur :

   kn trigger delete <trigger_name>

2. Supprimer la source de l'événement :

   $ kn source apiserver delete <nom_de_la_source>

3. Supprimez le compte de service, le rôle de cluster et le lien de cluster :

   $ oc delete -f authentication.yaml

1. Créez un compte de service, un rôle et une liaison de rôle pour la source d'événement sous la forme d'un fichier YAML :

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   Remplacez cet espace de noms par l'espace de noms que vous avez sélectionné pour l'installation de la source d'événements.

2. Appliquer le fichier YAML :

   $ oc apply -f <filename>

3. Créer une source de serveur API sous la forme d'un fichier YAML :

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     name: testevents
   spec:
     serviceAccountName: events-sa
     mode: Resource
     resources:
       - apiVersion: v1
         kind: Event
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1
         kind: Broker
         name: default

4. Appliquer le fichier YAML ApiServerSource:

   $ oc apply -f <filename>

5. Pour vérifier que la source du serveur API est correctement configurée, créez un service Knative sous la forme d'un fichier YAML qui déverse les messages entrants dans son journal :

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-display
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

6. Appliquer le fichier YAML Service:

   $ oc apply -f <filename>

7. Créez un objet Trigger sous la forme d'un fichier YAML qui filtre les événements du courtier default vers le service créé à l'étape précédente :

   apiVersion: eventing.knative.dev/v1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     broker: default
     subscriber:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

8. Appliquer le fichier YAML Trigger:

   $ oc apply -f <filename>

9. Créer des événements en lançant un pod dans l'espace de noms par défaut :

   $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

10. Vérifiez que le contrôleur est correctement mappé, en entrant la commande suivante et en inspectant la sortie :

    $ oc get apiserversource.sources.knative.dev testevents -o yaml

    Exemple de sortie

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      annotations:
      creationTimestamp: "2020-04-07T17:24:54Z"
      generation: 1
      name: testevents
      namespace: default
      resourceVersion: "62868"
      selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
      uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
    spec:
      mode: Resource
      resources:
      - apiVersion: v1
        controller: false
        controllerSelector:
          apiVersion: ""
          kind: ""
          name: ""
          uid: ""
        kind: Event
        labelSelector: {}
      serviceAccountName: events-sa
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

1. Récupérez les pods en entrant la commande suivante :

   $ oc get pods

2. Affichez les journaux de la fonction d'expéditeur de messages pour les modules en entrant la commande suivante :

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Exemple de sortie

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Suppression de la source du serveur API

1. Supprimer le déclencheur :

   $ oc delete -f trigger.yaml

2. Supprimer la source de l'événement :

   $ oc delete -f k8s-events.yaml

3. Supprimez le compte de service, le rôle de cluster et le lien de cluster :

   $ oc delete -f authentication.yaml

Procédure

1. Pour vérifier que la source de ping fonctionne, créez un service Knative simple qui déverse les messages entrants dans les journaux du service.

   1. Dans la perspective Developer, naviguez vers Add YAML.

   2. Copiez l'exemple YAML :

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   3. Cliquez sur Create.

2. Créez une source ping dans le même espace de noms que le service créé à l'étape précédente, ou tout autre puits vers lequel vous souhaitez envoyer des événements.

   1. Dans la perspective Developer, naviguez vers Add Event Source. La page Event Sources s'affiche.
   2. Facultatif : si vous avez plusieurs fournisseurs pour vos sources d'événements, sélectionnez le fournisseur requis dans la liste Providers pour filtrer les sources d'événements disponibles du fournisseur.

   3. Sélectionnez Ping Source puis cliquez sur Create Event Source. La page Create Event Source s'affiche.

      Note

      Vous pouvez configurer les paramètres de PingSource en utilisant Form view ou YAML view et passer d'une vue à l'autre. Les données sont conservées lors du passage d'une vue à l'autre.

   4. Enter a value for Schedule. In this example, the value is */2 * * * *, which creates a PingSource that sends a message every two minutes.
   5. Facultatif : vous pouvez saisir une valeur pour Data, qui est la charge utile du message.
   6. Sélectionnez un Sink. Il peut s'agir d'un Resource ou d'un URI. Dans cet exemple, le service event-display créé à l'étape précédente est utilisé comme puits Resource.
   7. Cliquez sur Create.

1. Dans la perspective Developer, naviguez jusqu'à Topology.

2. Affichez la source et la destination du ping.

   

Suppression de la source de ping

1. Naviguez jusqu'à la vue Topology.
2. Cliquez avec le bouton droit de la souris sur la source du serveur API et sélectionnez Delete Ping Source.

Procédure

1. Pour vérifier que la source de ping fonctionne, créez un service Knative simple qui déverse les messages entrants dans les journaux du service :

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. Pour chaque ensemble d'événements ping que vous souhaitez demander, créez une source ping dans le même espace de noms que le consommateur d'événements :

   $ kn source ping create test-ping-source \
       --schedule "*/2 * * * *" \
       --data '{"message": "Hello world!"}' \
       --sink ksvc:event-display

3. Vérifiez que le contrôleur est correctement mappé en entrant la commande suivante et en inspectant la sortie :

   $ kn source ping describe test-ping-source

   Exemple de sortie

   Name:         test-ping-source
   Namespace:    default
   Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:          15s
   Schedule:     */2 * * * *
   Data:         {"message": "Hello world!"}
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE                 AGE REASON
     ++ Ready                 8s
     ++ Deployed              8s
     ++ SinkProvided         15s
     ++ ValidSchedule        15s
     ++ EventTypeProvided    15s
     ++ ResourcesCorrect     15s

1. Surveillez la création de nouvelles gousses :

   $ watch oc get pods

2. Annulez l'observation des pods en utilisant Ctrl C, puis regardez les journaux du pod créé :

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Exemple de sortie

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
     time: 2020-04-07T16:16:00.000601161Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

Procédure

1. Pour vérifier que la source de ping fonctionne, créez un service Knative simple qui déverse les messages entrants dans les journaux du service.

   1. Créer un fichier YAML de service :

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   2. Créer le service :

      $ oc apply -f <filename>

2. Pour chaque ensemble d'événements ping que vous souhaitez demander, créez une source ping dans le même espace de noms que le consommateur d'événements.

   1. Créer un fichier YAML pour la source ping :

      apiVersion: sources.knative.dev/v1
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        data: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. Créer la source de ping :

      $ oc apply -f <filename>

3. Vérifiez que le contrôleur est correctement mappé en entrant la commande suivante :

   $ oc get pingsource.sources.knative.dev <nom_de_la_source_de_ping> -oyaml

   Exemple de sortie

   apiVersion: sources.knative.dev/v1
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     data: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

1. Surveillez la création de nouvelles gousses :

   $ watch oc get pods

2. Annulez l'observation des pods en utilisant Ctrl C, puis regardez les journaux du pod créé :

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Exemple de sortie

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

Procédure

1. Dans la perspective Developer, naviguez jusqu'à la page Add et sélectionnez Event Source.
2. Dans la page Event Sources, sélectionnez Kafka Source dans la section Type.

3. Configurez les paramètres de Kafka Source:

   1. Ajouter une liste de Bootstrap Servers séparée par des virgules.
   2. Ajouter une liste de Topics séparée par des virgules.
   3. Ajouter un Consumer Group.
   4. Sélectionnez le site Service Account Name pour le compte de service que vous avez créé.
   5. Sélectionnez le site Sink pour la source de l'événement. Un Sink peut être soit un Resource, tel qu'un canal, un courtier ou un service, soit un URI.
   6. Saisissez une adresse Name pour la source d'événements Kafka.
4. Cliquez sur Create.

1. Dans la perspective Developer, naviguez jusqu'à Topology.

2. Afficher la source et le puits d'événements Kafka.

   

Procédure

1. Pour vérifier que la source d'événements Kafka fonctionne, créez un service Knative qui déverse les événements entrants dans les journaux du service :

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display

2. Créer un CR KafkaSource:

   $ kn source kafka create <kafka_source_name> \
       --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \
       --topics <topic_name> --consumergroup my-consumer-group \
       --sink event-display

   Note

   Remplacez les valeurs de cette commande par les valeurs de votre nom de source, de vos serveurs d'amorçage et de vos rubriques.

   Les options --servers, --topics, et --consumergroup spécifient les paramètres de connexion au cluster Kafka. L'option --consumergroup est facultative.

3. Facultatif : Affichez les détails de la CR KafkaSource que vous avez créée :

   $ kn source kafka describe <kafka_source_name>

   Exemple de sortie

   Name:              example-kafka-source
   Namespace:         kafka
   Age:               1h
   BootstrapServers:  example-cluster-kafka-bootstrap.kafka.svc:9092
   Topics:            example-topic
   ConsumerGroup:     example-consumer-group
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE            AGE REASON
     ++ Ready            1h
     ++ Deployed         1h
     ++ SinkProvided     1h

Verification steps

1. Déclencher l'envoi par l'instance Kafka d'un message au sujet :

   $ oc -n kafka run kafka-producer \
       -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \
       --restart=Never -- bin/kafka-console-producer.sh \
       --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic

   Saisissez le message dans l'invite. Cette commande suppose que :

   • Le cluster Kafka est installé dans l'espace de noms kafka.
   • L'objet KafkaSource a été configuré pour utiliser le sujet my-topic.

2. Vérifiez que le message est arrivé en consultant les journaux :

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Exemple de sortie

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.kafka.event
     source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic
     subject: partition:46#0
     id: partition:46/offset:0
     time: 2021-03-10T11:21:49.4Z
   Extensions,
     traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00
   Data,
     Hello!

Procédure

1. Créer un objet KafkaSource sous la forme d'un fichier YAML :

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: <source_name>
   spec:
     consumerGroup: <group_name> 1
     bootstrapServers:
     - <list_of_bootstrap_servers>
     topics:
     - <list_of_topics> 2
     sink:
     - <list_of_sinks> 3

   1

   Un groupe de consommateurs est un groupe de consommateurs qui utilisent le même identifiant de groupe et consomment des données d'un thème.

   2

   Un thème fournit une destination pour le stockage des données. Chaque thème est divisé en une ou plusieurs partitions.

   3

   Un puits indique où les événements sont envoyés à partir d'une source.

   Important

   Seule la version v1beta1 de l'API pour les objets KafkaSource sur OpenShift Serverless est prise en charge. N'utilisez pas la version v1alpha1 de cette API, car elle est désormais obsolète.

   Exemple d'objet KafkaSource

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: kafka-source
   spec:
     consumerGroup: knative-group
     bootstrapServers:
     - my-cluster-kafka-bootstrap.kafka:9092
     topics:
     - knative-demo-topic
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

2. Appliquer le fichier YAML KafkaSource:

   $ oc apply -f <filename>

Procédure

1. Créez les fichiers de certificats en tant que secrets dans l'espace de noms que vous avez choisi :

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-literal=password="SecretPassword" \
     --from-literal=saslType="SCRAM-SHA-512" \ 1
     --from-literal=user="my-sasl-user"

   1

   Le type SASL peut être PLAIN, SCRAM-SHA-256, ou SCRAM-SHA-512.

2. Créez ou modifiez votre source Kafka de manière à ce qu'elle contienne la configuration suivante : spec:

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: example-source
   spec:
   ...
     net:
       sasl:
         enable: true
         user:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: user
         password:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: password
         type:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: saslType
       tls:
         enable: true
         caCert: 1
           secretKeyRef:
             name: <kafka_auth_secret>
             key: ca.crt
   ...

   1

   La spécification caCert n'est pas nécessaire si vous utilisez un service Kafka en nuage public, tel que Red Hat OpenShift Streams for Apache Kafka.

Procédure

1. Créez une source d'événement de n'importe quel type, en naviguant vers Add Event Source et en sélectionnant le type de source d'événement que vous souhaitez créer.
2. Dans la section Sink de la vue du formulaire Create Event Source, sélectionnez votre évier dans la liste Resource.
3. Cliquez sur Create.

1. Dans la perspective Developer, naviguez jusqu'à Topology.
2. Affichez la source de l'événement et cliquez sur le puits connecté pour afficher les détails du puits dans le panneau de droite.