Denna artikel presenterar ett projekt POC (Proof of Concept) för den automatiserade distributionen av LibreChat på AWS EC2, med Terraform för att orkestrera infrastrukturen enligt principen Infrastructure as Code, ett User-Data Bash-skript för att installera komponenter på EC2, och AWS Systems Manager för centraliserad hantering av API-nycklar och uppföljning av distributionen. Fokus ligger på automatisering och kostnadsoptimering genom användning av Spot-instanser.
Introduktion
LibreChat är en avancerad chattbot-applikation som integrerar flera AI-modeller, inklusive Mistral AI, och erbjuder funktioner som söker i konversationer, skapar anpassade förinställningar, redigerar och fortsätter meddelanden, samt plugin-integration. Den erbjuder ett flerspråkigt och multimodalt användargränssnitt, fleranvändarhantering med säker autentisering och är helt öppen källkod. Detta projekt utforskar dess distribution på AWS EC2 med avancerade verktyg för en helt automatiserad implementering.
Arkitektur
Den utplacerade arkitekturen inkluderar följande element:
- En
EC2
instans som körUbuntu Server
. - Ett
User-Data
bash-skript för att automatisera installation och konfiguration av nödvändiga komponenter för LibreChat. Terraform
för att definiera och tillhandahålla den AWS-infrastruktur som behövs för att distribuera LibreChat.AWS Systems Manager (SSM)
för att lagra och hämta de API-nycklar som behövs för LibreChat och följa distributionens framsteg.
Automatisering och Infrastructure as Code
Terraform
Terraform är ett verktyg som gör det möjligt att definiera och tillhandahålla infrastruktur som kod (Infrastructure as Code). I detta projekt används Terraform för att skapa och konfigurera EC2-instansen samt de tillhörande AWS-resurserna, såsom säkerhetsgrupper och IAM-roller.
User-Data
User-Data bash-skriptet körs vid första uppstarten av EC2-instansen. Det automatiserar installationen och konfigurationen av de komponenter som behövs för LibreChat, såsom Docker, Docker Compose, Git, Node.js och NPM. User-Data-skriptet gör det också möjligt att konfigurera de API-nycklar som behövs för LibreChat, såsom OpenAI, MistralAI, Anthropic, Google API och Google CSE ID, genom att hämta dem från AWS Systems Manager (SSM).
En funktion update_status
är definierad i User-Data-skriptet för att uppdatera distributionsstatusen via AWS SSM. Denna funktion möjliggör övervakning av distributionsstatusen och snabb upptäckt av eventuella problem. User-Data-skriptet skickar också funktionen update_registration.sh
och lägger till den i cron för att aktivera eller inaktivera registreringar.
Exempel på funktionen update_status
:
update_status() {
STATUS_MESSAGE=$1
aws ssm put-parameter --name "/librechat/deployment-status" --type "String" --value "$STATUS_MESSAGE" --overwrite --region $AWS_DEFAULT_REGION
}
Exempel på funktionen update_registration.sh
:
#!/bin/bash
set -e
# Update registration status in SSM Parameter Store
aws ssm put-parameter --name "/librechat/registration_enabled" --type "String" --value "$1" --overwrite --region $AWS_DEFAULT_REGION
# Update LibreChat configuration file
if [ "$1" == "true" ]; then
sed -i 's/enabled: false/enabled: true/g' /opt/librechat/config.yaml
else
sed -i 's/enabled: true/enabled: false/g' /opt/librechat/config.yaml
fi
# Restart LibreChat service
systemctl restart librechat
Funktionen update_registration.sh
används för att uppdatera statusen för aktivering av registreringar i SSM Parameter Store och konfigurationsfilen för LibreChat. Tjänsten LibreChat startas sedan om för att tillämpa ändringarna.
Uppföljning av distributionsframstegen med SSM
AWS Systems Manager (SSM) är en tjänst som gör det möjligt att hantera och konfigurera EC2-instansen centralt. I detta projekt används SSM för att lagra och hämta de API-nycklar som behövs för LibreChat samt för att följa upp distributionsframstegen.
En funktion check_deployment_status
är också definierad i skriptet export.sh
för att kontrollera distributionsstatusen via AWS SSM. Den här funktionen gör det möjligt att i realtid följa deploymentens förlopp och snabbt upptäcka eventuella problem.
Exempel på funktionen check_deployment_status
:
check_deployment_status() {
LAST_STATUS=""
INSTANCE_ID=$(terraform output -raw instance_id) # Récupère l'ID de l'instance Terraform.
if [ -z "$INSTANCE_ID" ]; then
echo "Aucune instance EC2 n'est actuellement déployée ou terraform output n'est pas configuré correctement."
return 1
fi
IP_ADDRESS=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID --query "Reservations[*].Instances[*].PublicIpAddress" --output text --region $AWS_DEFAULT_REGION 2>/dev/null)
URL="https://$IP_ADDRESS/"
echo "Vérification de l'état de déploiement..."
ATTENTE_STATUS=true # Utilisée pour contrôler l'affichage du message d'attente.
while true; do
STATUS=$(aws ssm get-parameter --name "/librechat/deployment-status" --query "Parameter.Value" --output text --region $AWS_DEFAULT_REGION 2>/dev/null)
if [ $? -ne 0 ]; then
if [ "$ATTENTE_STATUS" = true ]; then
echo -ne "\rEn attente des informations de statut de déploiement.\n"
ATTENTE_STATUS=false # Empêche la répétition du message.
fi
sleep 1
continue
else
ATTENTE_STATUS=true # Réinitialise pour le prochain cycle.
fi
if [[ "$STATUS" != "$LAST_STATUS" ]]; then
if [[ "$LAST_STATUS" != "" ]]; then
echo -e " \e[32m✓\e[0m" # Affiche une coche verte pour le statut précédent.
fi
echo -ne "\rÉtat actuel du déploiement : $STATUS"
LAST_STATUS="$STATUS"
if [[ "$STATUS" == "100% - Installation terminée" ]]; then
echo -e "\n\e[32m✓ Installation terminée avec succès\e[0m"
echo -e "Accédez à l'instance Librechat via : $URL"
break
elif [[ "$STATUS" == "Echec de l'installation" ]]; then
echo -e "\n\e[31m✗ Échec de l'installation\e[0m"
exit 1
fi
fi
sleep 1
done
}
}
Deploymentsstatusen lagras i en SSM-parameter, vilket gör att man kan kontrollera deploymentens status när som helst och varifrån som helst.
Felhantering med set -e
och trap 'error_handler' ERR
I User-Data-skriptet har en robust felhantering implementerats med set -e
och trap 'error_handler' ERR
. Denna metod garanterar att skriptet omedelbart stannar vid ett fel och ger detaljerad information om det uppstående problemet.
Här är ett utdrag ur User-Data-skriptet med integrerad felhantering:
#!/bin/bash
set -e
trap 'error_handler' ERR
error_handler() {
local error_message=$1
echo "Error occurred: ${error_message}"
update_status "ERROR: ${error_message}"
exit 1
}
update_status() {
STATUS_MESSAGE=$1
aws ssm put-parameter --name "/librechat/deployment-status" --type "String" --value "$STATUS_MESSAGE" --overwrite --region $AWS_DEFAULT_REGION
}
Funktionen error_handler
anropas varje gång ett fel uppstår i skriptet. Den tar ett felmeddelande som parameter, visar det i konsolen, uppdaterar deploymentens status via AWS SSM med funktionen update_status
och avslutar skriptet med en felkod.
Tack vare set -e
och trap 'error_handler' ERR
stannar deploymenten så fort ett fel uppstår, vilket underlättar debugging och problemlösning. Dessutom gör uppdateringen av deploymentens status i AWS SSM det möjligt att följa förloppet och snabbt upptäcka eventuella problem.
Kostnadsreducering med Spot Instances
Spot Instances är EC2-instansar som gör det möjligt att använda oanvänt kapacitet till reducerade priser jämfört med On-Demand-instanser. I det här projektet används Spot Instances för att minska kostnaderna för att hosta applikationen. User-Data-skriptet stödjer konfigurationen av Spot Instances, vilket möjliggör betydande kostnadsbesparingar utan att kompromissa med applikationens prestanda.
Gemensam användning av export.sh
i den automatiserade deploymenten av LibreChat på AWS EC2
Som en del av den automatiserade deploymenten av LibreChat på AWS EC2 har ett shell-skript kallat export.sh
skapats för att underlätta hanteringen av de olika uppgifterna relaterade till deployment och konfiguration av infrastrukturen. Detta skript används både från den lokala arbetsstationen och i GitLab CI-pipelines, vilket möjliggör en gemensam och konsekvent användning av de funktioner som det innehåller.
Skriptet export.sh
samlar flera användbara funktioner för deployment och hantering av AWS-infrastruktur. Bland dessa finns:
terraform_plan
: genererar en Terraform-plan för att förhandsgranska de ändringar som ska göras på infrastrukturen.terraform_apply
: tillämpar Terraform-ändringarna på AWS-infrastrukturen.terraform_destroy
: tar bort de Terraform-resurser som skapats under deployment.check_deployment_status
: kontrollerar status för pågående deployment genom att fråga AWS SSM.
Här är ett exempel på hur dessa funktioner används i en GitLab CI-pipeline:
stages:
- Vérifications
- Déploiements
- Suppressions
Vérification Terraform:
stage: Vérifications
script:
- /bin/bash -c "source export.sh && terraform_plan"
Déploiement Terraform:
stage: Déploiements
script:
- /bin/bash -c "source export.sh && terraform_apply && check_deployment_status"
Suppression Terraform:
stage: Suppressions
script:
- /bin/bash -c "source export.sh && terraform_destroy"
I detta exempel används funktionerna terraform_plan
, terraform_apply
och terraform_destroy
i de olika stegen av GitLab CI-pipelinen. Genom att sourca skriptet export.sh
blir de funktioner som det innehåller tillgängliga i pipeline-exekveringsmiljön.
Den gemensamma användningen av export.sh
mellan den lokala arbetsstationen och GitLab CI underlättar hanteringen av den automatiserade deploymenten av LibreChat på AWS EC2. De funktioner som finns i detta skript förenklar uppgifterna och säkerställer en konsekvens i de operationer som utförs på infrastrukturen.
För att lära dig mer om projektet och se källkoden, besök GitLab-repo. Du hittar detaljerad information om arkitektur, konfiguration och bästa praxis som implementerats i detta automatiserade distributionsprojekt.
Standardanslutning med SSM på instansen
AWS Systems Manager (SSM) möjliggör standardanslutning till EC2-instansen utan att behöva använda SSH. Denna funktion förenklar åtkomsten till instansen och ökar säkerheten genom att undvika att exponera SSH-porten mot Internet. Det är dock alltid möjligt att ansluta till instansen via SSH genom att öppna rätt flöde med den associerade variabeln.
Självsignerat SSL-certifikat och säkerhet
Som standard gör LibreChat port 80 tillgänglig utan att aktivera port 443. I detta projekt är port 443 aktiverad som standard med ett självsignerat certifikat, och port 80 omdirigeras till port 443. Även om en HTTPS-varning visas i webbläsaren, erbjuder användningen av HTTPS-protokollet säkerhet mot lösenordsstöld på nätverket.
Slutsats
Detta projekt utforskar hur man distribuerar och konfigurerar LibreChat på en AWS EC2-instans med Terraform för infrastrukturen, ett User-Data-script i bash för installation av komponenterna, och AWS Systems Manager för centraliserad hantering av konfigurationer och uppföljning av distributionsförloppet. Vikt läggs också vid kostnadsreduktion med Spot Instances och säkerhet genom att använda ett självsignerat SSL-certifikat och konfigurera HTTP-säkerhetsrubriker.
Genom att använda detta projekt kommer du att kunna distribuera och konfigurera LibreChat på en AWS EC2-instans på ett effektivt, säkert och ekonomiskt sätt. Detta projekt kan utvidgas och anpassas för att distribuera andra webbapplikationer på AWS med samma principer för automatisering, Infrastructure as Code och centraliserad konfigurationshantering.
Fortsätt Utforska med GitLab-projektet
För en djupare förståelse och de tekniska detaljerna kring distributionen av LibreChat på AWS EC2, inklusive arkitektur och konfigurationer, rekommenderar jag starkt att besöka projektets README på GitLab. Denna artikel introducerar projektet, dess nyckelbegrepp och fördelarna med denna distribution, men det är i projekts länken du hittar alla detaljer.
Detta dokument har översatts från versionen fr till språket sv med hjälp av modellen gpt-4o. För mer information om översättningsprocessen, se https://gitlab.com/jls42/ai-powered-markdown-translator