Przejdź do treści głównej
Maciej JasiewiczEN

CI/CD i wdrożenia na Dockerze

Przyjmuję zlecenia freelance na konfigurację CI/CD i wdrożeń na Dockerze dla małych firm z jedną lub kilkoma aplikacjami webowymi. Pracuję z Gliwic albo zdalnie, równolegle do pracy w ONEXO.pl, więc biorę ograniczoną liczbę projektów naraz.

Zakres

Co konfiguruję

Pipeline w GitHub Actions lub GitLab CI

Automatyczne sprawdzenia przy każdej zmianie, potem build obrazu Dockera, który faktycznie trafi na produkcję, i wypchnięcie go do rejestru. Kroki są zapisane w repozytorium, a nie w czyjejś historii terminala.

Wdrożenie na serwer Linux

Docker Compose na VPS albo własnym serwerze, za reverse proxy z TLS. Publiczne jest tylko proxy; porty aplikacji i bazy danych są przypięte do localhosta, bo porty publikowane przez Dockera omijają firewall hosta, np. UFW.

Sekrety i dostęp

Sekrety w CI, a nie w repozytorium, osobny użytkownik i klucz do wdrożeń, SSH ograniczone do osób i systemów, które go potrzebują.

Rollback

Każde wydanie to otagowany obraz, więc powrót oznacza wdrożenie poprzedniego tagu. Nikt nie musi odtwarzać, co było na serwerze.

Kopie zapasowe i odtwarzanie

Backupy bazy danych przechowywane poza serwerem i odtworzenie przećwiczone przynajmniej raz, żeby wiedzieć, że działa, zanim będzie potrzebne.

Dokumentacja do przekazania

Jak wydać wersję, cofnąć ją i odtworzyć bazę, gdzie są sekrety i co gdzie działa. Wszystko zostaje w Twoim repozytorium i na Twoich kontach.

Przebieg

Jak zaczynamy

  1. Piszesz mi, jak aplikacja działa dziś: gdzie jest hostowana, gdzie jest kod i jak teraz wygląda wydanie nowej wersji.
  2. Przeglądam obecną konfigurację i odpowiadam z zakresem oraz tym, co zmieniłbym w pierwszej kolejności.
  3. Konfiguruję wszystko w Twoim repozytorium i na Twoim serwerze, na Twoich kontach.
  4. Razem przechodzimy przez dokumentację i z Twoim zespołem robimy pierwsze wydania oraz rollback.

Tło

Skąd to podejście

Zaczynałem tam, gdzie wdrożenie oznaczało git pull na serwerze produkcyjnym. Od tego czasu używam GitHub Actions i GitLab CI do budowania, wypychania i wdrażania obrazów Dockera. Powody opisałem w notatce Deployment powinien być nudny.

Podczas produkcyjnego incydentu DDoS kontener z opublikowanymi portami był dostępny bezpośrednio, mimo włączonego UFW na hoście. Dlatego przy każdym wdrożeniu sprawdzam, co jest wystawione na zewnątrz. Incydent opisuje case study, a sam mechanizm notatka Opublikowane porty Dockera omijają UFW.

FAQ

Częste pytania

Czy potrzebuję Kubernetesa?

Przy jednej aplikacji na jednym czy dwóch serwerach zwykle nie. Docker Compose na VPS jest prostszy w utrzymaniu i w przekazaniu. K3s uruchamiałem w prywatnym labie, nie u klientów, i nie polecam go domyślnie.

GitHub Actions czy GitLab CI?

To, na czym już jest Twój kod. Obu używałem do pipeline’ów budujących i wdrażających aplikacje.

Czy przejmiesz istniejącą konfigurację?

Tak. Zaczynam od przeczytania tego, co już jest: jak dziś wygląda wydanie, co działa na serwerze i czego nikt nie zapisał. Potem proponuję, co zmienić najpierw, i zostawiam te części, które działają.

Co dostaję na koniec?

Konfigurację pipeline’u i pliki wdrożeniowe w Twoim repozytorium, skonfigurowany serwer i dokumentację, z której zespół skorzysta beze mnie.

Czy to musi być aplikacja w Laravelu?

Większość mojej pracy komercyjnej to Laravel i PHP. Inne aplikacje webowe działające w Dockerze wdraża się według tego samego schematu.

W sprawie wdrożenia napisz na maciej@jasiewicz.pro albo zajrzyj na stronę kontaktową.