Elasticsearch: GitHub Actions & GitLab CI

Uruchom prawdziwą usługę Elasticsearch bezpośrednio z pipeline'u GitHub Actions lub GitLab CI, przetestuj ją, a następnie automatycznie ją usuń

👋 Witamy w dokumentacji Stackhero!

Stackhero oferuje gotowe do użycia rozwiązanie Elasticsearch cloud, które zapewnia wiele korzyści, w tym:

Optymalną wydajność i solidne zabezpieczenia dzięki prywatnej i dedykowanej VM.

Dostosowywalną nazwę domeny zabezpieczoną wsparciem szyfrowania HTTPS.

Oszczędzaj czas i upraszczaj sobie życie: wystarczy 5 minut, aby wypróbować rozwiązanie Elasticsearch cloud hosting Stackhero!

Ten przewodnik przeprowadzi Cię przez proces uruchamiania rzeczywistej, dedykowanej usługi Elasticsearch w Twoim pipeline CI z wykorzystaniem GitHub Actions lub GitLab CI. Dzięki poniższym krokom możesz testować swój kod na żywej instancji Elasticsearch w warunkach zbliżonych do produkcyjnych, bez konieczności korzystania z mocków czy symulacji. Elasticsearch is a distributed search and analytics engine that turns large volumes of data into fast, relevant answers.

Za każdym razem, gdy pipeline zostanie uruchomiony, otrzymasz nową instancję Elasticsearch. Oznacza to, że Twoje testy będą pracować z takim samym typem usługi, jaki zobaczą użytkownicy w środowisku produkcyjnym. Workflow automatycznie tworzy tymczasowy stack, dodaje usługę Elasticsearch, czeka na jej gotowość, pobiera wygenerowane dane dostępowe, wykonuje smoke test przy użyciu curl, a na końcu zawsze czyści wszystkie zasoby po zakończeniu działania.

Wykorzystasz Stackhero CLI, samodzielne narzędzie wiersza poleceń, które umożliwia szybkie i proste uruchamianie oraz zarządzanie usługami Stackhero.

1. Utwórz token dostępu i zapisz go jako sekret CI

Aby CLI mogło działać w trybie bezinteraktywnym, potrzebujesz tokena dostępu (format: usr-xxxxxx:tokenId). Token wystarczy utworzyć tylko raz, a następnie dodać go do pipeline'u CI jako bezpieczny, zaszyfrowany sekret.

Utwórz token: Na swoim dashboardzie Stackhero kliknij zdjęcie profilowe w prawym górnym rogu, przejdź do Twoje konto, następnie Access tokens i kliknij Create token.
Dla GitHub Actions: W repozytorium przejdź do Settings > Secrets and variables > Actions > New repository secret i wprowadź token jako STACKHERO_TOKEN.
Dla GitLab CI: W projekcie przejdź do Settings > CI/CD > Variables > Add variable, ustaw klucz na STACKHERO_TOKEN i zaznacz Masked (oraz Protected, jeśli pipeline uruchamiany jest tylko na chronionych branchach).

Nigdy nie umieszczaj tokena dostępu bezpośrednio w pliku YAML pipeline'u. Jeśli znajdzie się on w YAML, może być widoczny dla każdej osoby z dostępem do repozytorium i pojawić się w logach builda. Przechowywanie go jako sekret CI zapewnia szyfrowanie i maskowanie, dzięki czemu Twój token pozostaje bezpieczny.

2. Skrypt obsługujący cykl życia usługi

Poniżej znajdziesz kompletny przykład skryptu zarządzającego pełnym cyklem życia usługi. Pokazuje on, jak niewiele konfiguracji jest potrzebne – wystarczy kilka poleceń. Gotowe fragmenty YAML dla wybranej platformy znajdziesz w kolejnych sekcjach.

#!/bin/bash
set -euo pipefail

# STACKHERO_TOKEN jest przekazywany jako sekret CI, CLI wykrywa go automatycznie.

stackName="ci-elasticsearch-$$"          # Unikalna nazwa stacka dla każdego uruchomienia
serviceStore="elasticsearch"             # Store usługi Elasticsearch
instance="20G"        # Zmień w razie potrzeby (patrz krok 3)
region="europe"                         # Nazwa regionu (patrz stackhero regions-list)

# 1. Instalacja CLI na runnerze
curl -fsSL https://www.stackhero.io/install.sh | sh

# 2. Instalacja klienta wymaganego do smoke testu (jq + curl to podstawa)
apt-get update && apt-get install -y --no-install-recommends jq curl

# 3. Utworzenie dedykowanego stacka dla tego uruchomienia
stackId=$(stackhero --format=script stack-create --name="$stackName")
echo "Stack utworzony: $stackId"

# 4. Dodanie usługi Elasticsearch i pobranie jej service id
serviceId=$(stackhero --format=script service-add \
  --stack="$stackId" \
  --service-store="$serviceStore" \
  --instance="$instance" \
  --region="$region")
echo "Usługa dodana: $serviceId"

# 5. Oczekiwanie na uruchomienie usługi (może potrwać kilka minut)
stackhero service-wait-for --service="$serviceId"

# 6. Pobranie konfiguracji (zawiera wygenerowane dane dostępowe)
config=$(stackhero service-configuration-get --service="$serviceId" --format=json)

# 7. Wyodrębnienie potrzebnych danych dostępowych
host=$(echo "$config" | jq -r '.configuration.domain')
user=$(echo "$config" | jq -r '.configuration.credentials.login')
password=$(echo "$config" | jq -r '.configuration.credentials.password')

# 8. Smoke test: Call the cluster health endpoint.
curl -fsS -u "$user:$password" "https://$host:9200/_cluster/health" | grep -q '"status"'

echo "✅ Elasticsearch jest osiągalny z CI."

Krok usuwania, który kasuje usługę, czeka na jej usunięcie, a następnie usuwa stack, opisany jest w sekcjach specyficznych dla danej platformy poniżej. Takie podejście gwarantuje, że sprzątanie nastąpi zawsze, nawet jeśli smoke test się nie powiedzie.

Stack można usunąć tylko wtedy, gdy jest pusty. Zawsze najpierw usuń usługę i poczekaj na jej usunięcie, a dopiero potem usuń stack. Komenda service-wait-for zapewnia, że usługa jest uruchomiona lub usunięta przed przejściem dalej, dlatego jest właściwym narzędziem także do oczekiwania na usunięcie.

3. Wybierz rozmiar instancji

Poniższe przykłady domyślnie używają podstawowej instancji 20G dla Elasticsearch. To solidny wybór dla większości zastosowań, ale możesz go zmienić według potrzeb. Aby zobaczyć wszystkie dostępne typy instancji dla Elasticsearch, uruchom:

# Kolumna NAME pokazuje wartość do przekazania do --instance
stackhero instances-store-list --service-store=elasticsearch

4. GitHub Actions

Aby rozpocząć, zapisz poniższy kod jako .github/workflows/ci.yml. Od tej pory każdy push i pull request uruchomi testy na prawdziwej instancji Elasticsearch.

name: CI with Elasticsearch

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      STACKHERO_TOKEN: ${{ secrets.STACKHERO_TOKEN }}
      STACK_NAME: ci-elasticsearch-${{ github.run_id }}-${{ github.run_attempt }}
      INSTANCE: "20G"   # Zmień w razie potrzeby (patrz krok 3)
      REGION: europe
    steps:
      - uses: actions/checkout@v4

      - name: Instalacja Stackhero CLI i klienta
        run: |
          curl -fsSL https://www.stackhero.io/install.sh | sh
          apt-get update && apt-get install -y --no-install-recommends jq curl

      - name: Utworzenie usługi Elasticsearch
        run: |
          set -euo pipefail
          STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
          echo "STACK_ID=$STACK_ID" >> "$GITHUB_ENV"
          SERVICE_ID=$(stackhero --format=script service-add \
            --stack="$STACK_ID" \
            --service-store="elasticsearch" \
            --instance="$INSTANCE" \
            --region="$REGION")
          echo "SERVICE_ID=$SERVICE_ID" >> "$GITHUB_ENV"
          stackhero service-wait-for --service="$SERVICE_ID"

      - name: Uruchomienie testów na Elasticsearch
        run: |
          set -euo pipefail
          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')
          # Call the cluster health endpoint.
          curl -fsS -u "$user:$password" "https://$host:9200/_cluster/health" | grep -q '"status"'
          echo "✅ Elasticsearch jest osiągalny z CI."
          # Możesz uruchomić własny zestaw testów z powyższymi danymi dostępowymi ...

      - name: Sprzątanie (zawsze, nawet w przypadku błędu)
        if: always()
        run: |
          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

Krok sprzątania skonfigurowany jest z if: always(), dzięki czemu uruchamia się zawsze, niezależnie od wyniku, zapewniając usunięcie instancji Elasticsearch i brak naliczania opłat za nieużywane zasoby.

5. GitLab CI

Tę konfigurację możesz zapisać jako .gitlab-ci.yml. Dzięki temu każde uruchomienie pipeline'u utworzy nową, rzeczywistą instancję Elasticsearch do testów.

test:
  image: ubuntu:24.04
  variables:
    STACK_NAME: "ci-elasticsearch-$CI_PIPELINE_ID-$CI_JOB_ID"
    INSTANCE: "20G"   # Zmień w razie potrzeby (patrz krok 3)
    REGION: "europe"
    SERVICE_STORE: "elasticsearch"
  # STACKHERO_TOKEN pochodzi z utworzonej w kroku 1 zmiennej CI/CD.
  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
    - 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')
    # Call the cluster health endpoint.
    - curl -fsS -u "$user:$password" "https://$host:9200/_cluster/health" | grep -q '"status"'
    - echo "✅ Elasticsearch jest osiągalny z CI."
    # Możesz uruchomić własny zestaw testów z powyższymi danymi dostępowymi ...
  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

W GitLab sprzątanie odbywa się w sekcji after_script. Ta część wykonywana jest zawsze, nawet jeśli job zakończy się niepowodzeniem, dzięki czemu zasoby Elasticsearch są usuwane i nie ponosisz kosztów za nieużywane instancje.

W GitLab after_script uruchamiany jest w nowej powłoce. Aby to obsłużyć, skrypt zapisuje identyfikatory usługi i stacka do pliku deploy.env podczas joba i ładuje je ponownie przed sprzątaniem. Dzięki temu, nawet jeśli coś się nie powiedzie w trakcie joba, Twoje zasoby zostaną poprawnie usunięte.

To kompletny cykl CI dla Elasticsearch: utwórz stack, dodaj usługę, poczekaj, pobierz dane dostępowe, wykonaj smoke test i zawsze posprzątaj. Każde uruchomienie pipeline'u korzysta z prawdziwej, odizolowanej usługi, a po zakończeniu nie pozostają żadne działające zasoby. Więcej informacji o dostępnych poleceniach i uwierzytelnianiu nieinteraktywnym przez STACKHERO_TOKEN znajdziesz w pełnej dokumentacji CLI.