Memcached: 5. GitLab CI
Cette documentation fait partie du guide GitHub Actions & GitLab CI. Consultez le guide complet ici : Lancez un vrai service Memcached à partir de votre pipeline GitHub Actions ou GitLab CI, exécutez vos tests dessus, puis supprimez-le automatiquement.
Bienvenue dans la documentation Stackhero
Stackhero offre un cloud Memcached entièrement géré qui simplifie la mise en cache des applications, tout en assurant sécurité et performance élevée.
- Appliquez les mises à jour en quelques secondes, d’un simple clic.
- Profitez d’une performance constante et d’une sécurité robuste sur une infrastructure privée et dédiée.
Libérez votre temps et concentrez-vous sur le développement. L’hébergement cloud Memcached de Stackhero est prêt à l’emploi en environ 5 minutes.
Vous pouvez enregistrer cette configuration sous .gitlab-ci.yml. Avec ce setup, chaque pipeline crée une nouvelle instance Memcached pour vos tests.
test:
image: ubuntu:24.04
variables:
STACK_NAME: "ci-memcached-$CI_PIPELINE_ID-$CI_JOB_ID"
INSTANCE: "1G" # Modifiez si besoin (voir étape 3)
REGION: "europe"
SERVICE_STORE: "memcached"
# STACKHERO_TOKEN provient de la variable CI/CD créée à l'étape 1.
script:
- set -euo pipefail
- curl -fsSL https://www.stackhero.io/install.sh | sh
- apt-get update && apt-get install -y --no-install-recommends jq curl libmemcached-tools
- STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
- echo "STACK_ID=$STACK_ID" >> deploy.env
- SERVICE_ID=$(stackhero --format=script service-add --stack="$STACK_ID" --service-store="$SERVICE_STORE" --instance="$INSTANCE" --region="$REGION")
- echo "SERVICE_ID=$SERVICE_ID" >> deploy.env
- stackhero service-wait-for --service="$SERVICE_ID"
- config=$(stackhero service-configuration-get --service="$SERVICE_ID" --format=json)
- host=$(echo "$config" | jq -r '.configuration.domain')
user=$(echo "$config" | jq -r '.configuration.credentials.login')
password=$(echo "$config" | jq -r '.configuration.credentials.password')
# Authenticate with SASL and read a key (a miss still proves auth works).
- memccat --servers="$host:11211" --binary --username="$user" --password="$password" stackhero-ci-probe 2>&1 | grep -vq "AUTHENTICATION"
- echo "✅ Memcached est accessible depuis la CI."
# Vous pouvez lancer votre propre suite de tests ici avec les identifiants ci-dessus ...
after_script:
- test -f deploy.env && . ./deploy.env || true
- >
if [ -n "${SERVICE_ID:-}" ]; then
stackhero service-delete --service="$SERVICE_ID" --confirm
stackhero service-wait-for --service="$SERVICE_ID"
fi
- >
if [ -n "${STACK_ID:-}" ]; then
stackhero stack-delete --stack="$STACK_ID" --confirm
fi
Sur GitLab, le nettoyage s'effectue dans after_script. Cette section est toujours exécutée, même si le job échoue, ce qui garantit la suppression de vos ressources Memcached et évite toute facturation inutile.
Sur GitLab,
after_scripts'exécute dans un shell vierge. Pour gérer cela, le script écrit les IDs du service et de la stack dansdeploy.envpendant le job, puis les recharge avant le nettoyage. Ainsi, même en cas d'échec en cours de job, vos ressources sont bien supprimées.
Voilà le cycle CI complet pour Memcached : création d'une stack, ajout du service, attente, récupération des identifiants, smoke test, et nettoyage systématique. Chaque exécution de pipeline bénéficie d'un service réel et isolé, sans rien laisser tourner après coup. Pour plus d'informations sur les commandes disponibles et l'authentification non interactive avec STACKHERO_TOKEN, vous pouvez consulter la documentation CLI complète.