Docker: Wdrażanie z GitHub Actions

Dowiedz się, jak wdrażać kontenery Docker za pomocą GitHub Actions

👋 Witamy w dokumentacji Stackhero!

Stackhero oferuje gotowe do użycia rozwiązanie Docker cloud CaaS (Containers as a Service), które zapewnia wiele korzyści, w tym:

Łatwe wdrażanie kontenerów do produkcji za pomocą prostego docker-compose up.

Dostosowywana nazwa domeny zabezpieczona HTTPS (na przykład, https://api.twoja-firma.com, https://www.twoja-firma.com, https://backoffice.twoja-firma.com).

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

Bezproblemowe aktualizacje za pomocą jednego kliknięcia.

Oszczędzaj czas i upraszczaj swoje życie: wystarczy 5 minut, aby wypróbować rozwiązanie Docker CaaS cloud hosting Stackhero i wdrożyć swoje kontenery do produkcji!

GitHub Actions umożliwia automatyzację zadań, takich jak wdrażanie kontenerów Docker na serwery produkcyjne. W tym przewodniku dowiesz się, jak bezpiecznie i niezawodnie skonfigurować GitHub Actions do wdrażania kontenerów Docker w środowiskach staging i produkcyjnym.

Dla tej konfiguracji będziesz utrzymywać dwie gałęzie: staging i production. Kod wypchnięty do każdej gałęzi będzie automatycznie wdrażany na odpowiadającą instancję Stackhero.

Posiadanie instancji staging nie jest obowiązkowe. Możesz postępować zgodnie z tym przewodnikiem, używając tylko instancji produkcyjnej. Jednak aby zredukować ryzyko i zwiększyć pewność podczas wdrażania do produkcji, zdecydowanie zaleca się posiadanie zarówno instancji staging, jak i produkcyjnej. Jest to standard branżowy i najlepsza praktyka, która może pomóc uniknąć wielu potencjalnych problemów.

Przed rozpoczęciem upewnij się, że masz konto GitHub z repozytorium hostującym Twój kod.

Tworzenie usług Docker

Zacznij od zalogowania się do swojego panelu Stackhero i utworzenia dwóch usług Stackhero: jednej dla staging i jednej dla produkcji. Aby zminimalizować błędy, możesz zmienić nazwy tych usług na "Staging" i "Production".

Nie masz jeszcze konta Stackhero? Możesz je utworzyć za darmo w zaledwie dwie minuty, a następnie utworzyć swoje usługi chmurowe Docker za pomocą kilku kliknięć.

Przykład usług Docker

Konfiguracja zmiennych środowiskowych i sekretów

Uzyskaj nazwę domeny i hasło do certyfikatów

Aby umożliwić GitHub Actions połączenie z Twoją usługą Docker Stackhero, potrzebujesz dwóch informacji: nazwy domeny Twojej usługi i hasła do certyfikatów.

W panelu Stackhero wybierz swoją usługę Docker "production" i kliknij przycisk "Configure".

Uzyskaj ustawienia usługi
Skopiuj "Domain name" i "Docker certificates password" do użycia w kolejnych krokach.

Uzyskaj ustawienia usługi

Ustaw nazwę domeny i hasło do certyfikatów w GitHub

Przejdź do GitHub i wybierz swój projekt.
Kliknij Settings > Environments, a następnie New environment.

Konfiguracja środowisk GitHub
W polu Name wpisz "production" i potwierdź.

Ustawienie środowiska
Kliknij przycisk No restriction i wybierz Selected branches and tags.

Ustawienie ograniczeń środowiska
Kliknij Add deployment branch or tag rule, wpisz "production" w polu Name pattern, a następnie kliknij Add rule.

Ustawienie gałęzi środowiska Ustawienie gałęzi środowiska
W sekcji Environment secrets kliknij Add secret.

Dodaj sekret
Dla sekretu wpisz STACKHERO_CERTIFICATES_PASSWORD jako nazwę i wklej swoje hasło do certyfikatów jako Value.

Ustawienie sekretu hasła do certyfikatów
W sekcji Environment variables kliknij Add variable.

Ustawienie zmiennych
Wpisz STACKHERO_ENDPOINT jako nazwę i wklej swój endpoint usługi Docker w polu Value. Możesz znaleźć ten endpoint w swoim panelu Stackhero.

Ustawienie zmiennej endpoint

Jeśli dostosowałeś nazwę domeny swojej usługi, użyj wersji dostosowanej zamiast xxxxxx.stackhero-network.com.

Dostosowanie pliku konfiguracyjnego Docker Compose

Jeśli plik docker-compose.yml znajduje się w katalogu głównym Twojego projektu i nie są potrzebne żadne dostosowania, możesz pominąć tę sekcję.

Domyślnie GitHub Actions oczekuje, że plik Docker Compose docker-compose.yml będzie w katalogu głównym Twojego projektu. Jeśli musisz użyć innego pliku, możesz dostosować polecenie wdrażania. Na przykład, jeśli używasz naszego boilerplate dla Node.js i Docker, możesz utworzyć nową zmienną środowiskową o nazwie STACKHERO_DEPLOY_COMMAND i ustawić ją na:

docker compose --env-file env.list --file docker/docker-compose.yml --file docker/docker-compose.production.yml up --build --remove-orphans -d

Konfiguracja workflow GitHub Actions

Na swoim lokalnym komputerze przejdź do swojego repozytorium Git i utwórz katalog o nazwie .github/workflows. W tym katalogu utwórz plik o nazwie deploy-to-stackhero.yml z następującą zawartością:

# File: .github/workflows/deploy-to-stackhero.yml

name: Deploy to Stackhero
description: Wdrażanie gałęzi "${{ github.ref_name }}" do Stackhero

on:
  push:
    # Te gałęzie uruchamiają akcję wdrażania przy pushu.
    # Upewnij się, że tworzysz środowisko odpowiadające nazwie gałęzi w GitHub (w Settings > Environments).
    # Następnie dodaj sekret STACKHERO_CERTIFICATES_PASSWORD i zmienną STACKHERO_ENDPOINT w tym środowisku.
    branches: [ "production", "staging" ]

jobs:
  Deploy:
    environment: ${{ github.ref_name }}
    runs-on: ubuntu-latest
    steps:
    - uses: stackhero-io/github-actions-deploy-docker-containers-to-stackhero@v1
      with:
        # Sekret STACKHERO_CERTIFICATES_PASSWORD i zmienna STACKHERO_ENDPOINT powinny być zdefiniowane w odpowiadającym środowisku gałęzi na GitHub.
        certificates_password: ${{ secrets.STACKHERO_CERTIFICATES_PASSWORD }}
        endpoint: ${{ vars.STACKHERO_ENDPOINT }}
        # deployment_command jest opcjonalne. Użyj go, jeśli musisz dostosować polecenie Docker Compose.
        deployment_command: ${{ vars.STACKHERO_DEPLOY_COMMAND }}

Zatwierdź swoje zmiany, wykonując:

git add -A .
git commit -m "Add GitHub Actions to deploy to Stackhero"

Następnie utwórz gałąź produkcyjną, wykonując:

git checkout -b production

Na koniec wypchnij swoją gałąź produkcyjną do GitHub:

git push --set-upstream origin production

Po wypchnięciu GitHub Actions automatycznie wdroży Twój kod na Twoją instancję produkcyjną Stackhero. Możesz monitorować wdrażanie, odwiedzając kartę Actions w swoim projekcie GitHub.

GitHub Actions, które wdrożyły do produkcji

Gratulacje! Możesz teraz automatycznie wdrażać swój kod do produkcji za pomocą GitHub Actions.

Tworzenie środowiska staging

Konfiguracja środowiska staging jest podobna do konfiguracji produkcyjnej. Po prostu powtórz powyższe kroki, zastępując production staging.

Następnie utwórz gałąź staging, wykonując:

git checkout -b staging

Wypchnij swoją gałąź staging do GitHub za pomocą:

git push --set-upstream origin staging

GitHub Actions automatycznie wdroży Twoją gałąź staging na wyznaczoną instancję Docker dla staging.

Używanie zmiennych środowiskowych w docker-compose.yml

Możesz zdefiniować zmienne środowiskowe w swoim projekcie GitHub, które będą dostępne w Twoim pliku docker-compose.yml. Jest to przydatne, jeśli chcesz wdrażać na różne domeny (na przykład staging.my-company.com dla staging i my-company.com dla produkcji).

Na GitHub przejdź do Settings > Environments i utwórz zmienną środowiskową o nazwie WEBSITE_DOMAIN.
Dla środowiska staging ustaw WEBSITE_DOMAIN na "staging.my-company.com".
Dla środowiska produkcyjnego ustaw WEBSITE_DOMAIN na "my-company.com".

Następnie zaktualizuj plik .github/workflows/deploy-to-stackhero.yml, aby przekazać zmienną WEBSITE_DOMAIN do Stackhero GitHub Action:

name: Deploy to Stackhero
description: Wdrażanie gałęzi "${{ github.ref_name }}" do Stackhero

on:
  push:
    branches: [ "production", "staging" ]

jobs:
  Deploy:
    environment: ${{ github.ref_name }}
    runs-on: ubuntu-latest
    steps:
    - uses: stackhero-io/github-actions-deploy-docker-containers-to-stackhero@v1
      with:
        certificates_password: ${{ secrets.STACKHERO_CERTIFICATES_PASSWORD }}
        endpoint: ${{ vars.STACKHERO_ENDPOINT }}
        deployment_command: ${{ vars.STACKHERO_DEPLOY_COMMAND }}
      env:
        WEBSITE_DOMAIN: ${{ vars.WEBSITE_DOMAIN }}

Na koniec zaktualizuj swój plik docker-compose.yml, aby używać zmiennej WEBSITE_DOMAIN zamiast zakodowanej na stałe nazwy domeny:

services:
  test:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.test.rule=Host(`${WEBSITE_DOMAIN}`)" # Używa zmiennej środowiskowej WEBSITE_DOMAIN jako nazwy domeny.
      - "traefik.http.routers.test.tls.certresolver=letsencrypt"

Idąc dalej

Dobrą praktyką jest ochrona gałęzi production i staging, aby zapobiec bezpośrednim pushom. Z włączoną ochroną gałęzi, pull request musi być utworzony dla gałęzi staging, a następnie scalony przez osobę z odpowiednimi uprawnieniami. Po zatwierdzeniu na platformie staging, ten sam proces można zastosować do gałęzi production.

To podejście pomaga zapewnić zarówno bezpieczeństwo (tylko upoważnieni członkowie zespołu mogą wdrażać na staging i produkcję), jak i niezawodność (funkcje są testowane na platformie staging przed wdrożeniem do produkcji).