Ressourcen

Introduction

Automating cloud infrastructure and deployments is a crucial aspect of DevOps. AWS Amplify provides a powerful framework for developing and deploying full-stack applications. However, initializing and managing an Amplify app manually can be time-consuming, especially when integrating it into a CI/CD pipeline like Jenkins.

This blog explores how we automated the Amplify app creation process in headless mode using shell scripting and Expect scripts, eliminating interactive prompts to streamline our pipeline.

Setting Up AWS and Amplify CLI

1. Configure AWS Credentials

Before initializing an Amplify app, configure AWS CLI with your Access Key and Secret Key:

aws configure

2. Install and Configure Amplify CLI

To install Amplify CLI and configure it:

npm install -g @aws-amplify/cli

amplify configure

This will prompt you to create an IAM user and set up authentication.

Automating Amplify App Creation

1. Initialize the Amplify App Using a Script

We created a shell script amplify-init.sh to automate the initialization process.

amplify-init.sh

#!/bin/bash

set -e

IFS='|'

AMPLIFY_NAME=amplifyapp

API_FOLDER_NAME=amplifyapp

BACKEND_ENV_NAME=staging

AWS_PROFILE=default

REGION=us-east-1

AWSCLOUDFORMATIONCONFIG="{\

\"configLevel\":\"project\",\

\"useProfile\":true,\

\"profileName\":\"${AWS_PROFILE}\",\

\"region\":\"${REGION}\"\

}"

AMPLIFY="{\

\"projectName\":\"${AMPLIFY_NAME}\",\

\"envName\":\"${BACKEND_ENV_NAME}\",\

\"defaultEditor\":\"Visual Studio Code\"\

}"

amplify init --amplify $AMPLIFY --providers $AWSCLOUDFORMATIONCONFIG --yes

Run the script:

./amplify-init.sh

2. Automating API and Storage Integration

Since Amplify prompts users for inputs, we used Expect scripts to automate API and storage creation.

add-api-response.exp

#!/usr/bin/expect

spawn ./add-api.sh

expect "? Please select from one of the below mentioned services:\r"

send -- "GraphQL\r"

expect eof

add-storage-response.exp

#!/usr/bin/expect

spawn ./add-storage.sh

expect "? Select from one of the below mentioned services:\r"

send -- "Content\r"

expect eof

These scripts eliminate manual input, making Amplify API and storage additions fully automated.

Automating Schema Updates

One of the biggest challenges was automating schema.graphql updates without manual intervention. The usual approach required engineers to manually upload the file, leading to potential errors.

To solve this, we automated the process with an Amplify Pull script.

amplify-pull.sh

#!/bin/bash

set -e

IFS='|'

AMPLIFY_NAME=amp3

API_FOLDER_NAME=amp3

BACKEND_ENV_NAME=prod

AWS_PROFILE=default

REGION=us-east-1

APP_ID=dzvchzih477u2

AWSCLOUDFORMATIONCONFIG="{\

\"configLevel\":\"project\",\

\"useProfile\":true,\

\"profileName\":\"${AWS_PROFILE}\",\

\"region\":\"${REGION}\"\

}"

AMPLIFY="{\

\"projectName\":\"${AMPLIFY_NAME}\",\

\"appId\":\"${APP_ID}\",\

\"envName\":\"${BACKEND_ENV_NAME}\",\

\"defaultEditor\":\"code\"\

}"

amplify pull --amplify $AMPLIFY --providers $AWSCLOUDFORMATIONCONFIG --yes

This script ensures that the latest schema changes are pulled and updated in the pipeline automatically.

Integrating with Jenkins

Since this automation was integrated with a Jenkins pipeline, we enabled "This project is parameterized" to allow file uploads directly into the workspace.

1. Upload the schema.graphql file via Jenkins UI.
2. The script pulls the latest changes and updates Amplify automatically.

This method eliminates manual intervention, ensuring consistency in schema updates across multiple environments.

Conclusion

By automating AWS Amplify workflows with shell scripting and Expect scripts, we achieved:  Fully automated Amplify app creation
  Eliminated manual schema updates
  Seamless integration with Jenkins pipelines
  Faster deployments with reduced errors

This approach significantly minimized manual effort, ensuring that updates were streamlined and efficient. If you're using Amplify for your projects, automation like this can save countless hours and improve developer productivity.

Have questions or feedback? Drop a comment below! 

GKE Ingress acts as a bridge between external users and your Kubernetes services. It allows you to define rules for routing traffic based on hostnames and URL paths, enabling you to direct requests to different backend services seamlessly.

A single GKE Ingress controller routes traffic to multiple services by identifying the target backend based on hostname and URL paths. It supports multiple certificates for different domains.

FrontendConfig enables automatic redirection from HTTP to HTTPS, ensuring encrypted communication between the web browser and the Ingress.
BackendConfig that allows you to configure advanced settings for backend services. It provides additional options beyond standard service configurations, enabling better control over traffic handling, security, and load balancing behavior.

Setup GKE ingress with application loadbalancer

To specify an Ingress class, you must use the kubernetes.io/ingress.class annotation.The “gce” class deploys an external Application Load Balancer

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: my-ingress

annotations:

kubernetes.io/ingress.class: “gce”

Configure FrontendConfiguration:

apiVersion: networking.gke.io/v1beta1

kind: FrontendConfig

metadata:

name: my-frontend-config

spec:

redirectToHttps:

enabled: true

The FrontendConfig resource in GKE enables automatic redirection from HTTP to HTTPS, ensuring secure communication between clients and services.

Associating FrontendConfig with your Ingress

You can associate a FrontendConfig with an Ingress. Use the “networking.gke.io/v1beta1.FrontendConfig” to annotate with the ingress.

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

networking.gke.io/v1beta1.FrontendConfig: “my-frontend-config”

Configure Backend Configuration:

apiVersion: cloud.google.com/v1

kind: BackendConfig

metadata:

name: my-backendconfig

spec:

timeoutSec: 40

BackendConfig to set a backend service timeout period in seconds.The following BackendConfig manifest specifies a timeout of 40 seconds.

Associate the backend configuration with service:

apiVersion: v1

kind: Service

metadata:

annotations:

cloud.google.com/backend-config: ‘{“ports”:{“my-backendconfig”}}’

cloud.google.com/neg: ‘{“ingress”: true}’

spec:

ports:

- name: app

port: 80

protocol: TCP

targetPort: 50000

We can specify a custom BackendConfig for one or more ports using a key that matches the port’s name or number. The Ingress controller uses the specific BackendConfig when it creates a load balancer backend service for a referenced Service port.

Creating an Ingress with a Google-Managed SSL Certificate

To set up a Google-managed SSL certificate and link it to an Ingress, follow these steps:

• Create a ManagedCertificate resource in the same namespace as the Ingress.
• Associate the ManagedCertificate with the Ingress by adding the annotation networking.gke.io/managed-certificates to the Ingress resource.

apiVersion: networking.gke.io/v1

kind: ManagedCertificate

metadata:

name: managed-cert

spec:

domains:

- hello.example.com

- world.example.com

Associate the SSL with Ingress

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: ingress

annotations:

networking.gke.io/v1beta1.FrontendConfig: “my-frontend-config”

networking.gke.io/managed-certificates: managed-cert

kubernetes.io/ingress.class: “gce”

associate it with the managed-certificate by adding an annotation.

Assign Static IP to Ingress

When hosting a web server on a domain, the application’s external IP address should be static to ensure it remains unchanged.

By default, GKE assigns ephemeral external IP addresses for HTTP applications exposed via an Ingress. However, these addresses can change over time. If you intend to run your application long-term, it is essential to use a static external IP address for stability.

Create a global static ip from gcp console with specific name eg: web-static-ip and associate it with ingress by adding the global-static-ip-name annotation.

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: ingress

annotations:

networking.gke.io/v1beta1.FrontendConfig: “my-frontend-config”

networking.gke.io/managed-certificates: managed-cert

kubernetes.io/ingress.class: “gce”

kubernetes.io/ingress.global-static-ip-name: “web-static-ip”

Google Cloud Armor Ingress security policy

Google Cloud Armor security policies safeguard your load-balanced applications against web-based attacks. Once configured, a security policy can be referenced in a BackendConfig to apply protection to specific backends.

To enable a security policy, add its name to the BackendConfig. The following example configures a security policy named security-policy:

apiVersion: cloud.google.com/v1

kind: BackendConfig

metadata:

namespace: cloud-armor-how-to

name: my-backendconfig

spec:

securityPolicy:

name: “security-policy”

User-defined request/response headers

A BackendConfig can be used to define custom request headers that the load balancer appends to requests before forwarding them to the backend services.

These custom headers are only added to client requests and not to health check probes. If a backend requires a specific header for authorization and it is absent in the health check request, the health check may fail.

Um benutzerdefinierte Anfrage-Header zu konfigurieren, geben Sie diese unter der Eigenschaft customRequestHeaders/customResponseHeaders in der BackendConfig-Ressource an. Jeder Header sollte als Zeichenfolge im Format Header-Name:Header-Wert definiert werden.

apiVersion: cloud.google.com/v1

kind: BackendConfig

metadata:

name: my-backendconfig

spec:

customRequestHeaders:

headers:

- “X-Client-Region:{client_region}”

- “X-Client-City:{client_city}”

- “X-Client-CityLatLong:{client_city_lat_long}”

apiVersion: cloud.google.com/v1

kind: BackendConfig

metadata:

name: my-backendconfig

spec:

customResponseHeaders:

headers:

- “Strict-Transport-Security: max-age=28800; includeSubDomains”

‍

Argo CD is a declarative, GitOps-based continuous delivery tool designed for Kubernetes. It allows you to manage and automate application deployment using Git as the single source of truth. Argo CD continuously monitors your Git repository and ensures the Kubernetes environment matches the desired state described in your manifest.

Step 1: Create and Connect to a Kubernetes Cluster

Steps to Create and Connect

Create a Kubernetes Cluster
If you’re using Google Kubernetes Engine (GKE), you can create a cluster using the following command:

gcloud container clusters create <cluster name> — zone <zone of cluster>

Replace <cluster name> with your desired cluster name and <zone of cluster> with your preferred zone.

Connect to the Cluster
Once the cluster is created, configure kubectl (the Kubernetes CLI) to interact with it:

gcloud container clusters get-credentials argo-test — zone us-central1-c

Verify the connection by listing the nodes in the cluster:
kubectl get nodes

Step 2: Install Argo CD

Installing Argo CD means deploying its server, UI, and supporting components as Kubernetes resources in a namespace.

Steps to Install

Create a Namespace for Argo CD
A namespace in Kubernetes is a logical partition to organize resources:

kubectl create namespace argocd

Install Argo CD Components
Use the official installation manifest to deploy all Argo CD components:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

This deploys key components like the API server, repository server, application controller, and web UI.

Step 3: Expose Argo CD Publicly

By default, the argocd-server service is configured as a ClusterIP, making it accessible only within the cluster. You need to expose it for external access.

Options to Expose Argo CD

Option-1 LoadBalancer
Change the service type to LoadBalancer to get an external IP address:

kubectl patch svc argocd-server -n argocd -p ‘{“spec”: {“type”: “LoadBalancer”}}’

Ingress
For advanced routing and SSL support, create an Ingress resource. This approach is recommended if you want to add HTTPS to your setup.

Option-2 Port Forwarding
If you only need temporary access:

kubectl port-forward svc/argocd-server -n argocd 8080:80

Step 4: Access the Argo CD Dashboard

Retrieve the External IP
After exposing the service as a LoadBalancer, get the external IP address:

kubectl get svc argocd-server -n argocd

Login Credentials

Username: admin

Password: Retrieve it from the secret:

kubectl get secret argocd-initial-admin-secret -n argocd -o yaml

Decode the base64 password:

echo “<base64_encoded_password>” | base64 — decode

Access the dashboard by navigating to https://<external-ip> in your browser.

Step 5: Install the Argo CD CLI

The Argo CD CLI enables you to interact with the Argo CD server programmatically for managing clusters, applications, and configurations.

Steps to Install

Download the CLI

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64

Install the CLI

sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd

rm argocd-linux-amd64

Verify Installation

argocd version

Step 6: Add a Kubernetes Cluster to Argo CD

Argo CD requires access to the Kubernetes cluster where it will deploy applications.

Steps to Add

Log in to Argo CD via CLI

argocd login <argocd-server-url>:<port> — username admin — password <password>

Get the Kubernetes Context

kubectl config get-contexts -o name

Add the Cluster

argocd cluster add <context-name>

This command creates a service account (argocd-manager) with cluster-wide permissions to deploy applications.

To Verify the added cluster via cli use below command else navigate to the ui dashboard setting -> cluster

argocd cluster list

‍

Step 7: Add a Git Repository

The Git repository serves as the source of truth for application manifests.

Steps to Add

1. Navigate to Repositories
   Log in to the Argo CD dashboard, go to Settings -> Repositories, and click Connect Repo.
2. Enter Repository Details

• Choose a connection method (e.g., HTTPS or SSH).
• Provide the repository URL and credentials.
• Assign a project to organize repositories.

Step 8: Create an Application in Argo CD

An Argo CD application represents the Kubernetes resources defined in a Git repository.

Steps to Create

Click New App
Enter the application details:

• Application Name: e.g., hello-world
• Project: Assign the application to a project.
• Source: Select the Git repository and specify the manifest file path.
• Destination: Select the cluster and namespace for deployment.

1. Enable Auto-Sync policy
   Enable this option for automated synchronization between the Git repository and the Kubernetes cluster.
2. Create the Application
   Click Create. Argo CD will deploy the application and monitor its state.

‍

‍

Introduction

Cloud storage plays a crucial role in modern infrastructure, providing scalable and reliable storage solutions. Many businesses migrate from AWS S3 to Google Cloud Storage (GCS) to leverage cost benefits, integration with Google Cloud services, or optimize their cloud strategies. However, when dealing with hundreds of S3 buckets, manual migration is inefficient and time-consuming.

To streamline the process, I automated the migration using Bash scripts and Google Cloud’s Storage Transfer Service. In this blog, I’ll walk you through the steps of automating S3 to GCS migration efficiently.

Why Automate S3 to GCS Migration?

Handling over 200+ S3 buckets manually would involve:

• Repetitive tasks – Creating GCS buckets, setting permissions, and transferring data for each bucket.
• Human errors – Misconfiguration, incorrect bucket names, or missing files.
• Time-consuming process – Manual intervention would take days to complete.

By automating this process, we can:

 Save time – Script execution takes a few minutes instead of hours/days.

 Eliminate errors – Ensures all S3 buckets are correctly transferred.

 Enable monitoring & scheduling – Automate recurring data transfers with Google’s Storage Transfer Service.

Prerequisites

Before running the scripts, ensure you have:

 A Google Cloud Project with Billing enabled.
AWS IAM User with s3:ListBucket and s3:GetObject permissions.
Installed Google Cloud SDK (gcloud CLI) on your local machine.

Step 1: Creating Google Cloud Storage Buckets

Each S3 bucket requires a corresponding GCS bucket. The script below reads a list of bucket names from a file and creates them in GCP.

create_gcs_bucket.sh

#!/bin/bash

# Variables

PROJECT_ID="ccd-poc-project"  # Replace with your GCP project ID

BUCKET_LIST_FILE="bucket_names.txt"  # File containing bucket names

OUTPUT_FILE="created_buckets.txt"

REGION="us-central1"  # Change if needed

# Check if the bucket list file exists

if [ ! -f "$BUCKET_LIST_FILE" ]; then

    echo "Error: Bucket names file '$BUCKET_LIST_FILE' not found!"

    exit 1

fi

# Read bucket names and create GCS buckets

while IFS= read -r BUCKET_NAME || [[ -n "$BUCKET_NAME" ]]; do

    if [[ -z "$BUCKET_NAME" ]]; then

        continue  # Skip empty lines

    fi

    # Clean bucket name

    BUCKET_NAME=$(echo "$BUCKET_NAME" | tr -d '\r' | tr -d '[:space:]')

    echo "Creating bucket: $BUCKET_NAME"

    gcloud storage buckets create "gs://$BUCKET_NAME" --location="$REGION" --project="$PROJECT_ID"

    if [ $? -eq 0 ]; then

        echo "gs://$BUCKET_NAME" >> "$OUTPUT_FILE"

        echo "Bucket $BUCKET_NAME created successfully."

    else

        echo "Error: Failed to create bucket $BUCKET_NAME"

    fi

done < "$BUCKET_LIST_FILE"

  Explanation:

• Reads bucket names from bucket_names.txt.
• Cleans up any unnecessary whitespace.
• Creates GCS buckets with the specified region.
• Stores created bucket names in created_buckets.txt.

Step 2: Automating Data Transfer from S3 to GCS

After creating the required GCS buckets, the next step is to automate data transfer using the gcloud transfer jobs command.

s3_to_gcs_transfer.sh

#!/bin/bash

‍

# Variables

AWS_ACCESS_KEY="YOUR_AWS_ACCESS_KEY"

AWS_SECRET_KEY="YOUR_AWS_SECRET_KEY"

PROJECT_ID="ccd-poc-project"

CREDS_FILE="aws-creds.json"

‍

# Create AWS credentials JSON file

cat <<EOF > "$CREDS_FILE"

{

  "awsAccessKeyId": "$AWS_ACCESS_KEY",

  "awsSecretAccessKey": "$AWS_SECRET_KEY"

}

EOF

‍

# Read bucket names and create transfer jobs

while IFS= read -r BUCKET_NAME; do

  echo "Creating transfer job for S3 bucket: $BUCKET_NAME"

‍

  JOB_NAME=$(gcloud transfer jobs create s3://"$BUCKET_NAME" gs://"$BUCKET_NAME" \

    --source-auth-method=AWS_SIGNATURE_V4 \

    --source-creds-file="$CREDS_FILE" \

    --schedule-repeats-every=1d \

    --project="$PROJECT_ID" \

    --format="value(name)")

‍

  if [[ -n "$JOB_NAME" ]]; then

    echo "Übertragungsauftrag erfolgreich erstellt: $JOB_NAME"

  else

    echo "Fehler beim Erstellen des Übertragungsauftrags für $BUCKET_NAME"

  fi

‍

done < bucket_names.txt

‍

# Anmeldedatei aus Sicherheitsgründen entfernen

rm "$CREDS_FILE"

‍

echo "Alle Übertragungsaufträge erfolgreich erstellt!"

‍

      Erklärung:

• Generiert eine sichere AWS-Zugangsdaten-Datei.
• Liest Bucket-Namen ein und initiiert einen Übertragungsauftrag.
• Prüft, ob eine bestehende Übertragung läuft, bevor eine neue erstellt wird.
• Löscht die Zugangsdaten-Datei nach der Ausführung aus Sicherheitsgründen.

Schritt 3: Ausführen der Migration

Um die Skripte auszuführen, gehen Sie wie folgt vor:

1. Speichern Sie die S3-Bucket-Namen in einer Datei namens bucket_names.txt.
2. Führen Sie das Skript zur Erstellung von GCS-Buckets aus:

chmod +x create_gcs_bucket.sh

./create_gcs_bucket.sh

3. Führen Sie das S3-zu-GCS-Übertragungsskript aus:

chmod +x s3_to_gcs_transfer.sh

./s3_to_gcs_transfer.sh

Fazit

Durch die Automatisierung der S3-zu-GCS-Migration haben wir:
Manuellen Aufwand für die Erstellung von über 200 Buckets eliminiert.
Genaue und effiziente Datenübertragungen sichergestellt.
Tägliche Synchronisierungen für inkrementelle Updates geplant.

Diese Lösung ist leicht skalierbar und kann um erweiterte Funktionen wie Logging, Monitoring und Benachrichtigungen erweitert werden.

Wenn Sie diesen Leitfaden hilfreich fanden, teilen Sie Ihre Gedanken und Erfahrungen gerne in den Kommentaren mit. Viel Erfolg beim Migrieren!

In diesem Blog führen wir Sie durch die Automatisierung von Benachrichtigungen für kritische Aktivitäten und den Schutz Ihrer Projekte vor versehentlichem Löschen mithilfe benutzerdefinierter Skripte. Das manuelle Einrichten von protokollbasierten Metriken und Benachrichtigungen kann eine zeitaufwändige Aufgabe sein, die typischerweise etwa eine Stunde dauert oder zu manuellen Fehlern führen kann. Um diesen Prozess zu optimieren und die Effizienz zu steigern, haben wir ihn mithilfe einer Kombination aus Shell- und YAML-Skripten automatisiert.

Durch die Implementierung dieser Lösung können Sie Benachrichtigungskanäle konfigurieren, um Benachrichtigungen zu erhalten, sobald Änderungen in Ihrer Cloud-Umgebung erkannt werden, was eine schnelle Reaktion auf potenzielle Probleme gewährleistet. Unser Ansatz beinhaltet die Nutzung von YAML-Dateien zusammen mit dem Deployment Manager, um Log-Metriken und Benachrichtigungsrichtlinien zu erstellen und zu verwalten. Sobald diese Komponenten erfolgreich bereitgestellt wurden, wird die Bereitstellung selbst gelöscht, da sie keine laufenden Dienste oder Ressourcen in Ihrer Cloud-Umgebung beeinträchtigt.

Die folgenden Schritte bieten Ihnen eine detaillierte Schritt-für-Schritt-Anleitung zur effektiven Implementierung dieser Automatisierung, wodurch Sie eine bessere Sicherheit und Betriebseffizienz aufrechterhalten können.

Schritt-für-Schritt-Anleitung zur effektiven Implementierung dieser Automatisierung

1. Repository klonen

Voraussetzungen:

Verbinden Sie sich mit Ihrer Google Cloud Shell und stellen Sie sicher, dass Sie die erforderlichen Berechtigungen haben, um das Skript auszuführen.

git clone https://github.com/nvrvenkat/Securitylogalerts.git

Dieser Befehl klont das Securitylogalerts-Repository von GitHub auf Ihr lokales System.

2. Zum Repository-Verzeichnis navigieren

cd Securitylogalerts/

Dieser Befehl wechselt das Verzeichnis in den Ordner Securitylogalerts, wo sich alle Projektdateien befinden.

3. Beschreibung von Metriken und Benachrichtigungen

4. Ersetzen Sie die E-Mail-Adresse in logmetric_notification.sh

Aktualisieren Sie die E-Mail-Adresse im Shell-Skript „logmetric_notification.sh“ mit der spezifischen E-Mail-Adresse, an die Benachrichtigungen gesendet werden sollen.

Diese E-Mail-Adresse wird zur Konfiguration des Benachrichtigungskanals verwendet.

‍

5. Führen Sie das Skript für den Benachrichtigungskanal aus

./logmetric_notification.sh 

Führt das Skript aus, um einen Benachrichtigungskanal mit der aktualisierten E-Mail-Adresse zu erstellen.

Es erstellt einen Benachrichtigungskanal mit der aktualisierten E-Mail-Adresse und generiert protokollbasierte Metriken, wie im Abschnitt „Metriken und Benachrichtigungen“ angegeben.

Hinweis: Wenn bereits ein Benachrichtigungskanal existiert, führen Sie die Datei logmetric.sh aus, um nur die protokollbasierten Metriken zu generieren.

6. Navigieren Sie zum Log-Alert-Verzeichnis und führen Sie Skripte aus

a) cd /Securitylogalerts/Logalert

./scripts.sh

Das Skript scripts.sh löst Folgendes aus:

replace_notification_channel.sh: Ersetzt den Benachrichtigungskanal durch ACT-MS-alerts in den YAML-Dateien, die zum Erstellen von Log-Metrik-Benachrichtigungen verwendet werden. Die Ausgabe wird in output.txt gespeichert.

logalert.sh: Erstellt Alarmierungsrichtlinien basierend auf dem aktualisierten Benachrichtigungskanal in den YAML-Dateien.

‍

 Aktualisierung der Alarmierungsrichtlinien:

• Sobald scripts.sh ausgeführt wurde, wird der Benachrichtigungskanal in den YAML-Dateien ersetzt und die Alarmierungsrichtlinien werden erstellt.

• Die Alarmierungsrichtlinien sollten innerhalb von etwa 10 Minuten vollständig bereitgestellt sein.

Die Ressourcen werden über den Deployment Manager in der Google Cloud Console erstellt. Sobald die Ressourcen erstellt wurden, wird die Bereitstellung gelöscht, wobei die Ressourcen erhalten bleiben.

‍b)Mehrere Benachrichtigungskanäle hinzufügen (optional):cd /Securitylogalerts/Logalertmultiple./scripts.sh

Dieser Befehl fügt den Alarmierungsrichtlinien mehrere Benachrichtigungskanäle hinzu. Stellen Sie sicher, dass Sie die entsprechenden Namen der Benachrichtigungskanäle in der Datei „replace_notification_channel.sh“ vor der Ausführung des Skripts aktualisieren. Es aktualisiert die YAML-Dateien für Protokollalarmmetriken mit den zusätzlichen Benachrichtigungskanälen.

‍7. Alarmierungsrichtlinien testen

‍Dieses Skript testet die Alarmierungsrichtlinien, indem es:

• Ressourcen erstellt und löscht (z. B. Instanzen, Festplatten, Dienstkonten, Dienstkontoschlüssel und Firewall-Regeln).
• Warnmeldungen an den konfigurierten Benachrichtigungskanal sendet, um zu überprüfen, ob die Richtlinien ordnungsgemäß funktionieren.

‍8. Aktivität zur Ressourcenerstellung und -löschung

‍Nach der Ausführung von „alerttest.sh“, werden Ressourcen automatisch gemäß den Konfigurationen der Alarmierungsrichtlinien erstellt und gelöscht.

Alarme werden ausgelöst und an den konfigurierten Benachrichtigungskanal gesendet.

Zum Beispiel: Alarme für die Erstellung und Löschung von Dienstkontoschlüsseln.

Ähnliche Alarme für andere Ressourcen werden basierend auf der Ressourcenerstellung ausgelöst.

‍9.Projekt-Liens aktivieren:

‍cd /Securitylogalerts/

./Liens.sh

Führt das Skript „Liens.sh“ aus, das die Projekt-ID automatisch abruft und Liens für das Projekt aktiviert, um eine versehentliche Löschung zu verhindern.

Durch Befolgen dieser Schritte können Sie die Überwachungs- und Sicherheitsprozesse Ihrer Cloud-Umgebung automatisieren und stellen so sicher, dass Sie potenziellen Daten- und Umsatzverlusten vorbeugen und das Risiko versehentlicher Löschungen minimieren.

In der heutigen cloudbasierten Welt sollten sensible Daten so sicher wie möglich aufbewahrt werden. Die IP-Filterung ermöglicht es Ihnen, zu steuern, wer auf Ihren Speicher zugreift, indem Sie sie für Ihre Google Cloud Buckets aktivieren, sodass nur vertrauenswürdige Netzwerke Zugriff erhalten. Dieser Leitfaden führt Sie Schritt für Schritt durch die Einrichtung der IP-Filterung.

Was ist IP-Filterung?

Die IP-Filterung beschränkt den Zugriff auf einen Bucket, indem sie den Zugriff nur von bestimmten IP-Bereichen oder Netzwerken zulässt. Sie gewährt Zugriff auf Ihre Daten, während sie Traffic-Anfragen von unbekannten oder bösartigen Quellen blockiert.

Wichtige Anwendungsfälle für die IP-Filterung von Google Cloud Buckets

1. Compliance-Anforderungen

• Beschreibung: Stellen Sie sicher, dass nur autorisierte Benutzer auf den Bucket zugreifen können, um gesetzliche oder branchenspezifische Vorschriften zum Datenschutz zu erfüllen.‍
• Kernpunkt: Einhaltung gesetzlicher Vorschriften (Einhaltung von Datenschutzbestimmungen)

‍2. Öffentliche Buckets schützen

• Beschreibung: Verbesserte Sicherheit verhindert unbefugten Zugriff auf öffentlich zugängliche Buckets, indem der Traffic auf vertrauenswürdige IPs beschränkt wird. Dies schützt sensible öffentliche Ressourcen vor bösartigen Aktivitäten.‍
• Kernpunkt: Zugriffskontrolle für öffentliche Daten

‍3. VPC-Integration

• Beschreibung: Privates Networking beschränkt den Bucket-Zugriff auf bestimmte Virtual Private Cloud (VPC)-Netzwerke. Dies gewährleistet sichere Interaktionen innerhalb einer klar definierten Netzwerkbegrenzung und verbessert den Datenschutz.‍
• Kernpunkt: Netzwerk-spezifischer Zugriff

‍4. Kontrolliertes Testen

• Beschreibung: Die Zugriffsbeschränkung während der Testphasen stellt sicher, dass der Bucket-Zugriff nur auf ausgewählte IPs oder Systeme beschränkt ist. Dies gewährleistet die Kontrolle über die Testumgebung und reduziert unbeabsichtigte Datenexposition.‍
• Kernpunkt: Kontrolle der Testumgebung

‍5. Verbesserte Überwachung

• Beschreibung: Vereinfacht Audits, indem der Zugriff auf bekannte und vertrauenswürdige IPs beschränkt wird. Das heißt, indem der Zugriff nur von vertrauenswürdigen IPs zugelassen wird, reduzieren Sie die Anzahl unbekannter oder verdächtiger Interaktionen. Dies erleichtert die Nachverfolgung, wer wann auf den Bucket zugegriffen hat, vereinfacht Audits und verbessert die Transparenz.‍
• Kernpunkt: Vereinfachte Audit-Protokolle

‍Unterstützte Standorte

‍Die Bucket-IP-Filterung ist an den folgenden Standorten verfügbar:

• asia-south1
• asia-south2
• asia-southeast1
• asia-southeast2
• asia-east1
• asia-east2
• europe-west1
• europe-west2
• us-central1
• us-east1
• us-east4
• us-west1

‍Einschränkungen‍

Die Bucket-IP-Filterung weist die folgenden Einschränkungen auf:

• Maximale Anzahl von IP-CIDR-Blöcken: In der IP-Filterregel für einen Bucket können Sie maximal 200 IP-CIDR-Blöcke über öffentliche und VPC-Netzwerke hinweg angeben.
• Maximale Anzahl von VPC-Netzwerken: In den IP-Filterregeln für einen Bucket können Sie maximal 25 VPC-Netzwerke angeben.
• Unterstützung für zwei Regionen: Die IP-Filterung wird für Buckets mit zwei Regionen nicht unterstützt.
• Blockierte Google Cloud-Dienste: Das Aktivieren der IP-Filterung für Cloud Storage-Buckets schränkt den Zugriff für einige Google Cloud-Dienste ein, unabhängig davon, ob diese einen Dienst-Agenten für die Interaktion mit Cloud Storage verwenden.

‍So aktivieren Sie die IP-Filterung für Buckets

Schritt 1: Installieren Sie die Google Cloud CLI (Befehlszeilenschnittstelle) auf dem Server

‍Stellen Sie eine SSH-Verbindung zu Ihrer Instanz her und installieren Sie die Google Cloud CLI mit dem folgenden Befehl:

sudo snap install google-cloud-cli --classic

‍

Authentifizieren Sie sich bei Google Cloud:

gcloud auth login

Sie werden aufgefordert, den Zugriff auf Ihr Google-Konto zu gewähren.

Google Cloud SDK möchte auf Ihr Google-Konto zugreifen

Legen Sie die gewünschte Projekt-ID fest:

gcloud config set project [PROJECT_ID]

‍Schritt 2: Überprüfen Sie Ihren Bucket

1. Listen Sie alle Buckets in Ihrem Projekt auf: gcloud storage buckets list
2. Suchen Sie den Bucket-Namen, den Sie konfigurieren möchten.

‍Schritt 3: JSON-Konfiguration vorbereiten

‍Erstellen Sie eine JSON-Datei, um Ihre IP-Filterregeln zu definieren:

• Öffnen Sie einen Texteditor, um die Datei zu erstellen:

nano ip-filter-config.json oder vim ip-filter-config.json

• Fügen Sie die folgende Konfiguration hinzu und speichern Sie die Datei:

{

 "mode": "Enabled",

 "publicNetworkSource":

   {

   "allowedIpCidrRanges": ["RANGE_CIDR"]

   },

 "vpcNetworkSources":

     [

             {

                    "network": "projects/PROJECT_ID/global/networks/NETWORK_NAME",

                     "allowedIpCidrRanges": ["RANGE_CIDR"]

             }

     ]

}

Ersetzen Sie die IP-Bereiche und VPC-Netzwerkdetails durch Ihre spezifischen Anforderungen.

Schritt 4: Konfiguration anwenden

Führen Sie den folgenden Befehl aus, um Ihren Bucket mit der IP-Filterkonfiguration zu aktualisieren:

gcloud alpha storage buckets update [BUCKET_NAME(gsutil URI)] --ip-filter-file=ip-filter-config.json

‍Schritt 5: Konfiguration überprüfen

‍Nachdem Sie die Regeln angewendet haben, beschreiben Sie den Bucket, um die Änderungen zu bestätigen:

gcloud storage buckets describe [BUCKET_NAME(gsutil URI)]

Sie können die IP-Filterkonfiguration im Bucket sehen.

Schritt 5: Zugriff testen

• Stellen Sie sicher, dass Anfragen von zugelassenen IPs auf den Bucket zugreifen können.

• Überprüfen Sie, dass nicht-zugelassenen IPs der Zugriff verweigert wird.

So deaktivieren oder entfernen Sie die IP-Filterung IP-Filterung deaktivieren

• Um die Deaktivierung vorzunehmen, ändern Sie das JSON von „Enabled“ zu „Disabled“ und aktualisieren Sie den Bucket, um die geänderte Konfiguration anzuwenden.

{ 

 "mode": "Disabled",

 "publicNetworkSource":

   {

   "allowedIpCidrRanges": ["RANGE_CIDR"]

   },

 "vpcNetworkSources":

     [

             {

       "network": "projects/PROJECT_ID/global/networks/NETWORK_NAME",

                     "allowedIpCidrRanges": ["RANGE_CIDR"]

             }

     ]

}

‍

Aktualisieren Sie den Bucket mit der geänderten Konfiguration:

‍

gcloud alpha storage buckets update [BUCKET_NAME(gsutil URI)] --ip-filter-file=ip-filter-config.json

‍

Entfernen der IP-Filterkonfiguration

• So entfernen Sie eine bestehende IP-Filterkonfiguration aus dem Bucket:

gcloud alpha storage buckets update [BUCKET_NAME(gsutil URI)] --ipfiltering --clear-ip-filter

‍

Durch die Aktivierung der IP-Filterung können Sie Ihre Google Cloud Buckets vor unbefugtem Zugriff schützen und die Einhaltung der Sicherheitsrichtlinien Ihres Unternehmens gewährleisten. Ganz gleich, ob Sie sensible Daten sichern oder den Zugriff während Tests einschränken, diese Schritte bieten einen robusten Rahmen für die effektive Verwaltung der Bucket-Sicherheit.

IP-Filterregeln für Buckets umgehen:

Das Umgehen von IP-Filterregeln für Buckets befreit Nutzer oder Dienstkonten von IP-Filterbeschränkungen beim Erstellen, Löschen oder Konfigurieren von Buckets, während die Regeln für andere weiterhin durchgesetzt werden. Weitere Informationen zur IP-Filterung von Buckets finden Sie unter IP-Filterung von Buckets (https://cloud.google.com/storage/docs/ip-filtering-overview).

Es ist entscheidend, eine Möglichkeit zu haben, den Zugriff auf Ihren Bucket wiederherzustellen, falls Sie versehentlich Ihre eigene IP-Adresse blockieren. Dies kann aus folgenden Gründen geschehen:

• Bucket-Sperre: Wenn Sie versehentlich eine Regel hinzufügen, die Ihre eigene IP-Adresse oder den IP-Bereich Ihres gesamten Netzwerks blockiert.
• Unerwartete IP-Änderung: In einigen Fällen kann sich Ihre IP-Adresse aufgrund von Netzwerkänderungen unerwartet ändern, und Sie könnten sich ausgesperrt wiederfinden.

Um bestimmten Nutzern oder Dienstkonten das Umgehen von IP-Filterbeschränkungen für einen Bucket zu ermöglichen, erteilen Sie ihnen die Berechtigung storage.buckets.exemptFromIpFilter mithilfe einer benutzerdefinierten Rolle. Diese Berechtigung befreit den Nutzer oder das Dienstkonto von IP-Filterregeln für Bucket-Operationen wie das Erstellen, Löschen oder Konfigurieren von Buckets. Gehen Sie dazu wie folgt vor:

1. Identifizieren Sie den Nutzer oder das Dienstkonto, das die IP-Filterbeschränkungen für bestimmte Buckets umgehen muss.
2. Erstellen Sie eine benutzerdefinierte Rolle.(https://cloud.google.com/iam/docs/creating-custom-roles)
3. Fügen Sie die storage.buckets.exemptFromIpFilter Berechtigung zur Rolle hinzu.
4. Weisen Sie dem identifizierten Nutzer oder Dienstkonto die benutzerdefinierte Rolle auf Projektebene zu.

Informationen zum Zuweisen von Rollen finden Sie unter Rolle zuweisen (https://cloud.google.com/iam/docs/manage-access-service-accounts#grant-single-role)

Imagine you've just put the finishing touches on your latest application. Now comes the challenging part: deploying it on Google Cloud's Compute Engine instances. The initial setup is like assembling a complex jigsaw puzzle: creating a Managed Instance Group (MIG) with auto-scaling and auto-healing, pushing your dockerized application to Artifact Registry, configuring URL maps, forwarding rules, backends, and finally, a load balancer to distribute traffic.

In the current landscape of software development, while automating code improvement remains a challenge, optimizing infrastructure management for code updates is achievable. With the involvement of iterative development methodologies, it's crucial to minimize the time and effort required for code deployment. 

This blog introduces and executes an efficient Continuous Deployment (CD) pipeline leveraging Git triggers on Cloud Build within Google Cloud Platform (GCP). My approach integrates SSH key authentication, enhancing both security and automation. We'll explore how to set up a Git trigger that activates whenever changes are pushed to your repository. We'll dive into configuring Cloud Build to work with these triggers, incorporating crucial security elements like Secret Manager for handling sensitive credentials, setting up GitHub SSH keys for secure, and also setting up SSH keys to maintain secure access of your deployment on your GCP infrastructure and thus lead to seamless integration.

These steps eliminate the need for repetitive infrastructure setup with each code iteration, significantly reducing deployment overhead and enabling rapid, secure updates to your production environment.

Before jumping into the implementation, let's understand the concept of Continuous Deployment (CD) in the context of Git-based version control. CD is a DevOps practice where code changes are automatically built, tested, and deployed to production environments automatically. In the Google Cloud Platform (GCP) ecosystem, Cloud Build serves as a robust CI/CD tool that can ingest source code from diverse Version Control Systems (VCS) or cloud storage solutions, execute builds according to user-defined specifications, and generate deployment artifacts such as Docker images or Java ARchives (JARs).

Let's dive into setting up the whole CD pipeline now;

To implement GitHub triggers effectively, the initial step involves properly structuring and updating your repository with the latest codebase. It's absolutely necessary that the person configuring the Cloud Build trigger possesses the requisite permissions on the target repository. Specifically, they should have collaborator status or equivalent access rights to enable seamless integration between GitHub events and the deployment pipeline. This ensures that the CD system can respond to repository updates and initiate the deployment process. The flowchart below is an overview of the steps we will be learning and practicing today. 

If you are already familiar with all the services, go ahead and complete your deployment using this diagram.

Before proceeding with the setup, ensure that the Cloud Build API and the Secret Manager API are enabled in your Google Cloud environment. These can be activated via the Google Cloud Console's API Marketplace.

Establishing GitHub SSH keys for secure repository connection

For this, open up your cloud shell on your console and wait for it to connect. Now type in the following commands:

mkdir workingdir && cd workingdir

To generate your github key run this line replace the github-email with the email id that you have used to create your repository on Github

ssh-keygen -t rsa -b 4096 -N '' -f id_github -C github-email

‍
This generates a 4096-bit RSA key pair without a passphrase, which is crucial, as Cloud Build doesn't support passphrase-protected keys.

Secure Private Key Storage on Secret Manager

Now after the above steps you would have a private and a public Github key. The private key (id_github) must be securely stored in Secret Manager to prevent unauthorized access. To do so follow these steps:

a. Navigate to the Secret Manager in Google Cloud Console.

b. Select 'Create Secret'. 

c. Assign a descriptive name to the secret.

d. For the secret value, upload the 'id_github' file from your workingdir. 

e. Maintain default region settings unless specific requirements dictate otherwise.

 f. Finalize by clicking 'Create secret'

Once these steps are done you can be assured that your private key is protected and isn’t accessible to everyone.

Connecting to your Github repository

Now that you have your Git keys it is necessary to add the public key on GitHub so as to connect it to your infrastructure on GCP. So log into your GitHub account move into your repository page and follow these steps:

‍
  a. Move to the Settings tab of your repository

   c. In the sidebar, select 'Deploy Keys' and click 'Add deploy key'.

   d. Provide a descriptive title and paste the contents of 'workingdir/id_github.pub'. This is your public key

   e. Enable  'Allow write access'.

   f. Confirm by clicking 'Add key'.

Once you have added the Git keys to the Secret manager and your GitHub repository Access key section you can continue and remove the local copies. This adds another level of security and makes sure nobody else is able to access your GitHub key. To do so run this on your cloud shell:

 rm id_github*

Configuring Cloud Build Service Account Permissions

Now that you have the above set you need to make sure that the  Service Account that you are using has access to the Secret Manager.

   a. Navigate to the Cloud Build Settings page in Google Cloud Console.

   b. Select the service account for your build operations.

   c. Enable the 'Secret Manager Secret Assessor' role for this account.

Preparing Known Hosts for GitHub

The 'known_hosts' file is a critical component of SSH security, playing a vital role in preventing man-in-the-middle (MITM) attacks. Therefore, the final step is to set up your known hosts file.

 We save the GitHub public key for SSH verification in the known_hosts file. Go ahead use this command and create a known_hosts file in the working directory

  ssh-keyscan -t rsa github.com > known_hosts.github

Make sure to download the  'known_hosts.github' file to the appropriate location in the build environment, in this case your Github repository.

With the GitHub SSH keys properly configured and securely stored, the next critical step is to create your cloudbuild.yaml configuration file. This YAML file defines the series of steps Cloud Build will execute during the deployment process.

For deploying applications to Compute Engine instances via SSH, it's imperative to set up authentication keys with the appropriate access permissions. These keys will enable Cloud Build to securely push code and execute commands on your Compute Engine Managed Instance Groups (MIGs).

In the next section, we'll delve into the details of setting up these SSH keys for Compute Engine. This final piece will complete our Continuous Deployment (CD) pipeline, enabling automated deployments to Compute Engine MIGs via SSH.

Configuring SSH keys for secure access to Compute Engine instances

This step is crucial for ensuring that our Cloud Build processes can securely interact with our deployment targets. Let's walk through this process, addressing common pitfalls and best practices along the way.

1. Generating SSH Keys

Create a folder named ssh_keys on your Cloud Editor. Inside that, create a blank text file called id_rsa.txt. This is where your SSH keys will be stored: both public and private. 

Let's start by generating the SSH keys. Replace the italics values in the command below and run it on your cloud shell.

ssh-keygen -t rsa -f ~/enter_path_to_id_rsa.txt -C your_username -b 2048

The addition of 2048 generates a 2048-bit RSA key pair, which offers a good balance of security and performance.

2. Enter into your instance through the shell through the following command. Now the changes and the directories of files you make will all be saved in your instance memory. Make sure that you have allotted enough memory during instance formation or MIG template formation.

gcloud compute ssh username@instance_name --zone instance_zone

3. Adding SSH Keys to Compute Engine Metadata

Once you have your key pair, you need to add the public key to your Compute Engine instance's metadata. This allows you to access the SSH on that particular instance.This can be done using the following gcloud command paste this on the:

gcloud compute instances add-metadata instance_name \

    --metadata ssh-keys="username:$(location_of_public_key/id_rsa.pub)" \

    --zone instance_zone \

    --project project_id

Replace the name of the instance with your compute engine instance name, followed by your username, location of public key, zone in which the instance is created and finally your project id.

4. Configuring the Instance for SSH Access

Now that you have added the public key to your instance metadata, in order to access the instance you would need to add the private key in the authorized_keys file in the instance ssh folder. This private key is verified with your public key from the metadata to give access to the ssh and further processing.

On your Compute Engine instance paste the following commands to set up the authorized_keys file:

mkdir -p ~/.ssh

nano ~/.ssh/authorized_keys

The nano command opens an editor. Paste your key in this file and then save it accordingly.

Next, let's set up the correct permissions for the keys, paste these commands in the shell:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

These permissions are crucial for security - SSH will refuse to work if the permissions are too open.

5. Testing Your SSH Connection

Once you have executed all the above steps your SSH connection should be set. You can test your SSH connection using the verbose flag to diagnose any issues:

ssh -v -i ~/ssh_keys/id_rsa username@external_ip_of_instance

Diese Schritte führen zur Fertigstellung Ihres CD-Setups, und Sie können Ihren Code von GitHub nahtlos in Ihre Produktionsumgebung integrieren.

Bevor Sie vollständig startklar sind, stellen Sie sicher, dass Docker korrekt auf Ihrer Instanz installiert ist und läuft. Ein häufiges Problem bei der Arbeit mit Docker sind Authentifizierungsfehler.

HÄUFIGES PROBLEM

Wenn Sie beim Abrufen von Docker-Images Fehler wie 'Unauthenticated request' erhalten, müssen Sie möglicherweise die entsprechenden IAM-Rollen hinzufügen. Führen Sie dazu diesen Befehl aus:

gcloud projects add-iam-policy-binding project_id \

  --member=serviceAccount:service_account_name\

  --role=roles/artifactregistry.reader

Konfigurieren Sie Docker außerdem für die Authentifizierung mit GCR:

gcloud auth configure-docker gcr.io --quiet

Mit diesen Schritten ist Ihre Deployment-Pipeline zusammen mit der Continuous-Deployment-Pipeline einsatzbereit, und Sie können Updates direkt von GitHub nahtlos in Ihre Produktionsumgebung auf der Google Cloud Platform integrieren.

Es kann vorkommen, dass der gerade bereitgestellte Produktionscode trotz mehrfacher Überprüfung fehlschlägt und Sie zur vorherigen Version zurückkehren möchten. Dies lässt sich mit der Rollback-Methode beheben, bei der Sie zu einer früheren Version Ihres bereitgestellten Codes zurückkehren können. Dazu haben Sie eine Option über die Konsole, wo Sie ein Rollback auswählen können. Wenn Sie jedoch die Shell verwenden und den Vorgang dort ausführen möchten, folgen Sie diesem Befehl und ersetzen Sie ihn durch die korrekten Variablen.

gcloud deploy targets rollback TARGET_NAME \ --delivery-pipeline= PIPELINE_NAME \ --release= RELEASE_NAME \ --rollout-id= ROLLOUT_ID

Stellen Sie dabei sicher, dass die Bereitstellung von fehlerhaftem Code in der Produktion zu erheblichen Ausfallzeiten Ihrer Anwendung sowie zu Datenverlust führen kann. Vergewissern Sie sich daher, dass Ihr Code vollständig getestet ist und reibungslos unter Last läuft, bevor Sie ihn in die Produktion überführen.

Fazit

Die Bereitstellung von Anwendungen auf Google Cloud mit einer sicheren und automatisierten CD-Pipeline ist mehr als nur eine technische Errungenschaft – sie ist ein Schritt hin zu einer optimierten, effizienten Entwicklung. Durch die sorgfältige Konfiguration von SSH-Schlüsseln und die Nutzung von Git-Triggern gewährleisten Sie nicht nur die Integrität Ihres Bereitstellungsprozesses, sondern auch die Geschwindigkeit und Zuverlässigkeit Ihrer Updates. Dieser Ansatz eliminiert manuelle Fehler, reduziert den Betriebsaufwand und beschleunigt die Bereitstellung neuer Funktionen in der Produktion.

Während Sie Ihre Cloud-Infrastruktur weiter verfeinern, werden die Erkenntnisse aus der Einrichtung dieser Pipeline – wie die Absicherung von Anmeldeinformationen mit Secret Manager und die Optimierung Ihrer GitHub-Integration – als solides Fundament dienen. Mit diesem Setup halten Sie nicht nur mit der schnelllebigen Welt von DevOps Schritt; Sie übernehmen die Führung auf dem Weg in eine sicherere, automatisierte Zukunft.

Im ständig härter werdenden Wettbewerb um die Entwicklung schnellerer, intelligenterer und bewussterer LLMs bringt jeder neue Monat eine wichtige Ankündigung einer neuen Modellfamilie mit sich. Und da die Gemini 1.5-Familie, bestehend aus Nano, Flash, Pro und Ultra, seit Mai 2024 verfügbar ist, hatten viele Entwickler bereits die Gelegenheit, damit zu arbeiten. Und jeder dieser Entwickler kann Ihnen eines sagen: Gemini 1.5 ist nicht nur einen Schritt voraus. Es ist ein großer Sprung nach vorn. 

Gemini ist ein äußerst vielseitiges und funktionales Modell, es ist ausgestattet mit einem 2 Millionen Eingabe- Kontextfenster. Das bedeutet, dass Prompts riesig sein können. Man könnte meinen, dass dies zu Leistungsproblemen bei den Modellausgaben führen würde, aber Gemini liefert stets präzise, konforme und kontextbezogene Antworten, unabhängig von der Länge des Prompts. Und die Länge der Prompts bedeutet, dass Benutzer große Datendateien zusammen mit dem Prompt übermitteln können. Das 2 Millionen Token umfassende Eingabefenster entspricht 1 Stunde Videos, 11 Stunden Audio und 30.000 Zeilen Code, die gleichzeitig über Gemini 1.5 Pro analysiert werden können. 

Angesichts dessen variiert die Entscheidung, welchen Ansatz man für den Aufbau eines Konversationssystems mit Gemini 1.5 wählt, stark, je nachdem, was der Entwickler erreichen möchte. 

Alle Methoden erfordern ein allgemeines Einrichtungsverfahren: 

1. Google Cloud-Projekt: Ein GCP-Projekt mit aktivierter Vertex AI API, um auf das Gemini-Modell zugreifen zu können. 

2. Python-Umgebung: Eine Python-Umgebung, in der die erforderlichen Bibliotheken (vertexai, google-cloud-aiplatform) installiert sind.

3. Authentifizierung: Eine ordnungsgemäße Authentifizierungseinrichtung, die das Erstellen eines Dienstkontos mit Zugriff auf die VertexAI-Plattform umfasst: Rollen wie VertexAI User. Anschließend muss ein Schlüssel in die Anwendungsumgebung heruntergeladen werden. Dieses Dienstkonto muss als Standard-Anmeldeinformationen für die Anwendung in der Umgebung festgelegt werden: 

Python 

import os 

os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "path/to/service/account/key" 

4. Modellauswahl: Auswahl der geeigneten Gemini-Modellvariante (Nano, Flash, Pro, Ultra) basierend auf Ihren spezifischen Anforderungen. 

Gemini-Modelle können über das Python SDK, VertexAI oder über LLM-Frameworks wie Langchain aufgerufen werden. Für diesen Artikel werden wir uns jedoch auf die Verwendung des Python SDK beschränken, das installiert werden kann mit: 

Nicht festgelegt 

pip install vertexai 

pip install google-cloud-aiplatform 

Um Gemini über diese Methode aufzurufen, muss die VertexAI API in einem Google Cloud Projekt aktiviert sein. Die Details dieses Projekts müssen instanziiert werden, damit Gemini über das Client SDK aufgerufen werden kann. 

Python 

vertexai.init(project="project_id", location="project_location") 

Um von hier aus auf das Modell zuzugreifen und mit dem Prompting zu beginnen, muss eine Instanz des Modells aus dem GenerativeModel-Modul in VertexAI importiert werden. Dies kann geschehen durch: 

Python 

from vertexai.generative_models import GenerativeModel, ChatSession, Part model_object = GenerativeModel(model_name="gemini-1.5-flash-001", system_instruction="You are a helpful assistant who 

reads documents and answers questions.")

Von hier aus sind wir bereit, unser Konversationssystem zu prompten. Da Gemini jedoch so vielseitig ist, gibt es viele Methoden, um mit dem Modell zu interagieren, je nach Anwendungsfall. In diesem Beitrag werde ich die drei Hauptmethoden behandeln und diejenigen, die ich für den Aufbau von Architekturen am praktischsten halte: 

Interaktion in einer Chat-Sitzung

Generative Modelle von VertexAI können ihren eigenen Verlauf speichern, solange die Instanz geöffnet ist. Das bedeutet, dass kein externer Dienst zum Speichern des Konversationsverlaufs benötigt wird. Dieser Verlauf kann gespeichert, exportiert und weiter modifiziert werden. Das Verlaufsobjekt ist nun ein Attribut des ChatSession-Objekts, das wir zuvor importiert haben. Dieses ChatSession-Objekt kann instanziiert werden durch: 

Python 

chat = ChatSession(model=model_object) 

Weitere Attribute können hinzugefügt werden, einschließlich des bereits erwähnten Chat-Verlaufs, der es dem Modell ermöglicht, einen simulierten Verlauf zu haben, um die Konversation fortzusetzen. Dieses Chat-Sitzungsobjekt ist die Schnittstelle zwischen dem Benutzer und dem Modell. Wenn ein neuer Prompt an die ChatSession gesendet werden muss, kann dies durch die Verwendung von: 

Python 

chat.send_message(prompt, stream=False ) 

Diese Methode simuliert eine mehrstufige Chat-Sitzung, wobei der Kontext während der gesamten Konversation erhalten bleibt, solange die Instanz der Chatsitzung aktiv ist. Der Verlauf wird vom Chatsitzungsobjekt verwaltet, was es dem Benutzer ermöglicht, weitere auf Vorhergehendem basierende Fragen zu stellen, wie z.B. „Was meintest du damit?“, „Wie kann ich das verbessern?“, wenn das Objekt nicht klar ist. Diese Chatsitzungsmethode ist ideal für Chat-Interface-Szenarien wie Chatbots, persönliche Assistenten und mehr. 

Der vom Modell erstellte Verlauf kann später gespeichert und während der Instanziierung des Chatsitzungsmodells wie folgt neu geladen werden: 

Python 

messages = chat.history 

chat = ChatSession(model=model, history=history) 

Von hier aus kann die Chatsitzung im Multiturn-Chat-Format fortgesetzt werden. Diese Methode ist sehr unkompliziert und macht externe Frameworks wie Langchain zur Verwaltung von Konversationen und deren Rückladen in das Modell überflüssig. Diese Methode bewahrt die volle Funktionalität der Gemini-Modelle und minimiert gleichzeitig den Aufwand für eine vollständige Chat-Oberfläche.

Single-Turn-Chat-Methode

Wenn die erforderliche Funktionalität keine Multiturn-Chat-Methodik erfordert oder kein Verlauf gespeichert werden muss, enthält das Gemini SDK Methoden, die als Single-Turn-Chat-Methode funktionieren, ähnlich wie Schnittstellen zur Bildgenerierung. Jeder 

Aufruf an das Modell fungiert als unabhängige Sitzung ohne Sitzungsverfolgung oder Kenntnis früherer Konversationen. Dies reduziert den Aufwand, der zur Erstellung der Schnittstelle erforderlich ist, während immer noch eine voll funktionsfähige Lösung vorhanden ist. 

Für diese Methode kann das Modellobjekt direkt verwendet werden, wie folgt: 

Python 

model = genai.GenerativeModel("gemini-1.5-flash") 

response = model.generate_content("What is the capital of Karnataka?") print(response.text) 

Hier wird eine Nachricht direkt an das Modell gesendet, ohne dass Verlauf oder Kontext zum Prompt hinzugefügt werden. Diese Methode ist vorteilhaft für jeden Anwendungsfall, der nur eine Single-Turn-Nachrichtenübermittlung erfordert, zum Beispiel Grammatikkorrektur, einige grundlegende Vorschläge und mehr. 

Kontext-Caching

Typischerweise werden LLMs nicht eigenständig verwendet, sondern mit einer Wahrheitsquelle geerdet. Dies ermöglicht es ihnen, bei der Beantwortung von Fragen auf eine Wissensbasis zurückzugreifen, was die Wahrscheinlichkeit verringert, dass sie halluzinieren oder Informationen falsch wiedergeben. Dies wird durch die Verwendung eines RAG-Systems erreicht. Gemini 1.5 macht diesen Prozess jedoch überflüssig. Natürlich könnte man den extrahierten Text eines Dokuments vollständig in den Prompt einfügen, aber wenn ein Dokumentencache zu groß ist – 33.000 Token oder mehr – hat VertexAI eine Methode dafür: Kontext-Caching. 

Kontext-Caching funktioniert, indem eine ganze Reihe von Dokumenten zusammen mit dem Modell in eine Variable übertragen und eine Chatsitzung aus diesem Cache initiiert wird. Dies macht die Erstellung einer RAG-Pipeline überflüssig, da das Modell bei Bedarf auf die Dokumentation zugreifen kann. 

Python 

contents = [ 

Part.from_uri( 

"gs://cloud-samples-data/generative-ai/pdf/2312.11805v3.pdf", 

mime_type="application/pdf", 

), 

Part.from_uri( 

"gs://cloud-samples-data/generative-ai/pdf/2403.05530.pdf", 

mime_type="application/pdf", 

),

] 

cached_content = caching.CachedContent.create( 

model_name="gemini-1.5-pro-001", 

system_instruction=system_instruction, 

contents=contents, 

ttl=datetime.timedelta(minutes=60), 

) 

Die zwischengespeicherten Dokumente können von jedem GCP-Speicherort bezogen und in ein Part-Objekt formatiert werden. Diese Part-Objekte sind im Wesentlichen ein Datentyp, der die Multi-Turn-Chat-Formate bildet. Diese Objekte werden zusammen mit dem Prompt in einer Liste gesammelt und an das Cache-Objekt übergeben. Neben den Inhalten wird auch ein Time-to-Live-Parameter erwartet. Dieser legt eine Ablaufzeit für den Cache fest, was zur Sicherheit und Speicherverwaltung beiträgt. 

Um diesen Cache nun zu verwenden, muss ein Modell aus der Cache-Variable erstellt werden. Dies kann wie folgt geschehen: 

Python 

model = GenerativeModel.from_cached_content(cached_content=cached_content) response = model.generate_content("What are the papers about?") 

#alternativ kann ein ChatSession-Objekt mit diesem Modell verwendet werden, um eine mehrstufige Chat-Schnittstelle zu erstellen. 

Der entscheidende Vorteil der Gemini 1.5 Modellfamilie ist ihre unübertroffene Unterstützung für multimodale Prompts. Die Part-Objekte können verwendet werden, um alle Arten von Eingaben zu kodieren. Durch Anpassen des mime-type-Parameters kann das Part-Objekt jede Art von Eingabe darstellen, einschließlich Audio, Video und Bildern. Unabhängig vom Eingabetyp kann das Objekt der Eingabeliste hinzugefügt werden, und das Modell wird es genau so interpretieren, wie Sie es benötigen.

Und voilà! Sie haben Ihren ganz eigenen multimodalen KI-Assistenten mit Gemini 1.5 erstellt. Beachten Sie, dass dies nur ein Ausgangspunkt ist. Das VertexAI SDK bietet Funktionen, die den Aufbau komplexer Agentic-Systeme, Bildgenerierung, Modelloptimierung und vieles mehr unterstützen. Der Umfang der grundlegenden Modelle von Google und die umgebende Unterstützungsstruktur wachsen stetig und verleihen erfahrenen Entwicklern und Neulingen gleichermaßen eine beispiellose Leistungsfähigkeit, um bahnbrechende, äußerst effektive und verantwortungsvolle Anwendungen zu entwickeln.

Heute werden wir einen vollständig automatisierten Sprachbot aufbauen oder einen Callcenter-Flow einrichten, der Ihnen Echtzeit-Konversationen ermöglicht, indem wir die in der Amazon Konsole verfügbaren Dienste Amazon Connect, Lex V2, DynamoDB, S3 und Lambda Function nutzen. Der Sprachbot ist auf Deutsch erstellt, und unten ist der gesamte Ablauf dargestellt, der in diesem Blogbeitrag beschrieben wird.

Vorteile der Nutzung von Lex-Bot

• Lex ermöglicht jedem Entwickler, schnell konversationelle Chatbots zu erstellen.

• Es ist keine tiefgehende Deep-Learning-Expertise erforderlich – um einen Bot zu erstellen, geben Sie einfach den grundlegenden Konversationsfluss in der Amazon Lex Konsole an. Der ASR-Teil (Automatic Speech Recognition) wird intern von Lex übernommen, sodass wir uns darum keine Sorgen machen müssen. Sie integrieren nahtlos Lambda-Funktionen, DynamoDB, Cognito und andere AWS-Dienste.

• Im Vergleich zu anderen Diensten ist Amazon Lex kostengünstig.

Architekturdiagramm

Architektur

Innerhalb der AWS-Umgebung, Amazon Connect ist ein nützliches Tool zur Einrichtung eines Callcenters. Es erleichtert Kundengespräche und schafft einen reibungslosen Ablauf, der mit einem auf Deutsch trainierten Lex v2 Bot kombiniert wird. Dieser Bot ist darauf ausgelegt, eine Reihe von Kundeninteraktionen zu verwalten und dabei wichtige Daten über Slots (bestimmte Datenpunkte, die der Bot benötigt) und Intents (Aktionen, die der Bot ausführen könnte) zu sammeln. Der Lex-Bot wird dann an eine Lambda-Funktion angehängt, die ausgelöst wird, wenn der Kunde mit einem Produktnamen antwortet. Andernfalls verbindet sie den Kunden direkt mit einem menschlichen Agenten für weitere Anfragen. 

Die Lambda-Funktion ermittelt zunächst den Produktnamen aus der Kundeneingabe und vergleicht ihn dann mit der Produktliste, die wir im S3-Bucket haben. Dort sind Details wie Preis, Gewicht, Größe usw. aus einer Excel-Tabelle (Excel-Tabelle) hinterlegt, die derzeit nur zwei Produkte enthält, nämlich Samsung Galaxy S24 und Apple iPhone 15, mit deren Preisen, Gewichten und Größen. Die Eingabe des Kunden wird mithilfe des Fuzzy-Matching-Algorithmus mit dem ähnlichsten Produktnamen in der Excel-Tabelle abgeglichen.

Der Schwellenwert für diesen Produktabgleich ist auf 60 oder mehr festgelegt und kann je nach Bedarf angepasst werden. Nur wenn der Kunde bestellen möchte, beginnt der Bot mit der Erfassung von Kundendaten wie Name und weiteren Details. Der Bot verfügt über einen Bestätigungsblock, der dem Kunden mitteilt, was er aus der Kundeneingabe verstanden hat (wie eine Überprüfung). Wenn der Kunde dies nicht bestätigt, fragt er erneut nach diesem spezifischen Intent. Bei Bedarf können wir die Wiederholungslogik hinzufügen. Hier ist eine maximale Wiederholungsanzahl von 3 für alle Kundendaten festgelegt, um sicherzustellen, dass der Bot die richtigen Daten von den Kunden abruft, während er von Sprache in Text (ASR) transkribiert. 

Nachdem die Daten vom Kunden abgerufen wurden, können wir vor dem Speichern überprüfen, ob die gesammelten Daten gültig sind, indem wir sie an das Mixtral 8x7B Instruct v0.1 Modell übergeben. Ich verwende dieses Modell, da meine Konversation auf Deutsch stattfindet und das Mistral-Modell in Deutsch und anderen Sprachen trainiert wurde, was die Verarbeitung für mich erleichtert. Dieses Modell wird über den Amazon Bedrock-Dienst aufgerufen. Wir rufen dieses Modell in der Lambda-Funktion auf, die eine Prompt-Vorlage enthält, die eine Reihe von Anweisungen beschreibt. Zum Beispiel gebe ich hier Anweisungen wie „extrahieren Sie einfach den Produktnamen aus der Eingabe des Anrufers“. Nachdem die Antwort vom LLM erhalten wurde, wird die Ausgabe dann zusammen mit den Originaldaten und den Anrufaufzeichnungssegmenten aus dem S3-Bucket als Session-Attribute im untenstehenden Code-Snippet gespeichert.

def update_custom_attribute(event, field_name, field_value):

    session_state = event['sessionState']

    if 'sessionAttributes' not in session_state:

        session_state['sessionAttributes'] = {}

    if 'userInfo' not in session_state['sessionAttributes']:

        user_info = {}

    else:

        user_info = json.loads(session_state['sessionAttributes']['userInfo'])

updated_session_state = update_custom_attribute(event, 'name', name_value)

return {

            "sessionState": {

                "dialogAction": {

                    "type": "ElicitSlot",

                    "slotToElicit": "country"

                },

                "intent": {

                    "name": "CountryName",

                    "state": "InProgress",

                    "slots": {}

                },

                "sessionAttributes": updated_session_state['sessionAttributes']

            },

            "messages": [

                {

                    "contentType": "PlainText",

                    "content": "Wie lautet der Name Ihres Landes?"

                }

            ]

        }

Schließlich werden die Aufzeichnungen in der DynamoDB gespeichert, wobei die Zeit als Primärschlüssel dient, damit jeder Datensatz eindeutig ist.

AMAZON CONNECT

So sieht die Benutzeroberfläche von Amazon Connect aus. Sie können eine neue Instanz erstellen, indem Sie auf die Schaltfläche „Instanz hinzufügen“ klicken. Sie können den Namen der URL-Connect-Instanz angeben. Nachdem Sie die Instanz erstellt haben, klicken Sie auf die Notfall-Anmelde-/Zugriffs-URL (melden Sie sich mit dem Benutzerkonto an, das Sie bei der Erstellung der Instanz erstellt haben).

Die Abbildung unten zeigt die Erstellung von gebührenfreien Nummern, wo Sie das Telefon-Symbol auswählen, die Telefonnummer auswählen und auf „Nummer beantragen“ klicken. Wählen Sie dann die Stimme für den Voicebot und das Land aus, für das Sie die Nummer erstellen möchten, und klicken Sie auf die Schaltfläche „Speichern“. Beachten Sie, dass Sie beim Beantragen einer Nummer für einige Länder Nachweise einreichen müssen. Beachten Sie dieses Dokument [1] . 

Erstellen Sie als Nächstes die Arbeitszeiten über den Flow-Pfeil in der Konsole. Ich habe eine Zeit von 9:00 Uhr bis 17:00 Uhr festgelegt, damit ich den Anruf an einen menschlichen Agenten weiterleiten kann, falls der Anrufer Fragen hat. Wenn Sie jedoch möchten, dass Ihr Voicebot rund um die Uhr verfügbar ist, ändern Sie die Verfügbarkeit oder erstellen Sie neue Betriebszeiten.

Erstellen Sie als Nächstes eine Warteschlange und fügen Sie die Betriebszeiten in die Warteschlange ein. Das war's, wir sind fast fertig mit der Einrichtung einiger Dinge in Amazon Connect. Schauen wir uns nun die Flows an und sehen, wie unser kompletter Flow aussieht.

Das obige Diagramm zeigt den Amazon Connect Flow, wobei der Block „Stimme einstellen“ verwendet wird, um eine bestimmte Stimme festzulegen. Der Block „Protokollierungsverhalten festlegen“ und „Aufzeichnungs- und Analyse-Verhalten festlegen“ werden verwendet, um das Gespräch nach der Verbindung mit dem Agenten aufzuzeichnen. „Aufforderung abspielen“ wird verwendet, um eine einfache Aufforderung zu beantworten, die besagt, dass der Anruf aufgezeichnet wird. Der Block „Kontaktattribute festlegen“ enthält zwei Sitzungsattribute: eines, um sich auf die Stimme des Benutzers statt auf Hintergrundgeräusche zu konzentrieren, und ein weiteres, um nicht dazwischenzufahren, wenn der Bot antwortet. Nach dem Hinzufügen dieser beiden Sitzungsattribute in den Connect Flow kann der Anruf den Flow passieren, selbst wenn ein gewisses Maß an Hintergrundgeräuschen vorhanden ist. Der Block „Kundeneingabe abrufen“ wird verwendet, um den Anruf mit dem Lex-Bot zu verbinden. Wenn der Kunde mit dem Agenten verbunden werden möchte, stellt die Einstellung der Arbeitswarteschlange sicher, dass die Verbindung zum Agenten hergestellt wird. Schließlich wird der Anruf mit dem Block „Verbindung trennen“ beendet.

AMAZON LEX

Als Nächstes können wir einen Bot von Grund auf neu erstellen, indem wir auf das Symbol „Bot erstellen“ in der Lex-Konsole klicken. Sie können den Namen des Bots mit den erforderlichen IAM-Berechtigungen angeben und „Nein“ für den Kinderschutz auswählen. Im nächsten Schritt wählen Sie die Sprache aus, in der Ihr Bot trainiert werden soll, und wählen die Stimme aus. Der Intent-Klassifizierungswert liegt zwischen 0 und 1. Dies ähnelt einem Schwellenwert, bei dem der Bot den Grund des Kunden/Benutzers klassifizieren kann. Wenn ich beispielsweise mehrere Intents habe, verbindet er sich basierend auf dem Wert mit dem wahrscheinlichsten Intent. Sie können auch mehrere Sprachen hinzufügen, um Ihren 

Bot zu trainieren.

Sie können einen Intent erstellen, um den Grund des Kunden/Anrufers für den Anruf zu erfahren, z. B. „Ein Mobiltelefon bestellen“. In unserem Fall erwarten wir einen Produktnamen vom Kunden, wie Samsung Galaxy oder Apple iPhone. Die Beispieläußerungen werden verwendet, um das Gespräch mit dem Bot ganz am Anfang des Gesprächs zu initiieren. Zum Beispiel können wir „Hallo“, „Ich möchte bestellen“ usw. sagen, um den Intent auszulösen, von dem Sie erwarten, dass Ihr Bot basierend auf dem Kundenwunsch antwortet. Wenn Sie mehrere Intents wie Begrüßungen, Bestellung, Adresse haben, verbinden Sie diese Intents nacheinander in einem Flow mithilfe des „Gehe zu Intent“-Blocks.

Slots werden verwendet, um den Intent zu erfüllen. Zum Beispiel muss der Bot hier wissen, welches Produkt der Kunde bestellen möchte, um diesen Begrüßungs-Intent abzuschließen. Ebenso können Sie Slots in einem einzelnen Intent erstellen oder separate Slots in jedem Intent erstellen und diese im Flow verbinden. Der Bestätigungsblock wird verwendet, um die Benutzereingabe, wie den Produktnamen, basierend auf der Antwort des Kunden erneut zu überprüfen (sagt der Kunde „Ja“, geht es zum nächsten Schritt; sagt er „Nein“, geht es zum vorherigen Zustand zurück und fragt erneut).

Sie können die Genauigkeit des Lex-Bots verbessern, indem Sie die Spracherkennung (ASR) dessen, was der Kunde sagt, verbessern. Dies geschieht durch das Erstellen eines benutzerdefinierten Slot-Typs und das Trainieren des Bots mit einigen Beispielen dessen, was der Kunde sagen könnte. In unserem Fall könnte der Kunde beispielsweise Produktnamen wie iPhone, Apple iPhone, iPhone 15 usw. nennen. Fügen Sie daher einige Werte in die Slot-Äußerungen ein, was die Spracherkennung verbessern kann. Sie können mehrere benutzerdefinierte Slot-Typen erstellen, z. B. Produktname, Kundenname, Adresse usw.

Sie können auf die Option „Visual Builder“ klicken, um Ihren Flow im Lex V2 Bot anzuzeigen. Lassen Sie uns besprechen, was jeder Block tut, und wir können diese Blöcke einfach per Drag & Drop ziehen, um den Flow zu erstellen. Lambda-Blöcke oder Code-Hook-Blöcke werden im Flow verwendet, wenn Ihr Bot Informationen von verschiedenen Diensten abrufen soll (S3, was in einer Lambda-Funktion geschieht). Zum Beispiel sind meine Produktdetails wie Preis, Größe, Gewicht alle in einem S3-Bucket gespeichert, um die Daten abzurufen, und wir verwenden auch Fuzzy-Logik, um die am besten passende Antwort zu finden. Wir können nur eine Lambda-Funktion pro Bot aufrufen, daher haben wir die Logik hinzugefügt, die die Kundeneingabe zur Überprüfung an das Mistral 8X7 Modell weiterleitet und die endgültige Ausgabe mit dem Audio-Ordner in der DynamoDB speichert.

Lambda-Funktion

Diese Lambda-Funktion wird verwendet, um die Produktinformationen abzurufen, nachdem die Eingabe des Kunden erfasst wurde. Wenn der Kunde beispielsweise „Apple iPhone“ sagt, ruft die Lambda-Funktion die Details aus dem S3-Bucket ab und gleicht diese mithilfe der Fuzzy-Logik ab, wobei wir einen Schwellenwert von 80 oder mehr festgelegt haben. Wenn der Score der Benutzereingabe den Schwellenwert erreicht, werden die Produktdetails zurückgegeben und zum nächsten Intent übergegangen. Der Bot erwartet eine Antwort innerhalb von 3-4 Sekunden, nachdem er die Benutzerabsicht abgefragt hat. Wird keine Antwort empfangen (wenn der Anrufer stumm ist oder nichts gesagt hat), hat der Bot ursprünglich den leeren String als Antwort interpretiert und direkt eine Verbindung zum Agenten hergestellt. Wir haben jedoch eine Logik implementiert, um den Ablauf fortzusetzen, indem bei einer leeren Eingabe erneut nach der Eingabe gefragt wird. In der nächsten Sitzung sehen wir uns an, wie Daten in einer DynamoDB-Tabelle gespeichert werden. Beachten Sie die untenstehenden Referenzen.

Beispielanrufe

Nachdem die Begrüßung empfangen wurde, werden die Informationen zu den verfügbaren Produkten mitgeteilt und es wird gefragt, nach welchem Produkt gesucht wird.

Nach Erhalt des Produktnamens erklärt der Bot die Produkte und fragt nach einer Bestellbestätigung. Wenn ja, beginnt er mit der Erfassung der Anruferdaten. Wenn nein oder wenn keine Produkte den Anforderungen des Anrufers entsprechen, wird eine Verbindung zum menschlichen Agenten hergestellt, um weitere Informationen zu erhalten.

Auf dem obigen Bild werden Details wie Name und Länderinformationen des Anrufers erfasst.

Anschließend werden der Stadtname und der Straßenname des Anrufers erfasst.

Zuletzt werden die Postleitzahl/PLZ erfasst und eine Dankesnachricht mit einer Bestellbestätigung von Lex gesendet. Diese Bilder beschreiben den vollständigen Ablauf, wie Amazon Lex auf den Kunden reagiert. Es wurde eine Wiederholungslogik von maximal 3 Versuchen integriert, bei der der Bot den Kunden erneut fragt, wenn er die Kundenabsicht nicht verstehen kann. Der Bot wurde darauf trainiert, eine Verbindung zu einem menschlichen Agenten herzustellen, wenn er nicht antworten kann oder wenn der Kunde direkt angibt, mit einem Agenten sprechen zu wollen. Nach Erreichen des Fallbacks für die E-Mail-Adressen-Absicht wird eine Dankesnachricht ausgegeben und eine Verbindung zum Agenten hergestellt, falls der Kunde Fragen hat.

Referenzen

Regionale Anforderungen für die Bestellung und Portierung von Telefonnummern – Amazon Connect

Flow-Block: Kundeneingabe erfassen – Amazon Connect

Timeouts für die Erfassung von Benutzereingaben konfigurieren – Amazon Lex