Portainer — pierwsze uruchomienie

Spis treści:

• Tworzenie konta
• Get Started
• Zmiana nazwy środowiska
• Omówienie interfejsu
• Administration — centrum zarządzania
• Co dalej?

---

Tworzenie konta administratora pomiń

Jeśli masz już za sobą pierwsze uruchomienie i utworzenie konta administratora — świetnie, możesz iść dalej. Jeżeli nie, zacznij od wejścia pod adres:

https://<<TWOJE IP SERVERA>>:9433

Na ekranie zobaczysz formularz tworzenia konta administratora.

Podaj nazwę użytkownika (np. admin) i ustaw silne hasło. To dobry moment, żeby zadbać o bezpieczeństwo — nawet jeśli to środowisko domowe i działa tylko w sieci lokalnej.

Nawyki wyniesione z początku konfiguracji zostają na długo, a Portainer to centrum zarządzania całą infrastrukturą — warto więc od razu traktować go jak narzędzie produkcyjne, a nie „tymczasowy panel”.

---

Get Started pomiń

Klikamy „Get Started”.

Po chwili zostaniesz przekierowany do sekcji Environments i zobaczysz mniej więcej taki widok:

Co tu właściwie widzisz?

Sekcja Environments to lista środowisk, którymi zarządza Portainer. W praktyce są to instancje Dockera, do których Portainer ma dostęp.

Dla świeżej instalacji powinieneś zobaczyć jedno środowisko, zwykle z nazwą:

• Name: local
• Last check-in: aktualna data i godzina (informacja, że silnik Dockera jest osiągalny)
• Type: Standalone
• Engine: wersja Dockera
• Endpoint: lokalny socket Dockera

---

Zmieniamy nazwę środowiska pomiń

Na start warto uporządkować nazewnictwo.

Zamiast domyślnego localhost zmień nazwę środowiska np. na:

serv-prod-1

(lub cokolwiek, co będzie dla Ciebie czytelne).

1. Kliknij ikonę ołówka przy środowisku.

Zmień nazwę i kliknij Update environment.

Od razu robi się czytelniej — i to nie tylko wizualnie. Dlaczego to ma sens? Portainer możesz traktować jak centralny panel zarządzania infrastrukturą. Dzisiaj masz jeden serwer. Jutro możesz dodać kolejny — np.:

• do testów,
• do backupów,
• pod osobne usługi,
• albo jako zapasowy węzeł.

Wystarczy wtedy dodać nowe środowisko do Portainer za pomocą portainer-agent i od tego momentu będziesz w stanie zarządzasz wieloma serwerami z jednego miejsca.

To właśnie jest cel tej konfiguracji:

• jeden punkt wejścia do całej infrastruktury, niezależnie od tego, ile maszyn finalnie będziesz mieć.

---

Omównie GUI pomiń

Spis treści:

• Dashboard
• Stacks
• Images
• Networks
• Volumes
• Containers
• Templates
• Host

Zanim przejdziemy do dalej, jedna ważna rzecz.

Zrzuty ekranu, które zobaczysz w tej sekcji, pochodzą z mojej prawdziwej instalacji. Celowo nie budowałem tu „sztucznego” środowiska tylko na potrzeby tutoriala.

Dlaczego?

Bo już na tym etapie chcę, żebyś zobaczył:

• jak usługi naprawdę wyglądają w działającym systemie,
• jak są ze sobą powiązane,
• i w jaki sposób organizuję je w logiczne grupy.

Pod każdą sekcją postaram się też krótko wyjaśnić dlaczego zrobiłem coś właśnie w taki sposób — nie tylko co kliknąć, ale po co. Dzięki temu łatwiej będzie Ci później budować własne środowisko, a nie tylko odtwarzać kroki z instrukcji.

No to… możemy zaczynać ;)

---

Dashboard pomiń

Aby przejść do dashboardu, kliknij w panel środowiska. Zobaczysz ekran z kilkoma przydatnymi kafelkami podsumowującymi jego stan:

Najważniejsze sekcje to:

• stacks
• images
• Networks
• Containers
• Volumes

Przejdźmy przez nie po kolei.

---

Stacks pomiń

Stacks to sposób na zarządzanie grupą powiązanych usług jako jedną całością. Najczęściej są to pliki docker-compose.yml, które Portainer uruchamia i kontroluje jako jeden „pakiet”.

Dlaczego to jest tak ważne?

Stack to nie tylko „worek kontenerów”, ale pełnoprawne środowisko:

• automatycznie tworzona jest wspólna sieć dla usług w stacku,
• kontenery mogą komunikować się ze sobą po nazwie usługi, np. database, mqtt, grafana,
• całość można: uruchomić lub zatrzymać jednym kliknięciem.

Dzięki stackom:

• konfiguracja jest powtarzalna,
• łatwiej przenosić środowisko na inny serwer,
• łatwiej zarządzać usługami w grupie.

Jak możesz zauważyć na screenie, mam kilka stacków. Wygląda to mniej więcej tak:

• home_automation — Home Assistant + inne komponenty wspomagające automatykę (np.: node-red)
• mqtt — broker EMQX
• service_storage — bazy danych
• zigbee_proxy — Zigbee2MQTT

To są osobne stacki, ale wszystkie są spięte jedną wspólną siecią: proxy.

Dlaczego rozdzielone, a jednak połączone?

Bo to daje najlepsze z obu światów.

Izolacja. Każdy stack to osobna jednostka zarządzania,

• aktualizacja Zigbee2MQTT nie restartuje brokera MQTT czy Home Assistant
• aktualizacja Home Assistant nie wpływa na EMQX, bazę danych czy inne usługi.

Czyli: zero efektu domina.

Wspólna komunikacja. Dzięki jednej sieci proxy, wszystkie stacki nadal mogą się widzieć, a usługi komunikują się po nazwach kontenerów, nie trzeba wystawiać wszystkiego na porty hosta. Mam więc separację odpowiedzialności, kontrolę nad restartami, i jednocześnie spójny ekosystem usług.

W praktyce oznacza to tyle że każdy komponent żyje swoim życiem, ale cały system działa jak jedna, dobrze zsynchronizowana infrastruktura. I dokładnie o to chodzi w sensownym projektowaniu środowiska pod Home Assistant.

---

Images pomiń

Pull images

Od góry możesz zobaczyć sekcje gdzie możesz pobrać obrazy Dockera.

Po kliknięciu w Search zostaniesz przekierowany na oficjalną stronę Docker Hub.

Tam możesz:

• wyszukiwać obrazy,
• sprawdzać dostępne wersje,
• wybrać dokładny tag, który chcesz użyć.

Przykład

Jeśli chcesz pobrać obraz MariaDB w wersji 12.1.2, wpisz:

mariadb:12.1.2

i kliknij Pull the image — Portainer pobierze dokładnie tę wersję.

Obrazy z innych rejestrów

Nie wszystkie obrazy są na Docker Hubie. Część projektów (np. Home Assistant) trzyma obrazy w GitHub Container Registry (ghcr).

Wtedy wystarczy:

• Przełączyć się w Advanced mode.
• Wkleić pełną ścieżkę do obrazu, np.:

ghcr.io/home-assistant/home-assistant:latest

Kliknąć Pull the image — i gotowe.

Ale...

GUI do pullowania obrazów jest fajne na start, do testów albo szybkiego sprawdzenia czegoś nowego. W produkcji lepiej, żeby obrazy pojawiały się same — jako efekt deploy-u, a nie ręcznego klikania. Dokładnie do tego zmierzamy w kolejnych krokach

---

Lista

Sekcja Images pokazuje wszystkie obrazy Dockera, które zostały pobrane na serwer.

Tabela zawiera informacje o:

• id obrazu,
• tagu (np. latest, v2.1),
• rozmiarze,
• dacie utworzenia.

Obrazy, które nie są używane przez żaden kontener, będą oznaczone jako Unused. Takie obrazy możesz bezpiecznie usuwać — to dobry sposób na odzyskanie miejsca na dysku i utrzymanie porządku w systemie.

---

Networks pomiń

Networks to wewnętrzne sieci Dockera, które łączą kontenery ze sobą.

Możesz mieć:

• jedną sieć dla całego stacka,
• osobne sieci dla różnych grup usług,
• sieci izolujące konkretne kontenery od reszty systemu.
• możesz mieć współdzielić sieci między stackami.

Dzięki sieciom:

• kontrolujesz, które usługi się widzą,
• poprawiasz bezpieczeństwo,
• unikasz konfliktów portów.

W dobrze poukładanej infrastrukturze sieci są tak samo ważne jak same kontenery.

---

Volumes pomiń

Volumes to trwała przestrzeń na dane.

Najprościej mówiąc: to katalogi na dysku, w których kontenery zapisują wszystko, co ma przetrwać restart:

• konfiguracje,
• bazy danych,
• logi,
• cache.

Bez volumes każdy restart kontenera oznaczałby utratę danych. Z nimi system działa jak „dorosła” infrastruktura, a nie jednorazowe środowisko testowe.

Ale...

W modelu, którego będziemy używać w tym projekcie, nie korzystamy z wolumenów zarządzanych przez Dockera z poziomu Portainer. Dlatego w zakładce Volumes często… nie zobaczysz nic istotnego.

I to jest celowe.

Całe trwałe dane będziemy montować w kontenerach jako bind mounts — czyli:

• katalogi na hoście (np. /opt/homeassistant, /opt/mariadb)
• bezpośrednio podpinane do kontenerów w plikach docker-compose.

Dzięki temu:

• dokładnie wiesz, gdzie fizycznie leżą dane,
• backup nie wymaga żadnych sztuczek — to zwykłe kopie katalogów,
• przeniesienie usług na inny serwer to po prostu skopiowanie folderów,
• nie jesteś uzależniony od „magii Dockera” ani od konkretnego narzędzia do zarządzania.

W skrócie: kontenery są tymczasowe, dane są trwałe — i właśnie tak powinna wyglądać zdrowa infrastruktura.

---

Containers pomiń

I wreszcie najczęściej używana sekcja — Containers.

To tutaj:

• widzisz wszystkie uruchomione usługi,
• sprawdzasz ich status,
• podglądasz logi,
• restartujesz kontenery,

W praktyce to Twoje centrum operacyjne: jeśli coś nie działa — zaczynasz właśnie tutaj.

Jak możesz zauważyć na screenie, przy kontenerze Portainer (u Ciebie pewnie też tak jest) nie ma możliwości jego zaznaczenia ani zarządzania nim z poziomu GUI. Dlaczego nie możesz zarządzać kontenerem Portainer?

Bo Portainer został uruchomiony bezpośrednio przez docker run, a nie jako stack zarządzany przez samego siebie. Żeby Portainer mógł w pełni zarządzać kontenerami, muszą one zostać utworzone przez Portainera (np. jako stack, container lub service).

Czy to dobrze czy źle?

Trochę jedno i drugie:

• dobrze, bo Portainer nie zarządza sam sobą — nie ma ryzyka przypadkowego zatrzymania panelu,
• nie do końca dobrze, bo nie masz nad nim tej samej kontroli co nad resztą infrastruktury.

W praktyce to jednak najczęściej spotykany i bezpieczny model uruchamiania Portainera.

Co dokładnie widzisz na liście kontenerów?

Na górze masz ikony akcji — większość z nich jest intuicyjna, dlatego nie będziemy ich tu szczegółowo omawiać.

Wyjątkiem jest Add container — do tego wrócimy w osobnym wpisie, bo w naszej architekturze raczej nie będziemy z tego korzystać (stawiamy na stacki i GitOps).

Niżej widzisz tabelę z kontenerami. Każda kolumna ma konkretne znaczenie:

Name – nazwa kontenera

State – aktualny stan (running, stopped, unhealthy itd.)

Quick Actions – szybki dostęp do:

• logów,
• szczegółów kontenera,
• użycia zasobów,
• konsoli,
• opcji Attach Console (bezpośrednie podpięcie się do procesu w kontenerze)

Stack – nazwa stacka, do którego należy kontener

Image – obraz Dockera, z którego został utworzony

Created – data utworzenia kontenera

IP address – adres IP kontenera w sieci Dockera

Published ports – mapowanie portów:

• zewnętrzny → wewnętrzny
• brak portów oznacza, że kontener działa w trybie network_mode: host lub kontener nie publikuje żadnych portów.

Ten widok to miejsce, do którego będziesz wracał najczęściej: przy debugowaniu, aktualizacjach, restartach i każdej awarii. Warto dobrze go znać — to Twoje centrum dowodzenia infrastrukturą

---

Templates pomiń

Zakładka Templates to galeria gotowych szablonów aplikacji, które możesz uruchomić w Portainerze jednym kliknięciem.

W praktyce są to predefiniowane konfiguracje kontenerów dla popularnych usług, takich jak:

• bazy danych (MariaDB, PostgreSQL),
• narzędzia developerskie,
• systemy monitoringu,
• aplikacje self-hosted.

Do czego to się przydaje?

Templates są świetne, gdy:

• chcesz szybko przetestować jakąś usługę,
• nie masz jeszcze własnego docker-compose.yml,
• stawiasz coś „na chwilę”.

Ale…

W dłuższej perspektywie warto traktować templates raczej jako:

• punkt startowy, a nie docelowe rozwiązanie.

Dlaczego?

• nie zawsze masz pełną kontrolę nad konfiguracją,
• trudniej wersjonować zmiany,
• trudniej przenieść konfigurację na inny serwer.

W moim setupie templates wykorzystuję głównie:

• do testów,
• do szybkiego prototypowania, a produkcyjne usługi uruchamiam przez Stacks z repozytoriów Git.

---

Host pomiń

Zakładka Host dotyczy bezpośrednio serwera, na którym działa Docker. To tutaj sprawdzisz nie tylko kontenery, ale samą maszynę, na której wszystko się kręci.

Host overview

W tej sekcji znajdziesz szybki podgląd stanu hosta:

• użycie CPU,
• użycie RAM,
• przestrzeń dyskową,
• liczbę uruchomionych kontenerów,
• status silnika Dockera.

To bardzo przydatne miejsce, gdy:

• coś działa wolniej niż zwykle,
• chcesz sprawdzić, czy serwer „nie puchnie”,
• diagnozujesz problemy z wydajnością.

Docker features configuration

Tutaj zarządzasz funkcjami samego Dockera z poziomu Portainera.

W zależności od konfiguracji możesz m.in.:

• włączyć lub wyłączyć określone funkcje silnika,
• sprawdzić dostępne możliwości runtime,
• zarządzać ustawieniami bezpieczeństwa.

To nie jest sekcja, do której zagląda się codziennie — ale warto wiedzieć, że istnieje, gdy zaczynasz:

• budować bardziej złożoną infrastrukturę,
• pracować z wieloma środowiskami,
• optymalizować bezpieczeństwo.

Environment registries

Registries to miejsca, z których Docker pobiera obrazy.

Domyślnie korzystasz z Docker Hub.

Po kliknięciu Add registry zostaniesz przeniesiony do kreatora konfiguracji nowego rejestr:

Możesz tu skonfigurować:

• prywatne Docker rejestry obrazów,
• AWS ECR,
• GitHub Container Registry
• GitLab Registry,
• własne registry w firmie lub w domu.

Po co to w ogóle robić?

• gdy chcesz hostować własne obrazy,
• gdy pracujesz zespołowo,
• gdy nie chcesz polegać na publicznych repozytoriach,
• gdy zależy Ci na kontroli wersji i bezpieczeństwie.

W praktyce: to krok w stronę bardziej profesjonalnej infrastruktury, nawet jeśli cały setup działa tylko w domu.

---

Administration — centrum zarządzania Portainerem pomiń

Sekcja Administration to miejsce, w którym nie zarządzasz już kontenerami, ale samym Portainerem jako platformą.

Tutaj ustawiasz:

• kto ma dostęp do infrastruktury,
• do czego dokładnie ma dostęp,
• jak Portainer łączy się z rejestrami obrazów,
• jak działa autoryzacja, logowanie i powiadomienia.

Krótko mówiąc: to panel sterowania całym systemem zarządzania Dockerem.

---

User-related — zarządzanie ludźmi

Users

Lista wszystkich użytkowników Portainera.

Tutaj możesz:

• dodawać nowych użytkowników,
• resetować hasła,
• dezaktywować konta,
• przypisywać role.

To pierwszy krok, jeśli Portainer ma być czymś więcej niż tylko panelem dla jednej osoby.

Teams

Zespoły użytkowników.

Zamiast nadawać uprawnienia każdej osobie osobno, tworzysz team i przypisujesz do niego użytkowników.

Przykład:

• admins
• devops
• developers
• read-only

Potem jednym ruchem nadajesz dostęp całemu zespołowi do wybranych środowisk.

Roles

Role definiują co użytkownik może robić, a nie tylko gdzie ma dostęp.

Możesz tu określić:

• kto może tworzyć stacki,
• kto może restartować kontenery,
• kto ma tylko podgląd,
• kto ma pełne prawa administracyjne.

niestety Business Feature

---

Environment-related — zarządzanie środowiskami

Environments

Lista wszystkich środowisk Dockera, którymi zarządza Portainer.

To mogą być:

• lokalne instancje,
• zdalne serwery,
• klastry,
• edge devices.

Każde środowisko to osobny „świat”, ale zarządzany z jednego miejsca.

Groups

Grupy środowisk.

Jeśli masz:

• prod-servers,
• test-servers,
• lab-servers

to zamiast nadawać uprawnienia osobno do każdego środowiska, robisz to na poziomie grupy.

Bardzo przydatne przy większej infrastrukturze.

Tags

Tagi to sposób na logiczne oznaczanie środowisk.

Np:

• production
• critical
• edge
• home-lab

Nie wpływają bezpośrednio na uprawnienia, ale bardzo ułatwiają orientację, gdy środowisk zaczyna przybywać.

---

Registries

Tutaj konfigurujesz rejestry obrazów Docker:

• Docker Hub,
• GitHub Container Registry (ghcr.io),
• GitLab Registry,
• prywatne registry w firmie.

Dzięki temu Portainer może:

• pobierać obrazy z prywatnych repozytoriów,
• używać tokenów i kluczy,
• działać bez ręcznego logowania się do registry na serwerze.

To kluczowa sekcja, jeśli pracujesz z CI/CD i prywatnymi obrazami.

---

Logs — audyt i bezpieczeństwo

Authentication

Logi związane z logowaniem:

• kto się logował,
• kiedy,
• z jakiego IP,
• czy próba była udana.

Podstawa przy kontroli bezpieczeństwa.

niestety Business Feature

Activity

Dziennik aktywności w Portainerze.

Zobaczysz tu:

• kto uruchomił stack,
• kto zatrzymał kontener,
• kto zmienił konfigurację.

To Twój audit log — bardzo ważny, gdy z Portainer korzysta więcej niż jedna osoba.

niestety Business Feature

---

Notifications

Wszystkie powiadomienia z Portainer, np.: Container successfully restarted.

---

Settings — konfiguracja platformy

General

Podstawowe ustawienia Portainer:

• ustawienie custom logo
• dodanie własnych templates
• ustawienia dla instalacji Kubernetes
• SSL
• Ukrywanie kontenerów
• Backup usługi

Authentication

W tym miejscu ustawisz:

• Długość trwania sesji (mniej = bezpieczniej)
• Metode autoryzacji
• Zmienisz wymóg długości hasła

Edge Compute

Sekcja Edge Compute służy do zarządzania zdalnymi hostami, które:

• są za NAT-em,
• nie mają publicznego IP,
• działają w oddalonych lokalizacjach (IoT, edge, oddziały firmy),
• nie mogą być podłączone do Portainer w klasyczny sposób.

W typowym homelabie raczej jej nie użyjesz, ale warto wiedzieć co tu się dzieje, bo to potężna funkcjonalność.